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