[~] BACK

~~ KYB3R_KEYS ~~

** EIN DIY KEYBOARD LAYOUT **

[HOW] | [20231107] | [20231120] | [0x17]

VERSION: 0.4 | 2023-11-16 [CHANGELOG]

Vor ein paar Jahren war ich auf der Suche nach einer neuen Tastatur und bin dann in ein Loch gefallen, dass mich bis heute nicht mehr losgelassen hat und immernoch fasziniert mit seinen immer wieder neu aufkommenden Themen und der Vielfältigkeit die sich auftut. Ich hab ein paar Keyboards gebaut und ausprobiert und kann für mich sagen, dass mir die CRKBD (Corne) am besten gefällt bis jetzt. Wenn man sich in diesem Hobby bewegt kommt man irgendwann an den Punkt, wo einem das default QWERTY Layout nicht mehr wirklich taugt und an genau dem Punkt bin ich jetzt. Also versuche ich mich mal an meinem custom Layout, das komplett auf meinen Usecase angepasst ist. So hab ich ein (hoffentlich) perfektes Layout und vielleicht hat ja jemand von euch einen ähnlichen workflow oder es hilft euch auch beim designen eures Layouts.
Wenn ihr das Layout auf eurem Keyboard habt, reicht ein Default US-Keyboardlayout am Rechner, damit alle Keys das tun was sie sollen. Wenn ihr die deutschen Umlaute Ä, Ö, Ü und ß haben wollt empfehle ich euch das EurKey Layout. Hier bleibt die Keymap die gleiche, aber ihr habt zusätzlich die Möglichkeit Umlaute per ALT-GR zu generieren.

0x01 - VORAUSSETZUNGEN

Bevor es aber ans eingemachte geht, müssen die Parameter nach denen das Layout gebaut ewrden soll, definiert werden. Fangen wir beim einfachsten an - welches Keyboard soll benutzt werden. Ich benutze die oben schon erwähnte CRKBD / CORNE mit 3x6 +3 Keys als daily driver. Die CRKBD hat als Main-Cluster (also der Block auf dem die Alpha Keys liegen) 3x5 Keys, d.h. drei Reihen und fünf Spalten. Jeweils an den Außenseiten befindet sich noch eine Spalte für Modifierkeys wie ESC, CTRL, ALT usw. Für die Daumen gibt es ebenfalls jeweils drei Keys die aber nur sekundär was mit den KYB3R KEYS zu tun haben, aber dazu später mehr. Das ganze sieht in der Hardwarevariante dann so aus:



Die nächste Überlegung sollte der Usecase des Keyboards bzw. des Layouts sein. Hier hab ich mir die letzte Zeit mal angeschaut was ich so auf meinem Keyboard tippe. Grundsätzlich kann ich sagen, dass es hauptsächlich um Code und Fließtext geht. Jetzt propagiere ich hier auf der $NB des öfteren, dass ich lieber Terminaltools als GUI-tools benutze. Da ich für die meisten Tools mittlerweile Aliase benutze würde ich die Terminal-Commands mit zum Fließtext zählen. Terminal-Optionen die noch nicht in einem Alias verbaut sind, finden sich dann trotzdem noch recht schnell. Beim Blick auf den daily use verteilt sich die Nutzung von Code zu Fließtext im Verhältnis 30% Code zu 70% Fließtext. Der Code den ich baue ist größtenteils Python, Nix, Vimscript, Bash und Markdown. Die hier benutzten Sonderzeichen verhalten sich relativ gleich. Die Analyse zur Benutzung der Sonderzeichen werde ich mir zu einem späteren Zeitpunkt nochmal vornehmen, wenn das Grundgerüst des Layouts steht. Was ich nicht ganz außen vor lassen kann (und will) ist die Benutzung von XMonad als WM. Der braucht in meiner Config den GUI-Key zur Steuerung - aber auch dazu später mehr.




