On Mon, Nov 5, 2012 at 6:30 PM, karl ramberg karlramberg@gmail.com wrote:
On Mon, Nov 5, 2012 at 6:45 AM, Steve Thomas sthomas1@gosargon.com wrote:
On Thu, Sep 27, 2012 at 6:24 AM, Bert Freudenberg bert@freudenbergs.de wrote:
Great essay by Bret Victor on "Designing a programming system for understanding programs":
http://worrydream.com/LearnableProgramming/He clearly explains what makes a programming system "learnable". While Etoys does not do all of it, many of its features fit right in, in particular as compared to other widely used programming systems. An Etoys project can be always running, changes have effect immediately, all state is visible (through the readouts in viewers) and most of the state can be changed directly (e.g. by dragging up and down the number arrows), tiles have default arguments so they do something useful immediately, there is an explanation (balloon help) for each tile
Yes but it is only textual help. It would be great if they could be a combination of Ricardo's Speech Bubbles and Ted Kaehler's roll your own quick guide feature. With one or two changes, the roll your own quick guides should be in a folder in the Etoys directory so it is easier for students and teachers to find and save these guides. The current location is hard to find, I believe varies by platform and can be locked down by school administrators. Also when saving a "My Quick Guides" area would be nice. Perhaps even encourage folks to modify them by having the New Help/Speech Bubbles have a "Modify Me" icon, which would open a new project with the existing Help/Speech Bubble opened. We should also have a mechanism to revert to the original so kids can easily experiment without fear of messing things up too badly.
, etc. And maybe this essay inspires some improvements to Etoys :)
I currently have the two key take aways so far as it relates to improvements to make in Etoys:
"Create by Abstracting" "Recomposition"
"Create by Abstracting": I believe the tools are already there, but what is needed is the "Great Literature" and Lessons teachers and learners can use. Not sure how this would impact the interface or if it should, but I think its a really important lesson. One possible way this could impact interface design is to provide a "turn #/expression into a variable" function. Where there is a way to click/touch on a variable and have a easily discoverable/accesible method to turn it into a variable. Actually it should work for "players/objects/morphs/colors" as well. Also kudo's to Etoys and its copy/sibling approach which IMO is a better design for "Start with one, make many" than the one for text based languages demonstrated by Brett.
"Recomposition": object re-use (across projects) is not very simple in Etoys. I like Scratch 2.0's use of a Backpack, which yes could be implemented as "add your own" section in the Object Catalog, but I think they made a good design choice in making it an "always there and visible" flap.
Regarding "Decomposition" Brett states
"Consider a programmer who has made a bouncing ball animation. How does she go from one ball to two, to a hundred? How does she make the balls bounce off one another? How does she make balls draggable with the mouse? In a genuine learning environment such as Etoys, this progression is natural and encouraged."
My suggestions here is that it would be good if Etoys "scaled better" when executing scripts on multiple objects. Unless you are using Kedama (which rocks in this aspect) Etoys slows down when you have say 20+ objects executing.
Okay, so that brings me to another area for improvement Kedama. Kedama is amazing and definitely rocks at massively parallel simulations, But it either needs a better (read easier to understand/grok) set of scripting tiles or I need a better model in my head of how it works. Probably more of the latter than the former.
I found this searching a while ago http://www.is.titech.ac.jp/~sassa/lab/papers-written/ohshima-phdthesis-07010... I have not read it yet.
I skimmed through this and it seems the Etoy user aspects of Kedama is described in chapter 3 and 4. I must say Kedama got a lot more understandable reading these chapters :-) Maybe we could extract the and post them on Squeakland ?
Also some chapters have info for the Etoys reference manual eg the Etoys language extensions and the features.
Yoshiki: Is it ok to use/copy from the thesis to the Etoys reference manual and eventually to a brief Kedama user guide ?
Karl
Karl
Of course all of the above would be great if we had more development resources :)
Cheers, Stephen
squeakland mailing list squeakland@squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland