Sugar UI design and Tux Paint

[Jameson "Chema" Quinn]

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


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

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


Actually, as far as I can see, it's more case-by-case. 'Paint' has limited
selection possibilities, and most of the verbs are pretty commutative and
associative, so my model is simple. A more full-featured photo editor has
much trickier forms of selection; and a more full-featured vector editor
like Inkscape has some verbs which are neither commutative nor associative,
and some which can only act on different classes of objects (shapes, paths,
bezier points, or text).

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


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

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.

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

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

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.

Jameson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080102/75fd45b3/attachment.html>