Teaching Users to Read

October 25, 2004

I've talked about irresponsible use of dialog boxes before, but a few pages I've read recently highlighted an interesting aspect of this topic that I hadn't considered. First, Joel Spolsky:

This may sound a little harsh, but you'll see, when you do usability tests, that there are quite a few users who simply do not read words that you put on the screen. If you pop up an error box of any sort, they simply will not read it. This may be disconcerting to you as a programmer, because you imagine yourself as conducting a dialog with the user. Hey, user! You can't open that file, we don't support that file format! Still, experience shows that the more words you put on that dialog box, the fewer people will actually read it.

And Mike dug up a fascinating Eric Lippert comment on the same topic:

It's not that users are morons or that they "forget" to think. It's that users are trained to not think. Users very quickly learn from experience that:
  • Dialog boxes are modal. But users do not think of them as "modal", they think of them as "preventing me from getting any work done until I get rid of them."
  • Dialog boxes almost always go away when you click the leftmost or rightmost button.
  • Dialog boxes usually say "If you want to tech the tech, you need to tech the tech with the teching tech tech. Tech the tech? Yes / No"
  • If you press one of those buttons, something happens. If you press the other one, nothing happens. Very few users want nothing to happen -- in the majority of cases, whatever happens is what the user wanted to happen. Only in rare cases does something bad happen.

In short, from a user perspective, dialog boxes are impediments to productivity which provide no information. It's like giving shocks or food pellets to monkeys when they press buttons -- primates very quickly learn what gives them the good stuff and avoids the bad.

Well, I couldn't help thinking of this classic Gary Larson strip:

What Dogs Hear

My intent is not to make fun of users, but to illustrate that there are far more effective ways to communicate with your dog. Essentially, any time you're asking the user to make a choice they don't care about, you have failed the user. Well designed software takes care of "teching the tech tech" all by itself, and leaves the user free to worry about things relevant to the work they are doing. Dialog boxes are almost always detrimental. The goal should be to write an entire application free of dialog boxes.

Well designed software avoids asking the user questions by...

  • Anticipating user needs (wizards, templates, autocomplete, IUI)
  • Remembering past preferences and using that to better anticipate future needs
  • Silently and automatically protecting the user from the consequences of any negative actions (versioning, undo)

It's amazing how few software packages even try to meet these goals, even with simple, common things. For example, why does the file save dialog always default to My Documents even though I saved to Desktop the last time I used the application?

Posted by Jeff Atwood
17 Comments

The reason it defaults to My Documents is what happened when Microsoft tried doing bullet #2: when non-primary users of the computer changed the last saved location to anything else, the primary computer user thought the document disappeared (since most novice computer users don't understand the file system). UI guy Alan Cooper even has one of his belabored stories about it.

That's one of those times where a novice and an intermediate person differ. I think there should be a per-user option to change that behavior.

Darrell on October 26, 2004 9:59 AM

Burton, thanks for the great compliment-- but I think they've even had Alan Cooper on DNR. They rate much better guest speakers than me. ;)

Beginning users should log in under their own account, so I still don't see why the preference cannot be saved. Unless users don't understand logging off, so they all end up using the computer under the same account, which is quite possible..

Jeff Atwood on October 26, 2004 12:17 PM

Partly the problem is the users themselves.

I recently wrote a small intraset website for a client. Before acceptance they required that I add in dialogs after certain events (writing to a db) had succeded or failed ... duplicating what they already had prominantly displayed on the screen... such is life.

Ian

Ian Murphy on October 26, 2004 1:14 PM

It's not too incredibly difficult to store the last directory used and then pass that to the file save dialog. You could do the same when using the BrowseForFolder stuff through Win32 calls, .NET, or wherever you decide to use it. It's a little tedious extra step, but I code around small annoyances like this.

I'd rather have this behavior than to pollute the registry with more meaningless control storage like the AutoComplete stuff. You do realize you would have to store some value for EVERY CONTROL that uses this, not just some "master file save dialog default". Your app would compete with any other app on the system which doesn't sound too fun to me.

Jeremy Brayton on October 27, 2004 4:09 AM

Thinking in the last two points "Save as path" and "dialog boxes", comes to my head a generic dialog box that will match in the most of the cases:

Change the user and press a key...


;)

Detky on March 28, 2007 4:06 AM

Ok, I admit that this is a very late reply.

About Darrell's reasoning on why Windows is not flexible over the "last folder" thing, I answer that, in that case, a good and simple solution would be a drop-down box with the last saved locations.

