Weekend Discussion: Usability - Mozilla to West Palm Beach

Friday November 10th, 2000

We're all probably keenly aware that there were numerous usability problems (and here) with the balloting in West Palm Beach county during this Presidential election which created voting patterns which according to statisticians are, for all practical purposes, an impossibility.

Not going into questions of legitimacy regarding the vote, my questions to you are these: Can blame be placed when usability issues create incorrect or uncertain results? Is there remedy? Much has been said about usability issues in Mozilla - how does Mozilla's usability play a part in the developer/user relationship? Is there blame to be placed if a lack of usability testing creates an interface that's difficult for users to navigate? Do you think a correlation can be drawn between software UI usability and usability issues for paper interfaces like government forms or ballots? What responsiblity, if any, does the user hold for navigating a UI or form that suffers from serious usability issues?

#17 Two aspects of usability

by mpt <>

Sunday November 12th, 2000 3:30 AM

You are replying to this message

There are two aspects to designing a good user interface. These apply whether the user interface is a Web browser, an airplane cockpit, a nuclear power plant control room, an oven, or a ballot form.

The first aspect is making it easy for the user to do what they want to do. Most RFEs in Bugzilla concentrate on this aspect -- someone thinks `hey, wouldn't it be cool if I could do this ...', so they suggest it. This can be good, if a majority of users are *expecting* to find this feature or option in the part of the UI where it is added.

But if too many features or options get added, the user's ability to find each one diminishes, as there is more UI for them to wade through, so usability as a whole goes down. In addition, things like price, memory requirements, and startup time tend to increase, also harming usability.

The classic example of this is Microsoft Word. Festooned with rarely-used and nearly-useless features like movable menu bars and AutoSummarize, getting to the basic features becomes harder and harder. And the extra features which are added to try to solve this problem (such as dancing paper clips, and personalized menus) tend to make it worse rather than better.

The second aspect to usability, which is often neglected, is the converse of the first: making it hard for the user to do what they *don't* want to do.

A simple example will illustrate. One day while using mIRC to chat in #mozilla, I entered a comment, pressed Enter, and nothing happened. So I did what any human would do, and what often works on devices other than computers: I tried the same thing again. Only when it still didn't work did I realize that the channel log was not scrolled to the bottom. When I scrolled it down, I found that my comment had actually been entered twice.

Yes, I felt foolish, but I was at least partly a victim of a usability problem in Windows: in Windows scrollbars, the scrollbar thumb is a similar color to the rest of the scrollbar, so it is not obvious (when looking at the scrollbar out of the corner of your eye) what position you are scrolled to. If the scrollbar thumb was a different color from the rest of the scrollbar, I would have seen that I was not scrolled to the bottom of the channel log, and my mistake could have been avoided.

These two aspects of usability are often in conflict. By making it easier for the user to do things that they want to do, you often also make it easier for them to do things which they *don't* want to do. The more toolbar buttons you have, for example, the smaller each one has to be, the longer it takes to find the one you are looking for, and the greater the likelihood of hitting the wrong one. Even so, it's scary how many of the RFEs filed in Bugzilla ask for a new toolbar button, a new context menu item, or some other bit of new UI, rather than removing or rearranging bits of UI which already exist.

There are several factors which threaten to give Mozilla poor usability. Some of them apply to all software projects, but others are especially acute in free software projects. Briefly, they are as follows.

* Software developers (and people who try out milestone and nightly builds) tend to be considerably more computer-savvy than the average user. As such, they can figure out bad user interfaces (designed by fellow developers) more easily than ordinary users can, so they may not see what all the fuss is about when people talk about usability problems.

* Developers may be obsessed with technology for the sake of technology, and may seek technological solutions which cause more problems than they solve. Example: At the local shopping mall, the toilets have water taps which use sensors to turn on when you put your hand under them. Very cool -- except that every single person (who hasn't used them before) wastes 5 or 10 seconds trying to figure out how the darn things work, because they're inconsistent with 99 % of other water taps. So people end up wasting much more time than they save. (And I bet the sensors won't work during a power cut, either.)

* Reviewers often concentrate on the number of features an application has, rather than how easy it is to use, and they compare it with other applications on this basis. This tends to encourage feature creep at the expense of ease of use.

* For a volunteer contributor, adding a new feature (with its own UI) is a considerably more attractive prospect than modifying existing UI to help prevent user mistakes.

* The person who designed the UI for a particular feature knows that feature inside out, so may be unable to believe that a considerable proportion of users have trouble with the feature until they are confronted with video footage of people trying to use it.

* Because free software projects are largely made up of volunteers, they rarely have the ability to carry out methodical usability testing.

* Finally, Mozilla is a cross-platform app implemented with a cross-platform UI toolkit. This makes it harder to implement many subtle platform-specific UI behaviors, which are needed in order to make Mozilla consistent with other applications on the user's computer.

-- mpt