Avoid Within-Page Links

by Jakob Nielsen on February 21, 2006

Summary: On the Web, users have a clear mental model for a hypertext link: it should bring up a new page. Within-page links violate this model and thus cause confusion.

I recently received two questions on the same topic on the same day. That's usually a sign that the topic has broader interest, so I decided to write a column about it.

Question #1:

I'm involved in a discussion about "jump links," where users click on a link that takes them to a "named anchor" (a different location in the document). I'm using two of your articles to make my point that jump links are not much better than links that open new windows.


Question #2:

I am wondering if you can please clarify some of your recommendations about opening new windows:
  • "Links that don't behave as expected undermine users' understanding of their own system. A link should be a simple hypertext reference that replaces the current page with new content. Users hate unwarranted pop-up windows." ( Top Ten Web-Design Mistakes of 2002 , point 6)
  • "Interaction consistency is an additional reason it's wrong to open new browser windows: the standard result of clicking a link is that the destination page replaces the origination page in the same browser window. Anything else is a violation of the users' expectations and makes them feel insecure in their mastery of the Web." ( Top Ten Web-Design Mistakes of 1999 , point 3)
Both of these recommendations speak of hyperlinks loading new content into the user's existing window. Does this imply that links to content situated on the same page confuse users? Or, put another way, is your recommendation suggesting that all links must load a new document into an existing browser window?

Both of these questions refer to my analyses of why it's bad for a link to open a new window or a pop-up. Both also rightly assume that this reasoning applies to links within a page as well.

Within-Page Links Violate Users' Mental Model

On websites, within-page links are bad for the same reason that PDF files are bad and that mailto links that fire off emails without warning made 2002's list of 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. In the Top Ten Web-Design Mistakes of 2002 article, I refer to mistake #6 in one place and mistake #10 in another. 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.

Reader Comments

See sidebar commenting on links for AJAX, "return to top," and skip-links for disabled users .


Share this article: Twitter | LinkedIn | Google+ | Email