posted by Thom Holwerda on Sat 16th Aug 2008 16:50 UTC
IconThis is the eighth article in a series on common usability and graphical user interface related terms [part I | part II | part III | part IV | part V | part VI | part VII]. On the internet, and especially in forum discussions like we all have here on OSNews, it is almost certain that in any given discussion, someone will most likely bring up usability and GUI related terms - things like spatial memory, widgets, consistency, Fitts' Law, and more. The aim of this series is to explain these terms, learn something about their origins, and finally rate their importance in the field of usability and (graphical) user interface design. In part VIII, we focus on the tab.

The tab is a user interface element that has existed for a long time, but only gained a strong foothold during recent years. The tab was first introduced by IBM's Common User Access, a set of interface guidelines which heavily influenced the early development of Windows. The goal of the CUA was to standardise the myriad of different key combinations and looks among different applications on mostly the MS-DOS platform. For instance, the default order of menus in menu bars (File, Edit) comes from the CUA, as well as various shortcut keys such as F10 to activate the menubar. Windows still uses the shortcut keys as specified by the CUA.

So, what is a tab, exactly? We all know them, but how would you define it? I could come up with my own definition, but seeing Wikipedia already has a good and clear one, that seems a bit redundant:

In graphical user interfaces, a tab is a navigational widget for switching between sets of controls or documents. It is traditionally designed as a text label within a rectangular box with its top borders rounded. Activating a tab (usually by a mouse click) makes its associated content visible and the tab itself usually becomes highlighted to distinguish it from other inactive tabs. Only one tab can be active at a time.

Tabs gained popularity quickly as a method to organise crowded settings panels, a place where you can still find tabs today. If you for instance open the mouse preferences panel in Windows, you'll see the various options grouped under a number of tabs. While using tabs can certainly improve settings panels, it can sometimes turn into a case of the cure being worse than the disease; two rows of tabs almost always act very confusingly, with the rows sliding up and down. This can be quite frustrating.

Having a single window with multiple documents open under tabs is a tabbed document interface. Most people will be familiar with TDIs in their web browsers, which is indeed one of the most common uses for tabs. The first product to use a TDI was the NeWS version of the Gosling Emacs text editor, and Don Hopkins later developed several add-ons for the NeWS windowing system which allowed every application to use tabbed window frames.

The first hypertext browser (so not web browser) to use tabs was Ben Schneiderman's HyperTIES browser. The first web browser to sport tabs, however, was InternetWorks. Released in 1994, it sported multithreading (loading and viewing webpages at the same time), multi-pane windows, and tabs (the tabs are located at the bottom). Some, however, disagree with the notion that InternetWorks's implementation of tabs was actually a form of "tabbed browsing":

In [InternetWorks] (and I have several copies floating around), tabs represented the navigation stack of a user's browsing session. To go back or forward, you switched to the different tabs which represented other locations in your session history. Tabs were not in any way independent, you could not right-click "open in new window/tab". In all modern tabbed browsers, each tab can be independent of the others. You can have one tab open at CNN, one at Slashdot, one at [InternetWorks]'s tabs just gave a picture of your navigation stack, that's all, like an expanded menu in your back and forward button.

The first of the modern web browsers to receive tabbing functionality is - in a sense - Internet Explorer. In 1997, NetCaptor, an Internet Explorer shell, saw its first release, and gained tabs shortly thereafter. NetCaptor's implementation served as the blueprints for all other modern browsers, with most browsers following suit after NetCaptor. Amiga's IBrowse implemented tabbed browsing in 1999, Mozilla somewhere in 2000/2001 (through an extension in 2000, and built-in as of Mozilla 0.9.5 in 2001), and Apple's Safari in 2003. Opera is a bit difficult to classify in this timeline, since Opera had a multiple document interface long before it had tabs - however, MDI is not the same as having tabs. 'Proper' modern tabbing wasn't added as a feature to Opera until 2002, with Opera 7.0.

From there on out, tabs spread like a wildfire through graphical user interfaces, making their way to every type of application, from text editors to instant messaging clients to mail clients to music players. Having tabs became almost a pre-requisite for success.

Advantages and disadvantages

One of the main advantages of using tabs instead of multiple separate windows is that it reduces clutter. All documents are logically grouped inside the main window, leaving more room in the taskbar for other entries. Most tabbed applications also allow you to group related documents together in various different parent windows, which can aid in window management.

This all comes at a price, however. While tabbed interfaces seemingly reduce clutter, they also add another layer of complexity. Most graphical user environments have a single place to switch between windows/applications (the taskbar), and while tabbed interfaces do reduce the number of entries in the taskbar, it does not in fact eliminate them - it only moves them to another location. So, instead of having one place where the user can go to to switch between documents and applications, he now has multiple locations. Switching from document Abc in a word processor to webpage Xyz in a browser may now require more clicks and attention focus switches than in a non-tabbed interface.

More often than not, other window management features (other than the taskbar) do not respect tabs either. Exposé in Mac OS X, or the ubiquitous alt+tab command both do not respect tabs, and will cycle through application windows alone, not through tabs. In other words, you need alt+tab to switch to the tabbed application, and then another, application-specific keyboard combination to switch to the proper tab. Again - added complexity.

Another disadvantage of using tabs instead of separate windows is that tabs are inherently maximised within their parent windows; in other words, you cannot look at two or more tabs at the same time. This problem was later on solved by making tabs 'detachable'. While this alleviates the situation somewhat, it still means you have to perform an extra task (detach the tab) - added complexity. Starting to notice a pattern?

Consistency is usually another victim of the tabbed interface. Even though a graphical toolkit might provide a default tab element, few applications use them, instead preferring their own, homegrown tab. A tab in Firefox looks different from a tab in Opera, which looks different from a tab in Notepad++, which looks different from a tab in a Windows settings panel, and so on, and so forth. Yet more complexity.

A final point of difficulty has to do with closing a tab versus closing a window. The tabbed document interface is actually a bastardised (and less capable) multiple document interface, and therefore shares a problem with the MDI: how do you prevent users from accidentally closing the parent window, instead of just the child window (MDI) or tab (tabbed interface)? Tabbed interfaces and MDIs come with multiple close buttons; one for the parent window, and one for each child window or tab. This is yet another example of the tabbed interface actually adding complexity.

Complexity ain't all bad

The fun thing is though - no matter how many theoretical downsides and disadvantages you can come up with when it comes to tabs, out in the real world, tabs have been a smashing success. Whether you are dealing with an advanced user, or the hypothetical grandmother, few will have problems understanding the concept of tabs, and how to properly use them.

A common sentiment, especially among the Apple and GNOME camps, is that reducing complexity in the graphical user interface is by definition always better than increasing complexity. While this might be true in a lot of cases, the resounding success of the tabbed document interface clearly shows that as with everything in computing, there is no golden rule. The tabbed interface increases complexity, yet it makes working with computers a lot easier for many people.

Sometimes, logic simply doesn't prevail.

e p (3)    35 Comment(s)

Technology White Papers

See More