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)
