[sugar] Icon/Menu bars (Was Re: Review of Build 539, firmware Q2C18)

[Eben Eliason]

I actually do work on the design team, and these comments are much
appreciated.  I'll give a little feedback on the direction we're
aiming for, and perhaps more discussion will follow.

> I'm just replying to a segment here.  I should note that I don't work as
> a designer for OLPC, so these comments are just from "some guy", though
> my academic background includes design epistemology, interface and
> narrative design, and perceptual psychology.
> ...
> > The Journal was my first experience of the new Sugar interface menus,
> > and -- I have to confess -- wasn't a positive one.  I loved the
> > simplicity of the early Sugar interface.  Now, I see an aberration in
> > the history of Interface Design: options split by tabs.  By tabs!  I
> > don't have screenshots, but use your memory.  The Abiword of the 400
> > series had a beautiful, simple interface.  The Abiword of build 539 is
> > a mess, complicated by a clunky, unintuitive interface.  Even the
> > Open/Save buttons are gone now, and it does feel clunky and confusing.
> >  Yes, it now allows space for tables and, yes, it now has these handy
> > mesh activity options, but I do not think the overall effect is well
> > conceived.
> >
> I would loosely concur, not necessarily with "it was better before", as
> the previous versions had far less exposed functionality, but the
> current menus-as-toolbars effect still needs a bit of refinement.  Many
> menu tasks require two full cross-screen seeks to non-edge components
> (i.e. careful seeks, because the motion is cross-screen, the fact that
> the icon bar touches the screen-top doesn't assist in seeking, you can't
> "throw" the cursor without doing a "v" shaped throw).

I'd argue that "many menu tasks" should instead be "many secondary
menu tasks", as the main purpose of the toolbar design is to surface
as many first-order controls as possible, while logically grouping any
related secondary controls or parameters with those particular
buttons.  As such the "copy" button has a "copy and erase" (cut)
secondary option.  A paintbrush tool will have a palette containing
brush size, shape, flow parameters, etc.  Full use of the interface
should be possible without even knowing the secondary menus exist.

Additionally, I'd argue that placement of the tabs at the top of the
screen does in fact assist in seeking.  Perhaps you can't throw the
mouse directly to the element you care about, but once within the
toolbar it's easy to seek back and forth without accidentally exiting
the toolbar, and once you choose a button to press, even the edge-most
pixel will respond to the click.

> There is also little visual to bind the "tabs" bar with the icon bar
> above it (beyond continuity of "background colour"), so there's no
> visual clue that choosing a tab changes the icon bar.  The tabs are
> rather minimalist and text-based, not particularly looking like icons or
> anything that has anything to do with them, I did not initially
> recognize them as something I could click until I happened to
> accidentally click one.
>
> Minimal design suggestions to address some of that issue:
>
>     * instead of using simple boxes for the tabs, use trapezoids which
>       connect up into the background colour of the button bar.  This is
>       using the "office-ish" metaphor of tabs, but it is a fairly simple
>       physical metaphor, there are things that stick out of the "stack"
>       of things in the area, clicking on one of those things brings that
>       level of the stack to the front.
>     * add a border that surrounds the toolbar and the current tab (yes,
>       I know the aesthetic has rejected borders)
>     * add icons to the tabs (almost everything else that is clickable is
>       icon-based and we do have some pre-literate users)
>     * use a hover style to make the tabs inform the user that they are
>       clickable icons when the mouse moves over them

First, a note on the design.  Frequently tabs appear above the "stack"
which they are part of.  We specifically did the opposite in order to
place the toolbar buttons themselves across the edge of the screen,
since the buttons are the primary functionality and will be used most
frequently.

I think adding a border is a reasonable option to try.  We do have
borders throughout much of the UI actually, and this is a logical
place for one.  We've also been considering adding icons to these
tabs; in fact, it's part of the specification for the control.  We've
just had many other things to deal with in the meantime and haven't
had time to play with it yet.  With our strong emphasis on iconic
forms, this is definitely something to try.

