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!
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
- This talk is designed to induce controversy and different ways of thinking. Please don't take it personally. It is not about the software you wrote.
- Of course, you don't have to agree with everything in this talk.
- I use negative examples because they are entertaining and easier to identify with. Also, it is easier to throw one away you will never get things right at first try anyhow.
- Negative and positive examples are freely intermixed in the text. Consider it a challenge.
- Designing for usability is a state of mind. Like striving for perfection, the job never ends. Also, stupid users tend to increase in numbers the more successful your software becomes (Hey! aren't we lucky to have so few users ;-)
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 part of the scene (you're Mario)
- The character is an extension of your body
- Every whack, kick, jump, swim, fly, feels natural
- All controls are direct (Look ma: no controls!)
- Feedback sight, sound, (with rumblepack even tactile,) is immediate
- You don't need no stinkin' docs
You are oblivious to the fact you're interacting with a software program.
You and the program are one.
Crossing the ChasmThere's a simple and quick test for usability. It is called:
(Apologies to Geoffrey Moore)``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 MetaphorWhen we define a scene or a world in which the user operates we should use familiar objects and familiar language.
- Are we speaking the same language?
- Users (usually) cannot read our minds, yet:
- Users (usually) know how to read our button labels
So one obvious way to screw the metaphor is:
Use unfamiliar terminology
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:
Design from the GUI downRight?
Think about the GUI. Only then program.
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
What's wrong with this picture?
Solving The Wrong ProblemDebuggers 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.
- Single stepping is the slowest way to get to the bug... ``It took my program two seconds to hit the bug from startup and you now want me to step thousands of steps to get there ? Get serious!''
- Inspecting variables, disassembling, and getting involved in other low-level details is exactly the wrong approach. When you look at bugs this way, they become the proverbial needle in the haystack
- Computers are great devices to walk-through zillions of operations per second. Debuggers, OTOH, are great devices to make people do the tedious walking instead.
- How many people do you know who:
- Start a debugger, get to a point, pause, scratch their head, then continue running the program in their heads, because debuggers are labor intensive devices and such a pain to use ... or
- Give up, let the computer do the walking. i.e: start using 'strace' or add printf's
The debugger that never wasTo solve a problem, we have to start with defining the problem.
- What is a debugger supposed to solve?
- How can one achieve this faster?
For starters, debuggers are designed backwards.
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 undoHow many times you said ``Oops, one step too much'' and had to rerun the program all over again from the start?
Saving a process state is easy:
Why do editors have "undo" and debuggers don't?
What a concept...
Multitasking OSes do this all the time.
Moreover, it is enough to save deltas only.
The debugger that never was (cont.)
Coarse grained steppingDebugger 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.
ControlsWhat'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!
The great american screwllbarWhat 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.
InteractionBy 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.
ObservationThe best GUIs are those in which interaction feels ``natural''.
What is it that creates this feeling ?
In Mario64 all interaction is:
- Context sensitive
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 ?
FeedbackWhat 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
FeedbackSpeaking 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) paradeLet'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.OK:
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.
e.g:prog: can't open file for reading.
prog: can't open file.
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"Without even identifying themselves.
"where are you?" (mesg y)
Designing for UsabilityOne 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''
- 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.
First Principles of UI design
Tog has always been the best. I wish more GUI designers first read this one...