Use multiple top-level tabs, tab groups, and windows so that users can view more than one page, project, file, or context at a time. Let users place these workspaces side by side if possible.
You’re building an application that views or edits any type of content—websites, documents, images, or entire projects that include many files.
Designers of conventional websites don’t generally need to think about this. All the common browsers supply perfectly good implementations of this pattern, using tabs and browser windows (as shown in the example at the top of the pattern).
Applications whose central organizing structure is a personal News Stream may not need Many Workspaces, either. Email clients, personal Facebook pages, and so forth only show the one News Stream that matters to the user; multiple windows don’t add much value. That being said, email clients often let a user launch multiple email messages in different windows. Some Twitter applications can show several filtered streams side by side—they might show a search-based feed, then a feed from a custom list, then a feed of popular retweets, for instance. (See the TweetDeck example below.)
People multitask. They go off on tangents, abandon trains of thought, stop working on task A to switch to task B, and eventually come back to something they left hanging. One way or the other, they will multitask, so you might as well support it directly with a well-designed interface for doing so.
Side-by-side comparisons between two or more items can help people learn and gain insight. Let users pull up pages or documents next to each other without having to laboriously switch context from one to another.
This pattern directly supports some Chapter 1 patterns, such as Prospective Memory (a user may leave a window open as a self-reminder to finish something) and Safe Exploration (because there’s no cost in opening up an additional workspace while leaving the original one where it is).
Choose one or more ways to show multiple workspaces. Many well-known applications use the following:
- Separate operating-system windows
- Columns or panels within a window
- Split windows, with the ability to adjust the splitters interactively
If you deal with fairly simple content in each workspace—such as text files, lists, or News Streams—split windows or panels work fine. More complex content might warrant entire tab pages or windows of their own so that a user can see a larger area at once.
The most complicated cases that I’ve seen involve development environments for entire coding projects. When a project is open, a user might be looking at several code files, stylesheets, command windows (where compilers and other tools get run), output or log- files, or even visual editors. This means that many, many windows or panels can be open at once.
(And then, perhaps, the user might temporarily switch to another project, with another set of open files and editors! Some development environments can support that.)
When users close some web browsers, such as Chrome, the set of workspaces (all open web pages, in tabs and windows) gets automatically saved for later use. Then when the user restarts the browser, her entire set of previously opened web pages is restored, almost as she left it. This is especially nice when the browser or machine has crashed. Consider designing in this feature, as it would be a kindness to your users.
TweetDeck is a News Stream–type application that can show many streams at once: filtered Twitter feeds, non-Twitter sources, and so on. The example below shows several typical TweetDeck columns. This maintains the spirit of a News Stream by keeping all the updates visible at once; had these columns been in different tabs or windows, a user wouldn’t be able to see all the updates as they happen.
On tiny mobile screens, you don’t have room to show anything side by side. Safari on the iPhone has solved this problem by letting the user open up to eight websites at a time, then using a Carousel to shuffle between them. A user swipes to the right and left to reach the other windows.