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

>
>>
>> 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.

> 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.
>

>
> 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
>
>