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
On Wednesday 07 Oct 2009 6:10:55 pm Bert Freudenberg wrote:
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
One cannot take functional literacy for granted in schools across the globe. The challenge in documenting a dynamic medium like Etoys for non-English audience is in moving from a traditional linear textual format to a visual format. Short video clips (2-3min clips) or screen recordings work much better than printed text. Children absorb a lot by watching others and imitating them.
Subbu
On 07.10.2009, at 17:21, K. K. Subramaniam wrote:
On Wednesday 07 Oct 2009 6:10:55 pm Bert Freudenberg wrote:
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
One cannot take functional literacy for granted in schools across the globe. The challenge in documenting a dynamic medium like Etoys for non- English audience is in moving from a traditional linear textual format to a visual format. Short video clips (2-3min clips) or screen recordings work much better than printed text. Children absorb a lot by watching others and imitating them.
Subbu
Good point - though I didn't actually say *written* documentation ;)
But how would that affect software development, which is the main topic of this discussion?
My idea of automating localized screenshots might be extended to screen recordings, which could be used to automatically have videos localized (the visuals anyway). Voice-over still needs to be done separately for each language.
Screen-recordings with Speex-compressed voice-overs may be space- efficient enough to include with Etoys. Just ASMOP ;)
- Bert -
Great. Thanks Bert!
In regards to my "staying out". From the beginning of this year, I was appointed to serve the software board for one year and is supposed to vacant the position at the end of this year. Its purpose was mostly to get more developers to work on Etoys and make the transition.
And, this is a good time. I see many capable people and actual patches are coming. While there are bug tickets and issues that may have been nominally assumed to be mine, there are people who can do it (and do it better). Please attack them without worrying about overlapping efforts.
Thank you!
-- Yoshiki
On Oct 7, 2009, at 5:40 AM, Bert Freudenberg wrote:
...
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 :)
On Oct 7, 2009, at 9:39 AM, Yoshiki Ohshima wrote:
Great. Thanks Bert!
In regards to my "staying out". From the beginning of this year, I was appointed to serve the software board for one year and is supposed to vacant the position at the end of this year. Its purpose was mostly to get more developers to work on Etoys and make the transition.
And, this is a good time. I see many capable people and actual patches are coming. While there are bug tickets and issues that may have been nominally assumed to be mine, there are people who can do it (and do it better). Please attack them without worrying about overlapping efforts.
I've agreed to stay on one more year on the Squeakland, Inc. board to help smooth the transition (though if a more appropriate volunteer steps forward, I'm quite willing to step down at the end of this year.)
In any case, like Bert and Yoshiki, I intend ("as much as possible") to stay out of the actual development process from now on.
So... etoy developers of the world: your moment has arrived! It's very gratifying to see that several people have already stepped forward; may the community grow and flourish!
-- Scott
etoys-dev@lists.squeakfoundation.org