Subhu writes that OpenStack’s blossoming project list comes at a cost to quality. I’d like to follow up with an even leaner approach based on an outline drafted during the OpenStack Core discussions after ODS Hong Kong, a year ago.
The key ideas in that draft are:
Only call services “core” if the user can detect them.
How the cloud is deployed or operated makes no difference to a user. We want app developers to
Define both “core” and “common” services, but require only “core” services for a cloud that calls itself OpenStack compatible.
Separation of core and common lets us recognise common practice today, while also acknowledging that many ideas we’ve had in the past year or three are just 1.0 iterations, we don’t know which of them will stick any more than one could predict which services on any major public cloud will thrive and which will vanish over time. Signalling that something is “core” means it is something we commit to keeping around a long time. Signalling something is “common” means it’s widespread practice for it to be available in an OpenStack environment, but not a requirement.
Require that “common” services can be self-deployed.
Just as you can install a library or a binary in your home directory, you can run services for yourself in a cloud. Services do not have to be provided by the cloud infrastructure provider, they can usually be run by a user themselves, under their own account, as a series of VMs providing network services. Making it a requirement that users can self-provide a service before designating it common means that users can build on it; if a particular cloud doesn’t offer it, their users can self-provide it. All this means is that the common service itself builds on core services, though it might also depend on other common services which could be self-deployed in advance of it.
Require that “common” services have a public integration test suite that can be run by any user of a cloud to evaluate conformance of a particular implementation of the service.
For example, a user might point the test suite at HP Cloud to verify that the common service there actually conforms to the service test standard. Alternatively, the user who self-provides a common service in a cloud which does not provide it can verify that their self-deployed common service is functioning correctly. This also serves to expand the test suite for the core: we can self-deploy common services and run their test suites to exercise the core more thoroughly than Tempest could.
Keep the whole set as small as possible.
We know that small is beautiful; small is cleaner, leaner, more comprehensible, more secure, easier to test, likely to be more efficiently implemented, easier to attract developer participation. In general, if something can be cut from the core specification it should. “Common” should reflect common practice and can be arbitrarily large, and also arbitrarily changed.
In the light of those ideas, I would designate the following items from Subhu’s list as core OpenStack services:
Keystone (without identity, nothing)
Nova (the basis for any other service is the ability to run processes somewhere)
Glance (hard to use Nova without it)
Neutron (where those services run)
Designate (DNS is a core aspect of the network)
Cinder (where they persist data)
I would consider these to be common OpenStack services:
SWIFT (widely deployed, can be self-provisioned with Cinder block backends)
Ceph RADOS-GW object storage (widely deployed as an implementation choice, common because it could be self-provided on Cinder block)
Horizon (widely deployed, but we want to encourage innovation in the dashboard)
And these I would consider neither core nor common, though some of them are clearly on track there:
Barbican (not widely implemented)
Ceilometer (internal implementation detail, can’t be common because it requires access to other parts)
Juju (not widely implemented)
Kite (not widely implemented)
HEAT (on track to become common if it can be self-deployed, besides, I eat controversy for breakfast)
MAAS (who cares how the cloud was built?)
Manila (not widely implemented, possibly core once solid, otherwise common once, err, common)
Sahara (not widely implemented, weird that we would want to hardcode one way of doing this in the project)
Triple-O (user doesn’t care how the cloud was deployed)
Trove (not widely implemented, might make it to “common” if widely deployed)
Tuskar (see Ironic)
Zaqar (not widely implemented)
In the current DefCore discussions, the “layer” idea has been introduced. My concern is simple: how many layers make sense? End users don’t want to have to figure out what lots of layers mean. If we had “OpenStack HPC” and “OpenStack Scientific” and “OpenStack Genomics” layers, that would just be confusing. Let’s keep it simple – use “common” as a layer, but be explicit that it will change to reflect common practice (of course, anything in common is self-reinforcing in that new players will defer to norms and implement common services, thereby entrenching common unless new ideas make services obsolete).
This upstirring undertaking Ubuntu is, as my colleague MPT explains, performance art. Not only must it be art, it must also perform, and that on a deadline. So many thanks and much credit to the teams and individuals who made our most recent release, the Trusty Tahr, into the gem of 14.04 LTS. And after the uproarious ululation and post-release respite, it’s time to open the floodgates to umpteen pent-up changes and begin shaping our next show.
The discipline of an LTS constrains our creativity – our users appreciate the results of a focused effort on performance and stability and maintainability, and we appreciate the spring cleaning that comes with a focus on technical debt. But the point of spring cleaning is to make room for fresh ideas and new art, and our next release has to raise the roof in that regard. And what a spectacular time to be unleashing creativity in Ubuntu. We have the foundations of convergence so beautifully demonstrated by our core apps teams – with examples that shine on phone and tablet and PC. And we have equally interesting innovation landed in the foundational LXC 1.0, the fastest, lightest virtual machines on the planet, born and raised on Ubuntu. With an LTS hot off the press, now is the time to refresh the foundations of the next generation of Linux: faster, smaller, better scaled and better maintained. We’re in a unique position to bring useful change to the ubiquitary Ubuntu developer, that hardy and precise pioneer of frontiers new and potent.
That future Ubuntu developer wants to deliver app updates instantly to users everywhere; we can make that possible. They want to deploy distributed brilliance instantly on all the clouds and all the hardware. We’ll make that possible. They want PAAS and SAAS and an Internet of Things that Don’t Bite, let’s make that possible. If free software is to fulfil its true promise it needs to be useful for people putting precious parts into production, and we’ll stand by our commitment that Ubuntu be the most useful platform for free software developers who carry the responsibilities of Dev and Ops.
It’s a good time to shine a light on umbrageous if understandably imminent undulations in the landscape we love – time to bring systemd to the centre of Ubuntu, time to untwist ourselves from Python 2.x and time to walk a little uphill and, thereby, upstream. Time to purge the ugsome and prune the unusable. We’ve all got our ucky code, and now’s a good time to stand united in favour of the useful over the uncolike and the utile over the uncous. It’s not a time to become unhinged or ultrafidian, just a time for careful review and consideration of business as usual.
So bring your upstanding best to the table – or the forum – or the mailing list – and let’s make something amazing. Something unified and upright, something about which we can be universally proud. And since we’re getting that once-every-two-years chance to make fresh starts and dream unconstrained dreams about what the future should look like, we may as well go all out and give it a dreamlike name. Let’s get going on the utopic unicorn. Give it stick. See you at vUDS.
ACPI comes from an era when the operating system was proprietary and couldn’t be changed by the hardware manufacturer.
We don’t live in that era any more.
However, we DO live in an era where any firmware code running on your phone, tablet, PC, TV, wifi router, washing machine, server, or the server running the cloud your SAAS app is running on, is a threat vector against you.
If you read the catalogue of spy tools and digital weaponry provided to us by Edward Snowden, you’ll see that firmware on your device is the NSA’s best friend. Your biggest mistake might be to assume that the NSA is the only institution abusing this position of trust – in fact, it’s reasonable to assume that all firmware is a cesspool of insecurity courtesy of incompetence of the worst degree from manufacturers, and competence of the highest degree from a very wide range of such agencies.
In ye olden days, a manufacturer would ship Windows, which could not be changed, and they wanted to innovate on the motherboard, so they used firmware to present a standard interface for things like power management to a platform that could not modified to accommodate their innovation.
Today, that same manufacturer can innovate on the hardware and publish a patch for Linux to express that innovation – and Linux is almost certainly the platform that matters. If Windows enters this market then the Windows driver model can evolve to give manufacturers this same ability to innovate in the Windows world, where proprietary unverifiable blobs are the norm.
Arguing for ACPI on your next-generation device is arguing for a trojan horse of monumental proportions to be installed in your living room and in your data centre. I’ve been to Troy, there is not much left.
We’ve spent a good deal of time working towards a world where you can inspect the code that is running on any device you run. In Ubuntu we work hard to make sure that any issues in that code can be fixed and delivered right away to millions of users. Bruce Schneier wisely calls security a process, not a product. But the processes for finding and fixing problems in firmware are non-existent and not improving.
I would very much like to be part of FIXING the security problem we engineers have created in our rush to ship products in the olden days. I’m totally committed to that.
So from my perspective:
Upstream kernel is the place to deliver the software portion of the innovation you’re selling. We have great processes now to deliver that innovation to users, and the same processes help us improve security and efficiency too.
Declarative firmware that describes hardware linkages and dependencies but doesn’t include executable code is the best chance we have of real bottom-up security. The Linux device tree is a very good starting point. We have work to do to improve it, and we need to recognise the importance of being able to fix declarations over the life of a product, but we must not introduce blobs in order to short cut that process.
Let’s do this right. Each generation gets its turn to define the platforms it wants to pass on – let’s pass on something we can be proud of.
Our mission in Ubuntu is to give the world’s people a free platform they can trust. I suspect a lot of the Linux community is motivated by the same goal regardless of their distro. That also means finding ways to ensure that those trustworthy platforms can’t be compromised elsewhere. We can help vendors innovate AND ensure that users have a fighting chance of privacy and security in this brave new world. But we can’t do that if we cling to the tools of the past. Don’t cave in to expediency. Design a better future, it really can be much healthier than the present if we care and act accordingly.
This work has been a LOT of fun. It started when we were trying to find the zen of each edge of the screen, a long time back. We quickly figured out that the bottom edge is by far the most fun, by far the most accessible. You can always get to it easily, it feels great. I suspect that’s why Apple has used the bottom edge for their quick control access on IOS.
We started in the same place as Apple, thinking that the bottom edge was so nice we wanted it for ourselves, in the system. But as we discussed it, we started to think that the app developer was the one who deserved to do something really distinctive in their app with it instead. It’s always tempting to grab the tastiest bit for oneself, but the mark of civility is restraint in the use of power and this felt like an appropriate time to exercise that restraint.
Importantly you can use it equally well if we split the screen into left and right stages. That made it a really important edge for us because it meant it could be used equally well on the Ubuntu phone, with a single app visible on the screen, and on the Ubuntu tablet, where we have the side stage as a uniquely cool way to put phone apps on tablet screens alongside a bigger, tablet app.
The net result is that you, the developer, and you, the user, have complete creative freedom with that bottom edge. There are of course ways to judge how well you’ve exercised that freedom, and the design guidance tries to leave you all the freedom in the world while still providing a framework for evaluating how good the result will feel to your users. If you want, there are some archetypes and patterns to choose from, but what I’d really like to see is NEW patterns and archetypes coming from diverse designs in the app developer community.
Here’s the key thing – that bottom edge is the one thing you are guaranteed to want to do more innovatively on Ubuntu than on any other mobile platform. So if you are creating a portable app, targeting a few different environments, that’s the thing to take extra time over for your Ubuntu version. That’s the place to brainstorm, try out ideas on your friends, make a few mockups. It’s the place you really express the single most important aspects of your application, because it’s the fastest, grooviest gesture in the book, and it’s all yours on Ubuntu.
Mapping out the road to 13.04, there are a few items with high “tada!” value that would be great candidates for folk who want to work on something that will get attention when unveiled. While we won’t talk about them until we think they are ready to celebrate, we’re happy to engage with contributing community members that have established credibility (membership, or close to it) in Ubuntu, who want to be part of the action.
This would provide early community input and review, without spoiling the surprise when we think the piece is ready. It would allow community members to work on something that will be widely covered at release (at least, on OMG ;-))
The skunkworks approach has its detractors. We’ve tried it both ways, and in the end, figured out that critics will be critics whether you discuss an idea with them in advance or not. Working on something in a way that lets you refine it till it feels ready to go has advantages: you can take time to craft something, you can be judged when you’re ready, you get a lot more punch when you tell your story, and you get your name in lights (though not every headline is one you necessarily want ;)).
There’s also plenty going on that doesn’t warrant the magician’s reveal. But if you are game for a bit of the spotlight, bring some teflon and ping Michael Hall at mhall119 on Freenode.
Microsoft has built an impressive new entrant to the Infrastructure-as-a-Service market, and Ubuntu is there for customers who want to run workloads on Azure that are best suited to Linux. Windows Azure was built for the enterprise market, an audience which is increasingly comfortable with Ubuntu as a workhorse for scale-out workloads; in short, it’s a good fit for both of us, and it’s been interesting to do the work to bring Ubuntu to the platform.
Given that it’s normal for us to spin up 2,000-node Hadoop clusters with Juju, it will be very valuable to have a new enterprise-oriented cloud with which to evaluate performance, latency, reliability, scalability and many other key metrics for production deployment scenarios.
As IAAS grows in recognition as a standard part of the enterprise toolkit, it will be important to have a wide range of infrastructures that are addressable, with diverse strengths. In the case of Windows Azure, there is clearly a deep connection between Windows-based IT and the new IAAS. But I think Microsoft has set their sights on a bigger story, which is high-quality enterprise-oriented infrastructure that is generally useful. That’s why Ubuntu is important to them, and why it was worthwhile for us to work together despite our differences. Just as we need to ensure that customers can run Ubuntu and Windows together inside their data centre and on the LAN, we want to ensure that cloud workloads play nicely.
The team leading Azure has a sophisticated understanding of Ubuntu and Linux in general. They are taking a pragmatic approach that will raise eyebrows around the Redmond campus, but is exactly what customers want to see. We have taken a similar view. I know there will be members of the free software community that will leap at the chance to berate Microsoft for its very existence, but it’s not very Ubuntu to do so: let’s argue our perspective, work towards our goals, be open to those who are open to us, and build great stuff. There is nothing proprietary in Ubuntu-for-Azure, and no about-turn from us on long-held values. This is us making sure our audience, and especially the enterprise audience, can benefit from the work our community and Canonical do no matter where they want to do it.
Windows Azure IAAS is in beta. If you are using the cloud today, or interested in it, I highly recommend you try it out. There’s no better way to make yourself heard over there.
The new privacy features in Ubuntu 12.04 are a lovely example of collaboration and contribution. I’d like to thank Manish Sinha and Stefano Candori who contributed significantly to that effort and hadn’t received a shout-out despite being central to the success. The body of contributors to Ubuntu and Unity continues to grow, and I know the team finds it immensely rewarding to help folk land patches or changes that bring the experience closer to the designed goal. Manish, Stafano, thank you!
A remarkable thing happened this year: companies started adopting Ubuntu over RHEL for large-scale enterprise workloads, in droves:
The trend is even starker if you look at what we know of new-style services, like clouds and big data, but since most of that happens behind the firewall its all anecdata, while web services are a public affair.
The key driver of this has been that we added quality as a top-level goal across the teams that build Ubuntu – both Canonical’s and the community’s. We also have retained the focus on keeping the up-to-date tools available on Ubuntu for developers, and on delivering a great experience in the cloud, where computing is headed.
The headlines for Ubuntu have all been about the desktop and consumer-focused design efforts, with the introduction of Unity and the expansion of our goals to span the phone, the tablet, the TV as well as the PC. But underpinning those goals has been a raising of the quality game: OEMs and consumers demand a very high level of quality, and so we now have large-scale automated testing, improved upload processes, faster responses to issues that crop up inevitably during the development cycle, a broader base of users and contributors in the development release, and better engagements with the vendors who pre-install Ubuntu. So 12.04 LTS is a coming of age release for Ubuntu in the data centre as much as its the first LTS to sport the interface which was designed to span the full range of personal computing needs.
We’re also seeing the wider community respond to the goal of cadence. OpenStack’s Essex release is lined up to be a perfect fit for 12.04 LTS. That is not a coincidence, it’s a value to which both projects are committed. Upstream projects that care about their user’s and care about being adopted quickly, want an effective conduit of their goodness straight to users. By adopting the 6-month / 2-year cadence of step and LTS releases, and aligning those with Ubuntu’s release cycle, OpenStack ensures that a very large audience of system administrators, developers and enterprise decision makers can plan for their OpenStack deployment, and know they will have a robust and very widely deployed LTS platform together with a very widely supported release of OpenStack. Every dependency that Essex needs is exactly provided in 12.04 LTS, the way that all of the major public clouds based on OpenStack are using it. By adopting a common message on releases, we make both OpenStack and Ubuntu stronger, and do so in a way which is entirely transparent and accessible to other distributions.
Quality. Design. Cadence. You can count on them in Ubuntu, and OpenStack.
Our mission with Ubuntu is to deliver, in the cleanest, most economical and most reliable form, all the goodness that engineers love about free software to the widest possible audience (including engineers :)). We’ve known for a long time that free software is beautiful on the inside – efficient, accurate, flexible, modifiable. For the past three years, we’ve been leading the push to make free software beautiful on the outside too – easy to use, visually pleasing and exciting. That started with the Ubuntu Netbook Remix, and is coming to fruition in 12.04 LTS, now in beta.
For the first time with Ubuntu 12.04 LTS, real desktop user experience innovation is available on a full production-ready enterprise-certified free software platform, free of charge, well before it shows up in Windows or MacOS. It’s not ‘job done’ by any means, but it’s a milestone. Achieving that milestone has tested the courage and commitment of the Ubuntu community – we had to move from being followers and integrators, to being designers and shapers of the platform, together with upstreams who are excited to be part of that shift and passionate about bringing goodness to a wide audience. It’s right for us to design experiences and help upstreams get those experiences to be amazing, because we are closest to the user; we are the last mile, the last to touch the code, and the first to get the bug report or feedback from most users.
Thank you, to those who stood by Ubuntu, Canonical and me as we set out on this adventure. This was a big change, and in the face of change, many wilt, many panic, and some simply find that their interests lie elsewhere. That’s OK, but it brings home to me the wonderful fellowship that we have amongst those who share our values and interests – their affiliation, advocacy and support is based on something much deeper than a fad or an individualistic need, it’s based on a desire to see all of this intellectual wikipedia-for-code value unleashed to support humanity at large, from developers to data centre devops to web designers to golden-years-ganderers, serving equally the poorest and the bankers who refuse to serve them, because that’s what free software and open content and open access and level playing fields are all about.
To those of you who rolled up your sleeves and filed bugs and wrote the documentation and made the posters or the cupcakes, thank you.
I’m very serious about loving the recent changes. I think I’m a fair representative of the elderly community ………. someone who doesn’t particularly care to learn new things, but just wants things to make sense. I think we’re there! Lance
You’ll be as delighted with the coverage of Ubuntu for Android at MWC in Barcelona last week:
“one of the more eye-catching concepts being showcased” – v3 “sleeker, faster, potentially more disruptive” - IT Pro Portal “you can also use all the features of Android” - The Inquirer “I can easily see the time when I will be carrying only my smartphone” - UnwiredView “everything it’s been claimed to be” - Engadget “Efficiency, for the win!” - TechCrunch “phones that become traditional desktops have the potential to benefit from the extra processing power” - GigaOM “This, ladies and gentlemen, is the future of computing” - IntoMobile
Free software distils the smarts of those of us who care about computing, much like Wikipedia does. Today’s free software draws on the knowledge and expertise of hundreds of thousands of individuals, all over the world, all of whom helped to make this possible, just like Wikipedia. It’s only right that the benefits of that shared wisdom should accrue to everyone without charge, which is why contributing to Ubuntu is the best way to add leverage to the contributions made everywhere else, to ensure they have the biggest possible impact. It wouldn’t be right to have to pay to have a copy of Wikipedia on your desk at the office, and the same is true of the free software platform. The bits should be free, and the excellent commercial services optional. That’s what we do at Canonical and in the Ubuntu community, and that’s why we do it.
Engineers are human beings too!
We set out to refine the experience for people who use the desktop professionally, and at the same time, make it easier for the first-time user. That’s a very hard challenge. We’re not making Bob, we’re making a beautiful, easy to use LCARS ;-). We measured the state of the art in 2008 and it stank on both fronts. When we measure Ubuntu today, based on how long it takes heavy users to do things, and a first-timer to get (a different set of) things done, 12.04 LTS blows 10.04 LTS right out of the water and compares favourably with both MacOS and Windows 7. Unity today is better for both hard-core developers and first-time users than 10.04 LTS was. Hugely better.
For software developers:
A richer set of keyboard bindings for rapid launching, switching and window management
Pervasive search results in faster launching for occasional apps
Far less chrome in the shell than any other desktop; it gets out of your way
Much more subtle heuristics to tell whether you want the launcher to reveal, and to hint it’s about to
Integrated search presents a faster path to find any given piece of content
Magic window borders and the resizing scrollbar make for easier window sizing despite razor-thin visual border
Full screen apps can include just the window title and indicators – full screen terminal with all the shell benefits
… and many more. In 12.04 LTS, multi-monitor use cases got a first round of treatment, we will continue to refine and improve that every six months now that the core is stable and effective. But the general commentary from professionals, and software developers in particular, is “wow”. In this last round we have focused testing on more advanced users and use cases, with user journeys that include many terminal windows, and there is a measurable step up in the effectiveness of Unity in those cases. Still rough edges to be sure, even in this 12.04 release (we are not going to be able to land locally-integrated menus in time, given the freeze dates and need for focus on bug fixes) but we will SRU key items and of course continue to polish it in 12.10 onwards. We are all developers, and we all use it all the time, so this is in our interests too.
We care about efficiency, performance, quality, reliability. So do developers and engineers. We care about beauty and ease of use – turns out most engineers and developers care about that too. I’ve had lots of hard-core engineers tell me that they “love the challenges the design team sets”, because it’s hard to make easy software, and harder to make it pixel-perfect. And lots that have switched back to Ubuntu from the MacOS because devops on Ubuntu… rock.
The hard core Linux engineers can use… anything, really. Linus is probably equally comfortable with Linux-from-scratch as with Ubuntu. But his daughter Daniela needs something that works for human beings of all shapes, sizes, colours and interests. She’s in our audience. I hope she’d love Ubuntu if she tries it. She could certainly install it for herself while Dad isn’t watching Linus and other kernel hackers are our audience too, of course, but they can help himself if things get stuck. We have to shoulder the responsibility for the other 99%. That’s a really, really hard challenge – for engineers and artists alike. But we’ve made huge progress. And doing so brings much deeper meaning to the contributions of all the brilliant people that make free software, everywhere.
Again, thanks to the Ubuntu community, 500 amazing people at Canonical, the contributors to all of the free software that makes it possible, and our users.
The desktop remains central to our everyday work and play, despite all the excitement around tablets, TV’s and phones. So it’s exciting for us to innovate in the desktop too, especially when we find ways to enhance the experience of both heavy “power” users and casual users at the same time. The desktop will be with us for a long time, and for those of us who spend hours every day using a wide diversity of applications, here is some very good news: 12.04 LTS will include the first step in a major new approach to application interfaces.
This work grows out of observations of new and established / sophisticated users making extensive use of the broader set of capabilities in their applications. We noticed that both groups of users spent a lot of time, relatively speaking, navigating the menus of their applications, either to learn about the capabilities of the app, or to take a specific action. We were also conscious of the broader theme in Unity design of leading from user intent. And that set us on a course which led to today’s first public milestone on what we expect will be a long, fruitful and exciting journey.
The menu has been a central part of the GUI since Xerox PARC invented ‘em in the 70′s. It’s the M in WIMP and has been there, essentially unchanged, for 30 years.
The original Macintosh desktop, circa 1984, courtesy of Wikipedia
We can do much better!
Say hello to the Head-Up Display, or HUD, which will ultimately replace menus in Unity applications. Here’s what we hope you’ll see in 12.04 when you invoke the HUD from any standard Ubuntu app that supports the global menu:
Snapshot of the HUD in Ubuntu 12.04
The intenterface – it maps your intent to the interface
This is the HUD. It’s a way for you to express your intent and have the application respond appropriately. We think of it as “beyond interface”, it’s the “intenterface”. This concept of “intent-driven interface” has been a primary theme of our work in the Unity shell, with dash search as a first class experience pioneered in Unity. Now we are bringing the same vision to the application, in a way which is completely compatible with existing applications and menus.
The HUD concept has been the driver for all the work we’ve done in unifying menu systems across Gtk, Qt and other toolkit apps in the past two years. So far, that’s shown up as the global menu. In 12.04, it also gives us the first cut of the HUD.
Menus serve two purposes. They act as a standard way to invoke commands which are too infrequently used to warrant a dedicated piece of UI real-estate, like a toolbar button, and they serve as a map of the app’s functionality, almost like a table of contents that one can scan to get a feel for ‘what the app does’. It’s command invocation that we think can be improved upon, and that’s where we are focusing our design exploration.
As a means of invoking commands, menus have some advantages. They are always in the same place (top of the window or screen). They are organised in a way that’s quite easy to describe over the phone, or in a text book (“click the Edit->Preferences menu”), they are pretty fast to read since they are generally arranged in tight vertical columns. They also have some disadvantages: when they get nested, navigating the tree can become fragile. They require you to read a lot when you probably already know what you want. They are more difficult to use from the keyboard than they should be, since they generally require you to remember something special (hotkeys) or use a very limited subset of the keyboard (arrow navigation). They force developers to make often arbitrary choices about the menu tree (“should Preferences be in Edit or in Tools or in Options?”), and then they force users to make equally arbitrary effort to memorise and navigate that tree.
The HUD solves many of these issues, by connecting users directly to what they want. Check out the video, based on a current prototype. It’s a “vocabulary UI”, or VUI, and closer to the way users think. “I told the application to…” is common user paraphrasing for “I clicked the menu to…”. The tree is no longer important, what’s important is the efficiency of the match between what the user says, and the commands we offer up for invocation.
In 12.04 LTS, the HUD is a smart look-ahead search through the app and system (indicator) menus. The image is showing Inkscape, but of course it works everywhere the global menu works. No app modifications are needed to get this level of experience. And you don’t have to adopt the HUD immediately, it’s there if you want it, supplementing the existing menu mechanism.
It’s smart, because it can do things like fuzzy matching, and it can learn what you usually do so it can prioritise the things you use often. It covers the focused app (because that’s where you probably want to act) as well as system functionality; you can change IM state, or go offline in Skype, all through the HUD, without changing focus, because those apps all talk to the indicator system. When you’ve been using it for a little while it seems like it’s reading your mind, in a good way.
We’ll resurrect the (boring) old ways of displaying the menu in 12.04, in the app and in the panel. In the past few releases of Ubuntu, we’ve actively diminished the visual presence of menus in anticipation of this landing. That proved controversial. In our defence, in user testing, every user finds the menu in the panel, every time, and it’s obviously a cleaner presentation of the interface. But hiding the menu before we had the replacement was overly aggressive. If the HUD lands in 12.04 LTS, we hope you’ll find yourself using the menu less and less, and be glad to have it hidden when you are not using it. You’ll definitely have that option, alongside more traditional menu styles.
Voice is the natural next step
Searching is fast and familiar, especially once we integrate voice recognition, gesture and touch. We want to make it easy to talk to any application, and for any application to respond to your voice. The full integration of voice into applications will take some time. We can start by mapping voice onto the existing menu structures of your apps. And it will only get better from there.
But even without voice input, the HUD is faster than mousing through a menu, and easier to use than hotkeys since you just have to know what you want, not remember a specific key combination. We can search through everything we know about the menu, including descriptive help text, so pretty soon you will be able to find a menu entry using only vaguely related text (imagine finding an entry called Preferences when you search for “settings”).
There is lots to discover, refine and implement. I have a feeling this will be a lot of fun in the next two years
Even better for the power user
The results so far are rather interesting: power users say things like “every GUI app now feels as powerful as VIM”. EMACS users just grunt and… nevermind ;-). Another comment was “it works so well that the rare occasions when it can’t read my mind are annoying!”. We’re doing a lot of user testing on heavy multitaskers, developers and all-day-at-the-workstation personas for Unity in 12.04, polishing off loose ends in the experience that frustrated some in this audience in 11.04-10. If that describes you, the results should be delightful. And the HUD should be particularly empowering.
Even casual users find typing faster than mousing. So while there are modes of interaction where it’s nice to sit back and drive around with the mouse, we observe people staying more engaged and more focused on their task when they can keep their hands on the keyboard all the time. Hotkeys are a sort of mental gymnastics, the HUD is a continuation of mental flow.
Ahead of the competition
There are other teams interested in a similar problem space. Perhaps the best-known new alternative to the traditional menu is Microsoft’s Ribbon. Introduced first as part of a series of changes called Fluent UX in Office, the ribbon is now making its way to a wider set of Windows components and applications. It looks like this:
You can read about the ribbon from a supporter (like any UX change, it has its supporters and detractors ;-)) and if you’ve used it yourself, you will have your own opinion about it. The ribbon is highly visual, making options and commands very visible. It is however also a hog of space (I’m told it can be minimised). Our goal in much of the Unity design has been to return screen real estate to the content with which the user is working; the HUD meets that goal by appearing only when invoked.
Instead of cluttering up the interface ALL the time, let’s clear out the chrome, and show users just what they want, when they want it.
Time will tell whether users prefer the ribbon, or the HUD, but we think it’s exciting enough to pursue and invest in, both in R&D and in supporting developers who want to take advantage of it.
Other relevant efforts include Enso and Ubiquity from the original Humanized team (hi Aza &co), then at Mozilla.
Our thinking is inspired by many works of science, art and entertainment; from Minority Report to Modern Warfare and Jef Raskin’s Humane Interface. We hope others will join us and accelerate the shift from pointy-clicky interfaces to natural and efficient ones.
Roadmap for the HUD
There’s still a lot of design and code still to do. For a start, we haven’t addressed the secondary aspect of the menu, as a visible map of the functionality in an app. That discoverability is of course entirely absent from the HUD; the old menu is still there for now, but we’d like to replace it altogether not just supplement it. And all the other patterns of interaction we expect in the HUD remain to be explored. Regardless, there is a great team working on this, including folk who understand Gtk and Qt such as Ted Gould, Ryan Lortie, Gord Allott and Aurelien Gateau, as well as designers Xi Zhu, Otto Greenslade, Oren Horev and John Lea. Thanks to all of them for getting this initial work to the point where we are confident it’s worthwhile for others to invest time in.
We’ll make sure it’s easy for developers working in any toolkit to take advantage of this and give their users a better experience. And we’ll promote the apps which do it best – it makes apps easier to use, it saves time and screen real-estate for users, and it creates a better impression of the free software platform when it’s done well.
From a code quality and testing perspective, even though we consider this first cut a prototype-grown-up, folk will be glad to see this:
Overall coverage rate:
lines......: 87.1% (948 of 1089 lines)
functions..: 97.7% (84 of 86 functions)
branches...: 63.0% (407 of 646 branches)
Landing in 12.04 LTS is gated on more widespread testing. You can of course try this out from a PPA or branch the code in Launchpad (you will need thesetwo branches). Or dig deeper with blogs on the topic from Ted Gould, Olli Ries and Gord Allott. Welcome to 2012 everybody!