Sugar UI design and Tux Paint

[Jameson "Chema" Quinn]

On Jan 2, 2008 5:35 PM, Eben Eliason <eben.eliason at gmail.com> 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...

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


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.

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)

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

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

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

panning overlay: your use of south. Might be nice, but not necessary.

Share link to here/share link overlay: your use of north. In mine, it would
be either in the toolbar or in back-button-then-N-hold (a context menu for
the link, which would also include 'open in new tab', though the tab list
would autoclean like the journal, but that's another story)

What would I do with W and E:
W hold: move focus 'out': get out of menu (note that in your scheme all
context menus/ nav overlays need an explicit exit option because there's no
button for out), get out of text box, get toolbar (you could include the
shared links bar too on this level - you have two dimensional navigation
after all), get frame, in that order.
W press: app-specific 'out', 'away', or 'back' option. In Browse, maybe zoom
out? (available for rew on a media player)
E hold: opposite of W hold. When you get down to the context-menu-level, it
would be the TOC menu which you have in E hold.
E press: zoom in.

I hope this is all clear. As you can see, the differences are less than one
might imagine.

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


OK, using your great click/hold idea, the buttons available to an app are
now 4-6, depending on how you count: E and W press for in and out, S press
and S hold completely free (if used in opposition to N "do", it would be
"undo"; but for camera, it would be 'take picture'), and maybe I can count N
hold (context menu) and even N press (select) as being app-specific.

Remember that if your main window doesn't have buttons inside it, you can
use N press (Select control) for what you will (abiword might use it to
sticky the shift key and turn the cursor into an I-bar, for instance). You
also have more freedom with the up/down/left/right then too (in Abiword,
holding them could page down/side scroll).


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


Not too much work: Granted. But there will always be apps which are
incompletely sugarized, we want that to cover as much ground as possible. It
would be great to be able to make a sugarizing wrapper that could make a
generic GTK app look like sugar.

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


When the focus is on the document, the arrow keys scroll. (The links or
buttons within the PDF are inaccessible). To jump through controls, put the
focus on the toolbar (which hides otherwise anyway) by holding W. This is
not even a special case, it is the natural behaviour; controls INSIDE a
document, like Browse, are the special case.


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


A well-sugarized activity could hide inapplicable controls. A
poorly-sugarized one could just take the hit.

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