#1385 HIGH Update.: Wireless LED usage during use.

[Zarro Boogs per Child]

#1385: Wireless LED usage during use.
--------------------------+-------------------------------------------------
  Reporter:  jg           |       Owner:  rchokshi
      Type:  enhancement  |      Status:  new     
  Priority:  high         |   Milestone:  Update.1
 Component:  wireless     |     Version:          
Resolution:               |    Keywords:          
  Verified:  0            |    Blocking:          
 Blockedby:               |  
--------------------------+-------------------------------------------------
Changes (by mikus):

 * cc: mikus at bga.com (added)


Comment:

 Been reading old tickets.  Apparently light_1 was to show "association"
 (to mesh OR to infrastructure access point) and light_2 was to show
 traffic (or MPP association).  These are good uses for network debugging
 -- but do they tell the child information that he needs to act on ?

 I believe the number of communication_status indicators is more than two.
 The question then becomes:  Which indicators need to be always visible,
 and which can be relegated to being shown on an appropriate screen view ?


 It seems reasonable that the child might "give up" something he is doing
 with his XO if he sees that communication was lost;  or he might initiate
 doing something with his XO when he sees formerly unavailable
 communication now established.  And it is likely that the most important
 destinations for the child to communicate with are the mesh (i.e., his
 "peers") and the school (i.e., his writeable "data repository").  My
 proposal is that light_1 indicate "connection working to at least one
 participant who can be shared with", and that light_2 indicate "connection
 working to the school server".  Keeping an eye on the status of these
 lights will help the child decide what to do next with his XO.


 --------

 That leaves "screen views" as the location of the remaining communications
 indicators,  The Neighborhood view *already* displays many of the
 destinations reachable by the XO -- it seems a good place to show status
 information about what those destinations can be used for (e.g., __here__
 is how internet connectivity is currently being provided).

  -  In my opinion, whatever eth0 is connected to ought to be *uniquely*
 marked in the Neighborhood view.  If the XO is serving as a Mesh Portal -
 that needs to be (separately) indicated in this view.

  -  If it is important to the network administrator to extract information
 about eth1, its destination can also be specially marked in this view.

  -  Notable destinations such as the school server and the jabber server
 (as specified in sugar-control-panel) should be specially marked.

  -  Where the icon in the Neighborhood view is the principal indicator of
 the status of a connection, the appearance of the icon ought to change
 *noticeably* upon disconnect.

  -  Flyover ought to list the characteristics of marked destinations.

  -  Availability of other 'Access Points' is already shown in this view.

 To present the "utility" of a connection, 'traffic' information can be
 added to wherever 'signal strength' is being shown.


 --------

 Serious shortcomings of the existing communication_status indicators:

  -  Rapid blinking of the XO front panel lights is very distracting.
 Instead, put in an option to have the software output a description of its
 transient state ("trying to connect on channel 6") to a log.

  -  Having the __rim__ of a circle change color when connectivity is lost
 is not conspicuous enough.  Have a light dedicated to showing the
 connection's status.  For connections without such a dedicated     light,
 in Neighborhood view change the __entire__ corresponding icon.

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