Mark Shuttleworth | here be dragons

Our goal with Unity is unprecedented ease of use, visual style and performance on the Linux desktop. With feature freeze behind us, we have a refined target render of the Dash for Oneiric, and here it is:

… click for the full size render.

Scopes and Lenses

We’ve moved from the idea of “Places” to a richer set of “Scopes and Lenses”. Scopes are data sources, and can tap into any online or offline data set as long as they can generate categorised results for a search, describe a set of filters and support some standard interfaces. Lenses are various ways to present the data that come from Scopes.

The Scopes have a range of filtering options they can use, such as ratings (“show me all the 5 star apps in the Software Center please”) and categories (“… that are games or media related”). Over time, the sophistication of this search system will grow but the goal is to keep it visual and immediate – something anyone can drive at first attempt.

This delivers on the original goal of creating a device-like experience that was search driven. Collaboration with the always-excellent Zeitgeist crew (quite a few of whom are now full time on the Unity team!) has improved the search experience substantially, kudos to them for the awesome work they’ve put in over the past six months. Since we introduced the Dash as a full screen device-like search experience, the same idea has made its way into several other shells, most notably Mac OS X Lion. While we’re definitely the outsider in this contest, I think we can stay one step ahead in the game given the support of our community.

The existing Places are all in the process of being updated to the Scopes and Lenses model, it’s a bit of a construction site at the moment so hard-hats are advised but dive in if you have good ideas for some more interesting scopes. I’ve heard all sorts of rumours about cool scopes in the pipeline 😉 and I bet this will be fertile ground for innovation. It’s pretty straightforward to make a scope, I’m sure others will blog and document the precise mechanisms but for those who want a head start, just use the source, Luke.

Panel evolution

In the panel, you’ll see that the top left corner is now consistently used to close whatever has the focus. Maximising a window keeps the window controls in the same position relative to the window – the top left corner. We have time to refine the behaviour of this based on user testing of the betas; for example, in one view, one should be able to close successive windows from that top left corner even if they are not maximised.

It’s taken several releases of careful iteration to get to this point. Even though we had a good idea where we were headed, each step needed to be taken one release at a time. Perhaps this might make a little clearer the reasons for the move of window controls to the left – it was the only place where we could ultimately keep them consistent all the way up to a maximised window with the title bar integrated into the panel. I’m confident this part will all be settled by 12.04.

As part of this two-step shuffle, the Dash invocation is now integrated in the Launcher. While this is slightly less of a Fitts-fantastic location, we consider it appropriate for a number of reasons. First, it preserves the top left corner for closing windows. Second, the Dash is best invoked with the Super key (sometimes erroneously and anachronistically referred to as the “Windows” key, for some reason ;-)). And finally, observations during user testing showed people as more inclined to try clicking on items in the Launcher than on the top left icon in the panel, unless that icon was something explicit like a close button for the window. Evidence based design rules.

Visual refinements

Rather than a flat darkening, we’re introducing a wash based on the desktop colour. The dash thus adjusts to your preferred palette based on your wallpaper. The same principle will drive some of the login experience – choosing a user will shift the login screen towards that users wallpaper and palette.

We’ve also integrated the panel and the dash, so indicators are rendered in a more holographic fashion inside the dash. Together with efforts to mute the contrast of Launcher icons the result is a more striking dash altogether: content is presented more dramatically.

Since we have raw access to the GL pipeline, we’re taking advantage of that with some real-time blur effects to help the readability and presentation of overlay content in the Dash, too. Both Nux in the case of Unity-3D and Qt in the case of Unity-2D have rich GL capabilities, and we’d like to make the most of whatever graphics stack you have on your hardware, while still running smoothly on the low end.

Growing community and ecosystem

A project like this needs diverse perspectives, talents and interests to make it feel rounded and complete. While Canonical is carrying the core load, and we’re happy to do so in order to bring this level of quality to the Ubuntu desktop user experience, what makes me particularly optimistic is the energy of the contributors both to Unity directly and to the integration of many other components and applications with the platform.

On the contribution front, a key goal for the Unity community is to maintain velocity in contributor patch flows. You should expect a rapid review and, all being well, landing, for contributions to Unity that are in line with the design goals. In a few cases we’ve also accepted patches that make it possible to use Unity in ways that are different to the design goals, especially where the evidence doesn’t lean very heavily one way or the other. Such contributions add some complexity but also give us the opportunity to test alternatives in a very rich way; the winning alternative would certainly survive, the other might not.

