Multiple windows vs tabs

Earlier this week, I had a discussion with my supervisor about ‘pop-ups’ vs ‘tabs’ in user interface design. Here are some thoughts arising out of that debate.

Firstly a note on terminology. In our discussion, we were talking about ‘separate windows launched by an application’ vs ‘tabs that appear inside the main application window’ as a means of providing distinct pieces of functionality to the user. Probably we were using the word ‘pop-up’ incorrectly. On reflection, a pop-up is a window that appears — pops up — without the user requesting it. Most commonly these are initiated by web browsers for on-line advertising. This post gives a more detailed discussion about this.

Many dialogue boxes in desktop applications are also pop-ups — they pop-up and prompt the user for information, interrupting the user’s work-flow. This is particularly true of modal dialogue boxes that require the user to interact with them before the main application can be accessed. These are also often criticised in usability circles — mainly because they are usually used unnecessarily where another form of interaction would suffice.

However, this is not really what the debate is about. The debate is about having multiple windows providing an application’s functionality to the user vs a using multiple tabs within one window. The main arguments against multiple windows were:

• They obscure what is beneath them
• They create desktop clutter
• They are difficult to manage (management is delegated to the window manager from the application)

I think it should be noted at this point that almost all of the literature on the subject of ‘pop-ups vs tabs’ concerns web usability. Specifically it concerns the relative merits and usage of browser pop-ups, pop-up ads, tabbed browsing, and light-boxes. There seems to be far less written on the web about ‘pop-ups’ in the context of desktop applications. In terms of the desktop we are talking about a number of different things:

1. Modal dialogue boxes
2. Mode-less dialogue boxes
3. Mode-less windows outside the main application window
4. Windows hosted inside the main application window

A tabbed interface only serves an alternative to 3/4 so we’ll now focus on those.

Interfaces with separate windows

I think there are many cases where there is a strong argument for having functionality presented to the user in separate windows. Good precedents for this can be found in Digital Audio Workstation (DAW) software software, which often has an ‘arrange’ window where audio segments are positioned on tracks in relation to a timeline, and a ‘mixer’ window which provides functionality for controlling the levels and plugin settings for each track. If these pieces of functionality were provided via a tabbed interface, much of the user’s time would be spent switching between tabs, with many unnecessary mouse-clicks/key-presses.

It is also useful to use a separate window for functionality that requires a fixed amount of screen space and is significantly smaller than the main window. Plugin ‘pop-ups’ are a good example of this. Again, most DAWs open a ‘pop-up’ for accessing plugin parameters. In fact the majority of VST, AU, DSSI etc. plugins are intended to have their UIs open in a separate window.

I don’t see that having multiple windows open for a given work-flow is inherently bad. It is quite often useful (if not essential) to see the state of various parts of the application simultaneously. It can also be an advantage to delegate layout etc. to the window manager, with some WMs such as Compiz for GNU/Linux providing advanced facilities for window grouping and arrangement.

Tabbed interfaces

There are also cases where a ‘tabbed interface’ is the right approach. Good examples are pieces of software where the user needs to keep multiple documents or sessions open at the same time. Good examples are web browsers, text editors, word processors and terminal emulators. The functionality provided to the user doesn’t change between tabs, it is only the active document or active session that changes.

Tabs are also commonly used to simplify preference panels and to provide multiple sidebars. In the case of preference panels, conceptually, the user is doing the same thing in each tab — altering preferences — there is no operational/functional change. However, in the case of multiple sidebars (cf. Inkscape’s ‘object’ operations), tabs are used to provide multiple ‘palettes’ of operations without cluttering the main window. Inkscape is an interesting case in point because the user can optionally detach the palettes and have them in separate windows.

Conclusions

With tabbed interfaces where tabs are used to switch the content of an application’s main window, the important thing to note is that from the user’s perspective, the operations they can perform don’t change between tabs. That is, the application provides the same functionality regardless of which tab is selected, it is the active document that changes, not the functionality. The opposite tends to be the case where separate windows are used. That is, individual windows provide discrete pieces of functionality to the user (separate plugin UIs, an arrange window, a mixer window), with all of these operations applied to the same active document. So in conclusion, tabs work best for switching between multiple documents/sessions with a common set of operations available between all tabs. Multiple windows work best for separating functionality that cannot realistically be provided with a single window interface, and where all windows operate on a common active document/session.