[sugar] Pie menus for pygtk and OLPC Sugar!

[Marco Pesenti Gritti]

On Fri, 2007-02-23 at 15:39 -0500, Eben Eliason wrote:
> WHERE
> 
> Pie menus are always tricky around screen edges, and I'm not a fan of
> any of the design solutions that aim to fix this.  As such, I'm
> proposing two very specific yet useful cases where these menus will be
> used.  They are not a general purpose replacement for all menus in my
> mind, but their benefits can be maximized in some cases.

I fully agree on this, so I'm going to comment on the specific cases.

> 
> 1. Contextual Menus/Rollovers
> 
> The current laptop design includes the notion of rollovers for
> Objects, which typically exist in two states.  A primary rollover
> appears to provide a text title for the Object, which is otherwise
> rendered as an icon only, and a secondary extension of this appears
> after a short delay to provide a preview, summary, and a list of
> actions associated with the Object.
> 
> All contextual rollovers should be replaced with pie menus.  The menu
> itself would appear, of course, surrounding the object so the icon is
> still visible in the center.  The text description of the object the
> menu relates to can appear with the icon, in the center of the menu
> (eg. the child's name when rolling over an XO).
> 
> This menu could contain a list of primary actions associated with the
> object.  For instance, for an XO you could "send message", "make
> friend", "invite to activity", etc.  Each object type might have a
> slightly different list of actions, but there will certainly be
> overlap.  Where possible, we will define the arrangement of these
> actions such that they always appear in the same place, regardless of
> the object itself.  This is important for spatial recognition, making
> gestural activation natural everywhere in the interface.  Slices for
> actions that don't apply to an object will be left empty.
> 
> The only drawback to this over the previous rollover design is that
> the actual preview image or summary won't appear automatically after
> delay.  Instead, the preview would appear as the secondary panel of a
> "preview" action slice in the menu, which would of course be
> consistently positioned for every object.  The advantage, of course,
> is that taking actions on objects is actually quickly exposed, whereas
> before they were confined to a secondary rollover state.
> 

I'm not fully convinced about this one.

* As we discussed it would probably not be possible to use it on the
frame (since icons are near the edges).
* It would make sense in the Friends view. Though we allow to reposition
Xo's there, so again, they could be near the edges.
* What are the advantages to use them in the mesh? The two primary use
cases seem 1 explore and 2 join activities. Pie menus doesn't seem to
make 1 easier (you can just click on the activities) and probably makes
2 a little harder (more indirect preview).
* In the current mesh design you can easily browse through participant
names with the little animation you sketched out in the flash demo.
Would that be as easy with pie menus?

> 2. Activity Menu
> 
> Until now, we didn't really have a menu system per se for Activities
> at all.  Instead, we have a toolbar, where buttons/controls in the
> toolbar can have rollover states which provide panels with additional
> controls contextual to the button itself.  There is a file menu of
> sorts in the frame, providing basic features like keep (save), share,
> etc, but nothing that the activity developer could extend in any way.
> 
> I propose that we allow each activity to define its own activity pie
> menu.  This menu could be invoked by right clicking anywhere on the
> screen where there isn't an object with its own contextual menu.  It
> could contain any number of items, ranked by the three levels
> mentioned above.  There could perhaps be a method of selecting which
> level of detail you want to see through the interface, but I have
> other ideas for this as well.

Sort of OT but I really dislike the idea of selecting the level of the
detail of the interface. It's just a question without a good answer. If
we decide to go this way we should at least analyze the previous
attempts to this kind of interface and figure out why they failed.

> This activity menu can function in two powerful ways.  The first is
> that it provides a place for activities to define additional
> functionality.  Until now, with no menu system, everything had to be
> exposed on screen.  This is a goal we still want to shoot for, and it
> should be known to developers that their activities should function
> completely without need for the activity menu at all.  However, when
> additional advanced controls or options would benefit experienced
> users, this menu could provide an outlet for some of them without
> cluttering the toolbar itself.  By design, I would recommend that such
> advanced features be ranked as tertiary items.
> 

This make sense to me but we have to define clearly the use cases. I
don't want activities to come with dumb interfaces and then put all sort
of "advanced" features in the pie to work around the design
deficiencies.

> The second and actually more powerful way to use these menus in my
> mind is, rather than for advanced functionality, for limited basic
> control of the interface.  As an example, consider the web browser.
> The basic set of controls might be "forward" (right), "back" (left),
> "reload" (up), "view source" (down).  By defining these as the
> primaries, I can instantly invoke these frequently used commands with
> gestural ease, without even needing to mess about with toolbar
> buttons.  This kind of gestural activation of frequent actions could
> be fantastic.  Similarly, a drawing activity might define "circle",
> "square", "line", "brush" as it's basic set of tools, making selection
> of the needed tool a breeze without needing to leave the region of the
> drawing being worked on.
> 

I really like this use case.

I have a couple of general concerns about the activity menu.

One is conceptual. The actions are global but both the visual
representation and the controller (mouse button) are contextual. I tried
the RadialContext extension in firefox and this aspect really feel odd
to me.

The other is about interaction. We conflict with context menus so the
user would have to be careful to hit a part of the screen where there
are not other context menus to activate them.

> 3. Handheld Mode
> 
> Finally, a fantastic side effect of the activity menu is its
> application in handheld mode.  Previously, we had stated that
> activities would have to explicitly implement handheld controls, since
> there would be no mouse and keyboard.  However, when the activity
> menus are designed such that the primary items are the basic key
> controls for the activity, any activity can run in handheld mode, at
> least in some form.
> 
> We could make the circle button on the right the menu button.  Press
> and hold this button to display the pie menu, and use the directional
> pad to select the option you want.  This is where the ranks for items
> also comes into play.  Since we can read 8 directions from the d-pad,
> we can show either primary or secondary levels of the menu.  Of
> course, activities could choose to use this button for something other
> than the pie menu if they wish - in games, for example - but this
> would be a really nice default that would make most activities play
> nice with handheld mode "out of the box."

I really like this.

> 
> I look forward to hearing what everyone thinks.  Also, Marco, I'd like
> to hear your thoughts on all of these ideas from an implementation
> standpoint.

I think it's very unlikely we will have a composite manager for
generation 1. That means we will have to use shaped windows to implement
it, which is possible theoretically, but I think no one actually tested
the performance of this on the OLPC. Before putting a lot of design work
on this I think it would be wise to try out a prototype on the olpc
(especially since we have already Don implementation and we can easily
add a shaped window to it).

Marco