Unorthodox Usability

This is a presentation I made in December 1998 to my MineSet team mates. MineSet is a very powerful data mining and vizualization product of SGI which literally turns zillions of lines with numbers into something that can be understood in a flash. This is what insight is all about.

Anyway, I thought this talk may be beneficial to other people outside SGI, especially to the Linux community who is now working on application level software. There are also some important observations which I have never seen in the literature for those who write debuggers. Maybe someone can write the best damn debugger for Linux based on this -- Ariel

It is all in one piece, no clicks are needed. Just Scroll down and enjoy!

Unorthodox Usability
20 (or so) ways to ensure
no one will use your software

or go out of their minds when they do...

A talk by: Ariel Faigon

A few introductory notes

What is Usability ?

Usability (n.):
A great and important virtue of man-made-things.

Usability is comprised of 3 elements:
  • Metaphor - cognitive universe we operate in
  • Control - what can we do in that universe
  • Feedback - what happens when we do it

Any one of these elements can be screwed up big time.

Let's see how.

But first, let's establish a reference point.

The Usability Gold Standard

Mario64: one of the best GUI ever created:

Some call this GUI ``first person'' and the experience ``immersive''.

You are oblivious to the fact you're interacting with a software program.

You and the program are one.

Crossing the Chasm
(Apologies to Geoffrey Moore)

There's a simple and quick test for usability. It is called:
``The 5 minute test''

Your software is unusable
if your users give up on using it
during the first 5 minutes of trying.

The first few minutes are critical. Any significant barrier popping up during these minutes (like having to stop and read the documentation) is potentially terminal.

This is not to mean that usable equals addictive, but the opposite is probably true. You can go for hours on end with Mario.

Being fun and entertaining goes a long way towards improving usability. Being frustrating, unnatural, awkward etc. causes users to realize they can make better use of their time and give up quickly.

Ladies and gentlemen, start your stopwatches...

The Metaphor

When we define a scene or a world in which the user operates we should use familiar objects and familiar language.

So one obvious way to screw the metaphor is:

Use unfamiliar terminology

Terminology (cont.)

Use of unfamiliar terminology is especially common in specialized, sophisticated, low-volume, software -- It shoudn't be so.

Changing a button labeled ``induce model'' to ``learn'' or ``study'' may sound too trivialized, even sacrilegious to data mining experts, but think about which terminology has more chance to be understood by my mom ?

Always do the Mom test
before labeling a button

Our 5 minutes spent will be recovered many times over by our users. Instead of thinking of this as a "trivialization", think of it as a good opportunity to make niche technology mainstream.

Terminology (cont.)

Another way (not really better) is to use vague or very general terms. Every other program we use daily has lots of these.

Say there's a button labeled:


What the hell does it do ?

This is not a puzzle...
You may as well say: ``Hey, click me to figure out.''
Or better, just leave the button blank...

Friendly Metaphors (cont.)

One way of making a metaphor easy and natural to users is to use well known paradigms and everyday familiar objects.

  • Desktop familiar objects: calculator, calendar etc.
  • A Trashcan to delete files
  • A Spreadsheet when dealing with tables

The Metaphor - Where to start?

The no 1. myth of application design: Right?

Wrong. You have to think about the problem first.

The no. 1 usability killer
(sure beats killing the metaphor):

Solve the wrong problem

Let's see an example...

Solving The Wrong Problem

Think debuggers:

What's wrong with this picture?

Solving The Wrong Problem

Debuggers are a good example for tools which solve the wrong problem; rather than helping pinpoint the bug quickly, they become a tedious way to spend an evening.


The debugger that never was

To solve a problem, we have to start with defining the problem.

It's Backwards, Darling!

For starters, debuggers are designed backwards.

Rather than:

Start in main and [slowly] step forward

We have to:

Start from the problem and [efficiently] step backwards!

The debugger that never was (cont.)

The missing undo

How many times you said ``Oops, one step too much'' and had to rerun the program all over again from the start?

Why do editors have "undo" and debuggers don't?
What a concept...
Saving a process state is easy:

Multitasking OSes do this all the time.

Moreover, it is enough to save deltas only.

The debugger that never was (cont.)

Coarse grained stepping

Debugger step control should be event driven. Rather than polling umpteen variables to check whether they changed...

Start with the corrupted variable, assertion failure, or symptom. Back-propagate it using dataflow analysis, and trap the changes to all possible causes up to a certain (small) depth.

e.g. We start by asking stuff like:

    • What leads to this assertion?
    • When does this index go out of range?
    • When does this variable get this bad value?

Coarse grained views

Views should be animations of the stack, heap, code in VCR form (forward, rewind + speed slider) all linked to the interesting variables or lines of code. For example we can have an animation of our growing and shrinking stack changing color to red and/or halting execution when a condition (e.g. variable gets corrupted) becomes true.


What's wrong with this picture?
The Control Freak's Dream

Some Great Ideas (tm) for controls

  • Create a 1000 buttons with cool symbols on them
  • Use hieroglyphics instead of cool symbols
  • Place buttons as far as possible from the object they are supposed to act on
  • Make lots of buttons then grey them out
  • Put frames within frames within panes so your main window doesn't waste too much real estate
  • Surround everything with cool thick decorations and titles
  • Add a wide scrollbar on every dimension possible
  • Make the page jump back when the cursor straddles the scrollbar area (works best for Parkinson patients)
  • Let them use their mice! A lot!
  • Never use defaults, let them sweat!

Apropos scrollbars...

The great american screwllbar

