If you're new here, you may want to subscribe to my RSS feed. So that you can read the latest updates about Web2.0 tools, Making Money Online, Tips in SEO, Ajax and many more. Thanks for visiting ProgramimiCOM!

Within-Page Links Violate Users’ Mental Model

On websites, within-page links are bad for the same reason that PDF files are bad entered without warning in the top-ten design mistakes. Users have developed a strong mental model for link following, which has several elements:

1. Clicking a link navigates you to a new place.
2. After you click, the old page goes away.
3. A new page loads into the window, replacing the old page.
4. You first see the top of the new page.
5. The Back button returns you to the old page.

Because almost all clicks work this way, users have very strong expectations that the Web will work this way. It’s a simple model that makes sense. Within-page links violate all five points in users’ mental model of links:

1. A within-page link scrolls the window rather than navigating you to a new location. This confuses users: they assume they’ll get new information, but if they’ve scrolled through the page before clicking, they’ll get stuff they’ve already seen.
2. The old page doesn’t go away; it’s still in the window. However, because users think they’re on a new page, they’ll try to figure out how the “new” information differs from what they’ve seen — obviously, a futile task.
3. No new page is loaded into the browser window: it displays the same data, just scrolled differently.
4. Rather than land at the top of the page, you typically find yourself somewhere in the middle with no navbar or other expected top-of-page design elements.
5. Clicking Back doesn’t take you to the previous page; it takes you to the previous scroll state of the same page. This can doubly confuse users who’ve scrolled to the top of the page before clicking Back.

After experiencing a few within-page links and Back button clicks, most users are completely confused about where they are on a site. Our studies also show that such links typically waste far more time than they save because users click back and forth multiple times and repeatedly review the same material.

When Within-Page Links Are OK

To avoid confusing users, you must communicate exceptions to their expectations in advance. It’s okay, for example, to use mailto links, as long as you clearly indicate that the links will activate an email program rather than navigate users to a new page. You can signal this through link format (”donald@duck.com“) or wording (”send an email to customer support“). Similarly, if you absolutely must use within-page links, say so. For example, add a short statement that says something like: “Clicking a link will scroll the page to the relevant section.”

Assuming you warn users, within-page links have three acceptable uses. First, with long alphabetized lists, you can show the letters of the alphabet across the top of the page and have each letter link to the appropriate place in the list. Second, in frequently asked questions lists (FAQs), you can list the questions at the top of the page and make each question a link that scrolls the page to the associated answer. Third, there are a few other cases where you can start a page with a table of contents that links to the appropriate sections further down the page.

All three exceptions share a common format: a long list of items summarized at the top of the page, with links taking users directly to the desired items.

Even with this scenario, it’s best to avoid within-page links if possible. You might, for example, make the lists short enough that users can easily scroll them. Only for very long pages will the time saved be worth the confusion that within-page links can cause.

For example, we recently tested a website that listed information for each of the fifty US states on a single page. Above the fold, the page displayed a map of the US with instructions that told users to click on their state.

First off, it’s usually a bad idea to ask users to select their state or country by clicking on a map. While it works well for those of us in big states like California, take pity on folks from Rhode Island or Connecticut. (The same argument applies, for example, when asking users to pick their country from a map of Europe: fine for German users, less ideal for Belgians.)

Assuming users have sufficiently steady mouse hands to click their particular state, our example page scrolls accordingly. If users click a state in the middle of the alphabet (say, New York), the state appears at the top of the window and users can easily find their information. Unfortunately, if they click, say, Wisconsin, they’ll typically find Tennessee on top of the screen, because that’s as far down as the page will scroll. This causes confusion: “I clicked Wisconsin, but it says Tennessee?”

In this case, because each state has only a few data items, it would be better to simply let users scroll through the page to find their state. Sure, that’s annoying if you’re from Wyoming, but it actually requires less time to simply scroll than to read and understand the non-standard instructions for clicking the map. After all, people arrived at such pages by clicking links like “Information about foo by state“; they expect to see a list of states, and know where to find their own state in the list.

Linking to Named Anchors Across Pages

Using named anchors to link to a specific place on a different page is not as bad as using within-page links on a single page. When you link to a named anchor on a different page, you retain four of the five expectations in users’ mental model: they navigate, the old page disappears, a new page loads, and they click Back to return to the old page. The remaining expectation is the only problem: instead of going to the top of the new page, users are typically dumped into the middle.

While it’s certainly better to violate only 20% of the mental model, violating user expectations is still a bad idea. Dumping users in the middle of a page causes usability problems because users need to situate themselves when they land on a new page. A page’s headline, introduction, and navigational apparatus provide essential context to that end.

Nonetheless, named anchors are tempting. At the top of this page, for example, I have links to various articles because I refer to points made within them. I refer to those mistakes in the Top Ten Web-Design Mistakes article. While it could be advantageous to directly link to these two sections, direct links also have disadvantages.

Say, for example, I linked to a named anchor for #6, which is about JavaScript in links. Sure, you’d see this point first, but further down your screen you’d see #7, which is about adding infrequently asked questions to a FAQ. That’s an odd continuation of a JavaScript discussion, don’t you think? That’s the penalty of starting users in the middle of a page when they don’t understand what the page is about.

The best solution in such cases is to create separate pages for everything that serves as a link destination.

So: you should avoid named anchors and within-page links because they violate users’ expectations for hypertext linking on the Web. A link should bring up a new page. Deviating from this model requires an explanation; you should only deviate if it will save users significantly more time than they’ll waste pondering the non-standard interaction technique.