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

[Nate Ridderman]

Eben,

By no means do I consider myself a user interface expert, but I have a few
comments.

In general, I agree that this proposal is better for localization and may
take up less screen real estate. Would there still be default buttons to
share, keep, and/or stop the activity? I believe it's important to have an
easy way to stop the current activity, but maybe you have this accounted for
elsewhere in the frame redesign. I haven't had a chance to build and test
Tomeu's branches yet. It looked like activities could be stopped from the
frame, but no preference was given to the current activity.  I'm not sure if
this is convenient enough. If a stop button is required, and perhaps a share
button and a keep button, this will eat up space and require most activities
to use a secondary toolbar.

Another concern would be porting an activity like Calculate that has
numerous tabs of text based buttons. It's reasonable to create graphical
icons for the tabs (Edit, Algebra, Trig, Booleans, Constants, Format) but
not for some of the actual buttons (sin, cos, tan, asin, acos, atan, sinh,
cosh, tanh) Are you proposing that all text should be removed from the
toolbar or is it acceptable to have some text based icons? If text based
icons are allowed, do we need the option of localizing them? I'm not sure,
for example, how trigonometric functions are represented in other languages.

Finally, this requires someone with good graphical design skills to create
icons for complex activities that can't just reuse the template icons. My
point is that it's easy for programmers to create text based buttons, but
graphical ones will require more (and a different kind of) work.

Thanks,
Nate

On Tue, Mar 25, 2008 at 10:47 AM, Eben Eliason <eben.eliason at gmail.com>
wrote:

> 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
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080325/c3f0e80f/attachment.html>