The Humane Interface

Reader Torulf contributed the below review of Jef Raskin's The Humane Interface .Though the book does not spend much time on Open Source software, it emphasizes ideas that every programmer probably ought to bear in mind -- at least if they wants hisprograms to have users. (And yes, he takes explicit exception to some UNIX truisms.)

The Human Interface: New Directions for Interface Design
author	Jef Raskin
pages	233
publisher	Addison-Wesley
rating	9
reviewer	Torulf Jernström
ISBN	0-201-37937-6
summary	A thought-provoking book on how to design user interfaces.

Introduction

The Humane Interface: New Directions for Interface Design, by Jef Raskin, the creator of the Macintosh project, provides an interesting read chock full of controversial ideas. As the book's full title suggests, Raskin focuses mainly on how things ideally should be made, rather than offering advice and recepies that can be immediately applied to problems in today's systems.

Don't Think!

The approach taken by Raskin stems from his definition of a humane interface: "An interface is humane if it is responsive to human needs and considerate of human frailties." In practice, this means that the interface he suggests is based on ergonomics and cognetics (psychology).

Basically, the idea is that we can do only one thing well at a time consciously. Most of us can walk, chew bubblegum, hold our bladder and speak (semi-intelligently) with a friend, all at the same time. This is because the only thing we are consciously doing (the only thing we are concentrating on) is the semi-intelligent babble. On the other hand most of us run into trouble when trying to study calculus at the same time we're hitting on a sexy lady (make that a handsome man for those 5% of ladies here at Slashdot, or some sort of hermaphrodite freak for those 11% with doubts about their sex).

The point with this is that the one thing we're consciously working with should, with as few interruptions as possible, be the content we are producing with the computer, not the computer itself. That is, all interaction with the system should, after the initial learning phase, become habitual or automated, just like we can walk or drive a car without ever consciously thinking about it. This way we could maximize productivity and concentrate on the content of our work.

There's Only One Way to Do it

For commands to become habitual as quickly as possible some interface-guidelines are given. First of all, all modes (differing types of responses based on context) should be eliminated. The system should always react in the same way to a command. All modes generate user errors when the user isn't paying attention to what mode the system is currently in (and the user should not have to pay attention to the systems current mode, the user should only have to pay attention to the content he or she is currently producing). An example of mode error happened to me while I was writing this review, just a few lines up: I unintentionally left overwrite on when I thought I was in insert-mode and thus overwrote a word by mistake. Of course, this was no big deal, but I had to take my mind off formulating the sentence to figure out what had happened, just for a second, but long enough to derail my thoughts, and that derailing should never happen.

Another way to speed the transition to habitual use is monotony. You should never have to think about what way to do something, there should always be one, and only one, obvious way. Offering multiple ways of doing the same thing makes the user think about the interface instead of the actual work that should be done. At the very least this slows down the process of making the interface habitual.

Unorthodox Suggestions

There are of course a lot of other suggestions in the book, some expected, some very surprising and unorthodox. The more conventional wisdom includes noting that the interface should be visible. That is one of the downsides of the otherwise efficient command line interface, i.e. you cannot see the commands at your disposal by just looking at the interface. A method called GOMS, for evaluating keystroke efficiency, and Fitts' law (the time it takes for you to hit a GUI button is a function of the distance from the cursor and the size of the button) are also among the less surprising ideas in the book.

The more unorthodox suggestions include Raskin's proposal for a universal undo/redo function, not just in the different applications but in the system itself. The same gesture would always undo, no matter what application or setting you last touched.

The really controversial idea, though, is to abandon applications altogether. There would be only the system, with its commands, and the users' content. Even file-hierarchies should vanish along with the applications, according to Raskin.

Conclusions

The Humane Interface focuses on the principle of user interfaces and the theory behind them. The ideas presented in the book generally make sense, after considering the background and argument for them presented by Raskin; even if some seem very drastic when first encountered (I can hear Slashdotters firing up their flamethrowers after reading the end of last paragraph). As mentioned before, the book does not provide many ready to use recipes. It does provide a good insight into the background of user interfaces, which the reader can apply to the project at hand.

Some related ideas were dicussed about a year ago on slashdot. The Anti-Mac paper discussed then, came to pretty much the opposite conclusions from the ones that Raskin presents (Raskin makes a case against beginner/expert interface levels). After reading both sides of the story, I'm inclined to believe more in Raskin's reasoning.

The only Open Source or Free Software the book mentions is Emacs, in a discussion about string searches. (The incremental model in Emacs is preferable to systems where the search does not begin until you click the search button.) I do, however, believe that the alternative interface models could be an opportunity to the open source community and that Raskin's ideas perhaps are more likely to be implemented and tested in such an environment, compared to the possibility that Microsoft would greatly simplify the thousands of commands that MS Office consists of. I therefore warmly recommend this book to anyone doing software development and I would love to see some of the ideas used in KDE or GNOME.

---

You can purchase this book at Fatbrain.