User Context and Navigation in Articles

Chad Lundgren’s latest entry got me thinking about user context and navigation within articles. The page is a great example of what not to do, (If there aren’t any more pages, don’t even show the word “next.”) but what about good examples? Let’s take a look at several common variations on showing user context.

I really like the way Wired shows context. It concisely shows the total number of pages, what page you’re on and where you can go. At the most, you’ll only have two navigation choices within an article: previous and next. (Click on the images for examples.)

Wired article navigation

Boxes and Arrows also uses previous and next links, but they show the total number of pages by linking to them all. I don’t like this method as much because I rarely have a use for going straight to a specific page number. I can go straight to page three of the article, but what will I find there? On the other hand, I can see it being helpful when I’m sharing the article with someone. For example, “It’s somewhere around the middle of page three.”

Boxes and Arrows article navigation

iView shows what can happen when the Boxes and Arrows method is taken to the extreme, but without using previous and next links. I don’t like this example for two reasons. First, as mentioned above, I can go to any point within this article, but why would I if I don’t know what I’ll find there? Secondly, not using next and previous links within the article navigation makes navigating to the next or previous page needlessly difficult.

Update: After posting this, I remembered that the iView article does have a next link at the bottom of the page. In this entry, I’m only referring to their main article navigation at the top of each page, as shown in the following image.

Iview tutorial navigation

Futher questions:

  • What are some other examples of user context and navigation in articles?
  • Does HTML limit our ability to show context with navigation effectively?
  • Can anyone point to some innovative Flash examples?
  • Has any research been done in this area?


  1. International Herald Tribune not only looks great, but their navigation is easy and fast. The whole page is already loaded, and pages get ‘flipped’ by Javascript; not only that, but getting the whole article in the browser is a click away, as are font-size changes and printing.

  2. Even more baffling, IHT has had that layout for probably 2 years or so now, and still nobody comes close. One thing to keep in mind is that no matter what the subject, journalism is an old field, which means the people running the show are old-school. This trickles down to a generally conservative attitude that has only been really challenged in the past 6 months or so as sites are making the push to modern sites, largely due to cost-cutting and competition.

    Another note is that Mozilla has a feature (since 1.2 I think, and not enabled by default) that turns on a navigation toolbar on pages that use the standard tags. Though the build of the site linked on my name (HotPOP) that is about to go out the door has it, the live site doesn’t. The only other site I know that uses it is (as you might expect).

    To enable:

    View > Show/Hide > Site Navigation Bar > Show Only As Needed

  3. AND the page still loads in NN4 and opera using alternative stylesheets.

  4. I’m fond of Phoenix, and since it’s based on Mozilla, I can change font size however I chose. Being a web designer, I don’t complain if things get a little odd when I do so.

    With the IHT layout, if I increase even one font size, parts of the story get clipped. It’s like they re-invented the infamous Internet Explorer you can’t resize text bug. (Oddly, Mozilla 1.21 doesn’t exhibit the same bug. Maybe their browser detecting needs a little work?)

    One thing I discovered from monkeying a bit is that if you select the one page icon it keeps that view for on subsequent stories, which is a nice touch that makes up somewhat for the text-clipping thing.

    I’m also perturbed not being able to hit Back on your browser and have it do what you expect. Reminds me of first-generation frames.

    BTW, thanks for the link, Joshua.

  5. IHT is an good example of what can’t be done with simple HTML and images. I agree on all of your points, especially the way the pages get ‘flipped,’ which is very slick. That it works in NN4 and Opera is even more impressive. So if IHT is doing it and has received tons of praise, why aren’t more publications following suit?

  6. Minor point Chad:

    IE not resizing fonts defined in pixels is not a bug, it is complying with the CSS spec/recommendation.

    “Pixel units, as used in the last rule, are relative to the resolution of the canvas”

    Due to general laziness of coders, most went with using px because it gives a high degree of consistency across browser/platform (as it is intended to do). Mozilla reacted to this problem by ignoring the spec and allowing you to resize fonts. A good thing? Probably, except now you cannot define an absolute font-size for Mozilla (useful for overlaying text on images). The root problem is that designers/html coders put laziness over accessibility, and that’s not an issue a browser can really fix, unless it decides to ignore its own mission (“designed for standards compliance” -from Mozilla homepage).

  7. I always wait a while to upgrade Movable Type (the software I use to publish this site). The wisdom of this approach was borne out when a security fix had…

  8. Too funny, was just having a conversation about the IHT site and why more sites haven’t pushed some more of their conventions. I love the “clippings” feature as well.

    IHT Designer Interview

    Eric, I have to disagree slightly with the use of pixels as pure laziness. Pixels are often the ONLY reliable measurement unit when your dealing with legacy browsers as well as the modern stuff. Though thats less an issue every day, Woot!

    Also I think the clipping feature at the IHT should find wider adoption in one form or another.

  10. It’s not laziness. It’s competiting concerns. Accessibility is important, but it’s only one of a number competing interests — such as brand identity — that need to be balanced.

    If browser maker’s early implementations of ems hadn’t been been so lethally buggy, I’m sure designers wouldn’t have minded using them.

    Back to the topic at hand, my preferred method of handling pagination is one of two ways:

    1) A List Apart style, where a list of subheads are used as links to each page — best suited for short stuff.

    2) Previous | Page [pulldown list] of [total pages] | Next

    The pulldown menu both allows easier random access among pages _and_ make the clicking target much larger — which a typical problem with number links. It’s not as universally accessible since it requires JS to automatically trigger the list.

    But it’s probably not hard to make it so. Have the JS change the CSS to hide the form button — so if JS is turned off, the button reappears. If you’re really concerned about accessibility, you could probably have CSS hide an alternate static page number or set of iView style page number links, which would only be used if the CSS is disabled or served up as an alternative stylesheet.

Comments are closed for this entry

Please send your feedback via Twitter to @jmk.