Ease of use is a feature

It may be an undervalued one, though. Like many other examples of good design, the best user interfaces go largely unnoticed by their users. If a user consciously notices the UI, as something separate from the task at hand, it could probably be improved.

Ease of use is a frequent topic of discussion in Ubuntu. For example, one of the primary reasons why we chose the GNOME desktop for Ubuntu is that the GNOME project was making great strides in this area, as exemplified by the GNOME Usability Project and its Human Interface Guidelines or HIG. Nearly four years later, usability is still a key consideration whenever we discuss alternative applications. Ubuntu users don’t often consciously notice if their system has good usability characteristics, though. By definition, it’s behaving as expected, and it’s human nature that this usually goes unnoticed.

Facebook is another example of this phenomenon. Like Ubuntu, Facebook was a relative latecomer in its space. There were already plenty of social networking sites at the time, some with millions of users. Today, Facebook is winning, with over 90 million users and one of the most visited sites on the web. They did a number of things right, notably their strategy to make Facebook an application platform, but one of them was usability. Their site looked and worked like a single application throughout, rather than a loosely connected universe of ugly pages. They’ve recently launched a redesign which aims to make it even simpler and more consistent, showing that they’ve maintained this focus so far. They’re even running it in parallel with the old design to measure its impact.

How about Ubuntu? Most of the software in Ubuntu is developed by other communities, but many of the applications which originated in Ubuntu exist for the sole purpose of making it easier to use: gnome-app-install (Add/Remove), Update Manager, Ubiquity (our desktop installer), Jockey (our driver manager) and UFW (our work-in-progress firewall) primarily provide a simpler interface to functionality provided by underlying tools. A system programmer wouldn’t say that they add much in the way of features, but they enable casual users to do things they couldn’t do before.

Where could we do better? I’m interested not only in specific usability improvements, but in how we can improve our overall approach to ensure that we continuously improve. The first step is to figure out how to measure how well we’re doing, and be able to try out new ideas.

How can we, as a community of users and developers, do effective usability testing, and collaborate with upstream projects to process the results? I have some ideas, which I’ll write about separately.

14 Responses

Usability shouldn’t be a feature, it should be a requirement. It goes right after “doesn’t crash” and “does what it’s supposed to do”.

It seems like what you are after is institutionalizing usability, rather than having it as a edge activity (interestingly, this is something I talked about in my Akademy presentation). We currently have this same problem in KDE — lots of stuff gets done, but it is so far on the fringe that it doesn’t effect the project as a whole. So you have these pockets of really good software mixed in with a user experience which isn’t fully integrated and seamless.

Making design part of the Ubuntu culture would be another step towards. When developers have resources they can draw on and expect UI reviews, I expect you will get halo effects beyond what actually gets fixed. Contributor’s work processes begin changing and usability becomes one of those things you check for, just as you would check for bugs and accessibility before a release. Activities such as documenting user research and iterating design come naturally instead of being a special project or exception.

You mention measuring how well you are doing now. This is certainly useful, but it is also an investment. It isn’t an easy task to properly baseline usability in an application, especially one which is always evolving and ever changing such as open source software. To do it correctly requires a strong research plan and some money.

Of course, all of this is going to be a challenge with one dedicated designer and the few floating volunteers in the community. If usability as a required feature truly is an Ubuntu goal, you’re going to have to make a serious investment in time, people, and philosophy.

I’m not sure if this qualifies as a usability issue per se, but users often have trouble knowing which packages to install to achieve a specific task. I think it would be great to have a site where users can submit screenshots and reviews of programs in Ubuntu. Then, programs like Synaptic can look up this meta-data for a specific package, and display a few screenshots, reviews, remarks and maybe even videos before the user decides to install it. If there are bugs in the program, users could even list workarounds and links to Malone.

I just went over to Brainstorm to find a link for an Usability section there, but there isn’t. I think if Brainstorm had a Usability section, it would be easier for you to gather the best and most popular ideas around it.

Coming from a user, I think a great strategy would be to make it the goal of the next LTS release a “people” centric release.

– So move toward Empathy/Telepathy and start using and developing libsoylent. Make contacts universal throughout the system, so Evolution can use libsoylent for contacts or other contact management applications people want to use can use libsoylent.
– Develop a Remote Assistant plugin for Empathy that ties into VNC which I’m sure would not only help other people, but I’m sure would help Canonical with their paid support solutions (i.e. if Mom’s having computer issues we can do a video chat in Empathy and then she can send me a remote assistance link and we can both control the pc so i can fix her issue).
– Make sharing/sending files to people easy and FAST (right now in ubuntu 8.04 when I click a samba shared folder it takes about 5 seconds and then a dialog window pops up to tell me it’s working and i can cancel if I want and then it takes another 5 seconds and that’s just to view a shared folder on the network between two ubuntu comptuers). On the Empathy front, I’m talking seamless integration. So if I’m in Evolution and I drag a contact in Evolution to a Empathy contact it will send that contact (vCard) to that Empathy user. No need to right click. Same should be for pictures in F-Spot or rhthymbox and in other applications too where I can click and drag within the app instead of browsing to the actual file (which btw you should be able to do as well).

