[Squeakland] Lack of documentation frustrating

[Alan Kay]

Hi --

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



At 12:12 PM 10/31/2006, Guyren Howe wrote:
>Hi,
>
>I am volunteering at a local school, and will be doing squeakland
>once a week with some fifth graders.
>
>Squeakland (etoys?) seems ideal for these kids, except that I'm
>frustrated by the lack of documentation.
>
>I've spent ages looking through the website and searching online, and
>I can't really find the kinds of things I'm looking for. I went
>through some of the tutorials myself, and those will be great to get
>started, but I would like to give the kids fairly free reign, and be
>able to answer most of their questions. I tried to do some little
>projects myself, but I kept coming up with seemingly simple things I
>wanted to do, and not finding any obvious way to do them (or,  as I
>say, any documentation suitable for answering the questions).
>
>For example: I wanted to make an etoy follow the mouse pointer
>around. I can't see any way of even obtaining a reference to a mouse
>object.
>
>I would also like to do loops and suchlike. Not obvious how to do that.
>
>I can see that if I can dive down into the smalltalk level, I could
>do it, but this seems like the kind of thing that's probably at the
>squeakland (etoy? What do I call the kids' environment?) level.
>
>But as I say, what I'm really looking for is not this particular
>fish, but how to fish for myself.
>
>I would buy a book, but the one pointed at from the website appears
>to just be a set of projects, rather than the kind of documentation
>I'm looking for. Squeak: Learn Programming by Controlling Robots
>looks like it might be sort of what I'm looking for, although I'm
>interested in a broader range of Squeakland projects than just the
>turtle graphics mentioned in the summary of the book.
>
>So: where is the documentation it seems ought to be there?
>
>Thanks.
>_______________________________________________
>Squeakland mailing list
>Squeakland at squeakland.org
>http://squeakland.org/mailman/listinfo/squeakland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://squeakland.org/pipermail/squeakland/attachments/20061031/88230c73/attachment-0001.htm