Yep, we should have more complete documentation in English,

especially on the media objects. (E.g. the Japanese and Spanish

documentation includes translations of ours, plus some very good

stuff done in those languages in those countries.)

But the book "Powerful Ideas in the Classroom" is still a very good

idea as a starting point because most good Etoys are thought up as a

way to help children learn an idea (and generally not as a way to

learn a particular programming technique -- the programming style in

Etoys is different).

The tradeoffs are interesting. On the one hand it is pretty easy to

get 7th and 8th graders to do a dynamic ecology of fish and food

sources from scratch, whereas the AP version of this in high school

in Java is deemed difficult enough that the high schoolers don't get

to program it but are giving the programs to study and change parameters on.

Etoys is all about children being able to make fun working versions

of interesting ideas from scratch, and learning much more about the

ideas than when force-fed with them. Considerable thought on the part

of the children's mentors is often required to set up a curriculum

that is a nice balance between the way children think and do, the

ideas, and what is most natural to do in Etoys.

Basically, every object in Etoys "is the same" for most things, plus,

for some objects (such as playfields, etc.) there will be a few extra

categories in their viewers for idiosyncratic behaviors. Just poking

around and trying things (which is what the kids do) will reveal a lot.

For example, the "world" (the desktop object) is a kind of playfield,

and all playfields have a "playfield" category, and in this category

are variables that hold the mouse coordinates relative to that playfield.

Every script can do a loop in parallel with other scripts, so there

are an unlimited number of parallel behaviors possible. These scripts

can be controlled by other scripts (look in the "scripting" category

for each object). Typical loops can be done by initializing in one

script and then telling another script to start ticking (and this

script can have a test tile that can decide if the loop should stop, etc.).

A little context: Etoys is kind of a "demo that wouldn't die". It was

originally aimed for a particular age of children (from about 7-8 to

about 11-12) to be an authoring medium for fun projects that could

have an underlying "powerful idea" or two, that could be absorbed

Montessori style. So the goal was not to teach anything like standard

programming, but to make it easy for children to e.g. use and learn

the ideas of vectors, calculus, feedback, systems ecologies, media

models, etc., while pursuing projects that seemed fun to them.

Human beings (even really smart ones) have a hard time coming up with

ideas that are better than mediocre. For example, if you put a piano

in a classroom, the children will explore it, and develop a

"chopsticks culture" with it, but they won't invent for themselves

how to play a keyboard instrument (it took centuries for experts to

work it out). But every child can be taught to play the piano.

Similarly, the children will not invent or discover important ideas

in mathematics by themselves. But every child can be taught a

powerful version of the calculus of vectors, and many other kinds of

advanced mathematics. And both of these can be taught as a kind of play.

If you give children a medium to explore, they will generally wind up

doing stories and games with it (in large part because that is how

nature has set all of us up to learn when we are children). For

example, Etoys is used widely in a number of places in the world. The

places that emphasize "creativity", "discovery learning", "free

exploration", etc., all wind up with lots of stuff done by children,

but virtually all of it uses simple animations and multiple tasking

to act out stories and games. This is no surprise (it took humans

100,000 years to invent math and another 2000 to invent science). If

we are interested in having children learn non-obvious powerful ideas

-- e.g. in math and science -- we have to scaffold their learning and

discovery by careful curriculum design.

This teaching doesn't have to feel like the kids are being put in a

lock-step chain gang. It can be much more like teaching and learning

an established sport or musical instrument. There are parts that are

almost impossible to invent, and thus have to be shown and practised.

But with these parts there are large elements of free joyful play.

We suggest using at least 3 phases for each idea.

- The first is a guided creation of something interesting -- for

example, how to make a robot vehicle on the screen that will follow

edges. This can be done in a number of ways including Socratic

leading questions, but basically it is giving the children something

they would not think up for themselves. But as David Ausubel pointed

out "People learn on the fringes of what they know".

- Now that the children know something, they can be given a specific

challenge -- such as "Come up with a car and a road where the car

will stay on the road". There are 5 or 6 ways of doing this and most

children working singly or in pairs will find one of them. A few of

these are elegant, and a few children will find these. Sharing the

solutions as demos gives the children a sense that such problems are

not only solvable, but there is more than one solution.

- The third stage is open play, where the children now know enough to

think of many different fun ways to use what they've just done (and

many of their ideas will be in the forms of games or stories). For

example, some of the "middle of the road" solutions lend themselves

to making a multilane racing track with multiple vehicles and using

the random number tile to generate random speeds to make the race

difficult to predict.

The way we've set up Etoys is with a uniform rich object model and a

very simple set of scripting abilities, but with easy multiple

tasking. From this we've asked ourselves what projects that involve

powerful ideas can be relatively easily made from the simple

ingredients. There are lots, and they fill more than a school year's

worth of time. This is why the project based documentation is not

such a bad idea. It's worth while to look at the kinds of things that

have been done with the current ingredients, and this will help with

the different style of programming that is used.

However, children younger than 7 really need a somewhat different

interface. And children older than 11 need more ingredients (both

scripting features -- such as case based control structures, better

event structures, etc. -- and expression building features -- e.g. to

more easily build complex expressions from left to right instead of

just from the top down, etc.). We are going to do the latter over the

next year, and the former a year after that. But for (say) 5th

graders, the current set of materials seems rich enough (for powerful

idea purposes).

The documentation is going to get a little more useful and detailed

because Etoys will be on the "$100 Laptop" project of the One Laptop

Per Child organization ( http://www.laptop.org ) . The test builds of

this machine are just starting to happen, and we are starting to

write more detailed documentation on the OLPC wiki (

http://wiki.laptop.org/go/Sugar_EToys ). This is not worth looking at

today, but should have quite a bit of useful stuff a few weeks from now.

Please don't hesitate to ask more questions. We are happy to help.

Cheers,

Alan