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

[Mike C. Fletcher]

Ivo Emanuel Gon?alves wrote:
> Warning: This is long.
>   
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).

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

...
> 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.

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.

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*
    * make small set of standard operations always available on a
      reserved portion of each icon-bar (this has space-on-the-toolbar
      implications)
    * 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")

> 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.
> 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.
>   
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)
    * 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

> 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).
...
> 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.

Take care,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com