Canonical Voices

Posts tagged with 'usability'

Tingting Zhao

Understanding user behaviour through user research is an integral part of our design process. In the last website testing, some insights surfaced about user behaviour, which could help to shape a great user experience for our website. We share the three mains ones here. They have been much discussed in the UX, and the findings from the testing reinforced their importance.

Who were the participants?

12 participants took part in this research. They belonged to two different groups:

  • Ubuntu novices: those who have limited computer knowledge and had not heard of or used Ubuntu before. 8 participants were from this group. They were professionally recruited and of mixed genders.
  • Ubuntu users: those who use Ubuntu OS on a daily basis. They were from our Ubuntu users database pool and were recruited via emails.

What were the three main types of user behaviour found?

The Power of Images

“I go straight to the pictures before I go to the words. You look at pictures and they give you a flavour of what it is all about.”(P3)

” I use images to decide on a product. I tend to work very visually. Sometimes it is not easy to understand the jargon, and it is much easier to see what it is like. ” (P6)

“I’m just looking at the picture to see how much learning is required.” (P10)

In the testing process, we observed that participants appeared to rely on images heavily to help them form an opinion about Ubuntu. They used images in multiple ways throughout their interaction process, including:

  • To understand what the interface is about or make sense of an unfamiliar concept/feature
  • To decide whether or not it looks easy to use
  • To compare it with what they are currently using, and to see how much learning it may require

Images are therefore a powerful communication medium for us to build a positive brand with our users.

Take away:

It is important that images are relevant to their context and offer the best presentation of the product. We should use images to reflect the user friendliness and uniqueness of Ubuntu.

The Journey of Persuasion

“When I first came to your site, you need to tell me why I want to use this. This is paramount.” (P2)

“ It (the site) needs to highlight what I don’t know. Why I should use it, and with examples.” (P5)

When participants first landed on the homepage, they expressed their need to be informed about what Ubuntu does, who it is for, and why they should use it. They wanted to be convinced from the very start.

During the exploration process, when they were looking at Ubuntu pages, participants were attentive to the apparent benefits Ubuntu could offer to satisfy their personal needs. They relied on concrete examples and statistical figures to establish and enhance their understanding and trust. They also enjoyed browsing through different quotations from our users.

Take away:
The persuasion process should start from the moment users land on our homepage, until leaving the site. The key proposition messages should be specific, apparent and repeated throughout the user journey.

Make Use of Opportune Moments

“It says free upgrade for life, that’s good. Built in security, that’s good. Thousands of apps, that’s good too. I want to click on these to find out more.” (P3)

Our website has many good design features that grabbed participants’ attention straight away, for instance, the image tiles for ‘Reasons to love Ubuntu’ and the use of bullet points to outline essential information about Ubuntu’s main features. When participants encounter such design features or content that they found interesting, they often wanted to click an icon or topic to explore it further. They were disappointed or even frustrated if these were not clickable.

Take away:
We should make use of these opportune moments to keep users engaged and informed by providing efficient and desirable navigational paths to lead them to more detailed and relevant information.

What’s next ?

The web team has been carrying out changes in response to the user testing results. The aforementioned user behaviour findings will feed into the next web design cycle to help with the design decisions. This will help users to get even more out of their visits to

Read more
Jussi Pakkanen

We have all ran into software inconveniences. These are things that you can basically do but for some reason or another are unintuitive, hard or needlessly complex. When you air your concerns on these issues, sometimes they get fixed. At other times you get back a reply starting with “Well in general you may have a point, but …”.

The rest of the sentence is something along the lines of these examples:

“… you only have to do it once so it’s no big deal.”
“… there are cases where [e.g. autodetection] would not work so having the user [manually do task X] is the only way to be reliable.”
“… I don’t see any problem, in fact I like it the way it is.”
“… replacing [the horrible thing in question] with something better is too much work.”
“… fixing that would change things and change is bad.”
“… that is the established standard way of doing things.”
“… having a human being write that in is good, it means that the input is inspected.”

These are all fine and acceptable reasonings under certain circumstances. In fact, they are great! Let’s see what life would be like in a parallel universe where people had followed them slavishly.

Booting Linux: an adventure for the brave

You arrive to your work computer and turn it on. The LILO boot prompt comes up as usually. You type in the partition you want to boot from. This you must do every time because you might have changed partition settings and thus make LILO go out of sync. You type in your boot stanza sure in the knowledge that you get 100% rock solid boot every time.

Except when you have a typo in your boot command but a computer can’t work around that. And that happens only rarely anyways and why would you boot your computer more than once per month?

Once the kernel has loaded, you type in the kernel modules you need to use the machine. You also type in all extra parameters those modules require because some chipsets may work incorrectly sometimes (or so you have been told). So you type in some dozen strings of hexadecimal numbers and really enjoy it in a stockholmesque way.

Finally all the data is put in and the system will boot itself. Then it is time to type in your network settings. In this universe there is no Protocol to Configure network Host settings Dynamically. And why would there be? Any bug in such a system would render the entire network unusable. No, the only way to ensure that things work is to configure network settings by hand every time. Errors in settings cause only one machine to break, not the entire network. Unless you mix gateway/netmask/IP addresses but surely no-one is that stupid? And if they are, it’s their own damn fault! Having things fail spectacularly is GOOD because it shames people into doing the right thing.

After this and a couple of other simple things (each of which you only need to do once, remember) you finally have a working machine. You log on.

Into a text console, naturally. Not all people need X so it should not be started by default. Resources must be used judiciously after all.

But you only need to start X once per session so no biggie. Just like you only need to write in your monitor modeline once per X startup because autodetection might fail and cause HW failure. The modeline can not be stored in a file and used automatically because you might have plugged in a different monitor. Typing it in every time is the only way to be sure. Or would you rather die horribly in a fire caused by incorrect monitor parameters?

After all that is done you can finally fire up an XTerm to start working. But today you feel like increasing the font size a bit. This is about as simple as can get. XTerm stores a list of font sizes it will display in XResources. All you have to do is to edit them, shut down X and start it up again.

Easy as pie. And the best part: you only have to do this once.

Well, once every time you want to add new font sizes. But how often is that, really?


The examples listed above are but a small fraction of reality. If computer users had to do all “one time only” things, they would easily take the entire eight hour work day. The reason they don’t is that some developer Out There has followed this simple rule:

Almost every task that needs to be done “one time only” should, in fact, be done exactly zero times.


Read more
Jussi Pakkanen

Every day computer users do a variation of a simple task: selecting an element from a list of choices. Examples include installing packages with ‘apt-get install packagename’, launching an application from the Dash with its name, selecting your country from a list on web pages and so on.

The common thing in all these use cases is intolerance for errors. If you have just one typo in your text, the correct choice will not be found. The only way around is to erase the query and type it again from scratch. This is something that people have learned to do without thinking.

It’s not very good usability, though. If the user searches for, say, Firefox by typing “friefox” by accident, surely the computer should be able to detect what the user meant and offer that as an alternative.

The first user-facing program in Ubuntu to offer this kind of error tolerance was the HUD. It used the Levenshtein distance as a way of determining user intent. In computer science terminology this is called approximate string matching or, informally, fuzzy matching.

Once the HUD was deployed, the need to have this kind of error correction everywhere became apparent. Thus we sent out to create a library to make error tolerant matching easy to embed. This library is called libcolumbus.

Technical info

Libcolumbus has been designed with the following goals in mind:

  • it must be small
  • it must be fast
  • it must be easy to embed
  • it is optimized for online typing

The last of these means that you can do queries at any time, even if the user is still typing.

At the core of libcolumbus is the Levenshtein distance algorithm. It is a well known and established way of doing fuzzy matching. Implementations are used in lots of different places, ranging from heavy duty document retrieval engines such as Lucene and
Xapian all the way down to Bash command completion. There is even a library that does fuzzy regexp matching.

What sets Columbus apart from these are two things, both of which are well known and documented but less often used: a fast search implementation and custom errors.

The first feature is about performance. The fast Levenshtein implementation in libcolumbus is taken almost verbatim from this public domain implementation. The main speedup comes from using a trie to store the words instead of iterating over all items on every query. As a rough estimate, a brute force implementation can do 50-100 queries a second with a data set of 3000 words. The trie version can do 600 queries/second on a data set of 50000 words.

The second feature is about quality of results. It is best illustrated with an example. Suppose there are two items to choose from, “abc” and “abp”. If the user types “abo”, which one of these should be chosen? In the classical Levenshtein sense both of the choices are identical: they are one replace operation away from the query string.

However from a usability point of view “abp” is the correct answer, because the letter p is right next to the letter o and very far from the letter c. The user probably meant to hit the key o but just missed it slightly. Libcolumbus allows you to set custom errors for these
kinds of substitutions. If the standard substitution error is 100, one could set the error for substitution error for adjacent keys to a smaller value, say 20. This causes words with “simple typos” to be ranked higher automatically.

There are several other uses for custom errors:

  • diacritical characters such as ê, é and è can be mapped to have very small errors to each other
  • fuzzy number pad typing can be enabled by assigning mapping errors from the number to corresponding letters (e.g. ’3′ to ‘d’, ‘e’ and ‘f’) as well as adjacent letters (i.e. those on number keys ’2′ and ’6′)
  • spam can be detected by assigning low errors for letters and numbers that look similar, such as ’1′ -> ‘i’ and ’4′ -> ‘a’ to match ‘v14gr4′ to ‘viagra’

Libcolumbus contains sample implementations for all these except for the last one. It also allows setting insert and delete errors at the beginning and end of the match. When set to low values this makes the algorithm do a fuzzy substring search. The online matching discussed above is implemented with this. It allows the library to match the query term “fier” to “firefox” very fast.

Get the code

Our goal for the coming cycle is to enable error tolerant matching in as many locations as possible. Those developers who wish to try it on their application can get the source code here.

