[sugar] Icon/Menu bars (Was Re: Review of Build 539, firmware Q2C18)
Mike C. Fletcher
Mon Sep 3 18:11:26 EDT 2007
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
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
* 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,
* 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.
Mike C. Fletcher
Designer, VR Plumber, Coder
More information about the Sugar-devel