TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: new keyboard From:"Maureen J. Akins" <csvmja -at- ADMIN -dot- AC -dot- EDU> Date:Mon, 22 Mar 1993 09:08:08 EST
David's answer is quite correct. Instead of a keyboard with individual
displays, (Do you really look at the keys much?) why not go for the rainbow
of voice recognition? Wouldn't "Set left margin at 2 inches" be much
better than obscure key combinations that keep sight impaired people as
second class computer users?
Maureen
On Sun, 21 Mar 1993 01:21:13 PST, David Hamilton wrote:
>Steve Hollander writes:
>> WHAT IF somebody developed a keyboard that recaptured the display function:
>> When the computer is off, the keyboard is BLANK. When turned on, the keyboar
>> display is loaded by whatever program (or op system) the computer is using.
>> Thus, the A key would routinely display "A" but if the Ctrl key were pressed
>> and Ctrl-A meant "Abort," the keyboard display (LCD, probably) would say
>> "Abort." The f---ing F-keys would display WHATEVER THEY WOULD DO AT ANY GIVE
>> TIME! (The COMPUTER knows what it'll do when Shift-F9 is pressed; it can dam
>> well tell us!)
>>
>> Think of the $million$ in training that would be saved. Think of how much
>> easier it'd be to write manuals. Think of how happy the software writers'd b
>> since they'd have to create (and sell!) new versions with keyboard drivers
>> built into them. The template saleshumen, of course, would have a fit; but t
>> rest of us'd be on Easy Street.
>The biggest problem with the your idea is that it would greatly
>increase the cost of the keyboard. Right now, the keyboard switch
>assembly for a "standard" keyboard layout costs about $20 in quantity
>(from Korea). Once the case, cable, keycaps, processor, and assembly
>are added in, we have keyboards in the $80-100 range. Adding the
>display for each keycap would increase the cost by an order of
>magnitude, not counting the amortization of the R&D effort required.
>The largest segments of the desktop market are strongly price-driven.
>Purchasing departments save a few dollars per keyboard by buying
>inferior equipment. How do you think they would react to a keyboard
>costing $700 or more?
>The second problem is convincing the software vendors to support such
>a keyboard. While there are no major technical hurdles on the
>software side, the a major redesign of the keyboard drivers would be
>required. Updating the keycap displays would slow the overall
>keyboard response. There is also the problem of synchronization for
>very fast typists. The display text would increase the size of the
>program executable files, as well. The software development cost
>would not be trivial and the vendors would pass this cost on to the
>customer.
>The software vendors would only make these changes if forced to do so
>by market pressure. Until they did, there would be no advantage to
>the keyboard hardware folks developing the keyboard design.
>The third problem is primarily technical. LCD displays wouldn't work
>well, given the current limitations. Touch an LCD display displaying
>text and you'll immediately see part of the problem. The text will be
>distorted and obscured. Now add the problem of contouring they keycap
>with the display. Then add the problem of carrying the wiring from
>the display around the key switch. Any of the current techniques
>would either be prone to wear (and thus failure) or change the feel of
>the keyboard.
>In addition to an extra microprocessor required to handle the display
>functions, there is a fundemental problem with the way keycodes are
>generated by the keyboard. For most keyboards, a keycode is not
>returned to the computer when the CTL key is pressed or released.
>Instead, a different keycode is returned by the keyboard if CTL is
>pressed in simultaneously with certain other keys (the notable
>exception being the PeeCee).
>In short, while millions of dollars might be saved by your suggestion,
>many more millions would be required to take advantage of it. The
>only vendors that would profit from the situation are the keyboard
>vendors.
>If all those who design and use computers have been unable to agree on
>the relatively simple matter of a standard keyboard layout, what
>chance would a radical change in concept have? How many different
>places are there to put an ESC key, brackets, etc? How much
>productivity is lost when users must move between keyboard layouts?
>Currently, they cannot even agree what to call the ALT key(s). On
>some keyboards these are labeled META, while on others they don't even
>exist. It sounds like a very simple problem to solve, with provable
>benefits in productivity and portability, doesn't it?
>I like your suggestion - I just don't think it will happen.
>David Hamilton
>Sr Tech Writer (and former hardware/software designer)
---------------------------------------------------------------
| Maureen Akins Augusta College |
| Internet: makins -at- admin -dot- ac -dot- edu Computer Services |
| (706) 737-1484 GIST: 337-1484 2500 Walton Way |
| FAX: (706) 737-1773 Augusta, GA 30910 |
---------------------------------------------------------------