*
programming and human factors
by Jeff Atwood
*
I'm currently re-reading About Face 2.0. I hadn't revisited this book since I bought the original version way back in 1995. The update, which was published in 2003, is a significant overhaul -- and frankly much better than the original. Adding the second author, Robert Reimann, was a smart move. Alan Cooper is a usability legend, but he can be bombastic and overbearing at times. Having another viewpoint in the book helps moderate and refine the message.
One part of About Face that I found particularly compelling was the section on considerate software:
To the programmer writing the program, it's a just-in-time information world, so when the program needs some tidbit of information, it demands that the user provide it. The program then discards that tidbit, assuming it can merely ask for it again if necessary. Not only is the program better suited to remembering than the human, the program is also inconsiderate when, acting as a supposedly helpful tool, it forgets.
Inconsiderate software supervises and passes judgment on human actions. Software is within its rights to express its opinion that we are making a mistake, but it is being presumptuous when it judges our actions. Software can suggest that we not not Submit our entry until we've typed in our telephone number. It should also explain the consequences, but if we wish to Submit without the number, we expect the software to do as it is told.
Most software doesn't attempt to provide related information. Instead, it narrowly answers the precise question we ask it, and it is not forthcoming about other information even if it is clearly related to our goals. When we tell our word processor to print a document, it doesn't tell us when the paper is low, or when forty other documents are queued up in front of us, or when another nearby printer is free. A helpful human would.
You can easily find menus offering simple, harmless functions adjacent to irreversible ejector-seat-lever expert functions. It's like seating you at a dining table right next to an open grill. Horror stories abound of customers offended by computer systems that repeatedly sent them checks for $0.00 or bills for $957,142,039.58. One would think that the system might alert a human in the accounts receivable or payable departments when an event like this happens.
A web browser spends most of its time idling while we peruse web pages. It could easily anticipate needs and prepare for them while we are reading. It could use that idle time to preload all the visible links. Chances are good that we will soon ask the browser to examine one or more of those links. It is easy to abort an unwanted request, but it is always time-consuming to wait for a request to be filled.
If we rely on a word processor to draft a new MicroBlitz Contract and then try to [save it in the same folder as an existing, but older, MicroBlitz Contract], the program offers the choice of either overwriting and destroying the old contract or not saving it at all. The program not only isn't as capable as [a human assistant who saw the name conflict and appropriately renamed the contracts], it isn't even as capable as [a human assistant who put the two contracts in the same folder]. It is stupider than a complete idiot. The software is dumb enough to make an assumption that because they have the same name, I meant to throw the old one away.
Software whines at us with error messages, interrupts us with confirmation dialog boxes, and brags to us with unnecessary notifications. We aren't interested in the program's crisis of confidence about whether or not to purge its recycle bin. We don't want to hear its whining about not being sure where to put a file on disk. We don't need to see information about the computer's data transfer rates and its loading sequence, any more than we need information about the customer service agent's unhappy love affair.
We don't want our local bartender to grouse about his recent divorce, but we appreciate it when he posts his prices in plain sight and when he writes what time the pregame party begins on his chalkboard, along with who's playing and the current Vegas spread. Nobody is interrupting us to tell us this information: it's there in plain sight whenever we need it.
Software should watch our preferences and remember them without being explicitly asked to do so. If we always maximize an application to use the entire screen, the application should get the idea after a few sessions and always launch in that configuration. The same goes for placement of palettes, default tools, frequently used templates, and other useful settings.
Are you sure? Are you really sure? Are you really, really sure?
Choices can be offered in different ways. They can be offered in the way that we window shop. We peer in the window at our leisure, considering, choosing, or ignoring the goods offered to us -- no questions asked. Alternatively, questions can be forced on us like an interrogation by a customs official at a border crossing: "Do you have anything to declare?" Software should never put users through this kind of intimidation.
Most programs are filled with data and settings. When they crash, that information is normally discarded; the user is left holding the bag. Let's say you are downloading your email from a server, when your email program runs out of memory at some procedure buried deep in the internals of the program. The program, like most desktop software, issues a message that says, in effect, "You are completely hosed," and terminates immediately after you click OK. You restart the program, or sometimes the whole computer, only to find that the program lost your email and, when you interrogate the server, you find that it has also erased your mail because the mail was already handed over to your program. This is not what we should expect of good software.
In most computerized systems, there are only two states: non-existence or full-compliance. No intermediate states are recognized or accepted. In any manual system, there is an important but paradoxical state -- unspoken, undocumented, but widely relied upon -- of suspense, wherein a transaction can be accepted although still not fully processed. The human operator creates that state in his head or on his desk or in his back pocket. For example, a digital system needs both customer and order information before it can post an invoice. Whereas the human clerk can go ahead and post an order in advance of detailed customer information, the computerized system will reject the transaction, unwilling to allow the invoice to be entered without it.
The characteristic of manual systems that let humans perform actions out of sequence or before prerequisites are satisfied is called fudgeability. It is one of the first casualties when systems are computerized, and its absence is a key contributor to the inhumanity of digital systems. It is a natural result of the implementation model. The programmers don't see any reason to create intermediate states because the computer has no need for them. Yet there are strong human needs to be able to bend the system slightly.
Lots of food for thought there. So many applications I use fail even the most basic criteria on this list.
Posted by Jeff Atwood View blog reactions
« The Value of Repetition.. Again The Ideal Computer Desk »
Those are very good, but keep in mind that even though automated systems have downfalls, there are reasons to have them over manual systems. Number 13, bending rules, is a big reason for automated systems. What happens when the invoice information is populated, but the customer information is never filled in because the clerk forgot?
We have two sides to a bunch of those items listed. Taking those points to heart when designing systems will ultimately help out though. Where you can help the user, do it.
Brian Russell on March 27, 2006 03:51 PMThat's true, but most software doesn't even *try* to do this stuff.
Jeff Atwood on March 27, 2006 04:31 PMIt says: "We don't need to see information about the computer's data transfer rates..."
That has actually helped me numerous times. For example just this weekend I was downloading something and the data rate was quite a bit lower than normal. Had I not seen the data rate, I wouldn't have noticed (it was a big file that was going to take a while regardless of data rate). But seeing it, I immediately stopped the download, figured out that by moving the computer earlier that day it was now at the edge of the wireless network's range, and I was able to fix the problem immediately. Had it not shown me the data rate, it probably would have lead to other network failures that I would have thought were for some other reason, and would have wasted a lot of time trying to fix.
And not to pick nits, but when I try to enter comments from within my news reader, neither "Yes" nor "No" is selected for "Remember personal info?" Shouldn't considerate software select "No" by default (which seems to be the case if you don't select either of them anyway)?
Darrin on March 27, 2006 04:37 PMI remember when the original version of this list appeared years ago in an late-1990's issue of Visual Basic Programmer's Journal. I think it was called "Polite Software." I remember two things from that time:
First, I remember that this polite software idea really resonated with me, and changed the way I designed user interfaces, error messages, etc. from that day forward.
The second thing I remember is in the following month's issue of the magazine a letter writer had written in a scathing letter stating that he thought that polite software was the dumbest idea anyone had ever come up with. I remember being stunned by this reaction.
Dan
> Had I not seen the data rate, I wouldn't have noticed
You don't want to see the data rate-- you want to see how long it will take the transfer to complete.
Eg, "3 hours remaining" is more informative to the user than "transfer rate is currently 3.21 bytes per second, 232,111 of 45,782,100 bytes transferred".
Jeff Atwood on March 27, 2006 05:06 PMThe problem with that is that you often can't trust the software, I can usually make better predictions about completion time than the software can.
deadscott on March 27, 2006 05:27 PMBrian in #1 said it perfectly.
I would like to add, as a Programmer, none of these points really phased me. I usually use software which has such shortcomings and it hardly bothers me.
However, I can see the need for them in a 'normal' user scenario.
It's almost like we need two sides to a program to satisfy both parties. A rigid, almost zombie-like side to satisfy the logic that Programmers see, and a flexible, adaptive side to satisfy the natural behavior of a real user.
genghis on March 27, 2006 05:33 PM> I can usually make better predictions about completion time than the software can
So you're a better computer than.. the computer? What's the square root of 1744, then? ;)
Jeff Atwood on March 27, 2006 08:26 PMhttp://www.google.com/search?q=square+root+of+1744
Jeff Atwood on March 27, 2006 08:27 PMI worry that some of these result in horrid software to use - the "Considerate software anticipates needs" resulted in bandwidth hogging and other problems when Firefox impleplented link prefetching as suggested here.
You have a contradiction in the examples for conscientious and doesn't burden. Software shouldn't just silently overwrite, but it shouldn't ask either. So you prefer the "make up a filename and put the file somewhere the user will never find it" approach? Or perhaps "put the new name and location in the status bar for a few seconds" to fulfil "keeps you informed"?
I dunno, I most of those I see as "useful to think about" rather than "guidelines" or "rules". perhaps I've suffered too much at the hands of software that was written as suggested here.
Moz on March 27, 2006 09:50 PMAnd can you please fix the stupid "you must enter text with an @ and a . in the email address field" thing? Either demand registration or drop the extra typing.
Moz on March 27, 2006 09:52 PM>So you're a better computer than.. the computer?
Well maybe not :) but I'm sure we've all seen progress bars that guess "9 hours" when you know it's only going to take twenty minutes
deadscott on March 27, 2006 11:40 PM"You have a contradiction in the examples for conscientious and doesn't burden. Software shouldn't just silently overwrite, but it shouldn't ask either. So you prefer the "make up a filename and put the file somewhere the user will never find it" approach? Or perhaps "put the new name and location in the status bar for a few seconds" to fulfil "keeps you informed"?"
I prefer the "no files" approach. Just information that I can search the content for. It's possible, it's just alot of work. But it's not far off.
[ICR] on March 28, 2006 02:47 AMI remember reading this once upon a time, glad you posted it for a much-needed reminder.
Personally I've shortened those ideas into my one rule of usability: Design it for my mother. My mother calls me with dread and a "I feel stupid" tone to her voice whenever her computer is upset about something. She is not stupid but a lot of applications make her feel that way when they give her a cryptic or worthless message and then make her decide something.
Like this one, "Application svchost.dll is trying to access the internet, allow it?" Great, just how is my mom supposed to know that she can go ahead and allow that? Where even is the link to the information so she can make an informed decision?
I know there are a few times I've been on the edge of letting a weak error message slide but then I think of mom and I make that extra effort because if my mom can't make sense of it no way a manager can :)
Shawn Oster on March 28, 2006 02:48 AM>>but I'm sure we've all seen progress bars that guess "9 hours" when you know it's only going to take twenty minutes
My guess is most of that comes from lazy programmers. Instead of calculating the remaining time based on the actual transfer, they use a base value. And if your network/transfer rates are different, the estimated time is wrong.
Eric D. Burdo on March 28, 2006 07:58 AMAbout saving, how about a dialog box allowing entry of a filename if a file with the same name already exists?
H on March 28, 2006 10:10 AMFilesystems Aren't a Feature:
http://www.codinghorror.com/blog/archives/000461.html
"This discussion is not theoretical: on the SwyftWare and Canon Cat products, the elimination of file names, directories, and the various mechanisms usually provided for manipulating them proved one of their most successful features."
Jeff Atwood on March 28, 2006 12:15 PMBrian (#1) wrote: "What happens when the invoice information is populated, but the customer information is never filled in because the clerk forgot?"
That was addressed in point #2: "Considerate software is deferential."
I think that's the most important point in the book. It's /my/ job and I know what I'm doing. The computer may make me more aware of what I'm doing, but it shouldn't tell me what to do.
I'm a Jedi Master. My software is R2D2.
Patrick
But R2D2 can't even talk 'Basic' (English for you non star wars types), so where is the consideration there? I understand that people are smarter than computers. I support the fact that users need to do things that were not originally thought of when the software was developed. What I don't support is the notion that our software has to work like paper. Paper has the ultimate flexibility, and with that, comes the most opportunity for errors.
Brian on March 29, 2006 01:08 AMComputers can come pretty close to ultimate flexibility. With the added bonus that they can also guide and hint. Done something wrong? Tell the user, but don't force them. Unless it is critical I suppose, but alot of the time things that are forced aren't even necessarily critical.
I had a large discussion with my friend when I was redesigning the UI for a booking system as to whether it should allow incomplete bookings, but just flag them up so you know that they are incomplete, and not include them in any calculations. His very good point was that if you leave a booking, come back to it, the customer is no longer there to give you the rest of the details. My point was that the user should be able to multitask slightly, correct details etc. in other places and come back, instead of being forced into completing the form.
I ended up with forcing a complete booking, as it would require slightly less training. The latter only circumnavigated a very small problem whilst creating larger ones.
Well another reason download estimates are bad is that most download managers ignore guidelines #1 and #4.
If the computer remembered previous downloads, it could frame the current download against historical data. Then it can use common sense to let you know that downloading a 10MB file over a broadband connection will not take 23 days.
Haacked on March 30, 2006 12:53 PM<treknerd>
Re "Considerate software is forthcoming", they haven't even solved this in the 24th century
[TNG episode where Geordi is talking to his former love interest]
Leah: "The computer never told you that I was married..."
Geordi: "I never asked... and the computer is notorious for not volunteering information..."
</treknerd>
Ricky Dhatt on March 30, 2006 08:41 PM> The second thing I remember is in the following
> month's issue of the magazine a letter writer had
> written in a scathing letter stating that he
> thought that polite software was the dumbest idea
> anyone had ever come up with. I remember being
> stunned by this reaction.
Hard to say. On problem is that he may not have read and understood the article. If so, he may have been reacting to his experiences with "polite" software. I've had some bad ones myself; polite doesn't necessarily mean effective.
Jeff Atwood Wrote:
> You don't want to see the data rate-- you want to see how long it will take the transfer to complete.
> Eg, "3 hours remaining" is more informative to the user than "transfer rate is currently 3.21 bytes per second, 232,111 of 45,782,100 bytes transferred".
No, I want both. I can't estimate in my head how long a file is going to take, but I do know about how fast my connection goes. In many cases I have options of download sources (game demos, linux ISOs, ...) and if I see that the rate is much below what I know my connection will do, I'll try a different source.
wget does it quite nicely, for example, with a visual progress bar, a numeric "transferred so far" readout, a current speed indicator, and a time remaining estimate.
me22 on February 8, 2007 07:48 AM| Content (c) 2008 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved. |
Subscribe in a reader
Subscribe via email