10 Nov 2006 Burgundavia   » (Journeyer)

On the consistency of tabs

Tabs in most apps are not very consistent. Different shortcuts, closing buttons, ways of programmatically making them, etc. Making them consistent is good. As such, the Tab Consistency spec as an idea is a brillant thing. However, there is a small problem with the spec as currently written: It simulteanously changes the way every tabbed app on Ubuntu works (including Firefox 2) back to the old Firefox 1.5 way , introduces some pretty heavy patches to do it and ignores a bunch of usability work that has been done in this area.

The bad

  • The "new tab" icon should itself be on a tab (which can be tiny - just containing the "new tab" icon) which is on the left of all the tabs. The "new tab" icon should use the same symbology between desktop platforms. Clicking several times in succession on this "new tab" tab would create the corresponding number of new, empty tabs. The rationale for having the "new tab" tab on the LEFT is that it keeps it far away from the "close tab" icon (which will be on the RIGHT of all the tabs), and keeps it in a consistent place. The other option was to have the "new tab" tab on the RIGHT of the current set of tabs, but this means it will constantly move around, meaning there is no opportunity to build up muscle memory for the "new tab" click.

    Comment: Having a button to open new tab is sane. Having it in the tab bar probably is not. No currently tabbed app in any OS (that I know of) does this nor have I seen anybody even propose it. Interesting idea, but it would essentially mean doing usability testing on 6 million+ Ubuntu desktops with no feedback. Not my idea of fun.

    Update: I was pointed at Konsole, which has such a button. Still undecided.

    2nd Update: Jeff Waugh pointed out that IE7 has such a tab as well.

  • There should be a "close tab" icon on the far RIGHT side of the tab bar (the bar on which the tabs appear). Comment: This is the old Firefox 1.5 model, which Mozilla explicitly moved away from in 2.0, due to Google-funded usability studies. You are read about them here. Why is this bad? It violates the concept of a tab as a physical object (which I will illustrate better in the moving tabs part. Yes, it does lead to accidental closures. However, from my experience and that of the Mozilla usability tests, I think the confusion over "how to close a tab" is a bigger issue than the "I closed a tab accidentally". Note that Opera and now Firefox get around this by allowing trivial reopening of tabs. Not saving users data is a bug. This is not a fix for that bug

  • "It should be possible to move a tab around in the sequence of tabs, by dragging it with the mouse. A small arrow should show the space between two tabs into which the current dragged tab would be placed. The arrow should be themable and consistent across all tabbed applications." Comment: This is currently how Firefox does moving and it has always irked me. I realized today why. It violates the whole "Tabs as objects" principle. When you move a physical object or a window, the object or window just moves there. It does not draw a rectangle or an arrow where I want to move it, it just does it. I can illustrate it very neatly with the following gif: . As you can see, when you move the beer bottle, it just moves. (Sorry, I had to get beer in there somehow). Having the tab just move has always "felt" more natural to me and the key part: It is faster and more fluid. Why? For one, the little arrow is tiny and it jumps around, rather than moving naturally. This means it is hard for your eye to follow. A full tab is quite large and moves cleanly.

    Update: I should clearly state I am talking about the Epiphany way of moving tabs. gnome-terminal just jumps around with a clear indication of which way it went.

There there is the issue of upstream. There are two major ones that care here: Mozilla and GNOME.

Mozilla - Given we just signed a nice agreement with them about working together and one of their stated goals is a consistent look, what are they going to say?

GNOME - The list of GNOME apps include Epiphany, Gedit and gnome-terminal. While tab consistency is very much on the agenda, especially given GTK finally got notebook support, I don't think this is what they had in mind. As the spec freely admits, if we implement this spec we are likely going to have to carry patches around forever and may break API stability (a key GNOME promise).

The good

This spec is not all bad. There are some good points about consistency in the GNOME apps, seen under the Implementation section. There is also a good discussion about keyboard shortcuts. Both of these parts should be talked about and implemented.

In closing

Sebastian Bacher is probably going to ask me why I am raising this now. Very simple. The spec is, as of this writing, at "Pending Approval". Given that this is Mark's spec, I wouldn't bet against it being approved. That means, time willing, this will be implemented for Feisty. As this is the spec I completely disagree with the implementation one, I thought I would raise my specific issues.

In the end, tab consistency is a good thing. However, the proper place for all this discussion is upstream, not in the distro. Let start a dialog in GNOME, decide on a course and all work towards that. Vendor patches are not going to make anybody happy here.

Tomorrow: Rocking specs from Mountain View (there were tonnes and love most all of them (except this one)

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!