[Squeakland] Lack of documentation frustrating
alan.kay at squeakland.org
Tue Oct 31 21:08:58 PST 2006
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
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.
At 12:12 PM 10/31/2006, Guyren Howe wrote:
>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
>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?
>Squeakland mailing list
>Squeakland at squeakland.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeakland