Canonical Voices

Posts tagged with 'ubuntu'


In the open source community, we celebrate having pieces that “do one thing well”, with lots of orthogonal tools compounding to give great flexibility. But that same philosophy leads to shortcomings on the GUI / UX front, where we want all the pieces to be aware of each other in a deeper way.

For example, we consciously place the notifications in the top right of the screen, avoiding space that is particularly precious (like new tab titles, and search boxes). But the indicators are also in the top right, and they make menus, which drop down into the same space a notification might occupy.

Since we know that notifications are queued, no notification is guaranteed to be displayed instantly, so a smarter notification experience would stay out of the way while you were using indicator menus, or get out of the way when you invoke them. The design story of focusayatana, where we balance the need for focus with the need for awareness, would suggest that we should suppress awareness-oriented things in favour of focus things. So when you’re interacting with an indicator menu, we shouldn’t pop up the notification. Since the notification system, and the indicator menu system, are separate parts, the UNIX philosophy sells us short in designing a smart, smooth experience because it says they should each do their thing individually.

Going further, it’s silly that the sound menu next/previous track buttons pop up a notification, because the same menu shows the new track immediately anyway. So the notification, which is purely for background awareness, is distracting from your focus, which is conveying exactly the same information!

But it’s not just the system menus. Apps can play in that space too, and we could be better about shaping the relationship between them. For example, if I’m moving the mouse around in the area of a notification, we should be willing to defer it a few seconds to stay out of the focus. When I stop moving the mouse, or typing in a window in that region, then it’s OK to pop up the notification.

It’s only by looking at the whole, that we can design great experiences. And only by building a community of both system and application developers that care about the whole, that we can make those designs real. So, thank you to all of you who approach things this way, we’ve made huge progress, and hopefully there are some ideas here for low-hanging improvements too :)

Read more
Iain Farrell

Birds in flight by Noombox

For another cycle a selection of images has been put forward for inclusion in Ubuntu. As there have been some questions on other blogs about the process I thought it was worth doing a quick refresher. Each release we ask the community contributors whose images were included in the last release if they’d like to help choose the images that should go into the up coming release. This release we are endebted to the following Flickr users and community members:

  • madeinkobaia
  • SirPecanGum
  • bolorino
  • Deacon MacMillan
  • Noah Bertilson
  • Micheo
  • Fix Peña
  • Fejes Ádám
  • federica_miglio
  • Difusa
  • Hugo.Cliff
  • Mohamed Malik
  • Dh0r
  • paco • espinoza
  • pr09studio
  • Belhor_
  • Emilio Merlino
  • erin_estes
  • j_baer
  • fernando garcía redondo
  • followtheseinstructions
They and I carefully went through the thousands of images and we thank them for their effort and care. Once some images are shortlisted the creators are invited to add them to a shortlist group and supply us with high resolution images (minimum 2550 x 1660) and make sure the licence they use is CC by SA.
The deadline for the wallpapers is the beta freeze and at this point the shortlisted images we’ve received are attached to the appropriate bug in Launchpad. We almost always have more images to put on the CD than will make it in but we always make sure that all the chosen images we receive from contributors are included in bug for inclusion in the distro, if some don’t make it at least everyone has access to these images.
As with all processes it’s about refinement over time so while this process went well and we’ve got some really great images, what can we do next time to make it better?
Firstly we’ll be looking at limiting entries, many people submitted way more images than is sensible. We have a very detailed photo diary of someone’s holiday, for example, and that’s not what choosing wallpapers is all about. We will also look to bring the deadline for entries forward to allow for more time to gather files. One of the reasons that the number of illustrated wallpapers we invited to be in the final shortlist haven’t made it is because at time of writing we don’t have high resolution files from them. Rest assured that if they do appear in the remaining time before release I’ll work to cajole cuddle and squeeze any additional great images in but it looks like in this case a week wasn’t long enough. This may in part be due to the fact that the contributors we get here are often new to the project and not always aware of the delivery mechanisms used and aware of how important deadlines are. We’ll allocate more time next release for collation and review so we can help educate people on what the development schedule, Creative Commons licensing and the like are all about. Members of the team who helped this time around have said they’d be happy to help moderate and educate during the next release so we should also have more hands to help with the process which is splendid!
Having read comments on some other blogs and news sites I’d also like to end on a very important point. Every six months we contribute in a small way to Ubuntu with this submissions process. Community members from all over the world provide a number of new images which if users choose, they can have as the wallpaper on their desktop. People take photos, draw illustrations and tinker to create images specifically for this project and it is unfair to them and the team who review the images to simply post comments saying that the images are poor and not what you’d have chosen. Wallpapers are an optional component. They’re a small part of the whole and a team of willing community volunteers, myself included, select what we hope people will like and what we hope is a bit different to last time to keep things fresh and interesting. If you don’t see something you’d have chosen, that’s ok, you can choose your own image(s) and even post yours in time for the next release. Get involved!
So to all of you reading on this Friday afternoon, if you like the work of someone whose image was chosen or included in the submissions process, tell them about it. Blog it, show it to your friends, tweet it, send it to friends who don’t even use Ubuntu who might like it. Let’s celebrate the creation of free content and celebrate Ubuntu. That’s what it’s all about isn’t it?

Read more
John Lea

Introduction to task switching

A key part of any operating system user interface is how it enables the user to switch between multiple tasks. In most desktop operating systems tasks are encapsulated into windows, and the most frequently used method of multi-tasking is window switching. Desktop OSs have multiple methods of window switching (e.g Alt-tab, clicking on indicators, notifications, etc…) however the most common means of window switching is via using what is variously termed a Launcher, Taskbar or Dock. Traditionally there has been a 1:1 correlation between each window and its representation in the Taskbar (see Windows2000 or Gnome2).

(Ubuntu Hardy Heron used Gnome2 which featured one taskbar icon per window)

With Windows XP, Microsoft introduced a way to aggregate multiple windows that belonged to the same application into a single task bar button. This change was primarily focused towards personas who made heavy use of multi-tasking; this feature only switched on when the number of windows represented in the Taskbar exceeded the length of the Taskbar. It gave the benefits of increasing the number of windows that could be comfortably represented in the available task bar space, and reduced the time and effort it took the user to visually scan a crowded Taskbar and identify an application. The cost of this change was that an additional click was required to switch to a window that was not the most recently focused window of that application.

Windows XP desktop
(The WindowsXP desktop that introduced the concept of representing multiple windows with one taskbar icon)

Unity’s current window switching functionality

Fast forwarding to 2009, when working on the original designs for Unity we knew that window switching was one of the key areas of any OS’s user interface, and we set out to design a window switching paradigm that would surpass the utility and usability of the contemporary competition at the time (Windows 7 and OSX Snow Leopard). The Launcher was only 50% of that equation, the other 50% was a set of functionality we termed the ‘Spread’.

The Spread designs were completed, prototyped and tested well before the launch of Unity with 11.04, but unfortunately due to the huge number of other items that needed to be completed before we could launch a brand new desktop shell, the decision was made to postpone the development of this feature and use the Compiz equivalent of this functionality as a stop-gap measure.

Ubuntu 11.04 desktop
(Compiz window switching in Ubuntu 11.04)

While using the Compiz window switching functionality enabled us to hit 11.04 launch deadline, there are a number ways in which it could be improved. Since then many many bugs, mailing list and forum postings have also requested the same set of functionality that was postponed as a result of this decision. Requests we frequently receive include:

  • Please make it easier to tell one window from another, all terminals look very similar!
  • Make it easier to select windows using keyboard navigation and shortcuts
  • I would like to be able to easily close windows from the window switcher view
  • Can you make it clearer to see which application’s windows are currently being displayed (in the switcher view)?
  • I find it difficult to see which window is currently focused in the window switcher view, can this be improved?
  • Can you find a way to make window switching faster?

Window switching requirements

After researching the window switching problem space and examining the use cases that a window switcher needs to support, we distilled the findings into a set of design requirements. These were:

  • To aid window identification, the window previews should to be as large as possible, taking maximum advantage of the available screen real estate.
  • Window switching needs to be very intuitive and easy to understand for new users. In user testing, a user who has never used Ubuntu before must be able to switch windows without encountering any difficulty.
  • More experienced users should be offered an accelerated method of ultra-fast window switching.
  • Users should be presented with all the information that is pertinent to making a window switching decision, but no more.
  • The window switching mechanism should follow the activity/task hierarchy, in order to minimise time needed to identity the required application, support intensive multi-tasking use cases with very large numbers of windows, simplify the Launcher ordering problem, and make the most efficient use of the Launcher’s screen real estate.

A very brief introduction the ‘Spread’

So now with 12.04 almost behind us, we have dusted off our original Spread designs and given them a light spring clean ahead of development starting in 12.10. So without further ado…

This design shows when happens when a user clicks on the Firefox icon to spread the available windows. The maximum amount of screen real estate is dedicated to making the window previews as large as possible. Moving the pointer over any of the previews will display the window name in a window title bar, and a close button is included so that any window can be dismissed directly from this view. When in this view users can also directly switch to spreads of other running applications by clicking on application icons in the Launcher.

