Jakob Nielsen's Alertbox, August 29, 2005:

Open New Windows for PDF and other Non-Web Documents

Summary:
When using PC-native file formats such as PDF or spreadsheets, users feel like they're interacting with a PC application. Because users are no longer browsing a website, they shouldn't be given a browser UI.

Users are easily confused when websites link them to non-Web documents that offer a significantly different user experience than that of browsing Web pages.

In user testing, we often observe the following behavior: When people are finished using PDF files, Word memos, PowerPoint slides, Excel spreadsheets, and similar documents, they click the window's close box instead of the Back button. This gets them out of the document all right, but not back to the Web page from whence they started.

Blowing away browser windows is particularly bad on intranets, where users often have to log in or jump through other hoops to access document repositories.

Because users frequently close document windows, the best guidelines for linking to non-Web documents are:

Open non-Web documents in a new browser window.
Warn users in advance that a new window will appear.
Remove the browser chrome (such as the Back button) from the new window.
Best of all, prevent the browser from opening the document in the first place. Instead offer users the choice to save the file on their harddisk or to open it in its native application (Adobe Reader for PDF, PowerPoint for slides, etc.). Unfortunately, doing so requires a bit of technical trickery: you have to add an extra HTTP header to the transmission of the offending file. The header line to be added is "Content-disposition: Attachment". If possible, also add "; filename=somefile.pdf" at the end of this line, to give the browser an explicit filename if the user chooses to save the file. (I thank Sybren Stüvel for providing this code.)

All these guidelines stem from the same underlying phenomenon: the non-Web documents are native PC formats. These formats have their own applications, each of which gives users a set of commands and navigation options that are completely different than the ones for browsing websites.

When you work with, say, a PowerPoint slideshow, your focus is on PowerPoint's slide-manipulation features. Because the user experience is so similar to that of working with your own local slides, it's easy to tune out the fact that you downloaded these slides from a website. When you're done with the slides, you do what you always do when you finish using PowerPoint: reach for the close box.

When a PC-native application opens inside a browser window, a second -- and equally unfortunate -- phenomenon occurs: When users can still see browser commands and buttons, they'll sometimes assume they can use these features to manipulate the document. Unfortunately, features that "make text bigger," "print," and help users "find in page" don't work while viewing a native application document. Given this, it's better not to show users familiar (and non-functional) browser buttons while they're working with a non-Web document.

Conflict with Existing Usability Guidelines

Since 1999, it's been a firm Web usability guideline to refrain from opening new browser windows for several reasons:

When new windows appear that users didn't ask for, it's both confusing and disruptive.
If the new window completely obscures the old one, many users don't even realize a new window has opened.
Less-technical users can't manage multiple windows.
New windows can defeat users who are blind or have low vision, as, for example, when a new window opens outside the part of the screen that's magnified for a low-vision user.

The common rationale designers have for opening new windows is "to keep users on our site," but that's bogus reasoning. If people want to leave, they'll leave. And if they just want to look at the other site, they'll return to your site by clicking the Back button -- the second most used feature on the Web (after hypertext links). In fact, one of the usability problems of opening new windows is that they alter the expected behavior for returning to the previous location.

I thus stand by the old advice against opening new windows while users are browsing the Web. So how can I reconcile this with the new guideline to open PDF and other documents in new windows?

User Experience vs. Implementation

The answer to this apparent conflict lies in the fact that we're concerned here with user experience guidelines, not guidelines derived from implementation technology. Yes, both cases are similar from an implementation perspective: stuff is downloaded over the Internet, from an address specified by a hyperlink, then rendered by a Web browser. But the user experiences are very different in the two cases, which is why the design guidelines also must be different.

Users don't view a PDF file as being the same environment as a website. There's no navigation bar or website features, and the mechanics of interacting with the document are very different than those of interacting with a website. It's exactly because of such differences that users start feeling like they're using an application rather than browsing, and thus click the close button when they want to quit.

Of course, this deviant user experience is one of the main reasons to avoid accursed PDF files in the first place if you're designing a browsing experience. PDF is good for printing, not for on-screen reading. But, if you must use PDF or other PC-native documents, at least recognize that they're different and treat them accordingly.

Intranet vs. Website Design

The new guideline to open documents in new windows was largely motivated by our user testing of intranets, where such documents are particularly common. Interestingly, another case of seemingly conflicting guidelines was also derived from intranet research: Although it's usually best to unify all searches into a single box, usability guidelines dictate a separate box for employee directory search.

Most intranet guidelines are the same as those for websites. The guideline to open documents in a new window applies in both cases, for example, even though it's more important for intranets. As always, usability comes back to two questions: Who are the users? What are their tasks? Because the answers to these questions differ for websites and intranets, the guidelines sometimes differ as well.

Web-Based Applications in New Windows

Since 1997 it's been a guideline for many Web-based applications to open in new windows without browser chrome. Smaller, content-focused apps should remain embedded in the originating Web page.

Learn More

Other updates and the latest usability guidelines are covered in my tutorial on Fundamental Guidelines for Web Usability at the User Experience 2008 conference in Chicago and Amsterdam.

The special guidelines for intranet usability are covered in two days of tutorials: Intranet Usability 1 (the basics that everyone should know) and Intranet Usability 2 (promoting intranets; designing special areas).

The conference also has two full days on application design guidelines:

> Other Alertbox columns (complete list)
> Sign up for newsletter that will notify you of new Alertboxes