[squeak-dev] Re: Squeak vision

Bert Freudenberg bert at freudenbergs.de
Fri Jul 3 10:06:17 UTC 2009


On 03.07.2009, at 11:15, Nikolay Suslov wrote:

> Hello,
>
> 2009/7/3 Hilaire Fernandes <hilaire at ofset.org>
> Le mercredi 01 juillet 2009 à 22:50 -0300, Juan Vuletich a écrit :
>
> > Not at all. It means literally:
> > - It would be great to have Etoys as a package on top of Squeak  
> (as Ian
> > says). (That's exactly what I tried to do when I was the Morphic  
> Team
> > leader 4 or 5 years ago, btw.) However, saying that and not being  
> able
> > to get it done is useless.
>
>
> Spending the effort on a new framework à-la Etoys could be easier.
> Also one could note that Etoys has been quite unsuccessful for large
> acceptance in school. Educators here don't like it, they found it too
> complicate and unwise to guide the user. I don't know why, but  
> comparing
> to how Scratch dealt with building script could give a few hints.  
> Not to
> mention the quality of the UI.
>
> "The quality of the UI" ? )
> Just to mention, the that Scratch has made a great step backward in  
> UI (comparable to Squeak/Etoys).
> It disallows the use of Halos!
> And instead of that, it offers an old-fashioned aka Windows/Mac/ 
> Linux static UI, where any visual element couldn't be modified by  
> user visually, and so limits the most creative possibilities in UI  
> interaction and experience.
> The question of the quality of the UI is not in the menu bar, pop- 
> up, color and border decoration etc. but in conceptual aspects of  
> end-user interaction with it (like self-exploratory environment).
> Want the children to be future "accounting officers"  or "door-mans"  
> use static, with limited creative possibilities UIs.
> Want the children to be artists, and creators by themselves, don't  
> limit their freedom for that.
> And the Halos implementation (existed in Etoys and current Squeak)  
> is a one big step into this direction!


The Scratch team just made different design choices, they are not  
universally better or worse. I admire the clarity and ease-of-use of  
Scratch, it's very polished and thought through. The pruning of  
features and the many design iterations show, as well as the amount of  
actual user testing.

Etoys on the other hand follows the "turtles all the way down"  
philosophy, everything is an object made of the same matter working by  
the same principles, "authoring is always on" as Alan described it.  
That is, in Scratch there is a clear distinction between "user  
objects" and the  "authoring tools" which cannot be modified by the  
same user scripts. In Etoys one of the a-ha features is that you can  
not only script the objects created by the user, but the entire  
environment. You can write an Etoys script that operates on a  
scriptor, for example. And as I mentioned earlier Etoys offers  
extensibility by Smalltalk, Scratch presents a sealed environment to  
the user.

The fact you can get a halo on *any* screen object in Squeak is an  
embodiment of that philosophy.  It feels so normal to Squeak  
developers that they usually do not even appreciate it but just take  
for granted. Yet, it is one of those deep ideas that make the  
environment so powerful.

But the power comes at a price - it's easy to destroy your environment  
by accidentally ripping out essential components using the halo. So  
for certain scenarios limiting the power seems advisable.

Guess that's a long way of saying the world needs both, Scratch and  
Etoys :)

- Bert -


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090703/05550ced/attachment.htm


More information about the Squeak-dev mailing list