I'm still thinking hard about the basic problems inherent to the success of an input device like Keychange. I believe that the combinations of solutions that past alternative keyboard projects used is mainly what relegated them to the historical dust bins. In this update I'm going to lay out what I think those problems are and how I intend to solve or avoid them.

Existing Chording Keyboards Are:

1. Unfamiliar - Looking at most chording keyboards, a non-techy person might have difficulty in even recognizing that the device is a keyboard. Each appears as an organically shaped high technology object covered in buttons. The gut reaction is fear and ridicule. Fear like fear of math. A person looks at some formulation and are told it is very useful, but the symbols used to describe it give an air of great complexity. People fear the unknown, so they avoid the device in favor of an easier alternative. Ridicule because such devices will be seen as tools for nerds who must care too much about the pointless, boring problem of digital text input.
2. Memory-Heavy - The basic premise of a chording keyboard is found in its chords. For every symbol there is a button combination that summons it. Unfortunately, the inherent trade-off is that a much higher mental effort is needed to get the benefits of the device. Most people will get discouraged when they find out they need to memorize dozens of chords before they can take advantage of a device. The traditional keyboard also requires practice, but a person can start using it immediately because every button is labeled with what it will do. For the traditional keyboard, efficiency is proportional to time. For a chording keyboard efficiency is zero for some time, and then it jumps up and slowly increases thereafter. The difference is a crucial friction point that prevents the wider adoption of chording keyboards.
3. Slow - For the bright, nerdy people who have traditionally used chording keyboards this is likely the most severe problem. Chording keyboards are inherently slower than their many-keyed counterparts. In reviewing the experiences of many chording typists I have found that it is not simply a matter of practice. Like in playing traditional musical instruments, motions involving individual fingers are much faster than motions involving the coordination of multiple fingers. Part of this problem is mental - it takes longer to order around several fingers compared to one. And part of the problem is physical - the machinery of our fingers is not independent per digit. Some fingers move together, and that makes many chords inherently more difficult to execute.
4. Bespoke - With unfamiliarity, this is a problem not inherent to the concept of chording keyboards. Alternative keyboards of all types have never seen wide popularity. So people who want them are forced to reinvent the wheel and come up with a custom solution. For those people who actually go and do it this is not actually a bad thing, I think, because they are more likely to be the type who would want a custom solution anyway. But when unlike people go looking for alternative keyboards they mostly just find those custom projects and face a wall. They do not have the skills to reproduce one of the projects, do not want to take the time, do not see a project that fulfills their needs, or cannot find enough details about any attractive project to reproduce it.

How Keychange is Different, and Why it will Win

Problem: Unfamiliar

Familiarity is a matter of context. Traditionally alternative keyboards have been fighting for the same space as the incumbent typewriter-style keyboard. Juxtaposing the two makes the alternative look like a loser. Most people are not going to bet on an underdog in a situation where they are mostly happy with the status quo.

Keychange sidesteps this issue of juxtaposition through virtual reality. In the context of virtual reality it is actually conceivable that the incumbent's advantageous position has been weakened and an underdog could be attractive enough to win. Keychange does aim to succeed as yet another alternative keyboard, but that is not the domain where it will choose to fight. As an input platform for virtual reality it can have the conceptual distance it needs to appear a daring underdog, rather than an unknown and scary threat to the existing paradigm. After winning there it might have the mind-share to take on the traditional keyboard, but that is a question to settle later.

Problem: Memory-Heavy & Slow

In solving this problem I think that Keychange can set itself apart from other similar projects. You may notice that this post sometimes uses the term "alternative keyboard" in place of "chording keyboard." The reason for that is I want to transition away from this being a project aiming to build a chording keyboard. I believe that many of the problems chording keyboards face are inherent to their model, and only by being willing to step outside their definition will this project have a chance at general success.

A requirement for great memorization effort before any use of Keychange is not acceptable for a device hoping to be used by ordinary people, or at least by virtual reality enthusiasts who don't actually care that much about keyboards and just want a good solution for VR text input.

Trying to make due within the chording model results in unacceptable trade-offs. To ease memorization a design can make the chord mapping follow some obvious structure, increase the number of keys so mappings are easier to follow, or just reduce the symbol-space (reducing the total number of chords). None of these solutions are very good. Coming up with an obvious structure is hard. Some commercial projects I found tried to achieve this by connecting chords to pictures involving the keys (see the microwriter). But the scheme is awkward at best. Increasing the number of keys defeats the purpose of the chording keyboard, makes it more expensive, and mechanically complex. Reducing the symbol space has been done by many commercial chording keyboard projects as well, but the result is more a toy that can be used for basic notes rather than a general purpose solution.

Minimizing Chording

In light of these problems, I am investigating models that are entirely separate from chording or hybridize with it. The most promising model that I am experimenting with eschews chords in favor of a sequence of keys per character. It is a powerful approach that I will explain with more depth in a post on an experimental scheme-testing keyboard that I am currently working on. A short example of the approach is: instead of pressing keys 1, 2, and 4 at the same time to get the character '~' you would press 1, then 2, and then 4. It might seem bizarre and even counterproductive to serialize what originally distinguished itself through parallel input, but I suspect that counterintuitively it will actually result in less faster learning time and greater typing speed. More information to come in a post on my "Prototyper" hardware, which I intend to use to test my hypotheses on the model.

Problem: Bespoke

It is relatively straightforward for Keychange to solve this problem. If it solves a problem people care about in an accessible way then it can become popular. If it becomes popular then it can set the standard for its domain. If it sets the standard then people looking to innovate further will have an attractive place to start. All of that should come naturally if I make it my business to enable each stage.

I argued in my first project log that Keychange can solve a problem people care about. To be accessible for further innovation I believe that it must be thoroughly open. I will make an effort to release as much of the work going into the project as open source, and keep it clean so that people can more easily take advantage of it. Also towards the goal of enabling innovation I will be putting a significant amount of effort into ensuring that the design is modular and can be easily modified for tangential purposes. The basic ways to accomplish that include breaking out unused pins on the PCBs, using well-known components, explaining why design decisions were made, clearly commenting the code, conforming to popular standards, and etc. I cannot write down a full list of these things. Instead I promise that I will give them careful thought during development.

P.S.

Oculus Rift

I ordered a Developer Kit 2 from Oculus Rift! Unfortunately it likely will not arrive until the end of prototype development in January. Fortunately, customization for virtual reality can wait until then. It is easy enough to simulate the relevant problems by closing my eyes and seeing how well I can type, or by trying to use a Leap Motion, Kinect, Wiimote, phone, or etc. for interaction while holding Keychange devices.

Better Information

I'm making two new sources of project information available:

1. The project notes that I am continuously adding to while working on the project. It is a very rough scratchpad of ideas and gives a general sense of what I am thinking about and where I am headed. Usually updates at least once per day.
2. The project now has a Github repository. Currently it just contains code for the experiments I am carrying out, but eventually it will hold everything needed to build your own Keychange, including hardware designs, a bill of materials, firmware, etc.