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

[Eben Eliason]

On Tue, Mar 25, 2008 at 12:41 PM, Gary C Martin <gary at garycmartin.com> wrote:
> On 25 Mar 2008, at 15:47, Eben Eliason wrote:
>  > 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:
>
>  Yes, I do like the idea a lot.
>
>  The main issue I see not covered in your list (and it's quite a
>  whopper), is that the extra tool-bar strip shifts the top of the main
>  activity canvas down, resizing it in the process. Problems:
>
>  1) As you mouse over, the main canvas content will jerk up and down
>  like a pneumatic road drill.

This is a valid point, and one that does indeed pose some technical
challenges, as there doesn't really seem to be any reasonable way
around it in the design.  It is, technically, the problem which by
definition this design creates by attempting to use screen space only
when necessary.

I see one possible tweak to the design which could minimize the
invasiveness of this dilemma.  Consider
http://wiki.laptop.org/go/Designs/Toolbars#06.  In this slide, we see
the toolbar in a "preview" mode; it hasn't yet been locked into place
by clicking on the toolbar button.  I have two things to say about
this mode, the first of which was initially intended but not made
evident, and the second which addresses your concern to some extent:

1. While in this preview mode, the toolbar and it's elements will
remain fully operational, as though this toolbar were simply a
palette.  (In fact, it's design, in black, helps to indicate this
relationship.  This means that, should I desire to copy something, I
could reveal the preview of the edit toolbar, move to the copy button,
click it, and then go back to working without ever toggling to toolbar
on.  Once the cursor left the toolbar area, the preview would go away.

2.  It almost comes naturally from outlining the above idea that the
toolbar *should* be overlaid above the canvas while in preview mode.
Only when locking it into place as a permanent fixture of the UI would
it turn toolbar-gray and shift the content of the activity.  While not
solving the technical problems that go along with reflowing the UI, it
would prevent the "jackhammer" effect you mention, instead only
causing layout changes upon explicit click.

>  2) The window resize is going to trigger the contained widgets to
>  redraw/re-scale/re-align. This may be fine for a trivial activity with
>  minimal UI complexity, but if any of those widgets require some
>  processing to regenerate their visual appearance or content flow...
>  ouch.

Following the above approach, we can minimize the hit this causes.

>  3) Activity developers should already be using flexible layouts to
>  cope with potential screen rotations, however the added potential for
>  a reduction in main canvas size will add to the UI design/testing
>  complexity, with designers making a little less use of the space by
>  default so they leave some vertical space to prevent things getting
>  cropped.

Here I'd have to say that, despite the knowledge that all activities
will run fullscreen, we should try to avoid developing to a particular
piece of hardware (and it's resolution).  Most applications out there
in general are designed to support natural reflow of UI elements based
upon the window size.  We too should aim, in general, to produce GUIs
this robust, in which case the change shouldn't be much of a problem.
In the worst case, some activities which have particular needs can
surmount this by rendering their "static" area in a larger region with
40px of padding at top and bottom, though I suspect (and hope) that
most won't have to resort to such a tactic.

- Eben