In addition to pointing and clicking with a mouse or trackpad, power users can perform all window switching actions without taking their hands off the keyboard. Holding down the SUPER key will reveal the Launcher with numbers overlaid on top of the individual Launcher icons.

Pressing a number performs the equivalent action to a left click, so if a app is already focused pressing its number will reveal a spread of its windows.

When the spread is revealed, numbers are displayed in the bottom left corner of the previews. Pressing a number will then select the relevant window and close the Spread. Added together this allows a power user to switch to any window of any application just by using the SUPER and NUMBER keys. In addition users will be able to navigate the Spread by using cursor keys to move the orange focus box and ENTER to select.

Another new feature is the ghost window ‘New Window’ option. Previously if a user wanted to open a new window for an application that was already running they had to either middle click on the application’s Launcher icon or press CTRL+N. The problem was that new users had no easy way of discovering these options. When using the Spread, a user can select the ghost window to open a new window of the currently focused application. This feature has even more benefits in a multi-monitor context, and if a application does not support multiple windows this option is not displayed.

Other features include the ability to filter the windows by typing…

and of course this new functionality apples to the SUPER+W spread of all windows on the desktop.

Multi-monitors, workspaces, and all the other gory details

This article only takes a very brief look at a few of the Spread’s features, and barely scratches the surface of the Spread design. A lot of thought has also gone into designing how the spread works in multi-monitor and/or multi-workspace environments, and if you are interested in learning more and reading all the gory details of how every corner case and eventuality is handled, head over to Unity Switching section of the The Toolkit to read the full spec.

Read more
Iain Farrell

All the way back in January we kicked off the submissions process for the next released of Ubuntu.

We did this using Flickr and since then the group has been inundated with over 2,700 submissions! This is an incredible achievement in a reasonably short time and many of the entries are looking great.

Charline, on the Canonical Design Team, contacted me earlier today to ask about what comes next. Well, first of all I’d like to thank everyone who has submitted thus far. It’s an incredible amount of user generated content and we should be chuffed to bits to have so much good stuff to sort through. Next I’d also like to encourage anyone who _has_ submitted to review what they’ve placed in the group. We are about to ask a small group of people to select from nearly three thousand images. If you’ve submitted more than one image if you could please review your images and decide if we really should be considering them all that would be a huge help :)

Lastly, don’t forget the deadline for submissions is March 15th 18:00 UK time. At that point I’ll close the group and the judges will start sorting through these entries. Then from their selection we’ll try and get down to a number of images that can be safely fitted onto the CD image. As always we’ll separate out the entries selected into their own group and we’re also looking into making a package of all the selected images so the completionists out there can get all the wallpapers in one easy package.

Easy, huh? Well you don’t have to sort through 3000 images in a week! ;) Happy snapping, sketching and scanning!

Read more
Mika Meskanen

Ubuntu and Canonical had a very strong presence at this year’s Mobile World Congress in Barcelona. The main attraction was our Ubuntu for Android prototype that was published just a week earlier. The beautiful cubic pavilion also housed the Ubuntu TV demo, Ubuntu One, and our established desktop and cloud offerings. The booth attracted a constant flux of curious visitors representing all walks of life: media, industry people, businessmen, technology enthusiasts, students and… competitors.

John Lea, Oren Horev and myself from the Design Team joined Canonical sales, business and technical staff in this bold effort. In addition to running demos and having interesting conversations with the visitors to the booth, we also had the opportunity to have a look at the endless exhibition halls and floors of the conference and do research on what makes the mobile world tick at the moment.

If the MWC 2012 had to be summarised in one tagline, anyone would probably admit, that it was a one massive Androidfest.

Google’s recently upgraded operating system was simply everywhere. Spearheading the Android avalanche were the latest generation supermobiles – every device manufacturer was showing off with their versions of quad-core, high-definition, 4G/LTE smartphones and tablets bumped up to the latest specification.

Bells and whistles ranged from glasses-free 3D displays to Dolby sound to watertight casings – demonstrating that OEM customisations go beyond branding and skinning the interface.

Google themselves hosted an extensive Android area that was more like a theme park than a typical business affair: fans and passers-by were treated to a smoothie bar, a tube slide (presumably an homage to Google offices), grab-a-plush-Android game – and lucky ones could have had their Nexus phones pimped up with Svarovski crystals assembled by an industrial robot.

In stark contrast to Google’s rather playful attitude towards their ecosystem, the manufacturers were more poised for flexing their technological muscle. The impending hockey-stick curve of serious mobile computing power seems to all but prove the concept behind Ubuntu for Android. The phones of the near future are going to effortlessly run desktop and mobile operating systems simultaneously, and those extra cores can do more than just keep your hands warm in your pocket. Similarly, in our hands-on testing, the demoed 4G/LTE connections were lightning fast, signalling that accessing your cloud and thin client applications from a phone running a full productivity desktop can shift the paradigms of your mobile working life.

While this year’s congress was overrun by Android, it will be interesting to see whether this will be repeated next year, when we can assume to see the effects of Google’s Motorola acquisition and the impact of Windows 8. The latter had reached Consumer Preview stage and was presented in a separate session outside the main exhibition.

Most of the manufacturers had an odd Windows Phone in their inventory, but basically its marketing was left to Nokia, who also occupied a substantial exhibition floor not far from us. The newfound underdogs were quite upbeat about their Lumia phones, 41 megapixel cameras and the staff were very approachable in their stripy Marimekko shirts and funny hats.

In one of the quieter affairs, the Nokia Research Centre demoed an indoor positioning system that promises 30 centimere accuracy and presumably lands in a Bluetooth standard in the near future, enabling a range of user experience scenarios for malls, airports and alike. Affordable Asha phones and Nokia Life for emerging markets were featured as well.

Aside from phones, there were a number of smart TV upstarts. We saw a few demos built on old versions of Android, where a phone interface jumped on the screen as soon as the user leaves the home screen. A more captivating demo came from the Korean company Neo Mtel, who showed off a UI with lots of lively widgets and affectionate animations. They also had a tablet-based “second screen” to complement the product vision.

Perhaps a little surprisingly, Opera (of the Opera browser fame) showcased a TV platform based on web technologies.

In Hall 7 we also had the pleasure of having Mozilla as our next door neighbours. They had set up a nice lounge where people could try out the latest Firebox browser for Android phone and tablet. The Boot to Gecko initiative had matured into the Open Web Device together with Telefonica, and resulted in a working demo of a phone OS, based entirely on web technologies with APIs to talk to the handset’s camera, sensors and telephony software, for example. It was also interesting to exchange thoughts on open-source design and development with the fine Mozilla employees.

Meanwhile, there were some interesting evolutions in device form factors to be discovered. Samsung exhibited a 10-inch Galaxy Note tablet with Adobe Photoshop Touch and very precise and responsive drawing stylus. With the exception of tactile feedback the experience is closing in on that of pen and paper – and for many, the benefits of digital malleability can outweigh the constraints of analogue tools.

Notepad-sized phones are parallel to this trend. The Galaxy Note phone got a rival from LG’s 5-inch Optimus Vu. Both devices channel the passport-size Moleskine or Muji notepad and flaunt oversized screens and stylus input. To prove the point, Samsung had dragged a bunch of portrait street artists to capture the likenesses of volunteering visitors on these polished pixelslates.

The requirement of pocketability and one-handed use has caused many (starting with Apple) to overlook this emerging form factor, but not everyone keeps their mobiles in their pockets and many use their phones with two hands anyway. It will be interesting to see how the notepad phones fare in the market and what kind of UI patterns will prevail there.

Last, but not least, the Padphone from ASUS is a very interesting play on device convergence and as such resonates with Ubuntu for Android. The Padphone is a smartphone that docks into a tablet shell and instantly becomes a tablet. The tablet with the phone inside can then be docked into a keyboard, turning the device into a laptop. While some clunkiness with the hardware remains, the user interface seems to transition from phone to tablet seamlessly and in a snap. However, there’s less wow in the tablet-to-laptop transition, where just a mouse pointer is added into the mix. Since Android is designed for touch this is no surprise, but there’s some added value in having a physical keyboard for typing.

Amidst all the sensory overload and throughout the four days of congress, the Ubuntu booth felt like an oasis of good vibes all the time. The interest and support from people we encountered was really encouraging and very heartwarming. Hands-on videos from the booth went viral across the internet. Many said that Ubuntu for Android was the highlight of the Mobile World Congress 2012.

Visit the Ubuntu for Android site for more…

Read more

Our mission with Ubuntu is to deliver, in the cleanest, most economical and most reliable form, all the goodness that engineers love about free software to the widest possible audience (including engineers :) ). We’ve known for a long time that free software is beautiful on the inside – efficient, accurate, flexible, modifiable. For the past three years, we’ve been leading the push to make free software beautiful on the outside too – easy to use, visually pleasing and exciting. That started with the Ubuntu Netbook Remix, and is coming to fruition in 12.04 LTS, now in beta.

