Re: Sugar UI design and Tux Paint

[Eben Eliason]

> Agreed. I said, 'sometimes'. I think that it is better to stay non-modal if
> possible. (For the last of your cases, changes to activity structure, eg
> email settings or ftp server or something, an autosaving
> dropdown/autocomplete list of previously-used settings is a way to provide
> undo without overloading the 'undo' command. Invasive changes to the
> interface should not be opaque - there should be some visible way to realize
> what is going on, or even a cue to changing the preferences back. And as for
> nontrivial computation, it is at least theoretically possible to save the
> settings in real time but apply them later. So I think that the
> modal-necessary cases still exist, but are rare exceptions.)

Indeed; this is why we have thus far implemented only the non-modal
version.  Particular instances have come up within Sugar that will
require modal dialogs, though.  Certainly the HIG will encourage
non-modal ones when possible.

> > I only provided one or two, but I imagine that most activities will
> > use them all.  Read my proposal for Handheld mode in Browse for a more
> > complete understanding of the type of interface I was envisioning:
> > http://wiki.laptop.org/go/Browse#Handheld_Mode.  In this paradigm, the
> > buttons retain their pairings when needed, and they can have both
> > instant and hold states (as modifiers which reveal an overlay menu
> > which can be navigated via the directional buttons).
>
> A lot of good ideas there, of course. I think we can come to a good
> compromise between my issues (more across-activity-consistency and
> complete-access, including sugar) and yours (in-activity applicability and
> usability).
>
> One basic idea of yours is to double the buttons by providing both press
> functionality and hold functionality (with hold often a context menu related
> to press). That is obviously applicable in my scheme too.
>
>  With this in mind, here's a look at your browse scheme vs. mine applied to
> browsing.

As a note, one thought behind the hold state for the buttons was that
it offers additional functionality on top of the basic set of actions
which is secondary, and therefore not necessary for the use of the
activity in simple form.  I'd like to keep this idea, never requiring
the hold states to be used unless the child wants extra power within
handheld mode.

> up/down/left/right: you scroll with up/down and select links with
> left/right; I select links with both. But notice that the two are not
> actually as seperate as it would appear. Selecting links can cause scrolling
> and vice versa. So in my scheme, a click selects links. If that is a small
> distance vertically, then a hold would be ONE page down/up; if it is a
> larger distance (maximum one page), then a hold would be continuous finer
> scrolling. (side to side would wrap, and a hold would scroll)

I'm not sure I'm properly envisioning what you mean here.  There seem
to be a number of ways to move about the page (scroll, page,
jump-by-link), and there doesn't seem to be a predictable mapping of
button to function in this model.  If I want to scroll down a few
pixels little to fit an image on screen, I have to hope that the links
are far apart.  If I want to jump through a bunch of links in a long
list quickly, I can't, because the hold state of the links button is a
paging function, rather than an autorepeat on the "next-link" action.
If I want to simply read a wikipedia article and completely ignore the
links, I can't, because there is no guaranteed way to simply page-down
at any given point.

On the other hand, by using up/down for page-up/page-down on press,
and smooth scrolling on hold, I can always move by a chunk or a small
amount from anywhere.  By assigning left and right to
next-link/prev-link, I can separate my browsing of the page from the
arbitrary link layout and do just what I want, and I can use the
autorepeat on the link selectors to quickly jump through a bunch of
links to the one I want.

> select link: you have that as east, I'd use north (select control). Same
> functionality.

We chose to use E for a main action/select button due to the check
mark on the button, which maps to the check on the enter key.

> TOC: you have that as east hold, I'd have it in repeated east hold (see
> below).

Note that in my mapping, the TOC (list of all available links) relates
directly to to the primary press function (select-link), in that it
offers a list of all the possible links one could select.

> back(/switch tabs nav overlay on hold): you have west, I'd have south
> (app-defined). Same functionality.

Also, note that mappings of such pairs often make sense in a
particular axis.  I made forward/back E/W since this mirrors the
buttons for the same purpose in the toolbar.  Volume up/down keys
(consider a media player) would make more sense being N/S, while ff
and rew make more sense as E/W.  I think that these intuitive
directional mappings would make the handheld controls easier to
manage.

Re: Sugar UI design and Tux Paint

[Jameson "Chema" Quinn]

On Jan 2, 2008 5:35 PM, Eben Eliason <[EMAIL PROTECTED]> wrote:

> > > 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.
> >
> > The whole point of a modal dialog box is that there are only 2 ways out,
> OK
> > and Cancel. This lets the program not apply the changes until you press
> OK -
> > like the 'save' command. But there is always another way out - killing
> the
> > activity from the user view. Sometimes it would be more kid-friendly to
> keep
> > changes as soon as they happen. If we do this, there's no reason to hide
> the
> > frame.
>
> That's a good point.  Here again, though, changing some preferences
> may result in more invasive changes to the interface, non-trivial
> computation to apply, or changes to the structure of the activity in
> such a way that they aren't undoable.  All of these things are reasons
> that an activity may want a strictly modal interface.


