Author Topic: HuiBoard - open source 5 or 10 key typing system  (Read 3201 times)

0 Members and 1 Guest are viewing this topic.

Offline huiboard

  • Thread Starter
  • Posts: 9
  • Location: California
    • HuiBoard
HuiBoard - open source 5 or 10 key typing system
« on: Sat, 24 September 2016, 16:25:17 »
In case anyone is interested, I’ve made a free and open source project, written in Common Lisp, and extends Engelbart’s one handed keyboard. It has a different alphabet, but allows for both one and two handed typing and allows for powerful mnemonic shortcuts. Currently runs on Linux.

I was looking for a place to buy a chorded keyboard like the original Engelbart design, but couldn’t find one! So I rolled my own. It’s currently prototype stage, but very usable and powerful. You can make your own or buy one from the website. More designs coming soon.

You basically connect 5 or 10 keys, such as Cherry MX, to an Arduino. The software on the computer creates a layer between the keyboard and the OS that lets you easily script what the key inputs do. It features a built in stenotype style dictionary for fast text expansion. The chord combinations let you access millions of symbols, Lisp functions, or shell commands mnemonically. The finger patterns form a binary sign language that can be implemented almost anywhere. You can even learn the system without a keyboard.

Let me know what you think, I’d love to get some feedback!

http://huiboard.com
« Last Edit: Sat, 24 September 2016, 17:07:43 by huiboard »

Offline Giorgio

  • Posts: 1846
  • Location: Italy
Re: HuiBoard - open source 5 or 10 key typing system
« Reply #1 on: Sun, 25 September 2016, 04:18:02 »
I don't mean to be rude, but what's the point of this? Smaller keyboards?

Does it use less keys than Engelbert's?
« Last Edit: Sun, 25 September 2016, 04:24:58 by Giorgio »

Offline huiboard

  • Thread Starter
  • Posts: 9
  • Location: California
    • HuiBoard
Re: HuiBoard - open source 5 or 10 key typing system
« Reply #2 on: Sun, 25 September 2016, 11:47:29 »
Not rude at all, it just means I haven't explained it well enough.

Assigning the alphabet to fingers has many benefits. The finger patterns form a binary sign language that can be implemented almost anywhere through machine vision, keyboards, gloves with MEMS devices, or possibly even non-invasive neural connections. I can't fit a full size QWERTY in my pocket, so anywhere but at a desk or laptop has slow, inefficient, non touch typing input.

Typing is faster than QWERTY, but slower than stenotype - at least right now. I believe that it will be able to hit stenotype like speed without the years that stenotype requires to master. It autogenerates a stenotype like dictionary that allows for fast word input. For example amzn expands to amazon and eclh expands to electroencephalograph, and this works in any app.

In some sense it is an attempt to answer the question - If typewriters had never existed, and QWERTY wasn't the paradigm, how would humans have designed the most efficient and practical keyboard for the computer age?

I admit that it seems silly and crazy at first glance, but it is very optimal. I would like to have one built into my phone so I can use apps full screen and touch type at the same speeds as at a desktop, without carrying around a full size QWERTY.

Thanks for the question!

Offline oneproduct

  • Posts: 859
  • Location: Montreal, Canada
  • @Ubisoft
Re: HuiBoard - open source 5 or 10 key typing system
« Reply #3 on: Sun, 25 September 2016, 21:55:58 »
I've tried a chording keyboard before and even with word expansion I am very doubtful that it would exceed the speeds that an experienced touch typist can reach. For people with low typing speeds however it could possibly be more efficient, though I think the barrier for them would be trying to memorize both the basic inputs and the short expressions that get expanded into full words.

The slowness from chording comes from the need to coordinate finger presses. Because not all fingers will press down at the same time, the software needs to provide a time frame for all the fingers participating in entering a single letter to press down on keys. This pause is not necessary when entering single strokes, and five fingers on a normal keyboard could enter five different letters nearly simultaneously. Amzn expanding to amazon turns four presses that cannot overlap in their input sequence into six letters, but I am certain you could type amazon faster with individual presses due to the less strict timing requirements. Fast touch typing is done by sort of pressing whole syllables worth of letters at a time rather than one letter at a time. This is why stenotype is even faster: it provides an input method specifically created to enter words in this kind of a method; whole parts of words rather than one letter at a time. Chording with word expansion is limited by the one letter at a time problem.