Beim Fließtext wechsel ich zwischen Deutsch und Englisch. Hier liegt die Verteilung bei 60% Englisch und 40% Deutsch. Diese Überlegung hat den Grund, dass es relativ komfortabel ist Umlaute wie Ü, A, Ö direkt griffbereit zu haben, da diese doch relativ häufig auftreten. Da der Fließtext hier den größten Teil einnimmt, werde ich mich auch vorrangig an diesem orientieren. So ergibt sich eine Prioritätenliste von 1. DE Text, 2. EN Text, 3. Code. Den nächsten Schritt den ich gemacht habe ist der Vergleich der ersten beiden Prios.

0x02 - VERGLEICH DE | EN

Wie können zwei Sprachen am besten verglichen werden? Brechen wir es runter auf das was bei beiden Sprachen identisch ist. Die benutzten Zeichen und deren Häufigkeit. Ich habe mir die Arbeit erspart diese Recherchen und Analysen selber durchzuführen. Genau das haben nämlich schon viele Menschen vor mir gemacht und auf deren Ergebnisse greif ich einfach zurück. Was ich verglichen habe, um ein einigermaßen valides Ergebnis zu bekommen, sind die Zeichen die in beiden Sprachen gleich sind. Ich habe also im deutschen die Umlaute ignoriert und nur die restlichen Keys verglichen. Die allgemeine Graphemhäufigkeit, also wie oft wird welcher Buchstabe benutzt, verteilt sich auf beide Sprachen wie folgt:



Beim ersten Blick darauf wird klar, dass einige Keys ähnlich oft benutzt werden. Das könnte daran liegen, dass die Sprachherkunft beider Sprachen sehr ähnlich ist. Wenn wir beide Sprachen direkt nebeneinander legen, sehen wir den Diff bzw. die Übereinstimmungen. Wenn wir uns den Aufbau des Keyboards anschauen, haben wir das oben schon erwähnte 3x5 Alphakey Cluster pro Seite. Die mittlere Reihe an Keys. Nennt sich Homerow. Dort ruhen die Finger, wenn sie mal nicht Tippen. Da diese reihe die Basis des Layouts ist, habe ich die 10 (bzw. 12) häufigsten Buchstaben genommen und die für die Homerow reserviert.




Die Homerow hat allerdings nur 10 Keys. Durch den Diff im Vergleich der beiden Sprachen entstehen aus den häufigsten 10 Keys schnell 12 Keys. Beide Sprachen unterscheiden sich bei O/D und bei L/U. Wie gesagt orientiere ich mich am englischen und behandel deutsch zweitrangig. Die Verteilung der Keys findet hier von Innen nach Außen. Grundlegend würde ich davon ausgehen, dass der Zeigefinger schlicht der stärkste ist und wir diesen auch anders belasten können als bspw. den kleinen Finger. Die zwei Keys die sich aus dem Diff ergeben, schiebe ich eine Row weiter runter, aber ebenfalls auf Position des Zeigefingers. So ergibt sich folgende Layoutbasis:



Nun tippen wir aber nicht nur reine Buchstabenfolgen, sondern es gibt auch noch Bigramme und Trigramme die häufig getippt werden. Die Trigramme ignoriere ich vorerst. Eventuell schau ich mir die an, wenn ich ein etabliertes solides Basis-Layout habe. Also zu den Bigrammen. Bigramme sind Zeichenfolgen die sich regelmäßig wiederholen. Im Vergleich von Englisch und Deutsch sind die 10 häufigsten Bigramme folgende:



Leider gibt es hier kaum Dopplungen zwischen EN und DE. Was ich gemacht habe um das ganze etwas einzudampfen, ist zu schauen welche Bigramme die gleichen Zeichen benutzen, aber in andere Reihenfolge. So z.B. ER | RE oder IE | EI. Danach habe ich das ganze nach Häufigkeit, mit Fokus auf EN sortiert. Daraus ergibt sich eine finale Liste von Bigrammen die sich wie folgt aufgliedert:



Das nimmt natürlich Einfluss darauf wie die Keys im Alpha-Layout verteilt werden. Grundsätzlich ist es hand- und fingerschonender wenn die Zeichen der Bigramme auf beide Hände verteilt werden. Hier natürlich auch unter Berücksichtigung der allgemeinen Keyhäufigkeit und dem Diff zwischen Homerow und sekundären Keys. Nach etwas Hirnverbiegung und viel Club Mate hat es dann aber funktioniert.

