When to Open Web-Based Applications in a New Window

In "When to Open Web-Based Applications in a New Window," Jakob Nielsen shows when to open web-based applications in a new window, and when to leave them in the current window. I am summarizing this one because it is interesting to me, and it is like the one I did last week. Some definitions to help us out:

Functionality Apps: Independent mini-applications in their own right with state transitions and multiple views (e.g., a tabbed dialog). Functionality applets often manipulate "real-world" data that exists separately from the webpage (e.g., allowing customers to manage their checking accounts, inventory control, server administration).
Content Apps: Tightly integrated with the content of a Web page. Examples include site navigation controls (e.g., an active sitemap, outline flippers to expand and contract a hierarchical listing), active content (e.g., a model of an engine that can be rotated, animated, and otherwise manipulated in place), and minor functions (e.g., a currency converter). Typically, running a content applet has no results other than changing the appearance of the current webpage.

Content applets should kept with content, in the window. Functionality applets should be opened in a new window.

If functionality apps are displayed in a user's browser, and they want to go back they will press back and then will terminate the app. Not good.

Even if there are navigation tools in the functionality app, if it is in the same window, the usual web browser navigation tools will be used. The only solution is to open it into a new window without web navigation tools, and then the users will "stop thinking web" and start thinking app.

Functionality apps may include links back to the original page but they should direct the user back to that page with web navigation tools, not just open the page in the same window. The functionality app can be left open in its current window.

Other Applet Usability Issues

"Most issues in applet usability are no different from traditional rules for user interface design. A functionality applet that spawns its own window(s) should follow application design guidelines, and a content applet that stays on the page should follow Web design guidelines and principles for good information design."

Progress Indicator Needed When Connecting Back to Server

If your applet communicates back to the server, you need to let the user know how it is doing. Use a percent done bar or some other textual/visual indicator of what the computer is doing. Also, include a "cancel" button so the user can ABORT! if it is taking too long.

Double-Click

I don't really understand this paragraph, so I will just give it to you in his words, "In principle, applets should follow current user interface standards, so there may unfortunately be cases where double-clicks need to be supported at this time. In the future, however, double-click must die since it causes novice users great difficulties and since it conflicts with the single-click interaction style of the Web. The main reason for double-click is to allow two operations to be overloaded onto a single-button mouse. Designers of more recent multi-button GUIs have faithfully duplicated a weaknesses that was made necessary by limitations of an early single-button GUI: let's do better in the future. Content applets should be particularly wary of double-click since people will think of them as single-click Web content. (Former Apple human evangelist Bruce Tognazzini provides further details about how newer window systems copied acknowledged weaknesses of the Mac: see his book Tog on Software Design.)"

Back