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

Sat Sep 3 08:56:58 EDT 2011

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. I think this is where the relative opacity of Etoys really hurts its acceptance, and why the intro UI should be set up differently. Adults can so easily bypass things that are good for children if they find them difficult to learn (consider what has happened to real math and real science).

When Mitchel, Brian and John Maloney were thinking of doing Scratch, I urged them to try a new design center that built on the Etoys experience in the hope that we could test more ideas. I think they succeeded brilliantly with both children and adults (I was only disappointed that so much of the good Etoys depth was excluded in the process).

The good news is that enough was retained to still bring real content (as opposed to e.g. the iPad, which discarded too much of what a computer is in order to be readily learnable and popular in the pop culture).

But (to me), once Hypercard appeared in the late 80s, it showed how to do "media programming for beginners" and (to me) drew a line that we should not retreat backwards from. The irony is that the media objects and tools for doing a Hypercard like experience as part of the environment are lurking below the surface in Squeak Smalltalk. Etoys exposes them wrapped in tile programming, and Scratch does not. This is a big mistake for Scratch IMO. Hardly anyone complains because hardly anyone understands what is being lost.

Given the problems with plugins, downloads, etc., one could imagine the next versions of Etoys and Scratch being done in Javascript (or less usefully in Flash). Here the temptations will be great to exclude needed features that are not already programmed in the substrate system. And we could see a further watering down of the ideas (for example it is not easy -- not possible pragmatically -- to do a particle system in Javascript). There will be many rationalizations concocted to explain away the lost abilities (just as there have been for what is still not doable in browsers after 20 years that is readily doable on the computers that run the browsers!) -- but the end result will be less for the learners, and that would be a real shame if allowed to happen.

We don't want to wind up with "Guitar Hero" here. We are trying to get children to learn powerful ideas, not just to "have a fantasy experience".

Cheers,

Alan

>________________________________
>From: R.D. Latimer <rdlatimer at gmail.com>
>To: Alan Kay <alan.nemo at yahoo.com>
>Cc: Steve Thomas <sthomas1 at gosargon.com>; iaep <iaep at lists.sugarlabs.org>; "naturalmath at googlegroups.com" <naturalmath at googlegroups.com>; squeakland <squeakland at squeakland.org>; "scratched at scratch.mit.edu" <scratched at scratch.mit.edu>; "Allard, Fred" <fallard at fcps.edu>
>Sent: Saturday, September 3, 2011 4:09 AM
>Subject: Re: [squeakland] [IAEP] Why is Scratch more popular than Etoys?
>
>
>Great discussion, thanks -
>We've been using Scratch for K-4 (Fairfax County VA) and last spring 
shifted over to BYOB/Snap (from Berkeley - now being named Snap with the
 new version not out yet).  We also started a Netlogo (Northwestern) 