> ...
> > My first suggestion is to get rid of the close button, which is placed
> > in the activity tab.  Have kids use the keyboard instead by making the
> > close key there (Esc key on a normal keyboard) actually do something
> > and close any of the Sugarized applications.  That's one less button
> > to worry about.  It's pretty annoying when you are working in an
> > application, say the browser, and when you want to exit it, you need
> > to switch to the activity tab to access the close button.  Not a good
> > approach to interactive design, in my opinion.
> >
> Getting rid of the most commonly needed button altogether is probably
> *not* a good idea.  Note how every previous WIMP design has reserved a
> space on each window for (at least one) button for closing the window.
> There's a psychological reason for that, it's a way to say "hey, get me
> out of here" that's always available to the user.  In most OS's I know
> of, that button is normally drawn by the window manager, so that even a
> poorly behaving windows can be killed.  You want something *always
> visible* that lets the user leave.

Right, this is something that we feel does need to be there on the
experience level.  In earlier versions of the software the close
button lived outside the activity (in the frame) and was hard for
people to find, which became apparent rather quickly as the close
button is something everyone (who is used to using computers, of
course) expects to find and many who are testing the software out will
want often.

We were faced with a dilemma about what to do with this button, since
a) every activity runs fullscreen by default and b) we didn't want to
waste extra screen real estate for a "header."

> The current situation, however, is about as bad as you can get.  The X
> button is normally on the right of the screen, so this extremely common
> task requires a seek to the left to hit a small button (the tab), a
> visual search for the close button in this activity, then a seek all the
> way across the screen to hit the X now found.

This is true.  This was actually considered (perhaps incorrectly, but
please give feedback).  We wanted this "destructive" task to be
something that couldn't happen accidentally, which is why it takes an
extra "seek" across the bar.  More importantly, however, we didn't
necessarily want the close button in the activity to be the sole means
of closing.  The home screen serves as an activity manager, so to
speak, offering an overview of all the running activities, the active
one, and how much memory each is consuming (as the RAM is rather low).
 The activities can be closed from here via their rollover palette as
well.

> Minimal suggestions to address this:
>
>     * put the activity operations directly on the menu bar (i.e. have a
>       "close" and "share" button right in the menu-set) *or*

I'm not sure I understand what you mean by this; could you clarify?

>     * make small set of standard operations always available on a
>       reserved portion of each icon-bar (this has space-on-the-toolbar
>       implications)

Indeed, this could get crowded fast, but we have considered the idea.

>     * advertise keyboard shortcuts and provide keyboard shortcuts for
>       each menu and option in the menu (reference Alt-F-O on
>       Windows/Linux desktops to invoke "open")

Keyboard shortcuts are not yet indicated at all in the UI, but we
intend to make strong use of them in the future.  The shortcut for an
icon button in the toolbar will appear next to its title (in the
primary rollover) and the shortcut for secondary functions will appear
as in menus we're familiar with.

> > I also suggest making the activity not the default tab.  Yeah, the
> > meshing activities are a vital part of the system, but are they more
> > important than basic operations like Open/Save?  I don't think so.
> > Make it non-default and push it to the far right, so it will be in the
> > same location on every application.
> >
> Here we just seem to be having problems with the fact that we have
> turned the icon-bar, which is normally used for a very small number of
> high-usage items, into a menu-bar, into which we are putting all
> possible options.  The activity sub-set of actions is large enough to
> crowd out the options on a regular icon bar, so it winds up needing its
> own "menu", and since it's "top level" people are seeing it as the
> logical choice for a first menu.  Problem is, other than "close" and
> maybe "share", it's not particularly the *first* thing people want to do
> with an activity, so, e.g. every time you open the browse activity you
> wind up having to seek to the "browse"  menu, potentially after having
> mistakenly typed your URL into the activity-name field.
>
> I would concur that the activity should be designating a default
> icon-bar and would guess that for most activities this should not be the
> "activity" bar.  See above for suggestions on having the high-usage
> items always available so that the activity bar is likely not that default.

This is already accounted for in the design, as we quickly became
aware that the activity tab was confusing as the point of departure
inside every activity.  The reason we initially made that decision, of
course, was to encourage naming of activities, since the auto-saving
feature results in countless "Paint activity" entries in the Journal.
That was a well founded fear, as I'm sure you've noticed if you've
looked at the Journal, but it's one we're going to have to solve
another way it seems.

We've already added support for allowing an activity to specify the
active tab, and will place this in the guidelines as something that's
recommended when the activity initializes, so that the "default" tab
is focused appropriately.

> > Finally distribute the remaining buttons not by topic, but by
> > importance.  For instance, in Abiword the children will rarely use the
> > table functions or insert images.  While distributing options by topic
> > may at first seem logic, it makes a bad experience interactive-wise,
> > as children will have to move from tab to tab frequently.

