[sugar] Mini-Conference Proposal: Toolbars & Tabs (or lack thereof)

[Eben Eliason]

A lot of thought has gone into the present tabbed toolbar design, with
goals of balancing valuable screen real estate with extensibility of
the design.  Still, we've come to find some drawbacks with the current
design, including the sole use of text (which is secondary to icons in
the rest of the UI), the smaller height of the buttons which can make
them harder for children to click on, and the fact that, despite the
smaller height which was designed to save screen real estate, many
activities with few tabs may find them to be wasteful of space.

Taking these concerns to heart, I'd like to propose an alternate to
the tabbed toolbar design which attempts to address these new concerns
with the current design, again making some tradeoffs but hopefully
coming out on top in the end.  The core component of the new approach
is the introduction of the "toolbar button", which you can see mockups
of at http://wiki.laptop.org/go/Designs/Toolbars.  There is no text
with the mockups yet, but I'll add it later.  In the meantime, please
consider the following advantages:

1. Toolbar buttons use icons instead of text as an identifier.  Beyond
the icon, we depend on the content of the toolbar to help define the
tab, with a textual name being superfluous.  This makes localization
easier (well, free) and prevents text from being cut off in due to
translation. Toolbar buttons will reveal their toolbars temporarily on
rollover, as palettes do, allowing one to preview the content of a
toolbar without toggling it on, for discovery.  OLPC will include
icons for a handful of common secondary toolbars in artwork for
developers to use.

2. Toolbar buttons are the size and shape of other buttons in the UI,
giving them a larger target area and making them easier to click on.

3. Rather than residing in a secondary region solely for tabs, toolbar
buttons are first class citizens in toolbars; when clicked, they
reveal a second tier toolbar beneath the first, visually attached to
the toolbar button.  For activities that have few toolbars, this
offers the advantage of providing space for a "basic control set" in
the main toolbar, in addition to several auxiliary toolbars which can
be shown in conjunction with the primary toolbar, only when needed.

4. When a given activity needs only a few toolbars, this design saves
screen space during normal use of the activity.  A good example is
Browse, which needs some basic edit and view controls to remain
available, but certainly not at all times during normal use.  Here we
save space for the content by eliminating the "tab bar".  This is a
tradeoff, though: advanced activities with many tabs may require the
primary toolbar to contain solely toolbar buttons, with the second
tier toolbar becoming the place where all the actual controls live.
In these cases, we lose a small amount of screen space (30px,
vertically, to be exact).

5. As a slight upside to the aforementioned tradeoff, the iconic
design of the toolbar buttons allows for up to twice as many toolbars
as the previous design, providing more extensibility in activities
that really need the space.  Naturally, we expect the majority of
activities to be in the class which actually benefits from (4), having
only a few toolbars, and the HIG will still recommend against bloat.
Nonetheless, we think that the added extensibility is a plus.

As this is an issue that effects every developer, I think that the
mini-conference provides a fine opportunity to expose these ideas and
discuss the pros and cons of the approach to come to a final decision
on our direction.  Thanks!

- Eben