[Date Prev][Date Next] [Thread Prev][Thread Next]
[olpc-software] Use cases and design scenarios for software handling
- From: Mike Hearn <mike plan99 net>
- To: OLPC Software List <olpc-software redhat com>
- Subject: [olpc-software] Use cases and design scenarios for software handling
- Date: Wed, 15 Mar 2006 16:19:22 +0000
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
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
+ 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
* Historically users have had problems understanding an explicit
uninstall process: see the way Windows warns you when deleting
application shortcuts from the desktop.
* 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
* 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
+ (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
+ 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
* 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?
[Date Prev][Date Next] [Thread Prev][Thread Next]