harp%terra.pkg.mcc.com@mcc.com (Christoph North-Keys) (05/20/89)
My apologies for the length of this submission.
Prologue:
This is not intended to be a flame of Sun (no pun intended), the Sun
type-4 keyboard appears to be a sound approach to attracting a share of
the market already indoctrinated to VT220 and IBM/PC style keyboards.
This is laudable on the part of Sun, but I believe they misunderstand
*why* many find the type-4 keyboard undesireable, even offensive. It is
my hope that Sun might even seriously considered the ideas presented
herein, and I hope that other Sun users will present both their
concurrence, and their differences with those opinions of mine which are
included herein.
There is also the fact that I running somewhat short of information, as we
do not have any type-4 keyboards on my network. All of the info I've so
far has been gleaned from Sun-Spots. If the type-4 does indeed resemble
the VT220 keyboard, which I have used before, the following should still
be germane.
All opinions are my own, and it should not be inferred they are concurred
with or supported by Mcc.
__________
Most of the users on the Sun networks with whom I have talked are fond of
the Sun-3 keyboard. We believe it would be improved most notably by a
capslock LED. A small number us would appreciate a Dvorak keyboard
release or at least a set of key stickers with which to arrange Dvorak
through software. There has also been comment on using the R1-R15 pad as
a numeric keypad.
This same group generally despises the VT220 keyboard, and does *not* have
any wish to be converted. Consider the fact the the numlock keys and so
forth used by many PC users cause the same class of errors as do modal
editors such a vi (many of us use GNUemacs, which avoids the constant
mode-flipping that vi requires). This bias is sufficiently deep-set to
inspire turning to non-Sun product lines if a comfortable keyboard from
Sun cannot be obtained.
The specific instance of bring the Backspace key closer to the user, and
moving Delete farther away: Delete is the UNIX default, why make life
difficult? It's much easier to hit Ctrl-H than it is to hit an
mispositioned Delete key. Emacs people in particular would be
inconvenienced, as Delete and Ctrl-Delete are used for editing, whereas
the Backspace maps to Ctrl-H, the help key.
A keypad is never a bad idea, even though such is not used as frequently
by scientific and programming folk as it is by accounting and business.
The Numlock key would be well used as a way to change the R1-R15 pad into
a numeric keypad. *However*, this should not be extended to moving
Delete, etc., to the R1-R15 area, as this brings on the Numlock error
problem seen by VT220 and PC users.
The idea of having a cursor-motion pad is nice, but most current sun users
have
---------------------------------
| | | | |
| Left | Down | Up | Right |
| | | | |
---------------------------------
already hardwired into their heads. Hence this layout would be a better
choice for a cursor-motion key layout than the arrangement found on VT220
and PC keyboards. It also happens to be more efficient to arrange them
in-line, something even Apple realized and used on the Mac-SE keyboard.
Sun would be much better served in offering a *selection* of keyboards
than it would in forcing the IBM standard "like it or lump it" approach,
as this has a negative effect on potential users who may have been in part
attracted by the nice design of the Sun-3 keyboard from days of yore.
Such a selection might include the following, noting that all would
benefit from Capslock indicators and a Numlock key on an otherwise
unaltered R1-R15 pad:
The standard Sun-3 keyboard we all know and love.
The preceding with a Dvorak key layout.
The type-4 for the dyed-in-the-wool VT220 and PC keyboard users.
I do not believe there would be a market for a Dvorak version of a
VT220/IBM style keyboard. Although the Dvorak is much faster for entry,
the group which would desire the VT220/IBM style keyboard is often
stereotypically resistant to relearning basic things like key layouts --
even when a substantial improvement would be achieved. Although this is
understandable from the perspective of the "learning curve", many of the
type-bound programmers and more serious word-processing folks would, I
think, appreciate the option of the modern Dvorak layout.
A short historical note for those not having heard about Dvorak:
|
| The typewriter keyboard, long ago, was arranged to allow very fast
| efficient typing. When the capabilities of the typists surpassed the
| technology of the typewriters, the typewriters jammed. The manufacturers
| rearranged the keyboard to make typing slower and more laborious, thus
| preventing the speed "problems" faced on the earlier keyboards.
|
| It's amazing how entrenched such barbarism can become. We are *still*
| using this same, sadistic keyboard layout.
|
| The Dvorak keyboard strongly resembles the first, efficient layout
| previously mentioned, and is a standard American key arrangement supported
| by various manufacturers. It benefits in part by placing the highest-usage
| keys directly under the fingertips. Many computers support it in software --
| even X11 has an "xdvorak" program to remap a standard keyboard.
Hence, most keyboards are, quite literally, part of a plot to make input
difficult. Would there not be substantial market support even for the
little improvements, even should they not offer Dvorak? Is the type-4
an improvement over the standard Sun-3 keyboard, or will it simply substitute
new difficulties for old?
This is a serious topic to me. I don't like companies deciding for me
which particular flavor of inconvenience is going to be inflicted upon me.
Does anybody out there relate deeply enough to tell Sun?
Seo: Harp[@Mcc.Com] /\ ^*^ Christopher North-Keys
/ \/\ Systems Administrator
Tha mi gu trang a'cluich. / \ \ Packaging/Interconnect, MCCmontanaro@sprite.crd.ge.com (06/07/89)
Having used the type-4 keyboard briefly, I agree it has its problems. Most annoying for me were: 1. The backquote key (`) is positioned where the left half of the RETURN key is on the Sun-2/3 keyboards. 2. BACKSPACE is where DELETE used to be. The Sun-2/3 keyboard is not without its faults, however. I think the right keypad should be replaced by a VT100/200 keypad, complete with numerics, arithmetic operators, commas, and periods. Data entry on a Sun-2/3 keyboard is difficult, at best. I also think the inverted "T" arrow key arrangement of the VT200 is the best. I doubt anyone but die-hard VT100 or vi users like the straight "< > ^ v" arrow arragement. Above all, overloading the arrow keys on the numeric keypad keys is a loser, especially when you can't decide what the arrow keys should generate. This confuses more novice Emacs users than just about anything else. I don't know how often I've answered, "Why does '217z' get inserted every time I press the left arrow key?" or, "Why don't the arrow keys work?" Skip Montanaro (montanaro@sprite.crd.ge.com)
henry@utzoo.uucp (06/08/89)
>The specific instance of bring the Backspace key closer to the user, and >moving Delete farther away: Delete is the UNIX default, why make life >difficult? ... Actually Delete is not the Unix default, as there is no single Unix default. Of course, if you're living entirely in the inbred little Sun world, that's different. I assure you, non-computer-science people find backspace a whole lot more intuitive for the purpose. (My own background is in CS, but I cope with a whole lot of non-CS users here.) >| The typewriter keyboard, long ago, was arranged to allow very fast >| efficient typing. When the capabilities of the typists surpassed the >| technology of the typewriters, the typewriters jammed. The manufacturers >| rearranged the keyboard to make typing slower and more laborious, thus >| preventing the speed "problems" faced on the earlier keyboards. A common myth, having no real basis in fact. The jamming problem was real, but the cause was not fast typing per se. (Do remember that touch-typing was unknown at the time.) The problem was hitting *adjacent keys* in rapid succession. The solution was not to slow down the typists, but to put frequently-used keys well apart. This has a slight tendency to *speed up* typists, since it increases the chances that successive keys will alternate between hands. The Dvorak keyboard's advantages, in impartial tests, seldom exceed 10% or thereabouts. (One can actually get comparable speedup with the standard layout by putting the RETURN key under the left thumb or using automatic word-wrap to eliminate use of RETURN altogether.) The much more spectacular claims made by Dvorak enthusiasts have never been confirmed by independent investigators. However, there are enough people with religious convictions about the massive superiority of the Dvorak keyboard that it would probably be worth the cost of making suitable keycaps available. >Sun would be much better served in offering a *selection* of keyboards >than it would in forcing the IBM standard "like it or lump it" approach... Now *this* I agree with; Sun is being stupid and arrogant. Henry Spencer at U of Toronto Zoology uunet!attcan!utzoo!henry henry@zoo.toronto.edu
brian@ucsd.edu (Brian Kantor) (06/08/89)
> ...DELete is the Unix [delete previous char] default....
Ah, another rank newcomer. No, the original Unix defaults were # for
backspace and @ for linekill, with DEL being the interrupt key. SysV
still comes that way from AT&T, but most of their .profiles seem to set ^H
as the backspace.
DELete didn't become the default BSD Unix backspace until someone (DEC?)
gave Berkeley a whole bunch of terminals that had this huge convenient
DELete key and this tiny little backspace key off in the function-key
wilderness. The VT220 keyboard is arranged that way in homage to VMS.
VMS grew out of earlier paper-tape based operating systems in which the
RUBOUT (aka DELete) key was used to obliterate a bad character on the
paper tape. It did NOT in fact delete the character in the input buffer,
but instead simply was discarded by the character input routine so that
you could physically backspace the paper tape and punch a RUBOUT over the
erroneous character, and it would pass unnoticed. In some bizarre flight
of illogic, VMS adopted the RUBOUT key as the character delete, thus
giving it a whole new meaning.
For some reason, Berkeley also adopted the other VMS character definitions
whilst they were at it. They choose to use ^U as line rubout, despite the
ASCII definition of ^X as CANcel and ^U as NAK (Negative AcKnowledge), and
^C (ETX, End of TeXt) for interrupt.
So much for ASCII as a standard.
Clearly in the world of 1200 bps modems there is a real advantage to not
using the DEL (RUBOUT) key for interrupt, since it is a common artifact of
line syncslips, but why would any community as virulently anti-VMS as the
Unix world is want to adopt the rest of the VMS bizarre keyboard editing
conventions? Sun continues the farce.
Maybe if someone donates a whole bunch of terminals with no delete keys
and real nice backspace keys on them to Berkeley, the 4.4 release will
turn to the use of ^H (BS) as the default backspace key?
Brian
NB: of course VMS isn't alone in this: many other DEC-influenced operating
systems used similar keyboard editing characters: TOPS, CP/M, etc.harp%terra.pkg.mcc.com@mcc.com (Christoph North-Keys) (06/13/89)
| The Sun-2/3 keyboard is not without its faults, however. I think the right | keypad should be replaced by a VT100/200 keypad, complete with numerics, | arithmetic operators, commas, and periods. Data entry on a Sun-2/3 | keyboard is difficult, at best. I would suggest combining the utility offered by the R1-R15 keys with a full-featured keypad with the following restriction and rationale: ** Use a single numlock key to differentiate the two usage of the right keypad. It should have an indicator light. The un-numlocked keypad should not have any default usage whatsoever. The key layout of the shifted keypad should not show a bias towards adding-machine usage, but rather provide ease of use for at least the minimum operator set { * / + - , . = }. The numlock should not be contiguous with the keypad. ** Rationale: Such would provide a multi-useful programmable keypad for the scientific/programming community, while still being useful to the business community. ** Problem: All lock keys promote errors due to their modal nature (see "vi") and should be placed with great forthought. Ideally this would be in the center of the keyboard with warning LED's, but ergonomic right/left keypad division is not yet in vogue. | I also think the inverted "T" arrow key arrangement of the VT200 is | the best. I doubt anyone but die-hard VT100 or vi users like the | straight "< > ^ v" arrow arragement. Disclaimer: I despise vi, hence could not possibly be one of those referred to above. Flame on. This man has clearly not used vi often nor often worked with any of the many programs whose programmers realized certain fundamental things about the inline layout which he has misrepresented. Flame off. --------------------------------- | | | | | | Left | Down | Up | Right | | | | | | --------------------------------- This layout requires no key travel in movement, and unlike the arrangement Skip quotes is only ambiguous in the Down vs. Up placement. The vi folks made the mistake of mapping this arrangement to "hjkl" rather than "jkl;" or even "dfjk", thus forcing just little enough key travel to be forgotten and contribute to errors. Realtime simulations are always the best tests of the utility of keylayouts to particular applications -- the one pictured above is used more often than all others and has been referred to as "hack keys". The inverse "T" layout, while marginally more obvious to someone who has never used the keyboard before, produces a severe performance degradation in cases requiring motion other than simple, linear point-to-point. The classes of input made more difficult by the "T" arrangement include cell-oriented data entry/editing, graphic editing, nested menus using cursor-motion, key-pointer control in graphics, and games. Since almost all movements beyond deleting the char before point will require a quick (batched) series of keystrokes, rather than single strokes interspersed into the main input stream, placing these keys on a seperate keypad (perhaps labeling equivalent to the diagram) seems acceptable. | Above all, overloading the arrow keys on the numeric keypad keys is a | loser, especially when you can't decide what the arrow keys should | generate. This confuses more novice Emacs users than just about | anything else. I don't know how often I've answered, "Why does '217z' | get inserted every time I press the left arrow key?" or, "Why don't | the arrow keys work?" I agree completely. Fortunately, most manufacturers seem to have already figured this out. ------------------------------------------------------------------------------ Seo: Harp[@Mcc.Com] /\ ^*^ Christopher North-Keys / \/\ Systems Administrator Tha mi gu trang a'cluich. / \ \ Packaging/Interconnect, MCC ------------------------------------------------------------------------------