Well, you've done a good job of describing various things I'm working 
on in Bricks.  Just need a few more hours in the day...
For instance:

> 	6. For the programmers, make morphic prototypes get saved.  When you 
> do
> "make own subclass", save the morph in a class instance variable, and
> have that morph get veryDeepCopied when you do a #new on that class.
> Also add menus to save a different prototype and to abolish the
> prototype (because you've written an #initialize method that sets
> everything up).  For extra credit, make the prototype get serialized
> into

You can save a filed out version of the morph into a class variable on 
any class you like.
That's pretty good.

On Tuesday, July 15, 2003, at 09:04  PM, Lex Spoon wrote:

> Tim Rowledge <tim at sumeru.stanford.edu> wrote:
>> I do like the point about designing the UI early (on
>> http://mpt.phrasewise.com/discuss/msgReader$182) - since the UI is 
>> what
>> you (usually) have to explain to users it helps if there is
>> something that _can_ be explained.
>>
>> Once you have a decent idea of what you actually want to achieve you 
>> can
>> try to work out how to use it. If you then make an attempt to write an
>> explanation of how to use it you learn a great deal about what you 
>> will
>> need to implement.
>>
>
> This is the hardest part of making a UI for Squeak.  How many people
> have a good grasp of  what, exactly, are the individual tasks you
> perform in Squeak?  Of those people, how many are any good with UI's?
>
> To complicate things, there are *two* flavors of Squeak usage, at the
> very least:
>
> 	1. One is the etoy-ish interface.  This is people who jump to all the
> example projects, browse around on the SuperSwiki, and maybe on 
> accasion
> get excited and fiddle with an EToys exercise.  Also, this is the kind
> of person who might make a presentation in Squeak.
>
> 	2. The second flavor of usage is people writing Smalltalk programs and
> taking advantage of the heavy integration between browsers, the
> debugger, and the morphic world.  Classic Smalltalk.
>
>
> Hmm, you know, this consideration gives me a lot of ideas, for anyone
> who wants to work on this.  Here are a few areas that would help
> immensely:
>
> 	1. Work out the UI for SuperSwiki usage.  The buttons and menus are
> confusing, there are multiple ways to save projects, and the multiple
> progress meters are stunning to the eye.  This is a classic UI design
> situation if anyone wants to go for it.  It looks like there is
> something very simple and intuitive underneath it.  After all, it's 
> just
> load and save, right?
>
> 	2. Make SystemWindows not pop forward all the time -- instead, make 
> the
> top-most system window be the "active" one and leave it where it is.
> This is a small thing, but it really drives me crazy.  Often it even
> gives the illusion that something has completely disappeared, which
> really throws newbies.
>
> 	3. Reorganize the SystemWindow menus.  There are *three* top-level
> menus for SystemWindow's, and they're all different: one is from the 
> red
> halo, one isfrom the icon next to the X button, and one comes up after
> ctrl-click.  They should probably be the same menu.
>
> 	4. Reorganize the "help" menu.   It should really only have help-like
> things in it.  Some of the stuff in there is preferences and shouldn't
> be in any menu.  Some of the stuff is fine to have around but is weird
> to have in the "help" menu.  Feel free to create new menus if 
> necessary.
>  "help" is an important menu item to get correct.  Probably it should
> link to the Swiki documentation....
>
> 	5. Go through the preferences and get rid of as many as possible.  At
> the very least, hide most of them under some kind of expert panel, so
> that newbies don't get overwhelmed.  While you're at it, feel free to
> rename them all consistently.
>
> 	6. For the programmers, make morphic prototypes get saved.  When you 
> do
> "make own subclass", save the morph in a class instance variable, and
> have that morph get veryDeepCopied when you do a #new on that class.
> Also add menus to save a different prototype and to abolish the
> prototype (because you've written an #initialize method that sets
> everything up).  For extra credit, make the prototype get serialized
> into
>
>
> There are other things, too, but this is a start and any one of these
> things would help a lot.
>
>
> Lex
>