Indeed this "default My Documents" folder pissed me off a lot on the days I used Windows, as well as almost all the folders that were automagically created - with, excuse me, very stupid names like "My Music".

Oh, "My Computer" every time got renamed to "Computer".

Andr Neves on August 12, 2007 9:49 AM

Well designed software definitely will anticipate user needs, remember past preference and choices, and protect users from themselves, however those things can be difficult, long and consequently costly to implement. Why would your manager want you to implement a complex undo system, when you can simply pop up a dialog and make the user confirm their choice? Sure it's not as cool, but cool isn't usually what project schedules are about... not that that stops us from implementing them at times anyway :)

Mike Hall on August 31, 2007 9:28 AM

wow i love the blog most deff adding to my favorite list thanks for the comic strip laught.

john wolfe on January 24, 2008 9:01 AM

you need to put some stories that you can read on there xxx

rosiebeth on February 6, 2008 12:25 PM

OMG

OMG on May 19, 2008 2:56 AM

this is a very late reply, but did you know that most of the options I have seen refered to here are default settings on mac os x leopard?

ebola on May 20, 2008 3:43 AM

I add this very late comment only to mention that the abovementioned Alan Cooper story is now available on Google Books, here:
http://books.google.com/books?id=04cFCVXC_AUCpg=PA11lpg=PA11dq=%22alan+cooper%22+%22my+documents%22source=blots=jfvgY5n3kPsig=MFhjq6Op9DZZFeSRuNDKmJhy07Ihl=ensa=Xoi=book_resultresnum=1ct=result

Daniel Rutter on November 1, 2008 11:32 AM

The save dialog not showing the last used directory is not a Windows specific problem. It also seems to be both a Java and Linux problem. I can't count the number of times where a program has presented me with a save dialog and the folder it's showing me isn't where I opened the file from, let alone the last place I saved the file to.

This doesn't happen all the time though. I'll admit that some programs do a pretty good job, it's when they trip up that bothers me. It seems to happen more with programs that use a GUI library that differs from the desktop environment ( ie, non-Gnome programs running in Gnome ). One of the small costs of using Linux I guess.

Actually, what really bothers me isn't even the save file dialog, it's when open file dialogs trip up. For example, the editor that ships with Processing ( http://processing.org ) is kind of messed up. The default folder it presents when you go to open a file is the directory the editor was launched from. I think that's a Java thing though. Just kind of bothersome when the folder that the editor is in is nowhere near my home folder!

Sean Hagen on November 23, 2008 1:10 AM

0.
Something similar on brilliant article by Joel Spolsky : http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html .
1.
Hello application x crashes? What am I supposed to do?
Tech tech tech tech tech tech tech tech tech tech tech tech and tech tech tech tech tech.
What is tech
Tech, its tech tech tech tech tech
This software is pieces of ... Software X is rules.
I like people like you, have you considered tech tech tech? Tech is always better than tech tech tech, tech tech
...
For stability's sake user just wants application whose source code does *not* include somethig like:

LPSTRZ lpstrzFoo(int x) {
char *cbzBar = malloc(x * x);
cbzBar[2] = gets();
if (!strstr(cbzBar, baz))
return 0x12345;
}
Programmers should reflect upon wiki wiki web http://c2.com/cgi/wiki?WikiWikiWeb .
2.
There is also necessary complexity. And sometimes you need expert to work with it. But in casual application its a bad thing.
Also reminds me of mine english teacher who said.

You don't understand it until you make your grandma uderstand it.

I apologize for my poor english. It's not fault of this teacher ;)

hribek on November 27, 2008 2:38 AM

I'd rather have this behavior than to pollute the registry with more meaningless control storage like the AutoComplete stuff. You do realize you would have to store some value for EVERY CONTROL that uses this, not just some master file save dialog default. Your app would compete with any other app on the system which doesn't sound too fun to me.
http://viewstroy.ru/

Oskar on February 7, 2009 1:55 AM

I just discovered your blog via your vb.net user control rewrite of the CAPTCHA code. You, sir, have been bookmarked. You should be on DotNetRocks (internet audio show)! I don't know if they've done a show on human factors.

http://www.franklins.net/dotnetrocks

Burton on February 6, 2010 9:30 PM

stop putting links in the middle of a damn paragraph. makes impossible to finish without getting pissed off at things that have nothing to do with each other.

anon on February 6, 2010 9:30 PM

The comments to this entry are closed.