Tab Appearance

Tab Width

  • Should tab widths be fixed or dynamic (or a combination of the two)?
  • Tab width relates to the more general problem of how large numbers of tabs should be handled (see the section on this below).
  • Fixed width
    • Has advantage of meaning that the placement of tab close buttons is predictable - fixed width tabs mean 'that you can close a number of tabs in a row with a few clicks, without having to move your mouse' (gnomebug:116519).
    • With fixed width, you soon run out of screen width - requiring scroll arrows for navigating between off-screen tabs. '[s]ometimes when you open a new link in tab and it's hidden from view, I've seen users continuously click and click it thinking it's not been loaded' (gnomebug:116519).
  • Dynamic width
    • It would be bad to base tab width on the length of their labels/titles because these are dynamic in some apps (like Epiphany, Galeon; see gnomebug:72101).
  • Combination of fixed and dynamic width
    • It is possible to combine fixed and dynamic widths. In Firefox, the first four tabs are have their width based on window size. As more tabs are added, width is adjusted automatically (gnomebug:72101).
  • Existing Implementations

Close Buttons

  • Approaches:
    • Close button on all tabs (see bug gnomebug:72101)
    • Single close button on the far right-hand side of the tab bar
      • 116650 (against Gtk+) - there should be "action area" for GtkNotebook (e.g. for tab close button). A patch was produced but never committed.

    • Close buttons on all tabs, only display the button on the selected tab when there are many tabs open (see gnomebug:330676
      • This would combine with dynamic tab widths
  • There's a trade-off to be made between ease of use and screen space (see http://mail.gnome.org/archives/usability/2005-June/msg00133.html).

Displaying Large Numbers of Tabs

  • Major discussion here: gnomebug:110540.
  • (Non-mutually exclusive) approaches:
    • Extend tabs off-screen, use scroll arrows (see gnomebug:72101).
      • Bug gnomebug:167693 - if the screen width is fully populated with tabs and a new tab is created, the tabs should slide along so that the new tab is visible, instead of being hidden off-screen (section on new tab placement is relevant here).
      • Bug 300537 and 330676 - having tabs hidden off-screen is bad.

      • Bug gnomebug:326953 - the scroll buttons are too small, and should highlight on mouseover.
      • Bug gnomebug:110540 - should scroll buttons change which tab is focused?
      • Bug gnomebug:377441 - Make notebook arrows scroll the tab view without having to click multiple times.
    • Multiple rows of tabs (gnomebug:440274, gnomebug:110540 (long discussion here), gnomebug:330676).
    • Use a drop-down menu to access tabs which aren't visible (suggested in gnomebug:110540 and gnomebug:501007), like what Firefox has.
    • Dynamic tab width (gnomebug:330676)

Tab Bar

  • Should the tab bar be displayed when only one tab is open (see https://wiki.ubuntu.com/TabConsistency)?

  • Bug gnomebug:547848 – gedit should not show a tab if only one document open - some Gedit developers want to hide the tab bar when only one tab is open. It is pointed out that the main disadvantage of this approach is that it means that it will not be possible to use the tab bar for other actions - such as dragging in new tabs.
  • Existing Implementations

Tab Alignment

Tab States

  • The issue - how to display different tab states: unsaved changes, loading, attention, changed, etc. (see gnomebug:72101).
    • It has been requested that this functionality be built into the Gtk+ netbook api (gnomebug:116647).
  • Possible approaches:
    • Display an asterisk before the tab title to denote unsaved changes (gnomebug:72101).
    • Themable colour coding (gnomebug:132173).
    • Bold tab titles - see the Epiphany tab states extension (gnomebug:132173. This is better for a11y reasons (colour blindness).
    • Audio feedback - gnomebug:155561 requests this.

Attic/UsabilityProject/Whiteboard/TabImplementation/TabAppearance (last edited 2014-07-10 23:07:15 by AllanDay)