Mark Shuttleworth | here be dragons

The desktop is the killer app for quad-core smartphones in 2012.

We’ll show Ubuntu neatly integrated into Android at Mobile World Congress next week. Carry just the phone, and connect it to any monitor to get a full Ubuntu desktop with all the native apps you want, running on the same device at the same time as Android. Magic. Everything important is shared across the desktop and the phone in real time.

It’s a lightweight way to be – everything seamlessly available with the right interface for the right form factor, with no hassles syncing. It just works, the way Ubuntu should. Lots of work behind the scenes to make both systems share what they need to share, but the desktop is a no-compromise desktop.

This isn’t the “Ubuntu Phone”. The phone experience here is pure Android. This announcement is playing to a different story, which is the convergence of multiple different form factors into one most-personal device. Naturally, the most personal device is the phone, so we want to get all of these different personalities – phone, tablet and desktop – into the phone. When you need a desktop, you connect up to a screen and a keyboard. When you need a tablet, you dock to some very elegant glass.

Just for fun, we’ve integrated the Ubuntu TV experience too – so this isn’t just a desktop in your pocket, it’s a media centre too.

Come and say hello in Barcelona next week, and I’ll be glad to hear what you think of it in person. Everyone we’ve shown it to has had a “wow!” moment. For network operators who have long believed that the phone was the PC of the future for the next billion connected consumers, and for handset manufacturers who want to offer companies a single device for corporate computing, this is a delicious prospect. For those of us who love our desktops free, focused and mobile, it’s nirvana.

Good news for people with skills deploying and managing Ubuntu: the corporate desktop is being reinvented, and Ubuntu is a popular option for those leading the change.

In the past year there’s been a notable shift in the way IT shops think about their corporate desktops. Suddenly, Windows is optional, or at least it can be managed and delivered as a service to any other platform, so it no longer has to BE the platform on the client. In part, that’s because so much has moved to the web, and in part it’s because virtualisation has become so good at letting people deliver desktop apps (and whole desktops) over the network. It’s also a function of the success of other non-Windows platforms, like iOS, which make IT think in terms of standards for interoperability rather than standard applications.

All of this is drumming up interest in alternative ways to design large scale desktop infrastructure, from Linux-based thin clients (Ubuntu is at the heart of some recent products from Wyse) on alternative architectures like ARM to straightforward Ubuntu desktops with thin client software giving access to legacy Windows applications. In all these cases, Windows and proprietary software continue to play an important role, but the stranglehold of Windows on the platform itself seems to be coming unstuck. That makes for a much enhanced competitive landscape.

A migration from Windows to Ubuntu is still a project that requires a lot of planning, analysis and hard work. But for most institutions, it’s realistic to be confident that 10-25% of the desktops can migrate smoothly if a professional team has that as their mission over a year or two. For large organisations, that might be 5,000-50,000 seats, and the resulting savings are tremendous given the increase in Windows licensing costs driven by Win 7.

I joined a call recently with the team at Canonical that works with customers to plan and deliver desktop migrations to Ubuntu. They have a standard engagement process that charts a course for the organisation and maps out typical risks and low-hanging fruit. They were talking to a bank, traditionally a very conservative audience, about the stages and milestones in a typical migration of 20,000 seats to Ubuntu. I was struck by the tone of the conversation on both sides – it wasn’t a question of whether to do it, it was a question of how to do so most efficiently. And that’s a huge leap forward from the days when we used to speculate if it was sane to even think about Linux on the desktop for anybody other than a developer.

It’s clear that Windows is no longer the target – personal computing and productivity computing are in the process of being reinvented, and being an effective replacement for Windows is no guarantee of relevance in the future. But for many IT departments, the desktop represents an enormous cost base which will not disappear overnight, and Ubuntu is creating options for them to control that cost.

We often celebrate the way free software transforms the lives of those most in need, but it’s equally energising to see it making a difference to IT teams that in turn help inject resources into the acceleration of the free software platform. Winning 20,000 desktops to Ubuntu helps improve the platform for every school or university deployment, just as much as it helps improve the platform for developers and home users too.

The Ayatana Indicators work has given us a crisp, clean basis for indicators in the panel. We’ve said they will all look a particular way, and behave a particular way. And we’ve said they will be placed on the right of the panel.

But why limit indicators to the panel? Let’s make it possible for applications to use indicators themselves, for all the things that indicators are good at:

• Conveying a particular state, such as whether or not the application is connected,
• Providing a handle for the indicator menu, to modify that state

