August 30, 2005
In this 1996 Alertbox, Jakob Nielsen champions writing for the web in an inverted pyramid style:
Journalists have long adhered to the inverse approach: start the article by telling the reader the conclusion ("After long debate, the Assembly voted to increase state taxes by 10 percent"), follow by the most important supporting information, and end by giving the background. This style is known as the inverted pyramid for the simple reason that it turns the traditional pyramid style around. Inverted-pyramid writing is useful for newspapers because readers can stop at any time and will still get the most important parts of the article.
On the Web, the inverted pyramid becomes even more important since we know from several user studies that users don't scroll, so they will very frequently be left to read only the top part of an article. Very interested readers will scroll, and these few motivated souls will reach the foundation of the pyramid and get the full story in all its gory detail.
For some reason, the idea that "content should never appear below the fold because users don't scroll" was a very widely held belief well into the millennium. I don't know what user studies Mr. Neilsen is referring to; even the ancient 1998 reference Web Site Usability: A Designer's Guide found no evidence to support this claim:
The Fidelity site, more than any other site we tested, went to great lengths to have many of its pages completely above the fold. The result is lots of pages, each with small amounts of content. There was no evidence to suggest that this strategy helped or hurt.
In fact, we never saw any user frustration with scrolling. For instance, when we counted "first clicks" -- the first place people clicked when they came to a new site -- clicks were just as likely to be above the fold as they were to be below it. If scrolling below the fold was a source of frustration, we would have expected to see some sort of negative correlation between first clicks below the fold and success, but we didn't.
In 2003, Jakob added an addendum to his Alertbox, which reads:
In 1996, I said that "users don't scroll." This was true at the time: many, if not most, users only looked at the visible part of the page and rarely scrolled below the fold. The evolution of the Web has changed this conclusion. As users got more experience with scrolling pages, many of them started scrolling.
You should certainly try to put the most important information at the top of whatever it is you're writing, be it a website, a program, an email, a resume, etc. Believe me, I've learned this the hard way; you're lucky if they read anything, much less the first paragraph.
But to claim that users don't scroll is downright ridiculous, even for 1996. Let's say you had a user who didn't know how to scroll a web page. How long would it take this user, however timid they may be, to learn that they needed to scroll when browsing the web? A user who can't learn to scroll within a few hours certainly won't be using the internet for very long.
In Joel Spolsky's excellent User Interface Design for Programmers, he notes the difference between Usability and Learnability:
It takes several weeks to learn how to drive a car. For the first few hours behind the wheel, the average teenager will swerve around like crazy. They will pitch, weave, lurch, and sway. If the car has a stick shift they will stall the engine in the middle of busy intersections in a truly terrifying fashion.
If you did a usability test of cars, you would be forced to conclude that they are simply unusable.
This is a crucial distinction. When you sit somebody down in a typical usability test, you're really testing how learnable your interface is, not how usable it is. Learnability is important, but it's not everything. Learnable user interfaces may be extremely cumbersome to experienced users. If you make people walk through a fifteen-step wizard to print, people will be pleased the first time, less pleased the second time, and downright ornery by the fifth time they go through your rigamarole.
Sometimes all you care about is learnability: for example, if you expect to have only occasional users. An information kiosk at a tourist attraction is a good example; almost everybody who uses your interface will use it exactly once, so learnability is much more important than usability. But if you're creating a word processor for professional writers, well, now usability is more important.
And that's why, when you press the brakes on your car, you don't get a little dialog popping up that says "Stop now? (yes/no)."
I was greatly impressed with the expanded book version of Joel's User Interface Design for Programmers page. I sort of assumed that the book was a mildly enhanced reprint of the HTML, but 7 of the 18 chapters are completely new material. Based on a few quick Google searches, they really are new. And the full color printing is fantastic!
I've read a bunch of UI books, and Joel's is easily in my top three. I'll definitely be adding it to my recommended developer reading list.
Posted by Jeff Atwood
There is another implicit point in that story. Who the user is matters quite a bit. When you concentrate on satisfying a very specific type of user, the critera for 'good' design changes.
Alan Cooper's book a href="http://www.amazon.com/exec/obidos/tg/detail/-/0672326140/qid=1125509030/sr=8-1/ref=pd_bbs_1/104-0483242-8996705?v=glances=booksn=507846"http://www.amazon.com/exec/obidos/tg/detail/-/0672326140/qid=1125509030/sr=8-1/ref=pd_bbs_1/104-0483242-8996705?v=glances=booksn=507846/a
has a great forumulation of this (Personas). It's worth a read if you can get past the preachy tone. It contains a reasonable argument that concentrating on a specific type of user provides a better result for all potential users.
what are the other two books in top three list?
For UI, definitely
1. Don't Make Me Think (Krug)
2. About Face 2.0 (Cooper)
3. UI Design for Programmers (Spolsky)
It's all on the recommended reading page, in order of preference (eg best at top)
Here's a list of the 8 new chapters in the "User Interface Design for Programmers" book:
It's hard to tell because the HTML page..
.. has them listed in a different order and sometimes with different "chapter" names, but I cross-checked and I believe this is correct:
Chapter 5: Broken Metaphors
Chapter 7: Putting the User in Charge
Chapter 13: Those Pesky Usability Tests
Chapter 14: Relativity: Understanding UI Time Warps
Chapter 15: "But.. How Do It Know?"
Chapter 16: Tricks of the Trade
Chapter 17: Designing for the Web
Chapter 18: Programming for Humans
Thank you very much for the info. I agree about the other two (still waiting for the preordered second edition of "Don't make me think").
Joel's book goes to the amazon's basket too :)
Guys, guys, guys.. before listing these books, check to see if I already have it listed on my recommended developer reading list! It's linked A) from the post B) from these comments C) on the blog homepage.
I'm just sayin'!
When reading a lot of sites, particularly 'magazine' type sites, the thing I look for is the "Print view" or similar link. This should really be called the "Hide the crap and put all the text on one scrollable page" link. Or perhaps the "Reading layout" link?
BTW, have you ever had the fun job of trying to persuade a bunch of science types to abandon the "detective story" style of writing/presenting, and move to the inverted pyramid. Aaarrrhhhhhh!
Hmmmm, this isn't thought through too much.
The car example is bad because we all know when self-driving cars come along they will be a massive improvement in terms of usability. The problem is that the current car is bound by technical limitations - it is not because the car manufacturers cannot be bothered to invest in a better interface. Software interfaces however do not have those limitations so lazy programmers use cars as an excuse! Apples and Oranges.
A good user interface will be able to accomodate, even adapt, to both types of users mentioned here (beginner and advanced). To say it has to be one way or the other is the classic mistake.
Take amazon.com. My mother can use it easily to buy books. I can query its database via its Web API and have it automatically place items in the basket. It goes as "deep" as the individual user needs, without sacrificing the beginner. The interface should grow *with you*. You should not have to grow with the interface.
Can't wait for self surfing browser.
I'd argue, that people who would use self-driving cars are already using public transport ;)
Jeff, what are the other two books in top three list?
Well, it's not that I'm losing revenue.. I'm just mildly offended that people would think I had never heard of "The Design of Everyday Things", or "The Inmates are Running the Asylum"-- both classics!
I too am a bit puzzled by the car example - was I atypical? I already knew how to drive from an early age because I had watched my parents do it everyday for as long as I can remember. It was just a matter of getting the feel for the controls, rather than the know-how.
On the subject of web pages, I never heard the one about 'users never scroll' but there was another one that I was told which I think is still relevant - it is harder to keep track of where you are on a screen, so pages need to be shorter. That is, it is tiring and difficult to read large amounts of fine text on a screen. Making it larger does not help, as there is a size where 'word-recognition' no longer 'works'. Of course, some websites make it even worse by insisting on black pages with white or yellow text, etc.
"Can't wait for self surfing browser."
They already have that for porn sites, don't they? (;-P) (malware)
I have to agree with you Jeff, Spolskys book is very good. What I liked most about it was how easy to read it is.
No elaborate case studies, just short and sweet
arguments with the occasional jokes here and there.
It's by far one of the funniest and most lighthearted books I've read on a computer science subject so far.
I think the problem with the "users don't scroll" dictum is that it confuses something mechanical (scrolling) with the more fundamental issue that users want to do the least amount of work requires to achieve their goals. The point is not how many clicks it requires (cf the example of someone's mom on Amazon, excellent point) but on how much work it is to get the task done vis-a-vis how motivated the user is. This is a huge factor in documentation, where many, many users go immediately to the code example, never mind the long blather preceding it. The code example can be at the bottom; people will find it (especially if it's called out in some fashion). As for different kinds of users, another good point, it's that people are different kinds of users under different circumstances. If I want the syntax of a method, I'm a show-me-now user; if I'm looking at a page on the basics of crypto, say, I will keep reading, top to bottom, as long as the information continues to be useful and comprehensible to me.
I'll ask again: am I the only one who thinks that Nielsen's has the world's ugliest Web site? :-)
many, many users go immediately to the code example, never mind the long blather preceding it
Well, that's exactly what I do. I may go back to the surrounding text if the code sample behaves strangely or isn't illuminating enough.
How about a documentation style that is almost exclusively code samples? That'd be kinda cool, definitely an interesting experiment.
D'oh, I'm sorry. I forget that you probably get click-throughs from amazon on your recommended reading list. I knew "...Everyday Things" was on your list, but I was just putting my vote in for it. Feel free to kill my comment(or change it to your click-thru URL), I definitely don't want to take away from any small amount of revenue you are getting from it.