A single long page, for printing convenience (the
old justification of structuring pages because of slow
modems is dumb).

The conventional textbook organization will not be
used, in favor of a more conversational flow and anecdotal
organization. I'm not trying to put people to sleep;
I'm trying to improve user interface design.

I opened the dropdown
again and there was something funny. It had changed from model
numbers to a list—well, sort of—of serial numbers
or so it said. The page hadn't responded because it was waiting
for me to make another selection—a second selection—from
the SAME dropdown list... ahhhh, the old Multi-Invocation,
Drop-Down Selection/Function control... how could I miss it?
Or as we say in the software world, how could I be such a stupid
user?

And at that moment this book was born. I've written a lot
about usability and user interface design over the years, but
I always ask myself, what is the real solution to the bigger
problem... not the individual UI fixes, but the whole industry.
How can we stop raising whole legions of developers who will
make the same mistake as on the weedwacker page? Where exactly
is the root cause that must be pinpointed correctly to improve
the situation. And I determined that it is in High School,
in 10th or 11th grade, maybe earlier. That is what this book
is for, to teach young programmers about the user side of software—what
makes software friendly, or not.

Jack Bellis —June 14, 2004

Chapter 1, Basics

There are dozens of good books and maybe hundreds of good
websites on usability. In fact, this book is a follow-up to
my 1997 "Computers Stink." You can read the PDF on our
Resources page. All of the books have got concepts, rules,
ideas, and checklists galore. But somehow rules and concepts
are making slow progress in improving user interfaces. Or are
they? Perhaps it's possible that the universe of interface
design is exploding so rapidly that any improvement is actually
a great accomplishment. Maybe I shouldn't be disappointed at
the Shindaiwa page... maybe I should be amazed that I can go
three or four days between such experiences. And during that
interval I will have looked at over 100 sites, perhaps 1000
pages!

In any case, it does appear that concepts are slow to sink
in... slow to become inculturated. Checklists are good, too
but they seem to be the tool of experts, not the food on which
to grow. So our approach will be to simply supply a handful
of carefully selected examples. Examples are everything in
computer work. That's because everything is so new. Concepts
are nice but they're really just an exercise undertaken by
the pundits of the industy. What you need are techniques. That's
where the rubber meets the road, so that's what this book will
made of.

OK, Maybe Some Concepts Won't Hurt

So that the reviewers out there don't totally dis' us for
presenting a rambling, stream-of-conciousness pile of blog,
here's a summary of the principles we'll be demonstrating:

Explicitness

Usability can't be boiled down to a single item, but
if you are forced to choose one, the best you can do
is explicitness. Users can put up with almost any software
shortcomings as long as they can figure things out. And
the only way they can figure them out is if they can
see what's going on.

Accuracy

Be perfectly accurate. Users are dealing with extremely
detailed situations. Information that doesn't exactly zero-in
on the circumstances will eventually be a problem.

Use Verbose Phrasing

Don't try to name features or web links with a single
word. Use a noun and verb. Use several words if that's
what it takes.

Directness

Don't put intermediate words or links or buttons or images
in between the user and the specific instruction.

Grouping

Put related things together.

General-to-Specific

Put important things at the top and left.

Segregation

Now that you've got groups of things, separate and distinguish
them to signify them accordingly.

Use Existing Solutions

Creativity is great, but when it's unneccessary, it's
a mistake.

Consistency?

Everyone constantly says that you should be consistent,
but this is overplayed. There are times when you need to
differentiate things. The answer to many consistency questions
is the same as the answer to all computer questions: "It
depends."

Make Everything Browsable

Sometimes this means using menus instead of special techniques
or values. Sometimes it means using words instead of icons.

Use Descriptive Values, Not Internal Codes

Use words that any competent Windows user will understand,
not industry jargon, computerese, or even special business
language. Translate things into what users are trying to
do.

Use Images as an Additional Option—Not
an Alternative—to Words

Graphics are good for coming back to a feature, not for
figuring things out in the first place.

Hopefully that didn't hurt too much. Beyond that, they get
too detailed... not really principles. And did you notice that
they're not particularly computer principles? They're actually
principles of traditional print publishing, book-writing, newpaper
layout, and so on... just general communication concepts. Yes,
that's right—that's write?—computer design is communication
design, just more dynamic.

The analogy to newspaper layout is from a great usability
book, "Don't Make Me Think," by Steve Krug. Read
my review.

