#2249 HIGH Trial-3: Web browsing should be possible in ebook mode.

[Zarro Boogs per Child]

#2249: Web browsing should be possible in ebook mode.
--------------------------+-------------------------------------------------
  Reporter:  cscott       |       Owner:  Eben   
      Type:  enhancement  |      Status:  new    
  Priority:  high         |   Milestone:  Trial-3
 Component:  web browser  |     Version:         
Resolution:               |    Keywords:         
  Verified:  0            |  
--------------------------+-------------------------------------------------
Comment (by Eben):

 Replying to [comment:5 cscott]:
 > In http://wiki.laptop.org/go/Browse#Handheld_Mode, I'd propose that
 "hold" for left/right activate scroll left/right, which is consistent with
 hold for up and down.  This also avoids the need for a separate panning
 mode, since panning is uniformly available by holding the directional
 buttons.

 I think this is a wise decision.  While it might be annoying in some cases
 to have to press to jump each link, it will serve the purpose well in the
 general case.

 > The previous proposal doesn't specify what happens when you use "focus
 next/prev link" and there are no links on the page.  If "focus next/prev
 link" is an up/down key, then it is intuitive for this to page up/down.
 But skipping forward an arbitrary amount to the next link could be
 unpleasant.

 I really want to keep all of the basic navigation mapped onto the D-pad on
 the left.  Essentially, all of the directional buttons move you laterally
 across the surface of the page, while the buttons on the right move you
 perpendicular to the page, forward or back in the stack.  I also think
 that there is an extremely small number of pages with no links at all, and
 we could still fall back to pg up/down then without sacrificing much.

 > I'm not convinced that link sharing is a vital activity for "handheld"
 mode.  I'd rather see the navigation and TOC displays mapped to the non-
 hold north and south buttons.

 Perhaps not, but we are placing a strong emphasis on collaboration.  Also,
 perhaps it would make more sense if I described this as the "bookmark"
 button, since that's really what it's doing.  It just so happens that the
 browser will share bookmarks with everyone else in the activity.
 Bookmarking is a basic browser feature.  Also, we have 2 stage rollover
 (contextual) palettes throughout the UI;  The hold state in handheld mode
 is meant to be an extension of that idea, with an "advanced" overlay
 mapped to a logically similar button, providing extended functionality.

 > You don't need a 'forward' button if you make sure to highlight the link
 you came through when you hit "back".  Then "back" then "forward" brings
 you to where you where.

 This is precisely the logic outlined in the wiki, and I think it will work
 quite well.  In order to make it work well, though, we may need to
 aggressively cache when possible.  Otherwise, the child will have to wait
 for the page to load, render (this might be the biggest delay for us,
 actually), and then jump to the appropriate link.

 > I don't think you need a special "help" overlay; instead you should just
 opportunistically pop up  a small legend in a corner when you invoke any
 overlay.  Normal presses of the north and south buttons would then have a
 side effect of telling you what the "hold" modes are.

 That's a possibility, but I don't think we'll have too much luck pushing
 it into a corner when the screen is so small.  Also, it doesn't address
 any possible need to switch activities (Which I'm not sure we need or not,
 yet).  Also, we want the entire UI to be easily discoverable, and part of
 the need for the menu in my mind is to teach the children about the hold
 states.  I think if we include this at all, it needs to be a single press
 event.

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