For the first time with Ubuntu 12.04 LTS, real desktop user experience innovation is available on a full production-ready enterprise-certified free software platform, free of charge, well before it shows up in Windows or MacOS. It’s not ‘job done’ by any means, but it’s a milestone. Achieving that milestone has tested the courage and commitment of the Ubuntu community – we had to move from being followers and integrators, to being designers and shapers of the platform, together with upstreams who are excited to be part of that shift and passionate about bringing goodness to a wide audience. It’s right for us to design experiences and help upstreams get those experiences to be amazing, because we are closest to the user; we are the last mile, the last to touch the code, and the first to get the bug report or feedback from most users.

Thank you, to those who stood by Ubuntu, Canonical and me as we set out on this adventure. This was a big change, and in the face of change, many wilt, many panic, and some simply find that their interests lie elsewhere. That’s OK, but it brings home to me the wonderful fellowship that we have amongst those who share our values and interests – their affiliation, advocacy and support is based on something much deeper than a fad or an individualistic need, it’s based on a desire to see all of this intellectual wikipedia-for-code value unleashed to support humanity at large, from developers to data centre devops to web designers to golden-years-ganderers, serving equally the poorest and the bankers who refuse to serve them, because that’s what free software and open content and open access and level playing fields are all about.

To those of you who rolled up your sleeves and filed bugs and wrote the documentation and made the posters or the cupcakes, thank you.

You’ll be as happy to read this comment on unity-design:

I’m very serious about loving the recent changes. I think I’m a fair representative of the elderly community ………. someone who doesn’t particularly care to learn new things, but just wants things to make sense. I think we’re there! Lance

You’ll be as delighted with the coverage of Ubuntu for Android at MWC in Barcelona last week:

“one of the more eye-catching concepts being showcased”v3
“sleeker, faster, potentially more disruptive” - IT Pro Portal
“you can also use all the features of Android” - The Inquirer
“I can easily see the time when I will be carrying only my smartphone” - UnwiredView
“everything it’s been claimed to be” - Engadget
“Efficiency, for the win!” - TechCrunch
“phones that become traditional desktops have the potential to benefit from the extra processing power” - GigaOM
“This, ladies and gentlemen, is the future of computing” - IntoMobile

Free software distils the smarts of those of us who care about computing, much like Wikipedia does. Today’s free software draws on the knowledge and expertise of hundreds of thousands of individuals, all over the world, all of whom helped to make this possible, just like Wikipedia. It’s only right that the benefits of that shared wisdom should accrue to everyone without charge, which is why contributing to Ubuntu is the best way to add leverage to the contributions made everywhere else, to ensure they have the biggest possible impact. It wouldn’t be right to have to pay to have a copy of Wikipedia on your desk at the office, and the same is true of the free software platform. The bits should be free, and the excellent commercial services optional. That’s what we do at Canonical and in the Ubuntu community, and that’s why we do it.

Engineers are human beings too!

We set out to refine the experience for people who use the desktop professionally, and at the same time, make it easier for the first-time user. That’s a very hard challenge. We’re not making Bob, we’re making a beautiful, easy to use LCARS ;-) . We measured the state of the art in 2008 and it stank on both fronts. When we measure Ubuntu today, based on how long it takes heavy users to do things, and a first-timer to get (a different set of) things done, 12.04 LTS blows 10.04 LTS right out of the water and compares favourably with both MacOS and Windows 7. Unity today is better for both hard-core developers and first-time users than 10.04 LTS was. Hugely better.

For software developers:

  • A richer set of keyboard bindings for rapid launching, switching and window management
  • Pervasive search results in faster launching for occasional apps
  • Far less chrome in the shell than any other desktop; it gets out of your way
  • Much more subtle heuristics to tell whether you want the launcher to reveal, and to hint it’s about to
  • Integrated search presents a faster path to find any given piece of content
  • Magic window borders and the resizing scrollbar make for easier window sizing despite razor-thin visual border
  • Full screen apps can include just the window title and indicators – full screen terminal with all the shell benefits

… and many more. In 12.04 LTS, multi-monitor use cases got a first round of treatment, we will continue to refine and improve that every six months now that the core is stable and effective. But the general commentary from professionals, and software developers in particular, is “wow”. In this last round we have focused testing on more advanced users and use cases, with user journeys that include many terminal windows, and there is a measurable step up in the effectiveness of Unity in those cases. Still rough edges to be sure, even in this 12.04 release (we are not going to be able to land locally-integrated menus in time, given the freeze dates and need for focus on bug fixes) but we will SRU key items and of course continue to polish it in 12.10 onwards. We are all developers, and we all use it all the time, so this is in our interests too.

For the adventurous, who really want to be on the cutting edge, the (totally optional) HUD is our first step to a totally new kind of UI for complex apps. We’re deconstructing the traditional UI, expressing goodness from the inside out. It’s going to be a rich vein of innovation and exploration, and the main beneficiaries will be those who use computers to create amazing things, whether it’s the kernel, or movies. Yes, we are moving beyond the desktop, but we are also innovating to make the desktop itself, better.

We care about efficiency, performance, quality, reliability. So do developers and engineers. We care about beauty and ease of use – turns out most engineers and developers care about that too. I’ve had lots of hard-core engineers tell me that they “love the challenges the design team sets”, because it’s hard to make easy software, and harder to make it pixel-perfect. And lots that have switched back to Ubuntu from the MacOS because devops on Ubuntu… rock.

The hard core Linux engineers can use… anything, really. Linus is probably equally comfortable with Linux-from-scratch as with Ubuntu. But his daughter Daniela needs something that works for human beings of all shapes, sizes, colours and interests. She’s in our audience. I hope she’d love Ubuntu if she tries it. She could certainly install it for herself while Dad isn’t watching ;) Linus and other kernel hackers are our audience too, of course, but they can help himself if things get stuck. We have to shoulder the responsibility for the other 99%. That’s a really, really hard challenge – for engineers and artists alike. But we’ve made huge progress. And doing so brings much deeper meaning to the contributions of all the brilliant people that make free software, everywhere.

Again, thanks to the Ubuntu community, 500 amazing people at Canonical, the contributors to all of the free software that makes it possible, and our users.

Read more
Charline Poirier

Every three months, I conduct benchmark usability testing.  I’m calling these tests ‘benchmark testing’ because the aim of these sessions is to measure our progress towards achieving a great user experience with Ubuntu.  Last testing took place in October 2011.  I am now preparing for testing 12.04 to take place a couple of weeks from now.

When I publish the results of usability testing, I get many questions about my process.  So I have thought that the best way to explain how I approach usability is to take you along the preparation and execution of my benchmark testing. Over the next month, I will take you, step by step through my process, from recruiting participants, to writing a test protocol to conducting and analysing usability sessions and writing up results.  This will afford you the possibility of ‘accompanying me’, so to speak, and of conducting usability in parallel, if you are so inclined.

For this post, I walk through the first stage of any testing: recruiting participants.


This is a crucial part of any successful and meaningful testing.  Some argue that just anyone you can get hold of will do.  This attitude, in my view, puts the software before the people who will use it, and carries the implicit assumption that software, by its very nature, is usable. But the simple fact, which we actually all realise, is that it isn’t. Take music players, for instance.  The challenge for this type of software is to fit into the lives of people who want to listen to music.  It doesn’t have to work well for those who don’t listen to music but who are, for instance, heavily into photo editing.  In a word, testing your software with your grandmother or your partner might not provide all the feedback you need to create a user-friendly product if they are not engaged in the activities your software is meant to facilitate.

So, the basic idea is:  in preparing the testing, recruit the right people. The type of participants you work with will determine the quality and reliability of the results you get.

There are some basic rules for writing a screener questionnaire.

Rule 1:  Recruit according to your testing goals

Is your goal to test, for instance, adoption: that is, are you going to assess how new users respond to your software the first time they encounter it and how delighted they are by it?  Alternatively, is your goal to test learning: do you want to assess how easily a novice can figure out how to use your software and how they progress over time? Or are you really interested in expert usage:  do you want to assess how performative your software is in a specific context of use involving expert tasks?  There are, of course, other scenarios as well.  The point here is that you need to be clear about your goal before you begin.

With Unity, we have 2 basic goals:  1) adoption:  we want to know how easy to use and attractive Unity is to someone who has not encountered it before; and 2) expert usage:  we want to know how performative Unity is with highly competent users who are fairly familiar with it.

Given these very different goals, I will need to conduct 2 different user testing sessions with different recruiting screeners or questionnaires, and different protocols.

In this blog, I concentrate on my first project, to test for adoption.

Rule 2:  Know your software

You need to review your software carefully:  you need to (1) identify the main purpose of the software and the activities or tasks that it is meant to facilitate; and (2) identify where you think potential usability weaknesses are.

When I prepare a usability test, and before I even think about recruiting participants, I spend a significant amount of time trying out the software, and even more time discussing with the designers and developers their own concerns.  From this evaluation of the usefulness and usability of the software, I’m able to sketch a profile of participants.  Bear in mind that, given my goals as set out above, the participants will need to be able to use the software right away even if they’ve never used Ubuntu, since I am not testing for learning.

Given what Unity aims to allow users to do, we need to confirm (or not) in the testing that Unity users can easily get set up for and can conduct at least the following activities:

  • writing, saving, printing documents
  • finding, opening applications
  • listening to music
  • watching a movie
  • managing and editing photos
  • customising their computer: organising icons and short-cuts and changing setting
  • browsing the internet
  • communicating

