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.

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

A context menu for what link?  This amounts to a bookmark function
which bookmarks the current page (sharing it with others in a
networked activity).  This seems like a primary function to me, and
something that should be just a button press away.

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

There is often no need for an explicit exit option in my scheme.  The
context menu appears while the button is held down, presenting a list
of options, the selected of which is highlighted when the menu
appears.  Releasing the button dismisses the menu without changing the
state (in a tab switcher the current page would be selected in the
navigation stack, so up/down are, for instance, forward/back).  Using
the direction keys to select another option would select the option
upon release.

This use of W hold thus requires use of hold states for non-secondary
functionality.

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

Honestly, I'm not sure I fully agree on this point.  Sugarizing an
activity needn't necessarily require handheld mode support.
Obviously, the more we can take advantage of it, the better, but I
don't expect it to make sense for everything.  TamTam (Edit), for
instance,  would be fairly impractical to manage; Likewise, painting a
picture would be pretty hard.  On the other hand, both of these
activities could, if they wanted, provide a core set of functions that
do make sense:  for instance, TamTam could provide a nice little
fullscreen playback suite.

For many activities which don't do extra work to support the mode,
handheld mode might be more of a presentation mode instead.  This
would be enhanced by the fact that the toolbar, trays, and cursor will
disappear automatically, at the very least offering a fullscreen view
of the interface and providing natural scrolling/paging when that
makes sense.

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

I think it's oversimplifying to assume that there is one "document"
which can have focus.  In Write, or Browse, or Paint this may be true,
but nothing requires it.  What if there are simultaneously a scrolling
list, a text area, and both vertical and horizontal button panels
within the interface, in addition to the toolbar.  What if the
scrolling list has some buttons within each list item as well.  The
control hierarchy can get complex quickly, and there would be no good
way to navigate it.  It seems you'd have to navigate each of these
sub-hierarchies with the "in" and "out" buttons, then use the
directional buttons at any given level to cycle through children.
This could make navigating even interfaces just slightly above the
bare minimum of complexity really tedious and non-intuitive.

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

A poorly sugarized one could also take the hit of being a presentation
mode, and then add meaningful functionality on top.  In the end, I'm
just unconvinced that a complex navigation system for the entire UI
actually has benefits which outweigh the cost.

- Eben