Collaboration Requirements: Difference between revisions

From OLPC
Jump to navigation Jump to search
Line 29: Line 29:
Definitions of "must" and "should" conform to RFC 2119
Definitions of "must" and "should" conform to RFC 2119


=== Main collaboration design ===
Collaboration is achieved when one XO starts an activity and others join it.
Collaboration is achieved when one XO starts an activity and others join it.
The view of available XOs and applications must use the neighborhood view as defined here: <br>

The view of available XOs and applications must use the neighborhood view.


<br>
<br>
[[Image:friends.jpg|right|thumb|240px|The Groups view: Members of the currently selected group and their current activities are visible from this view. Hovering over a “missing” XO reveals an "away message."]]
[[Image:friends.jpg|left|thumb|240px|The Groups view: Members of the currently selected group and their current activities are visible from this view. Hovering over a “missing” XO reveals an "away message."]]
<br>


Once multiple XOs are collaborating the neighborhood view must show all XOs working on an activity as shown here: <br>

<br>
[[Image:neighborhood.jpg|left|thumb|240px|The Neighborhood view (or Mesh view): All children visible on the mesh network can be seen clustered around shared activities; Away messages are also accessible from this view.]]
<br>
<br>



Revision as of 14:56, 20 January 2009

Collaboration requirements for OLPC XOs and XS

Greg Smith July 30, 2008

Background

The concept of "Collaboration" has been around for a long time. I have used cuseeme, MeetingPlace, NetMeeting, WebEx, IRC, AIM, Gobbby, Sametime, PC Anywhere, Cisco HD Video conferencing and others. Other related apps are, Email, free web hosting, filesharing networks, Croquet, erights.org, Alice ML, multi-pointer X, Groovy, the distributed source control movement, and the Google Apps

  • wireless
  • educational use
  • greater scale
  • Designed for use by people in close physical proximity to each other.

Motivation

The goal of this requirement definition is to provide all the information necessary to define tests and fix critical collaboration bugs in 8.2.0 and to set a goal for 9.1.0.

The best case is that this write up motivates test cases which results in a list of detailed examples of collaboration that will be supported in 8.2.0. These examples should be deployable and usable by teachers in class. Examples of use cases generated by teachers are at: http://wiki.laptop.org/go/Use_Cases#Collaboration_Examples

Collaboration is an area where we are on the cutting edge of available technology. It was well promoted and teachers on the "sur" list have repeatedly asked for a definition of how to use it successfully.

A list of activities supposedly enabled for collaboration is at: http://wiki.laptop.org/go/Collaboration_Central

Documentation on previous wireless tests is at: http://wiki.laptop.org/go/Test_Config_Notes#Wireless_.26_Network
and at
http://wiki.laptop.org/go/Collaboration_Network_Testbed

Requirements Definition

I set a high bar but I try to balance between available technology and the desires of the teachers. I hope can at least test to this standard soon, even if we don't close all bugs found by that testing until later.

Definitions of "must" and "should" conform to RFC 2119

Main collaboration design

Collaboration is achieved when one XO starts an activity and others join it. The view of available XOs and applications must use the neighborhood view as defined here:


The Groups view: Members of the currently selected group and their current activities are visible from this view. Hovering over a “missing” XO reveals an "away message."


Once multiple XOs are collaborating the neighborhood view must show all XOs working on an activity as shown here:


The Neighborhood view (or Mesh view): All children visible on the mesh network can be seen clustered around shared activities; Away messages are also accessible from this view.


Network Requirements

Supported Architectures

N1 - Must support one of the four network scenarios defined at: http://wiki.laptop.org/go/Networking_scenarios

The scenarios in priority order are named as follows.

  1. S1 - Simple Wifi
  2. S2 - School Wifi
  3. S3 - Simple Mesh
  4. S4 - School mesh (no need to test, just recorded here for completeness)

RF Environments

N2 - Must support environments where there are no other RF signals beyond the APs as needed by the network scenario.

N3 - Must support RF environments where up to 2 other APs are visible in the XO neighborhood.

N4 - Should support environments where there are up to 4 other APs visible in the XO neighborhood.

N5 - Must support a total available bandwidth budget between all of the speakers of 300Kb/s. Must define the latency and jitter of the network as well (per Michael S)

Scale

Scale of XOs collaborating

N5 - Must support up to 10 XOs collaborating together. See activity examples for exact steps.

N6 - Should support up to 20 XOs collaborating together.

N7 - Nice to support up to 30 XOs collaborating together.

Scale of XOs visible within range of each other

N8 - In N5 above must allow up to 1500 XOs within range in the school. Can require that all other XOs aside from those collaborating have their antennas turned off.

N9 - Must allow 50 (should allow 100, nice to have 300) other XOs within range in the school where all XOs have their radios turned on. Can require that only those collaborating are using the network (AKA everyone else is verbally asked to stop using the Internet and stop collaborating) but they can leave their XO radios on in scenario S1

N10 - Must allow 50 (should allow 100, nice to have 300) XOs within range in the school where all XOs have their radios turned on. Can require that only those collaborating are using the network (AKA no collaboration and no Internet access) in scenario S2.

N11 - Must allow 50 (should allow 100, nice to have 300) XOs within range in the school where all XOs have their radios turned on. Can require that only those collaborating are on a given Mesh channel (1,6 or 11) while all the other XOs are on different Mesh channels in scenario S3

Types of collaboration

In all cases, a single XO starts activity, then shares it, then other XOs join the shared activity.

N12 - Must support up to 3 XOs using an activity and all others XOs (as allowed by the scale) watching what happens on that screen.

N14 - Should support 10 XOs (as allowed by scale) using an activity simultaneously.

N15 - Nice to have all XOs as allowed by scale using an activity simultaneously.

N16 - Must support pairs of two XOs collaborating with each other up to the number of XOs supported by scale.

N17 - Should support all the partitions of XOs collaborating with each other (e.g. with 6 XOs, allow 2,2,2 and 3,3 and 4,1,1 etc).

N18 - Where an activity allows saving, must support saving at any time where the XO which saves gets a current copy of the shared file. If its a "save as" or "save" but not exit action then the XO which saves returns to the shared view. Where its an automatic "save" by leaving the activity, the journal must store a current copy of the shared file. All of these saving actions must not interfere in any way with the saved or shared file on the other XOs or with the collaboration or network connectivity of any XOs.

Activity Level Details

N19 - Must support Chat activity that ships with XO

N20 - Must support Write including adding pictures, formatting with tables and other write tasks. Must support saving (keeping) in Write, see N18 above. Should support large colored cursors, so that children can recognize what is the one they are moving. (source on second sentence: Bastien)


N21- Must support record including sharing pictures and recorded video with audio.

N2 - Must support Read

N23 - Must support Etoys

N24 - Should support other activities listed at: http://wiki.laptop.org/go/Collaboration_Central