Optimal models of navigation for web apps and a return to single-document interface windows.
The web makes everything easy. Your basic web site is not much other than pages and links, where a page is a block of content large enough to fill an entire window, and links connect these pages to make sites. With these simple elements, we build remarkably complex web sites that can be navigated by any user with a modicum of computer experience. This is effected by “history navigation,” in which users build a history of presentations of the pages with links and move within the history using the browser Forward and Back buttons.
As we develop increasingly sophisticated applications on the web, it’s tempting to use this history navigation model. While simple, elegant, and effective, history navigation is nonetheless not a trivial cognitive task for the user. The very fact that we call it web “navigation” is a clue that it’s actually pretty demanding, apparently conjuring comparisons to skilled use of sextants, chronometers, astral tables, and charts. Just as nautical navigators need to mentally visualize a line of position on which somewhere resides their ship, web users need to mentally visualize a line of history on which somewhere resides the current page.
The alternative navigation model comes from thick-client desktop apps. Here, we refer to “documents” rather than “pages,” but they are functionally the same thing, both being a block of content that fills a window. Like pages in a web site, a desktop document may or may not attempt to represent a printed document. A document could just as easily be a query result, a project, an entire database, or process control model, among other possibilities. Rather than accessing separate documents via a conceptual history list, each document is displayed alone in its own window, which users access by simply seeing and clicking the window. This action is the desktop analog of clicking the Back and Forward buttons for the web, navigating the user from one window-full of content to the other. With increasingly large screens for desktops, directly clicking on windows is sufficient for most navigation. However, there’s also a task bar or dock to provide a redundant means of access when windows are fully occluded (e.g., when the current one is maximized). That’s analogous to the dropdown menu on the browser Back button, giving the user relatively easy access to documents/pages that have been buried by others.
Such “window navigation” is cognitively less demanding than history navigation. One would scarcely consider it “navigation,” a term little used outside usability professionals before the browser came along. Indeed, even now, Microsoft calls any app using history navigation a “navigation-based user interface,” implying that a screen full of classic single-document interface windows involves no significant navigation.
Tasks and Navigation Models
While window navigation in principle is less cognitively demanding than history navigation, that doesn’t mean that window navigation is best for everything. There’s a reason why the web used history navigation by default. Each type of navigation is well suited for its associated tasks.
Desktop Application Tasks
In a desktop app, tasks tend to focus intensively on a few documents. The user may work for hours on a single document. This is largely a consequence of desktop tasks being dominated by content creation, rather than consumption. When the users have to build or edit the content themselves, it necessarily requires more intensive focus on each piece. Navigating is typically a small part of the task in a desktop app. Most interaction takes place after the users navigate when they start manipulating content. The user opens a PowerPoint document and scrolls to a slide in 10 seconds, and then may spend the next 10 minutes, writing, editing, drawing, copying, pasting, and annotating that one slide. Documents in desktop apps typically have more content than their page counterparts in the web world. More importantly, the amount of content the user is interested in is typically greater in documents than pages.
When the user is working on a few documents, it makes sense to put each in its own window alone so that the user has ready access to each over many minutes or hours of work. History is not irrelevant, as indicated by the benefits of Recent Document menu items on the File and Start menu, but a few open windows is sufficient for most navigation between documents. Removing documents from such ready access requires an explicit action by the user in the form of closing the document’s window. This means that when the user on occasion opens a document for a quick interaction (e.g., to reference a bit of information), the user will need to take an extra step to keep the screen from being too cluttered. However, given that users open most documents for more intensive work, it’s better to require the user to explicitly dismiss documents than to have them automatically lose their ready access.
Web Site Tasks
Web tasks in contrast tend to involve superficial focus on large numbers of pages. Often users spend only a few seconds on a dense web page or even an entire web site, extracting one or two key pieces of information and disregarding the rest. The user flits from web site to web site. One site may link to another, or the users may use Google to systematically access multiple sites from the same search result, or they may use a portal or news aggregator to track many sites.
User tasks do not necessarily follow the designed information structure of the sites. Well-designed information structures are very important on the web -that’s why you’ve an information architect on the design team -because most web site interactions are navigation of one kind or another. However, the information architecture you so painstakingly created is also inevitably inadequate. If your menu and links really were sufficient for all the users’ tasks, they wouldn’t need the Back button -the link they’d need would be right there were they expect it to be. The importance of the history chain in a browser rivals the content structure we build into our web sites.
It would be a nightmare if each web page opened in its own window by default. The user would be having to explicitly dismiss windows all the time to prevent the screen from being overwhelmed with no longer needed pages. Instead, web tasks are better served by history navigation, despite the greater cognitive demands that history navigation entails. Now if the user is no longer interested in a page, the user must do… nothing. It will naturally disappear on the next page load, and eventually fade back in the history chain until it’s no longer interfering (or easily accessible).
Web Apps are More App than Web
As for your web app, the first consideration is the experience level of your users. Counter-intuitively, some low-end users are better at history navigation than window navigation despite the fact that history navigation is more cognitively demanding. This is because these low-end users use nothing other than the web browser. All they ever needed from a computer they get from the web. They may have never had two windows open at once in their entire life. Basic window operations such as moving, resizing, and minimizing are alien to them. The task bar doesn’t even register in their minds. Some users may not even be aware that one can have two windows open at once.
Assuming you’re not dealing with such low end users, the best navigation model depends on whether the users’ tasks are more like desktop tasks, with intensive work on a few pages, or more like web site tasks, with superficial work on multiple pages. I would expect that the former is more likely than the latter. Or at least it should be in a well designed web app.
While users use a web site to find content, they use a web app to manipulate content. Any navigation is just the means to an end. Thus web apps should be designed to minimize navigation by providing the most useful content per page. This is especially true for any app intended to be used regularly. While rarely done tasks are usually best served with task-centered user interface structures, with multiple simple pages arranged in wizard-like chains, regular tasks are usually best served with object-centered user interface structures, with a few complex content-dense pages. This doesn’t necessarily mean long scrolling forms. Rather, it means a well-organized page that makes the best use of space by employing:
- Tabs, expanders, master-detail panes, and other ways of using the same space for multiple pieces of content.
- Compact presentation.
- Selectable objects and pulldown menus (at least for less commonly used commands) to reduce the space needed for command controls.
In an app, all content of a list or table should fit in a single page within a scrolling pane, rather than being broken into pages like Google does with its search results. As a rule of thumb, a scrollable area needs to show at least 5% of the objects listed in order for the scrollbar to be controllable. This means a full-screen vertical scrollbar can easily handle hundreds of items. Scrolling through lists has the following advantages over paging:
- The scrollbar control is standardized so most users are already familiar with it. Paging lacks standardization so it takes attention and learning to use it (e.g., where the page links are located, whether there’s a First or Last link).
- The number of items shown automatically adjusts with window resizing, allowing users to optimize the number of items visible in one step and avoiding situations when there is both scrolling and paging.
- The scrollbar is accessible no matter where the user is in the window. Paging interfaces typically provide the page links at only the top and/or bottom of the page which can scroll out of view.
- With scrolling, users can move as little as one item at a time to show the items they want to see together. Paging splits items into arbitrary groups which can result in the items of interest being split across pages.
- Users can scroll to anywhere in the list with a single drag. Paging is limited to the page links shown, generally limiting the user to move only around the immediate neighborhood.
- With scrolling, users can multi-select any set of items to perform an action on them (e.g., copying, deleting), and users can look at any other item while maintaining the current selection. Paging generally allows and maintains only selection of the items on the current page.
- With scrolling, sorting and filter unambiguously apply to the entire table or list. With paging, the user may think sorting and filtering only apply to items on the current page. Furthermore, with paging users can become disoriented if they sort while part way through the list; it’s not clear what page they should be on after performing a sort.
- Using a scrollbar, users can still move one “page” at a time anyway by clicking the “track” of the scrollbar.
Finally, a well-designed web app will be purged of gratuitous graphics. Big logos and headers (like at the top of this page) have no business in a regularly used app. The user will know what they’re using. Leave the branding to an About box.
A Window for Every Page
Given you probably want to design your app to have a few content-packed use-intensive pages, you want a window navigation model, rather than a history navigation model for your web app. Just because your app runs in a browser doesn’t mean it has to use the history navigation model. You can open each page in its own window, like a desktop app would. You may even want to hide the browser’s menu and toolbars -they have little use once you’re not using history navigation, and you can use the extra real estate to show more content.
This way you can have the best navigation model for your app, and also benefit from a less cognitively demanding navigation model. Furthermore, using window navigation frees the paging concept to be used for something else. If your app involves manipulation of database records, I recommend you use “paging” to allow users to view multiple records in a form-type layout. And more: the window navigation model makes it clear when the user has left the app. When the user selects Exit (or Logout) from the menu, the app closes all it’s windows. In a history navigation model, Exit typically only moves the user to a “thank you for using our app” page. All the other pages are still in the history chain, giving the user the illusion that they are still accessible, which can cause confusion, especially if users forget they’ve logged out.
Heresy? Opening a new browser window for a page is a Jakob Nielsen Bad Thing, but that’s based on the experience of web sites, not apps. Before the usability police cracked down on the practice, it was common for web site designers to set external links to open their pages a new window. The rationale was that this kept the user from actually “leaving” their site, and thus scoring them more eyeballs. What it actually did was annoy the hell out of the users because:
- The originating web page was just a navigation step. Often the users have finished with the originating web page, but now they have to get rid of it explicitly, rather than letting it automatically fade back into the mists of history. Opening a new browser window in this case is tantamount to a desktop Open dialog box that doesn’t close after the user opens a document with it.
- The originating web page was not a navigation step. Sometimes the users wanted to go back to the web site or some other part of their history but didn’t know how because the users were used to using the Back button for that and it wouldn’t work any more. Even if the users knew a new window had opened, and knew how to navigate back (e.g., via the Close button), it added workload. Now instead of just mindlessly smacking the Big Back Button, the user had to study the screen and figure out which navigation method to use for each page. If users incorrectly choose to use the Back button, they may have to hit it several times before it disables, signaling that won’t work and the users are wasting their time. If users incorrectly choose to use the Close button, they blow away the history they need to get back to where they wanted, and now they’re really wasting their time.
This implies that you can open a new window for each page if
- You do so for all your pages.
- None of these pages are intended as mere navigation steps.
Number (1) ensures your users aren’t burdened with figuring out which navigation model to use. You shouldn’t mix navigation models. Web sites that do this compromise usability. Windows started doing this with Vista, and it compromised usability. If you must include a history-like navigation model in a portion of your app, then you need to clearly signal that new navigation rules apply. One way to do this is display such content with the look and feel of a wizard, which coexist fine with window navigation.
Number (2) ensures you don’t pollute the users’ screens and taskbars with unwanted windows. With desktop monitors being substantially larger than when the web started, a cluttered screen or task bar is not as big of an issue as it used to be, but users normally keep between five and fifteen windows open at a time. Five windows will fill a task bar for a laptop screen; 15 will fill the taskbar for a 30-inch monitor. It’s still important to avoid unwanted windows, even for users with very large monitors.
- Avoid pages that are only menus or lists of links. Make your “home page” something the user can work on (e.g., a dashboard) not a mere launching point.
- Use top or sidebar menus for navigation rather than entire windows. If you have succeeded in having only a few complex pages, you won’t need a big navigation menu anyway. If you have many pages, then use pulldown menus to navigate to them, at least for the less commonly used pages. Pulldown menus are harder to use than simple links (taking two clicks), but remember navigation should be a smaller portion of the user’s work in a complex and capable application.
- If you must have an entire page for navigation then put it in a window that has the look and behavior of a dialog box. Like a dialog box, it should close automatically once users complete their respective input. It needs to look like a dialog box so users will be able to anticipate this behavior.
You should also resist the temptation to rely on drill-down, where the user opens a detailed page for a data object by selecting it from a more general representation or aggregate. You should always provide drill-down, in order to maximize flexibility. Any time more detail information is available on a data object, the user should be able to perform drill-down on it. However you should not rely on drill-down as the way to get to a detailed page when that’s the users’ only interest. Rather, drill-down should be used when the user has work to perform on both the detail and parent page. If your task analysis indicates that users will regularly need to work on only the detail page, then provide a means to access it directly, perhaps via a query or open dialog. This will be faster (the dialog design can be optimized for the one task of specifying the data object) and prevents leaving a large unnecessary open page behind on the screen.
The Preservation Problem
Another reason to use a window navigation model is that it avoids the problems with input preservations. Try this:
- Open a text editor.
- Enter some text.
- Navigate back to this web page.
- Navigate back to the text editor.
Is your text still there? Of course. It would be unacceptable if simply changing your focus to another window would wipe out user input. Now try:
- Navigate to your email web app.
- Compose a letter, entering some text.
- Navigate back to this page.
- Navigate back to the email app.
Is your input still there? No? That’s the preservation problem. Most web apps have not solved the preservation problem. I use Fast Mail’s web app, and the best it can do is show a warning if I attempt to navigate away from a page with input (except it doesn’t aways appear). Showing a warning is not a satisfactory solution to the preservation problem. It locks users in a mode, preventing them from using the computer flexibly. It would be like a desktop app made up entirely of modal dialog boxes.
Even if it weren’t for the formidable technical hurdles in solving the preservation problem, there’s the issue of how exactly preservation should work in the context of history navigation. If the history under the Back and Forward buttons is analogous to open windows in the window navigation model, then clearly navigating by these buttons should bring up each page exactly how the user left it, with both saved and unsaved input. But what about when the user navigates to the same page by a link? Should it also show the page as it was left, or should it create a fresh instance of the page anticipating that users select the link because they want to make new input separate from the other? I don’t know, but I would guess that users will click a link for page sometimes to get back to old input and sometimes to make new input. Either way, some users will get frustrated some of the time.
One could argue that links should always open a new instance of a page, that clicking a link is analogous to opening a new window in the window navigation model. This allows users to view and edit different data using the same page (e.g., compose two email messages a once), maximizing flexibility. The user can navigate back and forth between the separate instances of the page with the Back and Forward buttons. There will necessarily be a learning curve for users to understand the difference between navigating by links versus the Back and Forward button, but they’ll catch on, won’t they?
However, there is one big reason you can’t make links open new instances of pages. Like a Soviet-era dictator, the browser is incline to rewrite history. Imagine this: the user opens one page from another and starts making input. The user then uses the Back button to go back to the previous page and clicks a link to open another page to work on simultaneously. This makes the browser drop the page with the input from the history chain in the Back and Forward button. From the viewpoint of the user, it might as well have been dispatched to an Arctic gulag never to be seen again. Savvy users may be able to find the page in the History pane or window, but that is about as easy as retrieving a document from Recycling -not a normal way to perform navigation. The analogous action in the window navigation model is that opening some windows cause others to silently close. As long as this history “pruning” action exists, clicking a link must bring the user to the old instance of the page in order to provide a backup method to return to any input if the page falls off the history chain. As for the convenience of having two instances of the same page, sorry comrade, not with a history navigation model.
Of course, expert users are aware of the limits of the history navigation model when making input, and they know to open pages in their own window or tab in order to preserve input. They may even know to do this in order to have two instances of the same page with different inputs. However you shouldn’t rely on this expert technique. If your web app mostly involves input pages, then you probably should open each of them in their own window by default and save users the trouble.
As long as the preservation problem forces modes on users, the history navigation model should be limited to web apps where user input is limited to only a few simple fields per page, the kind of input suitable for a modal dialog box in a desktop app. I would say each page should require no more than thirty seconds of user work to complete the input before submitting. This limit minimizes the time the user is locked in a mode and the amount of effort wasted if the user must navigate to another page. I suspect that’s probably all that was ever intended with HTML. Such a modey app wouldn’t make a great app, but it would be no worse than some desktop apps. If you expect your users to flit about superficially through many pages, that may be your most usable solution.
Tabs or Windows?
There is a third option for users equipped with the right browsers, and that’s to open each page in a new tab rather than a browser window. It’s not a bad compromise. It has the window navigation model’s advantage of allowing the user to access any page quickly and avoids the preservation problem. It has the history navigation model’s advantage of keeping all the pages within a single window, minimizing the clutter on the screen and taskbar. However pages in tabs don’t naturally fade back with disuse, which is the major advantage of the history navigation model. Compared to opening each page in a new window, opening in a new tab has the following disadvantages:
- It adds a layer of navigation. Many simple actions can require a two-step process. For example, bringing a desired page to the foreground can require that the user first brings the browser window forward then select the right tab.
- More ways to get lost. It presents another way for non-power-users to “lose” their data. In addition to the browser window being hidden by other windows (including other browser windows), a tab can be hidden by other tabs. Recovery is different in the two cases: in the first, users search the task bar, while in the second, users search the tabs of a selected browser window.
- Single page viewing. The user cannot see two pages at the same time. Even if you do not anticipate the user needing to compare, monitor, or otherwise work with two windows at once, you should provide the ability just for the sake of general flexibility. Side-by-side windows are also better for navigation. Users can see the contents, thus don’t have to rely on reading tab titles, which may be truncated. Clicking on a big window is faster than clicking on a small tab due to smaller average slew distances and larger targets.
- Inefficient use of space. With tabs, every page is the same size on the screen, so users have to size the browser window to be sufficient for the most space-demanding page. With each page in a separate window, users can size each as necessary, making more efficient use of screen space (e.g., while one page may need to be maximized, other pages aren’t, so those pages don’t occlude other windows, minimizing the total frequency of occlusion).
While usually it’s better to open a page in a new window, rather than a tab, there are some special cases when opening in a new tab is preferred:
- Ignorance of multiple window conventions. Opening in a tab may be better for those very low-end users who are ignorant of or confused by the taskbar/dock and multiple windows, and don’t know how to resize windows. My impression is that compelling tab imagery works better than the taskbar for such users in cuing navigation.
- Menu confusion. Your users habitually confuse the menus and toolbars of inactive windows with their active window when there are overlapping separate windows for each page. Tabs hide the menus of inactive pages, which can reduce confusion.
Rather than opening the pages in one of the browser’s tabs, you may want to use your own tab controls in the app itself. When combined with the above two bullets, this can make a superior user interface when:
- You anticipate a large set of tabs for most users (e.g., four or more) and you can control their display in a manner more effective for the task than the browser can as tabs or the OS can as taskbar/dock icons (e.g., with regard to order and labeling).
- You have a fixed number of tabs that should always be open.
However, tabs in your app add clutter and consume real estate in your pages.
Usually, you’re best off opening each page in its own window rather than in a tab. This is especially true if you include features that address whatever disadvantages windows have compared to tabs. Typically, the user can switch between windows using the task bar as quickly as they can switch using tabs, but if you anticipate users having a large number of windows open (more than just for your app), you may want to provide a convenient means to navigate among your app’s windows from within each page. For example, you can provide a thumbnailed menu for switching among windows. Other advantages of tabs can likewise be negated with features. You can provide a control that iconifies all windows of an app with one click, allowing users to get all of your app out of the way like users can with tabs by minimizing the browser. You can provide a means to save the current window contents, sizes, and positions so the user can retrieve the setup in the next session, analogous to what can be done with tabs in some browsers.
I don’t see a problem with a complex app being spread across multiple windows as long as the app is well identified in each window so the users see them as all related. If you keep your page’s graphic design under control, the title bar may be sufficient for that.
In a multiple window app, you can have a centralized “home” master window that opens on app execution and provides the means to navigate to all other windows. Closing the home window exits the app, in contrast to closing any other window. However, in most situations, I recommend egalitarian windows so the users don’t have to identify and navigate to the home window for its functions. Every window should have a menu (perhaps a pulldown) that lets the user open any other window. Every window should have an Exit menu item (in addition to Close) to exit the app, closing all opened windows.
You can still have a dashboard window that opens by default on app execution that shows summary information and supports the user on key tasks, but also consider opening more than one window on app execution if you know what windows the user almost always will need to use. Or consider letting the user choose the window they want from a splash screen. Or install a shortcut to each window in the Start menu at installation, and let the user choose then. Or open whatever windows the user had opened in their last session, if users typically continue where they left off between sessions. With egalitarian windows, you have more options to provide the users whatever is best for their particular circumstances.
The only issues I see with egalitarian windows is this scenario.
- The user is working on Task 1 with Windows A and B.
- The user finishes Task 1, and is ready to start on Task 2, using Windows C and D.
- The user naturally closes Windows A and B, and….
- Oops! The user is out of the app with no way to easily open Windows C and D.
To avoid this scenario, I recommend a mini “when you need it” (WYNI) window. When the user closes the last open window in the app, a small window appears in the same place with nothing but a menu that looks much like the menu in all the windows, but only having menu items that work when there is no content. This includes menu items for things like Help, Options, Change Password, and all the menu items for opening the apps windows. This allows users to close all content windows when transitioning between tasks without shutting themselves out. Closing the WYNI window exits the app. That’s an extra click to exit, but there should be an Exit menu item in every window for exiting if the user wants to be quick.
Problem: Selecting a navigation model for your web app.
- Use history navigation if users will work superficially on many pages.
- Use window navigation when user will work intensively on a few pages.
Window navigation in general has the following advantages:
- Simpler, faster, and more visual navigation for recently used pages.
- “Paging” can be used for other purposes, such as showing multiple database records.
- Exiting or logging out leaves no ambiguous pages apparently available for access.
- Input is preserved when the user navigates to another page.
To make the best use of window navigation:
- Efficiently load large amounts of content on each page to minimize the number of open windows.
- Open every page in a new window -don’t mix navigation models.
- Avoid pages that are only used as navigation steps to other pages.
- Provide each page with a means to open any other primary page and to exit the app.
Opening each page in a window is generally better than opening each in a tab because:
- Navigation is faster and less likely to cause confusion.
- Two or more pages can be seen at the same time.
- Screen space can be used more efficiently.