Agreed. I said, 'sometimes'. I think that it is better to stay non-modal if
possible. (For the last of your cases, changes to activity structure, eg
email settings or ftp server or something, an autosaving
dropdown/autocomplete list of previously-used settings is a way to provide
undo without overloading the 'undo' command. Invasive changes to the
interface should not be opaque - there should be some visible way to realize
what is going on, or even a cue to changing the preferences back. And as for
nontrivial computation, it is at least theoretically possible to save the
settings in real time but apply them later. So I think that the
modal-necessary cases still exist, but are rare exceptions.)

>
>
> > > > > 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.
> > >
> > >
> >
> > Oh yeah? So where's the spec? Or do you want me to write one?
>
> There is no spec yet.  There is a ticket outlining some thoughts on
> the subject: http://dev.laptop.org/ticket/1310


Interesting - you're considering taking over the rotate key...


>
> > > 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.
> > >
> >
> > Your examples all give one or two default actions. I think this will be
> > typical. Also note that the only case with two - Browse - the two
> actions
> > can be thought of as movement in opposite directions along the same
> axis.
> > (The exception to my rule would be a media player, which wants 3: ff,
> rev,
> > and play/stop)
>
> I only provided one or two, but I imagine that most activities will
> use them all.  Read my proposal for Handheld mode in Browse for a more
> complete understanding of the type of interface I was envisioning:
> http://wiki.laptop.org/go/Browse#Handheld_Mode.  In this paradigm, the
> buttons retain their pairings when needed, and they can have both
> instant and hold states (as modifiers which reveal an overlay menu
> which can be navigated via the directional buttons).


A lot of good 

Re: Sugar UI design and Tux Paint

[Eben Eliason]

> > 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.
>
> The whole point of a modal dialog box is that there are only 2 ways out, OK
> and Cancel. This lets the program not apply the changes until you press OK -
> like the 'save' command. But there is always another way out - killing the
> activity from the user view. Sometimes it would be more kid-friendly to keep
> changes as soon as they happen. If we do this, there's no reason to hide the
> frame.

That's a good point.  Here again, though, changing some preferences
may result in more invasive changes to the interface, non-trivial
computation to apply, or changes to the structure of the activity in
such a way that they aren't undoable.  All of these things are reasons
that an activity may want a strictly modal interface.

> > > > 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.
> >
> >
>
> Oh yeah? So where's the spec? Or do you want me to write one?

There is no spec yet.  There is a ticket outlining some thoughts on
the subject: http://dev.laptop.org/ticket/1310

> > 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.
> >
>
> Your examples all give one or two default actions. I think this will be
> typical. Also note that the only case with two - Browse - the two actions
> can be thought of as movement in opposite directions along the same axis.
> (The exception to my rule would be a media player, which wants 3: ff, rev,
> and play/stop)

I only provided one or two, but I imagine that most activities will
use them all.  Read my proposal for Handheld mode in Browse for a more
complete understanding of the type of interface I was envisioning:
http://wiki.laptop.org/go/Browse#Handheld_Mode.  In this paradigm, the
buttons retain their pairings when needed, and they can have both
instant and hold states (as modifiers which reveal an overlay menu
which can be navigated via the directional buttons).

> In order to use a set of controls efficiently, I think it takes about 7
> buttons. Aside from the main 'do it' button, there are 6 for navigation: the
> four physical directions and two more directions (in and out) to let you get
> context menus ('in'), jump out of text fields ('out'), and get out to the
> toolbar and frame. (I know, you want to hide the toolbar by default. But
> there's no reason it shouldn't be accessible.)
>
> That means that there's enough buttons for generalized navigation and ONE
> activity-related button. It would be nice to have another sometimes but it
> is enough. The special button can be 'back' for the browser, 'ff'
> (toggleable using controls to 'rev') for a media player, 'take picture' for
> the camera, etc. The nav arrows turn pages in a book reader, or, if you
> REALLY need scrolling, you just have to give up on a dedicated turn
> backwards button.

I think offering only one button to the activity is extremely
limiting.  I personally think it would be better to allow activities
to cater to Handheld mode by providi

Re: Sugar UI design and Tux Paint

[Jameson "Chema" Quinn]

On Jan 2, 2008 2:17 PM, Eben Eliason <[EMAIL PROTECTED]> wrote:

> 
>

 ... discussion running on... the next step is example code... not gonna do
it next.


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


