Sugar UI design and Tux Paint

[Eben Eliason]

> > 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.
>
> This problem suffers not from too few solutions, but too many. Right clicks,
> tool settings menus (from the tool or using a right click on the canvas),
> little indicators in the corner of the tool pointer, modifier keys, and
> doing compound actions part-by-part: these are all possibilities. Of course
> there are disadvantages, too: obscurity (hard to 'discover'), complication,
> limitations. I think that the best solution will end up being some judicious
> combination.
>
> A good interface would have a variety of selection styles - lasso, marquee,
> fill ('magic lasso'), as well as add/subtract(/xor?) for all of the above.
> This should be indicated in the pointer, and accessible using sticky
> keyboard modifiers (I think all keyboard modifiers should be sticky for the
> duration of one complete action), right-click context menus within the
> canvass, or hover menus on the tool itself. Note that the possibility of a
> compound selection means deviating from the verb-object model (choose tool -
> construct selection - computer processes result and begins to blink result -
> press enter or choose other tool to apply result).

This is somewhat true.  To argue semantics a bit, I'd say that in the
Paint case we're talking about a selection as an object itself, since
is (or often is) largely independent of the underlying image.  From
that perspective, each successive modification with any form of
selection tool modifies the selection object, and then another set of
tools operates on the pair of the selection object and the image to
create meaningful changes to the painting.

> > fact, in most SVG editors, the transform 'tool' is implicitly
> > available when an object is selected.
>
> For simple translations or orthogonal dilations - but not rotations or
> skews.

True, but there's nothing limiting one from adding these if the
"handles" can be intuitively represented on screen in a reasonable
way.

> > 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.
> >
> >
>
> Granted, and laudible. But I doubt they can be avoided altogether, even if
> you end up calling them something else. An email program, for instance, will
> always need its account settings... and yet you will not want the controls
> for that to be everpresent on the screen.

Quite true.  I think we'll probably introduce a form of fullscreen
"modal dialog" for such a thing.  That is, you press an "account
settings" button and get a fullscreen overlay containing all of the
necessary settings, hiding the rest of the interface, including the
toolbar itself, to focus the child on the task at hand and eliminate
the presence of temporarily insensitive controls which don't respond
and keeping this preferences screen independent from the persistent
interface of the activity itself.

> > 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.
> >
> >
>
> 'Special functions relevant to the current activity' is fancy talk for
> 'ad-hoc and obscure'. Some consistency is necessary - even if it's just
> cell-phone-like, with an indicator of what the buttons do when you press
> them (a little picture of the four buttons with meaningful text and icons
> next to them) which shows up in the corner next to them for a short time
> whenever you press one.

Absolutely.  I wouldn't think of advocating this without a simple and
consistent way to view the mapping for the current activity, in some
form or another.

> I would still advocate for a more comprehensive plan, like the one I began
> to sketch out in the original message included above. It puts the load on
> Sugar itself, instead of on the programmer of each individual acivity - an
> obvious advantage.

This isn't necessarily so straightforward.  For instance, in the
Record activity the thing you really want to do most is [take a
picture]. In browse, you probably want a [follow link/forward] and
[back] buttons.  In a game of tic-tac-toe you need a [play piece]
button.  I don't think there is a very good generic solution to the
Handheld mode buttons, and therefore hope to focus on a consistent
system by which activities can identify and map these buttons to a
core set of functions relevant to the activity.

As far as defaults, we chose some basics like page up/down, enter, and
tab to make basic navigation of web pages and books more natural in
the early iterations, so that e-book style interaction would be
somewhat practical.

- Eben