Brakey

Brakey is a keyboard layout that is designed to account for a gap in traditional approaches in layout design. Most layouts are designed by changing the arrangement of keys to optimizing common metrics like same-finger bigrams, scissoring, and rollings. This can affecting figure usage distribution and typing comfort, but it does not ultimately change the total number of keystrokes required to type out a text. The name "Brakey" comes from combining "brachy" (short) and "key", as in to shorten keystrokes.

Brakey is a keyboard layout that puts macro keys forward as first-class citizens, where there are keys dedicated to common bigrams, trigrams, etc. The design aims to minimize the number of keystrokes for typing without significant compromises to typing comfort or familiarity. The introduction of ten new keys results in about a 10% reduction in keystrokes. The increase in number of keys will likely reduce how quickly one can stroke keys due to the increase in lateral motion, though this is balanced out by the reduction in number of keystrokes needed to type out a text. Although speed is not a direct design goal, skilled usage of a keyboard layout with macros could increase typing speed, depending on how these factors balance out.

Layout

This keyboard layout requires a base ×ばつ10 grid and is optimized around a columnar layout. It requires more planar motion than traditional keyboard while requiring fewer key presses. Numeral inputs are delegated to a separate layer (not shown).

Example sentences

Words no longer have a unique representation. There may be multiple sequences of key strokes that can result in the same word. For example, "here" can be typed as "here","here".

• The chef prepared a meal using fresh ingredients for her guests. She seasoned the dish with herbs and spices, then served it.

• The gard en er tended to her garden with great care and attention. She planted seeds and watered them regularly for ensuring flawless growth. / Before edits: "The gardener tended to her garden with great care and attention. She planted seeds and watered them regularly, ensuring healthy growth before winter arrives."

• The engineer designed a revolutionary device! After testing it, he presented his findings and recommendations to the board members before implementation.

Development

Selecting the bindings

To start, I decided I wanted to only focus on defining custom macro bindings to reduce keystrokes rather than other approaches like using magic keys or leader keys for this purpose. But I had to limit my scope further. I decided to keep the original 26 alpha keys but realized that the standard ×ばつ10 grid would be woefully insufficient. I co-opted the row typically used for numeral keys, delegating those to a separate layer, as a means to free up 10 keys that I can use for my macro bindings. This was my target, 10 macro keys.

Deciding on which macros to use for the ten bindings was not completely clear. A dedicated thorn key for entering th was an obvious candidate as well as common suffixes in words like ed or ing, but I wanted to approach this systematically and quantitatively. I needed a database of not only letter frequencies but also bigram, trigram, etc. frequencies. I specifically sought out non-normalized frequency data (occurrences) so that I can compare across different levels (e.g., 2-grams vs. 3-grams). Douglas (2021) provided a cleaned dataset of such values primarily for the use of keyboard layout analysis based on a variety of sources. I'm specifically using the frequency values based English corpus and not the computer code corpus.

With the dataset downloaded, I prepared some Python code that loaded the data, did some mild cleaning, and analyzed the frequency values. For every n-gram at each level, I quantified marginal utility: the number of keystrokes that would be saved if I were to define a binding that maps a single key press to enter that n-gram. I then created a bar chart, sorted by marginal utility, to see which n-grams are the best candidates for my macro bindings.

Histogram of n-gram marginal utility and occurrences

Here I'm depicting the top 50 due to limited space, but I was looking at the top 100. The lack of unigrams is due to the fact that we don't save any keystrokes by defining a new 1-gram that already exists, but otherwise we see a lot of bigrams, a handful of trigrams, a few quadgrams, and one pentagram. It is important to remark that bindings are not strictly independent. This assumes the marginal utility for the each singular binding, while there will actually be interaction in the actual marginal utility when making multiple simultaneous definitions when there is overlap in the macros. For example, the, th, and he have clear overlap, so a definition of one would reduce the marginal utility of the others. For simplicity, I don't iteratively define marginal utility but rather just use this chart for selection of macro bindings.

There are ten bindings to choose from this chart, so I walk through starting with the greatest marginal utility and define the bindings heuristically. Starting from the top, it's interesting to see that the macro dethrones the thorn macro for th. This suggests that a dedicated key for "the" might have more utility than a dedicate key for "th". Indeed, it seems 68.4% of instances of "th" are followed by an "e". This can be seen by looking at the top 100 most frequent English words from the Google Books corpus (orgtre, 2023): Eight words contain "the" whereas only three are "th" followed by a different letter. Due to the heavy overlap, it didn't make sense to define both the and th, and despite "th" being 30 more common than "the", I felt more compelled to go for the greater marginal utility of "the", so I defined the is my first macro binding and do not consider th. For similar overlap reasons, I also do not consider he.

For the next candidiate in, I noticed there was overlap with other existing n-grams as well: ing and ng, the former with more utility. This situation is a bit different than earlier since there is a larger gap between these. The frequency of in is only due to appearances in ing in 34.4% of cases. I made the possible ill-sighted decision to define the second macro binding as ing rather than in. The primary reason is that "ing" is a quite common morpheme with its own grammatical function, and more easily memorable. In contrast, usage of "in" is primarily not as a morpheme: Of the most common 10,000 words, only 19.2% of the ones containing "in" begin with this (orgtre, 2023).

For similar reasons as above, I defined the binding macro for and over an or nd. There is overlap between er and her, but since this was significantly more separated, I opted to define a binding macro for er. Similarly, there was a large gap between en and the much less commont ent and nt, I defined a binding for en. I defined a binding with re, which did not have overlap with any of the top candidates.

The next bindings required considerable thought. There was set of possible bindings that had overlap, namely {on, at, tion, ion, ti, ation, tio, atio, io, ati}. These stem from how the 5-gram "ation" is somewhat common while also boosted by large marginal utility arising from skipping 4 of the 5 key presses. I quickly discovered though that tion is much preferred over ation since it had 42.3% greater utility and is used 89.8% more frequently, so I dismissed ation a as a reasonable option. The decision between tion and ion was less clear because the later is 28.7% more common but with a bit lower utility of 14.2%. I was also considering the candidate at as a key binding, which had pretty high utility, so I opted to define at. I wanted to avoid overlap between bindings, so I decided against defining a bind for tion. Since io is much less common, I am now considering whether to define ion or on. Around 64.4% of instances of "on" are due to "ion" while having 40.5% greater utility, I opted for on over iondespite how ion is a stronger morpheme.

At this point, I had seven bindings and needed three more. These ones were straightforward as they were the next ones on the list: ed, or, and es. This finalizes the choice of all ten keybindings.

Note

The final set of ten key bindings: the, er, and, re, ing, on, en, ed, or, es

When holding shift with standard alpha key, the corresponding unigram becomes uppercase when entered. This behavior is somewhat ambiguous when applied to one of the new bindings. Should the whole macro become uppercase, or shoud just the first letter become capitalized? I chose to have just the first letter become capitalized when holding shift.

Reduction in keystrokes

One of the main goals of this layout is to reduce the keystrokes. The above process of selecting the bindings with the marginal utility gives a rough idea on how much reduction there will be. However, it is best to directly calculate it to ensure we aren't double counting any reductions and thus overestimating the savings. I took Shai Coleman's corpus to calculate the number of keystrokes it would take to type out the entire corpus. Capital letters and certain symbols require pressing the shift key, each of those counted as requiring an additional key press (e.g., by replacing "A" with "⇧a"). I did this process for a baseline case, using standard layout without any macro or leader keys, as well as the proposed bindings above. The arrangement does not matter for this, as long as they are not behind any layers requiring additional key presses. Since numbers now hidden behind a layer, I also prepended them by a dedicated layer key ("123" → "⠧123").

Note

Reduction in keystrokes: 9.88%

Arrangement of bindings

With the new bindings defined, we need to actually associate each with a physical key. I opted to use an Ergodox EZ out of convencie because I already own one and it was being unused. I also want to help my brain not confuse my currently primary Dvorak keyboard layout, nearly exclusively typed on column-staggared keyboards, with this new layout. Using this keyboard solely for this layout and vice-versa will help with forming the association and context-dependent memory. For similar reason, I didn't want to take the layout I'm currently using and just modify it, I wanted to take another existing layout and change it. I chose to start with the column staggered variant of the Gallium keyboard layout, but with an additional row above these keys for additional room. I already have a separate layer for numerals, so the top row was unused and usage of numbers should be straightforward still.

However, it would be not ideal to have these keys simply placed at the top without concern for their usage. Some of these bigram or trigram bindings would surely have more usage than some unigrams! But to be sure, we would need to determine a new frequency analysis for unigrams. Additional to unigrams, determinig new frequencies for bigrams and trigrams woul dbe helpful in evaluating keyboard performance through finger bigrams (SFB), same finger skipgrams (SFS), etc. To do this robustly, I took Shai Coleman's corpus again, replaced macros with a Unicode character representation of the key, and performed an n-gram analysis for levels 1 through 3. Below, I show only the key unigram results, replacing the Unicode character with the macro for presentation purposes.

Histogram of key-level n-gram occurrences (after macro application)

For comparison, this is what the unigram results look like without any macro definitions:

Histogram of baseline key-level n-gram occurrences (without macro application)

Next steps: Calculate performance and define arrangement of bindings

Heatmap of key usage for the keyboard layout

Future directions

• Demoting infrequently used 1-grams to a separate layer
• Support and analyze leader keys (sequences of key presses defining bindings)

References

• GalileoBlues, "Gallium." Github (2024) keyboard layout.
• I. Douglas, "Keyboard Layout Analysis: Creating the Corpus, Bigram Chains, and Shakespeare's Monkeys (1.0.2)." Zenodo (2021).
• J. D. Opdyke, "A unified approach to algorithms generating unrestricted and restricted integer compositions and integer partitions." Journal of Mathematical Modelling and Algorithms 9.1 (2010): 53-97.
• "orgtre, "Google Books n-gram frequency lists." Github (2023)
• Ergodox EZ
• Shai Coleman, "title." Colemak (2024)

Disclaimers

• This work is licensed under CC BY-SA 4.0.
• Source code (src/) is licensed under MPL-2.0.
• External data (data/) used in the analysis are copyrighted by their respective owners.