This book is about software usability engineering for Unix programmers, the presentational side of Unix software design. Its scope includes not only user interface (UI) design, but other related challenges such as making software easy to install, learn, and administer.

We choose the term “usability engineering” as a deliberate challenge to the all-too-prevalent notion that designing for usability demands special insight into areas like psychology or visual arts that are outside the scope of what programmers can do. We think the belief that usability engineering is a form of arcane magic best left to the exclusive province of specialists is both false and harmful, and is a passive but potent encouragement to slovenly interface design.

Just as damaging is the opposite assumption that usability engineering is trivial, and that usability can be sprayed on to a project after the design phase as though it were a coat of lacquer. The belief that security can be treated that way has caused no end of trouble as the Internet became a mass medium; similarly, the costs of after-the-fact attempts to spray on usability are rising as the potential audience of Linux and other Unixes expands to include more and more non-technical users.

We reject both extremes for the position that usability engineering should be considered a normal part of software design. There will always be a role for usability specialists, but basic competence in usability engineering can and should be part of every programmer's craft — even every Unix programmer's craft.

This book is aimed specifically at programmers operating within the Unix tradition, and especially for developers on modern open-source Unixes such as Linux. In The Art of Unix Programming we described the things Unix programmers do particularly well. In this book, on the other hand, we're going to delve into things Unix programmers have a long history of doing especially poorly. We think that deficit can and should be repaired.

Why start with Unix? The proximate cause is that the authors of this book understand how to address Unix programmers; we're writing for the audience we know. But more generally, we think that a book about usability engineering for Unix can be especially valuable because the Unix culture gets almost everything else right.

It has been famously claimed that all art aspires to the condition of music. If that's so, all operating systems seem to aspire just as insistently to the condition of Unix! One of the most persistent of the repeating patterns in the history of the field is large pieces of Unix getting grafted onto other environments (famously including Microsoft DOS, Microsoft Windows, and Mac OS 9) after their designers have run head-on into the limits of their original architectural model.

The planners behind Macintosh OS X noticed this, and concluded that it would work better to start from the solid architectural foundations of Unix and fix Unix's usability superstructure than to start from a highly usable but structurally weak operating system like Mac OS 9 and try to repair the foundations. The remarkable success of Linux at competing with Windows after 1995 suggests a similar conclusion.

As with architectures, so with architects. We believe Unix programmers who manage to integrate usability engineering into their craft will write fundamentally better software than usability-savvy programmers from other traditions trying belatedly to absorb Unix's architectural lessons in other areas like stability, security, and maintainability.

In the past, much of existing literature on software usability engineering has been tied to a specific non-Unix environment, or for other reasons written in an idiom that Unix programmers have trouble understanding. We began this book with the goal of bridging that gap.

We are aware that we are fighting a considerable weight of history in our attempt. Historically, hard-core Unix programmers have tended to be systems and networking hackers with little interest in — even an active disdain for — end-user applications and user interfaces. More specifically, the Unix culture has a long tradition of dismissing graphical user interfaces with the sour attitude recorded in the epigraph of this chapter.

In The Art of Unix Programming[TAOUP], we argued vigorously that there is more than a little justice in the anti-GUI case, and that Unix's tradition of command-line and scriptable interfaces has powerful virtues which have often tended to get lost in waves of consumer-oriented hype. But we think the rise of the Unix-centered open-source movement is making a big difference here. It has certainly made many people outside the Unix camp more willing than ever before to listen to the case for the old-school Unix gospel of the pipe, the script, and the command line. And we believe that it has made Unix programmers themselves less prickly and defensive, more willing to accept the best from the GUI tradition rather than dismissing it as gaudy trash. Modern open-source Unixes like Linux are observably GUI-intensive to a degree that would have been barely imaginable even a decade ago, and younger Linux programmers especially seem to be trying to find an accommodation that discards neither the GUI nor the best of the Unix old school.

We think, or at least hope, that the Unix community is ready to develop a healthy indigenous tradition of GUI design, one which does not merely imitate older models but integrates them with Unix's native design rules and best practices. We see promise for this project in the fact that Unix has often led the way in GUI technology and infrastructure even as it lagged badly in GUI design. We hope that this book will help systematize the ideas and insights that Unix community has been developing for itself and borrowing from elsewhere as it has slowly struggled to come to terms with the GUI.

More generally, we have written this book because we think we have detected signs that today's Unix community is ready to seriously take on usability issues — to accept them a challenge worthy of the same tremendous intelligence and effort that it has brought to its more traditional infrastructure concerns.

Our exposition will build on [TAOUP]). That book was an informal pattern language of Unix design, capturing Unix practice as it is. Much of it was concerned with developing a vocabulary (centered around terms like transparency, orthogonality, and discoverability) in which the implicit knowledge of the Unix tradition could be made explicit. In this book, we'll extend that vocabularity into the domain of usability engineering.

We'll use a combination of case studies with analysis similar to that in [TAOUP], and on a few topics we'll reuse bits of that book.^[1] However, the emphasis in this book will be very different. Where discussion of interfaces in [TAOUP] was primarily geared to explaining the persistence of non-visual interfaces for sophisticated users under Unix, we will be focusing here on the design of interfaces for nontechnical end-users, and specifically on graphical user interfaces (GUIs).

As with other aspects of design, usability engineering combines inspiration with learned skill. We can't supply the inspiration, but we can help you learn a vocabulary, some tools, and some technique.

One final note: The world is full of books about software design that urge programmers to swallow heavy methodological prescriptions like a dose of castor oil, grimly admitting that the stuff tastes nasty but insisting it's good for your character. This book is not one of those. We believe that one of the characteristics of great software designs, whether in the internals of code or its user interfaces, is playfulness. We believe that effective software-design methods are playful as well, because pleasure is what human beings experience when they are operating at their highest sustainable levels of effort and creativity.

Accordingly, we hope (and believe) that this book will not only teach you how to be a better programmer, but show you how to have new kinds of fun in the process. So when we say that we hope you'll enjoy this book, it is not just a conventional gesture of fond hope, it's actually our most serious methodological prescription. Enjoy what you learn here, because that's how you'll do a better job.