Mark Shuttleworth | here be dragons

A big thank-you to everyone who came along, or participated virtually. And to Benjamin, for the nicely packaged memories 🙂

A few months ago we took on the challenge of building a version of Ubuntu for the dual-boot, instant-on market. We wanted to be surfing the web in under 10 seconds, and give people a fantastic web experience. We also wanted it to be possible to upgrade from that limited usage model to a full desktop.

The fruit of that R&D is both a new desktop experience codebase, called Unity, and a range of Light versions of Ubuntu, both netbook and desktop, that are optimised for dual-boot scenarios.

The dual-boot, web-focused use case is sufficiently different from general-purpose desktop usage to warrant a fresh look at the way the desktop is configured. We spent quite a bit of time analyzing screenshots of a couple of hundred different desktop configurations from the current Ubuntu and Kubuntu user base, to see what people used most. We also identified the things that are NOT needed in lightweight dual-boot instant-on offerings. That provided us both with a list of things to focus on and make rich, and a list of things we could leave out.

Instant-on products are generally used in a stateless fashion. These are “get me to the web asap” environments, with no need of heavy local file management. If there is content there, it would be best to think of it as “cloud like” and synchronize it with the local Windows environment, with cloud services and other devices. They are also not environments where people would naturally expect to use a wide range of applications: the web is the key, and there may be a few complementary capabilities like media playback, messaging, games, and the ability to connect to local devices like printers and cameras and pluggable media.

We also learned something interesting from users. It’s not about how fast you appear to boot. It’s about how fast you actually deliver a working web browser and Internet connection. It’s about how fast you have a running system that is responsive to the needs of the user.

Unity: a lightweight netbook interface

There are several driving forces behind the result.

The desktop screenshots we studied showed that people typically have between 3 and 10 launchers on their panels, for rapid access to key applications. We want to preserve that sense of having a few favorite applications that are instantly accessible. Rather than making it equally easy to access any installed application, we assume that almost everybody will run one of a few apps, and they need to switch between those apps and any others which might be running, very easily.

We focused on maximising screen real estate for content. In particular, we focused on maximising the available vertical pixels for web browsing. Netbooks have screens which are wide, but shallow. Notebooks in general are moving to wide screen formats. So vertical space is more precious than horizontal space.

We also want to embrace touch as a first class input. We want people to be able to launch and switch between applications using touch, so the launcher must be finger friendly.

Those constraints and values lead us to a new shape for the desktop, which we will adopt in Ubuntu’s Netbook Edition for 10.10 and beyond.

First, we want to move the bottom panel to the left of the screen, and devote that to launching and switching between applications. That frees up vertical space for web content, at the cost of horizontal space, which is cheaper in a widescreen world. In Ubuntu today the bottom panel also presents the Trash and Show Desktop options, neither of which is relevant in a stateless instant-on environment.

Second, we’ll expand that left-hand launcher panel so that it is touch-friendly. With relatively few applications required for instant-on environments, we can afford to be more generous with the icon size there. The Unity launcher will show what’s running, and support fast switching and drag-and-drop between applications.

Third, we will make the top panel smarter. We’ve already talked about adopting a single global menu, which would be rendered by the panel in this case. If we can also manage to fit the window title and controls into that panel, we will have achieved very significant space saving for the case where someone is focused on a single application at a time, and especially for a web browser.

We end up with a configuration like this:

Mockup of Unity Launcher and Panel with maximised application

The launcher and panel that we developed in response to this challenge are components of Unity. They are now in a state where they can be tested widely, and where we can use that testing to shape their evolution going forward. A development milestone of Unity is available today in a PPA, with development branches on Launchpad, and I’d very much like to get feedback from people trying it out on a netbook, or even a laptop with a wide screen. Unity is aimed at full screen applications and, as I described above, doesn’t really support traditional file management. But it’s worth a spin, and it’s very easy to try out if you have Ubuntu 10.04 LTS installed already.

Ubuntu Light

Instant-on, dual boot installations are a new frontier for us. Over the past two years we have made great leaps forward as a first class option for PC OEM’s, who today ship millions of PC’s around the world with Ubuntu pre-installed. But traditionally, it’s been an “either/or” proposition – either Windows in markets that prefer it, or Ubuntu in markets that don’t. The dual-boot opportunity gives us the chance to put a free software foot forward even in markets where people use Windows as a matter of course.