Additionally, the OS should make it easy for users to:

  • multi task
  • navigate and use special features like alt-tab
  • be aware of what’s going on with their computer
  • create short-cuts
  • understand icons, notifications and generally the visual language

In this instance, I want as well to test the new features we have designed since 11.10

Given my goals, my recruitment screener should be written in a way that will provide me with participants who engage in these activities on a regular basis.

Rule 3: Make sure you have an appropriate number of participants, with an appropriate range of expertise, with appropriately different experiences

I’ve often heard it said that all you need is a handful of participants – for example, 5 will do.  While this may be true for very specific testing, when your participants come from a homogeneous group (for example, cardiologists, for testing a piece of cardiology software), it is not true generally.  Much more often, software is meant to be used by a variety of people who have differing goals, and differing relevant experience and contexts of use.

You need to take these into account for 2 purposes: 1) to be able to test the usefulness and appropriateness of the software for different users; and 2) to be able to assess the reasons and origins of any usability problem that you find – these can be explained by comparing differences between users. A usability problem will have a different design solution if it is created by a user’s lack of expertise than if it is created by a shortcoming of the software that stumped all user groups.  It will also help rate the severity of the discovered problems.

Some of the factors a competent recruiting will take into account are:

Different levels of expertise: for example, in the case of software for photo-editing, you probably need to assess the ease of use for people who have been editing their photos for more than 5 years, and for those who have been editing for less than 1 year.  Expertise can be reflected in the length of time they have been engaged in the activity and also in the complexity of their activities.  You may want to recruit people who do basic editing, like eliminating red-eye; and then, to compare their use of your software to the use by people who do special effects, montages, presentations and the like.  This way, you get feedback on a wide range of the software’s features and functionalities.

Different kinds of uses:  potential users will have different needs and different potential uses for the software.  For example, if the software is healthcare related, it may well be used by doctors, nurses, radiologists – and sometimes even patients.  It is useful, when considering recruiting, to include participants from these various professions and other walks of life, so that you will be able to determine how well your software serves the range of needs, processes and work conditions represented by the likely (range of) users.

Different operating systems:  you may want to select participants who use, at least, Windows, Mac and Ubuntu. Users who are new to Ubuntu have acquired habits and expectations from using another OS. These habits and expectations become with time equated with ease of use for these users because of their familiarity.  Recruiting participants with different habits and expectations will help you to understand the impact of these expectations as well as receptivity to innovation.

Recruiting your participants with precision will allow you to understand the usability of your software in a complex and holistic way and will dictate more innovative and effective design solutions.

Keep in mind, however, that the more diverse the kinds of persons who you envisage will be primary users for the software are, the larger the number of participants you will need.  You should recruit at the very least 5 similar participants per group – for instance, in the healthcare example, at least 5 doctors, 5 nurses, and 5 patients.

A few more things to consider explicitly putting into your questionnaire/screener, particularly if you are writing it for a recruiting firm:

It is advisable to have a mix of male and female participants;

Participants from different age groups often have different experiences with technologies, and so you should include a good mix of ages;

The perceived level of comfort with a computer can also help the moderator understand the participant’s context of use.  A question about how participants assess themselves as computer users can very often be helpful;

You should always add a general open question to your screener to judge the degree of facility with which the potential participant expresses ideas and points of view.  The moderator is dependent on the participant to express, in a quite short amount of time, the immediate experience of using the software.  Consequently, being able to understand the participant quickly and precisely is vital to obtaining rich and reliable data.  The individual who makes the recruitment needs to be able to evaluate the communication proficiency of the potential participant.

Rule 4: Observe the basics of writing the recruitment screener

The most reliable way to obtain the desired participants is to get them to describe their behaviours rather than relying on their judgment when they respond to the screening questionnaire.  For example, if you want a participant who has a good experience in photography, instead of formulating your questions as:

Question:  Do you have extensive experience in photography?

Choice of answers:


You should formulate your question in a way to make sure the person has some level of familiarity with photography:

Question:  During the last 6 months I have taken:
Choice of answers:
between 20 and 50 photos a month [Recruit]
Less than 20 photos a month [Reject]

By matching potential participants to actual behaviours, you can make a reasonable guess, for example, here, that someone who has been taking 50 photos every months in the last 6 months is indeed competent in photography, whereas when you rely on the person’s own assessment that they have extensive experience, you can’t know for sure that they are using the same criteria as you do to evaluate themselves.

Your screener should be created from a succession of questions representing a reasonable measure of familiarity and competence with the tasks you will test in your software.

That said, your screener should not be too long, as the recruitment agency personnel will probably spend no more than 10 minutes to qualify candidates they are speaking with on the phone.  At the same time though, you need to ensure that you cover questions about all the key tasks that you will ask participants to perform during the test.

Summing up

Let me sum up the basics I’ve just covered by showing you the requirements I have in my screener for testing the ease of use of Unity by the general public user, not necessarily familiar with Ubuntu. They include that:

  1. there should be a mix of males and females;
  2. there should be a variety of ages;
  3. participants should not have participated in more than 5 market research efforts (because people who regularly participate in market research might not be as candid as others would be);
  4. there should be a mix of Windows, Mac and Ubuntu users;
  5. participants should:
    • have broadband at home (being an indicator of interest in and use of computer during personal time);
    • spend 10 hours or more per week on computer for personal reasons (which shows engagement with activities on computer);
    • be comfortable with the computer, or be a techy user;
    • use 2 monitors on a daily basis (I want to test our new multi-monitor design) to carry out a variety of activities online (part of the designs I want to test relate to managing documents, photos, music, and so forth and  I want my participants to be familiar with these activities already);
    • use alt-tab to navigate between applications and documents (another feature I intend to test for usability);
    • have a general interest in technologies (I want to make sure that their attitude towards new technologies is positive, so they are open naturally to our design);
    • express ideas and thoughts clearly.


In closing let me add that testing with friends and relatives is very difficult at many levels.  First, you can’t ask all the questions you need to:  there are many ‘common understandings’ that prevent the moderator from asking ‘basic/evident/challenging’ questions that might need to be asked to participants. Second, participants might not be sincere or candid about their experience:  someone who knows you and understands your commitment to the software might not express what they think, and they may not identify problems they are experiencing and thus, they might minimise the impact of a usability issue or even take the blame for it.  Third, of course, they might not fit as precisely as they should the recruitment screener.

Feel free to use this screener to recruit participants if you would like to conduct testing sessions along with the ones I will be doing at Canonical.

In a couple of days, I will write a blog post about writing the protocol for this round of testing  – which is the next step you’ll need to take while you’re waiting for participants to be recruited.

Read more
Calum Pringle

First of all, thank you all for your feedback in both the blog post and, most importantly, the survey. Over 2000 surveys were completed, which is amazing.

We are really quite overwhelmed with the encouraging feedback received at this stage, so I thought it worth sharing some of the highlights.


It almost spells out U-bun-tu.

It’s unique and modern, but has a feeling of community within it.

Its pleasant that it reflects the working of OS, smoother more user friendly

An idea of a future, dynamism and creativity

It has a “rich” quality that has generally been part of the Ubuntu soundscape.

It is unobtrusive and feels like it fits the old “humanity” as well as the new “light” theme.

It’s distinctive, playful, lively and yet restrained, soothing and modest.

This is great. What is even better is the quantity of constructive criticism that means we can start to iterate further samples and get closer to the sound.

The vote

It was very close, but the winner was sound number one. For reference, this chart shows the closeness of the averages from the scaled questions in the survey.

Remember however there were open ended questions too, so with this result and the positive feedback from the free form text questions, sound one became a clear winner.

As the results were close (as you can see particularly between numbers one and two) we will feed that back to our chosen sound designer to influence their next development.

Thanks for all your feedback!

For the next stage we intend to

  • make it more human, less synthesised
  • increase the warmth of tone
  • tighten the end note
  • lower the pitch
  • land the sound for 12.04!

Read more
John Lea

How is Unity designed?  How can I contribute to this process?  Why did you make thus and such decision? The Unity Design Team is frequently asked these questions, and this article aims to de-mystify our design process and highlight the different ways in which volunteer contributions can help improve the Ubuntu user experience.

Before diving into the design process, let’s take a look at the types of contributions Ubuntu receives.  Ubuntu contributions can be divided into two equally valuable categories: whole project contributions and piecemeal contributions.

Whole project contributions are autonomous projects created by a single developer or a group of community developers and designers working together.  One example of such a project is the excellent  Some user experience design tasks require frequent ongoing high bandwidth dialogue between design team members; this is easier to achieve when a small group of contributors take responsibility for the end to end delivery of a project.  Whole project contributions empower the project contributors to take complete control of all aspects of the user experience design.

Piecemeal contributions are contributions that help one individual aspect of a larger project.  Examples of piecemeal contributions include bug reports, small patches and suggestions on how to improve public design specifications.  Coordination is required to ensure that the piecemeal contributions fit together into a coherent whole.  Thus some of the user experience responsibility is ceded from individual piecemeal contributors to the project’s steering team.  In the case of the Ubuntu desktop, the design decisions are coordinated by the Unity Design Team.  In this environment, many elements are contributed by external designers and developers, but the areas of user experience design that require high bandwidth, frequent communication are dealt with by the Unity Design Team.


