red/yellow/blue buttons an anachronism?

Peter Crowther Peter.Crowther at IT-IQ.com
Mon Oct 4 15:51:48 UTC 1999


> 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.

> 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 --- 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'.  Hard to code, without careful
consideration of the gesture interface and how the user help system can lift
information out of the gesture mappings.

> 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.

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.

> (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'? :-)

> 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.

> 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.

> 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.

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.

		- Peter





More information about the Squeak-dev mailing list