The whole point of a modal dialog box is that there are only 2 ways out, OK
and Cancel. This lets the program not apply the changes until you press OK -
like the 'save' command. But there is always another way out - killing the
activity from the user view. Sometimes it would be more kid-friendly to keep
changes as soon as they happen. If we do this, there's no reason to hide the
frame.

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

Oh yeah? So where's the spec? Or do you want me to write one?

(Sorry, I don't mean to imply that everything should be perfectly complete.
It is fine to have places in the HIG that say 'we're still writing the spec
for this'. But there should be some indication of how the thinking is
going.)

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

Your examples all give one or two default actions. I think this will be
typical. Also note that the only case with two - Browse - the two actions
can be thought of as movement in opposite directions along the same axis.
(The exception to my rule would be a media player, which wants 3: ff, rev,
and play/stop)

In order to use a set of controls efficiently, I think it takes about 7
buttons. Aside from the main 'do it' button, there are 6 for navigation: the
four physical directions and two more directions (in and out) to let you get
context menus ('in'), jump out of text fields ('out'), and get out to the
toolbar and frame. (I know, you want to hide the toolbar by default. But
there's no reason it shouldn't be accessible.)

That means that there's enough buttons for generalized navigation and ONE
activity-related button. It would be nice to have another sometimes but it
is enough. The special button can be 'back' for the browser, 'ff'
(toggleable using controls to 'rev') for a media player, 'take picture' for
the camera, etc. The nav arrows turn pages in a book reader, or, if you
REALLY need scrolling, you just have to give up on a dedicated turn
backwards button.

Concretely: the arrow keys would navigate a selector between controls, the X
key would choose the control with the selector, the square key would pop out
of context menus, out of text boxes or other complex controls, out to the
toolbar, and out to the frame, in that order (followed by out to user,
group, world view??); the check key would go in the opposite direction; and
the O key would be activity-specific.

The added benefit of doing things like this, as I mentioned, would be that
an activity programmer would need to worry about resp

Re: 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 compr

Re: 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, wh

Re: 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 

Re: Sugar UI design and Tux Paint

[Jameson "Chema" Quinn]

On Dec 30, 2007 12:02 AM, Albert Cahalan <[EMAIL PROTECTED]> wrote:

> Jameson "Chema" Quinn writes:
>
> > One thing I've noticed in Tux 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.
>
> Huh? Tux Paint doesn't have any of that complicated stuff.
> Are you sure you're using Tux Paint? The icon is a penguin.


Oops sorry, I meant the OLPC "Paint" activity, I didn't realize there were
two.

(I read with interest your other comments on Sugar, and would say "I agree"
if it weren't just me bikeshedding.)

Jameson
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Sugar UI design and Tux Paint

[Albert Cahalan]

Jameson "Chema" Quinn writes:

> One thing I've noticed in Tux 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.

Huh? Tux Paint doesn't have any of that complicated stuff.
Are you sure you're using Tux Paint? The icon is a penguin.

You have to install Tux Paint from here:
http://wiki.laptop.org/go/Tux_Paint

I certainly would appreciate comments on the Tux Paint UI design.

It's probably time to do some housecleaning to rip out the lower
quality stamps, "magic" (special effect) tools, and brushes.
It'd be great to have quality rankings from people who were not
involved in producing Tux Paint; I may be too harsh or lenient on
the things I've written.

Journal integration is an interesting problem. Tux Paint keeps
some extra per-image data in extra files. I'm thinking that an
export-to-journal button might be most appropriate.

I could use a way to tell Sugar to not start up a second instance.
I haven't verified that it is safe to run two copies of Tux Paint,
but even if it is, the laptop is unlikely to have the RAM for it.

Shutdown tends to have the usual trouble. Tux Paint makes this
highly configurable. I had two dialog boxes. I got rid of one by
configuring Tux Paint to save on exit, but I'm really not comfortable
with saving random junk that the user will just have to delete.
The other asks if the user should overwrite or make a new file.
Never minding the wisdom of such dialog boxes, Sugar is defective
to not allow for it. (one sees the problem in SimCity too, etc.)

I'm strongly tempted to configure Tux Paint to grab the screen.
That frame is horribly easy to invoke.

We're still searching for a mark-move, mark-copy, cut-paste, and/or
copy-paste interface that little kids can deal with. One idea is to
have something like the gimp's quickmask mode on one button, and a
stamp on the button next to it. Another idea would be to select via
flood-fill on non-background pixels. It's a really hard problem
because Tux Paint tries to support a bright 2-year-old or regular
4-year-old.

So far, we haven't really considered supporting canvas sizes other
than the one that fills the screen. Do people think that matters?
I don't know of any reasonable way for a tiny kid to deal with
scrolling and zooming.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel