Hi Andreas,

Thanks for a very thought-provoking email!

With respect to the effort to cleaning up and documenting Morphic, I
think that it's great that people are willing to organize and do it.
Morphic is a really cool system.  When people first see Squeak
Morphic, they are wowed because there's nothing much like it.  But
Morphic hasn't reached its potential, because it's too large,
confusing, and (dare I say?) hacked together for the average Squeaker
to comprehend.  I consider myself to have an above-average
understanding of Morphic, but the thought of adding (for instance)
tool-handling code to HandMorph is daunting.  The concept itself is
quite simple, but HandMorph has so many dependencies (to and from)
that it is difficult to avoid breaking things.

Morphic will certainly not be the last word in direct manipulation
user interfaces.  However, it certainly is better than anything else
that I'm aware of.  Cleaning up Morphic will make it more accessible
to the uninitiated, and allow great applications to be written.
Current Squeakers will be happier, outsiders will notice the increased
happy glow, and will turn into happy Squeak newbies.  The world will
be a happy and wonderful place.

Remember, not every Squeaker wants to be pushing the cutting edge of
HCI, nor dragged behind those who are (these social issues in the
Squeak community keep popping up everywhere :-).  Also, the Squeak
community isn't a representative of the world population; although the
flaws in Morphic are real and it falls short of being a system that
Homer Simpson can use, many members of the Squeak list make a living
writing clean applications in languages much crappier than Smalltalk.
A clean core Morphic is clearly possible and desirable.

(deep breath)

On the other hand, I'm personally very excited about going beyond Morphic.
I have an inkling of what this would mean.  Traits can be a very big part
of this, especially if you put some effort along the lines of Scott's
Vocabulary work.  I don't have any particularly clear vision of how
this would work, though.  Would you or Alan care to elaborate on how
you see things?  

Thanks,
Joshua


On Mon, Feb 10, 2003 at 01:16:04PM +0100, Andreas Raab wrote:
> > > I'm wondering why andreas does not tell us his point of 
> > > view on that.
> > 
> > yes, please.  :)
> 
> Simple. I think that all'y'all (thanks Jeff!) are barking up the wrong tree.
> Look at eToys. Kids in fifth grade are able to master them even though
> players have 500 methods IN ADDITION TO those in Morph and Object and the
> kids are essentially dealing with all of them. Given this, isn't it time for
> y'all to admit that you're more like these kids in fifth grade then one
> might think?! ;-)
> 
> Or, put differently: The problem is not "cruft in Morphic", it isn't
> "uglyness". That's an overly simplified point of view on the problem since
> it didn't start out that way. It ended up there because of the way it was
> exposed to all'y'all kiddies (including myself) not being able to protect
> its own critical notions in any way.
> 
> To me, this is the logical result of many of the shortcomings of Smalltalk.
> For example, subclassing for using the framework. When we subclass a
> framework class like Morph in Smalltalk we do not *use* that class but
> rather we *modifiy* it. We are able to access unprotected instance state
> (look at the ridiculous comment in Morph>>bounds) we are able to override
> system critical methods in incompatible ways. Even the tutorials (like the
> one up at Squeak.org) teach you that it's okay to break the framework in
> order to use it (in this concrete example, it lacks calls to any of the
> "super" methods even though this is required by the framework).
> 
> Given this, any attempt to "clean up" Morphic is doomed to fail if it does
> not address the "usability issues" for the programmer. The best you can hope
> for is a temporary effect but any newbie can (and therefore will!) write
> code that breaks the framework. Some of this code will either be cool or
> needed enough so that someone else is going to use it and you'll end up
> exactly where we are right now. 
> 
> Documentation, tests, etc. will (while being useful) not solve this problem.
> After all, we *want* people to play with this stuff, don't we? And if we
> want people to play with it then it should be easy to use in "the right
> way".
> 
> eToys do exactly this. They provide an environment which is extremely
> convenient for the kids to use and boy, many a time I have wished that
> Squeak would be more like eToys. Bridging this gap, making the "system
> level" part of Squeak more like eToys is the thing that needs to be done. In
> particular in the UI area since that's what most people will look at and
> play with first, so it's the place where strong fences are most needed
> (present in eToys). Pretty much everything else will come naturally. Of
> course, such an environment would no longer be "Smalltalk" - but in order to
> protect the critical system notions we simply HAVE to get rid of it or at
> least some of its intrinsically dangerous notions when it comes to an open,
> easily usable, and still robust environment.
> 
> Bottom line of this: Morphic is cool. Neither the designers nor the users
> are to blame for where it ended up in Squeak. Squeak (Smalltalk) itself is -
> by not providing any means to build the right "fences" into the framework.
> So my essential feeling here is: If you want to fix Morphic, then fix
> Smalltalk. Morphic is simply a place where it shows many of its intrinsic
> shortcomings for all'y'all kiddies.
> 
> Cheers,
>   - Andreas
>