The library is implemented in C++0x. The recommended API to use is the C++ one. However since many applications can not link in C++ libraries, we also provide a plain C API. It is not as extensive as the C++ one, but we hope to provide full coverage there too.

The main thing to understand is the data model. Libcolumbus deals in terms of documents. A document consists of a (user provided) document ID and a named collection of texts. The ID field is guaranteed to be large enough to hold a pointer. Here’s an example of what a document could look like:

id: 42
  name: packagename
  description: This package does something.

Each line is a single word field name followed by the text it contains. A document can contain an arbitrary number of fields.  This is roughly analogous to what MongoDB uses. It should be noted that libcolumbus does not read any data files. The user needs to create document objects programmatically. The example above is just a visualisation.

When the documents are created and passed to the main matcher object for processing, the system is ready to be queried. The result of queries is a list of document IDs and corresponding relevancies. Relevancy is just a number whose meaning is roughly “bigger relevancy means better”. The exact values are arbitrary and may change even between queries. End-user applications usually don’t need to bother with them.

There is one thing to be mindful, though. The current implementation has a memory backend only. Its memory usage is moderate but it has not yet been thoroughly optimized. If your data set size is a few hundred unique words, you probably don’t have to care. A few thousand takes around 5 MB which may be a problem in low memory
devices. Tens of thousands of words take tens of megabytes which may be too much for many use cases. Both memory optimizations and a disk backend are planned but for now you might want to stick to smallish data sets.

Read more
Paul Sladen

Normally the Ubuntu/Canonical Design Team are busy working on our own projects, but it makes a really good change to work on other Free Software design problems for a change. Starting at 22:00 UTC (15:00 PDT) on Monday 7 May 2012, you can join us for the next Ubuntu Design Theatre at the Ubuntu Developer Summit in Oakland, California:

Bring your design issues along and lets see how we can improve them! There should be visual designers, user interface designers, brand designers, … and the many other people who try and work to make users’ lives better with Free Software.

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
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
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
Charline Poirier

Recently we hired an external consultant to compare the usability of 2 email clients: Thunderbird and Evolution. I have taken some highlights from the report to compose this blog.

Setting of the usability session

The sessions took place in early June at the Canonical Office in London. Thirty participants were recruited. All of them used at least 2 email clients.

One email account was set up in preparation for the sessions; all users were asked to use this account’s details to set up the email package. Days prior to the testing, messages were sent to this account and it was also subscribed to a mailing list, in order to ensure a realistic influx of emails to this Inbox.

Half of the participants interacted with Thunderbird and the other half with Evolution; Thunderbird 5.0 build 1 and Evolution 3.1.2 were used on a desktop machine using Ubuntu 11.10.

During each 60 minute session, participants were asked to:

  • set up the relevant email package for an existing account;
  • create a signature;
  • compose an email and change font colour;
  • manage emails in folders;
  • locate a specific email containing an attachment (sent prior to the session);
  • respond to an email containing an attachment and send the latter back to the sender;
  • create a contact list and send a message using contacts.

Highlights of Report

What Participants Liked


  • Straightforward and familiar set-up
  • One-click Add to Address Book feature in email preview and window
  • Window/message tabbing system
  • Familiar, intuitive language
  • Quick search that meets expectations


  • Useful guiding steps in mail configuration assistant
  • Intuitive contextual menu option to Add Contact in email preview and window
  • Menu items easily accessed as alternative to button shortcuts


  • Both were seen as having a familiar layout
  • Both met expectations in terms of generally intuitive access to contextual menus
  • Both provided intuitive access to search facility

Where Participants Struggled


  • Confusion over search use (severe)

Users were confused by the existence of two search fields, often opting for the All messages search box as they intuitively saw this as highest in the hierarchy. This choice often resulted in disappointment when users did not expect to be taken away from the folder they were searching in; in addition, they found the search results confusing and inefficient, reporting that they expected the item they were searching for to be more easily visible.

Participants were further frustrated by the fact that if they had misspelled an entry or their search returned no results, they would not be aware of this until taken to the search results tab, which they saw as a frustrating waste.

  • Difficulty locating and managing folders (severe)

The majority of participants successfully created folders, either by right-clicking in the folder area or using the New functionality in the top menu. However, most of these users were unable to easily locate the folder created or move once they had located it. This was due to them not realising they were creating subfolders; once subfolders had been created, unless that folder already had folders within it and it was expanded, users did not notice the expand icon next to the folder and bypassed it. Finally, once they found the created folder, users attempted to relocate them to the desired place; majority of users failed in doing this successfully.

  • Difficulty personalising message text (mild)

More than half of users struggled finding the function to change font colour; the majority looked for this in the message text toolbar, bypassing the colour functionality because they expected the icon to look differently. Users eventually found this with the use of tooltips, but not after looking through all toolbar and top menu options first. Participants voiced the issue for this to be the icon being in black and therefore too subtle; they mentioned preferring a more colourful icon or one resembling a palette.

  • Unclear server options (mild)

Participants reported liking the apparent ease of setting up but most were confused by the server options provided in the second, and final, step. About half reported that they would navigate away from the window and research more into their options, with the rest either ignoring this message and go with the IMAP option already selected or choosing the POP option which caused them some issues finding emails later on. The majority of users reported preferring helpful information and guidance on the options provided in the set-up screen, in order to avoid navigating away or uncertainty.

  • Difficulty finding and personalising signature (mild)

The majority of participants were unsure where to find the signature functionality, with the majority expecting it to be either in the main toolbar, message toolbar or Message menu section. Most participants were unable to find this feature on their own without looking up help or reporting that they would ask a friend for help.


  • Longwinded, unexpected set-up (severe)

Despite appreciating the guiding steps outlined in the mail configuration assistant, the majority of participants reported feeling that this process was unexpectedly too long and found the options provided very technical and confusing. For the majority of users, this culminated just at the second step, where they thought they were being asked to retrieve backed-up files, rather than being offered option to set up this feature. Some users failed at this point, reporting that they were confused by this and would revert to using the current email set-up they had.

  • Locating account email (severe)

The majority of participants had difficulty initially locating account email due to the email folders displaying an Inbox and an account-specific email section. Most participants did not notice that the account email area was collapsed and were confused about the ‘Inbox’ shown at the top of the folder list not showing any messages. Users attempted to view the account Inbox by selecting Send/Receive and then clicking through all folders available. Eventually users noticed the email account folder with the expand icon next to it and accessed the account folders that way. This experience caused great alarm in these users, particularly as it was at the beginning of interaction with the system; as a result, many reported loss of trust in the package and considering ending its use.

  • Unintuitive message search (severe)

As discussed, search was intuitively used by participants to quickly find a required message in a large Inbox. Many participants failed finding the required search results because they carried out a search unaware that they had selected an irrelevant folder. This resulted in no results being returned and users being confused because they had expected to be able to search all folders.

  • Once email opened, difficulty getting back to Inbox (severe)

Half of participants naturally double-clicked to read email in more detail; however, in Evolution, this resulted in email opening up over the main Inbox window, hiding the email list. Participants were confused by this and struggled to get back to the message list; majority reported looking for a button or link to Inbox and were extremely weary of closing the window down (either via the buttons or menu items) because they were nervous about potentially closing down the entire email application.

  • Inability to personalise email text (severe)

Almost all participants were unable to personalise message text in Evolution; they expected access to font colour to be available along with the other font toolbar options and entirely bypassed the HTML option. One participant selected HTML and still missed the font colour option. Participants were very disappointed by the lack of this feature and looked at all toolbar and top menu options for access to this.

  • Despite long set-up, confusion over lack of password request (mild)

In addition to finding the Evolution email set-up longwinded, participants were confused why this had not asked them for account password details. The majority saw this as a frustrating time waster, particularly as they were asked for this separately, once their email had been set up.

  • Difficulty locating and managing folders (mild)

As with Thunderbird, the majority of participants successfully created folders, but here mainly by using the Folder functionality in the top menu. All participants expected to be able to create a folder by right-clicking in the folder area and only a few right-clicked on a folder to look for this functionality. Despite being able to create the folders using the top menu, users were disappointed with the lack of quicker access to this feature in the folder area (either by right-clicking or with the use of a button) or a button in one of the top toolbars.

Usability Issues Common to Both

  • Difficulty finding and personalising signature (mild)

As with Thunderbird, the majority of participants were unsure where to find the signature functionality, with the majority expecting it to be either in the main toolbar, message toolbar or Message menu section. When users found the Signature option in the message toolbar, they were very frustrated that this did not provide a shortcut to signature creation. Most participants were unable to find this feature on their own without looking up help or reporting that they would ask a friend for help.

When they were taken to the signature feature, users were again frustrated at the fact they could not find a font editing facility, despite the interface looking like it should allow for this.


As discussed, users gave both positive and negative feedback on their interactions with Thunderbird and Evolution, with Thunderbird consistently being perceived by users as easier to use and fit for purpose than Evolution.

Thunderbird was widely liked for the perceived straightforward set-up and facilitated access to contact save, search and open windows features. In addition, users commented on the familiar language used in the application.

However, participants encountered a few severe issues which tarred their image of the system. These consisted of extreme, at time show stopping, difficulty with:

  • successfully understanding and choosing the relevant search field to use;
  • locating and managing the preferred location of folders.

Finally, these users encountered some lack of clarity over server options in set-up and frustration at the inability to easily format email text.

Participants who interacted with Evolution liked the guiding steps in the mail configuration assistance, the intuitive contextual mention options to add contacts and the ability to easily access alternatives to button shortcuts in the menu.

Users reported multiple severe issues around the Evolution set-up, locating account email, message search use, formatting email text and navigating back to the Inbox. All of these issues were so major that users encountering them reported lack of trust in the Evolution package and a reluctance to continue its use.

One major fact to keep in mind is that, especially as the majority of participants were new to Ubuntu, they saw the email application they used as a representative of the operating system. This is particularly pertinent to the email system that is a system default and it should be ensured that, before either one of these products is chosen for this purpose, the severe issues reported here are addressed.

Read more
Charline Poirier

First and last impressions of Unity were that it was quite user-friendly, and pleasing in its design and ease of learning. The majority of participants left the session with very positive feelings and were looking forward to Unity’s release so they could download it. In short, participants in this testing session were considerably more positive about Unity than participants who tested the previous version in October.

This improvement, no doubt, is due to the significant changes we have made since the last testing, often in response to problems uncovered during that testing. Many of the serious issues discovered then have been resolved. Most significant, as it stands now, there are no longer any “show-stoppers”.

However, there are still a few interactions that were at odds with the product’s general ease of use.

Some important points to keep in mind

First, it appears that those of our participants who were Mac users seemed to have had more facility with the Unity interface than Windows users, especially those using anything previous to Windows 7. Generally, Windows users tended to rely on right click, and they sought menus from which they could find and launch applications as well as move and delete. They did not immediately take advantage of Unity’s visual assets. Accordingly, Windows users will need to be encouraged to manipulate icons and to develop a more physical relationship with Unity than the more text-heavy relationship they have with Windows.

Second, Unity’s concept of ‘Home’ (Nautilus file manager) is different for that of our users, even Mac users, and they did not immediately understand it. They had a tendency to go to the ‘Home’ icon, not only to find information about their computer, but for any programme or application they were looking for. Essentially, many navigated from one application to another using ‘Home’. For example, almost every participant first looked into ‘Home’ to find computer settings and to change their wallpaper.

Third, most participants were not able to figure out how to reveal the Launcher from the upper left corner. They immediately devised work-arounds, like closing windows or moving a window away from the left edge of the screen. They expected to be able to reveal the Launcher by approaching any point along the left side with their pointer. As the Launcher is one of the most important features of Unity, it should be either always visible or at least very easy to bring out.

Fourth, the Dash is hard to discover. The icon is too small and understated compared to the icons in the Launcher. By its size and placement, it is easily associated with the window management buttons. Participants who discovered the Dash found it very useful, but were more inclined to use Files and Applications Lenses at the bottom of the Launcher. This was, I’m convinced, partly due to the fact that there were no data, pictures, music or documents on the computer that they would want to access through the Dash at the time of the testing, whereas the Applications Lens, in early use, is more adapted to general exploration. The Dash needs to be more visible — it needs to be accorded its rightful place as a major feature of the interface.

Notwithstanding these small problems, it is fair to say that this test showed that we have made significant progress since the October testing.

Some Major Issues that Have Been Resolved since October

Visibility of icons at the bottom of the Launcher

During the April testing, participants experienced difficulty seeing the bottom of the Launcher when it was accordioned and then, when the Launcher expanded, it hid the bottom icons.  At the time of the testing, it was very difficult to reveal these bottom icons even by scrolling down. Recent updates have resolved this problem by making the Launcher automatically scroll down when users move the pointer down along it.  This way, the icons that were previously hidden are effortlessly revealed.

A related issue that has also been resolved is that, during testing, participants wanted to make the Launcher visible by touching any part of the left side border – whereas, in fact, the only way to reveal the Launcher was by reaching with the pointer to the upper left corner. With the updated version, users can now reveal the Launcher from any point on the left side of the screen.

Changing the order of icons in Launcher

During the October testing, when the interaction to move an icon in the Launcher was to select it and bring it outside of the Launcher before giving it a new position, many participants failed to do it.  The new interaction supports users’ natural way of moving an icon:  participants were able to move icons in the Launcher by selecting them and moving them vertically up and down.  It should also be noticed that the feedback provided when users select an icon they intend to move helps them understand that they have initiated an action.  Knowing that the icon has effectively been selected afforded them more freedom to move the icon around and to find a way to make it work.

Adding icons to the Launcher

Participants were able, even during the October testing, to drag and drop the icon of an application from the Applications Lens into the Launcher.  However, their first attempt, especially for Windows users, was to right click on the icon they intended to move and expect to be offered an option to attach to the Launcher in a drop down menu; and second, to look at the top of the Launcher for a ‘Launcher  menu’.

Identifying running applications

Most participants were able to see immediately which applications were running by means of the white arrows beside the icon in the Launcher.  However, they were not sure if they had made the right inference.  In short, although participants were unsure about the meaning of the white arrows and bars, they were able to figure them out which indicates that this is a feature easy to learn.

Changing the wallpaper

Most participants easily changed the wallpaper by right clicking on the desktop.

Deleting a document

Most participants easily deleted a document.

Detailed Summary of Benchmarking – Comparison of the October and April Test Results

The points above are the highlights of the findings. Let us now examine individually the differences in performance as revealed in the testing of last October and the one just completed in April.


October report:  “The level of performance in this regard significantly impaired the flow of use and the user experience.”
April testing:  Unity was quick and responsive.
Outcome:  This is fixed.

Multi-tasking: Having many items opened and accessing them

October report: “Thus, while working on a task, participants expected that Unity would provide them with a representation or visibility of what was available to them and how to easily access what they needed at any given point.”
April testing: No problems were observed with overlapping open applications and documents. Participants could easily move individual windows and reveal items placed underneath.
Outcome:  This is fixed.

General navigation

October report: “Overall, participants found the navigation to be cumbersome.”
April testing: Participants used Nautilus to find applications and documents as well as system settings. This is not, however, the most efficient way to do this.
The Files and Applications Lenses icons need to be more prominent in the Launcher.  However, participants found it easy to go from one document or window to another and to make them all visible to them.
Outcome:  In a recent update, the icon ‘Home’ (Nautilus) has been renamed ‘File Manager’ and the icon has been modified to downplay the home relationship.  This should help users recognise its role and lead them to look for an alternative place for system settings and other programmes and applications.

Minimising a window

October report:  “When participants minimised a document, the document seemed to have disappeared when they expected it to be shown at the bottom of the screen.”

April testing:  A few participants still expected to see a trace of their minimised document at the bottom of their screen.
Outcome:  Since the usability sessions this interaction has been updated to show the window minimised into its Launcher icon even when the Launcher is hidden.  This should help users to locate their minimised documents and windows.

Awareness of running applications

October report:  “Participants did not always see the white arrows that indicate a programme is running or documents are opened. Consequently, they were not aware of what was available to them.”
April testing:  Almost all our participants were able to tell which applications were running by looking at the white arrows. However, some were not sure at first and needed to ‘try it out’.  So they opened and closed windows and applications to check on the behaviour of the icon in the Launcher.
Outcome:  The white arrows seem to be working well once they have been discovered.  Although they are not obvious, users can figure them out.  This is easily learnable.

Displaying documents side by side

October report:  “No participant could find a way to resize his/her openoffice documents in such a way that they could be placed side by side while working on both at the same time.”
April testing:  Except for one, all participants were able to display two documents side by side. However,  as noted above, they were not able to discover the semi-maximised state.
Outcome:  The original problem is fixed.  In the new design of Unity, participants have a way to display their documents side by side and to work on them simultaneously.  The semi-maximised state is not readily discoverable.  Unfortunately, users are not yet taking full advantage of what Unity offers.

Overview of computer

October report:  “Many participants wished they could have an overview of what resides in various parts of their computer, as is facilitated by Windows’ ‘my computer’.”
April Testing:  This is still a problem. Participants in the April sessions were still looking for a place where they could do systems setting and have an overview of their computer.
Outcome:  None of the participants discovered the ‘system settings’ option in the top right indicators menu. Users need an icon either in the Launcher or in the indicator area, or a folder in Nautilus.

  • Bug #764744 (“Add system setting icon to Launcher”)

Delete a document

October report: “Participants could not delete existing documents from their files and folders. “
April testing:  Everyone was able to delete a document that was no longer wanted.
Outcome:  This is fixed. One remaining problem is that many participants cannot see the Rubbish Bin at the bottom of the Launcher.  They used other ways to delete, like pressing the delete key.

  • Bug #764751 (“Launcher – when Launcher contained folded icons, partcipants weren’t able to find the rubbish bin”)

Copy and paste

October report: “Copy and paste from one document to another didn’t always work for participants.”
April testing:  Everyone was able to copy and paste from one document to another.
Outcome:  This is fixed.

Lack of feedback

October report: “Unity is often slow, and as a result participants tended to be confused about what was going on.”
April testing:  Overall, and as noted earlier, the performance of Unity was much better and the system responded more readily to users’ commands. Some issues remain with feedback, however, for example, with the Rubbish Bin.  Participants wanted to be alerted, either with sound or a message that their document had been moved to the Bin.
Outcome:  Confirmative feedback is necessary whenever users complete an action, like deleting a file.

  • Bug #750311 (“Launcher – When a item is deleted by dragging to Trash, the trash should pulse once before the Launcher disappears”)

Nautilus search

October report: “When searching, participants didn’t know what the field and scope were that were covered by the search engine they were using.”
April testing
: Many participants searched for applications successfully. However, there are still problems with search. Participants made inappropriate searches, for instance in Nautilus, searching for Sudoku (search that pertained to Applications Lens) and they did not get the results they expected.
Outcome:  This is partially fixed.  Some issues with search are related to participants’ understanding of the structure of Unity. There should be some guidance hinting at the limitation of the search and thus, the kind of results that can be expected from the various search boxes in the various parts of Unity.

Adding an icon to Launcher

October report:  “Many participants were not able to add a short-cut of an application to the Launcher.”
April testing:  Most participants were able, this time, to add an icon to the Launcher. Windows users, however, had more difficulties than the others did; they tended to look for options in various menus or right clicking on the icon.
Outcome:  This is partially fixed.  The interaction is quite intuitive but, some users (particularly those using earlier versions of Windows) will require more guidance.

Reordering icons in Launcher

October report: “Most participants failed to reorganise the order of icons in the Launcher.“
April testing:  A few participants experienced some difficulty reordering icons in the Launcher because they did not have sufficient feedback to understand when the icon had actually been selected so that they could proceed vertically.  Consequently, they tried to move the icon too quickly after clicking on it and the icon did not respond.
Outcome:  This has been fixed in the latest update by providing feedback on selection – the interaction shows the icon as if it was detached from the Launcher – and by allowing users to move the icons vertically within the Launcher.

Finding the Dash

October report:  “The majority of participants who found the Dash found it by accident. They were not sure what it was, and didn’t know how they had gotten there if they accidentally had.”
April testing:  Participants still cannot readily find the Dash.
Outcome:  The Dash needs to be made more visible and promoted as a major feature of Unity, on a par at least with the icons of the Launcher.

  • Bug #764771 (“The BFB is visually lost and his position does not communicate its importance”)

Ubuntu Software Centre

The same features of the Software Centre were not tested this time because everyone agrees on its need for redesign and its existing usability problems. Nevertheless, some issues emerged in the course of testing other interactions.
April testing:  The Software Centre is still not recognized and, during testing, was mistaken for ‘systems control’.
Outcome:  The Software Centre needs to have a different look and feel and general presentation. Needs redesign.

Changing the wallpaper

October report:  “Many participants did not succeed in changing their wallpaper because the default screen of appearance was open in full screen by default.”
April testing
:  Almost all participants were able to change the wallpaper by right clicking on the desktop. Furthermore, one participant who was able to find ‘appearance’ had no problem changing the wallpaper because now, the screen opens in a way to provide visibility of the background.  The October usability problem was thus, fixed.  However, a new problem emerged.

In the April test, the target feature was, in fact, the ease of use of the Applications Lens by means of changing the wallpaper. Most participants were not able to change the wallpaper by finding ‘Appearance’ in the Applications Lens.  They were looking for ‘system settings’ to do that operation.
Outcome: The initial problem with the appearance screen covering up the immediate change of wallpaper and so, hiding the change from users, has been resolved.  Now, by default, the appearance screen does not open full screen.  In the April test, however, users could not find their ’system settings’, where they expected to make these changes.  Furthermore,  many participants did not think of system settings as an application and, thus, were not confident to find it in the Applications Lens.  Unity needs to provide obvious access to ‘system setting’ and make a distinction in the Application Lens between applications and other programmes.

Visibility of Files and Folders and Applications Lenses and  Rubbish Bin

October report:  “Participants thought that the grey icons at the bottom of the Launcher were inactive.”
April testing: These icons still have issues of visibility, especially when they are folded at the bottom. For example, most participants did not find the Rubbish Bin.  Another usability problem that arose from interacting with the Launcher is that some participants found it difficult to interact with the bottom part of the Launcher.  They found that it was ‘a long way to go’ to the Rubbish Bin or the Lenses when the Launcher was populated with many icons.
Outcome:  These icons still need more visibility. Changing the colour, and perhaps even changing their position in the Launcher, might help.

  • Bug #764751 (“Launcher – when Launcher contained folded icons, partcipants weren’t able to find the rubbish bin”)

Some Usability Issues that Have Arisen from Some of Our New Design

Top Menu Bar

The top menu bar is actually a new design.  There was some confusion about the role of the top menu bar: Participants wondered if it pertained to ‘the computer’ or to the application they had open at the time. When participants had many windows opened, they did not understand that the bar corresponded to the selected window.

System Settings

During testing, I encouraged participants to change their wallpaper in another way than by right clicking on the desktop to see if they could find ‘appearance’ in the Applications Lens.  Finding system settings programmes in the Applications Lens is not intuitive. Most participants did not succeed in changing the wallpaper by going into the Applications Lens. They were looking for a ’system settings’ icon in the Launcher or somewhere in the ‘Home’ at the top of the Launcher.  Those who went into the Applications Lens, did not expect to see ‘system settings’ in that area because they did not think of system settings as applications and accordingly they did not explore.  No one discovered the ‘system settings’ option in the drop down menu under the ‘turn off’ icon in the indicators menu bar.

Notification of message

This is also a new feature since the October testing.  The majority of participants did not see the notification that they had received a message. The change in colour of the icon was not noticed.  However, some noticed the change in the icon in the Launcher, in this case the Xchat, and they induced, by looking at the number that appeared on the icon, that they had received a message.  However, when the Launcher is invisible, participants were not aware that they had a message.

This said, a couple of participants saw the notification and the change in colour of the envelop in the notification area.  They had a strong positive impression of the feature.  It seems that in this case, it might be a question of making the change in the notification area more prominent.

Semi-maximised state

Again, semi-maximised state is another new feature.  Semi-maximised state is not readily discoverable. Only one participant discovered it. This participant was a Windows 7 user and said that there is the same feature in Windows 7. Two other participants interpreted the blue preview shadow as signalling that they were about to make a mistake or to do something not allowed by the system. The preview shadow was interpreted as a warning.  Users need both guidance and reassurance here.

We are doing better with the user’s experience and our users are closer to adoption

Overall, participants left with a strong positive impression of Unity after having tried it for 60 minutes.  Some of their closing comments:

“I like the layout and the screen (…) I want to customise it myself quite easily. It would be good to have a tutorial. (…) I like minimise and the fact that you can move things around. I like the casual font, aesthetically, it looks nice and it is easy to use. Nothing is really difficult. The important things are there and easy to use. It is nice.” [P1]
“The reason it was annoying today is because it is a new package. I like the design and layout. Design is important to me. It is quite clear. (…) “I would like more time to play around with it. It’s Ubuntu, I haven’t used it. This is new, the way I learn is by playing with it. (..) It’s good to use something that is a bit more independent. I like the idea that we can do things rather than being locked down in something more siloed like Windows or Mac. I would like to get it.” [P2]
“I prefer this set up to the start menu. I like the icons. We are a generation to see things with icons. I think there is a lot of significant gesture, like saving documents and I would not have any problem doing these activities. I really like the dragging format. I like to be able to order what I want. I think it is much easier than Windows. With Windows you have to go down menus. (…) I don’t think it’s complicated but it would take some time [to get use to it]. I’ve been working it out in an hour. It’s very user friendly. Even within the hour, I’ve learned a lot about how to do different things.” [P3]
“I really quite like it. I think it’s intuitive with the exception of the favourites, making an application a favourite. I would not be baffled to use it without a manual. I like the look of the desktop. It is modern. It looks like a Mac more than Windows. It’s quick.” [P5]
[About the Software Centre] “I didn’t anticipate to have access that easily to new apps. Also, I like the rating on the side. It’s quite helpful, I can see what I can trust. That’s quite nice.” [P5]
“It’s OK. Quite intuitive but I was going from what I know from Windows. I use the right click a lot, it’s nice to have it on the side. Generally this looks pretty good. It’s a bit more intuitive, for me, though, the right click is vital. It always brings up a good menu.” [P9]
“I think it’s very pretty, very pleasing as it were.” [P11]
“It’s quick and responsive. It’s very responsive, different from what I use, it would take a day or two to get acquainted. I wouldn’t be discouraged. I would rather spend time than pay money.” [P12]

In the summary of their experience post usability testing, participants also highlighted their main difficulties. It is meaningful that, at the end of the session, the following first came to mind:

“I don’t like the dragging in Launcher up and down. I mean I didn’t realise at first this is what I needed to do. It’s difficult to get to the Bin. It’s not easy to get to the top from the Bin, it is hard to drag things down a long way. I don’t like the dropping down.” [P1]
“My frustrations: I would like to know how to change the settings, I expect a button to change wallpaper clicking on a button right at the top. (…) The menu at the top bugged me.” [P2]
“I didn’t like when I have things minimised. There are many things I can’t do without maximising the screen.” [P3]
“It is hard to delete a file in this way. (…) You don’t find the menu bar and you don’t know what’s open.” [P4]
“I don’t know how to make the Launcher visible [when a window is opened]. I’m struggling a bit. This window [Dash] has a tendency to disappear.” [P5]
“I hated the Files and Folders, I didn’t know what it would do when I click on it, if it will open or just let me select it. I wasn’t able to select a document.” [P8]
[About the wallpaper] “I couldn’t find it. I wouldn’t have thought of it as an application for some reason.” [P10]
“I suppose my main thing is what I expected to have in terms of applications and control panel. I couldn’t find it. If I could have found this at the beginning life would have been a lot simple. I feel like I feel with Apple, I feel a bit stupid because I can’t do the things I normally do with my PC. I like things in words a lot, I like the drop down menu. This is interesting because this is generally shown with an icon.” [P11]
“I’m frustrated that I can’t find something like ‘my computer’. I want to find information about ‘my computer’ and what the hardware is, the driver versions, and I want to know if there are updates on Explorer. Here you need to go into ‘control panel’ to see if there are any updates. I still can’t figure it out.” [P12]

You  can also download a PDF of the full report by clicking on this link.

Read more
Matthew Paul Thomas

That’s it, we’re quitting

The “Quit” command in applications today is a relic from the days when the original Macintosh had no hard disk and couldn’t multitask. Modern applications have made this command increasingly annoying. Fortunately, though, modern PCs have also made it increasingly unnecessary. Mobile operating systems have, for the most part, eliminated the “Quit” command completely. In Ubuntu, the messaging and sound menus will help us do the same.

A compromise that got out of hand

It’s easy to forget just how much more powerful personal computers are today, compared with the machines on which some of our user interface conventions began.

In 1983, the Apple Lisa had a 5 megahertz processor, 1 megabyte of memory and two floppy drives — but failed largely because it was too expensive and slow. So the first Macintosh in 1984 instead used an 8 megahertz processor, only 128 kilobytes — kilobytes! — of memory, and one 400 KB floppy drive.

