Shift Key Problem is a constant battle.
- A constant nag: Am I using the shift key too often? Why do I have to do this, there must be a better way. Should I remap my keyboard? When do I draw the line?
- Example: when using a programming language, you have to use () and <> and {} and := and :. These are all shift-key combinations. It gets annoying.
- It's not just awkward and time consuming. It sometimes just destroys the fun, for unknown reasons. Maybe finger stress. Maybe it's just like having to do the dishes 3 times instead of once.
- It's not about being lazy.. otherwise we'd all want to type CTRL-ALT-SHIFT everything instead of just shift. There is a point where you draw a line.. Thum buttons would definitely be useful..
- It can interrupt programming thought. Shift key is interruptive in thinking mode. You get used to it, but if there was a better solution, you'd always want it and think about it.
- Programmable keyboard software doesn't offer a complete solution because most of the keys on the keyboard are needed anyway. The function keys are too far away to be of any use.. if any are available. Programming the number pad is not a complete solution because it is too far away access. Programmable keyboards on the market are silly solutions, because the keys are usually above the function keys (i.e. just as bad as the numberpad distance).
- Keyboards should have ThumbButtons below the space bar or some other useful innovation - not programmable keys far away and above the function keys.
- Foot pedals wouldn't work because we need more than two keys to feel satisfied, We need at least 5 extra thumb buttons.. I think.
I think to get around the
ShiftKeyProblem in any programming language:
- Keyboards could be developed for programming languages. (They tried this for AplLanguage.) A programmable keyboard and remap software isn't a complete solution, because you end up needing the standard key mappings on the keyboard anyway. We need extra keys in a hardware solution, not just programmable keyboards and software. Most programmable keyboards have programmable keys in sucky locations anyway.
- Could develop standards: a Pascal keyboard, C++ and PHP keyboard, a SQL keyboard, etc. (i.e. an ":=" button would be useful for Pascal and Smalltalk. An end button would be useful for SQL and Pascal.)
Programmable keyboards don't offer a standard, and everyone uses different setups.. this is not good. We need a hardware standard for each language (and similar languages could have a combined setup). (or just better programmable keyboards, ones with buttons in useful places.. not at the top of the keyboard above function keys.. and also not a $600 price tag. It's just a piece of plastic, after all. Then we could develop setup standards for those keys on the keyboard, rather than just a hardware standard.) Maybe the keyboard would cost a bit more, but it would be an investment. For example, having a button below the space bar for your thumb which typed out "end" or "curly brace" would be a lot more useful than using the shift key or a key at the very top of the keyboard.
I've also thought about a FingerWall. This would take up a bit more desktop space and air space, and might require hinges that were 'stiffer than laptop screen' ones.
In my days as a Telex/Teletype/TWX operator, I had to shift back and forth between "letters" and "figures" modes to type messages containing both alpha and non-alpha characters. The patter is something like this (LTRS = letters, FIGS = figures):
- [cr][lf][FIGS]12345-[LTRS]jones[FIGS]-3 [LTRS]dear frank[FIGS], [LTRS]yes lunch thursday is fine[FIGS]. [LTRS]please bring cotton contract for review[FIGS]. [LTRS]regards jones [FIGS]+++[LTRS][LTRS][LTRS]
(I was in Denmark, so all the alpha characters were lower case).
The [LTRS] and [FIGS] keys were not "state" keys in the "active while held down" sense, they were actual code keys that sent a separate signal and occupied a tape position. You didn't "hold letters shift and press X" or "hold figures shift and press *" rather you pressed [LTRS] and everything you typed was alpha until the next type you pressed [FIGS].
This latching model allowed for a typing rhythm where the shifts were just another single key you pressed, not something requiring two (or three) digits at once. Typing became a streaming activity over the entire symbol set.
If you wanted to, you could code the shift and control keys that way on your conventional keyboard. [Shift] could mean "shift the next key I press" while 2x[Shift] might mean something like CapsLock. It would take some getting used to, but that driver could be used anywhere without requiring new hardware. You could add visual cues as needed, but you would probably not need them for long.
-- GarryHamilton
This feature can be enabled in Windows. Hit the Shift key 5 times and you will get the usability menu. It is intended for impaired people who cannot physically hold 2 keys at the same time. The "hit 5 shift" causes a great deal of problems in non-direcX games where the shift key is being used as an input.
And you can keep it. Some of us prefer to use shift keys and as many BuckyBits? as we can - shift keys are not confusingly MultiModal?, like the CapsLock is. Such approaches create problems in remembering all of the state information.
Imho, the best solution is the aforementioned "programmer keyboard" where most of the punctuation keys are given their own key (so the numbers row is actually 2 rows, for example). Leave the regular keys as is, shift for caps is no big pain (personally, I'm against CaseSensitivity in general). Add an underscore key below the spacebar. Add an A,B,C,D,E,and F key to the numerical keypad.
-- MartinZarate
Maybe also CtrlKeyProblem?, MetaKeyProblem?
Shift Key Problem