The Art of Unix Usability

In [TAOUP] we introduced five basic metrics to categorize the quality of interfaces: concision, expressiveness, ease, transparency, and scriptability.

Concise interfaces have a low upper bound on the length and complexity of actions required to do a transaction; the measurement might be in keystrokes, gestures, or seconds of attention required. Concise interfaces get a lot of leverage out of relatively few controls.

Expressive interfaces can readily be used to command a wide variety of actions. Sufficiently expressive interfaces can command combinations of actions not anticipated by the designer of the program, but which nevertheless give the user useful and consistent results.

The difference between concision and expressiveness is an important one. Consider two different ways of entering text: from a keyboard, or by picking characters from a screen display with mouse clicks. These have equal expressiveness, but the keyboard is more concise (as we can easily verify by comparing average text-entry speeds). On the other hand, consider two dialects of the same programming language, one with a Unicode-string type and one not. Within the problem domain they have in common, their concision will be identical; but for anyone concerned with internationalization, the dialect with Unicode characters will be much more expressive.

Ease is inversely proportional to the mnemonic load the interface puts on the user — how many things (commands, gestures, primitive concepts) the user has to remember specifically to support using that interface. Programming languages have a high mnemonic load and low ease; menus and well-labeled on-screen buttons are easier to learn and use, but usually trade away concision or expressiveness for this virtue.

Transparent interfaces don't require the user to remember the state of his problem, his data, or his program while using the interface. An interface has high transparency when it naturally presents intermediate results, useful feedback, and error notifications on the effects of a user's actions. So-called WYSIWYG (What You See Is What You Get) interfaces are intended to maximize transparency, but can sometimes backfire — especially by presenting an over-simplified view of the domain.

Discoverable interfaces make it easy for the user to form and maintain a mental model not of the problem domain, but of the user interface itself. Discoverable interfaces usually leverage the user's understanding of the problem domain to help them figure out the controls. Various forms of assistance like on-screen labels, context sensitive help, or explanatory balloon popups can increase discoverability. But more important are qualities like the ability to experiment without damaging anything, and immediate feedback to let the user know what they just did when they try something. A truly discoverable interface makes the relationship between the controls and the task they perform intuitively obvious, and rewards experimentation rather than punishing it.

These virtues also have negative formulations in terms of staying out of the user's way. A concise interface doesn't get in the way by forcing the user to wade through a lot of waste motion to get the work done. An expressive interface doesn't get in the way by imposing the programmer's preconceptions about what the user is there to accomplish and how they're likely to go about it. An interface with ease doesn't get in the way by requiring users to learn and remember lots of non-obvious controls. A transparent interface doesn't get in the way by obscuring the state of the problem. A discoverable interface doesn't get in the way by requiring the user to attend a training course or read a manual.

For completeness, we'll note that scriptable interfaces is are those which are readily manipulated by other programs. Scriptability reduces the need for costly custom coding and makes it relatively easy to automate repetitive tasks. Scriptability will not be a major theme in this book; see [TAOUP], instead, for an in-depth discussion.

Usability is not one thing. It's actually a relationship between a program and its audiences. A program's usability changes as the audience changes; in particular, best practices for usability engineering change as its audiences' degrees of investment in the task and the software changes. We'll find it useful, later on, to distinguish at least four different kinds of user from each other.

The nontechnical end-user has very little knowledge of either the application domain of your program or of computers and software in general, and is probably not very interested in acquiring more of either. Most users of ATMs (automatic teller machines), for example, fall in this category.

The domain expert has a lot of domain knowledge about the application your program addresses, but is unsophisticated about computers. Domain experts are usually motivated to learn more about their domain, but not necessarily about computers in general.

The power user has a lot of experience with computers and different kinds of software, but limited domain-specific knowledge. Power users (like domain experts) are often willing to learn more about what they are already good at, but may resist acquiring more domain knowledge.

The wizard or guru is strong in both domain-specific and general computer knowledge, and is willing to work at getting more of either.

Of course, the degree to which any one persion is a domain expert varies with the domain. And even wizards don't want to have to be wizards all the time; even a software guru who enjoys programming (say) printer drivers usually just wants to press a button and have the printer print without fuss or fiddling.

Nevertheless, these four categories do define a power curve — nontechnical end-users at the low end, wizards at the high end, domain experts and power users in the middle. Their requirements and the kinds of interfaces that make them comfortable will differ. Just as importantly, an individual's requirements will change as he or she climbs the power curve.

In [TAOUP] we noted that while nontechnical end-users value ease most, wizards will trade that away to get expressiveness and concision. In this book we'll explain and analyze that tradeoff further, focusing on the tension between task-oriented and feature-oriented interfaces.

Many collections of user interface guidelines focus on the visual and presentational level of UI design — representative advice of this kind is to avoid using color alone to convey critical information, because about 10% of users have some variety of color blindness. Advice like this has its place, and we'll convey a good deal of it later in the book, but treatments that go at the UI design problem from the outside in often fail to engage deeper issues. The rules we choose to begin this book with are quite deliberately different — structural and logical, working from the inside out and (we believe) grounded in deep properties of the evolved nature of human beings.

These rules of usability are actually rules for programmers, who (almost by definition) are either power users or wizards. They are therefore aimed at programmers looking down the power curve, designing for an audience of domain experts and nontechnical end-users. But as we've already seen, even wizards are in the end-user position much of the time (especially when operating outside the specific realm of their domain knowledge). Therefore, you should consider these rules applicable for designing any program with an interactive interface.

We'll summarize the rules here, noting parallels with the Unix design rules from The Art of Unix Programming. While these rules are implicit in most good treatments of user-interface design, many have never before been written down explicitly. The rest of this book will unfold the implications and consequences of these rules.

After settling on the term “usability engineering” and writing down all but one of the design rules in the previous section, we discovered that there had been one previous attempt widely respected among specialists in the field to capture what is known about software interface design in a collection of rules. This was a set of heuristics proposed in a 1990 paper [Nielsen&Molich] and further developed in Jakob Nielsen's 1994 book Usability Engineering [Nielsen].

Upon inspection, we discovered that our approach converges with Nielsen's to a remarkable degree. The few marked differences are as instructive as the similarities. We'll therefore walk through Nielsen's heuristics here, and later in this book we'll propose an adaptation of the Nielsen-Molich heuristic evaluation method that should be readily applicable even given the decentralized organization characteristic of many of today's Unix projects.

Missing from Nielsen's heuristics are the Rule of Bliss, the Rule of Distraction, the Rule of Flow, the Rule of Seven, the Rule of Confirmation, the Rule of Automation, the Rule of Defaults, the Rule of Respect, and the Rule of Reality; however, the Rule of Reality is strongly implicit in the rest of the Nielsen-Molich method. We have no rule that directly corresponds to Nielsen's heuristics “Error prevention” and “Flexibility and efficiency of use”

Part of the reason we set more rules is that we have a decade more of experience, during which some fundamentals of the problem have become clearer. Another reason, though, is that Nielsen's approach is like that of most other interface design gurus (such as Bruce Tognazzini, today's principal exponent of the Macintosh style) in that it works from the outside inwards, where ours works from the inside outwards. We are more influenced both by the Unix tradition of system design from the internals outwards, and by attacks on the UI design problem like [Raskin] that seek to generate design rules not just by empirical observation but from considerations of the deep structure of human cognition.

As we learn more, the similarities between outside-in prescriptions like Jakob Nielsen's and Bruce Tognazzini's (on the one hand) and inside-out prescriptions like ours and Jef Raskin's (on the other) increase. The most basic thing both approaches have in common is the understanding that, ultimately, excellence in user-interface design comes from identifying with the user's experience.

Keeping the internals of code simple is at the heart of what it means to think like a programmer, especially a Unix programmer. But keeping interfaces simple demands the opposite discipline — learning how not to think like a programmer, and instead thinking like the end-users that you are serving. Interfaces that are really smart match the needs of those users.

Identifying with the end-user is a difficult and humbling task for many programmers. But if you nerve yourself to the effort, you may find great satisfaction in writing programs which are as responsive and intuitive from the outside as they are elegant within. The ultimate test of software (as with any other tool) is how well it serves human beings, and it is in serving other human beings that we reach the true zenith of craftsmanship.

If that's too abstract and idealistic for you, think of this. No matter how skilled you are, there are many times when you will be the end user. When you give yourself standing to demand good UI design from others by setting an example of good UI design yourself, the time and sanity you save will ultimately be your own. At the zenith of craftsmanship, through serving others you serve yourself — and vice-versa.

To reach that zenith, go back to zero. In [TAOUP] we used some ancient ideas from Zen Buddhism to illuminate the craft of writing code. Here is one that applies to user-interface design: beginner's mind. “Beginner's mind” is the stance that approaches a task with no assumptions, no habits, perfect ignorance awaiting experience. Achieving beginner's mind involves forgetting what you know, so that you can learn beyond the limits of what you know.

To design interfaces for end-users — to keep them simple, stupid — approach the interface-design task with beginner's mind.

In the batch era, computing power was extremely scarce and expensive. The largest computers of that time commanded fewer logic cycles per second than a typical toaster or microwave oven does today, and quite a bit fewer than today's cars, digital watches, or cellphones. User interfaces were, accordingly, rudimentary. Users had to accommodate computers rather than the other way around; user interfaces were considered overhead, and software was designed to keep the processor at maximum utilization with as little overhead as possible.

The input side of the user interfaces for batch machines were mainly punched cards or equivalent media like paper tape. The output side added line printers to these media. With the limited exception of the system operator's console, human beings did not interact with batch machines in real time at all.

Submitting a job to a batch machine involved, first, preparing a deck of punched cards describing a program and a dataset. Punching the program cards wasn't done on the computer itself, but on specialized typewriter-like machines that were notoriously balky, unforgiving, and prone to mechanical failure. The software interface was similarly unforgiving, with very strict syntaxes meant to be parsed by the smallest possible compilers and interpreters.

Figure 2.1. IBM 029 card punch.

Once the cards were punched, one would drop them in a job queue and wait. Eventually. operators would feed the deck to the computer, perhaps mounting magnetic tapes to supply a another dataset or helper software. The job would generate a printout, containing final results or (all too often) an abort notice with an attached error log. Successful runs might also write a result on magnetic tape or generate some data cards to be used in later computation.

The turnaround time for a single job often spanned entire days. If one were very lucky, it might be hours; real-time response was unheard of. But there were worse fates than the card queue; some computers actually required an even more tedious and error-prone process of toggling in programs in binary code using console switches. The very earliest machines actually had to be partly rewired to incorporated program logic into themselves, using devices known as plugboards.

Early batch systems gave the currently running job the entire computer; program decks and tapes had to include what we would now think of as operating-system code to talk to I/O devices and do whatever other housekeeping was needed. Midway through the batch period, after 1957, various groups began to experiment with so-called “load-and-go” systems. These used a monitor program which was always resident on the computer. Programs could call the monitor for services. Another function of the monitor was to do better error checking on submitted jobs, catching errors earlier and more intelligently and generating more useful feedback to the users. Thus, monitors represented a first step towards both operating systems and explicitly designed user interfaces.

Command-line interfaces (CLIs) evolved from batch monitors connected to the system console. Their interaction model was a series of request-response transactions, with requests expressed as textual commmands in a specialized vocabulary. Latency was far lower than for batch systems, dropping from days or hours to seconds. Accordingly, command-line systems allowed the user to change his or her mind about later stages of the transaction in response to real-time or near-real-time feedback on earlier results. Software could be exploratory and interactive in ways not possible before. But these interfaces still placed a relatively heavy mnemonic load on the user, requiring a serious investment of effort and learning time to master.

Command-line interfaces were closely associated with the rise of timesharing computers. The concept of timesharing dates back to the 1950s; the most influential early experiment was the MULTICS operating system after 1965; and by far the most influential of present-day command-line interfaces is that of Unix itself, which dates from 1969 and has exerted a shaping influence on most of what came after it.

The earliest command-line systems combined teletypes with computers, adapting a mature technology that had proven effective for mediating the transfer of information over wires between human beings. Teletypes had originally been invented as devices for automatic telegraph transmission and reception; they had a history going back to 1902 and had already become well-established in newsrooms and elsewhere by 1920. In reusing them, economy was certainly a consideration, but psychology and the Rule of Least Surprise mattered as well; teletypes provided a point of interface with the system that was familiar to many engineers and users.

Figure 2.2. ASR-33 Teletype.

The widespread adoption of video-display terminals (VDTs) in the mid-1970s ushered in the second phase of command-line systems. These cut latency further, because characters could be thrown on the phosphor dots of a screen more quickly than a printer head or carriage can move. They helped quell conservative resistance to interactive programming by cutting ink and paper consumables out of the cost picture, and were to the first TV generation of the late 1950s and 60s even more iconic and comfortable than teletypes had been to the computer pioneers of the 1940s.

Figure 2.3. VT100 terminal.

The VT100, introduced in 1978, was probably the single most popular and widely imitated VDT of all time. Most terminal emulators still default to VT100 mode.

Just as importantly, the existance of an accessible screen — a two-dimensional display of text that could be rapidly and reversibly modified — made it economical for software designers to deploy interfaces that could be described as visual rather than textual. The pioneering applications of this kind were computer games and text editors; close descendants of some of the earliest specimens, such as rogue(6), and vi(1), are still a live part of Unix tradition.

