Let’s celebrate this milestone in Ubuntu reporting for and by the community. UWN is my favourite way to keep up with waht’s going on across the full length and breadth of the community. If you want a single read per week to know what you are part of, this is it. And if you’re doing something cool, these are the guys to tell about it, they’ll tell the world.

A big thank you from me to the team who makes it real every week.

Welcome to the Ubuntu Weekly Newsletter, Issue 200 for the week June
27 – July 3rd, 2010.

The purpose of this newsletter is to let everyone know what is
happening in all the different corners of the vast Ubuntu community.
It’s a snapshot of the Ubuntu Community one week at a time.

The first issue was unleashed June 4th, 2006, and a little over four
(4) years and seven (7) releases later UWN and the Ubuntu Community
continues to mature and grow together.

The Ubuntu News Team, which includes both UWN and Fridge, continues to
report what happens, effects, and relates to the the vast and ever
growing Ubuntu community, including information from the different
teams, LoCos, forums, mailing lists, IRC universe, and newsworthy
press coverage and blogs. A very important and helpful contribution
many LoCo Teams continue to do is spread the news by translating UWN.

It has undoubtedly been a fun and rewarding experience for all involved!

We would like to thank all our readers for your continued support and
feedback and encourage you to keep sending the Ubuntu News Team your
comments and corrections (yes, we do make mistakes!).

Linaro: Accelerating Linux on ARM

Thursday, June 3rd, 2010

At our last UDS in Belgium it was notable how many people were interested in the ARM architecture. There have always been sessions at UDS about lightweight environments for the consumer electronics and embedded community, but this felt tangibly different. I saw questions being asked about ARM in server and cloud tracks, for example, and in desktop tracks. That’s new.

So I’m very excited at today’s announcement of Linaro, an initiative by the ARM partner ecosystem including Freescale, IBM, Samsung, ST-Ericsson and TI, to accelerate and unify the field of Linux on ARM. That is going to make it much easier for developers to target ARM generally, and build solutions that can work with the amazing diversity of ARM hardware that exists today.

The ARM platform has historically been superspecialized and hence fragmented – multiple different ARM-based CPU’s from multiple different ARM silicon partners all behaved differently enough that one needed to develop different software for each of them. Boot loaders, toolchains, kernels, drivers and middleware are all fragmented today, and of course there’s additional fragmentation associated with Android vs mainline on ARM, but Linaro will go a long way towards cleaning this up and making it possible to deliver a consistent platform experience across all of the major ARM hardware providers.

Having played with a prototype ARM netbook, I was amazed at how cool it felt. Even though it was just a prototype it was super-thin, and ran completely cool. It felt like a radical leap forward for the state of the art in netbooks. So I’m a fan of fanless computing, and can’t wait to get one off the shelf :-)

For product developers, the big benefit from Linaro will be reduced time to market and increased choice of hardware. If you can develop your software for “linux on ARM”, rather than a specific CPU, you can choose the right hardware for your project later in the development cycle, and reduce the time required for enablement of that hardware. Consumer electronics product development cycles should drop significantly as a result. That means that all of us get better gadgets, sooner, and great software can spread faster through the ecosystem.

Linaro is impressively open: www.linaro.org has details of open engineering summits, an open wiki, mailing lists etc. The teams behind the work are committed to upstreaming their output so it will appear in all the distributions, sooner or later. The images produced will all be royalty free. And we’re working closely with the Linaro team, so the cadence of the releases will be rigorous, with a six month cycle that enables Linaro to include all work that happens in Ubuntu in each release of Linaro. There isn’t a “whole new distribution”, because a lot of the work will happen upstream, and where bits are needed, they will be derived from Ubuntu and Debian, which is quite familiar to many developers.

The nature of the work seems to break down into four different areas.

First, there are teams focused on enabling specific new hardware from each of the participating vendors. Over time, we’ll see real convergence in the kernel used, with work like Grant Likely’s device tree forming the fabric by which differences can be accommodated in a unified kernel. As an aside, we think we can harness the same effort in Ubuntu on other architectures as well as ARM to solve many of the thorny problems in linux audio support.

Second, there are teams focused on the middleware which is common to all platforms: choosing APIs and ensuring that those are properly maintained and documented so that people can deliver any different user experience with best-of-breed open tools.

Third, there are teams focused on advancing the state of the art. For example, these teams might accelerate the evolution of the compiler technology, or the graphics subsystem, or provide new APIs for multitouch gestures, or geolocation. That work benefits the entire ecosystem equally.

