Partial Summary and Synthesis of Keyboard Suggestions [Long].

[Christoph North-Keys]

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 at 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
------------------------------------------------------------------------------