If the list above is not detailed enough for you and you don't
want to wait for the rest of this book to be completed, see
Computers Stink on the Resources Page. Otherwise, please
be seated and pull the safety bar down. The ride is about to
start. We will attack the list in no particular order.

In the Shindaiwa example, the author tried using a creative
solution. That's fine in some cases, but users are already
accustomed to a different solution. The page should have a
Go button and load a different page with the next choice.

Too Much Creativity, Before

Here's the second part of the Shindaiwa page, after I selected
a Model Number. Remember, it was totally unnoticeable that
the dropdown label changed.

Too Much Creativity, After

To improve the page, there are several options, but the most
common one you'll see is to refresh the page after the first
selection so the user knows a second selection is being made:

The lesson here is to use simple techniques that you see in
use elsewhere, whenever they get the job done. If there are
times when you must create a new technique, fine. But don't
create new techniques just to save time or work, or because
you think it's a better way to write the code.

Chapter 2: Accuracy

This motivation to finally commit this next block of content
to little blips of magnetism on some far-away platter is thanks
to Tim, a software engineer who's recently been nominated
"The
UI Guy"
at his
company. Other than that he gets no credit or blame for its
content, satirical, technical, or otherwise. Let's hope that
some day these little blips grow up to be proud pits on an
optical disk, or even someday—try to imagine it—ink
on a piece of paper.

The principle is as
simple
as can be: accuracy. You wouldn' think that would
be a problem for such folks as are attracted to the precision
on-off world of logic and algorithms, wudja? Well, my example
is from no less than IBM. If you're reading this in the year
2045, that was a crusty ol' company that Megamergercast (the
mega media conglomerate) bought and buried, indirectly by having
bought and buried Microsoft in 2014. Anyway, here's how IBM
did it in the good ol' days. What's wrong with this picture:? ...or
is it ?:

Accuracy, Before: IBM Login

Answer: the field label, "IBM ID" is inaccurate. It should simply
say Email Address. Here's the "After" version, not exactly
rocket surgery (give credit where it is due: Steve
Krug/book on Amazon), but
I promised before-and-after examples:

Accuracy, After: A Simple Fix

Now, I know what some of you are saying... "Hey, it says right
there in the blue text that it's their email address, right?"
No, it implies it. It's not in the field label, so it's
not direct. That's the problem with this UI stuff, you could
call this accuracy, or explicitness, or directness, or positioning.
But you can't mistake this for an issue of brevity versus verbosity.
So let's look at that next.

But first a note. Isn't it ironic that IBM, which ascended to
prominence on its ability to speak Computerese, descended to
dust on its inability to speak English?

Chapter 3: Verbosity

This might be my favorite UI issue. For the last few months
I've been using this new source control system called Accurev.
(Source control means a program that manages shared files
on a network and prevents two people from
editing a file at the same time.) Now, Accurev is an incredible
product compared to the simpler tool I've used in the past.
It provides a whole regimen for what's called configuration
management, escalating software versions and so on. But it
has this little Achille's Heel. (Hmm, there's no such thing
as a little one, is there?) It tries to reduce all of its magic
to single words, a new vocabulary of file contention dynamics.
Look at the following figure:

Verbosity, Before: Accurev

Can you guess what the difference is between an external and
stranded file is? Or how about member versus member modified?
External,
maybe you can intuit that one if you've got some code in your
blood.

Verbosity, After: RoboHelp's Source Control System

Now lookie here. Here's a competing product, of sorts, that
takes an entirely different approach:

It spells out "external" and all the other statuses in descriptive
words. External becomes "not controlled." This is a file that
one has not yet incorporated into the system. Stranded is one
that was Removed from Version Control. Member/modified is "Checked
Out Exclusive" and so on. All of a sudden, the system becomes
self-training. And that is the goal of all usability if you
ask me. (I'll take your presence here as evidence that you
asked.)

The Goal of Usability
...
is to eliminate the need
for in-advance training.

Yes, usability also concerns itself with speed
after training, but we'll get back to the ivory-tower-pontificating
after we smother the topic of verbosity. The rationale for
the Accurev approach is that brevity is a virtue, and eventually
the short words are better, easier to scan, or more elegant
whatever that means. Well, if elegant means that even brilliant
programmers have to run around asking for help after they unintentionally
clobber each others' files, then elegance has its place. Accurev
has one of the worst and most dangerous learning curves I've
ever seen. Even the brightest people I've worked with for years
can't explain some of its statuses.

