On Monday, October 04, 1999 8:52 AM, Peter Crowther
[SMTP:Peter.Crowther at IT-IQ.com] wrote:
> > From:	Michael Klein [SMTP:Mklein at nts.net]
> > Peter Crowther wrote:
> >>> The names of the buttons should be semantic, not color or positional.
> >  
> >> ... unless the semantics vary between different parts of the same system,
> in
> >> which case no single semantic naming convention can suffice.
> 
> > Exactly.  No single naming scheme an suffice.
> 
> Er... that's not *quite* what I said --- see above.

Close enough.  Of course at some point, even #selectAt: or
#operationMenuButtonPressed
(made up selectors) get translated into more context-specific message.

> > The names should be chosen
> > appropriate to the module within which they reside.
> 
> This gives the problem of a user of multiple environments having to remember
> the physical-to-gesture mapping for each environment 

Yes.  And that problem should be solved by the computer... Not the user.
 I.E.
network transparency.  My preferences travel around with me.  If that
takes an
entire Image, or worse yet, and entire computer.... well, always an
issue.
I happen to use an alternate input device called a Twiddler

	http://www.handyKey.com

And, If I want this "configuration", I have to take it with me.  

> --- and the complexity
> increases for the environment having to remind the user.  Help messages
> change from 'click the yellow mouse button' to 'perform your gesture X if
> you are in MVC; perform your gesture Y if you are in Morphic; perform your
> gesture Z if it's a full moon and high tide'.

Help messages should be bound to the preferences, then.  Remember the
lesson
of MVC,  separation of concerns.  I think it is great that the same
application in 
Squeak can have a UI's developed in two different frameworks.... Maybe,
some day,
that will help in developing vendor-neutral Smalltalk UI's

>  Hard to code, without careful
> consideration of the gesture interface and how the user help system can lift
> information out of the gesture mappings.

Yep.

> > If you are doing a UI framework, like MVC or Morphic,
> > Then I would hope you would have some coherent semantics for your
> > input scheme.
> 
> I agree, but... *within* each of MVC or Morphic (awkward when you flick
> between environments), or try to facilitate agreement *between* MVC and
> Morphic.

Agreed.  But also facilitate agreement between Dolphin, and VW, and VA,
and ...

> I used to have three computer systems on my desk: Mac, Windows NT and
> SunVIEW/SunOS.  Any coherent semantics goes out of the window at system
> boundaries.  A Mac may be easy to use for experienced (or even novice) Mac
> users, but becomes hell when you interleave use of two other incompatible
> systems for about the same time.  I needed coherence across these multiple
> interfaces.

I have the same situation (except only the SparcStation is on the
desk... the rest
are underneath.  I use Smalltalk to achieve transparency.  The three
button mouse
on all three machines works the same.  I no longer use 3 keyboards and
three mice.
Now I just use VNC  (it's great)

> > (How fun would that be... towing
> > windows around your screen :-? )
> 
> Would the undo button need a sound sample with a loud beep and 'Warning...
> user reversing'? :-)

Would we use the rules of the road to solve resource locking problems
:-?

> > The right thing to do is to decide on the semantics you want, and then
> > figure out good UI gestures to invoke them.
> 
> Yes, but the original discussion was about documentation of those gestures
> across multiple environments rather than the gestures themselves within a
> single environment.

Again, a seemingly simple question on the squeak-list provoking deep
thought.
This thread has surface before.  One Smalltalk replied that he used
fingernail
polish to make his mouse buttone the "correct" color.

> > How hard
> > would the piano be to play if all of the keys were laid out in a single
> > row,
> > rather than with the white-black scale-revealing system we use today?
> 
> I'd prefer it.  I know several (sloppy) keyboard players who just ignore the
> front half of a keyboard and use those nice evenly-spaced keys at the back
> --- especially those who work with singers who regularly want stuff dropped
> a semitone on gigs because their voice feels rough!  As you say elsewhere,
> the UI has most variation.

Even the evenly spaced back of the keyboard has the chromatic scale
represented by look (color) and feel (height).  I think this helps in
playing.
"fretless" instruments (like the trombone and violing) "scare" me.... Im
just a novice player, though.

> > Better still, provide an easy mechanism for users to customize and
> > extend their own mappings.
> 
> Easy and *consistent*.  It's this consistency that is hard to achieve across
> environments, but is what many users want --- witness fvwm95 on Linux, for
> example, for those MicroWeenies who can't let go of their Win95 interface.

My problem is I want olvwm (although Id settle for fvwm) on Windows.
Again, the easiest solution is VNC

> I was impressed with VisualWorks when it first came out; the idea of
> emulating the platform's look-and-feel was (and still is) neat.  But Squeak
> has (two incompatible) cross-platform looks-and-feels; is this better (for
> cross-platform users), worse (for single-platform users), or just different?
> I don't know.

And you can develop your own look and feel, which is great... in VW.
Again, Morphic and MVC are more than look and feel differences.
I think they are framework differences, similar to when VW added events
to its MVC, but squeak's morphic is a much more major variation in
framework.

-- Mike