Screen video displays were not entirely novel, having appeared on minicomputers as early as the PDP-1 back in 1961. But until the move to VDTs attached via serial cables, each exceedingly expensive computer could support only one addressable display, on its console. Under those conditions it was difficult for any tradition of visual UI to develop; such interfaces were one-offs built only in the rare circumstances where entire computers could be at least temporarily devoted to serving a single user.

We took the the trouble to describe batch computing in some detail because in 2004 this style of user interface has been dead for sufficiently long that many programmers will have no real idea what it was like. But if some of the above seems nevertheless familiar, it may be be because many of the behavioral characteristics of batch systems are curiously echoed by a very modern technology, the World Wide Web. The reasons for this have lessons for UI designers.

JavaScript, Java, and Flash support limited kinds of real-time interactivity on web pages. But these mechanisms are fragile and not universally supported; the Common Gateway Interface — Web forms — remains the overwhelmingly most important way for web users to do two-way communication with websites. And a Web form fed to a CGI behaves much like the job cards of yesteryear.

As with old-style batch systems, Web forms deliver unpredictable turnaround time and cryptic error messages. The mechanisms for chaining forms are tricky and error-prone. Most importantly, web forms don't give users the real-time interactivity and graphical point-and-shoot interface model they have become used to in other contexts. Why is this?

Batch systems were an adaptation to the scarcity of computer clock cycles; the original computers had none to spare, so only a bare minimum went to impedance-matching with the brains of humans. Web forms are primitive for an equally good reason, but the controlling scarcity was one of network bandwidth. In the early 1990s when the Web was being designed, the cabling and switching fabric to support millions of real-time-interactive remote sessions spanning the planet did not exist. The deficit wasn't so much one of bandwidth (available bits per second of throughput) but of latency (expected turnaround time for a request/response).

The designers of CGI knew most of their users would be using connections with serious latency problems, on communications links that often dropped out without warning. So they didn't even try for real-time interactivity. Instead, the interaction model for the Web in general and web forms in particular is a discrete sequences of requests and responses, with no state retained by the server between them.

The batch-to-CGI correspondence is not perfect. The batch analog of dropped connections — permanent interruptions in the act of feeding cards into a machine, as opposed to just unpredictable delays — was relatively rare. And one of the reasons the CGI model is stateless on the server side is because retaining even small amounts of session state can be cost-prohibitive when you might have thousands or millions of users to deal with daily, not a problem batch systems ever had. Still, the analogy does help explain why the Web was not designed for real-time interactivity.

Today, in 2004, it is largely demand for the Web that has funded the build-out of the Internet to the point where massive real-time interactivity is thinkable as more than a pipe dream. We're still not there; latency and bandwidth constraints are still severe, as anyone who has watched the slow and stuttering progress of a video download can attest.

The lesson here is that the batch processing style is still adaptive when latency is large and unpredictable. We may almost solve that problem for the planetary Web in the next few decades, but there are fundamental physical reasons it cannot be banished entirely. The lightspeed limit is perhaps the most fundamental; it guarantees, among other things, that round-trip latency between points on the Earth's surface has a hard lower bound of a bit over a seventh of a second. ^[7] In practice, of course, switching and routing and computation add overhead. Nor would it be wise to assume that the Internet will forever remain limited to Earth's surface; indeed, satellite transmission has been handling a significant percentage of international traffic since the 1970s.

The command-line style has also persisted, for reasons we discussed in depth in [TAOUP]. It will sufficient to note here that the reasons for the survival of this style are not just technical constraints but the fact that there are large classes of problems for which textual, command-line interfaces are still better-suited than GUIs. One of the distinguishing traits of Unix programmers is that they have retained sophisticated styles of command-line design and already understand these reasons better than anyone outside the Unix tradition, so we will pass over pro-CLI arguments lightly in this book.

There is a subtler lesson to be drawn from these survivals. In software usability design, as in other kinds of engineering, it is seldom wise to dismiss an apparently clumsy or stupid design by assuming that the engineers of bygone days were idiots. Though engineers, being human, undeniably are idiots on occasion, it is far more likely in the normal course of events that a design you find ridiculous after the fact is actually an intelligent response to tradeoffs you have failed to understand.

There were sporadic experiments with what we would now call a graphical user interface as far back as 1962 and the pioneering SPACEWAR game on the PDP-1. The display on that machine was not just a character terminal, but a modified oscilloscope that could be made to support vector graphics. The SPACEWAR interface, though mainly using toggle switches, also featured the first crude trackballs, custom-built by the players themselves.^[8]. ITen years later, in the early 1970s these experiments spawned the video-game industry, which actually began with an attempt to produce an arcade version of SPACEWAR.

The PDP-1 console display had been descended from the radar display tubes of World War II, twenty years earlier, reflecting the fact that some key pioneers of minicomputing at MIT's Lincoln Labs were former radar technicians. Across the continent in that same year of 1962, another former radar technician was beginning to blaze a different trail at Stanford Research Institute. His name was Doug Engelbart. He had been inspired by both his personal experiences with these very early graphical displays and by Vannevar Bush's seminal essay As We May Think [Bush], which had presented in 1945 a vision of what we would today call hypertext.

In December 1968, Engelbart and his team from SRI gave a 90-minute public demonstration of the first hypertext system, NLS/Augment.^[9] The demonstration included the debut of the three-button mouse (Engelbart's invention), graphical displays with a multiple-window interface, hyperlinks, and on-screen video conferencing. This demo was a sensation with consequences that would reverberate through computer science for a quarter century, up to and including the invention of the World Wide Web in 1991.

So, as early as the 1960s it was already well understood that graphical presentation could make for a compelling user experience. Pointing devices equivalent to the mouse had already been invented, and many mainframes of the later 1960s had display capabilities comparable to those of the the PDP-1. One of your authors retains vivid memories of playing another very early video game in 1968, on the console of a Univac 1108 mainframe that would cost nearly forty-five million dollars if you could buy it today in 2004. But at $45M a throw, there were very few actual customers for interactive graphics. The custom hardware of the NLS/Augment system, while less expensive, was still prohibitive for general use. Even the PDP1, costing a hundred thousand dollars, was too expensive a machine on which to found a tradition of graphical programming.

Video games became mass-market devices earlier than computers because they ran hardwired programs on extremely cheap and simple processors. But on general-purpose computers, oscilloscope displays became an evolutionary dead end. The concept of using graphical, visual interfaces for normal interaction with a computer had to wait a few years and was actually ushered in by advanced graphics-capable versions of the serial-line character VDT in the late 1970s.

If full vector graphics and the custom hardware needed for systems like NLS/Augment was too expensive for general use, character VDTs were too crude. Today's nethack(6) game, run on a color terminal emulator or console, is well representative of the best that advanced VDTs of the late 1970s could do. They hinted at what was possible in visual-interface design, but proved inadequate themselves.

There were several reasons character VDTs came up short that bear on issues still relevant to today's UI designers. One problem was the absence of an input device that was well matched to the graphics display capability; several early attempts, such as light pens, graphic tablets, and even joysticks, proved unsatisfactory. Another was that it proved difficult to push enough bits per second over the line to do serious graphics. Even after VDTs acquired the capability to write pixels as well as formed characters, running GUIs on them remained impractical because serial lines had a peak throughput far too low to support frequent screen repainting.

For reasonable update speed, graphics displays really need to be coupled more closely to the machine that is doing the rendering than a serial connection will allow. This is especially true if one needs to support the kind of high interactivity and frequently changing displays characteristic of games or GUIs; for this, only direct memory access will do. Thus, the invention of the GUI had to wait until developments in silicon integrated circuits dropped the cost of computing power enough that a capable processor could be associated with each display, and the combination had become sufficiently inexpensive that machines could be dedicated to individuals' use.

The other missing piece was Engelbart's invention of the mouse — and, just as significantly, the visible mouse pointer. This more controllable inversion of the large, crude early trackballs meant that users could have a repertoire of two-dimensional input gestures to match the two-dimensional screen. It made interfaces based on direct visual manipulation of objects on-screen feasible for the first time.

Figure 2.4. The Xerox Alto.

The input device on the left appears to be a touch tablet, a mouse alternative similar to the trackpads on modern portables.

NLS/Augment had shown what was possible, but the engineering tradition behind today's GUIs was born at the Xerox Palo Alto Research Center (PARC) around the same time character-cell VDTs were becoming generally available in the rest of the world. Inspired by Engelbart's 1968 demo, in 1973 the PARC researchers built a pioneering machine called the Alto that featured a bit-mapped display and a mouse. and was designed to be dedicated to the use of one person. It wasn't called either a “workstation” or a “personal computer”, but it was to become a direct ancestor of both. (At around the same time PARC gave birth to two other technologies that would grow in importance along with the GUI; the Ethernet and the laser printer.)

From today's post-Alto point of view, screen shots of the Alto UI show a curious mix of modernity and crudity. What's present are all the logical components of GUIs as we know them — icons, windows, scrollbars, sliders, and the like. The main GUI element missing, in fact, is the pull-down menu (introduced by the Apple Lisa in 1979). What's missing, most conspicuously, is color. Also, the pseudo-3D sculptural effects of modern GUI buttons and other impedimenta are missing; the widgets are flat outline boxes, and the whole resembles nothing so much as an etch-a-sketch drawing of a modern interface. It's a little sobering to reflect that most of what we have learned to add to GUIs since 1973 is eye candy.

Figure 2.5. Alto running the Executive file browser (c.1974).

It was not until the early 1980s that the implications of the PARC work would escape the laboratory and start to really transform human-computer interaction. There is no shortage of good accounts of that transformation, but most of them tend to focus on personal computers and the history of Apple, giving scant notice to the way the change interacted with and affected the Unix tradition. After 1990, however, and especially after 2000, the stories of Unix, the PC, and the GUI began to re-converge in ways that would have deeply surprised most of their early partisans. Today, a Unix-centered take on the history of user interfaces, even GUIs, turns out to be a much less parochial view than one might have supposed ten or even five years ago.

The entire story is a marvelous lesson for user-interface designers in how design innovation doesn't happen in a vacuum. UI design is no more separable than other forms of engineering and art from the accidents of history and the constraints of economics; understanding the complex and erratic way that we got where we are may be a real help to readers who want to think about their design problems not simply as exercises but as responses to human needs.

One skein of the story begins with the internal developments at Xerox PARC. The Alto begat the Dolphin, Dorado, Dandilion, Dragon, and Danditiger (an upgrade of the Dandilion). These “D-machines” were a series of increasingly powerful computers designed to exchange information over a prototype Ethernet. They had bitmapped displays and three-button mice. They featured a GUI built around overlapping windows, first implemented on the Alto as a workaround for the small size of its display. They had early connections to the ARPANET, the predecessor of the Internet.

These machines were tremendously influential. Word of them spread through the computer-science community, challenging other groups of designers to achieve similarly dramatic capabilities. Famously, in 1979 Steve Jobs was inspired to start the line of development that led to the Apple Macintosh after visiting PARC and seeing the Alto and D-machines in action there. Less often told is that Jobs had been pre-primed for his epiphany by Apple employee Jef Raskin, whose 1967 thesis had inspired some of the PARC research. Raskin had a keen interest in advanced UI design and wanted to find some of the PARC concepts a home at Apple so he could continue pursuing them.

One of the effects of the Alto was to popularize bit-mapped rather than vector-graphics displays. Most earlier graphics hardware had been designed to explicitly draw points, lines, arcs, and formed characters on a display, an approach which was relatively slow but economical because it required a minimum of expensive memory. The Alto approach was to hang the expense and drive each screen pixel from a unique location in a memory map. In this model almost all graphics operations could be implemented by copying blocks of data between locations in memory, a technique named BitBlt by its inventors at PARC. BitBlt simplified graphics programming enormously and played a vital role in making the Alto GUI feasible.

The very first commercialization of this technology seems to have been a machine called the Perq^[10] aimed primarily at scientific laboratories. The Perq's dates are difficult to pin down, but an early sales brochure ^[11] seems to establish that these machines were already being sold in August 1979; other sources claim that due to production delays they first shipped in November 1980. The Perq design featured the same style of portrait-mode high resolution display as the Alto. It was quite a powerful machine for its time, using a microcoded bit-slice processor with a dedicated BitBlt instruction, and some Perqs remained in use as late as 2001. It supported at least five operating systems, including (later in the 1980s) at least three in the Unix family. Curiously, however, the designers seem to have discarded the mouse and retained only the touch tablet.

The inventors of Unix at Bell Labs were not slow to take notice of the Alto and its BitBlt technique. In 1981 they built a machine originally called the “Jerq”^[12] and later renamed to “Blit” at management insistance. Like the Alto the Blit had a mouse, a bit-mapped screen, and a powerful local processor (in this case, a Motorola 68000). Unlike the Alto or Perq, it was designed to act as a smart terminal to a Unix minicomputer rather than for a network communicating directly with peer machines.

This difference in architecture reflected a basic difference in aims. While the PARC crew was free to reinvent the world, the Unix developers had history they were not interested in discarding. Plan 9, their successor to the Unix operating system, retained the ability to run most Unix code. The Blit, later commercialized at the AT&T 5620, was an amphibian — it could act as a conventional smart terminal, or it could download software from its host machine that would give it many of the GUI capabilities of an Alto or D-machine. Outside of Bell Labs and the special context of Plan 9 this amphibian was a solution that never found a problem, and the Unix community's first attempt at integrating a PARC-style interface sank into obscurity.

A few years later, however, Blit-like machines with local-area-network jacks and the character-terminal features discarded would rise again, as the X terminal.

Figure 2.6. The Xerox Star (1981).

That same year, in 1981, Xerox finally brought a machine based on the PARC technology to market. It was called the Xerox Star,^[13] and it was a failure. Technically, it was woefully underpowered, slow, and overpriced. Hesitant and inept marketing did not help matters. Many of the developers, sensing more willingness from Apple and other emerging PC companies to push the technology, had started to bail out of PARC in 1980; the failure of the Star accelerated the process. Xerox, despite having pioneered the GUI and several of the other key technologies of modern computing, never turned a profit from them.

Figure 2.7. Screen shot from a Star (1981).

The Star interface pioneered the desktop metaphor that would be ubiquitous in later GUIs.

The third key event of 1981 was the first IBM personal computer. This did not advance the state of the art in GUIs — in fact, the original PC-1 had graphics capability available only as an extra-cost option, and no mouse. Its slow 8088 microprocessor could not have supported a PARC-style GUI even if the will and the design skill had been there to produce one. Even then, however, it was obvious that IBM's entry into the market would eventually change everything.

Earlier PCs from Altair, Apple and elsewhere had been even more underpowered and crude than the IBM PC. ^[14] The earliest, like the Altair, harked back to pre-1960 mainframes, requiring programs to be read from paper tape or toggled in on front-panel switches. The next milestone in the evolution of the GUI was actually to come out of the Unix world.

That next milestone was the 1982 release of the first Sun Microsystems computer, yet another mating of Unix with an Alto-inspired hardware design. This one, however, would prove immensely more successful than the Perq or Blit. In fact it set the pattern for one of the most successful product categories in the history of the computer industry — what became known within a few years as the technical workstation.

Workstations were Unix machines with high-resolution bit-mapped displays and built-in Ethernet. Early in the workstation era most were designed to use the Motorola 68000 and its successors; later on they tended to be built around various 32- and 64-bit processors at a time when PC hardware was still struggling to transition from 8 to 16. Workstations were designed (like the Alto) to be deployed as single-user machines on a local area network, but (again like the Alto) they were too expensive for individuals to own and were never marketed that way; instead they tended to be deployed in flocks, and the only way to get the use of one was to be a knowledge worker at a corporation or in academia. Three of their largest markets were software-development organizations, electronic design and CAD/CAM shops, and financial-services firms.

The Sun workstations and their imitators added very little to the GUI design pattern set at PARC; slightly glossier screen widgets with pseudo-beveled edges were nearly the extent of the visible additions. Their success came from layering the PARC look-and-feel over a software platform, Unix, that was already familiar to many engineers and development shops. Within five years the combination of GUI and command-line interfaces supported by workstations effectively wiped out traditional minicomputers and their staid command-line-only interfaces. It would be nearly a decade before Sun's machines were seriously challenged for their leading role in the computer industry.

All through that decade Suns remained very expensive machines. There were a few attempts to scale down the workstation to a price where it would compete with PCs for individual buyers; perhaps the least unsuccessful was the AT&T 3B1 (aka “Unix PC”), a 68010-based machine available c.1984 with a pixel-addressable black-and-white display running a custom Alto-like window system. The 3B1 attracted a small but loyal fan base as a personal machine for Unix programmers, but it was in an awkward spot on the price/performance curve; too expensive for the home market, not powerful enough to compete as a full-fledged workstation. It lasted barely three years before being plowed under by steadily more powerful PC-class machines with monitors that could not match the 3B1's screen resolution but could do color.

The 3B1's demise took the concept of the personal workstation down with it; nothing similar was ever attempted afterwards, and the initiative in Alto-style interfaces once again passed out of the Unix world. Thus, the really pivotal 1984 event in the history of the GUI was when Apple released the Macintosh and brought the Alto-style graphical user interface to the masses.

Perhaps it should have been the Amiga, designed in 1983 but released only after the Mac in 1985. The Amiga followed the PARC GUI model, if perhaps less inventively than the Macintosh. Its designers at the original Amiga Inc. wrung remarkably effective graphics performance out of weak hardware, and the machine rapidly attracted a cult following after release. But Commodore mismanaged and squandered the opportunity after they acquired the Amiga development team. Delayed and underfunded development, anemic marketing, over-expensive followon machines, bad strategic decisions and a bruising price war with Atari dogged the Amiga, but the technology was so attractive that it actually survived the IBM PC, the Macintosh, and the 1994 bankruptcy of Commodore. For nearly a decade afterwards the Amiga retained a niche in video mixing and production. The design was revived at least twice, and as late as 2003 German-made Amiga clones were still available in Europe.^[15]

Figure 2.8. Kickstart on the Amiga 1000 (1985).

This is as good as the resolution of color monitors got in 1985 — no better than 640x256, not good enough to render fonts with the clarity of the black-and-white displays on the Star or Macintosh.

Apple did not squander its opportunity. Part of what made the first Macintosh a pivotal event was that Apple did not merely copy the PARC pattern; they reinvented and improved it. The development took five years, an eon by industry standards, and involved deeper investigation of interface psychology and design than anyone had ever attempted before. Apple successfully claimed the leading role in carrying forward the PARC-style GUI. Two decades later, the Apple Human Interface Guidelines^[16] are still recommended reading for anyone who wants to do graphical user interfaces well.

Figure 2.9. Early version of the Macintosh Finder (1985).

Compare this with the Amiga screenshot from the same year to see the dramatic difference between the quality of black and white vs. color displays in the 1980s..

Technically, the Amiga and Macintosh shared one major limitation with a subtle but important impact on UI design: unlike the PARC designs or any Unix machine, they supported only cooperative rather than preemptive multitasking. That is, they were not equipped to timeslice among any number of concurrent user and system processes; rather, a program had to give up control of the processor before any other program (even the system routines) could take over.

Cooperative multitasking was an economy measure. It meant the hardware platform could omit an expensive MMU (memory-management unit) from its parts list. On the other hand, it meant that the latency of interfaces was minimal and constant, never disturbed by random interrupts or scheduler-introduced jitter. This made for a smooth, predictable user experience even on relatively underpowered hardware. On the third hand, the absence of preemption turned into a serious liability as computers became more and more networked. It was literally the case that an entire network of Apple machines could be frozen by a user holding down a shift key at the wrong time!

Despite this weakness, the Macintosh had an even larger impact on user-interface design than had the Alto, because it was not dismissable as a mere laboratory toy but rather a very successful consumer product. GUIs, it proved, could sell computers to the mass market. Microsoft and others in the personal-computer market scrambled to adapt.

Microsoft's early attempts at a PARC-like GUI began with the 1985 release of Windows 1.0. Early versions were ugly and unsuccessful, garishly colorized but weak efforts to clone the PARC GUI that didn't support even such basic features as overlapping windows; they largely failed to displace Microsoft's own DOS product. Microsoft's time was not yet.

Figure 2.10. Windows 1.0 (1985).

Once again the next genuine advance came from the Unix world, though its true significance would not be apparent for several years after the fact. That was the release of Version 10 of the X window system from MIT in 1986. The X design, begun in 1983 but not widely deployed until Version 10, accomplished three important things.

First, in 1987-1988 X established itself as the standard graphics engine for Unix machines, a hardware-independent neutral platform on top of which to build GUIs. This ended five years of confusion and dueling proprietary window systems that had badly fragmented the workstation market, making it uneconomical for most third-party vendors to port their applications. Significantly, X's major advantage over competitors for that role (most notably Sun's NeWS. Networked Window System) was being open source; it was backed by a consortium including most major Unix vendors. X thus prefigured the rise of open-source Unixes five years later.

