"John R. Hall" <overcode at lokigames.com> replied to my
observation that the Squeak IDE is actually pretty nice.

	-The first few days with Squeak were very difficult. I really didn't know how 
	to do anything in the environment. I got over that, but it could have been a 
	more positive experience. This isn't really Squeak's fault; it just happens 
	that Squeak's interface is considerably different from anything else I've 
	ever seen.
	
Documentation, documentation, documentation!

The thing that made getting started with Squeak a breeze for me was
having the coloured books, LaLonde & someone, and the Squeak Reference Card.
The book
    Smalltalk-80, the Interactive Programming Environment
was *immensely* valuable.  I had our library buy Mark Guzdial's "Squeak ...
Multimedia" book, and it's a very nice little book, but I must say that
I would never have been able to figure the Squeak environment out from it
alone.   (Make that a *VERY* nice little book.)

Take the Form editor, for example.  Just looking at the icons at the bottom,
it's easy enough to figure out the "tools", but fat left arrow for "load"
and fat right arrow for "save"?  *With* the Orange book, a breeze.
*Without* the Orange book, forget it.  (I defy anyone to guess the
correspondence between those icons and the bottom two rows of the keyboard
without figure 7.3.)  (Why did "file name?" pop up when I selected
Reverse Mode?  And why are the icons gone, leaving vacant squares, when I
run the Form editor a second time?)

The Form editor doesn't run under Morphic.  What _does_ one use to edit
forms under Morphic?
Take the Supplies flap in a Morphic project.  I wanted a bookmorph, but
couldn't tell which little picture was a Bookmorph picture.  It finally
dawned on me that I could use the halo on each to find out what it was
called, but balloon help would have been even nicer.

	-Squeak's intense reliance on the mouse is likely to be frustrating for 
	basically anyone but hardcore Macintosh users. I've heard all sorts of 
	excuses for this, including at least one misapplication of Fitt's Law and 
	various experimental data to show that mousing is faster than keyboarding. 
	(It's true that mousing is often faster for new users in _unfamiliar 
	environments_; keyboarding can become a much faster means of input for 
	experienced users who know the shortcuts. A bit of keyboard window navigation 
	would work wonders.)
	
Documentation, documentation, documentation!

You would be *amazed* just how much you can do from the keyboard.
For example, let's see what it's like to find "OrderedCollection>>addLast:".
First up a 3.0 image.
Cmd-b to get a browser (no mouse or menu).
[move mouse anywhere in top left pane; wouldn't it be great if firing
 up a browser warped the mouse there for you?]
Cmd-f OrderedCollection RETURN
[shown "OrderedCollection OrderedCollection OrderedCollectionInspector" menu;
 why first two entries identical? Discover that arrow keys DON'T work in this
 menu, why not? They scroll the class category pane. That's silly.  Select
 the first of the duplicate entries with mouse.]
[try TAB to move to next pane.  Doesn't work.  Why not?
 move mouse to top right pane.]
a d d L [typing these keys takes me to addLast:]

What could make this easier for someone who doesn't particularly want to
use the mouse very much?

