We'll see | Matt Zimmerman

a potpourri of mirth and madness

Posts Tagged ‘Usability’

Listening to users

In the software community, people hold strong opinions on the subject of listening to users. Some feel that users are an essential source of information for making successful products, as evidenced in the customer development methodology, and seek to involve users deeply in product development. Others believe that users don’t know what they want, invoking the quote attributed to Henry Ford, “If I’d asked customers what they wanted, they would have said ‘a faster horse'”. Some say that user needs are unknowable except through the lens of a marketplace, where people choose in aggregate which products suit them best, and customers “vote with their wallets” (anything else is “anecdata”).

Regular readers will not be surprised that I believe they are all right, but only in certain contexts. The right strategy for involving users in product decisions will depend on factors related to the product itself, the market, and the product development method being used.

One of the most important is the life cycle stage of the product: is it a new and rapidly evolving concept, or a mature commodity, or somewhere in between? Simon Wardley explains this well over on his blog, so I won’t rehash his points here, but will add a few of my own.

If what we’re looking for is inspiration for a new product, it’s here that Henry Ford was right: users generally won’t hand you a complete product vision on a silver platter. They’ll frame their input in terms of what they know, and the choices already available to them. However, this doesn’t mean that users don’t have a role to play in this instance: watching users can be a great source of inspiration. It’s the combination of domain knowledge and passionate imagination which triggers the creative spark. Henry Ford applied his engineer’s interests to a problem which was evident all around him.

If our goal is to test whether a new product is a good fit for its users, there is no substitute for user feedback. We can guess at whether there is a fit, and our intuition may be good, but users are the ultimate judges, and we don’t know if we’re right or wrong until users evaluate it. So ask them! By engaging in dialogue with individual users, we can learn unexpected things which will help to refine the idea. If we don’t find what they think until our new product is released, we risk making something that no one wants. Why wait until it’s too late? It can be challenging to extract useful feedback for a product which doesn’t yet exist, but this effort is well worth it to avoid wasting much more effort in software engineering.

When our objective is to incrementally improve an existing product, individual anecdotes can mislead us. A given change may be an improvement for one user, but a disaster for another. What we want to know is whether the new version is better for the population as a whole, and in this case, we do well to rely on data. There are pitfalls here as well, of course. We need to choose our questions carefully, and realize that users will often resist any change: not because they’re stodgy by nature, but because they have to invest effort in adapting to the change. I think of incremental improvement as a joint investment made between product developers and their users, to improve the whole system of people and technology for the better.

By choosing the right tool for the job, we can make better decisions, improve faster, and ultimately solve the right problem for our users.

Advertisement

Written by Matt Zimmerman

March 7, 2011 at 12:56

Posted in Uncategorized

Tagged with , , , , ,

Ubuntu Brainstorm Top 10 for December 2010

As I mentioned recently, the Ubuntu Technical Board is reviewing the most popular topics in Ubuntu Brainstorm and coordinating official responses on behalf of the project. This means that the most popular topics on Ubuntu Brainstorm receive expert answers from the people working in these areas.

This is the first batch, and we plan to repeat this process each quarter. We’ll use feedback and experiences from this run to improve it for next time, so let us know what you think.

Power management (idea #24782)

Laptops are now outselling desktops globally, and laptop owners want to get the most out of their expensive and heavy batteries. So it’s no surprise that people are wondering about improved power management in Ubuntu. This is a complex topic which spans the Linux software stack, and certainly isn’t an issue which will be “solved” in the foreseeable future, but we see a lot of good work being done in this area.

To tell us about it, Amit Kucheria, Ubuntu kernel developer and leader of the Linaro working group on Power Management, contributed a great writeup on this topic, with technical analysis, tips and recommendations, and a look at what’s coming next.

I am going to attempt to summarize the various use profiles and what Ubuntu does (or can do) to prolong battery life in those profiles. Power management, when done right, should not require the user to make several (difficult) choices. It should just work – providing a good balance of performance and battery life.

IP address conflicts (idea #25648)

IP addressing is a subject that most people should never have to think about. When something isn’t working, and two computers end up with the same IP address, it can be hard to tell what’s wrong. I was personally surprised to find this one near the top of the list on Ubuntu Brainstorm, since it seems unlikely to be a very common problem. Nonetheless, it was voted up, and we’re listening.

There is a tool called ipwatchd which is already available in the package repository, and was created specifically to address this problem. This seems like a further indication that this problem may be more widespread than I might assume.

The idea has already been marked as “implemented” in Brainstorm based on the existence of this package, but that doesn’t help people who have never heard of ipwatchd, much less found and installed it.

What do you think? Have you ever run into this problem? Would it have helped you if your computer had told you what was wrong, or would it have only confused you further? Is it worth considering this for inclusion in the default install? Post your comments in Brainstorm.

Selecting the only available username to login (idea #6974)

Although Linux is designed as a multi-user operating system, most Ubuntu systems are only used by one person. In that light, it seems a bit redundant to ask the user to identify themselves every time they login, by clicking on their username. Why not just preselect it? Indeed, this would be relatively simple to implement, but the real question is whether it is the right choice for users.

Martin Pitt of the Ubuntu Desktop Team notes that consistency is an important factor in ease of use, and asks for further feedback.

So in summary, we favored consistency and predictablility over the extra effort to press Enter once. This hasn’t been a very strong opinion or decision, though, and the desktop team would be happy to revise it.

Icon for .deb packages (idea #25197)

Building on the invaluable efforts of Debian developers, we work hard to make sure that people can get all of the software they need from Ubuntu repositories through Software Center and APT, where they are authenticated and secure. However, in practice, it is occasionally necessary for users to work with .deb files directly.

Brainstorm idea 25197 suggests that the icon used to represent .deb packages in the file manager is not ideal, and can be confusing.

Matthew Paul Thomas of the Canonical Design Team responds with encouragement for deb-thumbnailer, which makes the icon both more distinctive and more informative. He has opened bug 685851 to track progress on getting it packaged and into the main repository.

I have reviewed the proposed solutions with Michael Vogt, our packaging expert. Solution #1 is straightforward, but we particularly like solutions #5 and #10, using a thumbnailer to show the application icon from inside each package.

Keeping the time accurate over the Internet by default (idea #25301)

It’s important for an Internet connected computer to know the correct time of day, which is why Ubuntu has included automatic Internet time synchronization with NTP since the very first release (4.10 “warty”). So some of us were a little surprised to see this as one of the most popular ideas on Ubuntu Brainstorm.

Colin Watson of the Ubuntu Technical Board investigated and discovered a case where this wasn’t working correctly. It’s now fixed for Ubuntu 11.04, and Colin has sent the patches upstream to Debian and GNOME.

My first reaction was “hey, that’s odd – I thought we already did that?”. We install the ntpdate package by default (although it’s deprecated upstream in favour of other tools, but that shouldn’t be important here). ntpdate is run from /etc/network/if-up.d/ntpdate, in other words every time you connect to a network, which should be acceptably frequent for most people, so it really ought to Just Work by default. But this is one of the top ten problems where users have gone to the trouble of proposing solutions on Brainstorm, so it couldn’t be that simple. What was going on?

More detail in GNOME system monitor (idea #25887)

Under System, Preferences, System Monitor, you can find a tool to peek “under the hood” at the Linux processes which power every Ubuntu system. Power users, hungry for more detail on their systems’ inner workings, voted to suggest that more detail be made available through this interface.

Robert Ancell of the Ubuntu Desktop Team answered their call by offering to mentor a volunteer to develop a patch, and someone has already stepped up with a first draft.

Help the user understand when closing a window does not close the app (idea #25801)

When the user clicks the close button, most applications obediently exit. A few, though, will just hide, and continue running, because they assume that’s what the user actually wants, and it can be hard to tell which has happened.

Ivanka Majic, Creative Strategy Lead at Canonical, shares her perspective on this issue, with a pointer to work in progress to resolve it.

This is more than a good idea, it’s an important gap in the usability of most of the desktop operating systems in widespread use today.

Ubuntu Software Centre Removal of Configuration Files (idea #24963)

One feature of the Debian packaging system used in Ubuntu is that it draws a distinction between “removing” a package and “purging” it. Purging should remove all traces of the package, such that installing and then immediately purging a package should return the system to the same state. Removing will leave certain files behind, including system configuration files and sometimes runtime data.

This subtle distinction is useful to system administrators, but only serves to confuse most end users, so it’s not exposed by Software Center: it just defaults to “removing” packages. This proposal in Ubuntu Brainstorm suggests that Software Center should purge packages by default instead.

Michael Vogt of the Ubuntu Foundations Team explains the reasoning behind this default, and offers an alternative suggestion based on his experience with the package management system.

This is not a easy problem and we need to carefully balance the needs to keep the UI simple with the needs to keep the system from accumulating cruft.

Ubuntu One file sync progress (idea #25417)

Ubuntu One file synchronization works behind the scenes, uploading and downloading as needed to replicate your data to multiple computers. It does most of its work silently, and it can be hard to tell what it is doing or when it will be finished.

John Lenton, engineering manager for the Ubuntu One Desktop+ team, posts on the AskUbuntu Q&A site with tools and tips which work today, and their plans to address this issue comprehensively in the future.

Multimedia performance (idea #24878)

With a cornucopia of multimedia content available online today, it’s important that users be able to access it quickly and easily. Poor performance in the audio, video and graphics subsystems can spoil the experience, if resource-hungry multimedia applications can’t keep up with the flow of data.

Allison Randal, Ubuntu Technical Architect, answers with an analysis of the problem and the proposed solutions, an overview of current activity in this area, and pointers for getting involved.

The fundamental concern is a classic one for large systems: changes in one part of the system affect the performance of another part of the system. It’s modestly difficult to measure the performance effects of local changes, but exponentially more difficult to measure the “network effects” of changes across the system.

Written by Matt Zimmerman

December 10, 2010 at 14:04

Posted in Uncategorized

Tagged with , , , , , , ,

Ubuntu 10.10 (Maverick) Developer Summit

I spent last week at the Ubuntu Developer Summit in Belgium, where we kicked off the 10.10 development cycle.

Due to our time-boxed release cycle, not everything discussed here will necessarily appear in Ubuntu 10.10, but this should provide a reasonable overview of the direction we’re taking.

Presentations

While most of our time at UDS is spent in small group meetings to discuss specific topics, there are also a handful of presentations to convey key information and stimulate creative thinking.

A few of the more memorable ones for me were:

  • Mark Shuttleworth talked about the desktop, in particular the introduction of the new Unity shell for Ubuntu Netbook Edition
  • Fanny Chevalier presented Diffamation, a tool for visualizing and navigating the history of a document in a very flexible and intuitive way
  • Rick Spencer talked about the development process for 10.10 and some key changes in it, including a greater focus on meeting deadlines for freezes (and making fewer exceptions)
  • Stefano Zacchiroli, the current Debian project leader, gave an overview of how Ubuntu and Debian developers are working together today, and how this could be improved. He has posted a summary on the debian-project mailing list.

The talks were all recorded, though they may not all be online yet.

Foundations

The Foundations team provides essential infrastructure, tools, packages and processes which are central to the development of all Ubuntu products. They make it possible for the desktop and server teams to focus on their areas of expertise, building on a common base system and development procedures.

Highlights from their track:

Desktop

The desktop team manages both Desktop Edition and Netbook Edition, on a mission to provide a top-notch experience to users across a range of client computing devices.

Highlights from their track:

Server/Cloud

The server team is charging ahead with making Ubuntu the premier server OS for cloud computing environments.

Highlights from their track:

ARM

Kiko Reis gave a talk introducing ARM and the corresponding opportunity for Ubuntu. The ARM team ran a full track during the week on all aspects of their work, from the technical details of the kernel and toolchain, to the assembly of a complete port of Netbook Edition 10.10 for several ARM platforms.

Kernel

The kernel team provided essential input and support for the above efforts, and also held their own track where they selected 2.6.35 as their target version, agreed on a variety of changes to the Ubuntu kernel configuration, and created a plan for providing backports of newer kernels to LTS releases to support deployment on newer hardware.

Security

Like the kernel team, the security team provided valuable input into the technical plans being developed by other teams, and also organized a security track to tackle some key security topics such as clarifying the duration of maintenance for various collections of packages, and the ongoing development of AppArmor and Ubuntu’s AppArmor profiles.

QA

The QA team focuses on testing, test automation and bug management throughout the project. While quality is everyone’s responsibility, the QA team helps to coordinate these activities across different teams, establish common standards, and maintain shared infrastructure and tools.

Highlights from their track include:

Design

The design team organized a track at UDS for the first time this cycle, and team manager Ivanka Majic gave a presentation to help explain its purpose and scope.

Toward the end of the week, I joined in a round table discussion about some of the challenges faced by the team in engaging with the Ubuntu community and building support for their work. This is a landmark effort in mating professional design with free software community, and there is still much to learn about how to do this well.

Community

The community track discussed the usual line-up of events, outreach and advocacy programs, organizational tools, and governance housekeeping for the 10.10 cycle, as well as goals for improving the translation of Ubuntu and related resources into many languages.

One notable project is an initiative to aggressively review patches submitted to the bug tracker, to show our appreciation for these contributions by processing them more quickly and completely.

Written by Matt Zimmerman

May 17, 2010 at 12:01

Posted in Uncategorized

Tagged with , , , , , , , , , , ,

Have you tried the “white boy” test?

From time to time, someone in the Ubuntu community writes about the experience of introducing a “normal person” (someone who has no specific expertise with computers) to Ubuntu. These accounts provide useful feedback to Ubuntu designers and developers working to make Ubuntu easier to understand and use. They are no substitute for rigorous usability studies, but are nonetheless worthwhile. By explaining where the subject got stuck, they help to identify the most obvious usability problems. By celebrating the user’s successes, they help to build a sense of accomplishment and momentum around usability.  They usually go something like this:

My grandmother is 104 years old and has never used a mobile phone before, much less a computer. One lazy Sunday afternoon, I introduced her to Ubuntu. I helped her into the den, showed her the mouse and keyboard, inserted the installation CD…

They go on to describe the subject’s attempts to use Ubuntu for common tasks, without any prior experience of the system.  I will boldly hypothesize, based on my own reading and without gathering any data, that the subjects are predominantly female.  Perhaps the earliest examples of this were our references to Jeff Waugh‘s mother, in early Ubuntu thought experiments, as an example of an uninitiated Ubuntu user.

Thus, we generalize: Ubuntu is so easy, even your grandmother can use it, or it passes the Mother test, or the girlfriend experiment shows just how far we have to go.

These generalizations idealize women as uninformed, technological novices or intellectual inferiors, which is particularly striking to some of us who learned computing from our mothers.  This is not to say that statements like these are the origin of gender stereotypes, but they do display and reinforce these (often unconscious) beliefs.

In analyzing statements about gender roles, it is sometimes helpful to substitute for gender some other trait, such as skin color or race.  This helps to illustrate bias, because many of us are more sensitized to racial stereotypes: is Ubuntu so easy that a white boy could use it?  Does it pass the white boy test?  If my white boyfriend can figure it out, you can too! This can be a useful way to “test” language and reveal implications.

We should think twice when we read, and make the effort to investigate our own speech as well.  Unfortunately, our first impulse is often to deny the possibility of bias, and treat the situation like an argument we want to win.  Instead, we should try to recognize these moments as opportunities to improve our awareness, and listen for new information in the reactions of others.

It would be a huge step forward for us as a community to do better at this.  We will know that Ubuntu has truly arrived, though, when becomes more popular among white people than Apple.

Written by Matt Zimmerman

June 20, 2009 at 17:37

Posted in Uncategorized

Tagged with , , ,

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.

Written by Matt Zimmerman

August 25, 2008 at 18:33

Posted in Uncategorized

Tagged with , , ,