Implementing a multi-application graphical user interface on that original Macintosh required many design tradeoffs. Most importantly, while the Lisa could multitask, the Macintosh just didn’t have enough memory. Except for a few small accessories, only one application could run at a time.

This raised an interesting problem. If you had an application open, and you closed the only document you had open in that application, what should happen? To open a document belonging to a different application, you’d need to go back to the file manager (which was the main application launcher back then), and that would require unloading the application. But if the next document you wanted belonged to the same application, unloading and then reloading that application (from a floppy disk, remember) would be an annoying wait.

So, the Mac designers made two decisions. First, they introduced a way to open a file within the same application, without going back to the file manager: the Open File dialog. And second, they required users to specify manually when an application should remove itself from memory to make way for another one — by invoking a “Quit” command.

This was a reasonable, if awkward, compromise. As the years went by, though, something weird happened. The Amiga copied both these ideas, and then so did Windows, and OS/2, and KDE, and Gnome, and many other environments — even though they could all multitask and (except for early Amigas) used hard disks. It was a classic case of cargo-culting.

To be fair, Open dialogs eventually became more efficient than file managers for the specific task of opening files. But “Quit” (which Windows called “Exit”) became less and less relevant. Mac OS X moved the “Quit” menu item from the “File” menu into the junk drawer that is the application menu. But quitting has remained a basic part of how Mac applications present themselves, and it has persisted for many applications in Windows and Ubuntu as well.

A few behemoth applications, such as LibreOffice and Gimp, still keep “Quit” separate from “Close” for the original reason — to save you from having to wait for the application to relaunch after closing its only document. But that is fixable, and all other applications have become fast enough that they don’t need it any more. After all, they’re running on hardware that is hundreds of times faster than it was in 1984.

People who have been using computers for a long time sometimes get a sense of reassurance from the idea of controlling application unloading themselves. Meanwhile, though, the presence of “Quit” has been getting confusing and even a bit destructive.

The problems with “Quit”

Most obviously, there is a problem with Web browsers. First, people have gotten more comfortable with the idea of having multiple Web sites open at the same time. Second, Web applications have become more common and more stateful. And third, since 2003, Web browsers have competed partly on how minimalist their interfaces can be — which has made the browsers less and less obvious as applications themselves.

As a result, the effect of “Quit” in a browser is now bizarre. For example, imagine that you have windows open for Amazon, Banshee, Calculator, eBay, Empathy, Facebook, Gmail, and Shotwell. What happens if you choose “Quit” in the Gmail window? Gmail quits, but Amazon, eBay, and Facebook quit too, while Banshee, Calculator, Empathy, and Shotwell stay open. How much sense does that make? Not much.

Browser designers have tried various hacks to lessen this problem. Some browsers ignore the standard Ctrl Q keyboard shortcut for “Quit”, because of the damage it can cause. Some put up a confirmation alert, asking you if you’re sure you want to quit. And some offer, in that confirmation alert, to remember your windows and tabs for next time you launch the browser.

The existence of a confirmation alert is a fairly reliable clue that the original design is broken. And that’s true in this case: none of those workarounds make it obvious, ahead of time, which of your applications are about to disappear. And even if a browser restores all the pages you had open, usually it has still lost any work you were doing in those pages. In Ubuntu, the Epiphany browser avoids the problem much more simply: by not having a “Quit” command at all.

It’s not just Web browsers, though. The same problem exists in any application that has windows for apparently distinct tasks.

For example, if you have a presentation open in KPresenter, and a spreadsheet open in KSpread, and you choose “Quit” in KSpread, the spreadsheet closes. But if you have the same presentation open in LibreOffice Impress, and the same spreadsheet open in LibreOffice Calc, and you chose “Exit” in Impress, the presentation closes, and — surprise! — the spreadsheet closes too. How much sense does that make? None whatsoever.

KPresenter and KSpread are coded as separate applications, so they quit separately. LibreOffice Impress and Calc happen to be coded as a single application, so they quit together. But why should you have to know that engineering detail? On 21st-century computers, it’s irrelevant.

Finally, “Quit” is confusing for any application that can do useful things in the background without windows open. A long-standing example is the file manager, which typically controls the desktop as long as you are logged in, and so doesn’t have a “Quit” function. A more recent example is the Mac App Store, which — like Ubuntu Software Center before it — continues downloading and installing applications when its window is closed. Surprisingly, though, the Mac App Store continues downloading and installing applications even after you “Quit” it. In Ubuntu Software Center we avoided that weirdness by not having a “Quit” command in the first place.

In other cases, though, the behavior needs to be more flexible. You might, or might not, want to be notified of new e-mail messages when your mail client isn’t open. You might, or might not, want to receive incoming chat messages or calls when your IM client isn’t open. And you might, or might not, want to keep playing music even when the music player isn’t open. In these applications there is at least a useful distinction between “Close” and “Quit”. Unfortunately, the result is that “Quit” is being used to mean several quite different and non-obvious things: “don’t check for messages any more”, “go offline”, “stop music playback”, and so on. A single term probably isn’t a good presentation for all these things.

In summary, then, “Quit” is more confusing than useful. For many applications, it can be either removed altogether, or changed to the more straightforward “Close” if that item isn’t present already. But for applications that run configurable things in the background, the design is a little more complex. Fortunately in Ubuntu, we have some elements waiting to help out: the messaging menu, the me menu, and the sound menu. (It’s almost like we’ve been planning it.)


Since Ubuntu 10.04, Ubuntu has had a messaging menu, which shows incoming messages from humans, as received by any application that integrates with it. (It’s been great to see Thunderbird integrating with the messaging menu, for example.) Ubuntu also has a “me” menu, which — among other things — lets you set instant messaging status, for any IM or VoIP application that integrates with it. It’s possible the structure of these menus will change in the future. But the basic idea will stay the same.

One awkward detail has been that if you have used the me menu to go offline for instant messaging, you can’t use it to go online again. Last week, Ken VanDine fixed that problem — which means that for any IM application that integrates with the menu, it’s no longer necessary for it to have a “Quit” item. If you want to go offline, you can do that from the global menu. And if you want to close the program’s contact list, you can do that without affecting your online status. The functions will no longer need to be tied to each other in unpredictable ways — they will be completely independent.

For e-mail and similar messaging clients, things are a little trickier. At the moment, these applications typically stop checking for messages when their window is closed. However, many people apparently want these functions to be independent too — as shown by the variety of separate mail notifiers available in Ubuntu.

The engineering solution here is for messaging clients to split out the code that checks for new messages, so that it can optionally run even while the rest of the application is not. Gwibber already does this, for example.


There are two main kinds of media player application. For standalone players like Totem and VLC, which mainly play individual files, the behavior when you close the window is fairly straightforward: the media should stop playing, just like a game or Web page would.

For jukebox-like players like Rhythmbox and Banshee, though, what should happen when you close their window has long been a source of debate. With Ubuntu’s sound menu, we have a chance to resolve it clearly.

The basic design principle of the sound menu is that in a multi-window environment, it’s reasonable to want to control a jukebox-type player quickly without its window being open, and that a menu is a good way to present that. Again, it’s possible that the exact presentation will change in future, but the basic idea will stay the same. We’re delighted that thanks to the Mpris standard, Amarok, Banshee, Clementine, Exaile, MPD, Rhythmbox, Spotify, Symphony, and Xnoise will all integrate with the sound menu in Ubuntu 11.04.

Having a separate quick-access interface reinforces the basic idea that whether a jukebox window is open, and whether music is playing, are completely independent things. You can close the jukebox window without interrupting playback. And you can start or stop playback without opening a window.

Implementing that much has been easy enough for our friends working on Banshee, for example. But it introduces a new issue: If you want to start music playing from the sound menu, you can’t be expected to know or care whether the player is already running. So in Ubuntu 11.04, the sound menu will show the Play button even for registered players that aren’t running. If you choose Play, the player will launch and then start playing.

If a player takes a while to launch — because it scans a database of media each time it launches, for example — making this a smooth experience will be a challenge. There are several possible solutions, though, depending on the player. For example, it could remember which track it was playing when it was last running, and postpone any database scanning if it has been launched for the express purpose of playing a particular track. Or it could even keep running in the background for a couple minutes after you stop playback with no windows open, just in case you’re going to start playback again.

Always be closing

Phone and tablet operating systems, such as Android and iOS, have abolished the ideas of “quitting” or even “closing” applications altogether. In Ubuntu, running on screens large enough (and with pointing devices precise enough) for multiple windows, “Close” remains a very useful idea. But with a little effort, we can reduce frustration and simplify Ubuntu overall, by making “Quit” something that humans no longer have to think about. Let’s stop being quitters, and start being closers.

Read more
Charline Poirier


I have just completed sessions of usability testing of Thunderbird.

This time, I had the pleasure of working with Andreas Nilsson, who came to London to observe the sessions. It was very useful to get his feedback and to work collaboratively with him on the analysis and implications of the findings. In addition to these benefits of our work together, there is an added one: since he observed participants struggling with certain aspects of the interface, he will no doubt be a very effective user experience advocate with his team.

Andreas, thanks for your time!

The Test

Twelve participants were recruited from the general public – one turned out to be a no-show. They represented a mix of gender and age. Special consideration was given to heavy email users. Of the 11 participants, 5 were exclusively Windows users, 3 were exclusively Mac users, and 3 used both Windows and Mac.

In preparation for the sessions, we set up 2 test email accounts. A few days prior to the sessions, I sent messages to these accounts and also subscribed them to mailing lists. When participants signed up, they had already received a sizable quantity of emails, allowing us to ask them to manage the messages the way they generally do in their own email boxes, to find specific messages, to create filters, and more.

Thunderbird was tested on Maverick and Unity.

Between sessions, Thunderbird was removed and all hidden files were deleted, so the next participant got to start from scratch.

The Methodology

