CARVIEW |
October 25, 2004
Teaching Users to Read
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:
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?
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.
https://www.franklins.net/dotnetrocks
Burton on October 26, 2004 03:43 AMThe 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 08:59 AMBurton, 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 11:17 AMPartly 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
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 03:09 PMThinking 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...
;)
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 08:49 PMWell 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 08:28 PMstop 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 January 14, 2008 07:13 PMwow i love the blog most deff adding to my favorite list thanks for the comic strip laught.
john wolfe on January 24, 2008 09:01 PMyou need to put some stories that you can read on there xxx
rosiebeth on February 6, 2008 12:25 PMOMG
OMG on May 19, 2008 01:56 PMthis 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 02:43 PMI add this very late comment only to mention that the abovementioned Alan Cooper story is now available on Google Books, here:
https://books.google.com/books?id=04cFCVXC_AUC&pg=PA11&lpg=PA11&dq=%22alan+cooper%22+%22my+documents%22&source=bl&ots=jfvgY5n3kP&sig=MFhjq6Op9DZZFeSRuNDKmJhy07I&hl=en&sa=X&oi=book_result&resnum=1&ct=result
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 ( https://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 01:10 AM0.
Something similar on brilliant article by Joel Spolsky : https://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 https://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 ;)
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.
https://viewstroy.ru/
Content (c) 2009 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved. |