#5826 NORM Never A: No user-feedback after pressing return in URL field.

[Zarro Boogs per Child]

#5826: No user-feedback after pressing return in URL field.
------------------------------+---------------------------------------------
  Reporter:  legutierr        |       Owner:  erikos                           
      Type:  defect           |      Status:  new                              
  Priority:  normal           |   Milestone:  Never Assigned                   
 Component:  browse-activity  |     Version:  Development build as of this date
Resolution:                   |    Keywords:                                   
  Verified:  0                |    Blocking:                                   
 Blockedby:                   |  
------------------------------+---------------------------------------------
Changes (by Eben):

  * owner:  Eben => erikos


Comment:

 Well, that's not ''quite'' accurate. Upon pressing the return key in the
 URL field:

  1 the refresh button becomes a stop button;
  2 the loading bar appears within the URL bar itself;
  3 and the mouse cursor gets a spinner.

 The first is subtle, the second occurs on a short delay, and the third is
 only visible when the cursor is above the web view itself, which amounts
 to a seeming lack of feedback.

 (1) is reasonable, and I think works fine.  (2) is a bit of a problem, I'd
 say.  In fact, I'm rather unsatisfied with the non-linear behavior of the
 loading bar anyway, which fails to convey any very meaningful information.
 I'm in favor of adjusting the manner in which we interpret progress so
 that a) it always feels like we're moving forward and b) the progress is
 more continuous.  Additionally, I would add a small constant amount of
 progress at the beginning, so that the bar appears to start filling
 immediately when the enter key is pressed. (3) is curious, does anyone
 know why it behaves this way? We could add a "spinner" somewhere in the UI
 to indicate asynchronously that something is happening, but that seems to
 be redundant with the mouse spinner.

 Tomeu, Simon: what are your takes on the possibility of adding adjusting
 the progress bar behavior.  These are the key ideas:

  1 Put an inverse weighting on the data with respect to time, such that
 the progress bar will move further per byte as the website gets closer to
 loading completely.  By making it feel like it's moving somewhat slowly at
 first, and speeding up considerably toward the end, we can make the whole
 process feel quicker.  This is almost the inverse of what happens now.

  2 Relating to the above, right now the bar actually jumps backward at
 various points while loading, making it look like loading has regressed.
 We should eliminate this behavior entirely, so that the new progress is
 measured as a percentage of the remaining area in the bar.  This will be
 less of a problem in conjunction with the above, since we err on the side
 of leaving extra space in the loading bar anyway.

  3 Smoother motion on the bar will spread out the progress more evenly,
 rather than making it jump in large uneven chunks. Applying a smoothing
 function to the data (for instance, always expanding the bar a fraction of
 the difference between its current value and the actual loaded amount)
 will also increase perceived loading time, and ensure that there is more
 continuous feedback of progress.

 4. By adding a constant offset to the bar when loading begins, we'll have
 a brief burst of animation upon pressing enter until the smoothing
 function reaches the desired cosntant (likely 10% of the bar or so).  This
 will provide much stronger immediate feedback.

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