Weiter geht es mit der Verteilung der restlichen Keys. Diese Unterscheiden sich dann deutlicher als die ersten zehn Keys. Statt zwei Diffs haben wir hier nur noch zwei Übereinstimmungen. Aber auch hier würde ich die Verteilung der benutzten Keys, je weniger benutzt, desto weiter nach außen. So werden die schwächeren Finger geschont bzw. die Belastung ausgeglichen durch die zusätzliche Benutzung der Modifier Keys and den Außenseiten.


Ich hab aus der schon erwähnten wunderbaren Community, noch ein Tool (LINK)empfohlen bekommen, welches die benutzten Keys, nach Häufigkeit farblich hervorhebt und zusätzlich noch die Bi- und Trigramme analysiert. Im default macht das Tool das mit einem englischen Textkörper. Ich werde mir das mal anschauen und vielleicht noch einen deutschen mit reinnehmen. Das ganze sieht dann für das KYB3R_KEYS Layout so aus:

0x03 - MODIFIER (THUMBCLUSTER)

Ohne die Modifier geht es natürlich nicht. Fangen wir an beim Thumbcluster. Also den drei Keys pro Seite die für den Daumen bestimmt sind. Viele sehen es anders aber ich find es super: SPACE auf der linken Seite und ENTER auf der rechten Seite und das auf den jeweils inneren Keys. Grade für Terminal-Kram ist das in meinem Fall sehr praktisch. Die mittleren Keys sind auf der linken Seite SHIFT und auf der rechten Seite BACKSPACE. Die beiden äußeren keys sind ALT links und rechts ALT GR.




Dann wären da noch die Modifier links und rechts außen. Also die Modifier die von den kleinen Fingern bedient werden. Hier orientiere ich mich zum einen an VIM und zum anderen an XMonad. So gibt es auf der linken Seite von oben nach unten TAB, ESC und LGUI. Da ESC in VIM recht häufig zum Einsatz kommt, wandert es hier in die Mitte damit die Aufwärtsbewegung des kleinen Fingers verringert werden. LGUI darunter ist der Mod-Key für XMonad. Mit diesem werden unter XMonad neue Terminal-Instnazen gestartet, Workspaces gewechselt, Tools zwischen Workspaces verschoben und und und. Die Abwärtsbewegung des kleinen Fingers ist etwas schonender als die Aufwärtsbewegung, deswegen die Position. Aber nicht nur der LGUI Key ist hier wichtig sondern auch Combos von LGUI mit LSHFT oder ALT. Das ganze ist hierarchisch in meiner xmonad.hs festgehalten:




Auf der rechten Seite sind die Mods von oben nach unten DEL, STRG und RSHIFT. DEL ist auf dieser Position gelandet, weil hier das Muskelgedächtnis nicht sonderlich umtrainiert werden muss. STRG ist wieder mittig um den Weg des kleinen Fingers kurz zu halten, da STRG ebenfalls recht oft benutzt wird. RSHIFT ist als Redundanz zum LSHIFT auf der linken Seite.

0x04 - LAYER

Damit haben wir das eigentliche Basis-Layout. Nun ist ein 3x5 Alphakeycluster aber von Haus aus zu klein um Zeichen wie Ziffern, Sonderzeichen und Klammern abzubilden. Hier kommen verschiedene Layer zum Einsatz. Layer sind Ebenen zu denen per Tastendruck umgeschaltet werden kann, um die Keys im laufenden Betrieb ein anderes Mapping zu verpassen. Ich habe hier drei zusätzliche Layer zum eigentlichen Baselayer. Zum einen den SYM-LAYER, einen NAV-LAYER,einen NUM-LAYER und einen F-KEY LAYER.

Layer 1 ist der SYM-LAYER. Der kümmert sich um Klammern, Kommas, Semikolons und ähnliche Code-relevante Sonderzeichen. Bis ver. 0.3 hatte ich eine symetrische Verteilung der Keys. Alle Keys befinden sich auf der linken Seite und werden mit press+hold des linken Key im Thumbcluster der rechten Seite aktiviert.

