Wednesday, September 26, 2012

Usability processes in open source software

David Nichols and Michael Twidale wrote an excellent article entitled Usability Processes in Open Source Projects that is an excellent match for my study. Nichols, D.M. & Twidale, M.B. (2003). The Usability of Open Source Software. First Monday 8(1).

They summarize how usability is a problem in open source software in four succinct points:
  1. Developers are not typical end users
  2. Usability experts usually do not get involved in open source software
  3. Open source projects often lack usability resources
  4. Developers do not approach interface design in the same way they do functionality design
I find this to be very true. In my own experience, I find that most open source projects are written by developers for other developers. That is, the developers are not typical end users. This may be okay if the developer is creating a developer tool, something so technical that "average" end users are unlikely to use it. But for the bulk of popular open source software, the developers are not like the typical end users. And unfortunately, open source software projects do not tend to attract usability experts.

Nichols and Twidale dicuss the complexity of open source software usability, saying the existence of certain usability bugs may be viewed as subjective and unreliable by open source developers. I view this as a cultural issue in the open source software community. As Nichole and Twidale mention, usability bugs just aren't perceived as having the same weight as functionality bugs. If a feature is broken, it needs to get fixed. If a feature is hard to use, you probably haven't read the manual.

You see this all the time in open source software projects. Bugzilla (a popular open source bug-tracking tool) allows bugs to be marked "WORKSFORME," which indicates the bug cannot be replicated by a developer. And usability bugs such as "this feature is hard to use" technically do work so often get closed with "WORKSFORME."

Nichols and Twidale's comment that "discussions need to involve complex design rationales, multiple, prehaps contradictory goals and design trade-offs" may be another indicator of cultural issues in open source software development. Many open source developers (certainly the ones I know) approach their work in a logical, ordered fashion. Design issues that involve trade-offs may be dismissed, in preference to work on bigger functionality enhancements.

The bug-reporting method needs to be different for usability bugs versus functionality bugs. Nichols and Twidale suggest creating mock-ups in HTML, "ASCII art," drawing packages, sketches, and interface design toolkits. After all, "a picture is worth a thousand words" - it's easier to show the problem and propose a solution via a simple drawing than to describe it in words.

So how can open source software projects improve their usability? Nichols and Twidale suggest several options:
  1. Improved bug reporting, by lowering the cultural, technical, and usability barriers. A usability "bug" tracking tool should be separate from a system that tracks functional bugs.
  2. Improved analysis of usability issues. In a 2003 study, Nichols and Twidale adocate creating a method for very small scale usability studies - as short as 10 minutes for a single user. [I am very interested in their suggestion. This may be helpful in a later phase of my study.] However, open source projects may be challenged in achieving consensus when changing an interface.
  3. Redesign work, and moving design work elsewhere. For example, "design by blog" may be used to offload design ideas from functional programming efforts. For example, Evolution (an open source email and calendar system) discusses design ideas on a separate blog. By working through different design ideas, and sharing mock-ups proposed by users, the blog can build consensus for new interfaces in a transparent way.

No comments:

Post a Comment