The Humane Interface, The Deadline

This article appears in slightly different form in the May/June 2000 issue of IEEE Micro © 2000 IEEE.

Doing It Right

This time I look at two books that aim at making life easier for humans. The first tells how to make computer interfaces that humans can use. The second uses fiction to explore the ways humans can work together to produce good software.

The Humane Interface -- New Directions for Designing Interactive Systems by Jef Raskin (Addison-Wesley, Reading MA, 2000, 254pp, www.aw.com, ISBN 0-201-37937-6, $24.95)

[NOTE: Jef Raskin died shortly after this review appeared.] Jef Raskin's best known work is the Macintosh. That product brought about a revolution in computer interface design, but yesterday's revolutionary idea has become today's entrenched paradigm. Raskin has moved on. In this book he shows the flaws of the desktop-and-application approach and explains how it can evolve into something much easier for humans to use.

Raskin centers his ideal system on your content -- not named files in a hierarchy of directories, but just content. You can have files and directories, but only if you decide to mark their boundaries in an otherwise undifferentiated sea of content.

Rather than applications to process your content, Raskin gives you individual commands. Thus, rather than buying Photoshop and Word, you buy individual (or perhaps groups of) image processing commands from Adobe and text manipulation commands from Microsoft. You can use the text commands to add text to images, and you can use the image processing commands to manipulate the images in your printed documents.

This sounds like component software or Unix filters. It's not a radically new idea, but Raskin arrives at it from a different direction. He begins by asking how he can make interfaces that humans can learn easily and use efficiently. To answer that question, he looks at the equipment on both sides of that interface: the computer and the human.

Many people have studied human cognition, but few have applied what we know about the capabilities and limitations of humans to the problems of interface design. To do this, Raskin applies techniques and observations that the cognitive psychologist Bernard J. Baars discusses in his book A Cognitive Theory of Consciousness (Cambridge, 1988).

Raskin takes a fundamental principle from Baars' work: humans can accomplish many tasks in parallel, but can only pay attention to one at a time. We all know this, but many people design interfaces as if it weren't true. Raskin gives examples of this error -- taken from widely used software products.

The fact that we have at most one locus of attention, while most tasks we perform with computers require us to accomplish a variety of subtasks in parallel, leads to the principle of automaticity: the more we can do without thinking, the more efficient we are. Anything that makes us think about what we already know how to do slows us down. This principle leads to the following conclusions:

• Interfaces should be modeless - the way to accomplish a task should be the same under all circumstances.
  
• Interfaces that change in an attempt to adapt to your actions can actually slow you down.

Raskin elaborates on these points with many examples. Some of the examples are surprising. They show the inefficiency of widely practiced interface design techniques.

Raskin turns a lot of attention to the problems of navigation. He likens current navigation methods in applications, operating systems, and the web to trying to find your way around a maze with only the ground-level view of where you are and where you've been. He proposes a two-prong approach to improving this situation: a zooming video camera metaphor for finding your way around a pictorial representation of your content, and a text-search facility that differs sharply from the most commonly used search facilities.

Raskin also applies quantitative methods to interface design. He uses the goals, objects, methods, and selection rules (GOMS) technique developed by Stuart Card, Thomas Moran, and Allen Newell to measure the relative efficiencies of alternative interfaces.

I haven't come near to covering all of the topics Raskin addresses in this marvelous book -- icons, programming environments, documentation, the number of buttons on a mouse, and even cables and connectors.

If you have anything to do with designing any aspect of computer systems for use by humans, you should read this book. People will be talking about it for a long time.

The Deadline -- A Novel about Project Management by Tom DeMarco (Dorset 

House, New York NY, 1997, 320pp, www.dorsethouse.com, ISBN 0-932633-39-0, 

$24.95) 

In 1964 I knew assembly language for the IBM 650, and I had recently learned Fortran II.  I sat down with the IBM Cobol manuals to see what that language was all about.  It took me very little time to decide that it was not a language I wanted to program in.  I don't regret this 

decision, but it shut me out of the world in which Tom DeMarco was later to flourish.  

