Tantek elik recently wrote a great entry on cognitive load in user interface, comparing instant messaging and email:
I find myself constantly oscillating between teaching good UI practices to programmers and just focusing on getting experts for the job. For someone who is reasonably intelligent and has a great deal of experience using software (that would pretty much cover all programmers), is designing a truly effective UI simply a matter of stopping and putting in the time and effort to think about it, or is it really a skill beyond most purely technical types?
When I first began writing web interfaces for databases, I used a simple redirect to send the user back to a page that I dictated after the form’s action page had worked its magic. After growing headaches accompanying growing applications, I switched to using window.open links that brought the forms up in their own window, so that the form could be submitted and the action page could then close the window and plop the user right back where he/she was before filling out the form and even reload that page if need be. Then I found AJAX, sweet, sweet AJAX, and all of my interface woes have ended.
@ Rex :
Most programmers feel like everyone around knows at least enough to use a computer while most users don’t. A “don’t make me think” way of programming isn’t and will never be easy to put in place.
You got to sit down and prepare in advance how you application is going to be used by your future users.
There is another side to cognitive friction (beside the number of steps/choices involved) that I’m aware of:
It has to do with how closely the tasks the user is required to perform correspond to the human brain’s expectations.
I wrote a piece a while ago on the superb example Apple’s iPhone sets for mobile phone makers in this regard: http://www.alhome.net/index.php/two-words-for-apple-thank-you/. Say I want to zoom in a picture, well I’d simple stretch it with my fingers. I think this is the most natural way you can go about achieving this task!
I am going through this very same problem at work right now. We have a page where customers can signup to receive a monthly safety tip newsletter. The Business Area wants to make it as simple as possible to signup (understandable) and Security wants us to send an “opt-in” email to the customer for verification before signing the customer up (understandable). Neither side wants to back-down because they both think they are right and here I am, the programmer, stuck in the middle. They are both right, but where do you draw the line between best practices and best usability?
Mike-- look at Truemors.
Sometimes you have to add friction to reduce the way anonymity can devalue a website.
Heh. Reminds me of something…
See, i wanted to listen to “Grey Street” by Dave Matthews Band. In order to do this, i would need to:
In the end, this sounded like just entirely too much work, so i just turned on the radio, and spent the rest of the time thinking, not for the first time, how nice it’d be to have a proper command line on the taskbar…
…Now, if only i wasn’t so disgustingly lazy…
At the same time in the comparison between email and IM, look at the difference in what it takes to add a user to the list. IM applications are not something I have used frequently in about 5 years, but in most cases it took jumping through a couple of seemingly unnecessary hoops, where email applications just tend to add users to the list (sometimes even when you don’t want them to).
I think the primary problem with email interfaces is that the simplest email applications have been around for a very long time and no one’s thought to change much about the interface (except perhaps making a BCC harder to accomplish, because few people use it often enough to keep it in that line of fields).
Another issue is that users typically start their email either to read their messages or to write a message, and most developers have trouble finding a way to make users happy regardless of why they opened the application. It would probably make sense to give users a method for opening their email application in a compose mode that for just those situations in which they want to send an email (for instance, bringing the application up in the background with the Compose/New Message dialogue in the foreground as if they had gone through the steps of opening the application and hitting the New Message button).
IM applications have the annoying habit of defaulting to interrupting whatever you’re doing by popping up a message whenever someone feels like sending you one, unless you trudge through some configuration dialogues to figure out how to suppress the interference.
Developers tend to see user interfaces as a series of required and optional inputs and outputs, and users often see only their own irritants when evaluating applications. If 90% of your users don’t use 90% of your functionality, you still have to figure out how much of the 10% that 90% uses overlaps.
Here’s a good site on interface design and one about Human Cognitive Abilities from Berkeley:
http://www.usernomics.com/user-interface-design.html
http://www2.sims.berkeley.edu/academics/courses/is213/s99/Lectures/Lecture8/sld001.htm
Simplified design has always been a good practice. Basically, the more your application can do in one key or button press the better. Of course there are always limitations to this whole thing based on requirements for data collection, et.al.
As far as email goes, I’m kinda partial to Thunderbird. Its recipient boxes are quite intuitive in that you don’t have to type, just click and drag and click again. For more recipients, move down one box and repeat. However, this requires entries in your address book. That too is rather nice in that Thunderbird will automagically add any newly typed address. Then, it’s subject (if desired) and body combined with send. Granted, it’s not perfect, but it’s leaning in the right direction.
What is truly needed to really bring this all to a simple interface design is Matrix-like connections. Then we are all networked and we don’t need to use these software interfaces. Or, the Star Trek: Next Generation computer. (“Computer.” “Yes, captain?” “Send my mother an email.”)
There is the “new” technique of user acceptance. That’s where you dummy up an interface and populate dummy data then give it to a set of users to see how they like it. Then, with ears open and mouth shut, you listen to them and take copious amounts of notes. Then go back to your computer and try again. Once you have another “prototype” you start back at giving it to the set of users then repeat until the users say, “I like it!”
This all depends on what the other departments (security, business, etc.) all say. But however it’s presented, user acceptance should always include interface design. It’s the user that’s going to be using the application more than the developer probably will and that’s the person who should drive your interface design, the user.
All the design courses/classes/seminars/websites in the world don’t mean a thing unless the user, the one using the application, feels comfortable and possibly (hopefully) productive. Just like using a graphics program for graphics design, good UI design doesn’t come easy, it takes practice.
I’d love to be able to have my email subject show up as the first x number of characters of the email body for people already in my address book. That would save one step.
If you skip a subject line on an email to me, it will almost guarantee a do-not-pass-go trip into the circular file. And more than 80% of the emails I send are replies to a previous email, building the dreaded reply-stack that is the best thing since continuous compilation for us highly multitasked people. With a reply the steps divolve to:
The value of email is it’s permanance, and the value in IM is it’s immediacy. If I have a right-now-quick-question then IM is usually a good way to get what I want. But if I think that I will need that info next week (or later) then it better be in an email or it will get lost forever. I just found an email in my files from 2002 (using the awesum X1 desktop search) that gave me the registration code for a required utility that is no longer supported. Back in the day I would have thought that I only needed that one time, but my email archives saved the day 5 years later.
But, I will agree with the reduction in distinct actions to accomplish a task. To paraphrase: Make it as simple as needed, but not any simpler. I use client side scripting to add logic to most of my apps to smooth the interface, especially as the user fills in data. Default (but allow changes) is the best way to speed the user to the final click, but still allow power users to change things. The best example would be a cart checkout that remembers your name, address and payment info, but lets you change any part of it.
Regarding IM, an important second step is missing: searching for your friend in the list. This would be either scrolling list up and down or typing several first characters of their name. Double-click can be used only if your contact list has about 7 persons, so you can immediately see contact you need. Sometimes searching can be hard because some user changed his nickname or you just forgot it.
On the other hand, replying to IM is even simpler - just type and press Return.
About sending Emails: If you are using Outlook Express, you have an area with your Adressbook. The process would be:
If you don’t want a subject you can spare 2 steps. The comparison is IM 4 steps, Email 5 steps.
Rex wrote:
“is designing a truly effective UI simply a matter of stopping and
putting in the time and effort to think about it, or is it really a
skill beyond most purely technical types?”
How about the purely artsy types write the programs, then.
I’m sure those will be much more useable.
Hey Jeff, Great Article.
Just letting you know you mispelled ‘tumblr’ as ‘tumbr’ at the end of the article. I love the service and want it to get the maximum attention possible. Feel free to delete this comment.
I started using Quicksilver in place of the finder in OSX for exactly this reason - I want my interface to present me options that most frequently correspond to my actual work process. With QS, it becomes trivial to locate data from one source (address book), insert it into an application (email client), fill in data from another source (URL from the current web browser) and execute an action. It’s down to about 6 keystrokes
JEFF CAN YOU MAKE AN ARTICLE ABOUT HOW PEOPLE SHOULD REDIRECT AFTER A POST ON THE WEB?
It’s so annoying these days to see “Should you repost form data that expired from the cache” messages. Do non-programmer types understand them? And the implications? People can resubmit orders, and so forth. A really badly designed site could charge them twice.
Instead, the simple solution is redirecting after any kind of POST. That way if you refresh, everything is cool. Also on a related note, if you set session variables (e.g. indicating that you’re logged in) and you go back, the pages should redisplay since the session has changed. So for example, you’re not logged in, then you log in and you go back. You shouldn’t be logged out as a result. You should instead see a page as you would have seen it if you had been logged in the first time.
Just a thought/request 
Greg
Personally, I have no problem opening a terminal and running /var/qmail/bin/qmail-inject to send an email. The fact that its all keyboard based and is conceptually straightforward makes it just as smooth as the shorter examples mentioned above.
“works good on smaller not-for-profit web sites, but on a lot of the stuff I work with, the more data we can gather from a user, the more money that user is worth to us.”
Nuts to that. We hear that from our clients, but it’s not true. All you wind up doing is annoying some users off and getting a lot of bad data from the users who do sign up. Better to get them to sign up in a simple way and then give them a reason to send you info about them.