#2337 HIGH Retriag: Switching between activities

[Zarro Boogs per Child]

#2337: Switching between activities
--------------------------+-------------------------------------------------
  Reporter:  bert         |       Owner:  marco            
      Type:  enhancement  |      Status:  new              
  Priority:  high         |   Milestone:  Retriage, Please!
 Component:  sugar        |     Version:                   
Resolution:               |    Keywords:                   
  Verified:  0            |    Blocking:                   
 Blockedby:               |  
--------------------------+-------------------------------------------------
Changes (by legutierr):

 * cc: Eben, legutierr (added)
  * priority:  normal => high
  * milestone:  FutureFeatures => Retriage, Please!


Comment:

 Eben:

 Would it not be feasible, and consistent with the Human Interface
 Specification, to put icons for the running activities in the upper-right
 of the Frame?  The HI spec says that the top is for "places", and the last
 zoom button brings you to the generic activity that is at the top of the
 active instance "stack", so having a series of icons of ''all'' the
 running activity instances would not break that paradigm.  If the list is
 too large for the window, left/right buttons could be used, but
 considering the resource limitations of the XO, it is unlikely that the
 number of icons would actually exceed the available space.

 Your illustration of the frame from the HI spec
 (http://wiki.laptop.org/go/Image:Frame.jpg) already shows an icon of a
 single application in that position.  Your illustration also shows a
 global search field in that position; the potential for that global search
 being implemented in the future would have to be eliminated, but
 considering that that global search feature seems to already have been
 depricated (no outstanding bug calling for its implementation, and the
 page describing global search in the HI spec is a stub), eliminating the
 possibility of implementing that feature in the future does not seem
 terribly costly in light of the need for this feature.

 Using this method seems more "sugar-consistant" than using a macintosh-
 like overlay (even if the overlay does reinforce the "ring" metaphor) and
 is probably a bit less work to implement, and more resource-efficient.  It
 also seems a better solution than putting running activities in the left-
 side of the frame with the clipboard objects (which can fill up very
 quickly), or disallowing the consistent use of the bottom of the frame to
 open new instances (as you point out). This method also requires fewer
 clicks (in fact, only one in most cases), and doesn't require the user to
 know any keyboard shortcuts, so is more intuitive.

 Might I also propose that you consider retriaging this feature of
 switching between activity instances without going home out of
 FutureFeatures (regardless of how it ends up being implemented)?  As an
 active user of the XO, I am constantly switching between activities by
 going through the Sugar Home; it takes a long time (two clicks, or a key-
 stroke and a click, and waiting for Home to load/draw) and is annoying.
 Using Sugar Home in this way also devalues the frame: to switch apps, I
 don't even touch the frame (using the keyboard "home" key to avoid
 extraneous movement).

 Also, by using Sugar home to switch between instances within the same
 process (i.e. between Browse instances), are we not causing unnecessary
 context switching, and slowing things down system-wise?

 (actually, if someone could take the time to actually answer that question
 in some detail, or point out some documentation that would help my
 understanding of that issue, I would very much appreciate it.)

-- 
Ticket URL: <http://dev.laptop.org/ticket/2337#comment:8>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system