Second, X supported distributing applications across a TCP/IP network. With X, a program could throw its interface on any networked display it could reach by sending requests to the X server attached to that display. The server, not the application, would then perform all the BitBlts necessary to put pixels on the memory-maped screen. This further decoupled Unix GUIs from the hardware.

Third, X separated policy from mechanism. It provided only generic graphics and event-handling, leaving the esthetic and policy issues in GUI design up to toolkit libraries or applications.

In fact, X represented the first fundamental advance in GUI infrastructure to achieve actual deployment since the days of the Alto itself. The Macintosh may have reinvented and improved the PARC GUI, but remained a monolithic system intimately tied to particular hardware — indeed, for many years the Mac GUI actually relied on patented ROMs and could not have run on machines without them as software only even if the Mac operating system had been ported. The Amiga GUI was similarly tied to specialized graphics chips included with the system. X reasserted the Unix tradition of portability and clean separation of functions.

Figure 2.11. OpenLook (c.1989).

Typical early X display on a Sun workstation. (This is actually a screenshot of a faithful emulation running under Linux.)

Despite its advances, X has attracted its share of brickbats over the years. Some parts of the design (including, for example, the resources feature) are notoriously complex and overengineered. The X APIs (application programming interfaces) are so baroque that toolkit libraries to simplify GUI programming are a stark necessity rather than merely a convenience. The design contains a lot of fossils and scar tissue related to odd and now-obsolescent graphics hardware.

The most serious indictment of X, however, is related to its separation of mechanism from policy. This has led to a huge proliferation of toolkit libraries and window managers. The Unix world, has, so far, been unable to settle on any one of these as as a stable unified standard for GUI look-and-feel. This is in stark contrast with other GUIs like the Alto's, Macintosh's or Amiga's, which wire in large parts of interface policy and thus make for a smoother and more uniform user experience than X provides.

Unix fans believe that over longer timescales the laissez-faire approach of X turns into an advantage. The argument is that policy ages faster than mechanism; X's flexibility helps it adopt new discoveries about UI while engines with more fixed policies gradually lose their appeal and relevance. Who, today, would buy the primitive etch-a-sketch look of the Alto GUI?

This debate is still live. The Linux community, at the forward edge of Unix, remains split between two major toolkits (GNOME and Qt). On the other hand, at time of writing in mid-2004 X is in the final stages of a successful architectural overhaul which gives it some dramatic new capabilities — without breaking compatibility with applications going clear back to the release of X11 in 1987!

One respect in which X10 was ahead of its time was in being among the first GUI engines (and the first widely-deployed one) to support color on a high-resolution display. In 1986 this was a engineering for a demand that barely existed yet; high-resolution color displays were rare and expensive hardware.

The mainstream acceptance of color displays was one of those pervasive technology adoptions that, like cellphones or video games, can become curiously difficult to remember the dates of even if one lived through it. After the fact, it seems like color displays have always been there. But, in fact, they did not become common on machines with the computing power to support a GUI until five years after the release of X10 — nearly twenty years after the original Alto.

More precisely, though monitors that were capable of both resolutions at or above 10,000 pixels and color began appearing on top-of-the-line workstations around the time of X10 in 1986, they remained too expensive for mass-market machines until around 1992. Early personal computers like the Apple II jumped one way, supporting command-line interfaces in low-resolution color on conventional TV displays. Machines positioned as “workstations” or high-end business machines jumped the other, following the Alto/Star lead to a custom-built high-resolution black-and-white display. But there were exceptions; the original Macintosh was black-and-white, because part of its charter was supporting word processing and WYSIWYG printing. And the original IBM PC tried to cover both markets by supporting a high-resolution green-screen monitor in their base system with an option for a low-resolution 16-color monitor.

Early Unix workstations running X opted for the black-and-white side of this fork, following the precedent set by serial-line VDTs and the Alto. But pressure to support color mounted steadily. Customers wondered, quite reasonably, why arcade video games and tiny 8-bit personal computers could throw a rainbow on the screen but much more sophisticated and expensive systems with mice and GUIs could not.

Next, Inc, a workstation manufacturer launched in 1988 by Apple cofounder Steve Jobs and others, marketed its designs around the promise of combining high resolution and color in a sytem that mated Macintosh-like UI polish with Unix power. But they moved a few years too soon; the technology to fulfil that promise at promised levels of price and quality was not quite ready. Limited-production prototypes attracted rave reviews and considerable loyalty from early adopters, but the hardware line was years late to market and not a success. Next exited the hardware business in 1993.

Figure 2.12. NeXTstep (1988).

After 1989, PC and workstation vendors threw enough demand at the monitor manufacturers to buy a solution to this problem. Increasing standardization around the PC helped, and change came more rapidly the with the emergence of an entire tier of vendors producing commodity 386 machines. By 1991 high-resolution color had begun to appear on entry-level workstations and the newer 32-bit business machines, and it was obvious that continuing price trends would soon push it downwards into consumer PCs.

For a brief period in the early 1990s, even serial VDTs grew color capability in an effort to compete with networked PCs. The last gasp of the VDT industry was a tiny box called the Dorio with a PC keyboard and monitor connectors one one side and a serial port on the other, designed to turn commodity PC parts (manufactured with economies of scale the VDT vendors could no longer match) into a capable but inexpensive color VDT. The product was clever but doomed. Bit-mapped graphics, color, and direct-memory-mapped displays like the Altos won the day. With them, so did the GUI.

The long transition to color left GUI designers with the Rule of Optional Color: Don't convey critical information in color without also expressing it as shape, position, or shading. This is still good practice today, since slightly more than 10% of the population has one form or another of color blindness.

