Jobs and Open Source Usability

A brief discussion concerning usability in open source. Despite views to the contrary, open source can be seen as a great testing ground for usability work.

Open Source Usability.

It appears that a bit of focus has been made on Linux Usability lately with articles by Eric Raymond here and a follow up here, and a reply by John Gruber here with comments on OS News here.


Like all the most interesting things in life, these matters are rarely as straight forward as they appear to be, and clearly the subject is one that touches close to my heart - after all, I've spent the last 4 1/2 years doing original research into HCI and usability (mostly of search engines but also of end-user applications) - so I've decided to respond to it. Whether anyone notices or cares though is a different matter! ;^)

The one aspect of all these that is apparent to me is the idea that open source is inherently ill-suited to generating usable software. The arguments in favour of this tend to revolve around the idea that usability is an art form that requires a dedicated effort from a usability expert (or a team of experts), and the argument is based on 2 premises: usability experts don't "do" open source projects, and dedicated effort is impossible for the open source development paradigm.

However, this argument reminds me of similar criticisms of the open source method when it first started becoming famous. These tended to follow the lines of "open source might be fine for small applications or scripts, but nothing major will ever come out of it." Clearly this argument is not true: open source has produced some very big and successful projects, from the Linux kernel upwards. Indeed, virtually the whole of the Debian distribution is built on open source software (aside: I am aware that a lot of the larger projects are funded commercially, like OpenOffice.org coming from Star Office which used to be proprietary, or Mozilla). Even Eric Raymond noted his surprise at seeing his first Linux distro working ("Open Sources: Voices from the Revolution").

So is there really a qualitative difference between software development (writing code) and UI design (designing interfaces)? An interesting comment from Eugenia Loli-Queru at the OS News website mentions her husbands fine work on BeOS which came about through regular contact and continual contact with the kernel engineer. This kind of setup is ideal and can lead to truly fantastic software being created. However, I sense that maybe there is a belief that interface design can only be done this way, and consequently any other method will crash and burn. For a long time, this idea was prevalent among open source skeptics, but the proof of the pudding is in the eating as they say, and Linux (for example) does work, so distributed software development can work.

But how can the distributed development model apply to something as artistic as UI design? The simple answer is that there are few examples of open source software being built with a usable design in mind, but it would be mistaken to confuse an absence of evidence for evidence of absence. As the OS community becomes more aware of end-user issues, focus on designing usable interfaces is becoming more important. Examination of the "help wanted" pages of SourceForge shows software in need of user interface experts.

But the experts aren't there, right? Well, there aren't that many involved right now, but they are there. MoreGroupWare (a php based groupware suite) recently advertised for help on the interface, and was rewarded with approximately 10 volunteers with many years of collective design experience from all areas of the field: from php coders wanting to increase their skills and learn a little, right through to the lead usability engineer for a large company with decades of experience at the sharp end of the business.

Clearly there are people around, and this situation may well improve in the future. After all, open source is a great place to get experience that looks good on a curriculum vitae: it shows motivation, an interest in the field, and a willingness to work with others as well as the chance to work on things that are outside of your normal experience.

But how well will the design process work within the distributed model of development? It should be remembered that the design process often doesn't work within completely commercial environments. With the exception of my own academic work, I have never worked on a project from inception (this is a refrain that I hear all too often in the field), though undoubtedly there companies with a more enlightened attitude that realise that HCI people are best employed from project inception.

The current success of the open source model in terms of generating code in undoubted, but there remains skepticism that this success will translate into the domain of interface design. In strict terms, there is no reason to assume this: just as developers don't need to work in close proximity in a well-ordered office, interface designers also do not need to work any more closely with other people in the project team than the code writers do.

But then, there is the issue of user testing. Open source, often being run by volunteers, cannot afford user testing, so this could be a problem. However, this ignores one obvious factor: the user base.

OS software is known for its user base being an effective source of bug reports, patches and feedback, and there are few reasons to assume that this population could not provide the same service for the user interface. The major point against this would, I imagine, be that the target audience of most developer tools differs from that of end-user applications. Fellow developers may be more likely to make an effective bug report than most end users, but this is just my assumption. It is worth noting that operating systems are increasingly encouraging feedback from end users. OpenOffice.org features a dialog to send a bug report to the project developers if it crashes for example.

Interface feedback can also be made this way. If users are willing to point out flaws in the design, any interface designers working on an open source project will have the breadth of usability feedback that most proprietary solutions can only dream of having. Of course, this leaves the problem of having to assess this information, but that's another story.

As counter-intuitive as it seems, user interface testing does not need to have user testing: methods have been developed to enable empirical assessments of interfaces (see the references for more information on how to use these methods). These methods are ways of examining an interface to work out how well it can be used. Of course, user testing is important, but in the early stages of the process, there can often be little need to have an amenable test population ready to hand.

Interface design is an iterative process. Often, a designer will produce several ideas for an interface, and fully expect to change them all at some point in the process. However, as long as the design process itself follows reasonable guidelines, there is often no more need to have the same designer in charge than it is to have the same coders working throughout a projects life.

In the real world, there are many restrictions on the quality of work that a designer can do, usually in terms of time, expenditure, and company politics. All of these can severely hamper the development of an effective design, but OS projects can offer benefits to interface designers. Because the open source development process is rarely time limited (rather, it's a continual process), the time factor becomes less of an issue which enables designers to really go to work. For any designers who are sick of doing hacked-up interfaces at work, I suggest trying an open source project for fun: you can really get the chance to do a bang-up job on something. Factors like having the marketing department nag you will be a thing of the past meaning you can lovingly construct the best interface you are capable of.

Finally, because an OS project might get a team of developers (like the MoreGroupWare example above), the skills and talents of the team will likely differ considerably. This diversity of opinions and backgrounds could well be a favour in exploring possibilities that a regular team may not be capable of.

I think OS can produce usable software. While at the moment this may not be as much in evidence as it could be, once more designers see the benefits of contributing, the future is certainly bright.

As a final note, it is worth noting that many programmers considered the open source development model as being incapable of producing anything of real value or size: indeed, some still do (reference). However, the truth is that open source has produced the kind of software that only a major company code hope to produce, and the barriers fall. Anyone care to bet against it this time?