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