Over the 60 minutes of each session, I went through as many features of Thunderbird as possible with each participant. Participants were asked to:

  • Install Thunderbird from the Software Centre
  • Create an account
  • Sign up
  • Create filters
  • Set up alerts
  • Manage emails in folders
  • Create a signature
  • Change the colour of the font
  • Create a contact list
  • Search for a specific email discussing a form (which I had sent prior to the session)
  • Respond to an email that contained an attachment: in particular, open the attachment, modify it and send it back to the original sender

What participants liked

There were many aspects of Thunderbird that participants enjoyed, and many tasks at which they succeeded.

Participants commented positively on the tab system, which makes the navigation between messages easy and immediate, and which provides visibility on multitasking. The tagging of messages also got positive evaluation. Many participants commented on the simplicity and usefulness of the contacts. Filtering was perceived as effective, although, as we will see below, the majority of participants experienced some challenges here.

Participants found the activities which they carry out most often – opening, reading, responding to and deleting emails – easy and straightforward.

Where the trouble is

Critical issues

Participants encountered few critical usability issues – by ‘critical’, I mean issues that would make it difficult or even impossible to use the application on a regular basis. These issues need to be addressed if we are not to lose users to alternative products.


After installation from the Ubuntu Software Centre, participants could not find Thunderbird to start using it. They did not see, in the product description, the bread crumb indicating the location of the download when provided.

Observation: After having installed a new application, users generally are excited about using their new software. The user experience would flow much better if, as the process of installation ends, the application opens automatically in the main window, allowing users to deal with their settings and messages right away. We need to keep users excited about Thunderbird. As it stands, it is a bit of a let down to not be able to find the new toy!

Create folders

One of the main challenges for participants was managing their many emails by creating folders.

Most participants did manage to create a folder by right clicking on the folder area. However, they could not find the folder once they’ve created it, and so couldn’t drop messages into it. This was because they had in fact not created a ‘folder’ (as promised by the menu label) but a ’sub-folder’. The sub-folder was not visible, because it was hidden under a folder.

Those participants who did eventually find the sub-folder they had created wanted to make it into a folder, but were not able to do so. Users normally organise their folders in a way that facilitates their use of emails. They tried to drag their sub-folder out of the parent folder and relocate it.

There are 4 main folders they want visible: inbox, sent, junk and draft. It is worth noting that the ’sent’ folder in Thunderbird is a sub-folder of gmail; this was confusing to participants. As a case in point, several participants failed at checking if a message they had sent me had really been sent because they couldn’t find the ’sent’ folder at all.

Participants also expressed a preference for ordering their folders. In addition to the point mentioned just above, some indicated that they like to create a work folder and a personal folder. They place these folders next to each other. They were not able to do this in Thunderbird.

Observations: Users manage their mailbox by customising folders. The level of customisation they need goes beyond creating and naming sub-folders. They want to create their own hierarchy of folders and sub-folders as well as to order them for convenience and visibility.

One more thing on this topic: participants were not clear about some of the words used to describe folders. For example, they did not know the difference between a ‘folder’ and a ‘local folder’.

Create filters

Most participants failed at creating a filter.

First, they didn’t know where to look to set filters up. Most participants looked under preferences and account settings. After looking generally at the menus they gave up.

Second, participants were unsure of the meaning of the dialogue boxes and of what was expected of them. They found the process of setting a filter unduly complex and they needed more feedback to measure their progress.

After participants managed to create a filter in the filter rules dialogue box, they clicked OK but didn’t know if the filter was actually set up or not. Additionally, they couldn’t figure out how to run a filter they had created. The issue was that, once having created a filter, when participants came back to the message filters dialogue box, the last filter set up is not selected – thus the run now option is not enabled. At the same time the enabled check-box is selected indicating that the item has been selected.

Observation: After setting up a filter, users would like to run it to confirm that it works. Make the command ‘run now’ the next step in the process without users having to specifically select the filter to run it.

Find open and modify an attachment

None of our participants was able immediately to find the attachment in a message. They expected the attachment to be visible at the top of the message. While most participants eventually found the attachment, some didn’t, and consequently could not open and modify it.

When participants did not find the attachment, they consulted help, but were not provided correct information.

After some participants found the attachment, I asked them to edit it. They did not expect that the attachment would be in a read-only mode and tried to edit it without saving it first. The message warning them that the document is read-only only appeared after many attempts. It would have been friendlier for the message to be shown at the first attempt.

A few participants, after they attached a document, were not clear if the document was in fact attached to the message. They needed a stronger visual cue.

Observation: Sending, finding and reading attachments are fundamental activities on email. The user experience would be greatly improved if the attachments were located where users expect them, at the top of a message and/or if they would be more visible by changing the appearance of the link or using a colourful icon. Additionally, users would benefit from some immediate feedback on ‘read only’ documents as well as from a confirmation that a document has been successfully attached to an email.

In this case, for Thunderbird to be user-friendly, it would need to anticipate users’ needs, mainly need for visibility and for feedback at the first occurrence of an error. This anticipation of users’ needs would show the willingness of Thunderbird to collaborate with its users and to recognize their goals.


Participants were unclear about the differences between the 2 search boxes at the top left of the screen.

Often they didn’t get results because the global search bar doesn’t suggest anything other than names.

Search doesn’t take into account misspellings – and so, when a word was misspelled, participants got no results.

Every time a participant performed a search, a tab opened automatically even if the search provided no results. As a result, participants opened many tabs that were not useful or wanted. They found that the tabs cluttered the interface and made it difficult to find such things as the inbox.

Observation: Users should know, before searching, what the fields will be actually searching. The area dedicated to filters is interpreted as a search and not a filter by participants. In part, the issue for users is that the boxes look virtually identical, and thus, from their point of view, should be interchangeable. A different visual treatment would greatly improve the usability of the different search boxes.

Less-than-critical issues

Participants also highlighted usability issues that were not critical, but that compromised their enjoyment of Thunderbird.

Mail account setup

Participants did not understand the message contained in the mail account setup dialogue box. They had to make a choice between:
IMAP – Access folders and messages from multiple computers
POP – Download all messages onto this computer, folders are local only

Uniformly, they did not understand the implications of this choice and went for the ‘recommended option’ – just because it was recommended. Most participants said that they would not read the message anyway and would just accept and move onto the next screen.

One participant chose the POP option, which caused her problems with search later.

In addition, the mail setup message has a button that says “create account”. This was confusing for some participants who thought they had already created an account and now were in doubt. Some wanted to go back to the signup page to check. There is no way to come back to the signup page, however.

Observation: While users are setting up their account, they are most eager to get the process over with. This is in part, because they want to see the application but also because they need to see what they will get, so to speak, before they can understand the pertinence of the various options proposed to them. In this case, it is good practice to make a recommendation – which simplifies the process. However, the choice should be clear, from the user needs perspective (so users don’t just choose what is recommended because it is simpler and don’t foresee the consequences of their choice).

Set up alerts

2 participants expected to be able to set up alerts in tools, but were not able to. Many participants were not able to find a way to set up alerts at all.

Create a signature

The majority of participants expected to be able to create a signature under ‘composition’. When that failed, they looked under tools, add-ons, preferences, insert and write. Most who wanted to did not succeed at creating a signature.

Some minor issues

‘Minor’ usability issues don’t compromise the main usage of an application or the integrity of the user experience. However, they can be annoying and irritating, particularly when the application is used on a regular basis.

Change the colour of the font of their message

Most participants either failed at changing the colour of the font for all their messages or were not sure they had succeeded after selecting a colour from the palette of ‘display’ in ‘preferences’.

In part, participants could not find the option to change colours. For those who found it, when they selected a new colour, the new selection was not reflected in the messages they wrote just afterwards. But also, after they selected a different colour, they were not sure if the chosen colour would appear in their message.

Observation: Many users like to personalise their communication. Playing with colours and lay-outs should be easier for them, with relevant options more visible. In addition, users need some feedback that their change will be immediately implemented. An ‘apply’ button or a confirmation that the new selection has been registered would reassure them.

Navigational issues

Participants did not know how to get back to their inboxes from either the address book or the ‘write’ screen. They didn’t understand that in these specific cases new windows were opened, instead of tabs, and that they needed to close them to go back to their in-boxes.

And more…

Participants had further suggestions for new features. They wished for:

  • A calendar on the side so they can see messages and their commitments at the same time
  • A way to compress large files directly from the email account
  • Some social networking, at least so that they could see that their friends are online

Read more
Daniel Foré

Hey Ubuntu One and Design fans! This is my first post here, and I have to say I feel priveledged to be able to write to you all. Recently I’ve been working with the Ubuntu One team on the desktop syncing apps, and trying to give them some special attention. I feel like these apps have the potential to be such an important part of not only the Ubuntu experience, but also the experience of users who may not have converted over to Ubuntu yet. As such, these are some of my personal motivations for my design work on Ubuntu One:

1. Make a good first impression

Ubuntu One has a great opportunity (as a cross-platform application and service) to be a bit of an evangelist for Ubuntu. Just like iTunes and Safari have been evangelists for the Mac experience on Windows, the Ubuntu One desktop app should introduce people to all the best things about Ubuntu. I want users under Windows to see and experience this amazing application and be hungry for more. I want them asking how to get more of our software on their computers. And with that, have an expectation that all the software we ship is going to be better than what they’re used to. Which is why I think it’s important that we…

2. Set a good example

Ubuntu One is one of only a couple of applications that users will see that was actually built from the ground up by Canonical. In this way, it should set a good example for others to follow. If we can’t provide applications with great design, we can’t expect our partners and community to. It has been said by Mahatma Gandhi that, “When the people lead, the leaders will follow.” In this way, I want to set a positive example with this small part of the desktop that every other application is going to be envious of and strive to acheive. This leads right into my next goal:

3. Offer a Superior experience