Getting back to the issue of speed after
training, do the single words have any value? Absolutely. But
there are
two fixes needed:

Make
them an option that one turns on after learning the system.
All complex systems, particularly business systems that
computerize a whole job category or industry, should have
a menu option for Beginner or Advanced Terminology.

The information that causes the statuses should be explicitly
displayed, probably as additional columns in the same listing.
For intstance, it should list the date that the local and
server copies were edited, flags for presence or absence
in each place, and so on. Then one could account for the
conclusions implied by the statuses. This gets us into implicitness
versus explicitness. But that's another chapter.

Chapter 4: The Usability Pyramid

It's time to interrupt our examples for another commercial
from our sponsors, the high priests of theory and concept.
This time they would like you to consider that the usability
principles are not an amorphous blob but indeed have a hidden
beauty to them. Consider the following pyramid. Since the
US FDA recently (April 2005) abandoned the pyramid for their
food recommendations, we've taken that now unemployed icon
and put it back to work.

Actually, ours started out as a tetrahedron, but depicting
that left face cluttered the visual so poorly, we went back
to the old King Tut style. By the way, there are two mistakes
in the figure. Can you find them?

A picture being worth 1000
words, I'll let it speak for itself but
let me
clarify
a
couple
of the items:

Menus are one extreme of letting users access functions,
and I believe that drop-down
menus are and will continue to be the ultimate (as
far as learning goes) for a long, long time. But that final
item in the Producing Tier, "Functions Accessed by Data...
what's that all about. What that refers to is getting to
functions by accessing items in a collapsible outline
control, and seeing pertinent functions, either by right-clicking
or having them otherwise enabled in the interface. Here's
an example of a web application from approximately 1999,
Asymetrix Librarian:

I see this as the diametric opposite of drop-down menus. Once you
completely understand the metaphor/paradigm/data structure
(call it whatever you want) of a system, you want to get
to function in a single action, by finding the data on which
you want to act.

The other thing to explain concerns "Multiple Metaphors"
and "Multiple
Paths to Functions."
Multiple paths means that users should be able to find a function in more than
one place, perhaps on a menu and in a toolbar... maybe even
in two places on the menus. Multiple metaphors means that
the most advanced programs should make themselves usable
in more than one way. The simplest example is that systems
with a robust GUI (graphical [point-and-click] user interface)
should also have an ASCII (American Standard Code for Information
Interchange, command line) interface.
Let me think of another one.

Chapter 5: Directness

If you're looking for
elaborate technology to answer your interface design problems,
you'll probably be disappointed. Most situations can be improved
with simple
wording, as in our example here.

Directness, Before

How would
you improve this dialog?

This is one of the
most common problems I find in the programming world. The
example here was from approximately the year 2000. I came
across the identical flaw in the
system I'm working with today (in 2005). The "before" dialog
is probably a simple case of "the convenience of the programmer taking
precedence over the convenience of the user," (because it's easy
to make a dialog with standard buttons). Many software development "environments" providea
a standard "message box" capability and the programmer can choose
to display one, two, or three standard buttons such as OK, Cancel
and so on. So no matter how peculiar the actions are, the programmer
looks for a way to map the options to the standard buttons. Well,
that's fine if the choices naturally fit the words OK, No, and
Cancel. But they have no relevance to the printer dilemma. Let's
look at more explicit wording.

Directness, After

Stare at the before-and-after until it sinks in.

Chapter 6: General-to-Specific

Put important things at the top and left. That's what our concept list
tells us.

In our part of the world, we read from left-to-right
so you should position the most general items in the upper
left. Our "before" poster child is from
Microsoft Hotmail. Notice the name of the page running off
the page to the right:

Before: Hotmail's Page Name

After: A Little Touch-Up Work

The page name is more general than the content of the page so it should
be above and/or to the left of the content. So that's what
we'll do.

We can't make this too complicated, there's just not that much to it.
But then, how could the world's biggest software something-or-other
get it wrong? (Maybe they wanted to advertise their Messenger
product where your eyes would be looking.) Yet this issue is
frequently the cause of complex problems. Let's look at another
one, a more serious one that has caused hundreds of thousands—probably
millions—of hours of lost time world-wide:

