#1310 HIGH Trial-3: Can't make sugar do ANYTHING in Ebook mode

[Zarro Boogs per Child]

#1310: Can't make sugar do ANYTHING in Ebook mode
-------------------------------+--------------------------------------------
  Reporter:  gnu               |       Owner:  Eben    
      Type:  task              |      Status:  assigned
  Priority:  high              |   Milestone:  Trial-3 
 Component:  interface-design  |     Version:          
Resolution:                    |    Keywords:  relnote 
  Verified:  0                 |  
-------------------------------+--------------------------------------------
Changes (by Eben):

 * cc: walter, christianmarc, jg (added)
  * priority:  normal => high
  * status:  new => assigned
  * component:  sugar => interface-design
  * type:  defect => task

Comment:

 Early thoughts for the mode specifically considered that Sugar would not
 be supported; Many of the main functions of Sugar aren't suitable for the
 controls available.  Recent discussion has brought up the possibility of
 allowing switching of activities via handheld mode as the sole Sugar
 supported operation, and I think this is a reasonable thing to shoot for.

 Sugar should automatically jump to the activity view when entering
 handheld mode, since the other views won't be supported.  We'll need to
 formalize a means by which to switch activities.  I'm beginning to like
 the idea of commandeering the rotate button as the "handheld menu" button.
 We've already decided that we want to require a second action when
 rotating the screen, and therefore want some on screen visual when this
 button is pressed.  I also feel that its a terrible idea to steal any of
 the other 8 buttons from the activities, since they are already limited,
 and I think it's useful to maintain the natural diametrically opposing
 pairs of buttons in many cases.

 I've been wanting an on screen key mapping for handheld mode which
 illustrates both press and hold actions for the buttons visually.  I think
 it makes sense to tie this key mapping to the rotate key, since the
 mapping may change when the screen rotates.  It also makes sense to tie
 this key mapping to the switcher interface, so that you can review the
 mapping for the selected activity when you switch to it.  I really liked
 the idea of pressing the direction that you want up to be, but perhaps we
 could settle for using left/right to switch activity, up/down to rotate.
 We could also map activity switching to one set of buttons, and rotation
 to the other.  I'm not sure what the right solution is, but does it sound
 reasonable to design such that this single button is the "handheld
 management" button?

 Fortunately  for us, the icon on the button could be interpreted both as a
 rotation button and also as a cycle through activities button.  Perhaps we
 could find a better icon in the future, but it actually seems ok as is for
 now, even if we do overload its purpose.

-- 
Ticket URL: <http://dev.laptop.org/ticket/1310#comment:5>
One Laptop Per Child <http://laptop.org/>