[etoys-dev] (SQ-749) and Kathleen's question on "What do you mean by Artifacts?"

Steve Thomas sthomas1 at gosargon.com
Thu Aug 12 11:11:46 EDT 2010

I have been reading Alan Kay's Thoughts About Teaching Science and
Mathematics To Young Children<http://www.vpri.org/pdf/m2007003a_thoughts.pdf>

> I think one of the trickiest issues in this kind of design is an analogy to
> the learning of science itself, and that is *"how much should the
> learners/users have to do by themselves vs. how much should the
> curriculum/system do for them?"* Most computer users have been mostly
> exposed to "productivity tools" in which as many things as possible have
> been done for them. The kinds of educational environments we are talking
> about here are a*t their best when the learner does the important parts by
> themselves, and any black or translucent boxes serve only on the side and
> not at the center of the learning.* What is the center and *what is the
> side will shift as the learning progresses, and this has to be accommodated.
> *

By exposing everything in Etoys as "First Principles" (which in this
particular case I understand to mean, that we have a minimal set of
scripting tiles and objects from which everything can be built) we avoid the
"productivity tools" issue because everything is exposed.  It is also a
beautiful, elegant and exposes a powerful idea.

The challenge in a system where everything is done from "First Principles"
is that when you are designing an"educational environment"  "lesson",
or "Artifact" ( better terms might be "playthink" and/or "tool to think
with"), it can take a lot of work to build those preferably translucent
boxes.  And to paraphrase another Alan Kay quote on user interface design:
"If it takes one step I'll do it, If it takes two steps I might do it, if it
takes three or more steps forget about it!"

No, I am not arguing to make things easy for everyone, we need find ways to
get kids to have "hard fun." Hard work and ragging a problem are good
habits.  I also strongly believe that giving kids a "blank canvas" and a
great set of brushes and paints is an excellent and preffered method, but
not the only one we should use.

I am arguing (and struggling) with is how in a "First Principle" system like
Etoys, we can find ways to make it easier for teachers/designers (ie: make
them more productive).  I fear I see in some folks (none on this email list
of course) a tendency towards what I initially saw (and fell into myself) as
the constructivism trap. Where I encountered people who thought kids should
construct all knowledge themselves from Scratch (pun intended ;).  As I
recall Alan (and others pointing out) we can't expect kids to do that, they
will repeat the same mistakes people did over thousands of years. My initial
thoughts are a repository of Artifacts that teachers can use along with a
set of scripts (the problem with the set of scripts idea is that the scripts
in Etoys are not decoupled from the ?morphs? (not sure of the correct term
here, but basically the pixels visually representing the object). Bert's
idea that we have a Player Variable and the scripts that operate on it is a
good one, but I think there may be some bugs there, need to test more.

Now I will more directly address Kathleen's question: "What do you mean by
I will switch from "Artifacts" to the term "Playthinks" (which I encountered
in the "The Big Book of Brain
by Ivan Moscovich).
One of the best and simplest "Playthinks" for teaching I ever encountered
was Robert B. Davis' classroom warm-up (which I showed at Squeakfest and
have wrote about
 Basically it involves drawing on the board a 4 x 4 grid

. . . .
. . . .
. . . .
. . . .

Then having kids pick two numbers and using those two numbers as X and Y
counting from 0 at the origin point in the lower left and then If they land
on the board marking an X or O until one team wins.  Some of the keys to
this "Playthink" are:

   - you let kids puzzle it out for themselves, they figure out the rules,
   you don't tell them
   - it contains a powerful idea
   - it can be easily extended to other concepts (negative numbers, a number
   is all the ways you can name it, is this game fair ...)
   - *its fun *

Other examples of "Playthinks" would be cuisenaire rods, pentagrams, area
blocks, other good "virtual manipulatives" and my feeble attempts Circle
Explorer <http://www.squeakland.org/showcase/project.jsp?id=10212> and Pattern
Blocks and Tools <http://www.squeakland.org/showcase/project.jsp?id=10216>.

*Bert*, your comments on SQ-749 sparked my writing this, I will address it
more specifically in a separate email after some more thought.

Including *Alan* so he can correct any misinterpretations and hopefully

FYI: A lot of other excelent writings from VPRI are
most are Computer Science related but a number deal with educational issues
and Etoys.


On Thu, Aug 12, 2010 at 5:02 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> On 12.08.2010, at 10:32, Steve Thomas wrote:
> > On Thu, Aug 12, 2010 at 3:32 AM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
> >> This would likely be simple to implement, but could break existing
> projects. E.g. the morphing stuff in the showcase. Maybe you could take a
> look?
> >
> > Checked "Morphing" by Kazuhiro Abe and that should be fine. Each Polygon
> in the holder has the same number of vertices and the script simple changes
> the positions of the vertices one at a time.
> >
> > "The Walkers" and associated remixes by P.A. Dreyfus uses a special
> category "morphing" which would be great to get into Etoys (although I would
> suggest the addition of some way to show/manage the frames) to make the
> invisible more visible and to make it easier to create these kind of
> animations. Anyway, whether this would be a problem or not depends on how it
> is implemented.  If he stores complete information about the polygon in each
> frame, I see no problems. If he only stores differences and
> adds/removes/repositions each vertex that MAY cause a problem.
> >
> > Anyway if it is a simple change and you can make it, I think I can easily
> test the change by opening the project, then file-in the changes and see if
> anything breaks. Or you could also ask P.A. Dreyfus (master of polygon's and
> connectors) what he thinks as he knows and can check the changes against his
> implementation.
> >
> > Stephen
> Thinking about this more I do not like the proposal. It would makes the
> system less predictable.
> Having the new vertex remain at the same position is the only sensible
> choice. It matches the "copy" behavior of regular objects, which also appear
> in the same position. It would not scale anyway - see this image where I
> only inserted 4 vertices. The position quickly converges to the next vertex
> position.
> Also, I'd argue that "add a vertex at beginning" and "add a vertex at end"
> tiles are not needed in the first place. To be useful they would, as you
> noticed, have to be "set cursor to beginning and insert vertex" and "set
> cursor to end and insert vertex", because otherwise one cannot assign their
> position immediately. But that makes them perform two operations that are
> available separately. There is no good reason to coalesce those steps into
> one.
> In any case, inserting a vertex should not change the cursor. If you want a
> cursor change to occur, insert a tile.
> So my counter-proposal is: remove the "add vertex at beginning" and "add
> vertex at end" tiles. (to not break existing projects, the tiles would only
> be hidden)
> - Bert -
> _______________________________________________
> etoys-dev mailing list
> etoys-dev at squeakland.org
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakland.org/pipermail/etoys-dev/attachments/20100812/4f79d1bb/attachment-0001.html>

More information about the etoys-dev mailing list