Why is Scratch more popular than Etoys?

> Alan Kay wrote:
>> [...]
>> Then we handed Etoys over to the Squeak Foundation, and the version
>> they put out online retains the classroom UI with flaps.
>
> Actually, that would be the Squeakland Foundation. But in the Squeak
> Board at least Bert and I try to represent the interests of the Etoys
> (and Scratch) users.
>
> One reason for Scratch's popularity is the restrictions they have made
> which upset some people in the OLPC community. Etoys, on the other hand,
> suffered from some of the problems that open source projects have -
> students and teacher become very upset when some project they have
> created won't load into a newer version of the system. Note that I am
> fully on the side of Etoys here, but we have to be aware of the costs.
>
> It is interesting to me that Scratch's explict loops (compared to Etoys'
> clock driven scripts) don't seem to cause any difficulties for beginners
> nor for young children. That shows how important it is to test stuff
> rather than follow our intuitions.
>
> What I would really like (in the sense that I am trying to get funding
> to pay a group of people to build) would be a system within
> Croquet/Cobalt that would start out like Scratch, then become more and
> more like Etoys as the programmer's skills improved with a smooth path
> all the way to the Smalltalk level.
>
> Jens Mönig, the guy who did BYOB (Build Your Own Block extension of
> Scratch), also created Elements, which is a Scratch syntax for
> Smalltalk-80:
>
> http://www.chirp.scratchr.org/blog/?p=24
>
> So it is easy enough to see how far this approach can scale.
>
> -- Jecel
>
> _______________________________________________
> squeakland mailing list
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/squeakland
>

> I also looked at these two web forum pages discussing programming for
> kids pages today but not much love for Etoys:
>
> http://pozorvlak.livejournal.com/169225.html
> http://www.reddit.com/r/programming/comments/kgbzq/why_we_should_teach_our_
> kids_to_code/
>
> There seems to be a mismatch from we perceive as values and strong
> features of Etoys and what other people see.  Why do we not get the
> ideas out? What makes is so hard ? Do people test Etoys and drop it ?

> On Friday 16 Sep 2011 3:06:34 AM karl ramberg wrote:
>> I also looked at these two web forum pages discussing programming for
>> kids pages today but not much love for Etoys:
>>
>> http://pozorvlak.livejournal.com/169225.html
>> http://www.reddit.com/r/programming/comments/kgbzq/why_we_should_teach_our_
>> kids_to_code/
>>
>> There seems to be a mismatch from we perceive as values and strong
>> features of Etoys and what other people see.  Why do we not get the
>> ideas out? What makes is so hard ? Do people test Etoys and drop it ?
> Etoys requires people to think hard before putting ideas onto a project. This
> raises the barrier for students and journalists working against a deadline
> ;-).
>
> Another aspect of Etoys will become apparent if you get kids to use Etoys in a
> language foreign to them (or say in dingbat fonts). Though the UI is graphical
> it still has a heavy text bias. I noticed this when helping children,
> illiterate in English, use Etoys. Painting lacks the directness of other
> Morphic ops like move, pickup etc. Beginners tend to the leave the Paint Tool
> on while saving their project. We could do more in simplifying the UI. For
> instance, compose sketches by long-pressing (embed) one Morph on another.
> Suzanne Guyader, author of Art and Etoys, had many nice ideas for easing
> compositions.
>
> What Alan proposed about going beyond Scratch and Etoys in an earlier mail
> rings true from my own experience. I would throw in Tuxpaint into the mix.
> Tuxpaint uses sounds very well. We need something that takes the best parts of
> Etoys, Scratch and Tuxpaint and build a new Idea editor.
>

> About programming for the masses, I see two educational reasons to
> insist on that. One (rather weak) reason is to demystify something that
> is everywhere. People will be dealing with software all the time and if
> having done one or two toy applications as a child makes them see that
> it is not magic then that is nice.
>
> A much better reason is Papert's: so the children will have an object to
> think with. The idea is to learn to learn but we need a suitable way to
> talk about learning strategies. Normal school tends to encourage a very
> poor strategy: take a guess, see if the teacher confirms it is right and
> if not take another guess. Not only is the search time long and
> unbounded, you also need some external way of checking your results
> which is something you won't always have.
>
> Teaching programming is just a way to be able to teach debugging, or
> successive approximation. You don't throw away incorrect attempts but
> instead build on them. And you learn to figure out for yourself if they
> are correct or not, and how far and in what way they are incorrect so
> you know what to change.

