Sugar UI design and Tux Paint

[Eben Eliason]

> Sugar entails a complete redesign of some basic UI concepts, so I thought a
> thread on how to rethink applications to take advantage would be
> appropriate.
>
> One thing I've noticed in Paint is that an Edit toolbar is far less
> useful than an Edit menu. You want to copy something - you go to the edit
> toolbar - you select the copy 'tool' - and nothing happens, because you
> don't have anything selected. So how do you select something? Oh, that tool
> is over in some other toolbar.

That's a tricky thing, and I agree with you.  The toolbar saves some
screen real estate at the expense of omitting an ever-present menu.
Now, I would argue that there are two other much faster ways to copy
things anyway:  by keyboard shortcut, and by drag'n'drop.  The latter
of these is direct and natural; the former is obviously the fastest
solution for "advanced" kids.  The presence of these buttons in the
edit toolbar is there almost as a teaching tool, since it will show
you that you can copy/paste, and indicate the shortcuts for those
commands.  We always want there to be a simple and consistent way to
do things that's naturally discoverable.

> There are various possible solutions. In order from smallest to largest
> changes:
>
> 1. Move the select tool onto the Edit toolbar, or put it in both places.
> 2. Automatically change to the select tool for as long as you're using the
> edit toolbar.
> 3. Move from an select - action (object - verb) metaphor to an action -
> select (verb - object) metaphor. In other words, have a 'copy tool' which is
> just a select tool which copies as soon as you let up the mouse. In a larger
> graphics program, like Inkscape, this would mean a separate selection tool
> for every possible transformation, and some sort of UI 'pronoun' idiom (a
> graphical menu on the side? Or a dropdown from the tool?) for reselecting a
> recent selection set, for when you want to do various transformations on the
> same set of objects.

All of these are valid suggestions.  The drawback to all is that they
make assumptions about the types of selections that can be made (More
specifically, they don't allow for compound boolean selections).
Perhaps that's not something many (any?) kids will want or need, but
we have to observe the limitations that come with decisions we make.
Actually, the 3rd is the only one which strictly limits this.  I'd
lean to 1 or 2 myself, which would allow a complex compound selection
to be made should a child desire one, and then offer a subset of
selection tools to modify or change the selection with the toolbar
visible.

> Idea number 3 is more radical, but I would be inclined towards it. I
> understand that for text, when the mouse is ALWAYS the selection tool, the
> current object-verb metaphor is best - but for graphics, it's actually more
> steps to get select tool, select, then transform, than it would be to get
> transform tool then select. For a kid who's in the see-what-it-does
> mentality, I feel verb-object is more direct too.

I like your way of thinking, but I'm again unsure if it covers the
possibilities.  Perhaps there is a circle in my drawing that I want to
make larger.  With the object-verb model I can perform a "fill
selection" (click inside the circle to select all it's pixels) instead
of a rectangular one, and then click the transform tool.  If the
selection was part of the transform tool, I wouldn't be able to
specify how to make the selection I need.  Of course, we're really
talking about special cases of bitmap graphics, as with vector
graphics, the model you speak of makes more sense, which the objects
are truly discrete objects, and not part of a flattened whole.  In
fact, in most SVG editors, the transform 'tool' is implicitly
available when an object is selected.

> Some more random sugar-related UI ideas:
>
> -- Obviously, the 'preferences dialog box' becomes the 'preferences screen',
> to be selected via the toolbar tabs, as if it were a toolbar.

I'm not sure this is necessarily obvious.  The tabs should really be
defining sets of tools, and not separate screens when at all possible.
 Moreover, the design of palettes bears preferences in mind, with the
intent that the secondary palette be used to provide contextual
preferences for the specific control.  In this manner, preferences
and/or parameters of the brush tool can appear in its secondary
palette.  We're steering away from global preferences as much as
possible.

> -- The current Sugar spec on the wiki says almost nothing about the game
> buttons - a good interface should allow give a consistent way for you to
> select any control or menu, including contextual menus, using just these
> buttons. As it is, the directional rocker is just useful for moving around
> inside text, and the four shape buttons seem to move around rather than
> doing actions or changing modes (X=select, O=context menu, square=toggle
> focus from main window/toolbar/frame, which leaves check free as a modifier
> key to use as shift with the arrow buttons... but that would be another
> thread)

Actually, while the HIG doesn't have too much to say on this yet, it
does outline clearly that the UI will transition to fullscreen (no
toolbars) when in Handheld mode, and the cursor itself will be hidden
by default.  The shape buttons will then be assigned special functions
relevant to the current activity, providing a limited but tailored set
of functions for the current activity.  The spec for Browse on the
wiki outlines in detail how this could work.

> -- The clipboard stack should show the first few characters of a text
> fragment in the frame

Absolutely.  Images, videos, sounds, and other media types should have
previews as well, and even where there is no preview available, there
should be a way to find out where the clipping came from.  This is
outlined in the spec for the Clipboard on the Specifications page of
the wiki.

> Happy new year,

LIkewise!

- Eben