intro for the older students.
>  Along with Etoys, I think it'll be great to try all of these 
environments with the kids, like you all are saying, each may have 
strengths and weaknesses.
>  BYOB/Snap has programming structures that can allow for connecting with other programming languages. For example -
>   - Definition of new blocks (procedures/funtions returning a value)
>     These blocks can have multiple inputs, 
>       Block to leap to a portion of the screen and spin a polygon shape
>              leapTo x:  y:    (Smalltalk type of syntax)
>              spinPolygon sides:  length:  times:
>
>  - arrays/lists of data  (though I find these process slowly in the current version of BYOB)
>       it can take a while to sort through a long list of numbers
>    list processing commands/statements/methods
>
>  - broadcast statements (I haven't explored these much)
>
>  - functional programming, mapping a block over a list, 'keeping' values that satisfy a test.
>    These capabilities are added at the Berkeley site.
>
>  - recursion
>
>  - parallel processing (I haven't explored this much)
>
>Netlogo is a 'typed in' language, has an easy to use interface.  Easily 
created thousands of turtles for simulation and modeling projects.
>
>  Python is very powerful and relatively easy for students to get 
started with, also a language called Processing.   These two languages 
may be examples of 'older student' programming that Scratch/Snap/Etoys 
can lead to.
>
>  With Etoys, is an eventual move for kids into Smalltalk part of the thinking? It doesn't sound like that's necessarily a goal.
>
> I think our students here are excited to be able to use all of these platforms at some point.  I'm not sure how much of the programming/development teams are available to make adjustments to the platforms as we receive feedback from the students.
>
>  I like the idea of a language environment incorporating lessons learned from all of these.
>THanks again for the discussion,
>Randy Latimer
>
>
>
>On Fri, Sep 2, 2011 at 11:33 PM, Alan Kay <alan.nemo at yahoo.com> wrote:
>
>Both Etoys and Scratch were done by some of the same people (especially John Maloney), and both are on top of Squeak Smalltalk. 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. The projects for the first Etoys were also like Scratch projects: effects, jokes, postcards, simple animations, etc.
>>
>>
>>
>>The next version of Etoys was for classrooms that would have much more help and do more ambitious projects. So we went to a full screen with flaps for the tools. This worked well in this setting.
>>
>>
>>The OLPC XO presented a problem in that it had lots of pixels but a very small visual angle.  We decided to stay with the classroom version, and I think this was a good idea on the one hand, but it went against the general lack of help that might be available in many of the XO's destinations.
>>
>>
>>Then we handed Etoys over to the Squeak Foundation, and the version they put out online retains the classroom UI with flaps.
>>
>>
>>
>>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. 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.
>>
>>
>>On the other hand, Scratch lacks a real media system, a massively parallel particle system, and many other features that are really needed and useful for learning things beyond simple programming. Etoys is much more complete in many more ways.
>>
>>
>>
>>Both systems have strong and weak points as to their language choices. Both lack nice extensions into more sophisticated programming. Both need to be greatly improved.
>>
>>
>>
>>And so forth.
>>
>>
>>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). So we have to praise Scratch here, and wish that it had more depth. Etoys could easily be set up with a more useful exposed UI, and this would help tremendously in initial impressions.
>>
>>
>>As to how many features to include, this is a tricky one. Scratch has quite a few features -- such as the thought balloon one -- because it was primarily initially designed for the "Computer Clubhouses", afternoon drop in experiences for junior high and high school kids. 
>>
>>
>>
>>Etoys has fewer built in features because part of the "real deal" is to learn how to make your own features. 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".
>>
>>
>>There is no question that both systems could be improved along the lines of their current styles.
>>
>>
>>One could also imagine taking the lessons learned from both systems and inventing a new environment that is quite a bit better than either. I like this option the best.
>>
>>
>>Cheers,
>>
>>
>>Alan
>>
>>
>>
>>
>>>________________________________
>>>
>>>From: Steve Thomas <sthomas1 at gosargon.com>
>>>
>>>To: iaep <iaep at lists.sugarlabs.org>; naturalmath at googlegroups.com; squeakland <squeakland at squeakland.org>; scratched at scratch.mit.edu
>>>Sent: Friday, September 2, 2011 7:04 PM
>>>Subject: [IAEP] Why is Scratch more popular than Etoys?
>>>
>>>
>>>
>>>I have taught both Scratch and Etoys to kids and hands down most kids prefer Scratch.  I also prefer Scratch for certain things, but prefer Etoys for most learning and teaching.
>>>
>>>
>>>What can we learn from Scratch (and TurtleArt et al) to improve Etoys?  And vice versa what can be done to improve Scratch?
>>>.  
>>>I have ideas, which I will share later, but I am curious to hear the thoughts of others (as mine add nothing to my current understanding and repeating them will simply further ingrain incomplete and incorrect assumptions and prejudices ;)
>>>
>>>
>>>Stephen
>>>P.S. I fully believe kids should learn multiple languages and am not looking for the "one ring to rule them all."  Each language/environment has its advantages and we need multiple.
>>>_______________________________________________
>>>IAEP -- It's An Education Project (not a laptop project!)
>>>IAEP at lists.sugarlabs.org
>>>http://lists.sugarlabs.org/listinfo/iaep
>>>
>>>
>>_______________________________________________
>>squeakland mailing list
>>squeakland at squeakland.org
>>http://lists.squeakland.org/mailman/listinfo/squeakland
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/iaep/attachments/20110903/ab85066d/attachment.html>