This is only partially true, actually.  The design of the toolbars
particularly caters to grouping controls by "context", such that the
toolbar for the current editing context will be automatically focused
when that context is active.  Considering write, for instance, if I
click no a table, the table toolbar would be focused automatically.
Likewise if I click on an image.  Of course, anytime I place my cursor
within the text the text toolbar would refocus.  In the end, the hope
for tabs is that they actually need to be switched very infrequently
(in many cases, only when "inserting" the table or image or object
which provides the context to later be selected).

> Here I'm not *necessarily* in accord.  There are two major approaches to
> designing "rich" interfaces (those which include large numbers of tools).
>
> In the first, you look at how power users work with the interface and
> attempt to streamline the interface for their usage.  Maya's (3D
> Modeller) original interface or Adobe's suite of graphics applications
> follow this approach (thinking of Maya 1 and Photoshop 6).  It works
> well if you are using the application all day every day, but it creates
> a high barrier to entry for the casual user or the user that doesn't
> happen to use the application in the patterns of those in the focus
> group (where's this, oh, why's it way over there, it should be next to
> this almost identical thing over here?)
>
> The other approach is to use logical grouping and organization.  3DSMax
> and the Corel suite of graphics applications follow this approach
> (thinking of versions 3 and 7 respectively).  It works well for allowing
> casual users to find something, though they often have to make a few
> extra clicks to find it.  By learning a few simple rules and scanning
> for a few seconds they can find what they want.  While not as efficient
> at the lowest level, it tends to reduce situations where users just get
> "lost" (I want to insert a table, that's really important, because I use
> tables all the time, so it should be in the "most important" tab, but
> it's not there.  What do you mean it's on the "least important" tab, why
> would it be there?)

> Each approach has its benefit and it's mostly a matter of the audience
> as to which you follow.  Of course, both approaches work better if you
> let the user customise the layout to suit their needs.
>
> Suggestions to improve this:
>
>     * provide easy customisation tools that allow children to rework the
>       menus/toolbars in the activities (requires cross-activity
>       discipline, and results in non-trivial implementation cost,
>       unfortunately)

This is hard, indeed, but it could be useful.

>     * provide (advertised (i.e. in pop-ups, underlined text)) keyboard
>       shortcuts for all menus/toolbars and their tools so that
>       cross-screen seeks can be reduced and switching between toolbars
>       can be done with a keyboard shortcut

This we absolutely want to do.  Of course, the context switching
mentioned above should go a long way to making this unnecessary
anyway.

> > With less tabs cluttering the interface it will be easier to make it
> > simple and beautiful again.  Maybe even go as far as get rid of the
> > tab bar, and put those options on the button bar, where they will
> > collapse right and left according to where the user clicks.  Nifty
> > effect that may be.  It would please the children and make the
> > interface that much less cluttered.
> >
> The problem being that e.g. Write has *6* menus, so 1/3 of the toolbar
> (with current sizing) would be taken up with the toolbar-choice-buttons,
> which would mean each toolbar would have to be smaller (fewer tools),
> meaning more toolbars... you get the picture.  You could do it with
> smaller (say 1/2-width) icons, but the seek-position for those icons
> will change every time you click one (going to the other side of the
> screen), so you no longer have a consistent set of actions to reach any
> given tool (same problem as is seen with "shutter" controls everywhere,
> which appears to be the reason tab-based controls have become the
> preferred approach to these kinds of interfaces).

Indeed, we tried for quite a while to limit functionality to a single
toolbar, for reasons similar to those you bring up, with simplicity
being the primary driver.  Ufortunately, it was just too limiting in
practice, especially considering the "low floor, no ceiling" model
we've been aiming for.  With only one toolbar, more and more got
buried, and as Mike mentioned above, the decision about which tools
were "important enough" to be surfaced isn't an agreeable one by all.

> > Back on Abiword issues, whatever happened to the Open/Save buttons?  I
> > am now forced to use the keyboard (Ctrl+O and Crtl+S) to access these
> > features.  Nothing wrong with using the keyboard, but how are the
> > children going to find out the shortcut keys?
> >
> As agreed above, advertising the keyboard shortcuts is probably a strong
> requirement for usability.  Every toolbar-tab and tool likely needs to
> have a keyboard accelerator sequence that is advertised.

Indeed.  It's on the way.

Thanks for all the feedback!  I hope this sheds a little more light on
some of our ideas.  Please feel free to provide additional concerns as
they come up, or further comments on what I've discussed above.

- Eben