From our friend Jim Hall of the FreeDos project…
Open source software developers have created an array of amazing programs that provide a great working environment with rich functionality. At work and at home, I routinely run Fedora Linux on my desktop, using Firefox and LibreOffice for most of my daily tasks. I’m sure you do, too. But as great as open source can be, we’re all aware of a few programs that just seem hard to use. Maybe it’s confusing, or has awkward menus, or has a steep learning curve. These are hallmarks of poor usability.
But what do we mean when we talk about usability? Usability is just a measure of how well people can use a piece of software. You may think that usability is an academic concept, not something that most open source software developers need to worry about, but I think that’s wrong. We all have a sense for usability – we can recognize when a program has poor usability, although we don’t often recognize when a program has good usability.
So how can you find good usability? When a problem has good usability, it just works. It is really easy to use. Things are obvious or seem intuitive.
But getting there, making sure your program has good usability, may take a little work. But not much. All it requires is taking a step back to do a quick usability test.
A usability test doesn’t require a lot of time. In fact, usability consultant Jakob Nielsen says that as few as 5 usability testers are enough to find the usability problems for a program. Here’s how to do it:
1. Figure out who are the target users for your program.
You probably already know this. Are you writing a program for general users with average computer knowledge? Or are you writing a specialized tool that will be used by experts? Take an honest look. For example, one open source software project I work on is the FreeDOSProject, and we figured out long ago that it wasn’t just DOS experts who wanted to use FreeDOS. We actually determined there were three different types of users: people who want to use FreeDOS to play DOS games, people who need to use FreeDOS to run work applications, and developers who need FreeDOS to create embedded systems.
2. Identify the typical tasks for your users.
What will these people use your program for? How will your users try to use your program? Come up with a list of typical activities that people would actually do. Don’t try to think of the steps they will use in the program, just the types of activities. For example, if you were working on a web browser, you’d want to list things like: visiting a website, bookmarking a website, or printing a web page.
3. Use these tasks to build a usability test scenario.
Write up each task in plain language that everyone can understand, with each task on its own page. Put a typical scenario behind the tasks, so that each step seems natural. You don’t have to build on each step – each task can be separate with its own scenario. But here’s the tricky part: be careful not to use terminology from your program in the scenario. Also avoid abbreviations, even if they seem common to you – they might not be common to someone else. For example, if you were writing a scenario for a simple text editor, and the editor has a “Font” menu, try to write your scenario without using the word “Font.” For example, instead of this: “To see the text more clearly, you decide to change the font size. Increase the font size to 14pt.” write your scenario like this: “To see the text more clearly, you decide to make the text bigger. Increase the size of the text to 14 point.”
Once you have your scenarios, it’s just a matter of sitting down with a few people to run through a usability test. Many developers find the usability test to be extremely valuable – there’s nothing quite like watching someone else try to use your program. You may know where to find all the options and functionality in your program, but will an average user with typical knowledge be able to?
A usability test is simply a matter of asking someone to do each of the scenarios that you wrote. The purpose of a usability test is not to determine if the program is working correctly, but to see how well real people can use the program. In this way, a usability test is not judging the user; it’s an evaluation of the program. So start your usability test by explaining that to each of your testers. The usability test isn’t about them; it’s about the program. It’s okay if they get frustrated during the test. If they hit a scenario that they just can’t figure out, give them some time to work it through, then move on to the next scenario.
Your job as the person running the usability test is actually the hardest of all. You are there to observe, not to make comments. There’s nothing tougher than watching a user struggle through your program, but that’s really the point of the usability test. Resist the temptation to to point out “It’s right there! That option there!”
Once all your usability testers have had their chance with the program, you’ll have lots of information to go on. You’ll be surprised how much you’ll learn just by watching people using the program.
But what if you don’t have time to do a usability test? Or maybe you aren’t able to get people together. What’s the shortcut?
While it’s best to do your own usability test, I find there are a few general guidelines for good usability, without having to do a usability test:
In general, I see Familiarity as a theme. When I did a usability test of several programs under the GNOME desktop, testers indicated that the programs seemed to operate more or less like their counterparts in Windows or Mac. For example, Gedit wasn’t too different from Windows Notepad, or even Word. Firefox is like other browsers. Nautilus is very similar to Windows Explorer. To some extent, these testers had been trained under Windows or Mac, so having functionality – and paths to that functionality – that was approximately equivalent to the Windows experience was an important part of their success.
Also, Consistency was a recurring theme in the feedback. For example, right-click menus worked in all programs, and the programs looked and acted the same.
Menus were also helpful. While some said that icons (such as in the toolbar) were helpful to them during the test, most testers did not actually use the quick-access toolbar in Gedit – except to use the Save button. Instead, they used the program’s drop-down menus: File, Edit, View, Tools, etc. In fact, testers experienced problems when the menus did not present possible actions clearly.
And finally, Obviousness. When an action produced an obvious result, or clearly indicated success – such as saving a file, creating a folder, opening a new tab, etc. – the testers were able to quickly move through the scenarios. When an action did not produce obvious feedback, the testers became confused. These problems were especially evident when trying to create a bookmark or shortcut in the Nautilus file manager, but the program did not provide feedback, and did not indicate whether or not the bookmark had been created.
Usability is important in all software – but especially open source software. People shouldn’t have to figure out how to use a program, aside from specialized tools. Typical users with average knowledge should be able to operate most programs. If a program is too hard to use, the problem is more likely with the program than with the user. Run your own usability test, and apply the four themes for good usability, and make your open source project even better!
Jim Hall is a long-time open source software developer, best known for his work on the FreeDOS Project, including many of the utilities and libraries. Jim also wrote GNU Robots, and has previously contributed to other open source software programs including CuteMouse, GTKPod, Atomic Tanks, GNU Emacs, and Freemacs. At work, Jim is Director of Information Technology at the University of Minnesota Morris. Jim is also working on his M.S. in Scientific & Technical Communication (Spring 2014); his thesis is “Usability in Open Source Software.”