And finally, there are teams aimed at providing out of the box “heads” for different user experiences. By “head” we mean a particular user experience, which might range from the minimalist (console, for developers) to the sophisticated (like KDE for a netbook). Over time, as more partners join, the set of supported “heads” will grow – ideally in future you’ll be able to bring up a Gnome head, or a KDE head, or a Chrome OS head, or an Android head, or a MeeGo head, trivially. We already have goot precedent for this in Ubuntu with support for KDE, Gnome, LXE and server heads, so everyone’s confident this will work well.

The diversity in the Linux ecosystem is fantastic. In part, Linaro grows that diversity: there’s a new name that folks need to be aware of and think about. But importantly, Linaro also serves to simplify and unify pieces of the ecosystem that have historically been hard to bring together. If you know Ubuntu, then you’ll find Linaro instantly familiar: we’ll share repositories to a very large extent, so things that “just work” in Ubuntu will “just work” with Linaro too.

Belgium was brilliant

Thursday, May 20th, 2010

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

Unity, and Ubuntu Light

Monday, May 10th, 2010

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

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

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.

Unity Dash

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.

Window indicators

Monday, May 3rd, 2010

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 follow the standard Ayatana indicator pattern, but are specific to a particular window.

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):

Mockup of maximised window, with smart panel and window indicators.

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.

In the netbook edition for 10.10, we’re going to have a single menu bar for all applications, in the panel.

Our focus on netbooks has driven much of the desktop design work at Canonical. There are a number of constraints and challenges that are particular to netbooks, and often constraints can be a source of insight and inspiration. In this case, wanting to make the most of vertical space has driven the decision to embrace the single menu approach.

It’s all about vertical pixels

Netbooks are conventionally small-and-wide-screen devices. A common screen format is 1024×600. There’s plenty of horizontal space, but not a lot of vertical space. So we’ve been lead to explore options that really make the most of the vertical space.

This is important because the main thing people do with a netbook is surf the web. And most pages will fit horizontally in a netbook screen, but they require quite a lot of vertical scrolling. The more we can optimise the use of vertical space, the more enjoyable it will be to spend time on the web, with your netbook.

In the first few iterations of Ubuntu’s netbook-oriented UI, we concentrated on collapsing the window title into the top panel. In 10.10, we’re going to put the menu there.

Only on the Netbook Edition UI

We’re going to put the menu in the panel on the netbook edition of Ubuntu, and not on the desktop edition, because that’s where the screen real-estate is most precious. There are outstanding questions about the usability of a panel-hosted menu on much larger screens, where the window and the menu could be very far apart. Those questions are greatly diminished in the netbook environment, by definition.

Also, the netbook edition has a reduced application load. That will reduce the number of applications we need to get this working on.

However, it will be straightforward to use this on your desktop too, if you want, and we’d encourage people to try with that configuration. The more testing we have early on, the better we’ll understand how it works with different applications. It will be easy to add to the standard desktop panel for people who want to try it out, or prefer to work that way.

Innovation: combining title and menu in a single panel

It’s not confirmed yet, but we will aim to go beyond what Apple and others have done with panel menus, to consolidate both the window title (and window controls) into the panel along with the menu.

By default, we’d display the contents of the title bar. When you mouse up to the panel, or when you press the Alt key, the contents would switch to the menu. That way, you’re looking at the document title most of the time, unless you move towards it to click on the menu.

In mockups and prototype testing, the result was a leaner, cleaner feeling netbook interface. Less clutter, less wasted space, and improved clarity of purpose. We’ll have to get running code in front of users to evaluate the usability of it and tweak transitions and presentation.

Generally, people use netbooks with a small set of applications running, all maximised. In that case, putting the menu in the panel will save 24 pixels, about 4% of the vertical space. Combined with other work on the netbook interface, we’re confident there is no better OS for surfing the net on your ultra-mobile netbook.

Under the hood: d-bus menu transport

The technical approach we are taking in this work is to build on the d-bus menu work that Cody Russel and Ted Gould have pioneered for our work on indicators.

Essentially, this lets us map a menu into d-bus space, where a different application can take responsibility for rendering it. The technology works across both Gtk and Qt applications, so we are confident that it will work for the common cases of GNOME and KDE apps running on the Ubuntu netbook edition.