> On Monday 19 Sep 2011 2:27:55 AM Jecel Assumpcao Jr. wrote:
>> About programming for the masses, I see two educational reasons to
>> insist on that.
> The debates about programmin I encounter is usually around "how" and not
> "why".
>> A much better reason is Papert's: so the children will have an object to
>> think with. The idea is to learn to learn but we need a suitable way to
>> talk about learning strategies.
> Papert had a multi-modal approach to develop thinking skills in children -
> using large spaces, physical movement, manipulation in three- and two-
> dimensional spaces etc. Etoys collapses everything to a single dimension -
> left-to-right sequence in tiles and top-bottom in scripts.
>
> Papert's methods were more closely aligned to the way children think and act
> while the gap seems to be much larger in Etoys and smaller in the case of
> TuxPaint or Scratch. There is lot more in Etoys than in these two but that is
> irrelevant if children cannot cross the initial chasm. Yes, a few children may
> make it across the chasm on their own steam, but thinking tools should be
> designed to benefit 80% of children, not just the top quintile.

> Steve,
> Wow! Thanks for putting this together!
> A comment before I go to work. . .
>
> Have you noticed that the education system is quite resistant to change? It
> has become more resistant and rigid in the past few years with the national
> emphasis on testing basic skills. This emphasis has devalued creative
> thinking by students and by their teachers. The timelines, benchmarks,
> pre/post tests and the high stakes spring test marathon for our children
> consume huge amount of time in schools days that are already quite short and
> an academic year that has not increased to take advantage of the fact that
> we are no longer an agrarian society.
> I am certain Etoys need to be in schools but I don't think programming is on
> the national agenda. Some schools don't even teach art and music which have
> long traditions but are considered frills rather than essentials.
> Regards,
> Kathleen
>
>
>
>
> ________________________________
> From: [hidden email] [[hidden email]]
> on behalf of Steve Thomas [[hidden email]]
> Sent: Tuesday, September 20, 2011 12:10 AM
> To: iaep; squeakland; [hidden email];
> [hidden email]
> Subject: Re: [squeakland] [IAEP] Why is Scratch more popular than Etoys?
>
> Thanks to all for an interesting discussion, I would like to review what I
> got out of discussion along with some comments and questions:
> On Fri, Sep 2, 2011 at 11:03 PM, Cherry
> Withers <[hidden email]> wrote:
>>
>> When I did my workshop on Etoys in the Philippines back in June, one kid
>> did a "draft" of the same project in Scratch first using the pre-installed
>> cliparts then did it in Etoys like I asked.... For him the pre-installed
>> cliparts made it easier for him to jump right into programming rather than
>> spend so much time drawing things. However, some kids derived more
>> satisfaction in using their own drawings.
>
>  To me, while it is important for kids to draw, I have seen kids who start
> using the clip art in Scratch and then get into the drawing. Also I have had
> kids using Etoys who did not feel comfortable with drawing and got "stuck"
> trying to do the drawings, until I either told them it was okay to use any
> drawing and they could change it later, or showed them how to "import' a
> drawing into Etoys, by dragging it in from a browser or Scratch Clip Art
> folder.
>
>>
>> Incidentally, no one taught the child how to use Scratch and he didn't use
>> it fully (never did a project in Scratch) till we got into conditional
>> statements in Etoys.
>
> This is perhaps the greatest compliment for the design of the Scratch UI and
> a goal (not for all things, but at least for the getting started part).
>>
>> He started drawing parallels with Etoys. On our 2nd and 3rd day, he would
>> always create his draft first on Scratch then do things in Etoys. It was a
>> lot easier for him to "find" things in Scratch he says.
>
> Love IT!!!  Kids should learn multiple languages and the ability to switch
> between two languages is a wonderful skill that should be encouraged and
> taught.
>
> On Fri, Sep 2, 2011 at 11:31 PM, Hilaire
> Fernandes <[hidden email]> wrote:
>>
>> Behing the more eye candy aspect of Scratch,  Scratch is also
>> better ergonomically with a more structured UI helping confort of the kids:
>> color scheme, predefined purpose area.
>
> Agreed the use of eye candy (which I take to mean great clip art that is
> attractive to the intended audience, in this case kids, but if you had one
> for adults, you could have different clip art), color and a more structured
> UI (which I take to mean a UI that helps guide the user as to intended use
> and understanding) is good.
> One thing I think could be improved upon in the Scratch UI is something that
> allows for what I will call the "Etoys Challenge" design where a few
> scripting tiles are placed on the world for the user to choose from to solve
> a particular problem. This helps avoid the too many choices cognitive
> overload and gets them to focus on what you want them to learn.
> The Etoys Challenge design I think is actually a potential "low floor"
> enabler to help kids get up to speed (although I think other ideas like
> picking a few tiles for each child to explore and become and expert in so
> they can teach the rest of the class, is also a good idea that does not
> require interface changes).
>>
>> However, Etoys and Scratch are very differents in purpose for me, so
>> not really competing.
>
> Agreed and along the lines of the work of Mark Guzdial and the great
> Spaghetti Sauce makers (plain, spicy, thick and chunky etc.) we need to have
> multiple environments for different learners (no I did not say different
> learning styles).
> On Fri, Sep 2, 2011 at 11:33 PM, Alan Kay <[hidden email]> wrote:
>>
>> The original Etoys interface was more like Scratch's (small area for
>> action results, most of the screen area used for showing tools, tiles,
>> etc.). The first Etoys was aimed at the web (at Disney), and making the
>> start up more obvious and using more screen for it is a good idea I think.
>
> Is there another design/way to help make start up more obvious without using
> more screen for it?
> So when you say "use more screen for it" I assume you are referring to
> Scratch's dedicated scripting area and tile area.
> I was thinking along the lines of a set of "Etoys Challenges" and "Etoys
> Castle" type projects, where only a limited set of tiles are visible and the
> user is asked to use them to solve problems.  Another idea is some kind of
> animated Quick Guides which are available from the scripting tiles
> themselves via halo, right click like in scratch or on hover a balloon help
> displays. Video tutorials (perhaps using Event Theater, which I hope stays
> in the next version, although one could argue for screen casting to solve
> the problem with that video embedded in the Scratch/Etoy project).
>
>>
>> Personally, I think the Scratch UI is better for many things than the
>> Etoys UI, especially first encounters, which are so important for so many
>> beginners these days.
>
> It is also better in the way the tiles snap together, it is a much more
> polished and forgiving interface with better visual clues when scripting,
>
>>
>> And I think the Scratch people have done a fantastic job on their web
>> presence, including their gallery, the emulator for Scratch projects so you
>> can see what they do, their online materials, etc.
>
> +1
>
>>
>> On the other hand, Scratch lacks a real media system,
>
> Details please Antwerth.
>
>>
>> a massively parallel particle system,
>
> Kedama is amazing and wonderful, but the learning curve is steep. Perhaps
> part of it is it has a different structure to it for scripting and you have
> to understand patches.  Some basic tutorials (video based for the visual
> learners among us) would be helpful but I need to play with Kedama more.
>
>>
>> and many other features that are really needed and useful for learning
>> things beyond simple programming.
>
> Well my short list would include: Player Variables, Holders/Playfields,
> Collections that hold anything not just numbers or strings.
> What's on your short list?
>
>>
>> But I think in the world we live in, it is initial experiences that count
>> in a non-classical culture (and this is most cultures around the world
>> including the US).
>
> +1
>
>>
>> As to how many features to include, this is a tricky one.
>
> Yup.
>>
>> Etoys has fewer built in features because part of the "real deal" is to
>> learn how to make your own features.
>
> The problem is its a lot of work and time to do the "real deal" and while it
> would be ideal, sadly most folks don't do it.  And part of
> the curriculum design is deciding what to make easy and what to make hard,
> but without the "productivity tools" everything is hard.
>
>>
>> It could have clip art, but we left it out because it is cognitively a
>> good thing for children to learn how to draw. This is good for a "learning
>> tool", but is not good for a "productivity tool".
>
> So part of the argument is that clip art was left out because we want kids
> to draw.  I agree its a good thing for children to learn to draw. But I do
> not agree that having clip art included will prevent this.  Look at some of
> the Scratch projects where kids do amazing drawings (although their drawing
> tool, could be improved by allowing the color picker to pick a color from
> anywhere within the Scratch environment not just the current drawing).
> On Sat, Sep 3, 2011 at 8:56 AM, Alan Kay <[hidden email]> wrote:
>>
>> One thing that hasn't been mentioned (but I should have) is not just the
>> initial experiences and learning curve for children/students, but also for
>> the adults who are trying to help them.
>
>  Agreed and I think Hilaire is on the right track for helping the adults who
> are trying to help children.  Providing a set of pre-built tools/projcts
> that teachers can use would greatly help acceptance and usage (and hopefully
> the kids learning as well ;)
>
>> I think this is where the relative opacity of Etoys really hurts its
>> acceptance, and why the intro UI should be set up differently.
>
> Its also the bugs (few as they are now) and the unforgivingness of the
> system (see Karl's example on losing a graphic).
> On Sun, Sep 11, 2011 at 5:14 PM, Dr. Gerald
> Ardito <[hidden email]> wrote:
>>
>> I have been using Scratch and Etoys with students in grades 5-8 for the
>> past 4 years or so. In this work, I have seen an interesting pattern. The
>> younger students (5th and 6th graders) ALWAYS prefer Etoys to Scratch. (I am
>> talking here about first exposure).They love the drawing component and then
>> being able to make their drawings move or do something. The older students
>> ALWAYS prefer Scratch. They get the bricks metaphor right away and so can
>> get things done very quickly.
>
> Okay, so this comment blew away my preconceived notions (thanks!!!).   So my
> question is why?  Perhaps it is that the Etoys drawing tool is simpler and
> more accesible and the Scratch scripting environment is simpler and has an
> easier on ramp.
>>
>> And sometimes students using Etoys get frustrated because there are so
>> many options and choices and opportunities for functionality.
>
> So again I think a series of Etoys challenges may be part of the answer.
> Another could be the ability to specify which scripting tiles are visible
> and which are not on a project basis. Of course that would put an extra load
> on the parents trying to help the kids and thus lead to less usage.
>
>>
>> What is also interesting is the degree to which the tools are owned by the
>> students. Whichever one they are using starts to become a powerful form of
>> expression for them so that, if given the opportunity, they will use it to
>> complete projects and presentations, etc.
>
> Yes both Scratch and Etoys can be improved in the "Power Point" replacement
> area.
> On Fri, Sep 16, 2011 at 3:29 AM, Hilaire
> Fernandes <[hidden email]> wrote:
>>
>> I am pretty sure at 100% that if Etoys came with huge libraries of such
>> artefact, specialised for various domains, ready to use by educators, Etoys
>> will have a tremendous impact both in the teaching communities and the
>> educative content producers.
>
> I agreed whole heartedly with Hilaire.  We need libraries of artifacts for
> teachers including but not limited to Etoys Challenges to teach specific
> topics, Tools to Teach with (cuisenaire rods, fraction tools, pattern
> blocks, etc) videos demonstrating how to use Etoys  (for students and
> teachers) and curriculum guides and other OERs.  This is no small task but
> worth starting.
> On Sat, Sep 17, 2011 at 9:20 AM, K. K.
> Subramaniam <[hidden email]> wrote:
>>
>> Another aspect of Etoys will become apparent if you get kids to use Etoys
>> in a
>>
>> language foreign to them (or say in dingbat fonts). Though the UI is
>> graphical
>> it still has a heavy text bias. I noticed this when helping children,
>> illiterate in English, use Etoys.
>
> I think graphical animated help could help here.  For example: if kids hover
> over a tile (or right click) a balloon shows up with an animation of what
> the tile does.  Or perhaps better a quiz where the child guesses what the
> tile does and then tests there guess by firing that tiles action all within
> the ballon quick guide/help.
>>
>> For instance, compose sketches by long-pressing (embed) one Morph on
>> another.
>> Suzanne Guyader, author of Art and Etoys, had many nice ideas for easing
>> compositions.
>
> Yes this is a wonderful project and hopefully Subbu's changes to support
> this will be included in the next release.
>
>>
>> We need something that takes the best parts of
>> Etoys, Scratch and Tuxpaint and build a new Idea editor.
>
> +1
>>
>> But then, we need to be able to look beyond software at the larger goal.
>> The
>> real question we should be asking is "Why aren't children acquiring
>> fluency in
>> learning with Etoys/Scratch/TuxPaint or whatchamacallit?"
>
> Well save that for another email chain ;)
> On Sun, Sep 18, 2011 at 12:22 PM, karl
> ramberg <[hidden email]> wrote:
>>
>> My kids play The Sims 3 and Starcraft 2. The interfaces
>> there are quite complex and the result is a kind of programming.
>
> But kids are motivated and motivation conquers all (well until frustration
> trumps it).
>
>>
>> It would be interesting to see if one could take these concepts a
>> bit longer and make programming tools more game-like.
>
> I think some game mechanics help, but I also think they have their limits.
>  I was listening to some game programmers at a NYU Games for Change
> conference. They were hired to work with the educators to help develop
> "learning games".  The comment they made that stuck with me was "every time
> they try and make it educational it becomes boring".
>>
>> Maybe there could be "clip art" of ready players that give the novice
>> less digressions.
>
> +1
>
>>
>> It would be great to be able to build for example make a decoder for a
>> video stream or a image form.
>
> Image editing (along the lines of Mark Guzdial's course where kids can
> program their own photoshop like effects) and video would be a great
> addition.
>
>>
>> It's also hard now to share single players.
>
> Sharing of players and scripts across project would be a good addition.
> I would add something along the lines of the Scratch Remote Connections
> Protocol where you can setup a mesh network of Scratch and Etoys projects
> which can exchange messages with each other (see Koji
> Yokokawa: http://www.squeaksource.com/ScratchConnect.html for the Etoys
> connection code).  Ideally we could also send players and scripts.
>
> On Sun, Sep 18, 2011 at 4:57 PM, Jecel Assumpcao
> Jr. <[hidden email]> wrote:
>>
>> A much better reason is Papert's: so the children will have an object to
>> think with. The idea is to learn to learn but we need a suitable way to
>> talk about learning strategies. Normal school tends to encourage a very
>> poor strategy: take a guess, see if the teacher confirms it is right and
>> if not take another guess. Not only is the search time long and
>> unbounded, you also need some external way of checking your results
>> which is something you won't always have.
>>
>> Teaching programming is just a way to be able to teach debugging, or
>> successive approximation. You don't throw away incorrect attempts but
>> instead build on them. And you learn to figure out for yourself if they
>> are correct or not, and how far and in what way they are incorrect so
>> you know what to change.
>
> Jecel, wonderfully stated, please provide details and specific examples we
> can use in classrooms ;)
> On Sun, Sep 18, 2011 at 6:09 PM, karl ramberg <[hidden email]> wrote:
>>
>> With Etoy now we have few projects that challenges a notion and show you a
>> way to get there.
>> We have the project showing the most basic stuff.
>>
>> I think we need more projects that features aspects of the system and
>> how to use them.
>
> Etoys Illinois has a number of good projects.
>
>  On Mon, Sep 19, 2011 at 1:05 PM, K. K.
> Subramaniam <[hidden email]> wrote:
>>
>> Papert had a multi-modal approach to develop thinking skills in children -
>> using large spaces, physical movement, manipulation in three- and two-
>> dimensional spaces etc.
>
> I think a lot is lost in the OLPC/Scratch/Etoys discussions where too much
> emphasis is placed on what can be done with the technology and not enough
> complimentary work on the large spaces, physical movement, etc that can be
> done outside of the computer.  Here I think Maria's work at Natural Math is
> a good compliment.
>
>>
>> Papert's methods were more closely aligned to the way children think and
>> act
>>
>> while the gap seems to be much larger in Etoys and smaller in the case of
>> TuxPaint or Scratch. There is lot more in Etoys than in these two but that
>> is
>> irrelevant if children cannot cross the initial chasm. Yes, a few children
>> may
>> make it across the chasm on their own steam, but thinking tools should be
>> designed to benefit 80% of children, not just the top quintile.
>
> +1 we need to better understand how children think and learn when
> designing curriculum and learning tools.
> And its not just the tools, but coming up with the appropriate metaphors,
> experiences, problems and questions ...
> to help kids cross the chasm that I struggle with.
> Thanks to all for their thoughts and time,
> Stephen
>
>
> _______________________________________________
> squeakland mailing list
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/squeakland
>
>

> Le 19/09/2011 19:05, K. K. Subramaniam a écrit :
> > On Monday 19 Sep 2011 2:27:55 AM Jecel Assumpcao Jr. wrote:
> >> About programming for the masses, I see two educational reasons to
> >> insist on that.
> >
> > The debates about programmin I encounter is usually around "how" and not
> > "why".
>
> I am not really sure programming should be the focus point. In Scratch
> it is but,
> is not connecting ideas and concepts the focus point in Etoys, and
> programming a small mean to get there?