In essence, make the next LTS release the best OS in terms of people and communication the best ever! Make it to where the UI is so intuitive where users can figure it out on their on (i.e. click and drag). So obviously you would need to push out Empathy in 8.10 to start this process (which I’m hoping you will from reading the mailing lists).

I should mention too that along the lines of collaboration between users it would be nice if there were things like real time document sharing like AbiWord, etc where two users can edit the same document in real time with seamless integration into telepathy/empathy/dbus… that would help it also make it a more people centric os and about connecting people and ideas.

@seele, I’d like to live in a world where usability could be taken for granted this way, but we aren’t there yet. You’re right that this needs to be a core value, not something which is relegated to certain people or teams, though such people and teams can make a big difference in promoting it.

Nobody said it would be easy, but this is an area where we (Canonical in this case) can justify making an investment. Watch this space.

@Eric Pritchett, I’ve explored some similar ideas in a usability context. A workable approach to usability testing for Ubuntu would need to support distributed operation, remotely observing user behavior. I wonder how successful this would be with simple observation of the desktop session. The cues from the user’s physical posture can be telling, and their spoken commentary can be invaluable.

I can think of 3 broad strategies for improving the ease of use, or maybe I should say usefulness, of Ubuntu or any distribution:
– Work from the current state. I think UI reviews should play a central role. You should also define user groups, environments and tasks to analyse the usability for said tasks within context. This is important to not get stuck on a per-package level.
– Build infrastructure that will make it faster and simpler to design, implement, test and tweak UIs. Specifically make it possible for non-coders.
– Do an activity-centered top-down design of the base system. What we have now has much to do with what has been convenient, technically. I think this is necessary to address some deep issues that are hard to impossible to get at with an incremental process.

Thanks for all the feedback. Note that I’m particularly interested in how we can *systematically* improve usability, more so than specific usability improvements, though I’ll have a look at those suggestions.

To expand on my previous post, drawing in some material from my archive :)
On how to systematically improve usability for Ubuntu.

First: Try to agree on one central, official definition of usability!

My preferred definition of usability goes along the lines of: the combination of effectiveness, efficiency and user satisfaction for a specific context made up of a goal to accomplish, a user and his environment.

So after defining the context, you have to ask if the goal can be accomplished by the user(s) at all. Then how well it can be accomplished (there can several factors such as how long different stages take or the stress level of the user, so you need a weighting). Finally how satisfied the user feels. Happy people tend to perform better, so this could be seen as an aspect of efficiency, but it is well possible that a less efficient design is more satisfying.

All other aspects such as learnability, memorability, predictability, responsiveness, robustness, … follow from the above.

2. Context approach, can be used outside of package boundaries
– Define user groups, environments and matching common activities/goals. Do surveys, interviews and on-site visits to learn about all these. Prioritises by importance for Ubuntu. You may have to explicitly exclude some fields.
– Break activities down into tasks (Activity: browse the web, task: find a picture of an Ibex)
– Evaluate if and how well the tasks can be performed / goals can be reached within their context with what Ubuntu currently has to offer.
– Consider the knowledge a user has to have for each task. See if it can be reduced.
– Go into research and conception to fix the holes you find.
– Implement changes and switch to 1.

3. Research approach, increase your knowledge
– Study potentially relevant HCI/usability and cognitive psychology research.
– Fund additional research if necessary.
– Build a hierarchical system of goals to facilitate objective and exhaustive judgment of concepts.
– Create concepts for basic interaction based on human-centered research (instead of what has been convenient for technical reasons).
– Add detail by going through user groups, environments, activities/tasks.

4. Vision approach, look ahead
– Create at least one scenario concerning upcoming technology, trends and cultural change in 5, 10 or 15 years.
– Extract new user goals, tasks and the resulting requirements.
– Combine this with 3.
– Write a roadmap to get from now to then and act accordingly.
– Communicate the vision and conclusions to the community.

5. Community and education approach
– Document everything of the above in an open manner. Facilitate participation.
– Publish examples of expert UI reviews and checklists and invite users and developers to try it themselves (many eyes …).
– Build or recommend a portal to usability related research.
– Build a manual on how to design or refine software UI to our best knowledge.
– Highlight successful developments.

6. Framework approach, allow it to happen.
– Make it easier to design, implement, test and change UI. Especially for those who don’t consider themselves developers.
– Push for engine/UI separation
– Build tools to manage the user- and/or activity-centered design of software. Starting from goals and requirements.