On Monday, October 04, 1999 8:52 AM, Peter Crowther [SMTP:Peter.Crowther@IT-IQ.com] wrote:
From: Michael Klein [SMTP:Mklein@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
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
squeak-dev@lists.squeakfoundation.org