1. Divining the future

Before we get started on designing anything, we need a long term vision and strategy of where we want to be in several years time, and a high level roadmap of what we need to do in order to get there.  My personal take on the Ubuntu vision is that Ubuntu aims to “help humanity by creating a fully open source free software platform that becomes the platform of choice for all computing devices and form factors”.  By virtue of reading this article you are probably one of the small minority of the population who cares and feels passionately about the benefits of open source computing.  But when the majority of people consider buying or using a product, they make a decision based on cost, personal utility, and user experience.  ‘Open source’ versus ‘closed proprietary software’ doesn’t often come into the equation.  So if we are going to succeed in making Ubuntu the platform of choice for the world, one of the things we need to do is deliver a user experience that surpasses the standard set by our closed source proprietary software competitors.  And to do this we need a vision to aim for, of where the world is going to be in 2, 5, and 10 years time.

To help shape our strategy and roadmap we listen to what the brightest minds are saying by:

  • attending conferences
  • reading articles, blogs and forums
  • watching people’s behaviour
  • reading and watching sci-fi books and films
  • and trying to live observant, interesting lives… ;-)


How you can be a visionary and help shape the world

If you have a vision of the future or ideas about new ways of doing things, make yourself heard.  Everything from talks at conferences to ideas posted on are thrown into the Ubuntu mixing pot, so if you have a great idea, tell people about it.  The more time invested in exploring your idea and communicating it to the world the more influence it is likely to have; a paper presented by a PHD student who has spent a year exploring a particular topic has a better chance of being influential that one or two forum postings.


2. The first step in designing a feature; what problem are we trying to solve?

The development of a feature starts as soon as resource becomes available.  After selecting the next appropriate item from our roadmap, the first questions we ask are “what problem(s) are we trying to solve?” and “what are our objectives?”.  One useful tool to help define the problem is to explore the problem using user narratives, and think about the impact of the problem on different personas (user archetypes which represent patterns of behaviour and common goals).  Another useful tool is to undertake requirements capture with members of the target audience.


How you can contribute to defining the problems

If you are suggesting either a new feature or a change to existing functionality, first state the problems you are trying to fix.  This opens the door to exploring different possible solutions, and ultimately finding the optimal way to meet the requirement.  Including user narratives in bug reports/mailing list postings/etc… can open up productive discussions that explore different ways of tackling the problem.  They also make it easier for others to understand the problem you are investigating, and therefore improve the likelihood of a solution being built.


3. What thinking has already gone in to trying to solve this problem?

Once the problem that we are trying to solve is clearly defined, the next step is to assemble the previous thinking that has gone into the problem area.  Understanding what has gone before and the current state of the art is the starting point from which new connections can be made, concepts built upon and extended, and new ideas created.  Mailing lists, bug reports, and forums are scoured for pertinent information and products relevant to the problem space are examined.  In addition to the collation of previous thinking, fresh research can also be conducted to generate new insights.  This solid understanding of the existing problem space is a elemental ingredient of the design process.


How you can contribute to the background research

If a discussion on a design problem is taking place, either in your own project, in a bug report or on a mailing list, feel free to add pertinent information from related fields or descriptions of how others have tackled related problems.  Throwaway opinions are cheap, but considered  background research is a very valuable contribution.


4. Ideation

Ideation requires high bandwidth communication between all participants, both for the rapid expression and debate of ideas, and to ensure that everyone in the multi-disciplinary group rapidly gains and retains a shared understanding of the problem space.  When starting a new project at Canonical, we have found it very beneficial to get all the developers, visual designers, UX architects, etc… who will eventually work on the new feature together in a single physical location and spend a week brainstorming and exploring ideas.  In addition, these design exploration sessions help gel the feature team together, and the interpersonal bonds that are established improve team communication and set a positive tone of discourse that persists throughout the entire course of the project.

During these ideation sessions, we:

  • Spread out all gathered information and explore patterns and structures.
  • Jointly brainstorm and sketch ideas.
  • Discuss all areas of the problem space, propose and iterate multiple ideas for tackling all the different aspects of the problem.
  • Examine the problem from different angles; user costs and benefits, technical possibilities, strategic direction, competitive landscape, fit with roadmap, etc…

At the end of this stage we will have a collection of ideas for solving the problem.  And this collection of ideas will have been discussed and examined by the whole feature team.


How you can participate in ideation

At a small scale you can make piecemeal contributions to ideation by participating in bug report discussions and offering different ideas for solving the problem.  As a larger scale you can get involved in ideation by joining or starting a community project team that is focused on delivering a feature.  Propose an idea, gather some developers and designers together, and start your design process!


5. User Experience design

User Experience design starts with the ideas generated in ideation, and through an iterative process evolves the concepts and fleshes out the interaction details.  Typically a UX architect will take the lead on designing a feature, and as they work through this process they will continually bounce ideas off other members of the feature team and other designers.   User testing is also utilised to provide feedback and inform the evolution of the design.   The UX architect’s work will also be reviewed with the overall UX lead to ensure consistency and linkage with all the other projects that are being designed and developed in parallel.

User Experience architects have a number of tools at their disposal for designing and defining the functionality of a feature or product.   Multiple tools are used simultaneously in order to approach the design from different perspectives; for example wireframes show grouping and hierarchy of elements at a specific moment in time, so they are frequently combined with use cases or sequence diagrams to ensure that the user journey centric viewpoint is also considered.

For very tactile and interactive elements, designing through prototype iteration is an invaluable technique.  An example of this in action is the recently released launcher reveal prototype.   In addition to defining the functionality, user experience design also involves taxonomy, association mapping, and personas.


How you can participate in User Experience design

As user experience design builds on top of steps 1-4,  before starting the first task is to make sure these preparation steps are complete.  In the case of adding a piecemeal UX design contribution to a bug, this involves reviewing the bug discussion and satisfying yourself that these preparation steps have been adequately completed.  If you are working on a whole project, make sure that all the previous steps have been conducted jointly with the other members of the project team.

Then start designing!  Look at design patterns that can be utilised, and keep an open mind by looking at mobile and web patterns in addition to established desktop design patterns.  Some good starting points are ‘About Face 3: The Essentials of Interaction Design’ by Alan Cooper, ‘Designing Interfaces’ by Jenifer Tidwell and also the pttrns mobile app design pattern showcase.  Approach the design from different perspectives; to learn more about the mechanics of using use cases to take a user journey centric approach I recommend the excellent ‘Writing Effective Use Cases’ book by Alistar Cockburn.  And keep looking at the design through the eyes of the personas you are targeting, otherwise you may end up designing the product just for yourself!

The artifacts you produce will vary depending on the projects requirements, but should include at the very least elements of layout design (wireframing), functional design (use cases, prototypes, etc…) and Information Architecture (hierarchy maps).


6. Visual design

Visual design is the marrying of form and function, it affects user confidence and comfort and makes for a compelling experience.  As we work through each level of the design process, we are both iterating the design and adding further detail.  We start with coarse brushes making wide strokes and work our way to the point where we are using fine brushes to refine the final intricate attributes.  Human beings perceive visual information before they perceive analytical information, and Visual design is about reducing the mental workload for our audience whilst delivering a delightful and cohesive aesthetic experience.


How you can participate in Visual design

If you are working on a whole project contribution, fire up your design programs of choice and start iterating the visual design!  For piecemeal contributions a great place to start is theme, icon and wallpaper design.  For a good example of a great community visual design contribution take a look at the Faenza icon theme by ~tiheum.


7. Implementation

Development resource is the biggest bottleneck to getting new features implemented, so the most valuable way you can make piecemeal contributions is by taking items from the bug list and submitting patches.  Implementation is also part of the design process, because as a feature is built even more understanding is gained and further refinements are iterated.


How you can participate in implementing new features and fixes

Pick a bug from underneath either the “Design changes signed off but not handed over” header at or “Upstream projects that can be worked on” at .  If you have any questions about a bug ping either myself (JohnLea), swilson, or nuthinking in #unity-design on Freenode IRC .  The Ubuntu wiki Unity page is good place to start finding out more about how you can help with the implementation of Unity.


8. Identifying user facing bugs and QA

After a feature lands it is time to start identifying bugs.  A good starting point is to look at the UX specification of a feature, and check that the implementation matches design.  Where there is a divergence, citing the relevant part of the specification in the bug report is both useful and will also raise the bug’s priority.  On the other hand, designs are never perfect and it may be that there is a bug with the design itself.  In this case it is also useful to cite the issue in the relevant UX specification as part of the bug report.  Unity UX specifications are available at , and we are currently working to increase the number of specifications that are publicly available.  Also all the design bugs that are currently queued for implementation are publicly available at underneath the “Upstream projects that can be worked on” header at .


How you can participate by reporting bugs