Of course, there is a lot of work to be done to support applications that use different toolkits, notably the Mozilla suite of Firefox and Thunderbird, and OpenOffice.

And there will be many applications which need some thought as to how best to map the experience from the current world of “one menu per window” to a single, panel-displayed menu.

We’ve started working on this with the existing Global Menu project. While there are differences in the technical approach we want to take, that team has already identified many of the common issues, and there are great opportunities for us to collaborate. I’m looking forward to seeing the result in action in 10.10!

Regional Membership Board nominations

Tuesday, April 27th, 2010

One of the most important things we do in Ubuntu is recognize the contributions of fantastic participants across the wide range of activities that make up something as broad as Ubuntu.

We have the guiding principle that we should be able to recognize the merits of any kind of contribution, coming from any part of the globe. Whether someone is spending time helping people on IRC, or answering questions in the Forums, or translating Ubuntu into Amharic, or leading local events to raise awareness of Ubuntu, or leading a team that deploy Ubuntu in schools, or building Ubuntu based virtual machines on EC2, or fixing bugs, or triaging bugs, or filing really good bug reports….. contributions of all forms make Ubuntu more useful to a broader audience, and so we set out to recognize them with Membership.

The actual decisions are taken by the Regional Membership Boards. We set up three of them to cover the America’s, EMEA (Europe, Middle East, Africa), and Asia-Pacific. People who are seeking membership present their work to the RMB’s, who confer membership on those who they believe have made a “substantial, and sustained” contribution, in any field. We also allow specialist leadership teams to confer membership for contributions in their fields, on the basis that they may have more insight into the dynamics of that particular work.

The RMB’s play a big role in sustaining the culture of Ubuntu, in who and what they recognize and in the advice that they offer applicants.

In order to keep the RMB’s fresh, we renew the membership of the RMB’s on a regular basis. Folks stand for a term, and we seek nominations regularly. Like now :-)

We’re seeking nominations to all three Regional Membership Boards. Ideal candidates have a track record good judgment – and a willingness to support positive contributions matched only by their willingness NOT to be drawn into supporting factions, personalities and cabals. In any community of scale (and Ubuntu is at a larger scale than most) there will always be people making fascinating and unexpected (and hard to evaluate) contributions, as well as people who want to further their own ambitions at the expense of others. Being able to tell the difference, and recognizing those who are going to continue to raise the bar for Ubuntu, is a skill.

If you know someone who does, please seek their assent to nominate them for their Regional Membership Board. You can chat with dholbach on IRC, or mail the RMB’s for further information.

The mails from RMB’s announcing new members are one of the most interesting kinds “pulse” for the project – who’s doing what, where. So I’d like to thank the folks who have lead the RMB’s over the past cycle, and say again how much I appreciate their work!

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.

It’s time to put our heads together to envision “the perfect 10″.

This is a time of great innovation and change in the Linux world, with major new initiatives from powerful groups bringing lots of new ideas, new energy and new code. Thanks to the combined efforts of Google, Intel, IBM, Canonical, Red Hat, Oracle, Cisco, ARM, many other companies, Debian and other projects, a hundred startups and tens of thousands of professional and inspired contributors, the open source ecosystem continues to accelerate. We need to bring the best of all of that work into focus and into the archive. For millions of users, Ubuntu represents what Free Software can do out of the box for them. We owe it to everybody who works on Free Software to make that a great experience.

At the Ubuntu Developer Summit, in May in Belgium, we’ll have a new design track, and a “cloud and server” track, reflecting some major focal points in 2010. They will complement our ongoing work on community, desktop, kernel, quality assurance, foundations and mobile.

Our new theme is “Light”, and the next cycle will embrace that at many levels. We have a continued interest in netbooks, and we’ll revamp the Ubuntu Netbook Edition user interface. As computers become lighter they become more mobile, and we’ll work to keep people connected, all day, everywhere. We’ll embrace the web, aiming for the lightest, fastest web experience on any platform. The fastest boot, the fastest network connect, the fastest browser. Our goal is to ensure that UNE is far and away the best desktop OS for a netbook, both for consumers and power users.

On the other end of the spectrum, we’ll be lightening the burden of enterprise deployment with our emphasis on hybrid cloud computing. Ubuntu Server is already very popular on public clouds like EC2 and Rackspace, and now that Dell supports the Ubuntu Enterprise Cloud for private cloud infrastructure, it’s possible to build workloads that run equally well in your data center or on the cloud. We’ll focus on making it even easier to build those workloads and keep them up to date, and managing the configurations of tens, or tens of thousands, of Ubuntu machines running in the cloud.