We’ll start with “window indicators”, or “windicators” for fun. Windicators are indicators displayed in the window title bar that behave just like the indicators in the panel: they have an icon which shows state, and clicking on the icon brings up a menu. Applications can create, update and remove window indicators using an API more or less like the AppIndicator framework first put to use in 10.04 LTS.

Window indicators, or "windicators", shown in a sample application window.

We’ve carefully placed all the panel indicators on the right, and we’ve carefully put the window controls and window title on the left. So now we have all this space on the right. As a pattern, it would fit to put the window indicators there.

Cody Russell is leading some work in Canonical around the technology which actually draws the window title bar and borders. It’s called “client side window decorations”. We are moving the rendering of the window decorations into the app itself, so that you don’t have the window manager and application drawing those pieces separately. That simplifies certain things (of course it also makes some things harder).

One of the most interesting consequences of the client-side decorations work is that it means that the application could more easily draw into the titlebar (because the application is drawing the title bar). And that makes it even more natural for the application to control the right side of the window title bar as well.

Update: Several commenters correctly pointed out that window indicators could just as easily be rendered by window managers in cases where the theme is not CSD-based. CSD provided the inspiration for giving that space to the application, it’s not essential to the implementation. It would be fantastic for window indicators to be available on 😉

Less chrome, more content: banish the status bar

I’m on a “less is more” kick with our design efforts, and one of the things I want to banish is wasted vertical space. For netbooks, that’s particularly important. And a lot of applications have status bars at the bottom, for no good reason other than it was that way in Windows 3.1.

Typically the application status bar has:

• Some status icons (“online”)
• Some tools (“Yslow”)
• A transient status message (“Saving draft…”)

We can replace these with a combination of windicators and temporary, overlay status bars. I really liked the Chrome browser’s use of overlay status messages, so kudos and thanks to them for the inspiration. The net result of those two steps, in apps where we can, is to save about 5% of the vertical space for your stuff – real content.

Prioritising examples for implementation

If you’re interested in this idea, please join the Ayatana mailing list and participate in the design discussions there. We’d like to develop some patterns that are generic, so that we can use a common icon and possibly also common indicator menu entries for addressing the same issue in diverse applications. Of course, applications will be free to use the mechanism for things that are unique to them.

Candidates for 10.10

It would be fantastic to implement a few of these window indicators for 10.10. Please help us choose the most useful cases! Currently on the list are:

• Online / offline status indicator and toggle options for the mail client, chat program or Gwibber, the broadcast messages application.
• An “unsaved” indicator, that tells people that the contents of the file they are working on have changed and potentially lets them save it or set autosave properties.
• Progress indicators, which show that an action is in progress, and possibly also indicate the extent of the progress. The associated menu would enable one to pause or cancel the operation, and perhaps define the behaviour on completion of the action.
• A “basket” indicator, which shows if any items have been selected for purchase,
• Sharing indicators, which would show if a document is shared with multiple people, and enable one to setup such a share.
• Volume indicators, which would show the loudness of application audio streams, and enable one to set the volume for that specific application.

The key thing is that these indicators are entirely application-specific, and ideally only relevant to the window that you are actually looking at.

Just like Panel Indicators…

From a visual design point of view, again the goal would be to ensure that indicators are symbolic. They would follow the same styling as Ayatana indicators:

• Monochrome by default, with shape indicating the function of the indicator
• Semantically colored: with red for critical problems, orange for alerts, green for positive status changes and blue for informative states that are not the default or usual state.

Integrated with the Netbook Edition Smart Panel

Last week I blogged about our decision to adopt a single, global menu for all applications, in the panel. And I also said we would explore putting the window title *and* menu into the panel, when the window is maximised. Of course, that means that we need to accommodate the window indicators in the panel as well.

So: when the window is maximised, and we are using a smart which can include both indicators and window titles, the window indicators will be inserted into the panel as well. They will appear on the right of the panel, and be the leftmost indicators. For example, here is the application, maximised (note the dodgy Ubuntu logo in the top left – that’s the panel, not the window title bar you’re looking at):

In this configuration, the system achieves “singular purpose”: the entire screen is devoted to a single application, yet the Ayatana elements continue to serve their purpose, either systemic (the battery indicator) or application specific.

When we set up Project Ayatana to improve the usability of the whole desktop, we called it Ayatana because we were focused on the “sphere of consciousness”, one’s awareness of what’s going on outside of the current application. There are two key aspects to the work:

1. Notifications are “awareness distilled” in the sense that you cannot interact with them at all.  We designed them as ephemeral “click-transparent” messages, implemented in Notify-OSD. Their sole purpose is to notify you of transient events.
2. Indicator Menus combine persistent awareness of a state with a set of options for modifying that state.

In this blog I’ll outline the arc of our work on indicator menus to date, and the trajectory we expect it to follow. We’re about a year into the effort, all told, and I think it will take another 18 months before we can consider it baked. It should be done by 12.04 LTS. This is an iterative process, and things are in flux right now. I hope, when we are happy that we can commit to ABI stability, that Gnome and KDE will adopt the work too. For the moment, the rapid pace of evolution has meant that we’re depending on fantastic upstreams to keep up with us as things move.

Goals of the Ayatana Indicators

The indicators are designed to create a persistent awareness of state, or an awareness of a persistent state. They complement notifications: they are persistent, when notifications are ephemeral. You might miss a notification, but you should always be able to check your indicators. You can interact with indicators, using their menus, in contrast with the un-clickable notifications.

We value:

• Support for both GNOME and KDE. Both desktop environments are important in Ubuntu. We encourage the teams to reflect a pure vision of each, but it’s also the case that users will want to run a GNOME application on Kubuntu occasionally, or vice versa. So we have to make sure the work is considered from the perspectives of developers on either side, and we have to provide APIs and libraries that work in both environments.
• Accessibility. Indicators are critical elements of awareness. Whether you are connected, what the time is, whether you are online, whether your battery will last long enough for you to finish your work, whether you have messages… these are all vital to a complete computing experience. We have to make sure that visual and other disabilities can be addressed.
• Familiarity and Innovation. As always, these are in tension with one another. Innovation helps us put free software at the front of the curve, but it creates the risk of breaking people’s habits and expectations.
• Consistency and Usability. We want the end result to be more usable in the whole, and we are willing to lose individual nuggets if that helps make the whole more valuable.
• Streamlining. There are too many indicators, that aren’t clear enough about their intent. There are also many indicators from different applications which do roughly the same thing, but in slightly different ways. The value of all the indicators is enhanced if there are fewer of them, and they are more obvious to discover and use.

Some firm decisions

Those values lead us to some anchor decisions:

1. D-Bus for communications. A messaging approach makes it straightforward to adopt consistent patterns across different desktop environments. We will provide wrapper libraries for both Gtk and Qt applications to access the indicator capabilities. A Qt application running on Ubuntu should “feel native” when it’s using indicators correctly. And vice-versa. The messaging approach also lets us handle accessibility in a better way: we don’t have to accommodate every possible disability visually, because we can have agents that interpret the indicator messages and handle it in ways that are appropriate for a particular disability.
2. Opinionated placement. We will place all indicators at the top right of the screen on GNOME. We’ll place them in a particular order, too, with the “most fundamental” indicator, which controls the overall session, in the top right. The order will not be random, but predictable between sessions and screen sizes. There will be no GUI support for users to reorder the indicators.
3. Constrained behaviour. All the indicators will take the form of an indicator (icon or text), and a menu. Clicking on an indicator will open its menu. Keyboard navigation will always work, and left and right arrows will translate either into submenu navigation or flipping from indicator to indicator. The whole set of indicators on the panel will be navigable as a single menu, in essence. We won’t support “right click” on indicators differently from “left click”, and there’ll be no ability for arbitrary applications to define arbitrary behaviours to arbitrary events on indicators.
4. Symbolic visuals. We want to pare back the visual representation of status presented by the icons. We don’t believe that visual accessibility for the disabled need drive the design of the standard icon set, as there will be both alternative icons, renderings, and entirely different options such as speech or custom devices to handle those. Colors on the indicators should have semantic purpose and be used mainly for alerts and awareness, while the shape of the icon should define its purpose.

The first part of our work was pure housekeeping. The panel in Ubuntu is very generic, it lets you put all sorts of different gadgets in all sorts of different places, and those gadgets can behave in all sorts of different ways. The result has been to stimulate innovation, but it has also made the panel very inconsistent and ultimately less useful.

We reviewed the way Ubuntu-specific applications were using the panel, and set out to clean them up. Update-manager lost its persistent notification in favour of the more direct popup window. Others will follow.

We decided to introduce a new gadget on the panel which would be a container for all the indicators which follow our new Ubuntu Ayatana pattern. And we started work on a set of indicators that would fit inside that container. Thus far, we’ve done the session, “me”, and sound indicators.

