The names of the buttons should be semantic, not color or positional.
Pity the left-handed, color-blind Smalltalkers.
In MVC, <select> <operate> and <window> are the names I think of for the mouse. In Morphic, <select> <operate> and <halo> .
Note the strange verbification of the third button for both frameworks. Or is it a noun :-?
Pity the left-handed, color-blind Smalltalkers.
Hey, I resemble that remark. Never had the slightest problem remembering a simple three piece mapping.
Michael Klein wrote:
The names of the buttons should be semantic, not color or positional.
This sounds reasonable to me too - but I'm in no way a Smalltalk expert. The discussion makes me wonder; does it really happen that you must tell the user about RYB buttons on the mouse? That sounds really low-level and dependent on one particular input method. I think that the "mapping" that Mac users must do to convert "yellow button" to "some key + button" is a clue that there's a problem.
How do other systems handle this? I haven't thought about this too much, so I'm winging it here - I might be completely wrong:
* I've seen docs in some Windows programs that say something like "Select the text...". This sounds good - a user is told to perform a higher-level action, not "Press the [left/second/blue] mouse button...".
* For showing popup/context-sensitive menu's, MouseEvents in Java have a method "isPopupTrigger" that hides the details of the particular platform's interaction style. This sounds good to me too - Like in the first case, the program docs can just rely on the user knowing how to use their own computer, and don't have to specify (become dependent on) low-level input mechanisms.
Can this approach be substituted for RYB buttons?
- Robb
squeak-dev@lists.squeakfoundation.org