Bill,

[Note to all: This is the last message where I will be responding to
details. You have to think about this a little more globally - I am not (and
never was) claiming that eToys are perfect as they are. Neither am I (never
was) claiming that they are perfect for *all* situations in *all*
circumstances - but their potential for both, novices as well as pros is so
immense that throwing the support for them out is about the dumbest thing
one can do]

Normally, I wouldn't claim that your application is a really great example
for eToys. Yet, in this particular example it probably is. When you generate
and configure your widgets based on meta data, isn't it - in quite a number
of cases - that the resulting view isn't *quite* perfect?! Like, for
example, that some input field should really have a plain colored border
instead of some standard 3D inset?! And isn't it for the most part a pain in
the neck to "extend the meta data" to be able to deal with it, just for the
sake of that individual customer?

And then, wouldn't it be just about perfect if you could go to your
costumers, tweak these things as you see fit, maybe add a funky little extra
in exactly the way they want for this particular widget and be able to just
say "set this as the default costume for this particular widget"?!

That's what eToys do.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Bill Schwab
> Sent: Tuesday, February 11, 2003 11:17 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: Re-doing Morphic ( Was: Re: Traits prototype image )
> 
> 
> Andreas,
> 
> ====================================
> > we could use this kind of 
> > refactoring to separate the "Morphic" programmers use to 
> build boring 
> > old applications, from the "Morphic" that's perfect for eToys. 
> 
> Nothing personal, but as of now, this is the most frustating 
> message I have
> seen in this thread. Don't you realize that the Morphic that 
> is perfect for
> eToys *is* the one that is perfect for programmers?
> ====================================
> I agree that eToys is a good interface for some tasks.  It 
> would be horrible for other jobs.  One of my "cash cows" is a 
> system that bypasses Dolphin's ViewComposer, allowing me to 
> create a system that creates and configures hundres of 
> widgets based on meta data.  The different views are created 
> lazily, so the user only waits for construction of what they 
> actually open, but it all has to be created and tied together 
> at some point.  
> 
> I am undecided at this point whether eToys is the Squeak 
> alternative to Dolphin's ViewComposer.  It seems like some 
> projects to create something like the latter have stalled.  
> Perhaps the authors discovered that they didn't need the 
> tool, or maybe they decided to leave Squeak entirely.  Any 
> hard facts on that point?
> 
> You might see these issues differently if you had to put up 
> with my users - sorry, I meant to say "if you had the 
> privilege of working with my users" :)  Both statements are 
> valid.  I deal with very intelligent but often not 
> technically savy people who can find themselves in extreme 
> circumstances with very little warning.  Something so mundane 
> as a modal dialog box is crucial to keeping them out of 
> trouble - their minds are on the tasks, and the computer is 
> supposed to be helping and coaching them, not coddled by 
> them.  Give them something non-modal, and you'll soon find 
> five or six of them open in various states of completion..  A 
> sequence of menus and prompters will frustrate them - they 
> want to see the kinds of choices they are going to face 
> without having to answer a bunch of questions to decide it's 
> not really what they wanted to do.
> 
> If that sounds like a plea for native widget support, it's 
> not.  In fact, I've had to devote quite a bit of work to 
> creating emulated widgets for various reasons.  However, 
> there is a somewhat standard "vocabulary" of user interfaces, 
> and despite the fact that many users don't know a control 
> from a window from a dialog box (I hear the term "screen" a 
> lot), they know when something deviates from the norms.
> 
> Zurgle might be overkill in some ways, but it did wonders to 
> punch up many appearance issues for Squeak.  I would have 
> chosen the Win2k look vs. XP, but if it is difficult to 
> change title bars, etc., then some refactoring to make that 
> easier seems warrranted.
> 
> However, Squeak's feel is much more of a problem than its 
> look (which has improved quite a bit over time).  My favorite 
> example is how clicking in just the wrong spot will pick up 
> an entire system window, bypassing the quick redraw and 
> resulting in very sluggish behavior - especially on slower 
> machines that I often need to target.  
> 
> Appologies if this adds to your frustration.  I'm going to 
> have another look at Bob's UI, but it seems to me that in 
> addition to providing an excellent simulation environment 
> (which is really how I look at Morphic), there is room for a 
> fast and robust widget set that will blow the doors off of 
> most native widgets, and will aid in writing the boring kinds 
> of programs that are often important to be able to write.  
> That widget set should be readily accessible from some kind 
> of GUI editing tools, as well as being friendly when 
> programmatic assembly is the best option.
> 
> Bill
> 
> 
> Wilhelm K. Schwab, Ph.D.
> University of Florida
> Department of Anesthesiology
> PO Box 100254
> Gainesville, FL 32610-0254
> 
> Email: bills at anest4.anest.ufl.edu
> Tel: (352) 846-1285
> FAX: (352) 392-7029
> 
> 
>