#1108 HIGH Trial-3: Implement the new mesh design

[Zarro Boogs per Child]

#1108: Implement the new mesh design
-------------------------------+--------------------------------------------
  Reporter:  AlbertCahalan     |       Owner:  Eben   
      Type:  enhancement       |      Status:  new    
  Priority:  high              |   Milestone:  Trial-3
 Component:  interface-design  |     Version:         
Resolution:                    |    Keywords:         
  Verified:  0                 |  
-------------------------------+--------------------------------------------
Comment (by Eben):

 Replying to [comment:13 Hello1024]:
 > Can't the tubes api route connections via the school server in the case
 where a user wants to connect to an activity on an alternate channel -
 then it's only the case where there is no connection to the school server
 that needs user interaction.  A forwarding system for presence information
 should also be set up on the schol server so status information about
 another user can be found even if they're on another channel.
 This is already the goal.  The crazy channel-hopping that the pdf
 illustrates should be the extreme edge case and not the norm.  It will
 only be available when a) the school server isn't reachable and b) a
 person is explicitly looking for another person or activity that they
 can't find on their channel.  For this reason, channel hopping isn't even
 exposed in the UI except as a small button that appears after performing a
 search, so as to say "if you didn't find that here, you might find it on
 another channel.

 In any case, I'd be perfectly happy accepting the limitations myself, but
 the general consensus seems to be that it's better to expose these types
 of details when they actually affect the kids' interactions with the
 system.

 > In this case, the user DOES need to know about the reliability of the
 connection, and a simple here or not here isn't good enough.  If it is
 decided that a mesh organised by signal strength isn't practical (and I
 can understand this view because in most circumstances it won't match
 physical geography anyway), then each xo should at least have a marking or
 tooltip showing some kind of score about whats possible.  (for example 1
 star=chat is possible, 2 star=file transfer is possible 3 star=video
 conferencing possible)

 Actually, we're one step better than that with this spec.  Each XO has 3
 states, not 2:  here, not-quite-here, and not here.  Anytime a signal is
 a) lower than some threshold or b) dropped completely temporarily, the XO
 will be rendered as a white outline instead of colored.  It can still be
 interacted with, but it has a lower status.  If the connection drops off
 and doesn't come back after a short period of time, it will disappear
 completely.

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