UI Practices

Neilsen - http://www.useit.com/alertbox/open_new_windows.html

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:

1. Open non-Web documents in a new browser window.
2. Warn users in advance that a new window will appear.
3. Remove the browser chrome (such as the Back button) from the new window.
4. 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.