Ich habe die KYB3R_KEYS mal im CCH!-Discord gepostet. Die Idee, die Symbole symetrisch auf der linken Seite anzuordnen, stieß eher auf - sagen wir - gemischte Gefühle. In dem Zuge hab ich mir den Sym-Layer nochmal zu Gemüte geführt. Die Analyse der Symbole ist genauso machbar wie die Analyse der Alphakeys. Da in Fließtext eher ein sehr kleiner Anteil an Sonderzeichen benutzt wird, finde ich Fließtext nicht representativ für Symbole. Die Symbole beziehen sich hier hauptsächlich auf Code, also nehmen wir doch auch Code zur Analyse. Eine wunderbare Übersicht der meistbenutzten Code-Sprachen gibts auf STATISTA.COM. Die meistgenutzten Sprachen sind hier C / C++, PYTHON, HTML / CSS, BASH, RUST, HASKELL und GO. Wenn ihr selber auf STATISTA geht, werdet ihr sehen, dass die Auswahl dort etwas abweicht von dem was ich hier heranziehe. Das hat den Grund das ich selber mit JAVA nichts zu tun habe und dann lieber noch HASKELL und BASH mit in den Topf werfe. Es bildet also nicht zu 100% die meistgenutzten Code Sprachen ab sondern variiert. Folgende zwei Parameter habe ich mir gesetzt:

[-] Code von verschiedenen Projekten um unterschiedliche Codingstile abzubilden
[-] Mindestens 6000 Lines of Code

Also hab ich mal Github, Gitlab und Codeberg durchforstet und hab für die einzelnen Sprachen folgende Messdaten generieren können:



Diese Parameter ergeben sich aus reinem Code-Copy-Paste und einem einfachen grep -c "." testat (in diesem Fall wird die Häufigkeit des Punktes ermittelt). Die grep-Befehle für die einzelnen Symbole hab ich einfach in ein kleines Bash-Script geschmissen, damit ich das nicht von Hand machen muss. So kann ich mir das Ergebniss direkt so generieren, dass es kompatibel zu LibreOffice ist. Bei grep gibt es aber ein paar Besonderheiten, die beachtet werden müssen. Es kommt zu Anomalien bei der Zeichenanalyse. Das fällt deutlich auf wenn wir uns die Häufigkeit von $ und ^ anschauen. Diese kommen mit einer auffälligen Häufigkeit vor. An dieser Stelle mal ein großes Dankeschön an PUROX. PUROX hat mir nicht nur den Tipp mit grep gegeben, sondern mich auch darauf hingewiesen, dass besagte Zeichen auch EOL Symbole sein können und deswegen wahrscheinlich überdurchschnittlich oft auftauchen. In den Ergebnissen seht ihr das ganz gut:



Hier aufgelistet seht ihr die Symbolverteilung für die einzelnen Sprachen, aufsteigend nach Häufigkeit sortiert. Nun gibt es zwei Möglichkeiten das ganze in KYB3R_KEYS zu integrieren. Entweder ich bau eine Version die auf die Summe aller Sprachen optimiert ist oder ich bau sprachspeziefische Versionen. Das einfachste ist natürlich die Variante aus der Summe aller Sprachen. Die Gesamtverteilung über alle 7 Sprachen, ebenfalls aufsteigend nach Häufigkeit sortiert, sieht wie folgt aus:



Optisch etwas aufgehübscht, sieht die Gesamtverteilung wie folgt aus. Wie bereits gesagt die Zeichen $ und ^ können wir hier getrost ignorieren, da sie einerseits EOL markieren und andererseits nicht auf dem eigentlichen SYM-LAYER liegen.



Bei der Verteilung der Symbole auf die Keys der linken Seite orientiere ich mich an der Vorgehensweise bei den Alphakeys. Ich gehe wieder vom Zeigefinger als stärkster Finger aus und die Stärke der Finger ist nach Außen hin abnehmend. Als Basis dient auch hier wieder die Homerow in der Mitte der Keys. So ergibt sich die Verteilung wie folgt:



Diese Verteilung ist wie bei den anderen Layern ebenfalls eine Mischung aus Statistik und Bachgefühl.
Ich habe lange überlegt, ob ich sprachspezifische Sym-Layer bauen soll oder nicht. Letztendlich habe ich mich dagegen entschieden. In den meisten Fällen bleibt es nicht dabei das Mensch ausschließlich C/C++ coded oder nur Haskell und so weiter. Meistens fließen bspw. Bash-Scripts mit in den täglichen Ablauf und das wäre hinderlich hier ein auf eine andere Sprache abgestimmtes Layout zu benutzen. Deswegen schnapp ich mir den Durchschnitt und mache den zum Default in der keymap.c. Ich lasse allerdings die symetrische Vertielung weiterhin als auskommentierte Version mit im Design. So könnt ihr selber testen und überlegen welcher euch besser gefällt.

Der zweite Layer ist der NAV-LAYER. Der kümmert sich um die Navigation. Das heisst in meinem Fall Vimkeys. Umgeschaltet auf den NAV-LAYER wird mit dem rechte Key im linken Daumencluster und ebenfalls per press+hold. Dadurch werden unnatürliche Bewegungen der Finger verhindert. Der Daumen auf der linken Seite löst den Layer-Key aus und die rechte Hand kann den NAV-LAYER bedienen.




Layer Nummer drei ist der NUM-LAYER. Der kümmert sich um die Ziffern und zusätzlich zu Sonderzeichen die sich bei einem Default QWERTY Layout auf den Ziffernkeys befinden. Umgeschaltet wird per mittlerem Thumbkey auf der rechten Seite. Die restlichen Keys bleiben leer. Auch hier wird per press+hold auf den Layer geschaltet.



Als ich mein Layout (noch in totaler Alpha Version) mal Menschen gezeigt habe, fiel dem Frank (Telebrot)) auf, dass es doch gar keine F-Keys gibt. Also die Keys F1 bis F12. Wir haben kurz darüber geredet, wofür er die Keys benutzt. Ich selber benutze nur F3 und der ist von mir selber auf diesen Key gemappt und öffnet NERDtree in VIM. Franks Usecase für die F-Keys: Umbenennung von Files, Website-Reload und Biosentry. Da KYB3R_KEYS fürs Terminal (und Terminal-Tools) optimiert ist, fällt bei mir das Umbennen von Files und der Reload weg. Den Bulk-Rename übernimmt bei mir ein Tool namens VIMV - darüber muss ich hier auch mal noch was schreiben. Den reload im Browser (qutebrownser) mach ich per :reload. Damit wären der Großteil der F-Key Belegungen hinfällig. Wenn da nicht das 1% Bios-Entry wäre. Das ist in der Tat ein valider Punkt. Deswegen bekommt KYB3R_KEYS einen F-Key-Layer. Er ist natürlich optional und solltet ihr ihn nicht brauchen, werft ihn raus. Die F-Keys verteilen sich auf der obersten Row von links nach rechts. Natürlich haben wir hier wieder nur 10 Keys zur Verfügung, deswegen rutschen F11 und F12 auf die Homerow. Aktiviert wird der Layer durch press+hold des TAB Keys in der linken Mod-Columns. Ich habe lange rumprobiert, wo ich den Layerswitch einbaue. Ursprünglich wollte ich ihn auf den mittleren Key des linken Daumenclusters packen. Leider ist da aber schon LSHFT. Da Shift bekanntlich per longpress + Buchstabe benutzt wird ist hier der Laywechsel per press+hold nicht möglich. Ich hatte auch im CCH! Discord gefragt was die anderen so benutzen würden und hab viele Möglichkeiten bekommen mit denen es auch gemacht werden könnte. Leider funktionierten die Optionen nicht so optimal für mich, deswegen die Entscheidung den Layerswitch auf TAB zu packen. Trotzdem ein riesen Dankeschön an die wunderbar flauschige Community.




Wenn alle Keys, Layer und Modifier verteilt sind ergibt das ganze ein wunderbares Layout, das (hoffentlich) viel Arbeit, Weg und Schmerzen spart. Ob das wirklich der Fall ist wird sich zeigen. Aktuell teste ich das ganze noch ausgiebig. Wenn es zu Änderungen kommt, werde ich sie hier im Post hinzufügen. Aber vorerst ist das hier mein gesamtes Layout:

