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 providing meaningful mappings that
provide access to a core set of functionality.  Setting this up
needn't require a lot of extra work, as this will likely amount to
setting up an alternate key binding for an action that is offered
elsewhere in the UI.

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

If the arrow keys only jump through controls, then there is no way to
scroll naturally.  Consider Read:  how do I both scroll (or page)
up/down/left/right and also navigate the controls?  And, even if I can
get there, I'll spend half my time cycling through a bunch of controls
which may not be of use to me in handheld mode at all, just to get to
the few that are.  There are also lots of other things one can't do
reasonably in Handheld mode.  For instance, there is no keyboard.  If
I select an action in the normal UI which prompts for keyboard input,
then I'm stuck.  While a nice idea, I don't think that any perfectly
generic system will provide a usable interaction.

> The added benefit of doing things like this, as I mentioned, would be that
> an activity programmer would need to worry about responding to just ONE
> extra event, the O key - or none at all if it already does the right thing
> on 'enter'. Sugar/GTK can handle all the rest.
>

- Eben