It’s not all about work. We don’t just want to be connected to the internet, we want to be connected to each other. Social from the Start is our initiative to make the desktop a collaborative, social place. For the past five years, we’ve all been shifting more and more data into the web, to a series of accounts and networks elsewhere. Now it’s time to start to bring those social networks back into our everyday computing environment. Our addressbooks and contact lists need to be synchronized and shared, so that we have the latest information everywhere – from mobile phones to web accounts.

So there’s a lot to do. I hope you’ll join us in shaping that work.

Introducing the Maverick Meerkat

Our mascot for 10.10 is the Maverick Meerkat.

This is a time of change, and we’re not afraid to surprise people with a bold move if the opportunity for dramatic improvement presents itself. We want to put Ubuntu and free software on every single consumer PC that ships from a major manufacturer, the ultimate maverick move. We will deliver on time, but we have huge scope for innovation in what we deliver this cycle. Once we have released the LTS we have plenty of room to shake things up a little. Let’s hear the best ideas, gather the best talent, and be a little radical in how we approach the next two year major cycle.

Meerkats are, of course, light, fast and social – everything we want in a Perfect 10. We’re booting really fast these days, but the final push remains. Changes in the toolchain may make us even faster for every application. We’re Social from the Start, but we could get even more tightly connected, and we could bring social features into even more applications. Meerkats are family-oriented, and we aspire to having Ubuntu being the safe and efficient solution for all the family netbooks. They are also clever – meerkats teach one another new skills. And that’s what makes this such a great community.

Here’s looking at the Lynx

Lucid is shaping up beautifully, but there’s still a lot to be done to make it the LTS we all want. Thanks to everyone who is bringing their time, energy and expertise to bear on making it outstanding. And I’m looking forward to the release parties, the brainstorming at UDS, and further steps on our mission to bring free software to the world, on free terms.

Less is more. But still less.

Thursday, March 25th, 2010

One of the driving mantras for us is “less is more”. I want us to “clean up, simplify, streamline, focus” the user experience work that we lead. The idea is to recognize the cost of every bit of chrome, every gradient or animation or line or detail or option or gconf setting. It turns out that all of those extras add some value, but they also add clutter. There’s a real cost to them – in attention, in space, in code, in QA. So we’re looking for things to strip out, as much (or more) as things to put in.

I’m not sure we’ll go as far as Microsoft has with their new Windows Phone 7 UI (links to .PPTX), which uses a design language called Metro. It’s radically pared back, and very cool work. It will be interesting to see if they’ve gone too far, or if users take to the more abstract feel of it.

It’s not hard to get people enthusiastic about the idea that less is more. However, it’s quite hard to get people to agree on which bits can be less. It turns out that one person’s clutter is another person’s most useful and valued feature.

Less, it turns out, is still less.

So, for example, consider tooltips on the panel. In bug #527458, there’s some discussion about a decision I made to deprecate tooltips on panel indicators. For quite a lot of people, that’s a little less too far.

On that particular decision, we’ll have to let time tell. For the moment, the decision stands. I’m the first to admit fallibility but I also know that it would be impossible to get consensus around a change like that. If those tooltips are, on balance, really just clutter, then unless someone is willing to take a decision that will be unpopular, they will be clutter forever. And it’s easier for me to make a decision like that in Ubuntu than for virtually anybody else. I apologise in advance for the mistakes that I will certainly make, and which others on the design team may make too, but I think it’s important to defend our willingness to pare things back and let the core, essential goodness shine through. We have to balance innovation and change with clarification and focus. We can’t *stop* innovating and changing, and we have to be willing to remove things that someone will miss.

The bug is a good place to continue the discussion about that particular issue. But I thought it would be useful to issue a call to arms, and invite suggestions from people on the Ayatana list as to what elements of the existing Ubuntu desktop can be trimmed back, on balance making the whole better.

There’s a growing awareness and excitement about the importance of design in free software. A few years ago, folks laughed out loud when it was suggested that design is a good thing for the free software community to build expertise in.  And it’s been slow going, admittedly. It’s hard to bring clarity in a crowd. Or mob. We’ve been doing our part to lead that at Canonical and in the Ubuntu community, both through internal work and through public forums. If you’re interested in design and Free Software, then Ubuntu and Ayatana and related forums are great places to participate. And your participation is welcome!