#1320 HIGH Trial-2: Implementing handheld support

[Zarro Boogs per Child]

#1320: Implementing handheld support
-------------------------------+--------------------------------------------
  Reporter:  cjb               |       Owner:  Eben    
      Type:  defect            |      Status:  assigned
  Priority:  high              |   Milestone:  Trial-2 
 Component:  interface-design  |     Version:          
Resolution:                    |    Keywords:          
  Verified:  0                 |  
-------------------------------+--------------------------------------------
Changes (by Eben):

 * cc: marco, walter (added)
  * summary:  Left-hand game keys should control mouse? => Implementing
              handheld support

Comment:

 I've put a lot of thinking into how the buttons can work in handheld mode.
 The Browse activity page on the wiki outlines a particularly good example
 of this.  (http://wiki.laptop.org/go/Browse#Handheld_Mode) I need some
 more direct feedback on the technical implications of the design as spec'd
 there, so we can adjust the UI as necessary and come up with a solid
 target for Trial 2.

 We need to nail handheld mode with at least one of our activities early on
 as an example.  Browse and Read seem like obvious targets.

 To address this thread a bit more directly, I think that the arrow keys
 should actually be tied to the up/down/left/right arrows by default.  This
 eliminates the need to deal with a button for simulating mouse clicks, and
 leaves handheld mode to more basic things like scrolling a view.  This can
 still be useful even if the toolbar and other buttons aren't accessible.
 Perhaps we need to consider a way to have activities automatically focus
 the "primary canvas" when handheld mode starts so that these keys can
 scroll it.

 As for the other keys, by default we could have:

  * Check: Enter, (Space?)
  * X: Escape
  * Circle: Tab
  * Square: Back-tab

 It seems like tabbing (and back-tabbing) through the interface should
 provide a way to get to all of the controls on screen, just as with basic
 keyboard navigation.  The (space?) question is there because, while the
 check key usually sends an enter signal, often the spacebar is the one
 used to activate controls.  In other words, the enter key is usually bound
 to the "submit" or "OK" button, and the other controls, such as option
 lists, are activated by focusing and pressing spacebar.  Perhaps we should
 ONLY send the spacebar signal, so that you can't accidentally trigger a
 button that isn't focused.  Thoughts?

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