If you are reporting a user facing bug affecting any part of Ubuntu, make sure the bug is marked as ‘also affects project’ ayatana-design.  The bug will then be triaged by the Unity design team, and if accepted it will enter the stack of bugs that are awaiting implementation.  Sometimes a bug will be marked as ‘Opinion’.   This means that the issue is acknowledged but the exact change request detailed in the bug is not currently scheduled for implementation.  This may be because further consideration is required, or because a project that will fix the bug in a different way is currently in the pipline.  Bug reports are one of the most useful ways you can contribute, every single bug that is reported to ayatana-design is reviewed by the Unity design team.


9. User testing

This will be coming soon in a subsequent article…

Read more
Stewart Wilson

We first posted a blog back in December about our work on the multi-monitor experience for Ubuntu. Back then we published the first revision of the Multiple Monitors UX Specification, and got some great feedback. We have taken comments, corrections and suggestions on board, and have come up with an updated multi-monitor specification. The specification can be found here:

There are several improvements to the specification (including more elegant discoverability of the Greeter login across displays, improved placement of windows upon removal of a display and a more feasible solution for providing missing resolutions in the Display Preferences panel).
The document has also been restructured in places, with new and extended sections, specifying in further detail how elements such as the Guest Session, Launcher, Spread and mouse cursor should work in a multi-monitor setup.

We have also created a prototype to explore how the Greeter works across multiple displays.

Multi-Monitor Greeter Prototype

Multi-Monitor Greeter Prototype

You can check out the prototype by downloading it from here:

Unzip the package and double-click the executable in the folder. You will need more than one display to check this prototype out. As you move your cursor across displays, the Greeter will follow the cursor, allowing you to easily log in on any display. The Greeter itself is not interactive, we are just exploring how it moves between displays. There are also a few keyboard controls to try out:

Press Escape to exit the prototype.

Press Space to check out the prototype against a number of different desktop backgrounds (will cycle through the images in /usr/share/backgrounds)

Hold down Alt to show numbers on each display. Still holding down Alt, you can then tap a number to move the Greeter across to that numbered display, allowing you to change the display you log in with, without using the mouse. In the final implementation, the Super key will be used rather than the Alt key, but I can’t bind to that keyboard shortcut in my prototype.

Please let us know your thoughts on the updated specification and the new Greeter prototype.

Read more
Inayaili León

If you’ve ever had to create Ubuntu or Canonical related design materials, chances are you had a look at the Brand Guidelines, which, until now, have only existed in the form of bulky PDFs. Those days are over, as we happily introduce the brand new Ubuntu Brand Guidelines site, where you can read the guidelines and download the assets necessary to create your projects.

Ubuntu Brand Guidelines homepage
Ubuntu Brand Guidelines homepage

You can learn more about the Ubuntu brand values and the brand assets, such as our logos, colour palette and pictograms, and how to use them. You can also consult some of our Web-specific guidelines, look at examples of design work that has been done, and download assets like the logos and pictograms.

Ubuntu Brand Guidelines - Brand assets section
Brand assets section on the Brand Guidelines site

This is the first iteration of the site: lots of content is being prepared and will be added later on, and we will also work on some refinements to the asset download process, as well as adding many more useful downloads, such as templates and photography.

Among the more frequently requested assets are HTML and CSS snippets and templates that can simply be copied and pasted on internal and external projects, so the designer or developer can be certain everything looks as it should. This is in the works, but it’s something that takes a little bit more time to get just right, so please bear with us.

For now, we’d be delighted to get your feedback on this first version: have you found anything particularly useful on the site? What would you like to see there that you think it’s missing? How do you think it can be improved?

We hope we enjoy the online Ubuntu Brand Guidelines!

Read more

The desktop remains central to our everyday work and play, despite all the excitement around tablets, TV’s and phones. So it’s exciting for us to innovate in the desktop too, especially when we find ways to enhance the experience of both heavy “power” users and casual users at the same time. The desktop will be with us for a long time, and for those of us who spend hours every day using a wide diversity of applications, here is some very good news: 12.04 LTS will include the first step in a major new approach to application interfaces.

This work grows out of observations of new and established / sophisticated users making extensive use of the broader set of capabilities in their applications. We noticed that both groups of users spent a lot of time, relatively speaking, navigating the menus of their applications, either to learn about the capabilities of the app, or to take a specific action. We were also conscious of the broader theme in Unity design of leading from user intent. And that set us on a course which led to today’s first public milestone on what we expect will  be a long, fruitful and exciting journey.

The menu has been a central part of the GUI since Xerox PARC invented ‘em in the 70′s. It’s the M in WIMP and has been there, essentially unchanged, for 30 years.

Screenshot of the original Macintosh desktop

The original Macintosh desktop, circa 1984, courtesy of Wikipedia

We can do much better!

Say hello to the Head-Up Display, or HUD, which will ultimately replace menus in Unity applications. Here’s what we hope you’ll see in 12.04 when you invoke the HUD from any standard Ubuntu app that supports the global menu:

HUD for 12.04

Snapshot of the HUD in Ubuntu 12.04

The intenterface – it maps your intent to the interface

This is the HUD. It’s a way for you to express your intent and have the application respond appropriately. We think of it as “beyond interface”, it’s the “intenterface”.  This concept of “intent-driven interface” has been a primary theme of our work in the Unity shell, with dash search as a first class experience pioneered in Unity. Now we are bringing the same vision to the application, in a way which is completely compatible with existing applications and menus.

The HUD concept has been the driver for all the work we’ve done in unifying menu systems across Gtk, Qt and other toolkit apps in the past two years. So far, that’s shown up as the global menu. In 12.04, it also gives us the first cut of the HUD.

Menus serve two purposes. They act as a standard way to invoke commands which are too infrequently used to warrant a dedicated piece of UI real-estate, like a toolbar button, and they serve as a map of the app’s functionality, almost like a table of contents that one can scan to get a feel for ‘what the app does’. It’s command invocation that we think can be improved upon, and that’s where we are focusing our design exploration.

As a means of invoking commands, menus have some advantages. They are always in the same place (top of the window or screen). They are organised in a way that’s quite easy to describe over the phone, or in a text book (“click the Edit->Preferences menu”), they are pretty fast to read since they are generally arranged in tight vertical columns. They also have some disadvantages: when they get nested, navigating the tree can become fragile. They require you to read a lot when you probably already know what you want. They are more difficult to use from the keyboard than they should be, since they generally require you to remember something special (hotkeys) or use a very limited subset of the keyboard (arrow navigation). They force developers to make often arbitrary choices about the menu tree (“should Preferences be in Edit or in Tools or in Options?”), and then they force users to make equally arbitrary effort to memorise and navigate that tree.

The HUD solves many of these issues, by connecting users directly to what they want. Check out the video, based on a current prototype. It’s a “vocabulary UI”, or VUI, and closer to the way users think. “I told the application to…” is common user paraphrasing for “I clicked the menu to…”. The tree is no longer important, what’s important is the efficiency of the match between what the user says, and the commands we offer up for invocation.

In 12.04 LTS, the HUD is a smart look-ahead search through the app and system (indicator) menus. The image is showing Inkscape, but of course it works everywhere the global menu works. No app modifications are needed to get this level of experience. And you don’t have to adopt the HUD immediately, it’s there if you want it, supplementing the existing menu mechanism.

It’s smart, because it can do things like fuzzy matching, and it can learn what you usually do so it can prioritise the things you use often. It covers the focused app (because that’s where you probably want to act) as well as system functionality; you can change IM state, or go offline in Skype, all through the HUD, without changing focus, because those apps all talk to the indicator system. When you’ve been using it for a little while it seems like it’s reading your mind, in a good way.

We’ll resurrect the  (boring) old ways of displaying the menu in 12.04, in the app and in the panel. In the past few releases of Ubuntu, we’ve actively diminished the visual presence of menus in anticipation of this landing. That proved controversial. In our defence, in user testing, every user finds the menu in the panel, every time, and it’s obviously a cleaner presentation of the interface. But hiding the menu before we had the replacement was overly aggressive. If the HUD lands in 12.04 LTS, we hope you’ll find yourself using the menu less and less, and be glad to have it hidden when you are not using it. You’ll definitely have that option, alongside more traditional menu styles.

Voice is the natural next step

Searching is fast and familiar, especially once we integrate voice recognition, gesture and touch. We want to make it easy to talk to any application, and for any application to respond to your voice. The full integration of voice into applications will take some time. We can start by mapping voice onto the existing menu structures of your apps. And it will only get better from there.

But even without voice input, the HUD is faster than mousing through a menu, and easier to use than hotkeys since you just have to know what you want, not remember a specific key combination. We can search through everything we know about the menu, including descriptive help text, so pretty soon you will be able to find a menu entry using only vaguely related text (imagine finding an entry called Preferences when you search for “settings”).

There is lots to discover, refine and implement. I have a feeling this will be a lot of fun in the next two years :-)

Even better for the power user

The results so far are rather interesting: power users say things like “every GUI app now feels as powerful as VIM”. EMACS users just grunt and… nevermind ;-) . Another comment was “it works so well that the rare occasions when it can’t read my mind are annoying!”. We’re doing a lot of user testing on heavy multitaskers, developers and all-day-at-the-workstation personas for Unity in 12.04, polishing off loose ends in the experience that frustrated some in this audience in 11.04-10. If that describes you, the results should be delightful. And the HUD should be particularly empowering.

