Usability and Open Source Software


This is an interesting report from David M. Nichols and Michael B. Twidale, Department of Computer Science University of Waikato, Hamilton, New Zealand.

They give a deep consideration on usability in Open Source Software.

I just like to publish this excerpt:

...

Developers are not users

This is a key point of Nielsen (1993), and is one shared with commercial systems developers. Teaching computer science students about usability issues is in our experience chiefly about helping them to try and see the use of their systems through the eyes of other people unlike themselves and their peers. In fact, for many more advanced OSS products, developers are indeed users, and these esoteric products with interfaces that would be unusable by a less technically skilled group of users are perfectly adequate for their intended elite audience. Indeed there may be a certain pride in the creation of a sophisticated product with a powerful, but challenging to learn interface. Mastery of such a product is difficult and so legitimates membership of an elite who can then distinguish itself from so-called 'lusers' (Raymond and Steele, 1991, p. 364). Trudelle (2002) comments that 'the product [a web browser] should target people whom they [OSS contributors] consider to be clueless newbies.'

However when designing products for less technical users, all the traditional usability problems arise. In the Greenstone study (Nichols et al., 2001) common command line conventions, such as a successful command giving no feedback, confused users. The use of the terms 'man' (from the Unix command line), when referring to the help system, and 'regexp' (regular expression) in the GNOME interface are typical examples of developer terminology presented to end-users (Smith et al., 2001).

The OSS approach fails for end user usability because there are 'the wrong kind of eyeballs' looking at, but failing to see, usability issues. In some ways the relatively new problem with OSS usability reflects the earlier problem with commercial systems development: initially the bulk of applications were designed by computing experts for other computing experts, but over time an increasing proportion of systems development was aimed at non-experts and usability problems became more prominent. The transition to non-expert applications in OSS products is following a similar trajectory, just a few years later.

The key difference between the two approaches is this: commercial software development has recognised these problems and can employ specific HCI experts to 're-balance' their processes in favour of users (Frishberg et al., 2002). However, volunteer-led software development does not have the ability to hire in missing skill sets to ensure that user-centred design expertise is present in the development team.

Usability experts do not get involved in OSS projects

Anecdotal evidence suggests that few people with usability experience are involved in OSS projects; one of the 'lessons learned' in the Mozilla project (Mozilla, 2002) is to 'ensure that UI [user interface] designers engage the Open Source community' Trudelle (2002). Open source draws its origins and strength from a hacker culture (O'Reilly, 1999). This culture can be extremely welcoming to other hackers, comfortably spanning nations, organisations and time zones via the Internet. However it may be less welcoming to non-hackers.

Good usability design draws from a variety of different intellectual cultures including but not limited to psychology, sociology, graphic design and even theatre studies. Multidisciplinary design teams can be very effective, but require particular skills to initiate and sustain. As a result, existing OSS teams may just lack the skills to solve usability problems and even the skills to bring in 'outsiders' to help. The stereotypes of low hacker social skills are not to be taken as gospel, but the sustaining of distributed multidisciplinary design teams is not trivial.

There are several possible explanations for the non-participation of HCI and usability people in OSS projects:

  • There are far fewer usability experts than hackers, so there just are not enough to go around.
  • Usability experts are not interested in, or incentivised by the OSS approach in the way that many hackers are.
  • Usability experts do not feel welcomed into OSS projects.
  • Inertia: traditionally projects haven't needed usability experts.
  • There is not a critical mass of usability experts involved for the incentives of peer acclaim and recruitment opportunities to operate.

...

3 Comments

  • Something I have been saying for a long time. Nice to see someone a little more "official" agreeing :-).

  • Jesse that's why I blog this, because it's a current issue in some projects I am linked to.





    OSS has a long way to go ;-)

  • Interesting article. At the moment on a dutch programmers forum there is a discussion going on about 'build tools', and I ventilated my opinion about how horrible they are to use because they are mostly without an interface and work with an own fileformat, have no handy tools and leave a lot to the user (NAnt). Clearly the developers of these tools think what they think is right, is what the users of their tools want. Which is not the case, since developers are users, namely the users of the tools they use to build the software. The major error OSS projects (I refered to NAnt above) make is that the developers who write the software think what they seem to find reasonable for 'developers' (f.e. the target audience) is also what these 'developers' think will find reasonable. But when you consider 'developers' as 'users', i.e. they do task ABC very well, but lack skills in task XYZ, most OSS projects fall short (also a lot of closed source software projects).





    It takes a lot of time to make software that is useful for the developer who writes it also useful for another user who uses that tool to avoid extra work because it is 'overhead' for that person.

Comments have been disabled for this content.