MENUS
    The down arrow key should move the selection down in a menu,
    setting it to the first item if there is no selection yet.

    The up arrow key should move the selection up in a menu,
    setting it to the last item if there is no selection yet.

    When there is a selection, the RETURN/ENTER key(s) should select it.

    I note that "PopupMenu>>controlActivity" checks for keyboard activity
    as well as mouse activity.  I note that "PopupMenu>>readKeyboard"
    already handles ESC (abort), CR (select), UP, and DOWN, and that
    initial letters can be used to move the selection as well.
    So why didn't these keys work with the "Class name or fragment?"
    menu?  Hooray for Cmd-E!  Well, that list is made using
	(PopupMenu labelArray: "classnames" lines: #(1)) startUp
    So these keys SHOULD work in this menu.

    Ah!  In an MVC project, this DOES work.  (I knew there was a reason
    why I thought it should.)

    I am still struggling with Morphic and couldn't begin to figure out what
    would be needed to make the menu keys work in Morphic as well. but are we
    agreed that Morphic should not be *less* usable than MVC?

BROWSERS AND INSPECTORS (multipaned things in general)
    The obvious key to move to the next pane is TAB.  That doesn't work
    when some of the panes have editable text, nor do plain or shifted
    arrow keys.  That leaves

    Cmd-Right arrow move to next pane
    Cmd-Left arrow  move to previous pane

    The order typically doesn't matter very much, so sorting things
    by vertical position then horizontal position of top left corner
    would do.  This feature makes a lot of sense in Morphic too.
    Consider the Rolodex tutorial we were recently told about.  People
    would very naturally expect *some* key to move between the text
    fields.

	-I've heard amazing success stories of Squeak images running continuously for 
	years at a time, but over the past semester of working with Squeak for a 
	class I've lost at least 3 hours of work due to random crashes and lockups. 
	Recovering code from the changes file is a major PITA. To make matters worse, 
	our class' Swiki crashes on a regular basis, frequently on the night before 
	projects are due (this has happened at least twice out of six project 
	deadlines). It's FAR too easy to fry an image. I've managed to do it 
	accidentally several times.
	
While poking around to substantiate some of the claims in this message,
I tried (in the initial (Morphic) project) the FormEditor class>>newForm
example.  The mouse continued to track, but there was no respone to mouse
clicks, and eventually an error box "Object is not in the collection"
popped up, something to do with trying to handle an exception.  Thank
goodness for the File|Quit menu bar item, say I.

This is not a flaw of the *IDE* though, it is just plain flaky code in
the *implementation*.  I wonder what Stable Squeak will be like?

	-The user interface is... well, clean, I guess... uncluttered,
	 maybe... not very pretty.  I tried to spice it up a bit with various
	 goodies, but that fried my image pretty quickly.

I don't know what "not very pretty" means.  I don't actually *like* the
brightly coloured stuff, because it reduces the contrast on text that is
already at the margins of legibility.  I'd have thought that the 3.0
Morphic projects with their Squeak and Supplies and Tools flaps were
"pretty" enough for anybody.  I defy anyone to say that Squeak's IDE is
more "uncluttered" or less "pretty" than XEmacs running under Common Desktop
or Metrowerks on a Mac.

	-The system is supposedly self-documenting, but much of the system is left 
	uncommented and without help boxes. This makes it very difficult for 
	beginners to learn the basic system classes. I've spent many red-eyed nights 
	untangling the code to try to figure out what's going on, and I usually 
	succeed, but a few more bits of documentation would help greatly. (Yes, I 
	know, programmers hate to write documentation, and I'm pretty bad about it 
	myself, but this small bit of effort would go a long way.)
	
Documentation, documentation, documentation!

The classic coloured books are amazingly useful.  When I loaned my
coloured books to another staff member, I must have asked him "you DO
understand that I'd like these back soon?" at least a dozen times.

Squeak is a bit like Eiffel here.  Eiffel has special hooks for documenting
classes so that assorted tools can find things.  Do they get used with
anything approaching thoroughness?  Not in the Eiffel code (other than
examples from ISE) that I've seen.  Java code in Sun's JDK is copiously
commented, with, it must be said, comments that are occasionally wrong and
quite often fail to explain what one needs to know.  Even so, it's _there_.

Since access to documentation *is* a feature of the Squeak IDE,
I suppose it *does* count as a defect of the IDE if the documentation
is incomplete or defective.

I rather like books, but I must say that important information seems to be
far easier to find in Squeak than in say Metrowerks.  Searching through
multihundred page PDFs is not the most effective way to locate stuff.
And printing them wastes about 50% of the paper.

One thing I'd rather like to see in Squeak is classes linked to tutorials,
as people write them.  Certainly the Squeak Reference Card should be part
of the base distribution.  The machinery to make and follow such links is
there, it just needs to be used.

	-Morphic. This graphical scripting stuff sounds like a neat idea, but I took 
	one look at such a "script" and found myself asking "WTF??"
	The Morphic environment is teeming with cool features, but how the heck is a 
	newbie supposed to figure them out?
	
I've been using Squeak for about a year and a half now, and I am still
pathetically grateful for Morphic tutorials.  (This is despite having a
copy of Self and having read the Self Morphic paper.)

Documentation, documentation, documentation!

(I have done my share of documentation on a commercial software project.
 I'd say it's at least as much work as writing the code, but BOY does it
 make a difference to the quality of the product.)