We’re all familiar with tabbed UIs. They’re far too common to miss.
But, as it often happens, “common” doesn’t mean “good idea”. Let’s take a look at what tabs are, why they were created, how they are used today and why they must die.
A dive into history
I won’t go all the way back to 1988 – roughly the year when tabs emerged, according to Wikipedia – and will limit the overview to Windows, Mac OS X and free desktop environments.
Apple adopted tabbed UI rather early. They inherited application-centric task management from NeXTSTEP along with belief that having several windows per app in such environment is a pain in the proverbial rear, and client-side tab-like solutions as a way of handling that properly.
In 2006 Apple announced Spaces (and don’t you dare to state that Apple invented them – they were first introduced in the original 1984 Xerox PARC, from which Apple also “borrowed” desktop metaphor and windowing and most of stuff you could see in a computer UI in the 90s and 2000s) as a way of grouping application windows.
For some reason (either the knowledge that allowing a lot of windows per app is a bad idea was lost, or some apps were needed on several Spaces at once) many contemporary Mac OS apps (e.g. Safari) allow creating multiple windows too. This is an important point, I’ll come back to it later.
Meanwhile, Windows stuck to window-centric task management. Tabs were uncommon in it until mid-2000s because windows were sufficient for most workloads.
One of the “nasty” workloads was using Internet Explorer – one of the biggest UX issues of IE6 is the fact that it floods and overflows the taskbar so switching between webpages and to other apps becomes very difficult. You probably remember that, Windows XP was damn common after all. No wonder web browsers were one of the first apps to adopt tabbed UIs.
During the Browser Wars only then-trialware Opera offered a tabbed UI. Firefox 1.0, released in 2004, already supported tabbed browsing that was inherited from Mozilla Application Suite. Internet Explorer got tabbed browsing support relatively late, in 2006.
Note that here tabbed browsing emerges as a client-side workaround for the failure of window-centric task management. Many apps became infected with this client-side workaround for failing task management, unaddressed by Microsoft until the release of Windows 7 in 2009. It was handy and trendy; who cares about consistency on Windows anyway?
So far Apple partially supports windows in addition to traditional tabs sometime in the past (probably to make them (probably to make them work better with Spaces),
Microsoft partially supporting tabs in addition to traditional windows, and GNOME and KDE following Microsoft in this.
This is where things went terribly wrong.
On Windows and free desktops, tabs worked well as a workaround for failing DE task switching. But task switching on the DE level was addressed eventually. However, the workarounds did not go away.
If you take IE, or Firefox, or Konqueror, or Nautilus, or Thunar, or any other app which is known to be multi-tasked often, you can’t really tell the difference between creating a new window and creating a new tab. Both serve the same purpose and do almost the same thing. (okay, windows can group tabs, but windows are also grouped by work-spaces (free desktops took up workspaces much earlier than Apple), so you don’t need to group tabs in the first place).
Imagine: e.g. in GNOME we have a consistent, system-wide mechanism of multitasking (windows), and yet-another client-side mechanism of multitasking inside it, which does exactly the same thing while duplicating the system wide mechanism.
KDE went even further to over-complicate things, and besides sticking with the failing window-centric task switching and allowing multiple tabs and multiple windows of an app at the same time, added yet-another-layer of multitasking – Plasma activities.
While GNOME struggles with 3 levels of task switching, KDE has 4.
Let’s try and fix that
Back to GNOME.
Let’s pretend we’re designing a new shell for GNOME that will solve all UI problems of humanity.
The shell will have to work with apps. We already know that in apps there are two ways of exposing task switching inside the app to the user: windows (handled by shell we’re designing) and tabs (completely client-side).
Duplicating the way of doing such a simple thing is deeply wrong (it completely breaks any consistency you were attempting, not to mention finding the content you had “somewhere here, in a tab in this window… no, in that window… no, not here either – let’s look in windows on other workspaces…”), so we’ll have to leave only one and work with it.
As a shell, we have control only over windows; we can’t really change how application works inside. So we can disallow showing multiple windows and let applications rely on tabs. We’ve effectively converted to an application-centric multitasking. That leaves one level of task switching per app. Phew!
Now we have to recall that single desktop and task switcher get cluttered easily and don’t really let you switch between activities. So we’re getting ourselves virtual desktops (or Plasma activities) too.
A discriminating reader will recall that exactly this has happened to Apple in 2006 when they introduced Spaces, and since then Apple is stuck with the same 3 levels of task switching as GNOME and Windows. We need to avoid that pitfall somehow.
The key is allowing one window of a given app per workspace. Assuming you don’t misuse activities-switching mechanism, that solves the problem. We now have 2 layers of task switching, one over the other. This is exactly what we wanted.
Time to proclaim victory? Not quite.
Still screwed
The fix described above will work in short term, but there’s one obstacle for real adoption of it: tabs are client-side. The shell we’ve just carefully crafted has no control over them.
To change the way tabs behave in apps, you’ll have to patch the toolkit (or worse – several toolkits. Ubuntu has 5, for example), and patch every existing app too (if you’re adding a feature). You’re effectively stuck at your y2006 tabs this way, or at least doomed to lag several years behind the whole industry and waste insane amount of effort on keeping up, because patching the toolkit and all apps takes a lot of time.
GTK+ tabs are not fabulous already; they’re like back from year 2006. Tab bar from elementary’s Granite is much better, but it’s still merely catching up with the whole industry; it’s nowhere near things like tab content previews because GTK+ itself is not ready for that.
The only solution
There’s only one solution. Client-side tabs must die.
The replacement should be ultimately handled by the shell.
It’s not really important design-wise how exactly that’s implemented. Windows will do, but there are better solutions.
What next
Ok, let’s imagine we’ve cleansed all GNOME apps of tab bars, and completely delegated handling task switching to the shell. What are the possible applications of that?
Well, tabs in titlebar instantly spring to mind. It will be very easy to implement, including tab previews. Compiz 0.8 already supports something very similar, see its tabbing plugin. All what’s left to do is adding support for it to window decorator and cleansing all the apps of client-side tabs.
The other idea is GNOME Shell which shows piles or groups of application tabs instead of mere application windows in the overview. Epiphany-like tabs are also an interesting concept to explore.
This also allows features like searching/filtering tabs by their title and improves accessibility tools.
And the way tabs are presented to the user can be changed without any modification of apps, in a few clicks. In fact, application developers don’t have to care about tab management anymore, all they have to do is to expose their “tabs” to the shell.
In fact, this opens infinite possibilities for designers. A completely new, never-seen-before shells might arise from this.
Here’s my take at designing one
Meet your new panel (click to meet):
For apps with several tabs the panel displays all application’s tabs next to it, and allows to create a new tab right from the panel. Bye-bye looking through lots of windows with lots of clicks to reach a tab.
For single-window/single-tab applications it behaves like a conventional dock.
The leftmost item is a menu, but not one more boring menu of yours. It’s The True App Center, another concept of mine. I didn’t bother to fully redraw it here, see the original concept for details.
The panel is also flexible. Applications can tell it to display arbitrary items; here’s an example of video player displaying its playlist in the toolbar:
And the panel is also a notification queue/hub, like most modern docks:
In this last pic you can see a lot of cleverness and integration with apps. IM client – the one with ,(!) icon – overrides the images for its tabs with userpics; its second tab is group chat. It also shows per-tab notification badges.
Supplying a custom thumbnail for a tab will be useful in a lot of cases; for example, a text editor can supply a thumbnail of the text around the cursor position so you’ll see the text which you last typed in the thumbnail instead of completely unreadable preview of the entire window.
IM client intentionally doesn’t show the [+] button – you’re supposed to either open existing conversations and add people there, or start new conversations from the address book.
The land of infinite possibilities
If we, as a community, manage to coordinate and kill client-side tabs, we will arrive to the land of infinite design possibilities. With proper multitasking in place, we can pioneer a whole new generation of desktop shells. We can be way ahead of all the industry which is still struggling with 3 levels of task switching.
Titlebar tabs will be simple to implement using mere windows. The last proposal of mine will require quite a bit of thinking and interface coordination; we can’t jump to implementation right away.
But there are a couple of things you can do right now.
- Spread the word. Make sure developers and designers are aware of the problem. If you notice a project infected with client-side tabs, let them know about it!
- If you’re an application developer, insert a kill switch for client-side tabs into your app. Let it be /desktop/screw-client-side-tabs GSettings key set to true, or existence of ~/.config/screw-client-side-tabs or /etc/screw-client-side-tabs files if you’re not using GSettings. Using windows instead of client-side tabs is good enough until we get some momentum going and some specs/interfaces drafted.
- “I’ve killed client-side tabs” badges linking to this article or “innovation-friendly” seals on apps without client-side tabs or with kill switches for them are fine too.
- Designing exciting stuff which uses shell-handled tabs to motivate people to migrate is greatly appreciated! As well as defining use cases and drafting interface specifications.
Guest post by Sergey “shnatsel” Davidoff.
Editing by Cody Garver, with additional editing & formatting by Joey-Elijah Sneddon