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.
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.
Given the above, it seems natural to invent an arbitrary set of names for an arbitrary set of virtual buttons. I'd quite happily go with Charles, Renaldo and Kung-Kiu as the names of the buttons provided the names were used consistently; what is then important is a consistent mapping of these virtual buttons to operations within any particular interface style, such as MVC, Morphic, the GIMP, the Windows Style Guide, Paint Shop Pro.
- Peter
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@mat.net, @eai.com
squeak-dev@lists.squeakfoundation.org