On Humane Interfaces

This is the first article in my series on the topic of interface design. I'll be using that term because several overlapping (but slightly different) terms have arisen to describe this discipline. Variously it has been described as UI design, User Experience Design (UX), Human Factors Engineering, Usability Engineering and probably others.. I'll be discussing the books and articles that I read and pointing out what I feel is valuable in each, where I think they went wrong, and what is unique about each author's take on the field and how he describes it.

To begin I'll be discussing Jef Raskin's The Humane Interface. Mr Raskin is the creator of the Macintosh and the Canon Cat. He dedicates his book as follows:

We are oppressed by our electronic servants. This book is dedicated to our liberation.

Wow. I did not expect such hyperbole from a serious (well recommended) text. If nothing else Raskin's passion makes an otherwise dry subject more fun to read. However I found myself disagreeing with him a lot and this line kind of highlights why. Raskin present many of his design rules as universal truths, frequently backed by research, but lacking in nuance. Design is fundamentally a balancing act between conflicting goals. Design rules guide our choices by informing us of the costs of our decisions, but they rarely point us in a direction of universal good.

An interface is humane if it is responsive to human needs and considerate of human frailties.

I admire his dedication to this ideal and his inventiveness in pursuing it. As a very long time computer user, a user of fairly diverse software, and a programmer, I was surprised that Mr Raskin came up with a number of interesting interface suggestions that I have never encountered nor imagined. A computer is a tool meant to augment the (human) user and meet his or her needs. The designers of such systems must consider the (human) user's limitations or risk creating interfaces that are error prone, disliked and possibly unsafe.

One area where he deviates from this ideal is his rant against User Preferences.

if we are competent user interface designers... personalizations can only make the interface worse. is an example of design hubris. Where consistency in a shared environment is a design goal, I agree that that user configurability should be avoided. But where software is personal (ie. personal computers) configurability allows software to accomodate frailties and meet human needs, even subjective ones.

The Expert vs. New User Myth is an excellent point. There is only knowledge (or lack thereof) of particular features. This goes hand in hand with the myth of intuitive interfaces. The epitome is the oft-cited example of the hammer. Supposedly a hammer's design makes it's use and purpose obvious. But as a father of small children I can tell you, not one of them held a hammer correctly the first time they picked it up. Nor could any of them drive a nail without instruction and practice. The same is true of software. Easy to Learn is the correct goal to strive for.

Visibility and Affordances refer to making the possible interaction elements visible to the user and obviously distinct from non-interactive elements. The current in vogue design trend is to remove these in favor of a "clean" design. A practice that I find frustrating. Where there is no visual distinction between actionable and non-actionable content we've allowed artistic vision to override usability.

Raskin's chapter on Focus, Habits, and Conscious/Unconscious Processes is a good catalog of some of the limitations of human cognition. I will paraphrase Raskin's empircal explanation here but save further discussion for when I cover Human Factors Engineering. Raskin asks, "What is the last character of your first name?" Until you read the question you were not thinking about that particular letter. Despite the fact that it might be on the screen in front of you. But you know the letter and could easily recall it. That fact (the last letter of your name) was a part of your unconcious (as Raskin calls it). It becomes a part of your concious process when you read the sentence and purposefully recalled it. This idea, of unconcious vs. conscious processes coupled with the demonstrated singular locus of attention provide a solid framework for roughing out an interface design. The user can only focus on a singular conscious fact at a time. Every change of focus requires a shift (however subtle) of attention and comes at a cost to the user experience. Other's have dealt with this concept with greater depth and rigor.

Noun Verb/Verb Noun covers a particular common case of forcing the user to switch their focus of attention. Generally the user is focused on the content they are creating (noun) and want to perform some action (verb) upon it. Less typically, interfaces require the user to first select the action and then the content. Raskin discusses text formatting as a common example of the former and painting programs as a common example of the later. The verb-noun order does require an extra context switch for the user. But I was surprised there was no discussion of reverse polish notation here even in passing. Many people swear it is faster or more familiar. I would love to see research that digs into it.

At this point I need to say something about modes. A mode in an interface is when a particular action has different effects depending on the actions before. The Caps Lock key is an example of a mode. I'm a long time VIM user but not an apologist. I use VIM because I was forced to learn it in my sysadmin days and I kept using it because I find a certain zen-like peace in using it's particular interface. While I don't think VIM-like modal interfaces are the be-all, end-all of interface design (I'll have to write another article about it's shortcomings) I have been bothered by the vehemence with which Raskin and other designers decry modal interfaces. Here's why I think they might be so dead set against them: modal errors, where the users executes an unintended action because they forgot what mode they were in, are easy to measure and can be very bad. Raskin gives an example that resulted in a airliner crashing. Clearly modes are bad for safety critical systems. But these facts don't lead to a general law that says, "Never design a model interface", rather they suggest a cost function for modes and give designers something to consider. Someone in an internet discussion of the topic pointed out that the accelerator pedal in every car on the planet is modal. Depending on the gear the transmission is in the car will go foward or backward. Why don't we have two pedals? The answer isn't simple but hints that the rule may not be absolute.

My second point is that something like a text editor is created with different design goals than a car or an aircraft cockpit. If I must physically constrain the interface (for ergonomics) than modes may be more acceptable than limiting features.

Thirdly Raskin defined modes as when the current state of the interface is not the user's locus of attention. As in the drawing program example, how the state is indicated (ie with a change to cursor shape) matters.

Finally UI design is not completely objects. If I, as a user, prefer an interface that results in a few more errors but engenders good feelings I use the objectively worse interface for subjective reasons. Designers who realize this will also be catering to human needs and frailties.

As always, design is about tradeoffs between constraints. The first principles are it depends and never say never.