And it looks beautiful:

Ubuntu Light, showing the Unity launcher and panel

In those cases, Ubuntu Netbook Light, or Ubuntu Desktop Light, will give OEM’s the ability to differentiate themselves with fast-booting Linux offerings that are familiar to Ubuntu users and easy to use for new users, safe for web browsing in unprotected environments like airports and hotels, focused on doing that job very well, but upgradeable with a huge list of applications, on demand. The Light versions will also benefit from the huge amount of work done on every Ubuntu release to keep it maintained – instant-on environments need just as much protection as everyday desktops, and Ubuntu has a deep commitment to getting that right.

The Ubuntu Light range is available to OEM’s today. Each image will be hand-crafted to boot fastest on that specific hardware, the application load reduced to the minimum, and it comes with tools for Windows which assist in the management of the dual-boot experience. Initially, the focus is on the Netbook Light version based on Unity, but in future we expect to do a Light version of the desktop, too.

Given the requirement to customise the Light versions for specific hardware, there won’t be a general-purpose downloadable image of Ubuntu Light on ubuntu.com.

Evolving Unity for Ubuntu Netbook Edition 10.10

Unity exists today, and is great for the minimalist, stateless configurations that suit a dual-boot environment. But in order embrace it for our Netbook UI, we’ll need to design some new capabilities, and implement them during this cycle.

Those design conversations are taking place this week at UDS, just outside Brussels in Belgium. If you can’t be there in person, and are interested in the design challenges Unity presents for the netbook form factor, check out the conference schedule and participate in the discussion virtually.

The two primary pieces we need to put in place are:

• Support for many more applications, and adding / removing applications. Instant-on environments are locked down, while netbook environments should support anybody’s applications, not just those favored in the Launcher.
• Support for file management, necessary for an environment that will be the primary working space for the user rather than an occasional web-focused stopover.

We have an initial starting point for the design, called the Dash, which presents files and applications as an overlay. The inspiration for the Dash comes from consoles and devices, which use full-screen, media-rich presentation. We want the Dash to feel device-like, and use the capabilities of modern hardware.

The Unity Dash, showing the Applications Place

The instant-on requirements and constraints proved very useful in shaping our thinking, but the canvas is still blank for the more general, netbook use case. Unity gives us the chance to do something profoundly new and more useful, taking advantage of ideas that have emerged in computing from the console to the handheld.

Relationship to Gnome Shell

Unity and Gnome Shell are complementary for the Gnome Project. While Gnome Shell presents an expansive view of how people work in complex environments with multiple simultaneous activities, Unity is designed to address the other end of the spectrum, where people are focused on doing one thing at any given time.

Unity does embrace the key technologies of Gnome 3: Mutter, for window management, and Zeitgeist will be an anchor component of our file management approach. The interface itself is built in Clutter.

The design seed of Unity was in place before Gnome Shell, and we decided to build on that for the instant-on work rather than adopt Gnome Shell because most of the devices we expect to ship Ubuntu Light on are netbooks. In any event, Unity represents the next step for the Ubuntu Netbook UI, optimised for small screens.

The Ubuntu Netbook interface is popular with Gnome users and we’re fortunate to be working inside an open ecosystem that encourages that level of diversity. As a result, Gnome has offerings for mobile, netbook and desktop form factors. Gnome is in the lucky position of having multiple vendors participating and solving different challenges independently. That makes Gnome stronger.

Relationship to FreeDesktop and KDE

Unity complies with freedesktop.org standards, and is helping to shape them, too. We would like KDE applications to feel welcome on a Unity-based netbook. We’re using the Ayatana indicators in the panel, so KDE applications which use AppIndicators will Just Work. And to the extent that those applications take advantage of the Messaging Menu, Sound Indicator and Me Menu, they will be fully integrated into the Unity environment. We often get asked by OEM’s how they can integrate KDE applications into their custom builds of Ubuntu, and the common frameworks of freedesktop.org greatly facilitate doing so in a smooth fashion.

Looking forward to the Maverick Meerkat

It will be an intense cycle, if we want to get all of these pieces in line. But we think it’s achievable: the new launcher, the new panel, the new implementation of the global menu and an array of indicators. Things have accelerated greatly during Lucid so if we continue at this pace, it should all come together. Here’s to a great summer of code.

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.