This morning I published an article on my lessons learned from 7 years of experimenting with usability testing. It is called "10 Lessons Learned from Usability Testing". Creative, huh? The post is on the Canoo blog instead of here... most modern web browsers will show you the article if you click the link above. I say most because I can't trust IE 6 to do anything right.
We all want our interfaces to be intuitive, don't we? Sounds good to me. I know I've used this word in the past when passing judgment on a user interface: "I'm confused by the interface... it's just not intuitive."
To intuitively understand something means it is understood without prior exposure to the subject, without requiring a learning process, and without using rational thought. Running away from a bear in the woods: intuition, fight or flight. Drinking water from a lake: not intuition, prior experience with lakes teaches you to expect water. Shaking a coconut, realizing there is milk inside, smashing it and drinking it: not intuition, you inferred liquid from rationally thinking about the sound it made. Operating any user interface that requires a keyboard or mouse: not intuitive by any stretch of the definition. Somewhere, someone taught you how these things worked. So sorry, your cool new interface that passed usability testing with flying colors is not intuitive.
Your user interface might be familiar, and this is good because it reduces the learning curve of users who have already been trained in something similar.
Or your user interface might be easily habituated, and this is good because repeated use will increase the user's productivity and operation time.
But ease of use and speed of learning are certainly not the same thing as intuitiveness. As Jef Raskin points out in "The Humane Interface", "The mouse is very easy to learn... [It's] fast and easy, but it is neither intuitive or natural. No artifact is."
What you can do is make an interface self-teaching, meaning the user can always find proper explanations and instructions when they are needed.
So from here on, I pledge to stop saying "intuitive" when it comes to interfaces. Instead I'll stick with "familiar", "self-teaching", and "easily habituated".
AND WHILE WE'RE ON THE TOPIC... I often hear people say their co-workers are idiots. The word idiot traditionally, specifically describes people with an IQ of 0-25. It is one step below imbecile (26-50), and two below moron (51-70). Here is a handy table for comparison:
| Term | IQ Range |
| Moron | 51-70 |
| Imbecile | 26-50 |
| Idiot | 0-25 |
I like a good UI as much as the next guy, but its not a layer I naturally strive to spend time on. I like simple, functional interfaces that work; if you want something with rounded corners and slick animations I might not be your man. But there was something that caught my eye about the paper Rethinking the Progress Bar, and it turned out to be some pretty interesting research.
We strive, as developers, to produce accurate and linear progress bars, and are constantly annoyed by inconsistencies and hiccups in that little blue meter. But since humans don't perceive time in a linear or consistent fashion, perhaps there is a way to hack a progress bar so that it appears faster to the human observer without actually being any faster. Turns out there is and it has to do with two phenomena called peak effect and end effect.
Peak effect means humans judge time based on peaks, or extremes, in the passage of time. Progress bars that pause seem to take longer to complete. End effect means humans judge time based on their most recent observations. Progress bars that slow down near the end seem to take longer. Naturally, a progress bar that speeds up near the end and never pauses will appear faster than a linear progress bar, despite the fact that both it and a linear progress bar might take the same time to complete.
The research was pretty cool and involved 8 different algorithms to drive a progress bar. They found the fastest appearing bar was a rapidly, but smoothly, accelerating one, starting slow and gradually ending quickly. Specifically, the function was called Fast Power:
f(x) = (x+(1-x)/2)8
So now we should all hack our progress bar class to do this, right? Well, maybe not. The researchers conclude that stable, linear progress bars aren't good candidates for 'optimizing'. I'm not sure why, and I'm tempted to go ahead and do it. There are also other alternatives to hacking the progress bar... if you want to avoid stutters in progress (peak effect) you could have the progress bar cache and under-report progress during normal operation, and then replay the progress reserve during pauses. If you want to avoid slowing down the bar near the end (end effect) then you could arrange your processes so that slower, more inconsistent operations are performed at the beginning. This is attractive because humans are more likely to tolerate negative behavior at the beginning of the operation than the end. If a pause occurs, best to get it over with early.
Well I, for one, don't buy any of the 'alternative' garbage. It's time to go subclass JProgressBar and get me some faster applications!
(By the way, the paper is only 4 pages long and contains fancy color graphs. It's an easy read, go check it out!)