1987 was a significant year in yet another respect. That was when the 386, the first true 32-bit Intel chip, became generally available and opened up the possibility of Unix machines built with cheap commodity hardware. 32-bit PC hardware ate into the workstation and classical Unix-based minicomputer/server markets with increasing speed after 1990.

But the 32-bit Unix-capable PC affected GUI design surprisingly little over the next ten years. We have already noted its most important consequence in the widespread availability of high-resolution color displays. Elsewhere, the basic features of the PARC pattern remained stable. The Macintosh interface changed hardly at all. Unix GUIs retained their relatively severe, functional look. The GUI to benefit most from the new wave of 32-bit machines was that of Microsoft Windows.

As the 1980s drew to a close, Microsoft got the hang of emulating the Macintosh version of the PARC pattern more closely. But where Apple left most design decisions up to its skilled cadre of in-house interface experts, Microsoft focus-grouped new versions relentlessly. Thus, while Microsoft's designs were derivative and poorly integrated, they did a better job than Apple of providing the individual features that actual customers were asking for. Responsiveness to customer feedback, saturation marketing, and the steadily rising resolution of color screens would help make Windows 3.1 a huge success in 1992.

Figure 2.13. Windows 3.0 and 3.1 (1992).

These were the critical years in which Microsoft cemented its desktop dominance and relegated Apple to niche markets. At least one lesson for today's GUI designers should be clear: never neglect the Rule of Reality! Apple's artistic vision of a clean, consistent, almost flawlessly integrated GUI lost over 90% market share to a design that was far messier and more contingent, but ruthlessly customer-focused.

In 1995, Windows 95 would be an even bigger success. It was dramatically more capable than 3.0/3.1, representing the largest increment of capabilities ever in a single Microsoft release.

Figure 2.14. Windows 95 (1995).

Some points to note about the Windows 95 screenshot are the resizing thumb at the lower-right-hand corner of the Notepad window, the menu bar, and the presence of documents on the desktop background. These, which first appeared in Windows 95, are representative of many other borrowings from the Macintosh GUI.

If the triumph of Windows 95 was the perfect case study in the Rule of Reality, Microsoft's one serious attempt to actually innovate in GUI design became an equally salutary lesson in the consequence of ignoring the Rule of Respect. That attempt was Microsoft Bob, a suite of eight programs intended to sit atop Windows 95 and modulate its UI into something more “user-friendly”.

Figure 2.15. Microsoft Bob home screen (1995).

The theory behind Bob was to replace the specialized metaphors of the PARC-style desktop with a pseudo-spatial virtual reality in which programs and documents were represented by familiar, everyday objects. The crude graphics of the home screen are an instant clue to what went wrong; in practice, Bob was a cartoonish, cloying interface populated by “Personal Guides” whose saccharine pseudo-friendliness failed to mask extreme mechanical stupidity.

Microsoft Bob became the worst flop in Microsoft's history, a debacle so embarrassing that the company destroyed all copies of the software it could get its hands on and attempted to erase the entire episode from the public record. The only “Bob” novelty to survive its demise was none other than Clippy, the painfully distracting “assistant” in Microsoft Word. Despite repeated later paeans to “innovation”, Microsoft has never since attempted any advance in GUI design that went deeper than improved eye candy. Once again, the next steps forward came out of the Unix world.

After 1995 the Unix tradition responded in two different ways to the rise of Microsoft Windows; both responses affected GUI design by tending to decouple GUIs from the underlying hardware, breaking up the layers as X had begun to do in the 1980s. One of these responses, the Java language, was essentially proprietary; the other was the rise of the open-source movement.

Java, by Sun Microsystems, was an attempt to produce a language in which you could “write once, run anywhere”. The explicit goal of Java was for applications to be able to run identically under Unix, Windows, the Macintosh OS, and everywhere else — and it was clearly understood that the biggest portability problem was making GUIs work identically on all these platforms. X had only solved the lower half of this problem, and then only on Unix systems; the designers of Java were more ambitious.

Towards that ambition, the Java interpreter carries its own GUI environment with it — not just a rendering engine analogous to that in the X server, but an entire toolkit and higher-level facilities as well. The inventors of Java, steeped in Unix tradition, essentially crammed an entire Unix-style GUI stack (two of them, actually!) into Java as the Swing and AWT toolkits. The visible part of these GUI stacks supports an Alto-style interface differing in visual detail from that of earlier Unix-based efforts, but with essentially the same capabilities and programming model.

Java left the underlying operating system in place, but tried to render it effectively irrelevant. The other and more radical Unix-tradition response was to reinvent the operating system itself as shared infrastructure.

Even as 32-bit PCs all but destroyed the workstation market that Unix-family operating systems had depended on, the new hardware also revealed the increasing inadequacy of single-user personal-computer operating systems. Their most important flaw was architectures too weak to support networking effectively, a job which (as we discussed in [TAOUP]) requires a combination of features including preemptive multitasking and full multi-user capability with per-user security domains.

Before 1990, lack of these features had been the fatal flaw that laid low most of Unix's competition in the mainframe and minicomputer worlds. After the Internet-access explosion of 1993-1994, these same weaknesses rapidly became a serious problem for the winners of the personal-computer OS wars at Microsoft and Apple. But traditional Unix vendors were uninterested in building low-margin consumer systems. They ignored or fumbled the Internet opportunity, and it was met by the rise of the open-source movement among Internet and Unix developers themselves. The flagship product of that movement was the Linux operating system.

The 1996-1998 emergence of the open-source movement into public view shook up the computer industry as nothing had in the previous decade. The evolution of user interfaces was affected, along with everything else. Four particular events during those three years well expressed the trend:

The last two items, in particular, pointed at two different ways to reconcile the Unix community with the PARC/Macintosh mainstream of the GUI tradition. Ever since the first Sun workstations in 1982 the Unix community had tended to lag the Macintosh community by as much as five years in the visible parts of UI design, but to lead in building the infrastructure that would best support GUIs in an Internetted world. Open-source Unixes helped draw the world's most accomplished GUI designers into the new Unix community at the same time as Apple was co-opting the work of that community to carry the Macintosh lineage forward.

In these and other ways, the Unix and Macintosh traditions are beginning to merge. Several levels of the Unix GUI stack, from the X server clear up to specific widely-used applications like the open-source Nautilus file browser, are undergoing rapid (and sometimes controversial^[17]) evolutionary change as this happens. Their only serious competion, the GUI of Windows, is much more constrained by history and Microsoft's institutional needs; in the wake of the Microsoft Bob debacle it is no surprise that Microsoft's tendency to cherry-pick individual design features from elsewhere, rather than innovating in broad ways, has become more marked.

The rise of GTK and Qt highlights another tendency. Increasingly, user-interface design tools are showing the same tendency to become shared infrastructure that we have previously seen in operating systems and networking. Already in 2004 there is no company other than Microsoft that could even conceivably buck this trend, and even Microsoft's next-generation .NET development tools are mirrored by the Microsoft-endorsed “Mono” open-source project.

The GUI environment around Sun's Java language is being similarly challenged by the open-source Eclipse project. It seems increasingly likely that Java itself will soon slip from Sun's control, whether because Sun opens the sources of its JRE (Java reference implementation) or because some competing Java-standard-compliant open-source implementation eclipses the JRE.

We won't attempt to cover Java or Eclipse in the remainder of this book, at least not in the first edition. Java has an entire voluminous literature of its own; we recommend Eckel as a starting point for the interested programmer. Within the Unix world, Java has so far taken both a technical and political second place to combinations of various scripting languages and the GTK or Qt toolkits. It is possible this may change in the next few years if an open-sourced Java overtakes the likes of Tcl, Perl, and Python in Unix developer mindshare. If that happens, future revisions of this book will reflect the new reality.

Since the earliest PARC systems in the 1970s, the design of GUIs has been almost completely dominated by what has come to be called the WIMP (Windows, Icons, Mice, Pointer) model pioneered by the Alto. Considering the immense changes is in computing and display hardware over the ensuing decades, it has proven surprisingly difficult to think beyond the WIMP.

A few attempts have been made. Perhaps the boldest is in VR (virtual reality) interfaces, in which users move around and gesture within immersive graphical 3-D environments. VR has attracted a large research community since the mid-1980s. While the computing power to support these is no longer expensive, the physical display devices still price VR out of general use in 2004. A more fundamental problem, familiar for many years to designers of flight simulators, is the way VR can confuse the human proprioceptive system; VR motion at even moderate speeds can induce dizziness and nausea as the brain tries to reconcile the visual simulation of motion with the inner ear's report of the body's real-world motions.

Jef Raskin's THE project (The Humane Environment) is exploring the “zoom world” model of GUIs, described in [Raskin] that spatializes them without going 3D. In THI the screen becomes a window on a 2-D virtual world where data and programs are organized by spatial locality. Objects in the world can be presented at several levels of detail depending on one's height above the reference plane, and the most besic selection operation is to zoom in and land on them.^[18]

The Lifestreams project at Yale University goes in a completely opposite direction, actually de-spatializing the GUI. The user's documents are presented as a kind of world-line or temporal stream which is organized by modification date and can be filtered in various ways.

All three of these approaches discard conventional filesystems in favor of a context that tries to avoid naming things and using names as the main form of reference. This makes them difficult to match with the filesystems and hierarchical namespaces of Unix's architecture, which seems to be one of its most enduring and effective features. Nevertheless, it is possible that one of these early experiments may yet prove as seminal as Engelbart's 1968 demo of NLS/Augment.

The Unix GUI stack obeys Unix design principles by being constructed as a set of layers or modules connected by documented APIs, and designed so that each piece can be swapped out for alternate implementations. This gives the whole system a great degree of flexibility and robustnness, though at the cost of making it difficult to guarantee a consistent user experience.

The base of the stack, is, of course, hardware. In 2004 Unix systems typically feature the following devices relevant to GUI programming:

Improvements in this hardware are still happening at time of writing, but the pace is slowing as their enabling technologies mature and the cost of each increment in capability rises. High-end graphics cards are approaching the limit of about 80,000 polygons per second at which they will be able to refresh with more speed and higher resolutions than the human eye can follow; we can expect that to happen about 2006-2007. The changeover from electron-gun monitors to liquid-crystal flatscreens is actually slowing the rise in screen resolutions, as large LCDs are even more prone to manufacturing defects than phosphor masks. Mice and keyboards are stable, old, and thoroughly commoditized technology; the largest recent change there has been a revival of trackballs in elegant thumb-operated versions that have better ergonomics than mice but are functionally identical to them.

Sitting atop the hardware will be an X server. The X server's job is to manage access to all the underlying hardware listed above, except for the sound card which is handled by a different mechanism which we'll specify further on.

The X server accepts TCP/IP connections from GUI applications. Those applications will read that connection to get input events, which include both keyboard presses and releases, mouse-button presses and releases, and mouse motion notifications. The applications will write requests to the TCP/IP connection for the server to change pixels on the display in various ways. There is a standard X protocol specifying how requests and responses are structured.

Each X application makes calls to a linked copy of a service library that handles the application end of the X protocol connection to the server. The raw API of this library is notoriously complex and only describes low-level services, so typically the application actually calls it through a second library called a toolkit.

The function of the toolkit library is to provide higher-level services and the basics of an interface policy. There are several tookit libraries, which we'll survey later in this chapter. The services each one provides are typically organized as a collection of widgets such as buttons, scrollbars, and canvas areas that can be drawn on. An interface policy is a set of rules (or at least defaults) about how the widgets behave — a “look and feel”.

Toolkit libraries are written in C. If the application is as well, it will call the toolkit directly. In the increasingly common case that the application is written in a scripting language such as Tcl, Perl or Python, the application will call the toolkit library through a language binding which translates between the language's native data objects and the C data types understood by the toolkit.

The application itself will, after initial setup, go into an event loop. The loop will accept input event notifications from the server, dispatch the input events to be handled by application logic, and ship requests for screen updates back to the server.

Figure 3.1. Comparing the X stack to a monolithic graphics system.

This layered organization contrasts sharply with the way things are done on non-Unix systems. Elsewhere, the graphics engine and toolkit layer are combined into a single service, and the GUI environment layer is at best semi-separable from either. This has two practical consequences. First, GUI applications must run on the same machine that hosts their display. Second, attempts to change the interface look-and-feel risk destabilizing the graphics engine code.

There are actually two layers within a running X server itself: a device-dependent display driver and a device-independent protocol engine. On startup, the X server determines which device driver to load by looking at its configuration file. Thereafter, from the point of view of anything above the X server in the stack, the display driver is almost invisible; all it does is supply a small set of calls that manipulate the display bitmap.

The X library linked to the client, Xlib, abstracts away the presence of the X protocol connection to the server and the individual characteristics of the underlying hardware. From the point of view of any program calling the client X library, the hardware is represented by a C structure called a graphics context; library operations manipulate that context, and there is an update call that tells the library to ship back to the X server the operations necessary to make the physical screen state match that of the graphics context. (Some library operations also finish by forcing an update.)

