[olpc-software] Use cases and design scenarios for software handling

[Mike Hearn]

Chris mentioned on IRC we were all getting distracted by the details
instead of concentrating on designing experiences. Fair point, my fault
too, I jumped in with some pre-baked notes on a package management
alternative.

Here's a list of use cases (+) and design requirements (*). What do
people think? Is this list a good start?

----------------------------------------------------------------------

+ A teacher talks to his colleagues and learns of a new program
  useful for showing kids maps. When he gets back to his home town, he
  vaguely recalls the name of it, but nothing else. How does he try it
  out for himself in preparation for a class?

    * Teachers should be using same laptops as the students?
    * Teacher must be able to quickly locate the software they want.
    * It may be that the name is not "natural" for his native tongue,
      and so there needs to be high quality search (eg soundex     
      matching, spelling correction)
    * Once found, the teacher must be able to download the software onto
      his laptop from the internet quickly and cheaply.

+ The teacher goes offline because he wants to try the program out in 
  the privacy of his home. 

    * The software must work correctly offline. 
    * The teacher must not find that the software is missing that vital
      feature he heard about because he is missing some optional
      component/because the package he got was built wrong/because he
      is using an older build of the distro than his colleagues.

+ Students arrive at school, and the teacher decides the use the
  program. Either the teacher needs to be able to push it to the
  students, or the students need to be able to easily find it on the
  network and pull it themselves.

    * Minimal storage should be used on the laptop.
      This means the system must be smart enough to only transfer
      translation files for the languages the students need.

    * However, no tech support or sysadmins are available, so robustness
      and usability should take precedence over efficiency.

+ The students leave the class and go home. The program was cool
  (imagine a less demanding Google Earth) and they want to use it when
  they get back home.

    * Ideally no explicit action would be needed to ensure the program
      is still available when no longer physically near the teacher.
      But transparently "installing" or caching software ZeroInstall
      style has another issue:

          + Some students aren't interested in geography at all. They
            don't want to run the program, and would rather the storage
            be available for something else.


+ Some kids who weren't at that class want to play with the program too.

    * Kids must be able to easily share software. 

    * They may be using different generations of the laptop: if the
      program requires a specific generation to run then it must be
      extremely obvious and easy to understand that this is the case.
   
    * We cannot and should not expect any knowledge of dependencies 
      or package management technologies. Sharing should either Just
      Work or fail because the laptop is not new enough. Failing due
      to conflicting packages, namespace conflicts, or other UNIX 
      esoterica is not acceptable.


+ Time passes and a new version of the geography program becomes
  available.

    + Perhaps the teacher is no longer using it. Kids may want to
      upgrade it themselves.

    + The teacher may wish to distribute an update so they can use
      the new features in class

    * The upgrade process should use minimal bandwidth. It's easy
      to imagine with a geography app some files changing and others
      not: a minimal changeset should be transmitted over the 'net.

    * Kids should be able to share upgrades as well. Ideally again
      by swapping minimal changesets.


+ New days and new challenges arrive, the geography program is no
  longer needed.

    * Historically users have had problems understanding an explicit
      uninstall process: see the way Windows warns you when deleting
      application shortcuts from the desktop.

    * Either:

        * It must be easy for kids to see where their storage is going, 
          and to free up space by removing things they no longer care 
          about.

        or

        * Software should be dropped/re-downloaded onto storage
          automatically in a ZeroInstall sense.
   
    * Whatever implementation is used, it's unacceptable for software
      to leave any cruft behind at all. When the user no longer has any
      way to access a program from the user interface, it must not be
      taking up any storage on the system. It is unacceptable for the
      operating system to "degrade" over time in the way Windows tends
      to.

+ (Potentially) A smart/motivated student gets hold of an SDK somehow
  and writes the next Tetris. She wants to share it with her friends,
  and maybe publish it on the internet as a whole.

    * Ideally, it must be extremely trivial to distribute software built
      using the SDK. Best case scenario, there's no work to do at all.

    * Certainly we should try and shield student developers from all the
      horrid issues Linux software distribution normally implies
      (dependencies, ABI stability woes, GPG keys etc).

    * The laptops are unlikely to support good development tools. Some
      kind of wireless headless add-on cube thing (basically wireless 
      terminal server in a box) could maybe solve that: all the
      developer tools and compiler power are held on a relatively
      expensive community-owned core and the laptops can use it via the
      mesh. Similar concepts could provide local Wikipedia copies and
      other geek-utopia ideals :)

+ Some educational developers want to write software for this huge new
  market. Nearly all full time educational developers currently work on
  either Windows or the Mac, usage of tools like Macromedia Director
  is very common (worked for an educational software company using Lingo
  myself a few years ago!).

     * How do we bring these people onto the OLPC Linux platform?
     * How do these people deal with versioning their software such that
       it is easy to obtain and works across multiple generations of
       laptop?

     + There is no equivalent to Director or other common authoring
       tools on Linux. Let us imagine somebody meets this need, and 
       much software is produced that depends on a specific runtime.

           * Can we reduce duplication of this dependency whilst 
             simultaneously preserving just-worksness? What alternatives
             are there? What about compromises that combine efficiency
             with just-worksness?

           * Worst case scenario: the runtime has some weird license.
             Is there any support in the software distribution system
             for handling policies like "only 5 licenses may be in use
             simultaneously"? Or is that a headache only western
             educational groups have to deal with?


OK, that's a pretty big list :/ Anything I missed or got wrong?

thanks -mike