<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: I want to document but I need to learn
first!</title></head><body>
<div>Jerry --</div>
<div><br></div>
<div>I think you should first separate out the Squeak system -- an
experimental version of Smalltalk that is quite beyond the scope of
this list, which is for parents and teachers -- from the Squeak
"Etoys" which is aimed at children and *is* discussed on
this list. So complaining about 2000 posts to SqueakDev on this list
is just confusing for most of the folks here -- it's like complaining
that LISP is big and comprehensive -- it's not an enduser system,
etc.</div>
<div><br></div>
<div>I will confine myself to the tradeoffs with the Squeak etoys.
First, we really do need better documentation, even for a system that
is still being tested by us. We have found that it takes about 3 years
in a classroom to get a good set of tests and we are just now in that
3rd year. The results of these 3 years have been written up by teacher
BJ Allen-Conn and Kim Rose in a "book of 10 projects" --
they have done a great job! -- and drafts of this book will be
available online not too far in the future. Another terrific
contribution is from Sebastian Hergott's 8th grade class in Toronto.
They did lots of projects and he got them to write them up as
documented examples. These two books together supply lots of examples
and should help to bridge some of the gaps in documentation.</div>
<div><br></div>
<div>However, I should say a little about the history of etoys. They
were originally not aimed at classrooms but as 10-20 minute projects
supplied on the web for parents and their children to do together. I
stripped out as many features as I could and tried to come up with a
system that could do "100 examples" pretty
straightforwardly. The documentation that was intended here was to
have been to teach parents how to do the examples so they and their
kids could have a good experience. For several reasons, this plan did
not work out at Disney. But BJ saw it and wanted to try etoys in her
5th grade classroom. I was initially against the idea because I
thought that etoys were not complete enough for that venue. But she
and Kim Rose decided to do it anyway. Six weeks later they started to
show me some really good results, and I realized that it would be
worth doing a 3 year experiment to see how well the etoys -- even with
some of their lacks -- would work out with 10 and 11 year olds.</div>
<div><br></div>
<div>The results have been excellent -- in the proper environment most
children have no trouble getting joyously creative and fluent -- and
hence the forthcoming book by BJ and Kim to help other teachers and
parents achieve the same results.</div>
<div><br></div>
<div>Our previous plans to make a kind of "superhypercard"
and then get version 2 of etoys from that much more comprehensive
design did not work out at Disney, and it wasn't until recently that
we've been able to get that plan going again. I think this is more
like the system you want, and you'll have a chance to try it out this
summer.</div>
<div><br></div>
<div>To zero in on a real critique of today's etoys, it is helpful to
confine discussion to 10 year olds and up, since essentially all the
experience that we and others have had are in this age range. The
etoys have changed very little in several years, in part because of
the testing that is going on, so comments such as "too fast
moving" really have to do with the larger Squeak community over
at www.squeak.org. Here I think the problems are not so much lack of
documentation as lack of particular kinds of documentation, such as
detailed tutorials and project workbooks. The user-tested books
mentioned above should help this.</div>
<div><br></div>
<div>Let me turn to another area, and tell a story that I witnessed
recently. I was visiting a classroom with a really terrific teacher,
who was truly ecstatic when his children could figure out something
before him (we need more of these kinds of teachers!). But he brought
up a problem that he couldn't see how to do. He wanted to general
random colors, and had seen that the red, green and blue blends are
given in the color picker. In etoys colors are not manifested as three
numbers (we possibly should, but don't) though they are in the larger
Squeak system (and in many other ways). So he didn't see how to make
up colors, especially random ones. My thought was to put a bunch of
objects (such as ellipses) into a holder, give them different colors
and then do random picking by moving the cursor</div>
<div
> <span
></span> holder's cursor <- random</div>
<div>to get an object whose color can be gotten at.</div>
<div> We did that and he was happy. But then
we saw a child who came up with a much better way to do this. He just
put splotches of paint on the desktop and ran a Squeak player (like a
car) over the splotches in a random "drunkard's walk" and
used "color under" to pick up the color as a value.</div>
<div> My thought on seeing that was that it
was the child who found the "etoys way" of solving this
problem, and that the general solution in this fashion would involve
using the color rainbow of a color picker to supply a wide range of
colors for the car to wander about on.</div>
<div> My second thought was that both the
teacher and I were somewhat trapped in our pasts. The teacher had done
something with color numbers in the past and wanted to do it again. I
went to a table lookup solution that I had done many times in the past
for other kinds of problems, and this worked. The child went at the
heart of the matter with a completely simple and concrete approach
that was quite brilliant and original.</div>
<div><br></div>
<div>One of the reasons I'm telling this story is that today's etoys
-- that lack a wide and comprehensive range of features that
"they should have" -- are best approached through the kinds
of projects that *can* be done really nicely using the features that
are there. There are more than enough such projects to occupy a full
year (really more like 3 years) of work and play by children. As for
the larger scope that is eventually needed, I'm hoping we can
accomplish this by the time today's projects are used up.</div>
<div><br></div>
<div>Now to another one of your comments in yesterday's email. You
wrote:</div>
<div>At 6:44 PM -0800 3/10/03, Jerry Balzano wrote:</div>
<blockquote type="cite" cite>Get a load of these (the total
"partial" list was almost 40 lines long):</blockquote>
<blockquote type="cite" cite><font face="Courier New" size="+1"
color="#000000"><br>
Orbits<br>
Springs<br>
Weighing<br>
Gradient following - Salmon and Clownfish<br>
Tree Growing<br>
Epidemics<br>
Multiple Mentalities<br>
Grey Walter Conditioned Response Learning<br>
Circuit Models</font></blockquote>
<blockquote type="cite" cite>Anyone who could create projects like
these in any programmable medium, I'd say, would have a serious leg up
on "real" programming by anyone's hard-nosed definition of
that elusive (and ever-changing) concept.</blockquote>
<div><br></div>
<div>I think I agree here. I've done each of these strictly in etoys
to see what the process is like and to understand how one would
explain the process to both teachers and children. Most of these
projects are aimed at older children (such as Sebastian's 8th graders
and older), and I think are quite doable, but they haven't been tested
yet with adults and children of a good age and mindset. Just to
provide a few more comments on some of these:</div>
<div><br></div>
<div>*Orbits* is easily done in etoys if you understand Newton's
inverse square law, vectors (and that each etoy player -- like a logo
turtle -- is a vector and can do vector arithmetic). The script that
does the work is about 4 lines of tiles long and is a pretty direct
translation of the inverse square law using "increase by" of
vectors. It's a very clean script.</div>
<div> Here quite a bit has to be worked up to
for most teachers and other adults. There are hurdles of mathematics,
science, and learning more about how to use etoys. The scaffolding
would require many projects to be done earlier, including the
accelleration and gravity projects that were easily done by BJ's 5th
graders. I think a good next one is to do a spaceship floating in
space without a gravity field to get a sense of how velocity is often
(usually) in a different direction than the ship is pointing.</div>
<div><br></div>
<div>*Springs* are fun to do, and easy to script in etoys if you go
through the exercise of deciding that the force on a spring is
proportional to the displacement and in the opposite direction. I
think there is quite a bit of scaffolding needed to do the science
part.</div>
<div><br></div>
<div>*Weighing* is part of doing a real roller coaster in etoys. An
insight is required here. Most people get stumped about needing sine
and cosine, etc., to find the forces on an inclined plane. But in
fact, you can "weigh" them using a postal scale on an
inclined scale. You can make up a simple table -- using a holder -- of
the forces every few degrees and this is quite good enough to make a
real roller coaster in etoys.</div>
<div><br></div>
<div>*Gradient following* If you make a gradient using the graphic
properties sheet you can do tests on it using "Brightness
under". This allows a simple feedback program to be written (very
much like the follow the road ones) that will cause a simulated object
to follow and find the darker or lighter regions of the gradient.
(Gradient following is a feature in starLogo, but I think people
should learn about it by actually scripting it.)</div>
<div><br></div>
<div>*Tree Growing* Most people have cognitive difficulties with
recursion, but one nice way to look at trees is recursively. This is a
conflict. Because etoys can make new objects via copies (see below) it
is possible to bypass recursion altogether in favor of a branching
activation. This turned out to be a very clear script and a good model
for other kinds of "recursion changed to branching activation"
problems.</div>
<div><br></div>
<div>*Epidemics* have a wide range. The easiest ones are just having
infected objects bump into noninfected ones and transmit the
infection. This is just a few lines of script to do.</div>
<div><br></div>
<div>*Multiple mentalities* comes from the Vivarium work we did 15
years ago. Here we have separate scripts or even objects that
represent parallel and mostly independent drives of the simulated
animal. The main thinking that is needed is to figure out which of the
drives should be allowed to control the animal. This is easy for two
(a simple comparison) and needs something like a sort for more (it is
actually just looking for the one with the largest
"urgency", so it's a matter of using the "max"
operator to perculate the largest urgency one in a holder.</div>
<div><br></div>
<div>*Grey Walter* conditioned reflex learning model. Here it is hard
to guess about the appropriate age for this wonderful etoy. My guess
is high school since Grey Walter's model is nicely subtle. (He did
this with a single vacuum tube in 1949, so parsimony was the order of
the day. He got all of his power from very careful reasoning and clear
thinking about a simple model to do this.) Once you understand how he
did it (I made a diagram to show the 7 steps you have to go through)
it was quite easy to do in etoys and generated a nice set of dynamic
graphs for the animal's "state of mind".</div>
<div><br></div>
<div>*Circuit Models* I've not quite figured out an appropriate
approach here. One way is to use the connectors stuff of Ned Konz and
propagate signals though his objects. Several folks have done this,
most notably a high school student who is working with us -- he went
to the heart of the matter and decided not to do batteries and bulbs
per se but to see about simulating logic.</div>
<div><br></div>
<blockquote type="cite" cite> My students (same ones as above)
wrote programs in NetLogo, Microworlds (a descendant of
Logo),</blockquote>
<div><br>
This is a product<br>
</div>
<blockquote type="cite" cite>and Stagecast Creator</blockquote>
<div><br></div>
<div>so is this. Etoys is an experimental system that is still quite a
ways from being a finished packaged product.</div>
<div><br></div>
<blockquote type="cite" cite>, including a "Turtle Epidemic"
model in NetLogo for which I wrote the tutorial (see
http://ccl.northwestern.edu/netlogo/resources.shtml) and a "Food
Fight" game in Stagecast Creator, for which I'd love to be able
to write the "etoys tutorial", if I could only see how to do
several simple things in Etoys, for example</blockquote>
<blockquote type="cite" cite> * have an agent (smiley) create
another agent (burger) in the space next to him</blockquote>
<div><br></div>
<div>Let's suppose that smiley is in a playfield called
"fastfood".</div>
<div><br></div>
<div>smiley create</div>
<div> smiley's temp <- burger copy</div>
<div> fastfood include smiley's temp</div>
<div> smiley's temp's x <- smiley's x + 25</div>
<div> smiley's temp's y <- smiley's y</div>
<div> </div>
<div>I found "copy" and "include" just by going
through the views of the two objects and seeing what the balloon help
told me. This is the documentation that is there, but most people
don't use it. I found that I could make a player valued variable by
looking at the menu item "change data type", etc.</div>
<div><br></div>
<blockquote type="cite" cite> * have an agent (smiley) send a
message to a counter agent (count down) each time he "uses up"
a burger, and another message to a counter-scorer agent (count up)
each time one of his burgers hits his opponent</blockquote>
<div><br></div>
<div>burger scoring</div>
<div> Test burger's color sees <color of boundary></div>
<div> Yes smiley's score decrease by 1</div>
<div> Test burger's color sees <color of opponent></div>
<div> Yes smiley's score increase by
1</div>
<div><br></div>
<blockquote type="cite" cite>...just to name two.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>So, speaking of "viable learning
paths", does anyone have a suggestion for one for *me*? Who
wants to respond to all the questions my teacher-students raised in my
field notes?</blockquote>
<div><br></div>
<div>I do.</div>
<div><br></div>
<blockquote type="cite" cite> Who wants to help me complete all
the projects on Alan's list?</blockquote>
<div><br></div>
<div>I have done these projects. I need help in explaining them in a
way useful to parents and teachers.</div>
<div><br></div>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>If *I* can't figure out how to do this
stuff on my own, there's no way any of the teachers I teach -- even
after they've been thoroughly Balzano-indoctrinated to the virtues of
programming and completed my
more-rigorous-than-99%-of-other-teacher-ed-computer-courses course --
will be able to figure it out either.</blockquote>
<div><br></div>
<div>I don't necessarily agree here, but your point is well taken. I
think that quite a bit of success for different kinds of people is the
match up between types of thinking, types of motivation, and the kinds
of materials and scaffolding available. Some teachers have been
amazingly successful with our inadequate documentation and others have
been less successful that one would expect, given the amount of
documentaiton that is there. Many children who like to explore and
don't want to read documentation have done even better. Some children
are quite stumped without explicit help (but that's what teachers are
supposed to be for.)</div>
<div><br></div>
<div>But the clear lesson is that we need to provide enough coverage
for a wide range of styles of learning. Please continue to be
interested and to help.</div>
<div><br></div>
<div>Cheers,</div>
<div><br></div>
<div>Alan</div>
<x-sigsep><pre>--
</pre></x-sigsep>
</body>
</html>