The X design uses several tricks to cut latency in screen updates. One is the Shared Memory Extension: if application and X server are running on the same hardware, X detects this and they communicate using a shared-memory mailbox, bypassing the TCP/IP stack entirely. Another is that the X protocol design is contrary to the normal Unix practice of loose, textual application protocols optimized for debuggability; instead, it uses a tightly-packed binary protocol to reduce datagram sizes per transaction to a bare minimum. Finally, the X server also bypasses the operating-system kernel; at startup time it requests access to I/O ports that go direct to the graphics card's video RAM, rather than using the Unix read/write. system calls. Thus, X avoids context-switching on every update.

The Xlib API is unpleasantly complex (less charitable but not infrequent descriptions run along the lines of “a baroque nightmare”). There are entire geological strata inside it full of fossils of optimization hacks that made sense in an environment of expensive RAM and slow hardware but are no longer necessary. For example, many of the Xlib calls are duplicated in clipped and unclipped variants, a leftover from days when clipping was an expensive software operation rather than a standard feature of graphics-card firmware.

Other complexities address problems that are still live but have better solutions independent of X than existed when the X design was laid down in the 1980s. Representative of these are the X security and access-control features. Under modern Unixes this notoriously messy and poorly-documented part of the system has been largely superseded by tunnelling the X protocol through ssh(1), the Secure Shell. ssh(1), an open-source tool for encrypting network connections. ssh(1)specializes in encryption and access control, and is easier to configure and administer than the native X features.

A few of the nasty spots are complex and unsatisfactory solutions to problems for which nobody has yet devised simpler and more satisfactory ones. Prominent among these is the X resource system. This allows users of X applications to set up name/property pairs which the X server digests and can use to alter the behavior of the applications running on it, (Common per-application resources include, for example, foreground and background colors for screen displays.) The problem with the resource system is that the server can collect name/value pairs from so many different sources that it is often difficult to tell where a given setting came from or what the effect of changing it will be. Modern practice tends to avoid using the resource facility entirely in favor of specialized per-application configuration files.

Despite these flaws, X has had no serious challenger for the role of Unix graphics engine in the last decade. A handful of attempts, such as the Fresco project (originally the “Berlin” project) have come to nothing. The Aqua libraries layered over the Unix Foundation of Mac OS X are X's only functional competition — but as single-vendor proprietary code they are a non-starter anywhere but on Apple machines, and can never expect to attract X's volume of cross-platform developer support. In recognition of this fact, Apple has added an X server compatibility feature to Aqua so that “legacy” X applications can run under it.

After several years of political and technical stagnation during which many Unix insiders worried that the codebase might have aged and complexified beyond salvage, X server development is undergoing something of a renaissance at time of writing in 2004. A new rendering engine based on Porter-Duff composition rather than the traditional BitBlt has been successfully implemented, and has been used to demonstrate dramatic new capabilities which should soon make their way into production versions.

The most visually obvious of these is full alpha-channel support. This means that upcoming X servers will make it easy for toolkit libraries to stack transparent and partially-transparent widgets on the screen, with lower layers correctly blending with the layers above them. This feature will make X fully competitive with Aqua, which has used alpha transparency to beautiful effect on recent Macintoshes.

Just as importantly, though less visibly, the re-architecting of the X server carries the original X concept a step forward by breaking the X server into communicating pieces. Image-composition logic will be separated from the server core that drives the graphics hardware. The next generation of X servers will be both more capable and less complex than today's, while still retaining backward compatibility with the X application base.

Most GUI developers will never have to see or cope with the legendary intricacies of Xlib. As we noted earlier in the overview, the X server's features are normally encapsulated by toolkit libraries and language bindings of those libraries.

Your choice of X toolkit will be connected to your choice of language bindings in two ways: first, because some languages ship with a binding to a preferred toolkit, and second because some toolkits only have bindings to a limited set of development languages.

The once-ubiquitous Motif toolkit is effectively dead for new development. It couldn't keep up with the newer toolkits distributed without license fees or restrictions. These attracted more developer effort until they surged past closed-source toolkits in capability and features; nowadays, the competition is all in open source.

The original open-source X toolkit is also moribund. The Xaw library, often known as the Athena toolkit after the MIT research project that spawned X, was written in the mid-1980s as a testbed for the server's features. It supported crude line-drawn widgets resembling those of the original 1973 Alto GUI. We mention it here mainly because you will occasionally run across references to it in the X documentation, but there is no new development in it.

The four toolkits to consider seriously in 2004 are Tk, GTK, Qt, and wxWidgets^[19], with GTK and Qt being the clear front runners. All four have ports on MacOS and Windows, so any choice will give you the capability to do cross-platform development.

The Tk toolkit is the oldest of the four and has the advantage of incumbency; it's native in Tcl and bindings to it are shipped with the stock version of Python. Libraries to provide language bindings to Tk are generally available for C and C++. Unfortunately, Tk also shows its age in that its standard widget set is both limited and rather ugly. On the other hand, the Tk Canvas widget has capabilities that other toolkits still match only with difficulty.

GTK began life as a replacement for Motif, and was invented to support the GIMP. It is now the preferred toolkit of the GNOME project and is used by hundreds of GNOME applications. The native API is C; bindings are available for C++, Perl, and Python, but do not ship with the stock language distributions. It's the only one of these four with a native C binding.

Qt is a toolkit associated with the KDE project. It is natively a C++ library; bindings are available for Python and Perl but do not ship with the stock interpreters. Qt has a reputation for having the best-designed and most expressive API of these four, but adoption was initially hindered by controversy over early versions of the Qt license and was further slowed down by the fact that a C binding was slow in coming.

wxWidgets is also natively C++ with bindings available in Perl and Python. The wxWidgets developers emphasize their support for cross-platform development heavily and appear to regard it as the main selling point of the toolkit. Another selling point is that wxWidgets is actually a wrapper around the native (GTK, Windows, and MacOS 9) widgets on each platform, so applications written using it retain a native look and feel.

As of mid-2004 few detailed comparisons have been written, but a Web search for “X toolkit comparison” may turn up some useful hits. Table 3.1, “Summary of X Toolkits.” summarizes the state of play.

Architecturally, these libraries are all written at about the same abstraction level. GTK and Qt use a slot-and-signal apparatus for event-handling so similar that ports between them have been reported to be almost trivial. Your choice among them will probably be conditioned more by the availability of bindings to your chosen development language than anything else.

GUIs depend on more than just a graphics toolkit. They need a framework, an integrating environment to help them communicate with one another and the rest of Unix. Because GUI environments normally aim at supporting some variant of the virtual desktop metaphor pioneered by the Alto, they are often referred to as “desktop environments” or just “desktops”. Among the things such a desktop environment typically supplies are the following:

Which GUI environment you choose to host your application is one of the most important background decisions you will make about it. The decision will have significant technical consequences, because although the features offered by different desktops are broadly similar they are by no means identical. The decision will also control which other applications you can most easily integrate yours with. Finally, the decision will have political consequences as well, because both of the major desktops have vociferous advocates, associated communities of interest, and major corporate backers.

To understand why choice of desktop is such a sensitive issue, a little review of the history of major Unix desktop environments is in order. Excluding one or two that have been obsolete for so long that they have no influence on present-day conditions, there have been four: NeXTstep, CDE, KDE, and GNOME.

NExTstep was the proprietary GUI environment associated with Next, whose premature attempt to build inexpensive color workstations we touched on in the History chapter. In 1993 NeXT went software-only to concentrate on developing and licensing NeXTstep, and successfully closed a licensing deal with Sun Microsystems. In 1997 Apple bought out Next in order to fold its software technology into the next-generation Macintosh operating system; that technology became a substantial part of Mac OS X. A screenshot of a NeXTstep desktop was included in the History chapter.

While NeXTstep itself was proprietary, attempts to build emulations of its look and feel have attracted persistent minority support in the post-1997 open source community. We have already touched on two of these, the AfterStep and WindowMaker window managers. There is a GNUStep project attempting to implement Apple's published standard interfaces for NeXTstep, but there is no realistic prospect that it will overtake GNOME or KDE in the struggle for developer mindshare. Nevertheless, NeXTstep continues to serve as a design model for the more widely used present-day desktops.

CDE, the Common Desktop Environment, was an attempt to do for desktops what the X window system had done for the underlying graphics engine. It was develped by a consortium of proprietary Unix vendors including IBM, Hewlett-Packard, and Sun Microsystems and built around the proprietary Motif toolkit. CDE successfully replaced a gaggle of single-vendor proprietary desktops in the early 1990s. But like Motif, CDE proved unable to keep up with open-source competitors after 1997 and has since been abandoned by its former patrons.

KDE, Kool Desktop Environment, began life in 1996 as an attempt to produce an open-source equivalent of CDE for Linux. Ther primary motivation of the developers was evangelistic, to build a GUI that would take Linux to end-users. Accordingly the aims of KDE almost immediately enlarged from just producing a desktop to shipping an entire application suite including a Web browser, word processor, spreadsheet, and other productivity tools.

While the KDE developers made rapid early strides towards their technical goals, they also made a serious political mistake. The Qt toolkit on which they based their desktop was under a license that did not completely conform to the developing norms of the open-source community. This led to a heated controversy, with opponents expressing concern that that Trolltech, the small Norwegian consulting company behind Qt, might eventually use its control of the code in damaging ways.

Trolltech eventually cbanged its license to be fully conformant with community norms. But by that time, the damage had been done. The GNOME project was founded in 1997 as an explicit rival of KDE. To the chagrin of the KDE hackers, it marketed itself more effectively than KDE had done and swiftly attracted a larger developer community. KDE's situation was not helped by the fact that its core group was located in Germany rather than the United States, and accordingly found it somewhat more difficult to recruit a large talent base.

Like KDE, GNOME quickly expanded its mission to supporting an entire application suite. The two projects settled into intense and sometimes bitter rivalry, occasionally punctuated by cooperation on technical standards such as drag-and-drop protocols. The arms race between them has probably stimulated greater code productivity by both teams, but has done so at the cost of dividing the developer community and the open-source applications space.

This situation is probably not stable, especially not given that in early 2004 a single corporate entity (Novell) acquired the two companies most responsible for funding KDE and GNOME development respectively. But it is at time of writing too early to tell whether the split will be resolved by the disintegration of one project or the merger of both.

We cannot tell you which environment is “best”, as the development of both moves so quickly that anything we were to say about relative capabilities would be likely to have changed by the time you read this. There will be, alas, no substitute for doing your own evaluation.

Each of the three different major interface styles we have described (batch, command-line, and GUI) implies a characteristic kind of control flow in the applications that use them.

Batch programs, for example, lived in a timeless world where they read from input sources and write to output sinks without having to worry about timing, synchronization, or concurrency issues; all those problems were the responsibility of human operators.

The basic control flow of command-line programs, on the other hand, is a request-response loop on a single device. When a Unix CLI is running on a terminal or terminal emulator, it can assume it has undisputed control of that device. Furthermore, there is only one kind of input event; an incoming keystroke. So the program can enter a loop that repeatedly waits for input of a single kind on a single device, processes it, and writes output to single device without concerns about whether that device is available. The fact that such programs sometimes have to poll storage or network devices at odd times does not change this basic picture.

Programs with GUIs live in a more complex world. To start with, there are more kinds of input events. The obvious ones are key presses and releases, mouse-button presses and releases, and mouse movement notifications. But the context of a window system implies other kinds as well: expose events, for example, notify a program when a window needs to be be drawn or redrawn because that window (or some part of it) has gone from being obscured to being visible. Further, GUIs may have more than one window open at a time, so events tied to a window cannot be simple atoms but have to include a detail field containing a window index.

What will follow next, then, is an overview of the X programming model. Toolkits may simplify it in various ways (say, by merging event types, or abstracting away the event-reading loop in various ways), but knowing what is going on behind the toolkit calls will help you understand any toolkit API better.

Toolkit libraries and GUI environments exist to save application writers from having to code at the level of BitBlt or Porter-Duff operators. They hide most rendering operations and most input-event handling behind an abstraction layer of widgets.

A widget is an X window object, possibly composed of a collection of subwidgets which are themselves X windows, Each widget or subwidget has its own event mask and event-handling logic. For example, a button is an X window that ignores keystroke events but captures mouse-button events. A text-entry field, on the other hand, may accept keystroke events but ignore mouse clicks. Some widgets, like toolkit-level window objects, can containers for collections of subwidgets.

GUI programs under X using a toolkit generally start by setting up a collection of widgets, then calling a toolkit-supplied driver function that implements an X event loop. The toolkit's (hidden) event loop takes care of dispatching input events to the appropriate widgets as they come in.

Widgets trigger actions in the program's application logic via callbacks. A callback is a function pointer that a widget will call (possibly supplying some arguments) on some particular event. For example, any button widget will have a place to plug in a callback for whenever the button is clicked.

Programming with this event-loop/callback combination leads to a very different style and organization of code than with CLIs. interfaces. When writing code with a CLI, the main loop is under the programmer's control and directly expresses the expected sequence of operations in the application. Programming is almost entirely imperative, with explicit code expressing what should be done when. This style does not cope naturally with multiplexing several input sources, nor with events coming in in odd sequences at unpredictable times; in fact, these have to be modeled interrupts and processed by callbacks outside the normal flow of program control.

