Sun type-4 keyboard offends
Christoph North-Keys
harp%terra.pkg.mcc.com at mcc.com
Tue Jun 13 13:04:25 AEST 1989
| 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
------------------------------------------------------------------------------
More information about the Comp.sys.sun
mailing list