harp%terra.pkg.mcc.com@mcc.com (Christoph North-Keys) (06/13/89)
Disclaimer: Contents do not necessarily reflect the opinions or areas of work of MCC or its employees. A number of people have sent mail to me about what they would like to see in a keyboard, so I am now going to subject you to their massed voices. I extend my thanks (and sympathy) to all those who have contributed, although I by no means expect the furor to cease anytime soon. Note: Must I point out that there might be a market for any company making an effort to address the issues below? I. THE LOGICAL LAYOUT OF THE KEYBOARD, KEYMAPPING TABLES. ---------------------------------------------------------------------- The unanimous solution to all layout problems was to allow wholesale remapping of the keyboard. The consensus is that there is no single optimum keymap for the wide range of uses to which computers are being applied, and that having on hand several different keyboards is both unacceptable and impracticle. Static remapping (such as would appear in /etc/rc.local, for example) should not be too difficult, and even more value was found in dynamic remapping (such as would appear in ~/.login or equiv.) on a per-user basis or better. Both cases bring up the question of how to reflect the keymap on the physical keyboard. Static mapping could be reflected by simply exchanging keycaps, but the Dynamic case is more complicated for all but the best touch-typists. Both cases would require more flexible keyboards to be used to their full potential, but most venders would rather pound their corporate opinion into users' heads (hands?) rather than let them make their own choices. Note that this is indeed a corporate, profit-rather-than-efficiency oriented problem with which we are dealing. Joe Grace notes: | Date: 26 May 89 01:37:22 GMT | From: jgrace@porter-square.bbn.com (Joe Grace) |... | The funny thing is, my DECcy friends tell me that DEC uses keyboards with | reasonable layouts *internally* but just doesn't sell them to customers. |... | I just saw the new Sun keyboard today, and the biggest flaw I noticed is | that they shrunk the <return> key to squeeze in another key. OOOPS! | | IBM did this sort of thing with their original IBM PCs to protect their | word processing DisplayWriter systems from being replaced with the less | expensive line. IBM pushed not only the <return>, but also their 2 | <shift> keys out by a key. Basically, touch typists can't use the old PC | keyboards. Ditto for VT220 keyboards which are similarly broken. Sun | seems to be trying to kill their top of the line computers --- a little | backwards even by IBM standards ;-). Some reasons for the current Sun keymapping: Brian Kantor (no, I'm not a rank newcomer, I've just spent too much time on Suns) points out that the current ascendency on Suns of Delete over Backspace appears to have been entirely due Berkeley suddenly acquiring keyboards with Backspace in La-La Land. Delete should probably be used for Delete-Forward, instead of what we on Suns use it for now. Brian also points out that the qwerty layout was actually intended to reduce jamming from hitting adjacent keys (I remember this syndrome), a problem seen more often by faster typists. The alternation between hands thus produced does aid speed somewhat, as does the Dvorak layout's reduction of key travel. II. THE PHYSICAL LAYOUT OF THE KEYBOARD, KEYPAD POSITIONING, ETC. ---------------------------------------------------------------------- A. The general impression is that people seem to like having programmable keypads on both sides. They use one of them with the mouse, and the other within applications. Generally they want the latter, usually the right one, to double as a keypad with the four basic operators, comma, and point. Sixteen to twenty keys would likely be sufficient for either keypad. I consider it of value to be able to swap these keypads for the left-handed, hence suggest equivalent physical layouts for both. The number of keys mentioned also reduces the need for the F1-9 row, which could be merged between the columns of the left keypad. B. Most people seem to hate having the "lock" keys within easy reach, as they get hit accidentally. This brings on situations such as the X user's not understanding why the window manager suddenly seems to think all his key-bindings are garbage. One poster went so far as to remove the spring from his CapsLock, making it less hazardous. Everyone seems to want LED indicators for all lock keys, but would really like them to be more prominent, perhaps even centered on the keyboard (easier with divided main keypads). I see value in being able to apply one *lock* key to any of shift, meta, super, hyper, control, alternate, etc., with the release of the lock triggered by the next event on the "shift"-type key (The kb(4) man page suggests that a Sun would not have a problem with this). C. One possibility generally thought highly valuable, but possibly too expensive, entailed designing LED matrixes into the keycaps, so as to allow the display directly on the keyboard of whatever keymapping/font was currently in use, and be dynamically remappable from software. A less expensive alternative would be easily changable keycaps of the click-on/pop-off variety. The latter is primarily useful for someone wanting, say, a Dvorak keyboard as a default. D. About half of the comments I received found the feel of the keyboard to be very important, but did not rate its importance as highly as overall layout and/or remapping. The key aspects of feel appear to be consistancy, freedom from mushiness and non-vertical travel, crisp assurance of contact being made (tactile and/or auditory), tactile confirmation of keyboard position (pips on certain home keys, etc.), and dependability. These aspects would tend to contraindicate widespread use of touch screens in the near future, a possibility suggested by several. E. An alternate arrangement entailed setting all shift-type keys in place for use by thumbs (greatly reducing the number of lock keys), splitting the main keypad at center and moving the indicators and cursor-motion keys into the created space. This was intended to produce a somewhat more ergonomic arrangement while solving the shift-class key and lock problems faced on current keyboards. It also halves the number of these keys required while making their indicators more visible. III. SYNTHESIS ---------------------------------------------------------------------- Remapping is earmarked as highly important, especially if one considers the heretofore unaddressed issue of dealing with the newer 256-element character sets (although an ascii extension is needed first and Adobe's seems too redundant to use for such). It would be truly sad if the fundamental way to do remapping was to create translation tables from the qwerty (sub)standard to the desire mapping, as very little of the punctuation on the qwerty is really standardized. As any mapping is dependent on the keyboard used, is seems reasonable to map from keycodes to either characters or special functions through the use of something like a ~/.keymap file. This file might containg tables resembling those found in kb(4). The actual choice of physical keyboard would be made much simpler with such remapping, especially if the changes could be indicated on the keys by rearranging keycaps or somesuch. The keycap LED-matrix approach seems difficult to implement without much more substantial work, but might be worth it in special applications or if less expensive than I am expecting. It would be particularly nice if the several corporations involved could arrive at a standard keyboard/computer connection. It would also be neat if a fundamentally more flexible keyboard could be produced, but I don't see it as very likely just now -- about 80% of the people out there probably wouldn't be interested. A instance of a radical (and wholly untested) possible central key layout using the thumb-shifts and split-keyboard mentioned above has been included below to jog imaginations. Points for a keyboard: A. Programmable keypads on both sides of the main key area. B. Lock keys isolated from the high-usage keys, preventing errors. C. LED-matrix or relocatable keycaps. D. Crisp, reassuring, dependable keys with locaters. E. Possible rearrangement to improve use of shift-class keys. Appendix: "Y"-type keyboard ---------------------------------------------------------------------- Current debate is over position of space bar and arrows (not shown). Can be mapped to qwerty with only minor alterations in the usually almost out-of-reach upper right. Indicators would be placed in upper center. The intent is to be able to map all characters appearing in current publishing packages, and then some. Some examples from one keymapping are included. My preference for Alternate over Compose should understandable. Row 1: symbols, numbers. Row 5: predominantly grouping symbols and sundry paired quotes. Cols +/- 6: operators, slashes, pipes, dash, under/overscore, ellipsis. -7 -6 -5 -4 -3 -2 -1 +1 +2 +3 +4 +5 +6 +7 /-------------------\ *: home keys /-------------------\ 1. | | | | | | .: main area | | | | | | /---/---------------\---| \: thumbkeys |---/---------------\---\ 2. | | . | . | . | . | . | =: thumbrests | . | . | . | . | . | | /---|---|---+---+---+---|---|-----------------|---|---+---+---+---|---|---\ 3. |esc| | * | * | * | * | . | space | . | * | * | * | * | |del| \---|---|---+---+---+---|---|-----------------|---|---+---+---+---|---|---/ 4. | | . | . | . | . | . | tab | ret | . | . | . | . | . | | |---\---------------/---|--------|--------|---\---------------/---| 5. | | | | | | |\\\\\\\\|\\\\\\\\| | | | | | | \-----------------------------------------------------------------/ 6. |\\\\\\\|=====|\\\\\|=====|\\\\\\\| \-------/ \-----/ \-------/ alter shift meta *lock control ------------------------------------------------------------------------------ Seo: Harp[@Mcc.Com] /\ ^*^ Christopher North-Keys / \/\ Systems Administrator Tha mi gu trang a'cluich. / \ \ Packaging/Interconnect, MCC ------------------------------------------------------------------------------