[etoys-dev] The road ahead

[Bert Freudenberg]

As the current release cycle is nearing an end (yay!) it is time to  
start discussing where Etoys development should be taken in the next  
cycle.

Our largest user base are the close to a million children using OLPC  
XO-1 laptops. Existing users are whom we need to support first and  
foremost, enlarging the user base is second to that for now. IMHO they  
need a stable system, well documented, and with ample of examples,  
project ideas, curriculum etc. I could be wrong of course, so we need  
to find ways to ask them. But unless we hear otherwise, I think  
development work in the next release cycle should focus on these three  
areas:

* Documentation
* Translation
* Usability

Users (teachers in particular, see Mel's post [*]) do not appreciate  
arbitrary UI changes. Neither are they helpful to documentation  
efforts. So any change to the UI should be done only to enhance  
usability, not simply to make things "prettier". Adding features is  
not as problematic as changing existing UI (e.g., we plan to add  
DrGeoII) but we should let the educators guide those.

The basic UI (tool bar, halo, flaps, viewers, scriptors etc.) should  
only see carefully chosen alterations to not get out-of-sync with  
experience and documentation. To make Etoys more inviting, we could  
(and maybe should) revamp the Home screen and the example projects.  
These can be contributed by non-developers (we need to make sure they  
are MIT licensed, so we can't simply take showcase content).

The majority of our users do not speak English as their first  
language. Having documentation, the Etoys UI, and example content  
translated to their native languages is of utmost importance.

The current huge translation template (POT) needs to be broken up to  
make it simpler to handle for translators. Also, it would give them  
guidance what areas they should tackle first (e.g. Etoys tiles are  
more important to translate than Smalltalk code tools). Projects need  
a mechanism to export and import translations so they can be  
translated independently.

To help documenters, an idea is to automate taking screenshots. A  
project could be made that iterates through all tiles, buttons, menus,  
etc. and does screenshots, saving them under a systematic name. It can  
also iterate through languages so we have localized screenshots. At  
the end of a release cycle, this could be used to automatically bring  
all documentation up-to-date.

Speed is an issue as it hampers usability, in particular on the XO-1.  
The cheapest speed-up we can get is the one we don't have to work on  
ourselves. That means moving closer to the Squeak.org releases. One  
major improvement should come from switching to Cog, a new Virtual  
Machine with considerable speed gains. We need to make our image and  
projects "closure-safe" for that.

We also lost speed - try our current release on an XO vs. the one that  
was shipped. At least startup is much slower now. It should not be  
impossible to get that speed back, though it may be hard. I have not  
heard plans to upgrade the OS in existing OLPC deployments but we  
should plan for that (and not just rely on the speedier XO-1.5).

Anyway, that's just my 0.02 €, to get the discussion going.

- Bert -

PS: A meta-change is that the "old" developers (Scott, Yoshiki, yours  
truly) will stay out of actual development as much as possible, and  
assume more of a mentor role. Development is going to be driven by  
whatever work is volunteered, screened by the software team (a.k.a.  
committers). So please keep the contributions coming :)

[*] http://lists.sugarlabs.org/archive/iaep/2009-September/008448.html