Above all, Ubuntu One should (as all of our work should) offer a superior experience simply for the intrinsic value of making our users happy. The Ubuntu One team firmly believes that the best way to attract more users and developers is to build something so great that people naturally want to be a part of it. As we heard from MPT (in his now quite infamous talk at UDS Natty), Ubuntu needs to be Useable and Keepable. That means providing a specific kind of desktop experience. Not only one that “gets the job done”, but one that people are going to prefer over any other available experience.

With those things in mind, let’s make this rock ;)

Read more
Charline Poirier

??’Appropriation’ – the taking of a product and using it for one’s own purposes, in ways unintended by the product creators – is implicitly at the core of the philosophy of opensource, because openness provides for change, adaptation and innovation.

Design specifications

Last year, I conducted several research projects to understand how developers work and how we can add design and a concern for user experience to their already very complex efforts.  I’ve published some of the results already, for example, those coming out of our study of Empathy.

One of my inquiries asked how developers use design specifications.  This research produced very rich results.  We realized that developers’ approaches to our design specifications documents varied quite a bit, and often the documents were not made as central to the developers’ work as we had anticipated.  So far, we’ve been able to characterize four different ways in which developers use our documents.  These illustrate tendencies and not necessarily rigid approaches.  Yet, they help us understand developers’ frame of mind when they deal with design information.

1) Some developers read meticulously specifications and try to figure out what the designer had in mind. These developers like to work closely and collaboratively with individual designers.

2) Some developers have a more organic approach to understanding specifications. They use them in combination with current conversations on chat networks about development topics and issues, and with other conversations that have taken place during past strategic meetings at UDS.  They essentially make the written specifications a second resource in favor of what their colleagues and managers say about them.  They fit the specifications in a dynamic broader context.

3) Yet other developers almost only look at screen representations of the specifications. They try to duplicate the visual guide that accompanies the specifications or simply to compare existing features of an application to the screen shots included in the document, trying to discern similarities and differences between them. Many of them use specifications documents as a simple reminder of past and current discussions and to get a general idea of what’s expected of them.

4) Finally, another group uses the “try and see” method. These developers implement changes as they see fit and rely on their colleagues to provide guidance once the development has been realized. Effectively, they hardly consider the written design specifications at all but like to follow their intuition.

Research, of course, doesn’t judge what people do because it appreciates that people do what they do for a reason. Furthermore, it doesn’t opine on which behaviour is the best – because people do things in a way that works for them in their situation.  What research does is understand the complexity of individual situations and help designers fit seamlessly in people’s contexts and frame of mind what their products offer.

Based on these, and related, results, we have been rethinking our design specs tools and experimenting with new concepts derived from co-design principles, so that these specs become helpful to all developers and enhance their work and not represent merely an external constraint to the work they do.

This is all good.  However, the issue is not restricted to our Ubuntu developers. We should not forget that, in the wider opensource community, many developers do not have access to the Canonical, or any other, design team or to anyone with solid design training. They are the developers who work on their own free time and produce amazing software. They have to wing design.  Many wish they could access such skills to help beautify and enhance the user experience of their products. These contributors deserve our support.

So what?

To us, the solution appears to be ‘design appropriation’.

Our challenge:  how can we create design specifications and design thinking tools that developers can ‘appropriate’, just as mobile phone users started to use their phones to text because it suited their needs even though texting was not considered by the phone first creators to be a very important feature?

How can we design for the unexpected?

Upcoming research this year will be concerned with what developers can teach us about ‘appropriation’ of design.

This represents for us a first step in the investigation of the potentiality of ‘appropriation’ for all opensource.  Ultimately, appropriation should be possible not only for developers but for all end-users.

Read more
Bruno Maag

The monospace is coming

In contrast to a proportionally spaced font a the characters in a monospace occupy all exactly the same width. In the past monospace type was used on typewriters, and more recently in some specialised printing environments such as Credit Card embossing, or ticketing. Today, monospace fonts are primarily used within a programming environment working on terminal windows. The monospace font answers the need for clear code structuring and predictable line lengths. Using monospace fonts allows the programmer to immediately spot a mis-typed character or double space, any of which would prevent the code from compiling as expected.

The new Ubuntu Mono in a code enironment.

Courier is probably one of the most widely recognised monospace fonts, available on many computers. Its pitch sits at 12 glyphs per inch, set at 12 point. Based on an em-square of 1,000 units this is equal to 600 font units. As Courier is widely used it must be considered as a baseline for new monospace designs.

When starting the work on Ubuntu Mono we soon felt that we could narrow the pitch and thus increase the character count per line without compromising legibility. Only a few other monospace fonts have departed from the Courier pitch, amongst them Consolas available in the latest Clear Type collection from Microsoft. We carried out numerous trials to establish the right pitch width for Ubuntu Mono and arrived at 560 unit width. The narrower pitch also helped with spacing of the font as many characters tend to have too much space on the left and right, locking the lowercases together for enhanced legibility. Naturally, the narrower width does create a conundrum on some wide characters such as ‘m’ and ‘w’ but we are confident to have found an acceptable compromise.

Comparing Ubuntu Mono Regular with Courier

Of course, as the font weight gets bolder the narrower width does create a number of design challanges, even more so with the critical characters mentioned above. But the tighter density of the type allows the type designer to compensate by reducing the stroke width of the characters compared to the proportionally spaced font, without deacreasing colour texture, or contrast against the Regular. The biggest difference between creating a proportional font and a monospace is that a proportional design allows the designer to draw the glyph in harmony within itself and agains the other glyphs. A monospace design is dictated by the width and side-bearings (space to left and right of glyph) leaving the designer challanged to find creative solutions to maintain harmony.

A number of alternative designs to solve the problem of the ‘m’-density. Sometimes we just have to live with a compromise.

The monospaced fonts are planned to be part of the next Ubuntu release in Spring 2011 after being exposed to extensive testing. This is to ensure that they meet as many needs as possible, and being aware that it will be used primarily within a coding environment our emphasis will be to create it with this user group in mind.

The challanges of placing the bold style onto the fixed narrow pitch

The dot within the zero helps to distinguish this glyph agains both the O and Danish Oslash.

Read more
Charline Poirier

In preparation for UDS, we conducted usability testing of Unity with general public users.  We are now better informed as to where we should expend further efforts to enhance the experience for users working with Unity.

I summarize my findings below.

Participants Selection

We asked an external recruiting firm to find 15 participants who answered to the following criteria:
1.  Mix of males and females: roughly equal
2.  Age:

  • 7 people between the ages of 18 and 30
  • 6 people between the ages of 30 and 50
  • 2 people 50 or over

3. Employment:  employed full-time or to be full-time student
4. Involvement in marketing research: no such involvement in the last 6 months.
5.  Basic technology:  Each participant needed:

  • To have a broadband connection at home
  • To be a daily internet visitor, staying online for at least 2 hours every day for personal reasons

6.  Online activities:  Participants needed to have done all of the following while online in the last 2 months:

  • Look for information
  • Read comments written by others
  • Read blogs written by others

In addition, they needed to have done at least 4 of the following in the last 2 months:

  • Create or review a social networking profile
  • Post comments or reviews
  • Write a blog and conduct some activities on social networking sites
  • Shop
  • Share photos
  • Play games
  • Download music on a music player.

7.  Participants needed to have a strong interest in technology.
8.  Each participant needed to own at least one portable music device, one mobile phone, and one computer/laptop.

Of the 15 participants recruited, 13 were Windows users, 1 was a Mac user, and 1 used both Windows and Mac.  None of the participants was familiar with Ubuntu.


During one-on-one sessions, Unity was presented on a netbook.  The goal of the sessions was to get participants to experience most of Unity’s features and functionalities.  I introduced the session with the following instruction:  “Imagine this is your new computer.  What do you want to do with it?”  I had songs and pictures available for them to import.  During the 60-minute session, I asked them to do some of the activities they normally do, which included importing songs and photos, engaging in social networking, etc..  However, some of the tasks were tailored to fit the specific interests and knowledge of given participants.  For example, if a participant was a professional musician, I proposed to him or her more tasks related to music management; similarly, if a participant was a student, more of the writing and reporting capabilities of Unity were explored.


What participants liked about Unity

The look and feel:  First impressions of Unity were positive and many comments pertained to its elegance.

One participant said:  “Simple and clear tabs on the side.  I don’t like to be crowded with stuff on the screen.  It looks quite approachable.

The core concept of Unity:  Many participants intuited the new concept underlying Unity’s look and feel and direction.

One participant  said:  “I like the application idea and that it is application-oriented and you can go there and have a quite user-friendly interactivity.  I  like the tabs at the top and when I hover it tells me what it is and it is big and clear, easy to see.”

Workspaces:  Many participants were unfamiliar with the concept of workspaces and were intrigued by its overall potential, and its friendliness.
One participant said:  “What you can do is that you can have different applications in different workspaces.  This is a nice feature.”

Dash:  Participants liked the simplicity of the dash and its look and feel.

Software Centre:  Generally, the software centre was seen as impressive, particularly its large number of available free software.

Usability issues

Performance of Unity

Participants were challenged by various functionalities and conceptual design features of Unity. It is noteworthy that one factor stood out as principally responsible for many usability problems: this was Unity’s slowness and suboptimal responsiveness during testing. The level of performance in this regard significantly impaired the flow of use and the user experience. Testing was done on a mid-range netbook that users were likely to own, and consequently the user experience in this regard was similar to what users would have experienced outside of the usability lab.

Multitasking  – Multitasking on Unity is disconnected and difficult at times

Task flow is interrupted: While working on a task, participants wanted to have all the documents and websites they were using easily available to them.  For them, the task was the unit of organisation of all resources and tools.  Thus, while working on a task, participants expected that Unity would provide them with a representation or visibility of what was available to them and how to easily access what they needed at any given point.  Unity does not, however, make evident the resources and tools users have at their disposal — whether it be multiple documents, programmes or websites. In a word, while Unity relies on users to keep track of the resources they are currently using, users are habituated to relying on the software to “keep track for them,” by making the resources highly visible, for example, by means of tabs. With Unity, resources are hidden from view.