Even casual users find typing faster than mousing. So while there are modes of interaction where it’s nice to sit back and drive around with the mouse, we observe people staying more engaged and more focused on their task when they can keep their hands on the keyboard all the time. Hotkeys are a sort of mental gymnastics, the HUD is a continuation of mental flow.

Ahead of the competition

There are other teams interested in a similar problem space. Perhaps the best-known new alternative to the traditional menu is Microsoft’s Ribbon. Introduced first as part of a series of changes called Fluent UX in Office, the ribbon is now making its way to a wider set of Windows components and applications. It looks like this:

Sample of Microsoft Ribbon

You can read about the ribbon from a supporter (like any UX change, it has its supporters and detractors ;-) ) and if you’ve used it yourself, you will have your own opinion about it. The ribbon is highly visual, making options and commands very visible. It is however also a hog of space (I’m told it can be minimised). Our goal in much of the Unity design has been to return screen real estate to the content with which the user is working; the HUD meets that goal by appearing only when invoked.

Instead of cluttering up the interface ALL the time, let’s clear out the chrome, and show users just what they want, when they want it.

Time will tell whether users prefer the ribbon, or the HUD, but we think it’s exciting enough to pursue and invest in, both in R&D and in supporting developers who want to take advantage of it.

Other relevant efforts include Enso and Ubiquity from the original Humanized team (hi Aza &co), then at Mozilla.

Our thinking is inspired by many works of science, art and entertainment; from Minority Report to Modern Warfare and Jef Raskin’s Humane Interface. We hope others will join us and accelerate the shift from pointy-clicky interfaces to natural and efficient ones.

Roadmap for the HUD

There’s still a lot of design and code still to do. For a start, we haven’t addressed the secondary aspect of the menu, as a visible map of the functionality in an app. That discoverability is of course entirely absent from the HUD; the old menu is still there for now, but we’d like to replace it altogether not just supplement it. And all the other patterns of interaction we expect in the HUD remain to be explored. Regardless, there is a great team working on this, including folk who understand Gtk and Qt such as Ted Gould, Ryan Lortie, Gord Allott and Aurelien Gateau, as well as designers Xi Zhu, Otto Greenslade, Oren Horev and John Lea. Thanks to all of them for getting this initial work to the point where we are confident it’s worthwhile for others to invest time in.

We’ll make sure it’s easy for developers working in any toolkit to take advantage of this and give their users a better experience. And we’ll promote the apps which do it best – it makes apps easier to use, it saves time and screen real-estate for users, and it creates a better impression of the free software platform when it’s done well.

From a code quality and testing perspective, even though we consider this first cut a prototype-grown-up, folk will be glad to see this:

Overall coverage rate:
   lines......: 87.1% (948 of 1089 lines)
   functions..: 97.7% (84 of 86 functions)
   branches...: 63.0% (407 of 646 branches)

Landing in 12.04  LTS is gated on more widespread testing.  You can of course try this out from a PPA or branch the code in Launchpad (you will need these two branches). Or dig deeper with blogs on the topic from Ted Gould, Olli Ries and Gord Allott. Welcome to 2012 everybody!

Read more
Iain Farrell

Precise Pangolin artwork

As developers all over the world sink their teeth into the new features for the next release of Ubuntu it’s time to get out our cameras, brushes and pencils out and start creating the images that will make up the wallpapers for the next release. 12.04 will be an LTS so the same super high quality that the teams delivering the desktop experience are working to should inspire us to make this the best wallpaper set we’ve released yet!

As usual there is a group on Flickr set up for your submissions – Precise Pangolin wallpaper submissions group. Simply upload your pictures to Flickr – accounts are free – and again as usual the contributors who were selected last time will be the ones asked to choose from the final selection of images. For guidance around what might make appropriate content, image resolutions to be used and the like check out the Ubuntu Artwork team wiki page on wallpapers.

You can see from the Pangolin Release Schedule that the development process is well under way so  we’ll be accepting entries until March 15th 18:00 UK time with a view to choosing the images and getting them into the release the following week as the Beta Freeze closes. Questions are welcome on my iain at ubuntu dot com address or on IRC in #ubuntu-design where you’ll find me, like-minded community members and Canonical’s designers.

So get snapping, sketching and painting! :)

View of Kinloch Rannoch in Scotland

Read more
Christian Giordano

Meeting Prezi

While we were sprinting in Budapest, we had the opportunity to meet the team responsible for such an interesting and inspiring product. We have in fact been lucky enough, thanks to some interesting connections, to be invited at Prezi’s! Of course this only after a hard day of work! ;)

Prezi is a presentation tool which will make your PowerPoint presentations look embarrassing.
The back-end of Prezi is unsurprisingly powered by Ubuntu but, regardless of what it is under the hood, Prezi deserves the spotlight in its own right.

We visited their offices with a delegation of designers and cloud engineers, not only to discuss our products, but also to exchange stories and ideas. We were welcomed very warmly with beers and pizzas in their office, which is, especially architecturally speaking, very inspiring (lots of indoor green).

Prezi is a web application and uses a zoom and pan metaphor to move from a slide to another, it basically produces a ZUI (Zoomable User Interface). This not only allows you to be more creative but gives your slides more “context”, making them part of a bigger picture.
While Prezi is not an open-source project as we know it, and still requires Flash Player, it encourages the sharing of your prezis source.
Some of the functionalities, e.g. the typography, can seem quite limiting but overall the editing is very straight forward and the result can be very, very, effective!

For the purpose of the meeting I quickly put together a prezi and shamefully showed it to the real experts!

This presentation is targeted at people who never heard about Ubuntu, taking advantage of our beautiful logo (font included).

.prezi-player { width: 550px; } .prezi-player-links { text-align: center; }

If you want to see what Prezi is capable of, have a look to this presentation their team put together:

.prezi-player { width: 550px; } .prezi-player-links { text-align: center; }

Internally we have other tools that we have to use for collaboration purposes, but it is clear that Prezi is definitely a powerful medium and, after having talked to the creators, I can guarantee you it will keep improving (and also moving to different platforms).

Read more
Stewart Wilson

For the multi-monitor design project, we have been making use of prototypes to develop and test some of the finer interactions of the system. One such crucial element is the reveal of the Launcher, particularly as we are exploring having a Launcher on each display. The motivation for making the Launcher available from any display is to allow the user to launch and switch applications, without having to travel onto another display to do so.

So, here is a prototype for the Launcher reveal, which we would like to share and get some feedback on.

Download the prototype application and source code

It is worth pointing out that this prototype concentrates on the detailed interactions for the Launcher reveal only. This is not the more fully featured multi-monitor prototype, mentioned in a previous post (first shown at the October 2011 USD), which will be shared a little further down the line.

Launcher Reveal Considerations

With a Launcher available on each display, we have chosen to hold the cursor briefly at the edge of any display which does not sit on the left-most edge of the extended desktop, allowing the user to push against the edge to reveal the Launcher. Important considerations here are:

  • The Launcher reveal must be reliable and easy to achieve when required
  • The Launcher reveal must not be too sensitive: there is already an issue with false positives for the reveal, when targeting items near the left edge of the screen (eg. the browser Back button)
  • The user should be able to pass quickly and easily onto the display to the left – they will not always be looking for a Launcher reveal.
  • Related to the previous point, if a user overshoots onto a display to the right (when targeting items such as scrollbars on the far right of a left-located display), it should be quick and easy for them to correct their position back onto the other display.

Running the Prototype

The prototype is a C++ Qt application. Download the archive and unpack it. You may be able to launch the application by just double-clicking on it. If this doesn’t work, you will need to launch the executable from the terminal. The steps are as follows:

  • Unpack the downloaded archive to a suitable location. In this example, we unpack onto the Desktop.
  • Open the LauncherReveal folder on the Desktop and try double-clicking the LauncherReveal executable to launch it.
  • If this doesn’t work, launch the Terminal application.
  • Type ‘cd Desktop/RevealLauncher’ to change to the directory which contains the executable (replace ‘Desktop’ with the directory you have unpacked the archive contents into if necessary)
  • Type ‘sudo ./LauncherReveal’ to launch the executable. To grant permission for the system to run the executable, you will then be prompted to enter your login password.

We have used quite a low-level language and framework for the prototype because it needs to create windows across multiple displays and to manipulate the position of the mouse cursor.

You can run the prototype on a PC with a single display, and try out the Launcher reveal. However, the prototype really becomes interesting when you run it with more than one display attached, and check out the Launcher reveal across all displays.

This prototype concentrates on the Launcher reveal only, so there are lots of things (windows, top bar) which do nothing. The prototype will only work properly for multiple displays with the same height, organised in a row. Being a prototype, this is essentially throw away code, which lives just to explore a very specific set of interactions, for a limited configuration of hardware.

In order to reveal the Launcher, you push the cursor into the left edge of a display for a fraction of a second (100ms by default). This works on any display (not just the far-left display), as we hold the cursor at the edge of a display when it crosses from either the left or right. Push a little more (a further 150ms by default) and the cursor will break through onto the next display.

