On Fri, 1 Oct 1999, 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.  For
example:
>
> > In MVC, <select> <operate> and <window> are the names I think of for
the
> > mouse.  In Morphic, <select> <operate> and <halo> .
>
> Case closed, to me at least.

Hmm, I'd say these are arguably "close enough" to make a semantic naming
convention work, between MVC and Morphic at least.  (Or in the words of
the immortal Meat Loaf, "Two out of three ain't bad.")  And even with the
last one, <window>/<halo>, the term <window> might suffice for both, if
you think of morphs as window-like elements to be manipulated via a halo.
Or come up with a more general term which covers both of them.

I suppose you could run into more problems if you had an application
written in Squeak which needed to use the mouse buttons for a totally
different purpose.  For example, a 3-D viewer which uses the three mouse
buttons to move objects along each of the X, Y and Z axes.  (I mention
this because our human modeling software, Jack, works like this. (No, it's
not written in Squeak. :-) ))  On the other hand, re-mapping the buttons
to do something different like this could be considered a Morphic/MVC UI
violation.

> As we're in a situation where a button does not necessarily have a
single
> physical realisation (for example, option keys to distinguish multiple
> virtual buttons on the click of one physical button), let alone the same
> physical realisation for all users on all platforms, a positional
notation
> is also inappropriate.

True, something like left/middle/right is obviously bad and non-portable.

However, I think Bert got it right when he said
"Primary/secondary/tertiary click describes the intention best".  This is
a naming convention based on importance, and I think it might be the best
overall global convention. It's not too specific (which a semantic-based
convention can be), but it's not too general/arbitrary either, so it's
much easier to learn and remember than red/yellow/blue.

With this convention, I don't think the potential confusion with
left-right-middle/1-2-3 mouse button numbering is significant, either.  On
the Mac, it makes sense that the <primary> button would be the one on the
mouse, it being the most important button.  With Windows 2-button mice,
obviously the <primary> and <secondary> buttons will be the ones on the
mouse.  A left-handed person would naturally reverse the mapping so that
the <primary> button would be the right button, etc.  (The 1-3-2 default
preference mapping for 3-button mice on Windows should be treated as a
bug, or as an indication that for whatever reason Microsoft decided that
the right mouse button is more important than the middle mouse button.)

On Mon, 4 Oct 1999, Michael Klein wrote:
> Close enough.  Of course at some point, even #selectAt: or
> #operationMenuButtonPressed
> (made up selectors) get translated into more context-specific message.

I guess you're arguing that semantic-based naming should be used from
within a specific UI framework or application, which sounds fine.

But I think a good global naming convention is still useful.  I admit that
the red/yellow/blue convention is kind of cool from a nostalgia point of
view, but in general, arbitrary naming shouldn't be used if there are
better alternatives, and I think primary/secondary/tertiary is better.

(I guess the question is whether it's worth the trouble to change the
button naming conventions at this point... :-) )

- Doug Way
  EAI/Transom Technologies, Ann Arbor, MI
  http://www.transom.com
  dway at mat.net, @eai.com