Ski trails come in three varieties—green, blue, and black—because skiers, too, are of three kinds: novices, intermediates, and experts. I happen to be an intermediate skier, have been for years, and expect to be all my life. I'm what ski instructors refer to euphemistically as a classic “improving intermediate,” meaning I'm middle-aged, keep getting better, but not by much and not very quickly. I'm happy. I love skiing and have even survived a few of those dreaded (or lauded) double black diamond trails, usually because I miss the last turnoff onto the kinder, gentler slopes. Mostly, though, I keep my eyes out for those user-friendly blue squares and reassuring green circles.
Skiing has a lot to teach us about the relationship between users and systems and how software developers can improve that relationship. It would be a punishing experience to learn to ski on one of those steep expert slopes strewn with bone-jarring bumps. A few tyros, mostly youngsters under twelve, seem to go directly to the mogul fields following their first try on the bunny slope, but I've always suspected that they were really bionic mutants. For most of us, those wide gentle slopes marked with friendly green circles are essential for early learning.
On the other hand, you can only learn so much if you stay all day on the bunny slopes. Sooner or later you have to move on to the bigger challenges of the blue and the black (or, occasionally, the black and blue).
The power users of skiing, experts who twist their way down the slalom course and fly over the mogul fields, would have us believe that theirs is the only way. But improving intermediates can enjoy transcendent moments, too, as when you come off the top at Heavenly Valley, with the turquoise jewel of Lake Tahoe shining below and the desert to the east, a brown and ocher sea stretching to the horizon, and the crisp morning air stings your face as you whisper through a dusting of fresh powder.
Okay, so what has this got to do with software development? Aside from daydreaming about skiing Tahoe again, I wanted to introduce the triphasic model of human interfaces (Constantine 1994a, 1994c). The triphasic model says that system users have different needs at different stages in their development as users, and that the user interface should be designed to accommodate these changing needs. To do this, software must present different faces to users of different levels of ability, each designed with its own distinct features and particular technical goals. Like the network of trails at a good ski resort, these interface components are not really separate but are intricately interconnected.
The three interfaces in the triphasic model are the acquisition interface, the transition interface, and the production interface. The acquisition interface is the system the naïve user sees on first encounter with the software. A good acquisition interface enables the beginner to do work right from the get-go. The production interface makes it possible for an experienced, fully trained user to produce sophisticated results with high efficiency. In between is the transition interface, for the improving intermediates among software users—those who are beyond the slow and sloppy point-and-click of the beginner, but are not and may never be real power users who can slalom their way with shortcut keys through multiple applications in cascaded windows. Just as the novice, intermediate, and expert trails at the ski resort are distinct but interconnected, so a well-designed system presents a threefold interface with smooth transitions among its parts.
I think one of the most serious problems in user interface design today is that most of the attention is given to laying out the bunny slopes of software. Expert users are grudgingly accommodated by leaving open access to rather rough and ugly “advanced” features or by cobbling together a random set of keystroke shortcuts and an awkward macro facility. But the “improving intermediates,” who may well be the most numerous and most important category, are virtually ignored.
If a system is useful and reasonably well designed, users will not remain novices forever. A minority of them may eventually become experts or power users, but the majority will probably spend their days as improving intermediates. Their needs are neither those of experts nor novices; they need a user interface that allows them to steadily and incrementally add knowledge of the software and increase their skill in using it. It should not punish them for what they don't know or need, and it should not send them unexpectedly hurtling down the double-black-diamond slopes of dialogues only a C++ programmer could love.
At best, commercial software and software development tools seem to have green trails and double black diamonds, but almost nothing in between. The transition interface, which helps the former novice continue to improve in efficiency and versatility, needs to be designed as a distinct collection of interface features that are systematically tied to what the beginner already knows and what the expert will need to know. User-configurable button bars and tool palettes are probably a good idea but not the answer, since they either saddle users with the standard set—invariably either too complex or too limited—or make them figure out for themselves which features are which.
The entire interface could be modal, offering a novice mode and a series of intermediate modes with expanding interface richness and versatility. Novices should probably not see or be offered access to the black diamond features, except through clearly marked “lifts” or “trails.” A check on a preference list tells the system what general level the user has reached or wants to use. Custom interface layouts could start from this range of standard ones. Oddly, many freeware computer games are readily configurable by player ability, but expensive productivity packages and software development tools come in one-size-fits-all configurations.
Ski resorts typically provide other user-friendly features that ought to be part of every software interface. Trail maps show how to get from where you are to where you want to be and guide the skier who is seeking out or trying to avoid certain kinds of trails. Software systems should incorporate or provide their own trail maps, visual guides to the layout of features in the maze of buttons and dialogues, pull-down and pop-up menus. On-line help, at least as typically done with the help engines of popular GUIs, is of only limited value. Such on-line un-help is every bit as difficult or clumsy to navigate as the menus and dialogues themselves and, worse, is invariably organized differently than the interface itself.
On the ski slopes, the trails themselves are clearly marked, the same way as on the map. In software, menu titles frequently give little or no clue to what lies below, and the “help” system, separated from the interface features it is supposed to help with, often employs a different vocabulary. If I am trying to figure out how to make a footnote go away in my word processor, the darned help system should just show me, opening the right menus in sequence and pointing to what I need to use.
Different tools and approaches, even different rules and principles, may apply to the transition interface than to the acquisition or production interfaces. Usability testing (see Chapter 36), which studies users actually interacting with a system, may help fine-tune the acquisition interface, but it is likely to help little with the transition or production interfaces. Why? Because the camcorder runs out of tape or the psychologist runs out of attention span long before users progress to intermediate or expert levels of ability.
With the help of good engineering and extensive usability testing, some GUIs have succeeded in furnishing a reasonable acquisition interface. The original Apple Macintosh interface was designed to a target of twenty minutes from sealed box to productive work, for example.
The problem is that, as the user progresses, the typical interface remains the same. Beginning users of a system really need what amounts to software training wheels. Training wheels have helped many a kid learn to ride a bicycle, but training wheels were not meant to be permanent. Training wheels, in fact, do not actually help kids learn to ride a bicycle; they help kids learn to ride a bicycle-with-training-wheels! In order to develop the balance and motor skills to ride a bicycle, the training wheels have to come off.
There you have it. Just when you were reluctantly ready to accept the need to design and test the user interface for your next product, you find out one interface is not enough. You need green, blue, and black versions, with trail maps and markings, and maybe even detachable training wheels. Okay, so the analogy isn't perfect.
I think I'll go and hit the slopes!
From Software Development, Volume 1, #2, February 1993.