10 Nov 2006
(updated 10 Nov 2006 at 06:36 UTC) »
On the consistency of tabs
Tabs in most apps are not very consistent.
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
- The "new tab" icon should itself be on a tab (which
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
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
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
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
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
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.
two major ones that care here: Mozilla
Mozilla - Given we just signed a nice
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
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).
This spec is not all bad. There are some
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
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.
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
and love most all of them (except this one)