In the end though, very few people would try to get used to this method. There have been many attempts at it before and there is already software to turn touchscreens into chording keyboards (e.g. https://play.google.com/store/apps/details?id=com.gkos.keyboard&hl=en), none of which have any notable following. I tried it personally for some time for amusement and because I thought it would be fun to be able to type with one hand while using the mouse in another.

Speech recognition will very likely be the near-future replacement for the keyboard, which is a lot more accessible to most people as it doesn't require any special training.
Layout: Colemak
Fastest typing speed: 131 WPM on typeracer, 136 WPM on 10fastfingers.
Daily driver: Filco Tenkeyless MX Brown with ergonomically weighted, lubed springs.
Ergo keyboards: Truly Ergonomic, Kinesis Advantage, Ergodox

Offline huiboard

  • Thread Starter
  • Posts: 9
  • Location: California
    • HuiBoard
Re: HuiBoard - open source 5 or 10 key typing system
« Reply #4 on: Sun, 25 September 2016, 22:56:22 »
I tried the GKOS board too, and didn't like it much.

As far as memorization, amzn amazn amzon all expand to amazon. You just have to enter a sub-sequence of the word that uniquely identifies it from the other words in your dictionary. In longer words there are tens or hundreds of possible sub-sequences that will expand to the word you want. It's a lot like autocomplete, but repeatable. It's also fast because you don't have to choose the correct word from a list. You just enter it.

You would only need to memorize the shortest sub-sequences of words that were used frequently, and only if you wanted to achieve the highest possible speed.

Also, you have an alphabet on each hand , so amzn is only two chords: am then zn. I can do this two to three times a second (the sequence amzn), which extrapolates to 120-180wpm, nearly independent of actual word length.

I got around the timing problem by doing a bitwise AND operation on the keys pressed, calculated after all the keys have been released. Practically what this means is that you only have to hit all of the keys that make up the cord before the last key of the chord is released. It leaves a lot of room for poor synchronization.

I am hoping that speech recognition gets better soon, but I don't see it completely replacing the keyboard unless we get some better solutions that run non-networked. A chorded keyboard on the touchscreen is a bad idea I think, better to have physical keys to press on the case of the phone, in the locations where our fingers naturally rest when we are holding it.

Thanks for taking the time to look at this and give me feedback, it's letting me know the parts that I haven't made clear.  I agree that very few will try to get used to this method, unless it is very advantageous. Even then it would be unlikely :)
« Last Edit: Sun, 25 September 2016, 23:20:52 by huiboard »

Offline oneproduct

  • Posts: 859
  • Location: Montreal, Canada
  • @Ubisoft
Re: HuiBoard - open source 5 or 10 key typing system
« Reply #5 on: Sun, 25 September 2016, 23:51:55 »
Needing to wait for a release at all is the problem however. If you roll your fingers across a keyboard without ever letting go of a key, you provide as many outputs as you do inputs. Needing to wait for the release is the problem. In touch typing, the slowest possible input is hitting the same key twice, because you must press the key, wait for it to become depressed, then press it again. With chording, you experience this problem on every press on a given hand.

The problem with memorizing subsequences is the overlap. For example, I would think of amzn as amazing rather than amazon, as amazing is far more common and comes first lexicographically. Mentally juggling which subsequences go with which words can be difficult, and if multiple users wish to use the same device, perhaps not feasible as different people would wish to use different subsequences.

However, I would consider the subsequence/autocomplete of this as a separate feature, as you could easily apply autocomplete to regular keyboard usage (and we already do so in many programs, such as google search, word editing or programming IDEs offering suggestions). If we do discuss more, I'm more interested in just focusing on the user input side of things.

