Five Finger Keyboards
In previous blog entries I have talked about mobile phones replacing desktop computers and the ways in which we could run applications on them. The biggest inhibitors that phones present are their dinky screens and keyboards. Screen resolutions are rapidly getting better, and iPhone has shown that if you can use the real estate that is usually hogged by buttons, you can get a good-sized screen onto a mobile phone. But without buttons, how can you enter text, or operate the phone's menus? iPhone offers you a virtual keyboard. When you need to enter text, an image of a keyboard pops up. You activate the keys by poking them with your fingertips. But there isn't much space for the keyboard. The keys are so close together that it's hard to touch one without touching others next to it. The iPhone makes it easier for you by using a form of predictive text, similar to what normal mobiles do; it checks the spelling of each word that you type, tries to work out what keys you meant to touch, and fixes the spelling on the fly. This approach works, but you will probably use only one fingertip to key in text, and you still need to aim quite carefully, so it isn't going to be fast. Some mobile devices like the Blackberry provide a full qwerty keyboard, but space limitations are such that you have to use a stylus, or point and aim with one finger very carefully, to use such a small keyboard. There is clearly still room for improvement.
In practice, 324 combinations would be enough to satisfy most needs and to confuse most users, so we can forget about the extended sequences for now. We will return to them when we discuss the needs of people with disabilities.
In this sequence, the user chooses successively a-i, b-d, then c to get the single character "c". Three key depressions are required in the sequence 1, 2, then 3. The keys are then released, and the mobile ignores the release sequence.
With this scheme, the novice user is guided with a series of soft key popups as to which key to depress next. With practice, users will quickly learn the sequence of depressions that give them the characters that they need most often. Users won't have to move their fingers from one button to another as they do with conventional mobile devices (or even desktop keyboards). They should be able to enter text quicker than folk do on current mobile keypads. Maybe with practice we will even be able to match our desktop keyboard skills. It sounds unlikely, but bear in mind that 93 year old Gordon Hill, a former telegraph operator, beat 13 year old Brittany Devlin in a texting speed test where Gordon transmitted the test message verbatim using a Morse code key while Brittany texted the message through a mobile keyboard, using common texting shortcuts (see here). Hopefully we could get international standards on the key sequences that give us at least the commonly-used characters and controls, so that users can migrate from one manufacturer's mobile s to another with relative ease.
Patents Pending?
I have done absolutely no searches to find out if any of the ideas described in this article have been patented or not. If you're interested in developing any solutions that incorporate some of these ideas, maybe you should take a snapshot of the page to defend yourself against patent claims in the future. If it appeared here before it reached the patent office, it's prior art, and can't be patented. Let's all do some "open source" invention to try to improve the way things work for one another rather than always trying to make money from one another.
Five Key Keyboards
Let's think of another approach - the five key keyboard, one for each finger and the thumb. Not an entirely new idea - there are about 2,000 Google hits for "five [or 5] key keyboards". They have been used to control a number of simple devices. But can we scale this up to the big time, to handle general text entry of the sort that we would usually use a full-size desktop keyboard to do? Let's try.Simple Binary Combinations
A general desktop keyboard has about 120 keys, a lot more than the five we're looking at. But suppose we allow the user to press combinations of keys on our five key keyboard? We use multi-key combinations on desktop keyboards, after all: Shift-a for A, Ctrl-c to copy, Ctrl-Alt-Del to freshen up our desktop software. Five binary (on/off) keys allow for 2*2*2*2*2 = 32 unique combinations. We need to assign one of these combinations to the gaps between keys, that leaves 31 that we can use. Enough for the Latin alphabet and a few other letters, such as a numeric shift, Alt shift, Ctrl shift.Sequenced Combinations
That's interesting, but can we do better? Yes we can, if we take the order in which the keys are depressed into account. Not such a strange idea, since Shift-a gives a different result to a-Shift, after all. That would give us:5 + 5*4 + 5*4*3 + 5*4*3*2 + 5*4*3*2*1 = 325 combinations.
Even less one for the gap between characters, that's quite impressive, even more than the number of combinations that we can get on a desktop keyboard using two-key combinations (a, Shift-a, Alt-a, Ctrl-a for example).Doubly Sequenced Combinations
Can we do better? Yes we can, because once we have depressed a sequence of keys, we need to release them, and if we take the order in which we release the keys into account then we have:5 + 5*4*2*1 + 5*4*3*3*2*1 + 5*4*3*2*4*3*2*1 + 5*4*3*2*1*5*4*3*2*1 = 15,685 combinations.
Now we're cooking on gas! That's enough combinations to handle the characters commonly encountered in Kanji and traditional Chinese writing, all with just five keys.Extended Sequenced Combinations
Can we do better? Yes we can, because so far we have only considered the cases where we press various keys in various sequences, and then release them in various sequences. What happens if we allow sequences in which keys may be pressed, released, pressed, released, and so forth, the only limitation being that at least one key must be pressed at any time, otherwise the sequence ends? Then the sky is the limit - you would have an arbitrarily large number of different sequences at your disposal. In fact this would hold true even if you have only two keys on the keyboard. You could press one, then the other (2 combinations) and then release and repress either one or the other, gaining one net bit each time, until you have chosen the character that you want. Interesting, but tedious.In practice, 324 combinations would be enough to satisfy most needs and to confuse most users, so we can forget about the extended sequences for now. We will return to them when we discuss the needs of people with disabilities.
Arranging the Keys
How would we arrange five keys on a mobile phone? Simplistically, we could locate four down one edge for the fingertips to operate, and one on the opposite edge for the thumb to operate. But which edge? Left-handed folk might like the opposite edge to right-handed folk. And even right-handed folk will likely switch hands from time to time; like when their one thumb is cut and bandaged (as mine happens to be right now); or when they're actually listening to a call - right-handed folk are mostly left-eared, and tend to hold their mobiles in their left hands while they're talking. They might still want to be able to operate the phone in this position to do things like:- increase or decrease the earpiece volume
- put the current call on hold and answer a second call
- terminate a call
- initiate a conference call
This Sounds Hard!
So technically, it's doable. But how easy would it be for a phone user to memorise up to 324 key depression combinations? Or even just about 100 if the user is happy with the Latin alphabet? Well, we can make it easier by using the concept of soft keys, which are already used by Java midlets when they run on mobile devices. Most modern mobiles have at least two keys just under the bottom edge of the screen with no labels permanently assigned to them. As you work through the mobile's menus, or run Java midlets, different labels are assigned to these keys. The labels appear on the screen just above their respective buttons. They may change as you move from one screen to another. Once the user has registered the buttons that they are going to use to operate the mobile, it can pop up little labels next to each of these buttons. As the user starts depressing buttons, the labels next to the remaining buttons (and even next to the depressed buttons) could change. Assuming that the user has registered a full five buttons, they might navigate through the following sequence of button depressions to choose a character. The sequence is shown left to right. In each panel, the number indicates the button next to which the label will appear, the buttons already depressed by the user in previous panels are shown in italics and the one that they choose to depress in that panel is shown in bold. If a menu option appears underlined then that option will be taken if the user releases all of the keys, completing the character selection process.
|
|
|
In this sequence, the user chooses successively a-i, b-d, then c to get the single character "c". Three key depressions are required in the sequence 1, 2, then 3. The keys are then released, and the mobile ignores the release sequence.
With this scheme, the novice user is guided with a series of soft key popups as to which key to depress next. With practice, users will quickly learn the sequence of depressions that give them the characters that they need most often. Users won't have to move their fingers from one button to another as they do with conventional mobile devices (or even desktop keyboards). They should be able to enter text quicker than folk do on current mobile keypads. Maybe with practice we will even be able to match our desktop keyboard skills. It sounds unlikely, but bear in mind that 93 year old Gordon Hill, a former telegraph operator, beat 13 year old Brittany Devlin in a texting speed test where Gordon transmitted the test message verbatim using a Morse code key while Brittany texted the message through a mobile keyboard, using common texting shortcuts (see here). Hopefully we could get international standards on the key sequences that give us at least the commonly-used characters and controls, so that users can migrate from one manufacturer's mobile s to another with relative ease.
Oops!
One thing we all know is that as we key characters, we make mistakes. Thank heavens for the backspace and delete keys! So if we implement the five key keyboard, how will we allow users to correct mistakes? The character set should certainly include sequences for backspace and delete, and also cursor movement keys (up, down, left, right, tab, back-tab, home, end, and so forth). If you happen to be part-way through a long sequence and depress the wrong button, the mobile may allow you to let go that button and press another instead, ignoring your first choice, if it does not implement the extended sequence scheme described above.People with Disabilities
People with various disabilities also need to be accommodated in our digital world. When a person picks up a particular mobile for the first time, they will have to go through an enrolment process so that the mobile can discover which fingers they have positioned on which key, as described above. If the user happened to be missing one or more fingers or a thumb, they would not respond when those particular digits were highlighted on the mobile's screen. The phone would discover this, and would use a different character encoding scheme that falls within the capabilities of its user. Hopefully we can develop international standards for less than five key sequences for the commonly used characters as well. If the disabled person can operate only a few keys, we could still define extended key sequences that will allow them to access all the characters that they need to operate a mobile.Patents Pending?
I have done absolutely no searches to find out if any of the ideas described in this article have been patented or not. If you're interested in developing any solutions that incorporate some of these ideas, maybe you should take a snapshot of the page to defend yourself against patent claims in the future. If it appeared here before it reached the patent office, it's prior art, and can't be patented. Let's all do some "open source" invention to try to improve the way things work for one another rather than always trying to make money from one another.
posted by Trevor Turton at 2:15 am
50 Comments:
I would be interested in ANY ideas that would eliminate the current ridiculousness which is mobile phone keyboards. Even Blackberry-esque QWERTY keyboards can't even come close to the speed of a regular keyboard, and therefore make themselves incredibly frustrating/slow for a touch-typer to use.
Won't happen. What you suggest is nearly as difficult as learning to play the recorder. Most people can't be bothered to learn to play a recorder because they find it tedious, so they won't even try this. Voice is, as it has been for the last decade, the next logical break through in interfacing with a handheld
These have been around for more than 40 years. Wikipedia: Chord keyboard
I think you're really on to something. Using sequence adds a bit more complexity than chording, butI used a twiddler (a chording keyboard) as part of a control prototype, and it was amazingly easy to pick-up chording. My daughter is a teen and I could see her being up to speed with this sort of interface in hours. That's probably the best test of a cellphone UI.
The basic idea dates back to 1836:
http://en.wikipedia.org/wiki/Chorded_keyboard
Hope that helps,
Andrew
look up "chorded keyboard" on wikipedia.
This could catch on like wildfire with kids. Nowadays they have to hold their phones in front of their face and look at the screen while using two hands to enter stuff in. Its really obvious when anyone is texting, and kids hate getting yelled at for doing it in places they shouldn't like school. After learning this system, you could theoretically send text messages while casually holding your phone in your pocket.
the screen real-estate problem is already solved: http://www.lumusvision.com/
soon on your nose.
I think you are looking for this thesis. I have really wanted a bluetooth enabled chording keyboard for a while. The iFrog seems to be the most reasonable effort, but it seems too large and too expensive.
cheers,
ken
Hi, I did some research into 5 finger keyboards a while ago and as far as I know this idea wasn't patented. Ubercool idea.
Actually I was creating a keychord map optimized for a wearable five finger keyboard: the most used characters for each finger and then the rest of the letters in the easiest to chord combination. 31 characters should be enough for everyone!
Take a look at the PARC Tab.
It used touchscreen input, plus it had three buttons down the side. The text input system on it allowed you to select words, based on groups. You might have to drill through 4-5 levels of menus to select the word you want, but if it's more than 4-5 letters in length, it's not a bad tradeoff. With 4-5 buttons on one side of the device, you could easily break a vocabulary into menus with 4-5 options, allowing a few clicks to pick an entire word. Using your method of picking starting and ending order, you could really speed through the menus. If the menus were static, people would learn, with practice, which sequence corresponded with which word, increasing input speed.
Also look at the Data Egg. I believe the main purpose on this one was for one-handed text input for astronauts. It never really caught on, but it gives you and idea of what the form-factor could be link.
I remember my father bringing back one of these devices from the office in the early 80s - a microwriter.
It was actually 6 key - 4 for the fingers, two for the thumb - and (certainly in my father's business) was intended for stenographers to enter text very quickly (to take notes during meetings).
Never caught on - but definitely commercially produced at one stage.
I remember these Chorded Keyboards 'chriss' cites in Wikipedia: my first school (pupils aged 4-10) had the 'Microwriter' brand nicknamed 'QUINKEY'. It is patented, but it will shortly expire as it was filed in 1988...[anybody else thinking what good/bad timing this is?]
Aged 8 some of us could learn the combinations fast though, others not at all. In general we hated Quinkey though and begged to use the QWERTY Keyboard because on that we could search round the keyboard until we found the letter we wanted.
I don't recall there been feedback to visualized where you were in the "decision tree" as you homed-in on the character you wanted (as Trevor suggests as an improvement). Yet, there on the Microwriter is an LCD display....so maybe aged 8 years old we just ignored it? It wasn't useful? After nearly 25 years I've forgotten?
Whatever: nowadays any Intern student could do better and offer a full graphic guide as to which "branch" of the tree you have already taken.
What you've described reminds me of Dasher: http://en.wikipedia.org/wiki/Dasher
Morse code can be related to Huffman coding: http://en.wikipedia.org/wiki/Huffman_coding
I think it's not strictly necessary for the keypresses to be simultaneous, aka chording. It's highly desirable or even required for the gadget to enter a serial/sequential mode. I'm glad someone finally piped up about this. Entering text on PDA's & mobile phones is ridiculous. Even morse code would be an improvement.
Yo, Francis, you should consider basing your glove interface chording on American Sign Language, then use things like use frequency and ease of use to resolve the inevitable mapping issues.
Making it as much like AmSLan as possible would not only help people learn your keyboard, it might someday help people learn AmSLan.
Win-win!
I have seen a method like this on a Japanese PDA. I cannot say for sure there were only 5 buttons, but there were definitely no more than 8.
Lame. You need to hold the phone as well, which means you have less than five digits to punch buttons with.
Try actually designing the thing before going on about it.
There are a couple of published ACM papers about this idea (it's called a 'chording keyboard', by the way):
Lyons et al. on the 5-finger idea:
http://doi.acm.org/10.1145/985692.985777
and Wigdor & Balakrishnan on a chording-based approach to adapting the mobile phones:
http://doi.acm.org/10.1145/985692.985703
I'm afraid, though, that chording for a mobile phone is indeed patented - I couldn't find it by googling a minute ago, but I did encounter it when we tried to patent the ChordTap technique described in Wigdor & Balakrishnan above.
Cheers,
Daniel
Does anyone know of a program to do this on a normal keyboard? I would like to try and use my left hand only but using a standard keyboard.
scott wrote: "Voice is [...] the next logical break through"
I think this is incorrect, as texting still has a very real use in a word were silence is often required. Think library, movie theater, meetings, class rooms, airplanes - anywhere where you'd be bothering someone else by talking.
I think this 5 key idea is very interesting, and I'd like to have a little "toy", so to speak, to try it out. I don't think it has a learning curve any steeper than a keyboard - learning how to type is very tedious for many, but when people start seeing the advantages, they'll start making the effort.
I worked for a backwater tiny little part of SGI at the beginning of the '90s or thereabouts. For a period of time I was unable to use one hand to type and, so, I designed a 5-button keyboard and encoding. It was a fairly successful effort -- my burst rates in typing were pretty good and my worst rates were still good enough to get work done.
So, yes: a good way to analyze the problem is as a "gesture space" -- counting up the number of unique gestures a particular system allows. In mine, I settled on using the relative timing of key-down events -- I don't think I recall using the timing of key-up events, though I'm sure I considered it.
Two observations can help a good design congeal:
First, the ergonomics matter a lot. For example, it's a lot easier to control the finger next to your thumb than the finger next to your pinkie. So, you may have this big gesture space but, because different gestures use different fingers in different ways, some gestures are a lot easier to type than others. You want to put commonly used characters on those easy-to-type combinations.
Second, the ergnomics matter even more than that. Suppose you are holding down some buttons because you've just typed "t" and next you want to type "h" or "o" or "i" --- the transition between gestures also matters because you can have two "easy" gestures that, if put side by side, are suddenly awkward.
I found it worked to get a good design by first guesstimating the costs of various gestures and combinations of gestures, then guesstimating what typical input streams would look like statistically, then writing a kind of hill-climbing A.I. search for a mapping of characters to gestures that had a local minimum cost.
Worked like a charm, more or less -- but it's a lot more complicated if you're aiming for a five-button typing system that would be the same for all five-button devices, even if those devices have very different ergonomic form-factors.
-t
The Twiddler and other chorded keyboards have been around for a long, long time. Your idea isn't even vaguely new or original.
Frances, that's really cool!
I have also been creating a five fingered mini-keyboard. My take on it is that it is bit clumsy until you get used to it. I completely agree that 31 characters is more than enough. Actually, our prototypes are a bit big, but we are hoping to get something nicer together in a few months. If you have done extensive work on this, maybe you would like to controbute?
I get carpal tunnel syndrome just thinking about this device... bm
Well the Agenda (I think this was the name) did this a long time ago... 1980 something. The machine was popular with Journalists for taking notes and it is also most impossible to buy one second hand. Could be kept in pocket while taking notes.
I'm gonna have to disagree with speed comments regarding the crackberry; with either a predictive or responsive text engine, I can type 50wpm on one.
Five keys is tricky and thats why we developed a system that uses ten keys. That way you have 100 combinations with only one or two presses. We are close to finalizing a marketable USB keyboard that can be used left handed, right handed or two handed and we plan to go bluetooth. The applications include typing with gloves or on a video game controller. www.in10did.com is our site and the device is the X-ses (although we are considering other names) It is great to see an interest in this technology!
novices can hunt and peck on a keyboard and limp there eventually. The chordal thing would need a way to navigate up down through possible letters to find the right one otherwise a chart would need to be printed on the back
Don't listen to the naysayers. Users are willing to adapt to a new input method if the return on their investment is great enough. If this weren't the case then precedents like Graffiti, T9 or even the regular keyboard we take for granted would not have caught on.
A well-implemented rendition of what you are describing would catch on in the right product.
The idea of interpreting "hold-A press-B" differently from "hold-B press-A" looks novel to me. I haven't seen that described in other chording implementations.
Four small points to round out the outline of the solution:
1. A game to train the user on the new input method. Both the Palm and the Newton had them, and they are standard for learning how to touch type.
2. Optimize the chords to the most common letters, so that they require the least amount of button presses.
3. Since your technique has such a large "namespace", allow the most common completed words to be entered in one shot, not just individual letters. More training is required, but huge payback results for those willing to invest the time.
4. Repetitive use could get painful with one hand. An alternate design: hold the device like a Blackberry but use the 8 fingers under the device to press 8 buttons. The training/feedback UI would be like an x-ray to these 8 buttons underneath.
Nice writeup!
Philip Haine
StealThisIdea
I love your design that uses quasi-modes and is very ergonomic.
I have a design for a two fingured keyboard which requires about a minute to learn and is capable of about 3 characters a second without any further training. I'd like to meet up with a person who could go through the process of obtaining a patent for it.
Anyone who has done this sort of thing before interested?
Chordite, a bluetooth chording keyboard, taking orders now.
There are old pictures in the SRI (Stanford Research Institute) archives of Doug Engelbart -- mouse in his right hand and five-finger keyboard under his left. To the best of my recollection, Doug invented both. This would have been around mid 1960s. The mouse took off; the five-finger keyboard died.
earle
I've been working on developing an single hand chording keyboard for about a year now. It's mostly an hobby project, but I'd probably jump on an interesting opensource / openhardware project if it existed.
(For example an reprogrammable open ARM7 based chording keyboard design. say based on the the philips LPC2148 that already has an opensource USB stack and ARM/firmware compiles on gnu software.)
IMHO I'd like to to point out some pitfalls.
BTW; I'm making one assumption, please correct me if I'm wrong to assume that there are maximum five fingers available to press buttons at the same time. ^_^
Now, to get down to the tasty details:
First of all, the tree structure/algorithm shouldn't be US/English latin alphabet centric. That is, since most of the written languages on this planet has than 25 letters in their alphabet, a chording keyboard shouldn't "solve the problem" by adding a few more buttons or to need an radical redesigning on the the basic tree structure for every single language.
Secondary, almost everyone manages to press wrong key in an key-chain at some point. This can be counteracted different ways. the most obvious way is to introduce an "delete last key in chain" and/or "abort keychain" button. But then we are wasting an valuable button on an single action.Isn't the whole point of an chording keyboard to use keychains to represent characters rather than single buttons?
So, what to do? well, you can design your tree structure /algorithm to account/correct for these things if your willing to limit the maxmimum number of combinations.
And thirdly but not the least important, most people don't have the same muscle strength on all fingers. For example, to use the pinky repeatedly and often in often used keychains (characters) should be avoided. But this again limits the maximum number of combinations.
Ufortunately this differs between languages as the most often used characters varies wildly between languages. (Check out Wikipedia's LetterFrequency page.)
My partial solution to both problem 2 and 3 is to reduce the number of possible keycombinations to 'N!' rather than N^N. This allows for example keychains where you push down button N and then hold it down while pushing N+1,N+2,N+3 until the keyboard gets an unambigious resolution. And when you releasing any of the pressed buttons you reset the spawning tre structure.
Then I move Uppercase and less used characters&special keys out of the regular tablespace by introducing at least one meta button that modify the next/subsequent keychain(s).
The trick with the Meta button is that it doesn't have to spawn the whole 'N!' tree. For example Meta+N buttons can serve 5 different modifiers if Meta is an toggle button. (for example Meta+shift/delete/pg-up/pg-down/'go to N+1 level')
Even better, most of the the Meta keychains can be user programmable.
So, how to deal with problem 1? Well, its quite obivous for me that you can't please everbody, so some compromises has to be done.
First of all the 25 english letters should be spread evenly over 5 buttons. (As only four buttons leave you with only 24 possible combinations, less than the english language has.)
Then the characters on Nth level on the tree structure is fixed for all Germanic/Latin languages, ditto for cyrillic and arab languages. The trick is to add all the extra characters in each language on the N+1,N+2,N+3 level. For example, Nordic/Scandinavian languages has three extra characters(except Islandic). These resemble A,E and O and share same ASCII code as similar germanic characters, so they should be placed (whenever possible) on the same Nth level as their english equivalents.
PS. those that wish to discuss this, please email me at heikkismogowli@matnat.uiobagheera.no
Remove mogowli and bagheera to get my propper email adress.
In my own tinkering, I've concluded (to my own satisfaction) that a Huffman Coding gorithm is nec.
http://en.wikipedia.org/wiki/Huffman_coding
For example, suppose the vowels are used 50% of the time, you might devise a system where
000 a
001 e
010 i
011 o
100 u
and 101, 110, 111 lead larger sequences. Consider UTF-8. The 128 ASCII characters map to 7-bits. The eighth bit indicates subsequent bytes. A character glyph can be represented by, 1, 2, 3, or 4 bytes.
An similarly absurd system is Unichord:
http://genaud.net/2007/04/unichord/
UTF-5 has never been accepted as a standard, so it's open to new interpretation. Here's my contribution which includes only "normal" chords -- 2^5 combinations. First, 00000 is not possible because that would mean no finger press at all (waiting rather than NULL). If you are familiar with UTF-8 binary streams, this will make more sense:
01xxx 1xxxxx = 7 bit ASCII (00-7F)
001xx 1xxxxx 1xxxxx = 10 bit (Latin extended, IPA, etc)
0001x 1xxxxx 1xxxxx 1xxxxx 1xxxxx = 17 bit (plane 0 & 1)
00001 1xxxxx 1xxxxx 1xxxxx 1xxxxx 1xxxxx = 20 bit (planes 2-16)
Unlike UTF-8, the proposed UTF-5 would be accumulative. 2^7 + 2^10 + 2^17 + 2^20 is within the full +10FFFD Unicode range.
That blog proves that many people read Trevor Trinkets and like "brainstorming".
But it also proves that very few have done a minimal "state of the art" study.
The best published data and thinking about chord keyboard is from the team of Thad Starner, of Georgia University and VP of Wearable computer association.
The problem of all past chord keyboards is that getting a speed higher than with existing systems, for the same number of hands and fingers and focus of attention is fully above mass market user will.
Then the problem and the solution is not in a given chord scheme, but in the learning path starting at the discovery and going to the expert level, above 40 words per minute with one hand and several fingers.
Larry : tikilgs@gmail.com
Thanks for the comment, Larry. You're right, lots of people are thinking about the same problem and they are coming up with similar, but not identical, ideas. Thad Starner has used the Twiddler chording keyboard for some of his wearable computers. This has a 3x4 (12 key) keyboard like a mobile phone and the users have to move their fingers from key to key, preferably without looking. My experience with keying SMS messages while driving is that it isn't easy or quick to use a 12 key keyboard without looking. Moving the thumb from one key to another is the problem.
My particular contribution to the discussion is to propose a 5 key keypad for people who have 5 fingers/thumbs (adapting to fewer keys for people lacking digits) that achieves the needed number of combinations by taking the order in which the keys are pressed into consideration. You may think that chording keys would be hard enough without having to worry about the order, but in reality people use sequenced chording on PC keyboards today with no trouble. We use Ctrl-C to copy, Ctrl-V to paste, and a variety of other key sequences as shortcuts, including 3 key sequences to invoke Excel macros, and the infamous Ctrl-Alt-Del sequence as well. Ctrl-C does something totally different than C-Ctrl, and yet we cope fine.
Our goal is not to compete with the existing PC keyboard for speed and simplicity. I'm sure that PC keyboards will reign supreme for as long as PCs are used, which will probably be a another five years or even more. But increasingly people are going to prefer to carry the computer power that they need in their pockets and purses. The technology required to do this is already available, it's the mobile phone. All we need now is a more convenient way of getting our input into the device. Voice recognition must eventually meet most of our inputting needs, but even then we will find ourselves in situations like meetings or public places where we don't want to share our secrets with everyone around us, and will prefer to key them into our mobiles one way or another. The paradigm that we need to beat is that of the current 12 key mobile keyboard with its requirement for lots of thumb movements and multiple key depressions to get one letter, or predictive texting which is rather hit and miss and still requires lots of thumb movements plus eyeballs to make sure the thumb is in the right place.
Tikilgs contribution :
5 keys is not enough.
5 fingers are not equal nor equally independant.
3 agile + thumb + small.
the data flow from a hand is at best when typing simultaneously = humans can do between 3-4 tap (very young, old) to 10-12 (virtuosos, pianists, flutist...) taps per second.
The "chord" system has to be built to allow best data flow (number of different chords * taps per second) for when people are trained.
Then you have to look back at how you get beginners at the expert level. When they start, they know nothing and their fingers are not yet trained to act separately (most of humans).
And on phones as on a laptop they are already proficient with existing solutions.
I am currently typing this on the best chord keyboard on earth... yet not yet published nor on the market... just wait... or help me !
Now, some links about chording :
http://xaphoon.com/dataegg/ProductsThatNeedIt.htm
http://wetpc.com.au/html/
http://www.cc.gatech.edu/~thad/030_research.htm
http://www.handykey.com/
http://www.infogrip.com/
of course there are a lot more.
Then, about the successive concept vs the simultaneous concept.
Yes ! when you use the input order information you have more distinct "chord" ...(in maths, A arrangements vs C combinations) but it is very much against speed.
When beginners discover a chord scheme it is easier to use one finger (thumb or index) successive input, but you start around 2 seconds per letter = 5 words per minute...
which is 3 times below Multitap and four times below T9 and others.
When you add correction and completion (to finish words) you are in fact 30/50% quicker !
And we don't compare microqwerty where users are above 30 words per minute.
The pb is there : who is going to start using a system that slow against a system he knows and he has to know to use other available devices ?
How long will he have to be slower before overtaking the standard solution ?
It is the Nash Law ! It cannot get off ground. See the Dvorak and other improvements of supposed bad and wrong Qwerty.
You have to find many more things and concept to get general public using really chord schemes then get good general mass market price devices which implement them.
Well ... thanks for opening the discussion ! Larry.
To be honest to readers... i am the promoter of the Tiki® interaction process
in http://en.wikipedia.org/wiki/Chord_keyboard
you can read :
"At the Xth symposium of the wearable computers society (11-14 October 2006), french Tiki'labs [1] www.tikilabs.com has introduced Tiki® input process which is a mix of a successive solution with a fully simultaneously chordic solution. That mix is intended to facilitate beginner experience and to allow more flexibility in the way you interact with the keyboard : from one finger to five fingers.""
As you read, i am not against "successive" action ! We have just decided to use it to facilitate learning and immediate usability. With an additional feature all chord keyboards lack : interactive screen guide which tells you how to produce any thing.
The trick i can "give" you : find a task where beginners can get immediate benefits even when they are still slow. It will be a task which cannot be done at all on existing schemes... like typing without ever looking to the keys nor to the screen ... in a silent and non intrusive manner (keys in your pocket for example).
As Thad Starner demonstrated with his team, you learn quickly by useful usage and really get the fast touch typing within hours.
Every body !
I am currently typing with a Tiki®.
Then i can say that i am not a beginner in the chord keyboard realm (i have used nearly all known scheme ).
As i see here, several people could be interested to work in a team where Tiki® would be implemented on several devices.
Tiki® can work on touch screens (currently monotouch), with existing keys or with outside keys, or a pointer on visual keys...
There exist mockups working in C++ on Windows XP tablet pc, symbian serie 60 2nd edition, windows mobile 6 (within a few weeks), in java and on the Nokia N800-810 free linux platform (debian see maemo.org).
We are interested by software programmers but also by electronic techies.
No money is possible since we have not raised money.
You can help in that domain too, and we have two contract forms for fund raisers and business facilitator.
Best regards.
Larry larry@tikilabs.com
in Paris ... France ....
My god this is a horrible idea. Having a cell phone keyboard customized to the user's hand placement? What if someone else wants to use your phone? Just hold the phone like a normal person and get over it! You really shouldn't be typing essays on your phone anyway. If you have something lengthy to say, ACTUALLY CALL THE PERSON. It might make you seem like less of a robot.
I don't really understand your comment ?
classical keys with printed signs you push until they click are really dominant, but many technologies are coming to detect your fingers (actuators) positions and movements
with much more flexibility.
A chord keyboard on a multitouch screen with haptic feed back can do all what classical keys do,
and adapt and remember users choices.
Of course a new user will be offered either a 12 keys numpad or a microqwerty (stylus) or a half qwerty display (as all Touch phones provide currently).
I'm in.
If you're working on it - i want to contribute!
with the design, or logic, or anything..
Nur Nachman Eytan
http://nurne.blogspot.com
nurnur at gmail
I have been thinking about building an open source demonstration of the five finger keyboard concept in JavaScript so that it can run on any device that has a JavaScript-enabled browser. I am encouraged by your offer, so I'll start on the project and probably upload it to http://code.google.com.
I have at last developed a prototype sequence-dependent chording keyboard. It's coded in JavaScript embedded in an HTML page, so anyone who has access to a browser with JavaScript support can check it out.
I have uploaded the code as an open source project on Google Code, see http://code.google.com/p/chording-keyboard/.
There is an online version available at http://turton.co.za/chordingKeyboard/chordingKeyboard.html.
Unfortunately it does not disable key repeat, meaning it is VERY hard to use. Can you please fix this?
There is a sight-to-sound program for blind persons, called... the voice..
It requires a PC or an Android phone with USB webcam. It is well worth trying.
It gives astonishing results with practice,but think of the blind user on the street, with dog, cane and groceries.. Having to fiddle with an expensive phone to adjust the camera might lead to all sorts of trouble.
I see a real opportunity to involve a chord keypad to give single handed in-pocket control of the keyboard
of the Android host. But how? By Bluetooth? or by a shared USB port?
I have not the techno to decide. Can anybody suggest or assist with this worthwhile application. johnf.
Many of the problems presented here have been solved recently by the GKOS chorded keyboard Android application by using the touch screen capabilities, like dynamic on-screen help, no chord maps needed, type with one or two hands, navigate (arrow keys), type as fast as you can tap on the display (one quick tap per letter), big keys, even touch typing is possible (looking at the text while you type) etc.
Think about blind people. A group called is working with "The vOICe" which is a camera to soundscape translator. This is available as an app for Android, Mac and PC. Android phones are the only practical solution for outdoor use. However there is an obvious need for one handed control of the system and a chord keyboard would give privacy and security.
Post a Comment
<< Home