Overall, participants found the navigation between documents to be cumbersome. Often, they looked for a way, a back button or breadcrumb, that would navigate them through their open applications and  documents.  They didn’t find either. As a consequence, they ended up going through the files and folders section to access their open documents. Clicking on the OpenOffice icon to access a document already open was not immediately discoverable.

One participant noted: “[navigation] seem[s] awkward.  I’m not getting around as quickly as I should.  The icons are supposed to tell you but I don’t know what they are.  That is a problem.

Another said: “It seems a bit pedantic to have to go through the application menu to navigate.”

Poor visibility of applications and of windows that are opened: Participants experienced difficulties with the following:

Minimising a document: When participants minimised a document, the document seemed to have disappeared when they expected the mininised document to be shown at the bottom of the screen.  In Unity, there were no traces of the document on the screen and participants could not find it again.

“I’m not entirely sure how to get back into my new document [after minimising it].  [It is] not clear that it opened a new page for it.  I don’t know how to get back to it.  I don’t know, it’s weird.  I expect it to be a tab and be able to switch between the two.”

Knowing which documents are currently opened:  Participants made it clear that they not only wanted to know if their documents were opened, but also wanted to know how many documents or windows were open at any given time.  But they did not always see the white triangle that indicates that a programme is running or that documents are opened.  Consequently, they were not aware of what was available to them.  In short, the general indicator was not enough for their needs for awareness.

Being able to distinguish between similar documents:  In the exposé view, documents are very small and, when 2 documents are similar, participants could not tell which was the one they wanted without opening each one individually.

Identifying a document:  When participants were in the process of writing a document, they looked for the name of the document they were working on in the top menu bar, but couldn’t find it.  They were also looking for such information in the exposé view.

Being aware of multiple open documents or windows they needed to consult or modify: Almost all participants wanted to organise their work by opening several windows and physically positioning them in a way to maintain an awareness of all of them.  For example, one participant opened Facebook and a word document.  She wanted to move the word document so she could expose the top part of Facebook.

“Can you move the window down at all?  I like to have a little bit of space for organisation.  I want to be able to move the window down.  It would be nice to [be able to do that], especially if you want to start working, you want to organise your environment.  You want to feel the sense of relief and organisation before you start working and [the sense] that what will come to you will be manageable.”

Immediate access to documents they currently are working on:  Exposé is not readily discoverable.  The majority of participants could not find the exposé feature.  As it is not a feature they are used to having, they need a prompt to help them explore it.

Exposé does not allow users to work on documents side-by-side.  Participants expected to use the exposé feature to be able to cut and paste between documents directly without having to bring one document up in full screen and then having to navigate to the next document by means of the workspaces icon.  As it is, exposé is useful for viewing only.  Participants would have liked to have had the option to directly navigate and conduct operations (e.g., cut and paste) between documents.

Documents cannot be resized and placed side-by-side:  No participant could find a way to resize his/her Open-Office documents in such a way that they could be placed side-by-side while working on both at once.

Overview of what’s going on: Many participants wished they could have a view of what resides in various parts of their computer, as is facilitated by Windows’s “my computer”.

Back button:  Many participants needed to “go back” to a document or an application that was currently open.  But the back button doesn’t work coherently and seemed to bring participants to arbitrary pages.

“The thing here, backward and forward buttons don’t work.  Back button doesn’t get me back to where I was.  I don’t know where it is taking                 me, I’m frustrated.  The back button is taking me somewhere [else].”

“If you can’t navigate you feel like a fool and you feel ashamed even if you’re alone in your room.”

“I’m struggling to find short-cuts and a back button.  Right now, to me, it feels very clunky to go from one place to another.”

Document management

Open documents: As already indicated briefly, participants didn’t know how many documents they had opened.  The white triangle indicator, meaning that the programme is working or that at least one document is currently open, is too general for users’ needs.

Delete documents:  Participants could not delete existing documents from their files and folders.  They first tried to drag and drop documents in the waste basket; then they right-clicked to see if they had such an option.

Copy and paste:  Copy and paste from one document to another didn’t always work for participants.
“Copy and paste is not going to work.  I’m not impressed, it must work.  I’m one for copying and pasting.”

Lack of feedback and guidance

Unity is often slow, and as a result participants tended to be confused about what was going on. They didn’t know:
1) if the system was slow and would eventually produce the desired effect, or
2) if the system had not registered the participant’s command and as a consequence, they should repeat their action, or even
3) if the system had crashed.

Unity needs to clearly show if it is engaged in a process or not.

“Has it crashed?”

“Let’s make sure I clicked it.  [She opens a document.  She's getting confused navigating between documents and she closes the document without saving it.]  When I close, it should ask me to save it.  This is not good [that it doesn't].  You rely on the computer to save the document or not.”


When entering a search term in the search bar, there is no feedback to show that Unity is indeed engaged in a process.  Many participants were confused by this.

“How do you know this is searching?  Is there any sort of symbol to tell you if it is doing something?  I would like to see if there is a symbol that says the computer is working so I am not clicking around.”

Other issues:  Interactions with the launcher, finding the dash, lack of reference to understanding Ubuntu features

Interactions with the launcher

Adding an icon to the launcher:  Many participants were not able to add a short-cut of an application to the launcher.  They used various strategies but failed:

  1. They tried to drag and drop icons directly from the applications section to the launcher.
  2. They right-clicked, expecting an option to copy.
  3. A few participants noticed that when an application is open, it appears in the launcher, and when they close it, it disappears.  They were confused by this feature, but at the same time perceived it as a clue.  So they tried to drag and drop the icon from the applications section onto the similar icon visible in the launcher.

Changing the order of icons in the launcher:  Most participants failed to reorganise the order of icons in the launcher.  They selected an icon and tried to drag it upwards within the launcher; that is, they did not realise that they needed to remove the icon from the deck first before they could relocate it.

Deleting an icon from the launcher:  Participants did not succeed in deleting an icon from the launcher.  Most selected the icon and then dragged it into the waste basket at the bottom of the launcher.  They did not see that they could remove an icon by dragging it horizontally away from the launcher.

Finding the dash:  The majority of participants who found the dash found it by accident. They were not sure what it was, and didn’t know how they had gotten there if they accidentally had.  As a consequence, they were not able to find it again. The problem for participants here was that the logo is not recognisable to them.  Of course, they were not familiar with Ubuntu; but, equally important, the logo is less visible in size and colour than the icons contained in the launcher.  It took participants a while to see it at all.

“The logo should stand out more.  It would be nice if the icon itself [was] coming at you, more of a three-dimensional thing.

Lack of reference to understanding Ubuntu unique features

Software centre: Almost all participants were surprised when I suggested that they install a game that was not currently installed on their computer.  All of them immediately went to the internet.  When I told them that such games could be found on Ubuntu, they were confused and many didn’t know where to find them.  They went to the applications section, where there remembered a section called “installed” software.  They expected either a section below this one with a list of uninstalled software or (at the very least) a link to the software centre.

Moreover, most participants expected to be able to click on an icon in the dash, for example ‘music,’ and directly access their albums and songs.  They were a bit surprised to be taken to music applications instead, especially in light of the interactions of the other icons in the launcher, which  are quite different.

“I expect to see music files, names of songs or albums, anything you’ve downloaded.  Titles.”

Familiar short-cuts: Participants who normally used short-cuts to navigate didn’t find the familiar short-cuts and were frustrated.

“There are things that are nice to keep from one OS to another, like right click and short-cuts.  It’s nice to have two possible solutions.”

Changing the wallpaper

Many participants did not succeed in changing their wallpaper because the default screen of appearance was open in full screen by default.  Because of this, the action of immediate wallpaper change, as users select a wallpaper, was not visible to them. After participants had selected a wallpaper, they expected a step to confirm that they wanted their wallpaper to be changed.  Instead they were given  other options that were not relevant to what they were trying to do, and at which they had already (but unbeknownst to them) succeeded.


The search functionalities felt limited to participants. When searching, they didn’t know what the field and scope were that were covered by the search engine they were using.

Grey icons in launcher

Participants thought that the grey icons in the launcher were inactive, especially when they clicked on them and the system was very slow in responding

Read more

For the first year and a half in Canonical I worked with the amazing Launchpad team, with the ambitious goal of building a new user interface, introducing AJAX in an established code base and rolling it all out on time. While all of that was overwhelming in itself, what was more important to me was making sure the UI remained consistent across time.
Long story short, it was a success and it's been 8 months since I've left the team and the established process is still on-going.

I wrote a paper on the whole experience and presented it at the agile conference XP2010 in Norway.

Here's the introduction:

When I started working with the Launchpad team I was tasked with designing and rolling out a new interface using cutting-edge technology on a well established product and team. The existing processes and team structure made it very hard to roll out big changes while also ensuring consistency as time went by.
While the general designs and work ow changes were being eshed out, I started to drive some change to the existing processes, enabling me to be successful at an objective that would take a year to accomplish, and unexpectedly, beyond that.
The project was 4 years old and had over 500 dynamic pages with different templates and layouts that had been left untouched at different points in time. The goal for the next year was to make the application easier to use, even enjoyable. I also had to make the UI consistent across the board, take the project from static HTML pages into the wonderful world of in-line editing, streamlined work-flows and predictable interactions. In parallel, fundamental features that had been developed were going completely unused and we needed to turn that around. A re-usable AJAX infrastructure had to be developed from the ground up, new features needed to be designed and delivered, and general navigation issues needed to be addressed.
However, this story isn't about the success of the roll out of a new interface, but rather the success in the process changes that evolved during that year and how the project went from nobody feeling ownership over the user interface, to the developers taking strong ownership.

I feel very passionate about this subject, and hope this experience can help other projects and teams.

Here's the paper for download: xp2010_paper.pdf

Read more