Contrary to common prognostication, this community is shaping up to be happy and productive. For those who do so for love and personal interest, participating in such a community should be fun and stimulating, an opportunity to exercise skills or pursue interests, give something back that will be appreciated and enjoyed by many, and help raise the bar for Linux experiences. I’d credit Jorge and others for their stewardship of this so far, and my heartfelt thanks to all of those who have helped make Unity better just for the fun of it.

Outside of the core, the growing number of apps that integrate sweetly with the launcher (quicklists), dash (scopes), indicators (both app-specific and category indicators) is helping to ensure that API’s are useful, refined and well implemented, as well as improving the experience of Ubuntu users everywhere. Now that we’re moving to Unity by default for both 2D and 3D, that’s even more valuable.

Under the hood

In this round, Unity-3D and Unity-2D have grown together and become twin faces on the same underlying model. They now share a good deal of common code and common services and – sigh – common bugs :-). But we’re now at the point where we can be confident that the Unity experience is available on the full range of hardware, from lightweight thin client systems made of ARM or Atom CPU’s to CADstations with oodles of GPU horsepower.

There’s something of a competition under way between proponents of the QML based Unity-2D, who believe that the GL support here is good enough to compete both at the high end and on the low end, and the GL-heads in Unity-3D, who think that the enhanced experiences possible with raw GL access justify the additional complexity of working in C++ and GL on the metal. Time will tell! Since a lot of the design inspiration for Unity came from game interfaces, I lean to the “let’s harness all the GL we can for the full 3D experience” side of the spectrum, but I’m intrigued with what the QML team are doing.

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.

We have a strong preference for inclusivity in the way we structure the Ubuntu community. We recognise a very diverse range of contributions, and we go to some lengths to recognise leaders in many areas so that we can delegate the evaluation process to those who know best.

For example, we have governance structures for different social forums (IRC, the Forums) and for various technical fields (development, translation). We quite pointedly see development and packaging as one facet of a multi-faceted project, and I think Ubuntu is much stronger for that approach.

Jonathan Carter raised a very interesting question recently, which was how we recognise those who’s best contribution to Ubuntu (and it may well be intended very much as a contribution to Ubuntu) is by working in other projects. His specific question was “upstream” but as we discussed it amongst members of the CC it threw up all sorts of gaps in our membership process, such as recognising those who make collaboration between Debian and Ubuntu easier, and those who work in derivatives like Mint, and do so in a way that makes it easy for Ubuntu to benefit from their work.

The issue was brought to the fore because several contributors to Unity and Launchpad had applied for membership. We had previously seen scattered upstream-based applications for membership, but the fact that there were a few of these and that they were Canonical employees turned it into something which needed wider consideration.

For obvious reasons, I don’t think a Canonical project should be special cased. Ubuntu is a shared effort between Canonical and community contributors, and Canonical already has effective representation. But I think the question is much more interesting when it’s asked as a general proposition: if someone feels they want to help other Ubuntu users by doing work in a *different* project, why should we not recognise that? And if we’re going to try to do so, how do we do it well? Specifically, how do we
avoid diluting the cohesive nature of the membership of Ubuntu, who are polled for confidence in appointments to the Community Council, if we say we will consider membership applications from any of the thousands of projects that feed into the platform? How on earth do we even start to evaluate “substantial and sustained” contributions? It’s a very interesting problem.

Matthew East blogged to say that there are some codebases that are closer to Ubuntu than others. That’s probably true, but it’s also been a point of pride that we encourage groups like the LXDE community to express their experience as official remixes, from Kubuntu to Xubuntu and Lubuntu and beyond. I agree with Matthew that, in order to be an unambiguous target for developers, we need to be firm about a narrow set of API’s and installation requirements. That means a project like Unity becomes an “obvious” way to contribute to Ubuntu, though of course other distributions are likely to use Unity and there may be people who contribute there specifically for them.

But more importantly, I think we should start to find ways in which someone could participate in ANY project upstream (or downstream) and still gain membership in Ubuntu if that is valuable to them, or aligned with their values.

For example: someone who correlates upstream bugs with Ubuntu bugs in Launchpad, is doing work that improves Ubuntu for everyone. Someone who fixes issues in an upstream stable release in order to facilitate an SRU, is doing the same. Ensuring that an upstream is going to work with the next kernel/toolchain/X/GL version set has a similar benefit. There are any number of ways in which someone who uses Ubuntu, shares the values of the project and wants to help but is closer to an upstream can express
themselves. And we should recognise them all.

I’m not at all certain how we would do so perfectly in practice, because the diversity of projects out there is so great, and the diversity of ways they track their contributors is so great. But I think we should try. We could create a team that reviews such applications and makes a best effort to assess them, erring on the side of caution. Who’s up for the challenge?