#2921 NORM Trial-3: Web-Activity: Add a new link on the left or on the right

[Zarro Boogs per Child]

#2921: Web-Activity: Add a new link on the left or on the right
---------------------+------------------------------------------------------
  Reporter:  Simon   |       Owner:  Eben    
      Type:  defect  |      Status:  assigned
  Priority:  normal  |   Milestone:  Trial-3 
 Component:  sugar   |     Version:          
Resolution:          |    Keywords:          
  Verified:  0       |  
---------------------+------------------------------------------------------
Changes (by Eben):

 * cc: christianmarc, okada, edsiper (added)
  * status:  new => assigned
  * component:  design => sugar

Comment:

 This is an interesting question to consider.  My first instinct was to
 insert to the right, so the newest link should be at the tail of the list,
 consistent with RTL language, etc.  The problem with this approach
 (specifically in relation to our tray design) is that the newest link
 could wind up being the first link on a new page within the tray, both
 requires auto-paging the tray to reveal the new link, and also "hides" all
 of the links on the previous page.

 By inserting at the head of the list, the most recently added link always
 appears at the very same spot.  Also, it always pushes one link off the
 first page of the tray (once there are more objects than fit in one page),
 but it never requires scrolling and keeps the remaining links on the first
 page.  This is also more consistent with our design for the clipboard,
 people, and invitations in the Frame, where the newest item always appears
 in a fixed location (at the head).

 That all said, I think that the newest link should be added to the head of
 the list, where the head is the left for RTL languages and vice versa.
 Pentagram, do you guys agree with this assessment?

 Another option, just to toss it out there, is to redefine the way paging
 works so that no page  (except the first, when it isn't full) is rendered
 with gaps.  That is, the last page would actually be composed of the last
 few elements of the entire tray ''plus'' the last several objects of the
 previous page such that the whole tray remains full.  This would basically
 mean that all of the above benefits of the insert-at-head model apply, but
 in the other direction.  The only drawback is that the "pages" are quite
 as well defined, since some items will appear on pages n and also n-1.

 I'm reassigning this to Sugar since this question affects the design of
 the tray widget in general.  Also, Simon and Eduardo please get in touch
 about the implementations so that we're aiming at a single OLPC supported
 control for this in the end.

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