[etoys-dev] The road ahead
bert at freudenbergs.de
Wed Oct 7 08:40:55 EDT 2009
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
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
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
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 :)
More information about the etoys-dev