[IAEP] [squeakland] Why is Scratch more popular than Etoys?

[Steve Thomas]

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 <cwithers at ekindling.org>
 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 <
hilaire.fernandes at gmail.com> 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 <alan.nemo at yahoo.com> 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 <alan.nemo at yahoo.com> 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 t*he 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 <gerald.ardito at gmail.com
> 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 <
hilaire.fernandes at edu.ge.ch> 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 <kksubbu.ml at gmail.com>
 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 <karlramberg at gmail.com>
 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 <http://wiki.scratch.mit.edu/wiki/Remote_Sensors_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. <jecel at merlintec.com>
 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 d*on'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 <karlramberg at gmail.com>
 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 <http://www.etoysillinois.org> has a number of good
projects.

* On Mon, Sep 19, 2011 at 1:05 PM, K. K. Subramaniam <kksubbu.ml at gmail.com>
 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<http://www.naturalmath.com>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/iaep/attachments/20110920/1b1cb8cb/attachment-0001.html>