0x05 - TESTING

Die Theorie und Software steht damit. Jetzt geht es natürlich darum das ganze auch im Meatspcae zu testen und vor allem zu schauen ob das ganze so performt wie es soll. Es gibt verschiedene Möglichkeiten das ganze zu Testen. Dafür gibt es Tools die einem die größte Arbeit abnehmen. Aber bevor ich zu den Tools komme, werfen wir mal einen Blick auf das wichtigste - das eigene Gefühl. Jemand hat im CCH! Discord mal geschrieben, es sei völlig egal wie viel WPM man auf einem Keyboard erreicht, selbst mit 10WPM merkt man schnell ob ein Layout rund läuft oder ob es irgendwo hakt. In diesem ersten Schritt des testings fühlt sich KYB3R_KEYS ganz rund an (spätere Änderungen nicht ausgeschlossen). Dann geht's an die Tools die einem wertvolle Metriken liefern. Zum einen wäre da natürlich MONKEYTYPE. Hier gibt's diverse optionen wie eure Tippgeschwindigkeit ermitteln könnt und eure Words-per-Minute (WPM) und nicht verzweifeln wenn anfangs die WPM im Keller sind, das ist normal bei neuen Layouts.

0x06 - FIRMWARE

Natürlich muss das ganze noch in Software gegossen werden. Wie auf allen meinen Boards realisieren wir das ganze in QMK, denn QMK ist gut! Ja es gibt auch VIAL - ich weiß - aber irgendwie mag ich die old-school-handkompilierte-QMK. Die QMK bietet ein nettes Command:

TERMINAL

Das legt eine komplett leere Keymap (in dem Fall für das CRKBD) an. Hier müssen dann nur noch die Keycodes für das KYB3R_KEYS Layout rein. Die Keycodes finden sich in der Doku zur QMK (HIER). Die fertige Keymapfile erspare ich euch an dieser Stelle. die könnt ihr euch in der keymap.c selber anschauen. Ich hab die fertige Keymap (inkl. dem fertig kompilierten Files bereit zum flashen) auch hier verlink, so das ihr natürlich nicht alles selber von Hand bauen müsst. Wenn alles fertig ist, muss die Firmware noch auf das CRKBD. Dazu wird das Board an den Rechner gehängt und der Resetbutton gedrückt. Nun sollte das CRKBD von der QMK erkannt werden und ist bereit KYB3R_KEYS zu flashen.

TERMINAL

Wenn alles durchgelaufen ist sollte KYB3R_KEYS auf eurer CRKBD wohnen und ihr könnt loslegen. Ich pack euch noch ein Cheatsheet mit allen Layern mit dazu. Mir hilft das ganz gut beim lernen und umgewöhnen.

0x07 - FAZIT (VORLÄUFIG)

Es ist etwas Aufwand sich Gedanken über ein eigenes Layout zu machen und es ist kein Projekt, das abgeschlossen werden kann. Es ändert sich immer irgendetwas. ABER! Es lohnt sich und macht Spaß sich mit seinem eigenen Tippverhalten auseinander zu setzen. Nun ist KYB3R_KEYS aber doch auf einen sehr spezifischen Anwendungsfall ausgerichtet: Eine Mischung aus CODE/TEXT und EN/DE dazu viel Terminal-Nutzung und VIM/VIM-like zentriert. Es wird bestimmt noch andere Menschen geben, die den gleichen Usecase haben, aber es wird nicht die Mehrheit sein. Das ist mir bewusst.

0x08 - FILES

Natürlich wollt ihr jetzt noch die Files die ich euch schmackhaft gemacht habe. Hier bitte:

[KYB3R_KEYS CHEATSHEET]: LINK
[KYB3R_KEYS keymap.c]: LINK
[KYB3R_KEYS kyb3r_keys.hex]: LINK


Habt Spaß damit!

Ich bekomme doch recht viel Input. Deswegen gibt es jetzt hier auch eine explizites Dankeschön an alle die Input liefern:

THX

LINKS

EDIT

CHANGE LOG