The images of the browser window are used to test for false positives and overshooting problems when trying to target the Back button on the far left, and the vertical scrollbar on the far right.


Tuning the Parameters

You will notice a panel with lots of parameters to tweak. We have chosen defaults which work well for the small sample of people and hardware we have tested the prototype with so far – informal ad-hoc testing at this stage. Here is an explanation of each parameter and the trade-offs they represent:

Launcher reveal: push for 100 ms
The length of time the user must push against the left edge of the display to reveal the Launcher. For lower values, you get a more responsive-feeling Launcher, but you also get more unwanted reveals when targeting items on the left of the display (eg. the browser back button). Try tuning this value up to 200ms for less unwanted reveals, but you’ll need to push a little harder for those reveals that you want.

Pass display edge: push for 150 ms
Once the Launcher has revealed, we don’t want the cursor to break straight onto the next display, so we continue to hold the cursor for a little more time on a left-most edge. This gives the user the opportunity to stop pushing and move to target a Launcher icon. Lower values make it easier to move from one screen to another, but more likely that you will break though onto the next display when you wish to target something in the Launcher.

Event sampling period: 50 ms
The event sampling period is the size of the time-slices which are used to determine when the user has stopped pushing. A time-slice which collects no mouse events will result in an ‘end-of-push’ condition, cancelling a Launcher reveal or movement across a display edge. Lower values will increase the chances of an unwanted ‘end-of-push’ condition (for gentler pushes or older hardware). This period must be large enough to divide the previous time values into multiple time-slices, otherwise they just degrade into timer delays.

Cursor travels freely after crossing display edges for 1000ms
In order to allow the user to quickly correct an overshoot onto another display (when targeting items to the left or right extremities of a display), we temporarily drop the hold-at-edge behaviour once the cursor crosses an edge. Lower values give the user less time to make any corrections, but making this value too large results in missed edge-holds and Launcher reveals.

Cursor travels freely at velocities over 1000000 pixels/sec
In the prototype, we have prioritised easy, predictable Launcher reveals over travelling very quickly across the extended desktop. The user can still travel across the desktop fairly quickly, although they will be detained for a fraction of a second at any edges in the way. If you want to try out an alternative prioritisation (quick travel across the extended desktop, requiring a slower, more careful and deliberate targeting of the edge for a Launcher reveal), then drop this value down from the very high default value (which effectively disables this feature), to something in the region of 2000-5000 pixels/sec.

Hold cursor at right edge of displays (true)
We found that symmetric behaviour, with respect to holding the cursor on display edges, feels more natural, and also makes it easier to target items near the right edge of a display. However, this feature can be disabled, in order to evaluate whether less intervention on cursor movement might be preferable.

Show Launcher proximity shadow (true)
A shadow will appear at the left edge of a display to improve the discoverability and feedback for the Launcher. It grows out as the cursor approaches the edge, and then grows further still when the user pushes against the edge, providing feedback that the push is being recognised and the Launcher is about to reveal.


How It Works

You can check out how the prototype works by looking at the source code. If you know some C++ and Qt, you should hopefully be able to make some sense of it.

Fundamental to the interactions here, is the ability to determine when the user starts to push against an edge, and when they stop. We measure the duration of the push to see if we should reveal the Launcher or let the cursor through onto the next display. It is straightforward to determine when the push starts: we identify the first mouse move event which crosses a display edge. But how to determine when the push ends is more difficult. Jason Smith, on the DX team, came up with the neat solution of splitting the entire duration of the push into smaller time slices. For each time slice, we count the number of mouse move events coming in. As soon as a time slice expires which has collected no mouse events, then we have the end of our ‘push’.

Read more
Christian Giordano

System Settings for Precise

With Unity we have been trying to raise the bar innovating in the User Experience with new UI elements, such as Dash and Overlay Scrollbars. But this shouldn’t come at the cost of overlooking less exciting but essential core areas of the OS.

Last cycle we started thinking about how to improve System Settings, and in Precise we hope some of these improvements can start landing.

After examining the current panels and a number of interesting and useful discussions with GNOME upstream, we have defined a small but useful set of changes that we hope will add another level of refinement.

Besides the usual detailed tweaks to options + related widgets, there were other areas we looked at. These are:

  • layout consistency
  • Unity customisation options
  • simplified structure

Switch pattern consistency

With the introduction of the switch widget in GTK 3, and consequentially in GNOME System Settings, different layout patterns have emerged. However, unlike its use in mobile design patterns where it is aligned to the right of its label, in System Settings there were instances of it aligning to the bottom or left of its label.

Because this mobile pattern is here to stay, and it is also easily encapsulable (eg. in menus), made sense to bring consistency to its alignment. Also cognitively, the control should be “after” the label.

This is the result:

Where the description under the header is optional.

Simplified structure

While adding new options to some panels, also reported in some bugs, it became obvious that a bit of reordering was necessary. The biggest change has been the removal of the Screen Settings. Its options have been distributed across more panels.

Where to start

You can review all the details starting from this document. As usual, specs and code are meant to be fixed, so I would be very grateful if you could share your most constructive opinions! ;)

Read more
Stewart Wilson

Over the past few months we have been working on improving the multi-monitor experience in Ubuntu. We took the opportunity at UDS in November to get some feedback on a prototype, which shows how we are planning to develop the multi-monitor experience over the next few cycles:

Here is a short video of the prototype in action at UDS:

Multi-monitor prototype at UDS

We invested in a six monitor rig and the prototype to test a number of different display configurations and to ensure that our design ideas scale well. However, our main focus for Precise is to ensure that we deliver a reliable and supportive experience for the core use cases, such as connecting to a second display or projector, disconnecting displays and using a closed laptop with an external display.

So here is the Phase 1 specification, scoped for the next couple of cycles, incorporating the feedback we got from the prototype and sessions at UDS:

Work continues now on the prototype, which will be used to conduct usability testing on the launcher, spread, window management and workspace interactions for multiple monitor setups.  We will be publishing the prototype on this site (the Ubuntu prototype application, along with the Qt C++ source code) in the near future, so keep tuned for more Multiple Monitor news.

Read more
Paul Sladen

Ispravka ?irili?nog fonta «?» «? ? ? ?» «? ? ? ?»!
????? ?????? ??? «?»:

Amélie Bonet at Dalton Maag has drawn up redesigns for a number of the Cyrillic and Serbian/Balkans characters that weren’t as clear, or ideal as they could have been. If you use these characters, please help give feedback about whether the suggested improvements are sufficient, or whether they could be improved further. For Greek, there is also a proposed fix to monospace Gamma:

Many appreciations to those who reported the original bugs about the Ubuntu Font Family. We have tried to follow up to the original reports at Blog Russia and at (thank you to ????????? ???????? and also all those on the #ubuntu-rs IRC channel.

Please comment directly on the bug reports. You can use your own language if it is easier (eg. Russian, Serbian, English, Greek…). ??????? ???????!

Read more

Good to see the level of interest in a TV experience for Unity. From a weekly update Friday:

Earlier this week the guys in #ubuntu-tv (on Freenode) generated an Etherpad with their thoughts and then arranged a meeting to discuss priorities.  Alan Bell produced some designs:

The mailing list has seen some decent traffic as well, with people talking mostly about what the future of the Connected TV might be and features they’d like to see.

Thanks guys. The resulting list looks like this:
- 10′ interface- Watching Media (DVR, Live, Network(TV Guide is part of DVR/other services))- Control via remote controlHigh priority- Plugin support- Cloud and/or server storage (for home grown media)

- Playback of physical media (USB cd/dvd/bluray drive)

- Installable image

- Easy configuration of new devices (eg. installing same plugins, mounting same network shares)

- Ubuntu One Accounts

- Push media to/from other Ubuntu devices / Media syncing capabilities (Pause on one device, resume from same spot on another device)

- Collaborate with other Ubuntu devices (context: )

- Control from portable devices (phones/tablets/web interface/PC) (collaboration with Ubuntu Phone/Tablet?)

Medium priority

- Sharing media with friends (social network connectivity)

- Purchasing media through online stores (Ubuntu one/Amazon/Netflix)


Not a bad list at all. Thanks to tgm4883, MrChrisDruif, imnichol, callumsaunders1, dmj726 and others.

Separately, reports from a team that may have a crack at implementing the TV interface:

… tracked down some bugs in QML itself, fixed them, and are submitting patches upstream.  Next time you read that Qt Mobility now supports hardware accelerated video playback, or how the “ShaderEffectItem” now respects the “clip” property, or simply that the OpenGL video painter renders where it’s supposed to; you know who to thank.  As an added bonus this will benefit Unity-2D.  Awesome work.

Read more
Mika Meskanen

Big thanks to everyone who turned up at the Ubuntu Developer Summit in Orlando to discuss Ubuntu’s future on new devices!

Now, following Mark Shuttleworth’s keynote announcement and a number of initial UDS sessions on tablets, TVs and smartphones, we are setting up new channels to pick up the conversation.

We’ve got three new mailing lists for everyone to participate in. Just follow these links and sign up (click ”Join the team” on the right-hand side):

See also our previous post: Getting in touch with us

Read more