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.
Regards .. Subbu
On Mon, Sep 19, 2011 at 7:05 PM, K. K. Subramaniam kksubbu.ml@gmail.com wrote:
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.
I don't think Etoys are that far behind either Scratch or Tuxpaint. Etoys does have a steep learning curve. But so has most stuff worth doing anyway :-)
I think we need user testing on Etoys to expose the biggest flaws. What are the biggest stumbling blocks ? Fix that issue and repeat the process.
Cheers, Karl
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@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@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@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@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@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@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@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@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@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@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@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 Mathhttp://www.naturalmath.comis 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
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: squeakland-bounces@squeakland.org [squeakland-bounces@squeakland.org] on behalf of Steve Thomas [sthomas1@gosargon.com] Sent: Tuesday, September 20, 2011 12:10 AM To: iaep; squeakland; naturalmath@googlegroups.com; scratched@scratch.mit.edu 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 <cwithers@ekindling.orgmailto:cwithers@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@gmail.commailto:hilaire.fernandes@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@yahoo.commailto:alan.nemo@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@yahoo.commailto:alan.nemo@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 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 <gerald.ardito@gmail.commailto:gerald.ardito@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@edu.ge.chmailto:hilaire.fernandes@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@gmail.commailto:kksubbu.ml@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@gmail.commailto:karlramberg@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 Protocolhttp://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@merlintec.commailto:jecel@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 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 <karlramberg@gmail.commailto:karlramberg@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 Illinoishttp://www.etoysillinois.org has a number of good projects.
On Mon, Sep 19, 2011 at 1:05 PM, K. K. Subramaniam <kksubbu.ml@gmail.commailto:kksubbu.ml@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 Mathhttp://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
Maybe you can draw similar conclusion from focus on tests as the the focus on money as incentive to accomplish tasks
http://www.ted.com/talks/dan_pink_on_motivation.html
I think it is very damaging to both deeper learning and also to realy learn anything. As students learn to score in a test and not learn to agument them self.
Cheers, Karl
On Tue, Sep 20, 2011 at 1:07 PM, Harness, Kathleen kharness@illinois.edu wrote:
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: squeakland-bounces@squeakland.org [squeakland-bounces@squeakland.org] on behalf of Steve Thomas [sthomas1@gosargon.com] Sent: Tuesday, September 20, 2011 12:10 AM To: iaep; squeakland; naturalmath@googlegroups.com; scratched@scratch.mit.edu 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 cwithers@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@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@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@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 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 gerald.ardito@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@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@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@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 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%C2%A0for 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@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 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 karlramberg@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 has a number of good projects.
On Mon, Sep 19, 2011 at 1:05 PM, K. K. Subramaniam kksubbu.ml@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 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 squeakland@squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
On Tue, Sep 20, 2011 at 7:10 AM, Steve Thomas sthomas1@gosargon.com wrote:
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@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@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@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).
EventTheater is a good idea but it is very fragile for even simple use and it breaks too easy. I'm not sure how to fix it, we would need a scripable gui. Quite possible but a big job. Screen capture of hoe to do stuff is currently the best way to show how to Etoy :-)
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
Webpage has a big and engaged following. Very cool.
On the other hand, Scratch lacks a real media system,
Details please Antwerth.
It would be great to get for example libffmpeg as a plugin. It supports most video formats and would help the use of video in projects.
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.
Kedama keeps its secrets tight to it's chest. I have not cracked it yet...
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?
PolygonMorph is not in Scratch.
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@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 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).
One of the hard parts to learn is that the player on screen is gone if I delete it. All it's scripts and features disappear. Maybe a kind of book, of favorite morphs and project could be to keep track of them.
On Sun, Sep 11, 2011 at 5:14 PM, Dr. Gerald Ardito gerald.ardito@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.
I would think it's the Scratch web community that engage kids.
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@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.
To be made: tools to build a curriculum and keep track of students projects and help with students with issues etc
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.
Make ObjectTools more dynamic.Make it simpler to share single objects.
On Sat, Sep 17, 2011 at 9:20 AM, K. K. Subramaniam kksubbu.ml@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.
I'll look at this one
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@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).
True. But some games can they can keep playing for years.
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".
I think they need to find a way to work with layers. To find a way to show more and more specific info the deeper you go in. Look at a game like Minecraft. Build stuff using different knowledge and materials. Learn how to find the materials, refine them and combine them. It could be a wonderful world of expanding knowledge. Not boring at all if done properly.
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 my list of stuff to add to Etoys. We have previous work that should be quite easy to add :-)
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%C2%A0for the Etoys connection code). Ideally we could also send players and scripts.
Net connection is needed but it is hard. I don't know much about how to do it. It should be made user friendly and also made so one could either work in a small team, a class or include everyone.
On Sun, Sep 18, 2011 at 4:57 PM, Jecel Assumpcao Jr. jecel@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 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 ;)
Also reevaluation of approaches is important as other concerns com up. Refactoring or rewrites of the same project. Etoys would benefit from a good debugger in the Etoys level.
On Sun, Sep 18, 2011 at 6:09 PM, karl ramberg karlramberg@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 has a number of good projects.
I must check it out :-)
On Mon, Sep 19, 2011 at 1:05 PM, K. K. Subramaniam kksubbu.ml@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 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 squeakland@squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
Karl
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?
Hilaire
On Wednesday 21 Sep 2011 11:51:15 AM Hilaire Fernandes wrote:
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?
"Programming" is just a common way of referring to the process of giving shape to ideas on a computer. Such a process is very error-prone (due in no small part to the crude tools available) and requires a person to apply both inductive and deductive ("debugging") skills to perfect the creation. The creation becomes important in a business context but not in an educational context.
Programming in Etoys is like juggling. What is the end-product of juggling? Why are people fascinated by juggling?
A village school teacher related an incident of a 4th grader with poor writing skills who, after spending a few weeks typesetting letter shapes using LatexMorph, broke into a torrent of writing. I have also come across other cases where Etoys (once past the initial chasm) triggered a big jump in learning levels. To me, this is the most fascinating aspect of Etoys.
Regards .. Subbu
squeakland@lists.squeakfoundation.org
-
Harness, Kathleen -
Hilaire Fernandes -
K. K. Subramaniam -
karl ramberg -
Steve Thomas