Sugar UI design and Tux Paint

[Jameson "Chema" Quinn]

On Jan 2, 2008 2:17 PM, Eben Eliason <eben.eliason at gmail.com> wrote:

> <selections: verb-object or object-verb>
>

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


> <global preferences>
>
> 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 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080102/fcf6a339/attachment.html>