In the event-loop/callback world of GUIs, the main flow of control is implicit (dedicated entirely to waiting on and dispatching the next input event, and everything at application level is a callback processed rather like an interrupt in “normal” program flow. Much of programming is declarative (hooking application functions into the callback slots of widgets) rather than imperative.

Programming in the event-loop/callback world by hand is trickier than CLI programming by hand, but the stereotyped nature of the main event loop and the encapsulation of most input handling in widgets also means that code generators can be proportionately much more helpful. In the next section, we'll survey some tools for easing the GUI coding burden.

The single most important advice we can give you about writing application GUIs is don't code them in raw C!

We discussed the general reasons for moving away from C towards scripting languages in [TAOUP]. On modern hardware, memory and clock cycles are so inexpensive that the inefficiencies of automatic memory allocation are well worth paying in order to simplify implementations and reduce the maintainance cost of code. Thus, higher-level languages like Tcl, Perl, Python, and Java make more and more sense not just for prototyping applications but for delivering them.

This is even more true of GUI programming than of most other kinds. Widgets are naturally encapsulated as objects (in the OO sense) and callbacks often most naturally expressed as anonymous functions declared at the point of call. C doesn't support either of these abstractions very well. Scripting languages do.

Even supposing your GUI application has a core part that is performance-critical in ways that can only be satisfied by C coding, then it will still generally make sense to leave the GUI in a scripting language and connect it to a C core. We described many different ways of doing this in [TAOUP]; here, the implementation details matter far less than the architectural advice.

Because it reduces development time and effort, writing your GUI in a higher-level language can help keep you from becoming over-invested in a poor design. Going this route also makes iterative changes in response to interface testing easier.

The next step beyond just using a scripting language is using a visual-design tool to create and edit your interface. Tools like these create your entire GUI, including both the event loop and the widget layout; you get to specify the names of the callbacks into your application engine. They can reduce coding time by a large factor, and make it easy to try out variations that would otherwise be too much work to explore.

If you're using GTK, the tool to investigate is Glade^[21]. If you're using Qt, you have alternatives. There is Ebuilder ^[22], a pure GUI editor. There are also KDE Studio ^[23] and KDevelop^[24] which are both interface builders and entire integrated development environments. All these tools are open-source code.

Our most basic insight about UI design is the Rule of Bliss: ignorance is a luxury because human beings are happiest when they can handle routine tasks without having to use logic or allocate any of their relatively limited capacity for handling novelty. The kind of cognitive consciousness that we summon to deal with novelty and branching decisions is, as Jef Raskin reminds us, normally only sustainable for seconds at a time; unconscious cognition and adaptive habit are the more normal state.

The next simplest insight about how humans interact with UIs may be the most important, which we'll call Raskin's First Law because Raskin (op. cit.) has discussed its consequences in more depth than anyone else:

Raskin's First Law: Most human beings can only concentrate on one thing at a time.

The pattern of human competence suggests that our ancestral environment shaped us for an regime of sporadic but intense challenges, one in which nothing much happens most of the time but we have to be at maximum during the few minutes per average day when we are either predator or prey. Under stress, our attention becomes more single-focused. But evolution has not made us any more capable of sustained attention than we have to be to cope with transient crises, because excess capacity is inefficient.

Despite scattered results suggesting (for example) that under some circumstances humans can have two simultaneous loci of spatial attention, the actual measured task performance of human beings on computers suggests that Raskin is correct when he maintains that in the GUI context there is one single locus of attention, and that managing that locus effectively without jerking it around is a problem right at the center of GUI design.

Natural settings like our environment of ancestral adaptation also differ from technological civilization in that they may require an organism to react quickly, or to cope with novelties outside its instinctive responses, but they seldom do both at once. Thus a related and equally important result:

Raskin's Second Law: Humans take up to ten seconds to prepare for tasks requiring conscious cognition, during which they are unaware of passing time.

This gap in subjective time has odd consequences. Raskin was able to make use of it in the design of the Canon Cat word processor by making a capture of the screen part of the standard disk save, then throwing that capture on the display at the begining of the document-load sequence, which (using some tricks) he held just below 7 seconds in duration. Most users perceived the reload as instantaneous, because it all happened during the 10-second subjective-time gap while they were mentally tooling up to work on their document.

The costs of focus-switching usually life more difficult for UI designers rather than easier. A major one is that users are prone to not notice interface friction caused by focus-switching, even when lost time is substantial. Macintosh UI guru Bruce Tognazzini has observed that users often think that a mousing through a GUI is quicker and more efficient than using keyboard shortcuts, even when actual timings show the reverse is true. The problem is that the multiple focus switches involved in finding and moving the mouse do not reach the user's awareness.

The ratio of aggregate times spent using two different interface designs for the same task is probably our best measure of relative efficiency, but Tognazzini's observation implies that user perceptions aren't a good measure of either. Accordingly, an entire discipline of quantitative interface analysis has grown up around doing actual timings. [Raskin] gives examples and discusses several efficiency methods. Here are some averaged timings, combined from [Raskin] and [Lewis&Rieman]:

These timings have many interesting implications just as stated. Here are a few:

Analysis of timings on real-world interfaces sometimes yields suggestive curves. That is, suggestive to a statistician, who may be able to recognize a powerful qualitative principle in the numbers. One such regularity is Hick's Law,^[26] which for our purposes we can paraphrase as: The time M(n) required to make a choice from a menu of n items rises with the log to the base two of n.

The key fact here is that the rise of M(n) is sublinear. Thus, the Rule of Large Menus: one large menu is more time-efficient than several small submenus supporting the same choices, even if we ignore the time overhead of moving among submenus.

A related result is Fitts's Law, which predicts that the time T(D,S) to move the mouse pointer to a region on a screen, when is initially D units away from the region border and the region is S units deep in the direction of motion, rises with the log to the base two of D/S.

Since you can't control D — the user will start his mouse movements from unpredictable locations — it follows that the way to reduce the D/S ratio that predicts select time in a point-and-click interface is to make the target larger. But not huge; the log to the base two in the formula means that, as with Hick's Law, the efficiency gains are sublinear and fall off as the ratio rises, and that gain has to be traded off against the value of other uses for the screen space.

Still, we get from this the Rule of Target Size: The size of a button should be proportional to its expected frequency of use.

Macintosh fans like to point out that Fitts's Law implies a very large advantage for Mac-style edge-of-screen menus with no borders, because they effectively extend the depth of the target area offscreen. This prediction is borne out by experiment. Under Unix. we can capture this benefit with a (borderless) taskbar adjacent to any screen edge, but the standard Unix toolkits don't give us a way to harness it within applications (because application windows have borders and anyway don't typically appear nestled up to a sctreen edge).^[27]

We can get from this the Rule of the Infinite Edge: The easiest target rectangles on the screen are those adjacent to its edges.

Hick's Law and Fitts's Law come from a place even deeper than evolved human instinctual wiring. They're related to the Shannon-Hartley Theorem in information theory and would probably just hold as true for intelligent squids, robots, or anything else with an eye-brain-hand loop that has to check whether the mouse pointer has landed in the right spot by tracking progress against a visual boundary.

For more on the application of Fitts's Law, including some marvelously detailed case studies, see Bruce Tognazzini's February 1999 Ask Tog^[28].

Some of the action times listed in Table 4.1, “Timings for various interface actions” are so long that it seems fair to wonder how human beings ever get anything done at all! The answer is implicit in the remark on long-term memory retrieval: habituation. As humans repeat tasks, they form habits — a change that pushes the task from conscious cognition to unconscious cognition. This change observably cuts way down on task times and increases quality of performance.

This is where it helps to remember that consciousness seems to be a recently-evolved subsystem for coping with novelty, layered over mind/brain circuitry intended to deal with routines in a more habitual and much less self-aware way. Even physical skills that are learned consciously often cannot be practiced at a level of mastery when one is being conscious about them; the very act of attention gets in the way. The same is true of many cognitive skills, including those involved in using GUIs.

Raskin makes the empirical point that human beings cannot be prevented from forming habits about routine tasks, and elegantly defines good interfaces as those which encourage benevolent habituation. We can go a bit further and observe that “benevolent habituation” — the ability to do the right thing by unconscious or half-conscious reflex — is precisely what we normally mean by expertise.

Thus, our Rule of Modelessness. Users will form gestural habits, and it is a bad thing when gestural habits they form in one part of the system become inappropriate or even destructive in another part. When this leads to problems, the fault lies not with the user's habits but with system designers' failure to maintain consistency.

Mediocre interfaces don't support the development of expertise. Actively bad interfaces create dangerous habits; they promote anti-expertise. Raskin observes “Any confirmation prompt that elicits a fixed response soon become useless” but the actual situation is worse than the word “useless” implies. Potentially destructive operations, for which racing through a confirmation prompt becomes reflexive, are traps that turn habituation into a weapon against the user's interests.

Thus, our Rule of Confirmation: Every confirmation prompt should be a surprise. It is better still to eliminate confirmation prompts and irreversible operations entirely, as suggested in our Rule of Reversibility: Every operation without an undo is a horror story waiting to happen.

The usual outline of that horror story is that a habituated user running through a sequence of actions that he/she has learned to treat as a unit realized just too late that he is in the unusual circumstances where those reflexes are inappropriate, and has stepped on something critical. It is no use trying to discourage users from forming habits; that would prevent them from gaining expertise. The correct adaptation is to support undo so users can always back out of the jams their habits occasionally land them in.

In these latter days of abundant computation and inexpensive memory, the only good excuse an interface designer has for not supporting undo is when the software is triggering some intrinsically irreversible action in the physical world, or some financial/legal move like a stock trade in which non-repudiation is part of the definition. In the world of information that most computer programs inhabit, full undo with a reversible transaction history should be considered mandatory.

Benevolent habituation, important though it is, is only half of the picture. The other half, as we noted in the Premises chapter, is supporting flow states.

A person in flow state has elevated alpha-wave levels in the brain, not unlike those of a Zen monk in meditation. When in this alpha-wave-intensive state of flow, we can retain cognitive consciousness for far longer than the few seconds of duration characteristic of normal (beta-wave) consciousness. This extended consciousness equips us to solve complex problems, follow extended chains of reasoning, and take on tasks that we simply cannot fit into the transient episodes of normal beta-wave arousal.

Flow states also seem to be more conducive than normal consciousness to activation of the right superior temporal gyrus, a region of the brain associated with intuitive leaps and sudden insight. Why this is so is not yet clearly understood, but thousands of years of anecdotal evidence suggest that that the chatter of beta-wave activity in normal consciousness somehow competes with our “aha!” circuitry. Or, as a Zen master would put it, the mind is a noisy drunken monkey, and our Buddha-self can only whisper. The monkey has to be soothed into a flow state before we can hear.

Computer programmers are not unfamiliar with flow state; it appears in our folklore as “hack mode” and many of our behavioral quirks (such as programming into the still hours of early morning) are patently designed to maintain it. But flow is just as characteristic of many categories of computer users as it is of programmers. Flow-seeking behavior is obvious in writers, artists, musicians, scientists, and engineers of all sorts. On examination it turns out to be no less important to businessmen, military officers and even athletes. Human beings of all kinds rely on flow states to reach peak creative performance at what they do.

People who are practiced at maintaining flow can remain effectively conscious and creative for hours at a time, with tremendous gains ind productivity and inner satisfaction. In fact, it seems almost certain that no human being can function competitively (at least in creative or professional work), without routinely entering flow. This makes it a continuing mystery why we tolerate work environments full of loud noises and other kinds of interruptions that are disruptive of flow states.

We learn from [DeMarco&Lister] that it takes about fifteen minutes to establish flow, or re-establish it after it has been interrupted. In a normal working day, as few as seven randomly-spaced disruptions can completely destroy any possibility of maintaining flow long enough to get any real work done. There are a few exceptions (like, say, software controlling the alarm sirens in a missile-defense system) — but in general, one of the most important goals of any user-interface designer must be to make sure that his product is never, ever one of those disruptions.

Thus, our Rule of Distractions and Rule of Silence. Eschew popups and animations, avoid visual and auditory noise. Make messages clear but unobtrusive. When in doubt, quiet down.

Even successfully maintaining a flow state doesn't seem to do much about the limitations of human memory. As we noted under the Rule of Seven in the Premises chapter, these limitations have implications that echo all through UI design.

Human memory works much like a virtual-memory system, in that it is divided into short-term and long-term storage with a relatively high cost for pushing data from the short-term working set out to long-term memory.

The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information [Miller] is one of the foundation papers in cognitive psychology (and, incidentally, the specific reason that U.S. local telephone numbers have seven digits). Miller showed that the number of discrete items of information human beings can hold in short-term memory is seven, plus or minus two.

We've already observed than any hidden state in a program is likely to take up at least one of these scarce slots. We have further observed that having more than seven visible controls on a program's interface is likely to collide with this limit as well; using the controls involves refreshing short-term memory with retrieved knowledge about them, and if that retrieved knowledge doesn't fit easily in the working store, the cognitive cost of using the interface increases. We can use the timings reported earlier in this chapter to be more specific; the penalty for going over our 7±2 working store sizes implies a long-term memory retrieval for every extra slot, with an expected time penalty of about 1.2 seconds each.

Humans compensate for the limited size of their working set in two main ways: selective ignorance and chunking strategies. If the main panel of a GUI has thirteen buttons, users will often quickly figure out that they can ignore five of them for normal use and group some others into chunks that can be remembered as groups rather than individually, with the meaning of the individual group members being swapped in whenever the user determines that the next operation needed is probably in that group.

In fact, developing this kind of implicit knowledge is a large part of what we mean by “learning” an interface, another kind of habit formation that builds expertise. Therefore, good interface designs allow selective ignorance and encourage chunking. Well-designed UIs often include visual aids to chunking, such as box rules around groups of related controls. More fundamentally, strong functional metaphors in programs are aids to chunking. Orthogonality of features helps make features ignorable.

It is wise not to lean on the user's chunking capacity and ability to selectively ignore features too hard, because those capabilities have costs and require effort. The more you can hold the number of items a user must grasp at any one time below seven, the happier and more comfortable they will be.

It is especially important for expert programmers to internalize this habit, for two reasons. One is that expert programmers are disproportionately drawn from the high end of the bell curve in their working-set size; therefore they tend to systematically overestimate the amount of complexity other people can handle easily.

The other is that, for a particular well-known task, apparent working-set size can increase because some knowledge about the interface has been committed to long-term memory. Expert programmers tend to evaluate interfaces by what they are like when they are familiar (e.g. a lot about them has gone into long-term storage); thus they systematically underestimate the degree to which complex interfaces strain the novice user and present barriers to learning.

Thus, for an audience of programmers, we emphasize the number seven. It may not be right in all circumstances, but using it as a hard threshold will bias programmers in a good direction, which is simpler than their own reflexes and working-set size would usually take them.

One consequence of human evolutionary history is that we are profoundly social creatures. Ancestral hominids lived in each others' pockets, traveling in small nomadic bands that stuck close together for mutual protection. Through most of our evolutionary history, among the most important of our adaptive challenges has been getting better at the games of communication and contract that determined success within the social group — because thus conditioned the amount of protection won got, and one's degree of access to the best food and the choicest mates.

Thus, human beings have developed elaborate machinery for modeling each others' mental states. A significant portion of our brains is devoted just to recognizing and interpreting facial expressions. We are hardwired for negotiation in more subtle ways as well; evolutionary psychologists have found that hunan beings do substantially better on logic problems when they are framed as a way to spot people who are reneging on agreements.

So powerful is our instinct to negotiate that we routinely project human consciousness onto the inanimate world in order to feel more comfortable with it. Primitives anthromorphize rocks and trees, the more allegedly sophisticated build cathedrals, and computer programmers often talk of their tools as if they were little homunculi even though they know exactly how mechanical the internals of the hardware and software are. It is human nature to see human nature everywhere, and to create it where it didn't previously exist to any extent that is possible. Indeed, some animal ethologists are beginning to think our demand for humanlikeness is so powerful that it occasionally elicits sentience in pets and domesticated animals that wouldn't have it in the wild.

We invent imaginary friends, and we tell stories about them. In his provocative and seminal work The Origin of Consciousness in the Breakdown of the Bicameral Mind (1976) pyschologist Julian Jaynes argued that the single most important characteristic that distinguished full human consciousness from that of earlier hominids may have been the development of a drive to narratize — to assemble out of the incidents of the world stories that have a beginning, internal causal connections, an end, and a meaning.

It would be surprising if pervasive behavioral biases towards negotiation and narratization didn't have implications for UI design. To date, attempts to make computer interfaces humanlike and social have been largely unsuccessful; human brains, honed by several million years of competition, too easily detect the shallowness of the simulations. Nevertheless there is a way we can use the phenomenon of projection to improve UI design. It called “ persona-based design”, and has been effectively championed in (among other places) [Cooper].

It is difficult and frustrating to design a UI for “the user” as an abstraction or impersonal statistical profile. But when we give the user a face and a name, even a fictional face and name, all our evolved machinery for modeling other minds, negotiation, and narratization gets engaged. UI design becomes easier, and can even yield some of the emotional satisfactions that we get from socializing with real humans or reading a book about fictional ones.

This book was conceived when one of the authors (Raymond) had a scarifying experience with the Common Unix Printing System under Fedora Linux. Our first case study will be a very lightly edited and merged version of the two rants Raymond uttered as a result. We have refrained from massaging it into the neutral third-person because we think the feelings of anger and frustration it expresses are too typical of the non-technical end user's experience to be sanitized away in a misguided attempt to make Unix developers more comfortable.

I've just gone through the experience of trying to configure CUPS, the Common Unix Printing System. It has proved a textbook lesson in why nontechnical people run screaming from Unix. This is all the more frustrating because the developers of CUPS have obviously tried hard to produce an accessible system — but the best intentions and effort have led to a system which despite its superficial pseudo-friendliness is so undiscoverable that it might as well have been written in ancient Sanskrit.

GUI tools and voluminous manuals are not enough. You have to think about what the actual user experiences when he or she sits down to do actual stuff, and you have to think about it from the user's point of view. The CUPS people have, despite obvious effort, utterly failed at this. I'm going to anatomize this failure in detail, because there are lessons here that other open-source projects would do well to heed. The point of this essay is not, therefore, just to beat up on the CUPS people — it's also to beat up on every other open-source designer who does equally thoughtless things under the fond delusion that a slick-looking UI is a well-designed UI. Watch and learn...

The configuration problem is simple. I have a desktop machine named ‘snark’. It is connected, via the house Ethernet, to my wife Cathy's machine, which is named ‘minx’. Minx has a LaserJet 6MP attached to it via parallel port. Both machines are running Fedora Core 1, and Cathy can print locally from minx. I can ssh minx from snark, so the network is known good.

This should be easy, right? *hollow laughter* Famous last words...

First, I do what any nontechnical user would do. I go to my desktop menu and click System Settings→Printing, then give the root password to the following popup. Up comes a “Printer configuration” popup. I click “New”. Up pops a wizard that says, in big friendly letters, “Add a new print queue”. So far, so good. I click “Forward”.

Figure 5.1. CUPS configuration: the saga begins

First screen of the Fedora configurator for CUPS.

Now, those of you who are intimate with CUPS know I have already made a basic error. I shouldn't be trying to create a new print queue on snark and then glue it to the server on minx, at all. Instead, if I want to pass print jobs to minx, I should look at the configuration wizard, see minx's print queue already announced there, and make it snark's default. But nothing in the configuration wizard's interface even hints at that! And minx's print queue does not show, for a reason we'll discover later in this sorry saga.

Figure 5.2. CUPS configuration: the Queue Name panel

New form in the window, saying “Queue name” in equally big friendly letters. It offers a default of “printer”. I change it to “laserjet” because I might at some point want to hook up the ancient dot-matrix thingy I still have. I enter the optional short description: “the laser printer”. So far this is all good. Aunt Tillie, the archetypal nontechnical user, could handle this just fine. Forward...

Figure 5.3. CUPS configuration: the Queue Type panel

New form. “Queue type”, it says. There's a drop-down menu. The default is “Locally connected”, which is reasonable. Clicking on the menu, I am presented with the following alternatives (which I list here as text because of a technical limit in my screenshot tool):

	Networked CUPS (IPP)
	Networked Unix (LPD)
	Networked Windows (SMB)
	Networked Novell (NCP)
	Networked JetDirect

Here is our first intimation of trouble. If I were Aunt Tillie, I would at this point be thinking “What in the holy fleeping frack does that mean?” And just as importantly, “why do I have to answer this question?”" I do not, after all, have any Windows machines on my network. Nor any Netware boxes. And I certainly don't have a “Networked JetDirect”, whatever that might be.

If the designers were half-smart about UI issues (like, say, Windows programmers) they'd probe the local network neighborhood and omit the impossible entries. If they were really smart (like, say, Mac programmers) they'd leave the impossible choices in but gray them out, signifying that if your system were configured a bit differently you really could print on a Windows machine, assuming you were unfortunate enough to own one.

But no. Instead, Aunt Tillie is already getting the idea that this software was written by geeks without clue.

But wait! Wait! Hallelujah! There's a help button! I click it. Up comes a nice glossy page of on-line documentation. But instead of answering the question in my mind, which is “How do I choose the right queue type”, it is a page on adding a locally connected printer. That is, it's associated with the currently selected-by-default queue type, not the operation of choosing a queue. The help is...unhelpful.

Aunt Tillie, at this point, is either resigning herself to another session of being tortured by the poor UI choices of well-meaning idiots or deciding to chuck this whole Linux thing and go back to the old Windows box. It blue-screened a lot, but at least it allowed her the luxury of ignorance — she didn't have to know, or care, about what a JetDirect or a CUPS might be.

I am not ignorant, but I have my own equivalent of Aunt Tillie's problem. I know I want one of the top two methods, but I don't know which one. And I don't want to know or care about the difference either; I have better things to do with my brain than clutter it with sysadminning details. If the tool can detect that both methods are available on the local net (and that shouldn't be hard, they're both well-known ports) it should at least put “(recommended)” next to one so I can click and keep going.

But nooooo. Instead I have to stare at the help screen and think “Where might I find some guidance on this, and why is this already taking too freaking long?” Applying my fearsome hacker-jutsu, I try clicking “Prev”. I get a page about the printer configuration which describes the queue types, but still no guidance on how to choose between CUPS and LPD.

Obviously it never occurred to the designers of this tool that this could be an issue, either for Aunt Tillie or for the more technically ept. There is no large friendly button next to the “Select a queue type” that says “How to select a queue type”. This lack is a grave flaw in the UI design that turns the superficial spiffiness of the configuration wizard into a tease, a mockery.

Applying my fearsome hacker-jutsu once again, I guess, and select “CUPS (IPP)”. Comes now the form that turns the UI from a mockery to something worse. It presents two text fields. One is labeled “Server” and is blank. The other is labeled “Path:” and contains the string “/printers/queue1”.

Figure 5.4. CUPS configuration: the stone wall

If Aunt Tillie were still along for the ride, she would be using some unladylike language right about now. And with good reason, because this is a crash landing, an unmitigated disaster. To understand why, you have to stop thinking like a hacker for a few moments. Cram your mind, if you can, back into the mindset of a clueless user. Somebody who not only doesn't know what a string like “/printers/queue1” might mean, but doesn't want to know, and doesn't think he or she ought to have to learn.

From Aunt Tillie's point of view, it's reasonable that the host field is empty; she hasn't selected one, after all. But the fact that the Path field is filled in is worse than useless, it's actually harmful — because she doesn't know what it means, and doesn't know how to tell whether or not that default would be valid if she did fill in a server name. She is stopped dead.

What she ought at this point to be seeing is one of two things: either a list of CUPS print queues available on the local network, or a big bold message that says “I don't see any queues available locally; you may need to go set up a print server.” The prompt for server/path, presented here, is a stone wall; not only does it leaves Aunt Tillie with no idea how to proceed, it is just as opaque to an experienced hacker like me.

The meta-problem here is that the configuration wizard does all the approved rituals (GUI with standardized clicky buttons, help popping up in a browser, etc. etc.) but doesn't have the central attribute these are supposed to achieve: discoverability. That is, the quality that every point in the interface has prompts and actions attached to it from which you can learn what to do next. Does your project have this quality?

In fact, the “Queue type” form is an anti-discoverable interface — it leads you right down a blind alley of trying to set up a local queue pointing to a remote server that you know can print — like my wife Cathy's machine — and then cursing because your test print attempts fail. This is, in fact, exactly what happened to me next.

I typed “minx.thyrsus.com” into the server field, on the assumption that “/printers/queue1” might be a safe default that other CUPS instances would honor. I went through the manufacturer and model screens and confirmed the queue creation. The wizard popped up a window offering to print a test page; I told it yes...and nothing happened. Actually, it was worse than nothing; the configurator window displayed a message that said ‘Network host "minx.thyrsus.com" is busy, will retry in 30 seconds’, and then (to all appearances) hung.

We are now deep in the trackless swamps created by thoughtless, feckless UI design — full of glitz and GUI, signifying nothing. This is the precise point at which I decided I was going to write a rant and started taking notes.

The “Queue type” screen gave me no clue about the existence, nonexistence, or sharable status of any print queues on my network. I have two other machines in the house, both running full Fedora Core and plugged into Ethernet; the really right thing would have been a message that said "I see CUPS demons are running on minx, golux, and grelber, but no queues are accessible." with a pointer into the CUPS documentation.

Again, the help I did get wasn't helpful. The page associated with “Networked CUPS (IPP) Printer” says "Any networked IPP printer found via CUPS browsing appears in the main window under the Browsed queues category." Oh, really? What "main window" would that be in? And it doesn't give me a clue what to do if I don't see any Browsed queues category, which is particularly wack since that is the normal, default situation for a new installation!

None of this is rocket science. The problem isn't that the right things are technically difficult to do; CUPS is already supposed to have discovery of active shareable queues as a feature. The problem is that the CUPS designers' attitude was wrong. They never stepped outside their assumptions. They never exerted the mental effort to forget what they know and sit down at the system like a dumb user who's never seen it before — and they never watched a dumb user in action!

CUPS is not alone. This kind of fecklessness is endemic in open-source land. And it's what's keeping Microsoft in business — because by Goddess, they may write crappy insecure overpriced shoddy software, but on this one issue their half-assed semi-competent best is an order of magnitude better than we usually manage.

But enough prescriptive ranting for the moment. I'm going to tell you about my efforts to research my way out of this hole, because there are some lessons there as well. First, I went looking for documentation. I did this in a Unix-hackerish way, by eyeballing the output of `locate printers` for anything in /usr/share/doc related to CUPS. I found /usr/share/doc/cups-1.1.19/printers/index.html and fired up a browser on it. It redirected me to http://localhost:631/ which was OK, though the redirect went by too fast.

And I found myself looking at a web page that was not obviously useful for troubleshooting my problem. I tried clicking on the button marked "Administration" in hopes the tool behind it would be a bit more discoverable than the configuration. I got a pop-up with a password prompt (which I can't display here becaiuse the GNOME window-capture tool doesn't do Mozilla popups correctly).

Hello? How am I supposed to know what to do with this thing? All it tells me is that it wants a “CUPS login”. Is this the same as a system root login, or is there some special funky CUPS identity I'm supposed to telepathically know about? The prompt on these password popups is configurable; it could have offered me a clue and a pointer into the documentation. It didn't.

Once again, the theme is the absence of discoverability. That password prompt, rather than being a signpost leading further into an understanding of the system, was another stone wall.

When all else fails, there's always Google. I searched on CUPS printing HOWTO and found a link to The Linux Printing HOWTO — which when I chased it, turned out to be a 404. Now that bit is probably not the CUPS designers' fault; I'm throwing it in just to establish that, at that point, I was feeling screwed, blued, and tatooed. The shiny-surfaced opacity of CUPS had, it seemed, defeated me in what should have been a trivial 30-second task.

I persevered, however. My next step was to ssh into minx and see if I could discover the name of the active CUPS queue. Maybe, I thought, if I found that out I could plug that queue name into the configuration wizard on snark and it would all work. Alas, it was not to be. The two commands that seemed possibly relevant were lpinfo(8) and lpadmin, and you can't get a list of queue names from either of them. The output of “lpinfo -v” looked like it ought to be useful, but I had no idea how to map these device URLs onto queue names.

We are now in real time. I am writing this rant as I am trying to figure out the path out of this maze. I am reading the CUPS System Administrator's Manual and it claims : “CUPS supports automatic client configuration of printers on the same subnet. To configure printers on the same subnet, do nothing. Each client should see the available printers within 30 seconds automatically. The printer and class lists are updated automatically as printers and servers are added or removed.” Well, that's very nice, but the breezy confidence of their exposition leaves me with no clue about what to do when the autoconfiguration isn't working!

I'm reading the manual, and I find a reference to “BrowseAddress” and /etc/cups/cupsd.conf which begins to unfold for me the mystery of how the autoconfiguration is supposed to work. It seems that CUPS instances periodically send broadcast packets advertising their status and available printers to a broadcast address to be picked up by other CUPS instances. Smart design! But...bugger me with a chainsaw, the broadcast facility is turned off by default and the documentation doesn't tell you that!

So, let's review. In order for the nice, user-friendly autoconfiguration stuff to work, you have to first edit an /etc file. On a different machine than the one you're trying to set up. And you have to read the comments in that configuration file to know that you need to do this in the first place.

What a truly lovely, classic blunder this is. That somebody turned off the autoconfiguration support is understandable from a security-engineering point of view. But failing to mention this in the Administrator's Guide, and failing to warn the user during the configuration-wizard dialogue that operating printers may not be visible unless your site admin has performed the appropriate ritual on the printers' host machines...that is moronically thoughtless.

This kind of crap is exactly why Linux has had such trouble gaining traction among nontechnical users — and it becomes less forgivable, not more, when it's surrounded by a boatload of GUI eye candy that adds complexity without actually delivering friendliness to the user.

I edit a correct broadcast address for my network into /etc/cups/cupsd.conf on minx. I am unsurprised to learn that the cupsd(8) man page doesn't tell me whether the standard kill -HUP will force cupsd to reread that file, because at this point I am long past expecting the documentation to be helpful. I do /etc/init.d/cups restart instead.

I write the last paragraph, then go back to the configuration wizard. A little poking at it discloses an Action→Sharing item. When I click the OK button, "Browsed queues" appears in the wizard window. Excelsior! It appears that snark is now receiving broadcat configuration info from minx. And sure enough, when I click “Browse queues” a LaserJet 6 shows up as a device. Curiously, however, it is labeled “lp0” without any indication that it's not on the local machine.

I fire up the Web interface. Sure enough, it finds the LaserJet 6 on minx. But not all is goodness. When I try to print a test page, a popup tells me “The connection was refused when attempting to contact minx.thyrsus.com:631”.

I am again unsurprised to learn that neither the user's nor the Administrator's Guide has anything to say about troubleshooting CUPS problems. The lpr(1) interface is massively unhelpful; when I submit jobs from snark, they appear to vanish into a black hole.

Eventually I notice the Listen directive in the /etc/cups/cupsd.conf file. “Aha!” says I to myself, “Maybe this is like sendmail, where you have to tell it explicitly to listen on the server's IP address.” I add “Listen 192.168.1.21”, the latter being minx's IP address, restart cupsd...and lo and behold my test job comes tumbling out of the printer.

The thing to notice here is how far behind we have left Aunt Tillie. An iron rule of writing software for nontechnical users is this: if they have to read documentation to use it you designed it wrong. The interface of the software should be all the documentation the user needs. You'd have lost the non-techie before the point in this troubleshooting sequence where a hacker like me even got fully engaged.

But in this case, the documentation was passively but severely misleading in one area, and harmfully silent in others. I eventually had to apply m4d skillz gained from wrestling with sendmail to solve a problem the CUPS documentation never even hinted about.

As I said before, the point of this essay is not especially to bash on the CUPS guys. They're no worse than thousands of projects out there, and that is the point. We talk about world domination, but we'll neither have it nor deserve it until we learn to do better than this. A lot better.

It's not like doing better would be difficult, either. None of the changes in CUPS behavior or documentation I've described would be technical challenges; the problem is that these simple things never occurred to developers who bring huge amounts of already-acquired knowledge to bear every time they look at their user interfaces.

It doesn't matter a damn whether the shoddy and unhelpful design of the printer-configuration tool came out of a CUPS brainpan or a Fedora brainpan. What matters is that whoever was responsible never audited the interface for usability with a real user.

It also doesn't matter whether the the failure of the browsing defaults in CUPS to match the documentation was a CUPS-team screwup or a Fedora screwup — Aunt Tillie doesn't care which direction that finger points, and I don't either. No, the real problem is that whoever changed the default didn't immediately fix the documentation to match it as a matter of spinal reflex.

The CUPS mess is not a failure of one development team, or of one distribution integrator. In fact, it makes a better example because the CUPS guys and the Fedora guys are both well above the median in both general technical chops, design smarts, and attention to usability. The fact that this mess is an example of our best in action, rather than our worst, just highlights how appallingly low our standards have been.

Good UI design is not a result of black magic, it just requires paying attention. Being task-oriented rather than feature-oriented. Recognizing that every time you force a user to learn something, you have fallen down on your job. And that when Aunt Tillie doesn't understand your software, the fault — and the responsibility to fix it — lies not with her but with you.

Let's go back to the queue type selection screen. Remember that one? It looks like this:

        Locally connected
	Networked CUPS (IPP)
	Networked Unix (LPD)
	Networked Windows (SMB)
	Networked Novell (NCP)
	Networked JetDirect

This is a feature-oriented menu, not a task-oriented one. The attitude it exhales is “Oooh! Look how cool it is that we support all these printer types!” But you know what? Aunt Tillie doesn't care. She doesn't want to know about all the world's printer types, she just wants to make her printer work.

A task-oriented configurator would have logic in it like this:

The technical details of these tests aren't important, and anybody who writes me arguing for a different set will have fixated on the wrong level of the problem. The point is that, unlike a command tool for techies that should give them lots of choices, the goal of a GUI is to present the user with as few decision points as possible. Remember the Macintosh dictum that the user should never have to tell the machine anything that it knows or can deduce for itself.

“As few as possible decision points” is another way of stating the guiding principle of good UI design for end-users: Allow the user the luxury of ignorance. This does not mean that you can't reward acquired knowledge with more choices and more power; you can and should do that. But the user should also be able to choose to remain ignorant and still get all their basic tasks done. The more thoroughly software developers internalize the truth that real users have better things to do with their time and attention than worship at the shrine of geek technical prowess, the better off everyone will be.

xine is a project aiming to provide full support for playback of video and audio multimedia on Linux computers. The project maintainers ship several components that partition the task in a traditionally Unixy fashion: these include both xine-lib (a library which provides an API for multimedia playback) and xine-ui (a GUI front end that exercises the library). Comments here apply to the 0.9.22 version released in late 2003.

The xine-lib API is documented, and several alternate front ends have been written for it. One of these is gxine, intended to be run as part of the GNOME desktop environment and shipped by the xine project itself. Another is totem, a third-party front end written by developers dissatisfied with xine-ui and gxine.

The designers of xine-ui appear to have taken their cue from a popular audio player, xmms (remarks here apply to version 1.2.8). The GUI concept of the xmms UI is that it imitates the look and feel of the sort of small CD or tape player that one might install in one's car. The appearance of xmms is customizable by selecting one of about two dozen skins. All supply the same dozen or so controls, which are mainly buttons with the play/pause/stop and other graphic labels familiar from consumer electronics. Options and less-frequently-used controls can be reached through a pulldown menu activated by the right mouse button.

Figure 5.5. xmms

Main panel of the xmms audio player using the Ultrafina theme.

The UI of xmms works pretty well. It makes effective use of the Rule of Least Surprise, and will be readily discoverable by anyone who has used physical stero equipment. There is trouble narrowly avoided in one of the options. which is to double-size the xmms panel. The panel and its skins were designed as graphics with a fixed pixel height and width for 72-dot-per-inch displays; they look too small when thrown on the 100dpi pixel density characteristic of 19-inch and larger displays. Because xmms uses only a large and relatively crude font simulating those found on an LCD display, the track-title marquee is readable even without double-sizing on a 100dpi display, and scales up nicely when that option is enabled.

The xine-ui GUI is based on applying a very similar design concept to a much more elaborate set of controls; the authors have tried to make it look like the control panel on an expensive home entertainment center. Visually, they succeeded. On first acquaintance xine-ui and the large collection of skins available for it look very impressive — so much so that it can actually be a guilt-inducing experience to discover that the xine-ui GUI is nigh-unusable. It's easy to think that if the developers put such effort into making it pretty, any difficulties in using it must be due to one's own stupidity.

Figure 5.6. xine-ui

Control panel of xine-ui front end.

But there are severe design problems here, problems which arise from the choice of a visually attractive metaphor that leads to poor ergonomics. The main panel features lots of buttons labeled in small fonts, many of which (unlike those on the xmms panel) look alike. Thus, it is difficult to operate the GUI without reading the labels next to each button. Labels which are in low-contrast gray on black.

Worse, as with xmms skins, the xine-ui panels were designed as fixed-size graphics on a 72dpi monitor. The fonts are baked into the skin along with the control graphics, and don't scale, The legends are difficult to read at 72dpi; at 100dpi, they are impossible. There is no double-size option, and if there were it would turn small, spidery, eye-straining labels into larger, blurry, eye-straining labels.

The combination of overemphasis on surface gloss and skinnability with complete failure to address the problem of varying display resolutions is telling — particularly since technology trends give us every reason to expect that what is ultra-high-resolution today will be normal in a few years. This is what happens when programmers pursue usability in a superficial way, doing things that make their interfaces attractive for the first thirty seconds and a trial to use forever after.

But the mis-design of the UI goes beyond the appearance of xine-ui and deep into its interface logic. The application's control menus, when you can find them, are complicated and confusing, replete with cryptic abbreviations that don't make sense unless one is already immersed in audio/video jargon. Despite the surface gloss, it's an interface written by geeks for other geeks. Most nontechnical end-users, presented with it, would run screaming.

All in all, xine-ui is a dreadful example of what happens when developers mistake visual polish for usability. It is all the more powerful an example because it is such an elaborate and energetic execution of a bad idea.

The designers of gxine and totem have demonstrated that a xine front end doesn't have to be that way. They abandoned the goal of looking pretty. Instead, they focused on usability and created front ends with far simpler interfaces. Notably, gxine usees the same set of standard consumer-electronic icons for play/stop/pause, etc., that gxine does. Also, gxine comes closer than xine-ui, to obeying the Rule of Seven; there are exactly ten visible controls (not counting the pull-down menus).

Figure 5.7. gxine

gxine running under GNOME. The window frame is not part of gxine itself; it is generated by Sawfish, the default GNOME window manager, under the Bluecurve theme used by Fedora.

What lessons can we draw from the xine debacle and the totem and gxine recovery?

At least one lesson is not new. Just before the turn of the millennium Macintosh interface guru Bruce Tognazzini observed “In the hands of an amateur, slavish fidelity to the way a real-world artifact would act is often carried way too far.” It is perhaps not coincidental that the egregious example he was condemning was another media player, Apple's QuickTime 4.0. Its numerous blunders, parallelling those of xine, were well dissected in [Turner].

At least one xine interface mistake that QuickTime 4.0 avoided was to plow a lot of effort into supporting skins. Skinnability is a two-edged sword. As a feature of a fundamentally sound UI design, it can help users feel empowered. But, as the xine case shows, skinnability can also be a psychological and technical problem. Psychologically, it may give developers a misplaced sense of accomplishment, distracting them from other issues like poor discoverability due to complex and crptic menus. Technically, it may pin them to methods which don't adapt well as background realities like monitor dot pitches change.