In this dialog from the world's most used software application, MS Word,
the Apply To field is the most general item in the dialog.
It controls something called the "scope" of the dialog... how
much of the document the dialog applies to. In this dialog
and a few others in Word, users don't realize until they mess
up their document that they should have chosen a different
scope. But not until spending a few minutes or hours backtracking
and debugging. Where should the field be moved to? We'll leave
that up to you.

Chapter 7: Grouping

If you haven't noticed by now, a lot of UI design is for the
eyes, before the words are even read. Here's an example
that shows the importance of putting things together in blocks.
The following dialog appears in MS Word when you open a document
(from your network) and someone else has it open already:

Without reading every word, it's a little hard to tell what the relationship
is between the top two buttons. The following redesign groups
the Notify button with its explanation. Just as importantly,
it groups the Read Only button with Cancel. This helps clarify
that your basic choice is to either open the document as
read-only, or not. The notification feature is what you might
think of as a side track. This is admmitedly an interesting
situation, in that all three buttons are "terminating" buttons
and I'm recommending putting one of them in a box (instead
of at the bottom or side), but UI design is creative, folks.
You're not going to help people if you try to use simplistic
rules for complicated situations.

By grouping things separately, we let the 'mind's eye' quickly evaluate
the choices. The user can instantly ignore the notification
choice if they just want to read the document. And the usual
choices of OK/Cancel are respected even though OK has the
twist of being read-only.

Chapter 8: Noise Reduction

This chapter is courtesy of a guest expert, Luke Wroblewski of LukeW
Interface Designs (www.lukew.com). If
you want to be a slam-dunk genius at the visual side of interface
design, spend a lot of time
reading Luke's site.
In his article, So
the Necessary May Speak, Luke presents a wonderful before-and-after
demonstration of how to present table data.

Take a look at this table. It's fairly common for work you'll see if
you ask someone to take data from a database and put it in
an HTML page:

It's not horrible but would you recognize any of its shortcomings? Now
look at the "after" version:

Here are the techniques that were applied:

Eliminated fluff by removing "General" and "Number
of." Even if these were the literal
names in some other part of the system, writing
is for reading, and no one wants to read repetitive phrases.

Eliminated redundant
phrases. This is the biggest theme. It's equivalent
to the old "distributive law" that we learned in fifth (?)
grade about multiplication, right? (3 x 4) + (3 x
5) = 3 x (4+5). The "3" should
only be stated once. As a result, "Discharges"
and "Admissions" were changed to headings.

The black heading and bold black text were softened.

The vertical borders were removed. I've noticed this technique
in better designed tables for years, not just on the web
but in plenty of books and magazines.

All of those techniques come under the umbrella of reducing "noise,"
which is visual stuff that hides or distracts from the real
story. Two more techniques were added that are just pure
judgment...

The ultimate information—the numbers—was made bold.

The New Admissions section was "banded" with light blue.

But if there were no room for judgment, then we wouldn't be needed
for this work in the first place, and it wouldn't be much
fun either.

Explicitness

The following figure is from a "source control" system, one that
has a shared database of files on the network. When you delete
a file, here' s the message you get.

Now, you have to picture that the experience of learning a new
source control system can be pretty harrowing since you're
risking what seems like the loss of otherpeople's work...
critical team work. Misunderstanding the system can be
harrowing. So what does "delete is just delete" mean? The
message is trying to tell you this:

"Explict" means "doesn't require any translation. Would you agree
that the reworded message is as close as we can get to
the issue?

Precision

*** The End for Now ***

To Do List

When the user does not have control, announce it prominently. If programmers
were painters: Could you imagine "Wet Paint" that were the
size of Post-it notes, perhaps stuck to the leg of a freshly
painted park bench? Intermediate
progress.

Embed the instructions: consider the example of MS Project, a software
product that "sets the bar" on how complex a generic task
can be. It requires lots of instruction on the screen.

Trap errors at every level and report them in descriptive words.

Next Installment:
It's Up To You!

I'll write Chapter n when someone emails
me that they're interested in reading more. And feel free to send a
comment or question. Let me know if you want your comments added as a preamble
to the
chapter, with or without your identifying information. If you want your
info included, at the minimum I'd expect to use first initial, last name,
and city.
Otherwise, it's up to you.

Thanks, Jack May 28, 2005

"My interest in usability arose from the pain
and tears of patching the wounds of suffering interface designs
with the inadequate bandages of help files and user guides."
— Daniel Cohen