Re: [Usability] Tab implementation review

[Randall Wood <randall h wood alexandriasoftware com>]

On 10 Feb 2009, at 07:16, Allan Day wrote:

> On Mon, 2009-02-09 at 19:22 -0500, Randall Wood wrote:
> > On 9 Feb 2009, at 12:12, Allan Day wrote:
> >
> > > Hey all,
> > >
> > > I've been working (on and off) on reviewing all the bugs and other
> > > discussions on tabs in GNOME [1]. It's reached a fairly mature stage
> > > now. I think the review contains useful information about how tabs
> > > could
> > > be improved in GNOME. Any comments or suggestions?
> >
> >
> > I would suggest the following:
> >
> > - The display of a single tab (show tab or collapse tab bar) should  
> > be
> > user configurable and universal across the entire desktop (A user may
> > find that screen real estate is more valuable than consistency). I
> > would make showing the tab bar when there is only a single tab the
> > default.
>
> There has been some recent discussion about the display of the tab bar
> in Gedit (this is the only GNOME app to display the tab bar when only
> one tab is open) [1]. In that bug, a number of devs state a preference
> for hiding the tab bar by default.
>
> You might also want to read this discussion on the Usability list:
> http://mail.gnome.org/archives/usability/2005-June/msg00133.html .
>
> So let's review the arguments:
>
> *Tab bar hidden by default*
>
> Advantages: clean, simple interface. Apps look very minimal without  
> it,
> which can be nice. Makes learning the basics of the interface easier
> (since it is simpler). Conforms to current practice amongst GNOME  
> apps.
>
> Disadvantages: makes tab functionality less discoverable. Means that  
> it
> isn't possible to introduce additional functionality to the tab bar.
> Clicking on empty space in the tab bar could trigger the creation of a
> new tab, for example. Or it might be possible to drag tabs and windows
> from elsewhere into the tab bar. (Maybe the first step is to decide
> whether this functionality is desirable?)
>
> > - Perhaps the close button should be hidden when there is only a
> > single tab?
>
> I'd say leave the close button there, for sake of consistency.
>
> > - Use Ctrl+{ / (Open brace) Ctrl+} (Close brace) to move between tabs

PgUp/PgDown moves around between keyboards even in the same layout.  
Look at compact keyboards like on laptops compared to full size  
keyboards. I switch between fullsize keyboard on a docking station and  
the compact keyboard on my laptop frequently, and the PgUp/PgDown keys  
are in different locations, while the {} keys are in a constant  
location.

> Oh? Why not Ctrl+PgUp/PgDown?
>
> > - Tabs should be included in the Window menu
>
> Agreed. There are decisions to be made about what this menu entry  
> should
> be called and what it should contain. Most GNOME apps call it 'Tabs'.
> Gedit is the exception - it calls it 'Documents'.

It seems to me that conceptually the tab is nothing but a logical  
extension of the window, and if we do a document-centric design, the  
window is nothing but a container for a document, so that makes sense.  
The only problem with using "Documents" instead of "Windows" is a  
matter of consistency--if every document-centric application had a  
menu for the type of objects it handles in windows (documents,  
conversations, drawings, etc), the user would loose the common target  
of "window" for dealing with the document container. Also,  
applications that work with multiple types of document-like objects  
might have problems as well (think of OpenOffice - it has the Window  
menu, would it need "Documents", "Spreadsheets", "Drawings", etc if it  
lost the window menu?

> > - There should be a menu item "Window->Merge All Windows" to move all
> > tabs in all windows to a single tab bar in a single window
>
> Sounds like useful functionality. The main argument against might be  
> in
> terms of keeping things simple. Also, I'm not sure whether this is
> something that could be done by the window manager - might have to go
> into the File menu.

I don't think this should be a window manager task, its just that  
since tabs are window-like things, it fits with the other activities  
in the window menu. The File menu should about taking actions against  
the file being displayed or edited in the window or tab, not about  
moving tabs between windows, or moving all tabs to a single window.

> Allan
>
> [1] http://bugzilla.gnome.org/show_bug.cgi?id=547848