Also, just to elaborate a bit on why regular typing can be quite rapid, consider the words "the" and "there".

I consider "the" to be a single input, and "there" to be two inputs:
the on the first stroke
re on the second stroke

Took a quick recording to show it here:

With subsequences and chords, I imagine the shortest sequence for "the" would be two inputs: th and e
And perhaps also two for there as th and er? But what would the input for therapy, thereafter or therefore be in that case? Unless you chose something like:
ther = there
thap = therapy
thfr = therefore

In general I just find that subsequences don't work out so well when you're limited to two letters per stroke vs steno being able to output several syllables at once.

As a phone input method with physical buttons in natural hand holding position, I'm also somewhat concerned that I'd drop the phone, particularly if thumb inputs were not involved for some strokes. :)
« Last Edit: Mon, 26 September 2016, 00:18:37 by oneproduct »
Layout: Colemak
Fastest typing speed: 131 WPM on typeracer, 136 WPM on 10fastfingers.
Daily driver: Filco Tenkeyless MX Brown with ergonomically weighted, lubed springs.
Ergo keyboards: Truly Ergonomic, Kinesis Advantage, Ergodox

Offline huiboard

  • Thread Starter
  • Posts: 9
  • Location: California
    • HuiBoard
Re: HuiBoard - open source 5 or 10 key typing system
« Reply #6 on: Mon, 26 September 2016, 00:38:41 »
Yes, it is limited by the release, though I hope to design a faster interface using analog instead of digital keys in the future. This would allow the software to characterize the direction the fingers are moving, and use that information to infer the chord the user is entering. The first prototype HuiBoard is made with Cherry MX which are binary, of course.

For the shorthand system, it works basically as follows:

Everything is "autogenerated" on the fly from 2 files:
1. A dictionary (which is personal and customizable)
2. A list of word occurrence frequencies, generated from Google Books data containing ~750 billion words - you can read about it here: http://norvig.com/mayzner.html specifically the "word count file" is used.

The best expansion candidate is then chosen from sorting the words by length, and then by frequency. Also the first letter of the subsequence must match the first letter of the word. No Bayesian or other statistical inference is used.

Since amazing is a longer word than amazon, amzn will expand to amazon, even though amzn is a subsequence of amazing. If there was a word the same length as amazon that contained the subsequence amzn, and this word was more common than amazon, then amzn would expand to that word instead.

Incidentally amzg expands to amazing since that subsequence meets the criteria, and arguably makes more sense. The stock ticker for Amazon.com is AMZN, so it seems there is some precedent. Any subsequence of amazing that also contains amzg as a subsequence will expand to amazing, as mentioned previously. It sounds complicated, but ends up really being quite intuitive and easy to remember. Even if you can't remember how to spell a word, you can often come up with a proper subsequence of the word.

The source code on GitHub has a lisp function named "best-word" that you can play around with if you like, you don't need a HuiBoard to load the Lisp package and use most of the the functions. To use it:

(best-word "amzn")

will return the string: "amazon"

There is also a function (print-best-words "subsequence") which shows the first 20 entries of a list containing all the words that contain "subsequence". The best-word function returns the first entry of such a list.

I think it should be easy to adapt this to be usable by any keyboard, I would just need to read up on how to intercept keystrokes from the OS. Right now the software reads binary representations of the current HuiBoard state from an Arduino.

Offline huiboard

  • Thread Starter
  • Posts: 9
  • Location: California
    • HuiBoard
Re: HuiBoard - open source 5 or 10 key typing system
« Reply #7 on: Mon, 26 September 2016, 00:53:28 »
Here is the output of a couple short subsequences:

HUIM> (best-word "thr")
"thru"
HUIM> (best-word "thre")
"there"
HUIM> (best-word "ther")
"their"
HUIM> (best-word "th")
"the"

Some words get a bigger boost:

HUIM> (best-word "hv")
"have"

So "the" would also be one input, and there/their/thru would be two inputs. I see what you mean, thanks for posting the video. You're basically chording with more keys! Very neat. I've never tried Colemak, and my janky QWERTY does not have n-rollover.


Offline huiboard

  • Thread Starter
  • Posts: 9
  • Location: California
    • HuiBoard
Re: HuiBoard - open source 5 or 10 key typing system
« Reply #8 on: Mon, 26 September 2016, 00:55:57 »
And the longest word in the dictionary on my Ubuntu machine:

HUIM> (best-word "eclh")
"electroencephalograph"

Offline algernon

  • Posts: 311
  • A tiny mouse, a hacker.
    • Diaries of a Madman
Re: HuiBoard - open source 5 or 10 key typing system
« Reply #9 on: Mon, 26 September 2016, 01:43:55 »
I've tried a chording keyboard before and even with word expansion I am very doubtful that it would exceed the speeds that an experienced touch typist can reach.

The Guiness World Record is 360 WPM on a Steno machine, which is a chorded keyboard, basically. That's quite a bit more than the top touch typist's speed (which is around 212 WPM). The average steno-typist is also faster than the average touch typist, and usually even faster than the top touch typists.

Quote
The slowness from chording comes from the need to coordinate finger presses. Because not all fingers will press down at the same time, the software needs to provide a time frame for all the fingers participating in entering a single letter to press down on keys. This pause is not necessary when entering single strokes, and five fingers on a normal keyboard could enter five different letters nearly simultaneously.

It is very easy for Steno hardware to do chording: wait until all keys are released. As soon as that happens, expand. No additional delay. The Steno systems are set up so that you have to do minimal finger and hand movement, so the hardest part becomes memorizing the shorthands. Once you have that, five fingers can type 10+ chars in the same time a touch typist can type five symbols. And once you use ten fingers for Steno, touch typing becomes as slow compared to it, as hunt-and-peck is to touch typing.

Even if you do Steno in software, the delay is still minimal, because the software can keep track of which keys are pressed, and do the expansion once all of them are released - and it only has to remember which ones were pressed. Not hard - very easy to do, in fact.

In practice, pressing five keys takes the same amount of time on both Steno and normal keyboards, the only delay is in seeing the result on-screen. With touch typing, you see each char individually. With Steno, you get the whole word all at once. But other than that, there is no delay. Most touch typists can type even if they don't look at the screen either, so having a bit of delay there is no issue.

Quote
Chording with word expansion is limited by the one letter at a time problem.

There are Steno systems that make chords VERY efficient.

Quote
none of which have any notable following.

Perhaps not in the keyboard community, but live-captioning for example is nearly impossible without Steno. There are many other areas (such as court transcription) where touch-typing is just too slow. Steno - and Chorded systems - work very well. You just need a good system, and a lot of patience to learn it.
 I tried it personally for some time for amusement and because I thought it would be fun to be able to type with one hand while using the mouse in another.

Speech recognition will very likely be the near-future replacement for the keyboard, which is a lot more accessible to most people as it doesn't require any special training.
[/quote]

Offline oneproduct

  • Posts: 859
  • Location: Montreal, Canada
  • @Ubisoft
Re: HuiBoard - open source 5 or 10 key typing system
« Reply #10 on: Mon, 26 September 2016, 06:14:48 »
@algernon
I absolutely agree that Steno is faster than regular typing. I specifically mentioned that Steno doesn't quite behave the same as ETL because in Steno the chords represent syllables more so than single letters, which is what makes the shorthand less jarring than with ETL from a mental perspective as you only need to think of the sound a word makes rather than a subsequence of words that is unique.

In Steno you also type the whole word at once because you enter the begin/mid/end of the word at the same time with the left/mid/right of the Stenotype machine. Not so with ETL where you are simply inputting letters rather than sounds.

But what do you think of ETL? Hui is trying to show that Steno is not strong because of its input method, but because of shorthand. He proposes that by using word expansion with singly typed letters, aka regular style vs Steno style, you can type fast. You could _theoretically_ (in most cases no, but there are some cases) use shorthand notation with regular typing style and regular typing style could provide input faster than a Steno machine because it is not limited by releases. The same is true with any chording input method: if you could figure out a way to avoid the need for waiting for releases, chording could potentially be faster than it already is.

Imagine two words in Steno that have non-overlapping inputs. If you weren't limited by waiting for the release, you could enter both words at once. For example, I wager I could type "i am" faster than someone on a Stenotype machine because the Stenotypist would have to write "i" as one sequence and "am" as a separate one whereas on a regular keyboard you could write it all in one slightly offset stroke, with the type of style shown in my video.

So again, I have no doubt Steno is faster than regular typing, but chording could be faster if it wasn't limited by releases and ETL doesn't share the same human-friendly shorthand that Steno does, at least as I perceive it. More on that below.

@Hui
I somewhat disagree with your statement that it becomes rather intuitive, at least not so compared to Steno due to the naturalness of Steno's syllable based system versus subsequences. To look at one of your cases:

HUIM> (best-word "thre")
"there"
HUIM> (best-word "ther")
"their"

I find these best words rather unintuitive. I would imagine things more like:
ther -> there
thre -> three

as each is an in order, direct match. While I understand that there is a systematic way to assign a unique, best identifier for each word, I find it is anything but intuitive and memorizing these types of shorthands is much harder than simply considering the sound the word makes when spoken and using the syllable sound on a Stenotype machine. The former requires analysis of words other than the word you wish to input (a non-constant operation) vs analysis of just the word you wish to input (a constant operation).

I imagine in Steno that there/their would be the same input (or perhaps not, as these are common enough words that perhaps they have dedicated inputs, but the point I'm trying to make will be the same), but that Steno would resolve which one it is through context rather than through different inputs. This is natural language processing vs dictionary matching and it is inarguable that natural language processing is the more powerful of the two systems as it is a superset of dictionary matching. This is with modern Steno software. Back in "the old days" this NLP was provided by a Stenotypist mentally parsing shorthand when reading their text back.

I also have a question for you. How do you enter the words me, meme, I, it and its?
« Last Edit: Mon, 26 September 2016, 09:09:38 by oneproduct »
Layout: Colemak
Fastest typing speed: 131 WPM on typeracer, 136 WPM on 10fastfingers.
Daily driver: Filco Tenkeyless MX Brown with ergonomically weighted, lubed springs.
Ergo keyboards: Truly Ergonomic, Kinesis Advantage, Ergodox

Offline huiboard

  • Thread Starter
  • Posts: 9
  • Location: California
    • HuiBoard
Re: HuiBoard - open source 5 or 10 key typing system
« Reply #11 on: Mon, 26 September 2016, 11:35:37 »
I coud be wrg, bt I thk it's vry intutv and esy to lern. It bscly fnctns as a dctnry
basd cmpresn algrthm, lk LZW. https://en.wikipedia.org/wiki/Dictionary_coder

Or, mathmtcly spekng, yu cn thnk of it as a prjctn of wrds dwn to a smalr subspce.

It basically lowers the dimensionality of word selection from a dictionary. You just don't need to type in all of the letters for most words.

"How do you enter the words me, meme, I, it and its?" These would all be entered as is, there are no shorter subsequences that uniquely identify them.
« Last Edit: Mon, 26 September 2016, 11:41:54 by huiboard »

Offline algernon

  • Posts: 311
  • A tiny mouse, a hacker.
    • Diaries of a Madman
Re: HuiBoard - open source 5 or 10 key typing system
« Reply #12 on: Mon, 26 September 2016, 13:02:02 »
I absolutely agree that Steno is faster than regular typing. I specifically mentioned that Steno doesn't quite behave the same as ETL because in Steno the chords represent syllables more so than single letters, which is what makes the shorthand less jarring than with ETL from a mental perspective as you only need to think of the sound a word makes rather than a subsequence of words that is unique.

Depends largely on the Steno system. Plover, for example, uses a dictionary, which, by default is more or less syllables. But sometimes not, for example "PAOUBL" is short for " proximal convoluted tubule", in the default Plover dictionary, or "A/KHEL/ES" is "Achilles", and so on. It's a tad more complicated than syllables, really.

Quote
In Steno you also type the whole word at once because you enter the begin/mid/end of the word at the same time with the left/mid/right of the Stenotype machine. Not so with ETL where you are simply inputting letters rather than sounds.

I don't really see a big difference, except for the dictionary. (Plover has an input method where you finish a sequence by hitting space, for keyboards without NKRO).

Ok, Steno is a little bit smarter, because it allows you to use multiple chords to input a single word - or at least Plover is smart enough for that. But you can get pretty far with a specialized dictionary too, and avoid the release problem.

Quote
The same is true with any chording input method: if you could figure out a way to avoid the need for waiting for releases, chording could potentially be faster than it already is.

But that is already figured out: have a system where you - in most cases - don't need to hit the same key twice to enter a word, thus, you can just hold all the keys required for the chord, and once the last one is released, a dictionary lookup is made. For the rare case where you'd need to hold the same key twice, you split the word, and use two chords to enter it. This should be the rare case, though, and at this point, the slowdown of having to use two chords is negligible compared to the speed gain by using short chords to enter full words.

Also, consider that with any reasonable chording system, you can press the keys in any order. "HABG", "GBAH" and any combination of these keys will still expand to "hack". This is quite a relief for your brain, you don't have to care about key order, so inputting a four-key chord to type a four-key word is in most cases faster than typing it out letter by letter, because of not having to pay attention to the order. Put it in another way: I don't have to wait for "h" to register before I can type "a".

In most steno systems, there are less keys than on a normal keyboard, thus less movement too.

Nevertheless, I do agree that the simplistic abbreviations presented before are inadequate to achieve higher speeds. But that's not the fault of chording, or the input system, but of the dictionary, mostly.

Quote
Imagine two words in Steno that have non-overlapping inputs. If you weren't limited by waiting for the release, you could enter both words at once. For example, I wager I could type "i am" faster than someone on a Stenotype machine because the Stenotypist would have to write "i" as one sequence and "am" as a separate one whereas on a regular keyboard you could write it all in one slightly offset stroke, with the type of style shown in my video.

The default Plover dictionary has "EU/-PL" as the chord for "I am". That's four keys to press - exactly the same amount as typing it one by one, and you can do it in one stroke. If you take order and the need to wait for "I" to register before you can press space into consideration, Steno will be faster. Even if you'd need two Steno strokes to input "I am", you'd only have to wait for "I" to register (which happens at release) before you can input the next chord, while with touch typing, you have to wait for each char to register before tapping the next, and have to pay attention to order too. A good chording system, with a good dictionary makes wait time a lot less.

Quote
So again, I have no doubt Steno is faster than regular typing, but chording could be faster if it wasn't limited by releases and ETL doesn't share the same human-friendly shorthand that Steno does, at least as I perceive it. More on that below.

I agree that the shorthands presented before are not great, but again, that's the fault of the dictionary. Chording is considerably faster with a good dictionary and expansion system.

Quote
I imagine in Steno that there/their would be the same input (or perhaps not, as these are common enough words that perhaps they have dedicated inputs, but the point I'm trying to make will be the same), but that Steno would resolve which one it is through context rather than through different inputs.

Most Steno systems don't do NLP, and they don't look at context, unless you specifically instruct the system to do so: like, "I'll be entering a single word, in multiple chords, don't put a space between them", or similar. But that needs manual action.

(for the record, "THR" is "there", "THAER" is "their" in Plover)

Offline oneproduct

  • Posts: 859
  • Location: Montreal, Canada
  • @Ubisoft
Re: HuiBoard - open source 5 or 10 key typing system
« Reply #13 on: Mon, 26 September 2016, 13:13:36 »
@Hui
For a compression algorithm or someone kind of algorithmically minded, I can understand. But I think if you ask an "average" person if they think "ther" would lead to "their" or "there" that the answer you'd find would be either mixed or more towards "there." Of course people could learn all the shorthands, but for a casual user many of the shorthands would probably have to line up with certain of their built in perceptions.

Also I really don't think that a person is able to fluidly translate words like dictionary into dctnry. How do you readily remember which letters are omittable? It's not always just vowels that can be omitted, as you had "lern" as an example. I think it's not easy to memorize that you can write learn without an a. When thinking mentally, how do you ensure that the shorthand you chose doesn't match with another similar word rapidly? I'm certain for common words you would eventually get the hang of it, but for less common words I imagine you'd have to sit and think for a bit, or do some trial and error. As an experiment for yourself, think of a phrase using some less common words and without using the function that returns the best shorthand, see if you can get it 100% correct using the optimum shorthand for those words. I'm sure you'll probably do fairly well, because you're the creator, but humor me. ;)

Also, consider that in ETL, the shorthand could be any combination of letters to best represent a word, whereas in stenotype there are a fixed number of syllable sounds. Yet even for those it takes a considerable amount of time to learn and memorize.

Also, as for the short words I asked you about, I misunderstood about when word expansion takes place, my mistake. I thought you didn't need to input spaces like stenotype, and that in ETL the word would just expand the moment it sees a unique identifier.

@Algernon
Thanks for that info. I'm not fully aware about Stenotype, so I'm trying to make educated guesses here and there or explain ideas whose intent should hopefully be clear even if the particular example I choose isn't quite right.

My main point however was not to put Steno down, but to suggest that ETL is more akin to QWERTY than Steno, yet that it simple introduces a weakness of release time. Since ETL's power relies on the dictionary, QWERTY could do much the same, because anything you can input in ETL could be inputted in QWERTY in the same amount of time as ETL only allows two letters to be pressed at a time while QWERTY allows more. Using the same dictionary you could achieve the same thing as ETL on QWERTY. Of course ETL then stands out for its smaller form factor, which is fine, but I wouldn't say that it is faster than QWERTY.

Stenotype on the other hand is not like ETL or QWERTY because the input method is not individual letters, so that puts it ahead of ETL and QWERTY in terms of speed as its input method is suited specifically to this particular task.
« Last Edit: Mon, 26 September 2016, 13:21:58 by oneproduct »
Layout: Colemak
Fastest typing speed: 131 WPM on typeracer, 136 WPM on 10fastfingers.
Daily driver: Filco Tenkeyless MX Brown with ergonomically weighted, lubed springs.
Ergo keyboards: Truly Ergonomic, Kinesis Advantage, Ergodox

Offline huiboard

  • Thread Starter
  • Posts: 9
  • Location: California
    • HuiBoard
Re: HuiBoard - open source 5 or 10 key typing system
« Reply #14 on: Mon, 26 September 2016, 14:34:05 »
Using text expansion on QWERTY would definitely be faster than Hui. I doubt Hui could ever be as fast as steno. Though a proficient Huiboarder with text expansion should be faster than most QWERTY users that aren't using text expansion. I wasn't trying to optimize for speed, as most people can already type fast enough on QWERTY for most purposes. I wanted to make sure that typing on ten keys would not make speed handicap, so that a physical keyboard could be built into mobile devices, in gloves, or used with a machine vision device like Leap Motion etc. Ubiquity and ease of implementation across virtual and physical spaces is the main benefit, I think.

Text expansion is a choice after a sequence of letters has been entered:
1. The thumb key acts as a space, and leaves the subsequence as entered with no text expansion
2. The index finger key activates text expansion, and also adds a space at the end. Pressing the index finger again sends the "enter" keystroke.

You can always type out the full word, and for words like "me" the text expansion just produces "me", so the index and thumb buttons produce equivalent results in this case.

Right now the optimum subsequences are found by trial and error, but I can almost always enter a longer non-optimal subsequence by omitting some letters on longer words. There are at least two "more optimal" subsequences than the shorthand "dctnry" in the prior post, but you are right - they aren't as quite as intuitive:

HUIM> (best-word "dcnry")
"dictionary"
HUIM> (best-word "dtnry")
"dictionary"

Generally though, if it looks like the word, most likely it will expand to the word - but not always. The number of examples where it doesn't work seem to be much less than number where it does work. You would have to slowly get the hang of it. My ten year old can do it pretty well, but quickly gets bored with typing. I'm thinking of having the thumb buttons pop up into joysticks, sort of like a ballpoint pen click mechanism, so it can be used as a chorded game controller and trick kids into learning it lol. It would be good for RPG's since the eight keys on the back of the phone would have 256 possible chord combos.

Do you guys thing a Bayesian/autocomplete approach might work better than the subsequence approach for ten keys? I'm trying to stick with shorthand notations that can be automatically interpreted or generated from a word frequency list, but maybe it needs to move up to the word or phenome level. There's no reason why it can't have different chording systems available as different modes. Also, the software can be easily extended to include more or less keys on each hand, such as three thumb buttons like the BAT keyboard.
« Last Edit: Mon, 26 September 2016, 15:01:41 by huiboard »

Offline oneproduct

  • Posts: 859
  • Location: Montreal, Canada
  • @Ubisoft
Re: HuiBoard - open source 5 or 10 key typing system
« Reply #15 on: Mon, 26 September 2016, 15:00:35 »
I strongly believe that for an average user autocomplete is the better approach. I doubt most people would have the will to learn shorthand for a large variety of words. Those times where people do feel comfortable with shorthand, they already make use of it with things like "luv, u, grats, lol" and the like. The autocomplete could even suggest both the full word and a shorthand version for it in parentheses, and more advanced users could choose to memorize the shorthand (much like many emojis offer both a mouse and text input option; people start to memorize the text input method for emojis they use commonly, such as :) ).

That being said, it would be nice if the autocomplete were "fuzzier" than many autocomplete options that exist. For example, in my programming IDE, my autocomplete plugin would let me write "acom" and suggest "autocomplete" for it, and I tend to write like that. What makes the difference is that rather than the shorthand being replaced automatically, it provides me with a list of options so I can understand what the software thinks I might mean, and I can see how different inputs provide different suggestions. This case is slightly different however as the suggestions come from existing text in the appropriate scope rather than any word in the dictionary, so this context sensitivity helps a lot.
« Last Edit: Mon, 26 September 2016, 15:04:38 by oneproduct »
Layout: Colemak
Fastest typing speed: 131 WPM on typeracer, 136 WPM on 10fastfingers.
Daily driver: Filco Tenkeyless MX Brown with ergonomically weighted, lubed springs.
Ergo keyboards: Truly Ergonomic, Kinesis Advantage, Ergodox

Offline huiboard

  • Thread Starter
  • Posts: 9
  • Location: California
    • HuiBoard
Re: HuiBoard - open source 5 or 10 key typing system
« Reply #16 on: Mon, 26 September 2016, 17:01:49 »
Yes, this is actually where I was going to go with this idea. Right now the software knows what program the user is currently typing in, but I haven't made the dictionary context dependent yet. Maybe I should have specified this earlier, but the "dictionary" in the program is actually a global variable that can be changed based on application. What I described earlier is more of a prototype for typing English, say, into a blank Word document. Right now the default dictionary that loads at startup is English, and it's the only one that has been implemented so far.

For example, I use Emacs to write Lisp. Since the software knows I am currently using Emacs in Lisp mode, the dictionary will be populated with Lisp "words", as well as the words that are in the current buffer.

Eventually it will have context and app dependent features. So far only one is defined - the "kb" shortcut kills a buffer when in Emacs (sends keystrokes: ctrl+x k), and closes a tab when in Chromium (ctrl+w).

The (best-word-list) function provides the list you are talking about, but I need to make a good way to present it to the user.

With a context dependent (much smaller) dictionary "acom" could expand to "autocomplete", though with a large dictionary I'd have to figure out a good algorithm for disambiguation. It might be difficult to get the contents of a text field in programs that don't have an API to do so. Maybe a - select all - copy - then read text from clipboard would work, and then keep track of keystrokes to edit a virtual buffer to stay in sync.
« Last Edit: Mon, 26 September 2016, 17:20:09 by huiboard »