What the book ``Insanely Great'' will never tell you:
The scrollbar is the worst control ever invented.

  • It all started on a rainy day in a small town named Cupertino (or, if you insist, in Xerox PARC)

  • The &#$@%!-ed mouse had only one button

  • So they made the SB ubiquitous, and since then we've all been:

    • Double clicking like hell (and still can't get it right)
    • Going back and forth from our mouse to our keyboards
    • Unable to pan our pages diagonally
    • Moving a funny rectangle to move something else...
    • ...In the opposite direction

The great american screwllbar (cont.)

Exhibit 1:
MacOs 8.5 is bringing us a great screwllbar innovation:

    Hey, they finally put the two up/down arrows next to each other!    

This is not to pick on MacOS!
In fact, they are one of the only ones in the industry, (LessTiff, NextStep are others) who got it right...

Too bad no one realizes why scrollbars were invented in the first place.


By combining a metaphor and its controls together, we define the way a user interacts with our world. This interaction is the essence of what makes our software usable.


The best GUIs are those in which interaction feels ``natural''.
What is it that creates this feeling ?

In Mario64 all interaction is:
    • Object-oriented
    • Direct
    • Context sensitive

Interaction (cont.)

When Mario wants to kick Bowser, or jump on Yoshi's back, he just does it!

Imagine what it were like if you had to select Bowser, then go to the top pull-down menu, and click on kick.

GUI elements considered harmful:

  • Pull down menus
  • Multiple windows and dialogs
  • Long uncommitted intermediate states
    • OK/Cancel buttons
    • Multilevel combinations of the above

Interaction (cont.)

Back to debuggers. Let's look at a few objects, the possible operations on them, and the recommended interaction mode.

Object Operation Visual cue Interaction
Source Line toggle breakpoint Stop sign on left margin Mouse toggle
  execute to here Pop up menu mouse click on line
Variable Inspect value baloon help brush mouse over variable
  Trap change text color to indicate "trapable" click on variable brings a popup

The idea is:

  • Every object has its logical operations defined
  • Operations are done by interacting with the object
  • No indirect interactions via distant controls

So after settling on a Metaphor and defining the objects sit down and for each of the objects, ponder:

  • What would the user want to do with this object ?
    [Not what you (as a programmer) would want to.]
  • How to make the interaction direct ?
  • How to make the interaction as obvious and natural as possible ?


What is Feedback?
  • A confirmation/reinforcement of a user action.
  • Not an obstacle on the way to the solution

Which leads us to a few new ideas on how to screw an application:

  • Let users do something; then punish them for doing so
  • Have some controls just give an error message
  • Give lots of error messages
  • Give notices like ``file didn't exist, created successfully''
  • Do this as a popup to force them to click OK
  • Make otherwise normal feedback look like error messages

And while on the subject of tormenting our users:

  • Write a lot of documentation, preferably on paper
  • If they can't do it, you can always tell them to RTFM
  • Make the user guide really thick
  • And don't forget: lots of `Note's and exceptions


Speaking of feedback; aren't error messages great?

Let's see: we are in the midst of some complex code, the situation is too complex to deal with, so why not just bail out and blame it on the user? Sure makes programming easier, saves a lot of design effort, etc. Wonder why we use them so often ?

What error messages basically say is:

Hey there, you dummy!
You cannot do this!

So, to make our application highly usable:

Forget about fool-proof design,
just give lots of Great Error Messages (tm)

The Great Error Message (tm) parade

Let's go from worst to perfect:

Really Bad (tm):

Program gives no error message, just does what you want.


Helpful error message, with a possible solution:
Program name: this version is not licensed to perform this operation. Click here to extend your license. Please have your credit card ready.
Really clear error message, no hint for a solution...
(Insert joke about that plane in a storm above Redmond.)

Getting better:

Take the basic:
progname: can't open ``filename'': permission denied

(i.e. program-name, object, object name, failure, reason) and start dropping the unimportant parts, or just add some numbers.


prog: can't open file for reading.
prog: can't open file.
can't open.

The Great Error Message (tm) parade

But we can do better that that...

Really perfect:

Check out ``The Unix Haters Handbook'' for some examples.

Ah, those cool 4.1BSD to 4.2BSD days, when the network was added, and suddenly all terminal apps started saying really strange things like:

"not a typewriter"
"where are you?" (mesg y)
Without even identifying themselves.

Designing for Usability

One of the best ways to kill usability in the long run is to lock into early implementations details early.

The more monolithic our implementation is and the bigger and hairier the interfaces between components are, the more likely it is for our program to:

  • Become less usable the more code is added
  • Make it more difficult to reverse this trend

Thinking early about the components of the system and defining small interfaces between them leads to information hiding and simplicity that is crucial for both maintaining and improving usability in the long run. Recommendations:

  • Think APIs early
  • Keep all interfaces small and simple
  • Keep complexities under the hood
  • Make the UI independent of the ``engines''
  • Componentize
  • Design around the data rather than the procedures


  • Always remember Mario
  • Never forget your mom
  • First define the problem
  • Apply the 5 minute test
  • Be direct with your objects
  • Be sentitive with your contexts
  • Be positive with your feedback
  • Componentize your design
  • Think API; keep interfaces small

  • Don't take things personally
  • Relax: It'll never be perfect
  • Cheer-up: It can be much worse

Observation: it is way much easier to write a presentation on how unusable software is, than to write highly usable software. Notwithstanding the humoristic style of this presentation, my hat's off to those who write usable software.


Further Reading: usability related links