We also created a framework for applications which want to display their own indicator. That’s the AppIndicators work, which has been fantastically lead in 10.04 LTS by Jorge Castro, coordinating with many upstreams to ensure that their applications feel tightly integrated into the panel.

The icon visual design turned into a conversation about “-symbolic” icons at UDS in Dallas, and is now being realised in the ubuntu-mono icon theme in 10.04 LTS. There is work under way to make symbolic icons a more formal and rigorous construct that can be themed, and we’ll participate in that effort or offer an alternative implementation.

9 parts perspiration, 1 part innovation

The detailed design of a large set of systemic indicators, together with the work to make them all look, feel and behave in a consistent fashion, has been substantial effort involving MPT, Ted Gould, Cody Russell and many others. There’s still a lot of work to do. Conor Curran and Kalle Valo joined the team in this latest cycle. There is a great deal that remains to be done.

We also aspire to introduce some new and innovative concepts.

Category Indicators

In order to reduce the number of indicators and improve the persistence and usefulness of the indicators that remain, we’ve introduced the idea of “category indicators”. These are indicators into which multiple, similar applications can embed themselves. Instead of having a different indicator each application, we have one indicator for the whole category.

The messaging indicator, which aggregates awareness about many different types of messages from real people, is an example. Instead of having three different icons for email, IM and Identi.ca or Twitter, Ubuntu has just one messaging indicator, which can make you aware of important messages in any of those applications.

The three default applications for those lines of communication all share the same indicator. They are part of the same category. There are custom API’s for messaging applications which let them:

1. Insert entries in the messaging menu which are displayed even when the application is not running. Useful for helping people go straight to the activity. Instead of having to check if the email client is running, then switching to it or launching it, then going to the message composition window, I should *always* be able to compose a new message with just two clicks, regardless of whether or not the mail client is running initially.
2. Add custom menu entries to the messaging menu that are relevant to them. Each applications gets a “section” in the category indicator menu, and they can add custom menu entries to their section.
3. Register themselves as applications that should be shown in the messaging menu, or remove themselves from that menu. The default applications will show up there unless they are uninstalled or expressly configured not to use the messaging menu. Other applications will put themselves there by default when they are run by that user, who can also configure them not to display there.
4. Show whether they are running, a state which is indicated with a small “play” style triangle next to the application icon in the menu.

There are also some behaviours which are collective across all the applications in the category. For example, any of the applications can set the messaging indicator to an alert state, signalling that it’s worth clicking on.

Each category indicator supports a unique API that’s relevant for that category. There are some common features, for example the ability of applications to register and de-register for the indicators and the ability to add menu entries, but the details might vary substantially from one category to another.

The underlying goal is to make it clearer to users “what all of those icons are about”. There are fewer of them, and the ones that are there are more persistent – they are always there, and they always do the same sort of thing. “You’ve got a message” is useful no matter which channel the message came through. The net result is that the whole set of indicators feels tighter and better defined.

The session indicator, which displays the shutdown / restart menu, has a similar capability that replaced the “restart required” panel icon in 10.04 LTS. Since the session menu already contains the “restart” menu option, the session menu will now be set into an alert state when you need to restart. The “Restart…” menu option is changed to “Restart Required…” (though I would now prefer something like “Restart, completing updates…”).

The battery indicator shows the status of all of your batteries, from laptop to UPS to mouse and wireless keyboard. Other applications and devices which have battery information should be able to insert themselves there appropriately.

Similarly, all the calendar and alarm applications might fit into the Clock Indicator. And perhaps all the applications which have downloads might use a single category for that – there’s some discussion along those lines on the Ayatana list at the moment.

Timelines and iterations

The basic “add an indicator with a menu” capability is there now, and was used for Application Indicators in 10.04 LTS.

What complicates the picture from a delivery perspective is our evolving understanding of how best to organise the category indicators. For example, at the moment we are aggregating received messages in the messaging indicator, but the send or broadcast elements of those same communications channels are accessed through the Me menu, where we track presence. That has been controversial – sensible folks think we should perhaps restructure that to bring the elements together.

Each arrangement of category indicators involves shaping the API’s in new ways, because the categories are fundamentally different from one another, and we want to design custom indicators for each category. Not only are the individual category indicator designs changing, but the arrangement of categories themselves is subject to active debate and experimentation, which is important to getting a crisp final result.

We can’t be certain that the current configuration is the best one, and want the flexibility to continue to evolve and reshape the APIs accordingly. We expect it will take at least three iterations of Ubuntu to be certain, and that we can commit to ABI stability for 12.04 LTS onwards.