OT: Dolphin smalltalk giving up

Bill Schwab BSchwab at anest.ufl.edu
Sat Aug 11 22:30:44 UTC 2007


Matthew,

Fair enough.  I am mostly thinking of my users.  Suppose I display a
menu, they click in one of the magic spots, and instead of doing
something or nothing (which would cause a reflex to click again), it
gets attached to the hand.  I can hear it now: the menu is "stuck to the
mouse".  The file/directory picking "dialogs" are not really that at
all.  They are inconsistent, do not provide a clear way to show/hide
hidden files (at least on Linux).  As long as Squeak has been in use, it
seems that there should be a lot more polish in the interaction with the
user.

The behavior of input focus is a lot better than it once was, but it is
still not consistent.  I hate to think about putting a clerk in front of
Squeak-based form.  If they have to touch the mouse, the software is
broken.  Why care what clerks think?  They enter data that can be turned
into serious money, but one has to make life easy for them, or they find
ways not to cooperate.  It can be hard enough when it is easy.  Squeak
is starting to show some respect for tabbing, but it is again not
consistent.  It might be far enough along that one could build something
robust for end users.  For example, in a deployed app, one would not use
a system window; the main window would be app's shell (MDI fans will see
it differently of course), and an alignment morph would likely cover the
entire world, with the widgets living inside it.  I have yet to actually
do this, but I can imagine that it would hide many of the IDE's
annoyances.

One of my favorites is the method finder.  Especially with an optical
mouse (the kind that moves the cursor even when still), one has to
"balance" the cursor in the selector field, lest the focus fly off to
some other widget.

Workspace menus: the browse-it command should be on the first menu, near
inspect, debug-it, and friends.  Many other ergonomic annoyances have
been posted recently. 

The Linux vm will shutdown w/o warning.  It could do a better job with
virtual keys.  Some of that is Linux culture, but I notice that other
apps respond as expected to keypad vk messages.

Again, it is mostly feel: how it reacts to keyboard and mouse input.  I
am of the opinion that Microsoft is losing their collective grip on
reality, but they did some really good usability testing - what, 20
years ago??  Scary.  Much of what they learned watching "idiots"
interact with computers has become widely adopted.  If I am giving them
too much credit, I apologize, but there is a mechanical vocabulary of
interaction with computers, with a fine line between being responsive
and fragile.  I argue that Squeak as packaged is in the latter camp.

Please note that I am trying to remove a barrier to use of Smalltalk.  I
believe there is nothing one can do to make the masses leave the
sharp-infested waters(TM) for the power and elegance of Smalltalk. 
However, we can help those who "get it" make their would-be users' life
as easy as possible, making it just that much easier to apply Smalltalk.

Bill




Matthew Fulmer wrote:

On Sat, Aug 11, 2007 at 04:20:21PM -0400, Bill Schwab wrote:
> At the risk of becoming a broken record: my complaints about the
Squeak
> GUI are not about look, they are about feel. I can sell funny looking,
> but I cannot sell clumsy.

Squeak is easy to get used to, so we usually forget what makes
it clumsy. The only things I can think of is using the Alt
(rather than Ctrl) key for modifiers (on Linux and Windows), and
the lack of support for one-click copy/paste (under X11). What
else bothers you about it? We are not conspiring to make a
clumsy user interface. I got used to the interface after 1 week
and never saw it as clumsy.

I want to know. Really. What don't you like?


Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bschwab at anest.ufl.edu
Tel: (352) 846-1285
FAX: (352) 392-7029




More information about the Squeak-dev mailing list