2009/11/9 Bill Kerr <billk...@gmail.com>: > On Tue, Nov 10, 2009 at 4:35 AM, Bert Freudenberg <b...@freudenbergs.de> > wrote: >> >> On 07.11.2009, at 23:28, Bill Kerr wrote: >> >> On Sat, Nov 7, 2009 at 11:43 PM, Bert Freudenberg <b...@freudenbergs.de> >> wrote: >>> >>> On 07.11.2009, at 04:48, Bill Kerr wrote: >>> >>> > On Fri, Nov 6, 2009 at 11:35 PM, Tomeu Vizoso <to...@sugarlabs.org> >>> > wrote: >>> >> On Thu, Nov 5, 2009 at 11:10, Bill Kerr <billk...@gmail.com> wrote: >>> >> > http://activities.sugarlabs.org/en-US/sugar/browse/type:1/cat:107 >>> >> > How come scratch is no longer available for sugar? >>> >> > (the link is to the programming category of sugar activities) >>> >> >>> >> You mean Scratch was available in ASLO but isn't any more? >>> >> >>> > No but it should be there since Scratch has a far better UI than Etoys >>> >>> Agreed on the "should be there" part. >>> >>> As for "better UI": Scratch does what it does incredibly well. If all >>> you want to do can be done in Scratch then it is an excellent tool. >>> >>> Etoys is way more powerful, but comparatively hard to get into. >> >> thanks for replying Bert >> I'm not sure what you mean by Etoys being way more powerful. I would agree >> that Kedama, the parallel tile particle system, is way more powerful than >> anything in Scratch. >> Did you have something more in mind? >> >> Yes, too many to list all in fact. The power of Scratch lies in its limited >> scope - several years of development and refinement went into it to find the >> smallest set of features that make it easily teachable while still broadly >> applicable. >> There are others who could describe the Squeak/Etoys philosophy better than >> me, but one of its core ideas is "no limits". >> Where Scratch is a closed environment, Etoys provides just a thin layer of >> visual scripting on top of a much larger system. There are literally >> hundreds of objects that can be used as building blocks, from basic ones >> like rectangles, ellipses, polygons, or text, to complex ones like a book or >> a MIDI sequencer or video player or a working chess game (in Scratch there >> are only bitmap-sprites). In Etoys you can change coordinate systems, or >> embed objects into each other creating hierarchical animations, or connect >> objects with arrows to create diagrams that are fully scriptable, etc. In >> Scratch, every Sprite is separate, and they can communicate with others only >> by broadcasting - this is more limited but much easier to learn, and less >> prone to errors. >> And if all that is not enough (there are always things the designers can't >> anticipate) Etoys lets you escape to the full Squeak environment. While >> Scratch is implemented in Squeak too, you cannot access it. Again that >> limitation was a conscious trade-off (for example it enables "players" for >> Scratch projects to be implemented in other languages). >> Here are a few examples of my own projects in the Squeak showcase that I >> think would be hard to recreate in Scratch. >> Collision Physics >> http://squeakland.org/showcase/project.jsp?id=7052 >> (objects with collision sensors adding their forces to influence motion, >> this one is pure Etoys) >> OLPC-XO-Display >> http://squeakland.org/showcase/project.jsp?id=7050 >> (adds a new Squeak class to simulate the pixel pattern of the XO's display) >> Euros >> http://squeakland.org/showcase/project.jsp?id=7055 >> (connects to a web service to get currency conversion rate using a few lines >> of Squeak scripting) >> >> For teachers the ability to make an easy start with a program is very >> important. When teaching a group then if several students encounter >> something they can't solve then it creates huge problems, especially for >> difficult to manage classes. And even for more advanced students features >> that are easy to find and work smoothly are important so that they can focus >> clearly on the challenging learning (scripting) rather than hunting around >> for where the tools are. There are a whole lot of features in Scratch that >> makes this possible (as you acknowledge). I haven't spelt out those features >> in detail here but will run some more tests and attempt to do so soon. One >> of my students mentions some of them here: >> http://soeasyman123.blogspot.com/2009/11/great-race.html >> >> "I found Etoys very troublesome for a few reasons. >> 1. was because whenever I tried to save it would just close the program and >> I would jsut simply lose all my work. this occurred to me 3 times. >> 2. I couldn't view the scripts while having the cars move because the >> scripts would get in the way of the test. >> 3. the scripts were always in the way of the pictures so i had to close them >> everytime i finished with them which was very time consuming. >> 4. the drawing tools on Etoys aren't the greatest tools you could get. >> Although these reasons were troublesome I found Etoys interesting because >> there were so many scripts and other things to play with" >> >> 1 sounds like a bug. 2 and 3 can be resolved by arranging the scripts so >> that the scripted objects only cover a smaller portion of the screen (like >> in Scratch). 4 is true, patches welcome ;) >> One of the fundamental Etoys ideas is that "authoring is always on", hence >> there are no designated screen areas reserved for authoring tools. In fact, >> the tools cannot be used just on the user-created content, but on the tools >> themselves. This is a powerful idea in our opinion, it helps in demystifying >> the tools. >> >> My inclination has been to try to transition students from scratch to python >> - but it doesn't work all that well I think in part because Scratch is >> *entirely* visual drag and drop tiles and the transition to text based >> programming is too abrupt for many. >> >> There is a translation of Scratch into Python. It makes its tiles look >> almost like Python code, very cool: >> http://mail.python.org/pipermail/edu-sig/2009-June/009382.html >> >> It might work better with etoys if the intended transition was from etoys to >> smalltalk (squeak). That might be a better way to go but a harder sell in a >> school environment (since python is a better known language and also fits in >> with Sugar) >> >> I think that GameMaker (proprietary but a free version is available) handles >> this issue best - it has drag and drop for beginners and a code window for >> more advanced and you can mix and match scripts using both features >> together. I know that etoys has a code window but I found it very difficult >> to use successfully. >> >> You can have both tile scripts and textual scripts in Etoys, too. The >> difference is that there is no real need to use the textual scripting for >> the same stuff you can do with tiles. It's to access the advanced features, >> but you will have to know Squeak first to even know what to look for. >>> >>> OTOH >>> Etoys does integrate into Sugar reasonably well, unlike Scratch. If >>> platform conformity was the sole criterium for "better UI" then Etoys >>> would win hands down, with its Journal and Collaboration support. >> >> ok - with SoaS my efforts to enable collaboration on our school network have >> not been successful so although I have seen these features (in a session >> organised by Donna Benjamin in Melbourne a year ago) my students haven't >> been able to enjoy them unfortunately >>> >>> But another, maybe even more important difference is that Etoys is an >>> open-source community project. So if there is an Etoys itch you know >>> how to scratch (pun intended): patches welcome :) >> >> Yes, I suspect this (the license) is the main issue which I raised with >> Mitch Resnick (and on this list) last year and wrote a blog summing it up: >> http://billkerr2.blogspot.com/2008/11/scratch-license-disappointment.html >> The last word in the comments on my blog comes from Tom Hofmann: >> >> "Neither license is a free or open source license. The binary one limits >> modification, the source one limits use and redistribution. They're just >> unfree in different ways." >> >> So I guess it's really up to the Scratch team at MIT to improve the license >> and their failure to do that has resulted in Sugar Labs downgrading its >> distribution perhaps not consciously but as a "slipping into darkness" event >> >> Scratch is so enjoyable precisely because of being developed in a very small >> group, with lots of experimentation happening behind closed doors, but tight >> control of what gets released to the public. The license is just a >> consequence of not wanting to dilute the Scratch values. >> - Bert - > > thanks for that Bert, much to think about there - I appreciate the thought > and effort you put into your response
Btw, if anyone would like to work on improving the Scratch experience for Sugar users (including making its installation easier) I will be happy to provide pointers, help and contact the Scratch maintainers and other people who want to see this happen. I have heard that Scratch is quite used by Sugar users, and I'm surprised at the little work that has gone into making their experience better. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
