Collaboration Requirements: Difference between revisions

From OLPC
Jump to navigation Jump to search
 
(4 intermediate revisions by the same user not shown)
Line 25: Line 25:
== Requirements Definition ==
== 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.
I set a high bar but I try to balance between available technology and the desires of the teachers. This requirements definition is intended to show the main GUI elements and ways which XOs access collaboration. Most importantly, its written to set a test standard for scalability fo collaboration which allows us to define a minimum supported scale level.


Definitions of "must" and "should" conform to RFC 2119
Definitions of "must" and "should" conform to RFC 2119
Line 32: Line 32:
Collaboration is achieved when one XO starts an activity and others join it. The icon below the XO icon shows the currently shared activity which other XOs can join.
Collaboration is achieved when one XO starts an activity and others join it. The icon below the XO icon shows the currently shared activity which other XOs can join.


- Must allow the user to see available activities to collaborate on by navigating to the neighborhood with a keyboard press or frame selection.
D1 - Must allow the user to see available activities to collaborate on by navigating to the neighborhood with a keyboard press or frame selection. <br>
- In Neighborhood view must show available XOs and activities in a single view.
D2 - In Neighborhood view must show available XOs and activities in a single view.


A design for the view of available XOs and activities is defined here: <br>
A design for the view of available XOs and activities is defined here: <br>
Line 41: Line 41:
<br>
<br>


Once multiple XOs are collaborating the neighborhood view must show all XOs working on an activity as shown here: <br>
D3 - Must show all XOs currently collaborating on an activity in the Neighborhood view. <br>
D4 - Should show the maximum scale and make it easily discoverable if there is capacity for additional XOs to join a collaboration.

A design for the view of all XOs which are collaborating the neighborhood is shown here: <br>


<br>
<br>
[[Image:neighborhood.jpg|center|thumb|640px|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.]]
[[Image:neighborhood.jpg|center|thumb|640px|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>

D5 - Once collaborating, must allow multiple XOs to simultaneously enter data (text or images). <br>
D6 - Must allow all XOs which are collaborating to see the data entered by other XOs. <br>


The following shows an example activity showing collaboration with the bulletin board. The icons on the right of the frame represent XOs currently collaborating on this activity. Once collaboration is started input to any XO must be visible on the all the XOs.
The following shows an example activity showing collaboration with the bulletin board. The icons on the right of the frame represent XOs currently collaborating on this activity. Once collaboration is started input to any XO must be visible on the all the XOs.

Latest revision as of 18:23, 26 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. This requirements definition is intended to show the main GUI elements and ways which XOs access collaboration. Most importantly, its written to set a test standard for scalability fo collaboration which allows us to define a minimum supported scale level.

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 icon below the XO icon shows the currently shared activity which other XOs can join.

D1 - Must allow the user to see available activities to collaborate on by navigating to the neighborhood with a keyboard press or frame selection.
D2 - In Neighborhood view must show available XOs and activities in a single view.

A design for the view of available XOs and activities is 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."


D3 - Must show all XOs currently collaborating on an activity in the Neighborhood view.
D4 - Should show the maximum scale and make it easily discoverable if there is capacity for additional XOs to join a collaboration.

A design for the view of all XOs which are collaborating the neighborhood is 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.


D5 - Once collaborating, must allow multiple XOs to simultaneously enter data (text or images).
D6 - Must allow all XOs which are collaborating to see the data entered by other XOs.

The following shows an example activity showing collaboration with the bulletin board. The icons on the right of the frame represent XOs currently collaborating on this activity. Once collaboration is started input to any XO must be visible on the all the XOs.

Bulletin-board.jpg

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.

N22 - Must support Read

N23 - Must support Etoys

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