Our book:
Defensive Design for the Web: How To Improve Error Messages, Help, Forms, and Other Crisis Points
Available Now ($16.99)
Most Popular (last 15 days)
Looking for old posts?
37signals Mailing List
37signals Services
Syndicate
This cake is all frosting
19 Apr 2004 by Ryan Singer
Aaron Gustafson works a few miracles in his ALA article, Let Them Eat Cake. He really knows his stuff, and his end-product is impressive and instructive.
But there’s a problem.
Aaron starts with a nod to the latest accessibility/usability hoo-ha and states his intentions for the article:
It is my feeling that, using the DOM, we can improve the usability of a page without restricting its accessibility. Sprinkle in a little CSS and we have the recipe for a wonderful experience all around, regardless of the browser, platform or device being used.
For his example, Aaron starts with a nicely marked-up version of his article text. That’s where the accessibility comes from — good markup. Sounds good so far.
Then Aaron sets a usability goal for the page (to show that accessibility needn’t restrict usability):
The article is divided into sections and, as human psychology demonstrates, information is easier to digest in chunks. One way to make a lengthy article easier to follow is to display the content section by section. This not only aids in digesting the information but reduces scrolling (which appeals to the many who remain convinced that the general population still has no clue how to scroll).
In the end, we have an attractive page that splits the article sections into separate screens (using DOM show/hide) while still keeping the print version as one page. Very cool, I have to admit.
But I’m not so sure this treatment is more usable than the plain markup version. Does a single article really need its own menu bar? Is it easier for people to understand the article in chunks, or does the lack of context make it harder to follow along? Will someone viewing a single chunk expect the whole article to print? What if they hit the print button on each screen and get five copies? These questions may be open for debate, but some of the problems with this design are clear-cut:
- The back button does not work between screens.
- People can’t link to the screens directly or bookmark them (the URL doesn’t change).
- There’s no call to action at the end of each “chunk”. (A ‘Next’ or ‘Continue’ link would give each chunk context, letting people know there’s more around the corner and that the chunks belong to a sequence.)
We’ve all known since the great debates over Flash and frames that breaking the back button and denying deep links are not nice things to do. The print stylesheet is great, the idea is cool, but in the end the technique outshines the content (and isn’t that design for design’s sake?)
Good interfaces set peoples’ expectations. While this page is smartly designed so that five “screen pages” print as one “print page”, the reader probably expects the total opposite. The reader may also expect to be able to bookmark one of the screens with a good code snippet, but will end up bookmarking the introduction.
“Let Them Eat Cake” is a helpful and valuable lesson in clean semantic markup and CSS styling, but it’s not about usability. No matter how far we can stretch our tools, it’s all for nothing if they don’t make things simpler and smarter.
10 comments so far (Post a Comment)
19 Apr 2004 | Andrei Herasimchuk said...
I have used that technique in some projects that I have worked on, but not for the purpose of reading articles.
I used the technique in web applications that operate more like traditional desktop apps do. In places like an executive dashboard, reporting systems to disclose summary and detailed information. In spots where it doesn't feel like reading a simply article.
Used in those spots, the technique is actually quite useful in packing in a lot of information, and allowing frequent users and power users to work the system more elegantly without constantly hitting the refresh or back buttons.
For a system that sees frequent usage on a daily or wekly basis, the technique, when used properly, really can be much more effective than relying on that dead data, page refresh model that is the web browser.
19 Apr 2004 | Trevor said...
I don't think Ryan's point was that the technique itself is always bad, rather that it's not very useful in the context of reading an article online. I actually think 37signals uses the technique on the Basecamp dashboard in the "What's Fresh" section.
20 Apr 2004 | Cade Roux said...
Yup - he forgot one of the main things books have taught us about the reading experience - you can tell the length of the book by it's size and weight.
By re-formatting this into a tabbed web application style content, you don't even realize it's an article or that there is really any meaningful content...
Sure, there's a place for this, but not for articles.
20 Apr 2004 | Colin Ramsay said...
There are a lot of similar comments in the attached discussion at ALA. I think the general feeling is that this technique is very good - just not in the context it was demonstrated.
Probably the best use for it is as a webpage widget - a supplimentary device to present information.
20 Apr 2004 | pb said...
Articles shouldn't have that much code.
I'm just waiting for Google to start providing cached pages with the design stripped out.
20 Apr 2004 | David S said...
I have to agree that, while cool, it isn't very condusive to reading. Having to click just to see sections of the page is a pain. People are used to scrolling (don't know why he thinks they aren't) and the scroll wheel has made it even easier. Breaking that functionality is a bad thing.
20 Apr 2004 | Allan W. said...
One use case that I do appreciate this technique is when, say, there's a technical article with code snippets sprinkled throughout. The code snippets could exist in the 'collapsible' links, so you could expand them as need be. Un-expanded, they don't interrupt the articles' flow, and printing is unified and coherent.
What I've seen many sites do is use a scrolling text field for long code snippets; this works, but it's less visually and functionally elegant.
I do agree that the tabbed presentation is at odds with the nature of the content. It's a nice excercise, but the function doesn't follow the form.
20 Apr 2004 | Darrel said...
Whenever I'm reading an article that has multiple 'pages' I immediately hunt for the 'print friendly' version so I can read and/or print it in one document.
20 Apr 2004 | Kristen said...
Darrel: Me too, I hate multi-paged articles. I think it's all a scam to generate more pages on which to splatter advertising.
20 Apr 2004 | Austin said...
The back button and bookmarking could be fixed by switching the show/hide based on a variable in the URL.
Sure, you'd have to relaod the page with every requests (where straight DOM manipulation avoids that), but I don't understand why people avoid reloading like the plague.
If your page is light, properly coded so objects cache, and contains content or features people want, then a reload should be acceptable.
And they should become more and more acceptable as average connection speeds contnue to rise (more people on broadband) and computing average power also continues to increase (more people with better processors and more modern browsers).