Fifteen years and many languages later, I wound up (briefly) advising a large California bank, and the book that bridged the gap between my way of thinking and theirs was Tom DeMarco's Structured Analysis and System Specification (Prentice Hall, 1979).  I still remember how exciting it was to use DeMarco's methods to produce diagrams that represented the elements of the bank's proposed application.  The bank, however, was less concerned with the quality of the information than with the fact that my "work product" was drawn in pencil on D-size graph paper.  We parted company.  They later went out of business.  

In 1979, DeMarco was insightful.  Today he is wise.  Then he was concerned with how software modules work together.  Today he focuses on how people work together.  His book is fiction, but it teaches many real lessons about project management and team building.  

Here is the essence of the plot.  Mr.  Tompkins, a middle-aged middle manager, is laid off from a thinly disguised AT&T, kidnapped by a beautiful and resourceful industrial spy, and spirited away to Moravia, a post-Communist third world country somewhere on the Adriatic coast.  A thinly disguised Bill Gates has acquired this country secretly in a stock swap and has decided to help it dominate the shrink-wrap software business by producing knockoffs of Quicken, PhotoShop, Quark XPress, PageMill, Painter, and Lotus Notes, and giving them away.  

Tompkins takes the job of managing this development.  Because Moravia has far more programmers than required to develop these six products, Tompkins sets up three parallel projects for each product, turning the whole operation into a project management laboratory.  He gets carte blanche from Bill, and everything seems to be going smoothly.  

Just as Thompkins is beginning to feel complacent, Bill returns to the States to work on his house, leaving the sinister bean counter Allair Belok in charge.  Belok embodies every stupid, unscrupulous, bullying executive you've ever worked for.  Sadly, his tactics seem true to life. They certainly rang a few bells for me.  Thompkins must face arbitrarily shortened schedules, merging of his parallel projects, and forced overtime.  On top of this, he must contend with the well meaning purveyors of process improvement, whom Belok sics on him with even more unreasonable goals.  

Thompkins is not alone in his struggles, however.  Belinda Binda, the world's greatest project manager, burnt out and now a bag lady, agrees to help Thompkins staff his projects.  So does Ex-general Markov, former head of software development for the Moravian army.  Lahksa, the beautiful resourceful spy, runs around the world sending Thompkins consultants for 

brief visits.  The reclusive Aristotle Keneros, Moravia's first programmer, helps to divert the process improvement folks, and teaches Thompkins the importance of debugging the decomposition and interfaces during the design phase.  

That's it for the plot.  DeMarco patterned Mr. Thompkins after George Gamow's character of the same name.  Gamow had a wonderful ability to explain physics and mathematics with stories.  In One Two Three .  .  .  Infinity, one of my favorite books when I was in high school, he explains complex numbers with a story about buried treasure.  Mr. Thompkins is a 

bank clerk who goes to lectures on science, falls asleep, and has wonderful dreams that make the concepts clear.  

DeMarco has followed that tradition admirably.  His chapters are little vignettes of project management.  A problem arises, a consultant shows up to help solve the problem, and Thompkins adds a few aphorisms to his journal.  According to DeMarco, most of these aphorisms come from his own journal and represent lessons he learned the hard way.  

Here are a few of the aphorisms that I especially like: 

• Four Essentials of Good Management: Get the right people, match them to the right jobs, keep them motivated, and help their teams to jell and stay jelled. (All the rest is administrivia.)
  
• There are infinitely many ways to lose a day  . . . but not even one way to get one back.
  
• People under pressure don't think any faster.
  
• It's not what you don't know that kills you  . . . it's what you know that isn't so.

The last one is an old proverb, but DeMarco applies it to one of the sacred cows of software development, code inspection.  

I've discussed the more general aspects of DeMarco's book here, but parts of it get pretty technical -- though rarely enough to bog down the story.  DeMarco believes in metrics and modeling as project management tools, and several of his vignettes show surprising ways to use those tools.  

At the end of the book, Thompkins gives away his journal, saying "I can never imagine opening it again.  I don't need to.  I carry those hundred and one principles everywhere I go. They're carved into my hide." The book is a crash course in project management and team building.  If you do any sort of technical development, you should read it and absorb it.