Tastaturlayout prüfen und evolutionär entwickeln

strict warning: Only variables should be passed by reference in /www/htdocs/w0062791/arnebab/modules/book/book.module on line 559.

UPDATE: Zur Zeit nutze ich das Cry-Layout:

Ich habe ein kleines Python Programm geschrieben, um das Neo Tastaturlayout zu prüfen und mit evolutionären Codes zu verbessern.

bitbucket.org/ArneBab/evolve-keyboard-layout/

Inzwischen hat es von verschiedenen Leuten Verbesserungen erfahren, daher ist das „Ich“ oben nur noch eingeschränkt richtig. Dank geht an die wundervolle Neo-Community!

Es braucht Python 3.

Seine Lizenz ist wie üblich GPL (frei).

Das Ziel dabei ist, eine Belegung zu finden, die schnelleres und weniger belastendes Tippen ermöglicht und so hoffentlich hilft, Erkrankungen der Handgelenke durch viel Tippen zu vermeiden.

Ergebnisse der Optimierung schreibe ich dabei meist auf der Mailingliste der Neo-Gemeinschaft.

Einige weitere Informationen gibt es auf EvolvedLayouts und Neo3 im Neo-Wiki.

Anschauliche Ergebnisse

Um die Optimierung anschaulich zu machen, gibt der Optimierer Bilder der Buchstabenhäufigkeit und Bigrammübergänge aus (nach einem Design von Wolf).

Hier sind sie für einen Ausschnitt aus der Entwicklung der Tastaturbelegungen erstellt. Hellblaue Übergänge zwischen Buchstaben sind gut, dunkelblaue/lilane sind unschön und gelbe sing grausig.

Qwertz ist die alte, typische und offensichtlich schreckliche Tastaturbelegung (v.a. durch „de“ und „un“), die selbst ihr Erfinder wieder ändern wollte – Remington (der Hersteller der Tastaturen) verweigerte das aber… sowas passiert, wenn man seine revolutionären Erfindungen verkauft…

Dvorak ist die verbreitetste optimierte, aber durch z.B. „ei“ nicht für Deutsch geeignet. Sie wurde noch von Hand optimiert.

Neo 2 ist die aktuelle Belegung der Neo-Gemeinschaft. Ihre Hauptschwäche sind die Fingerwiederholungen (z.B. „la“).

Haeik ist das Testlayout, das ich seit Februar 2011 nutze, um zu testen, ob es Probleme gibt, die erst bei höheren Tippgeschwindigkeiten auftreten. Seit Anfang März 2011 bin ich wieder bei über 300 Zeichen pro Minute und habe ein paar Anpassungen vorgenommen.

Tnrs ist ein aktuelles Ergebnis des Optimierers (aktuell=2011-03-13).

Die Dicke der Übergänge zeigt die Häufigkeit an. Die Richtung wird durch die Transparenz gezeigt: Von durchsichtig zu vollständig sichtbar. Einwärtsbewegungen machen dabei einen Bogen nach oben, auswärts einen nach unten.

Der Grauton der Tasten gibt die Buchstabenhäufigkeit an und der kleine Punkt zeigt, wie oft das Zeichen am Wortanfang steht. Hell ist selten, dunkel ist oft.

Alle werden erstellt via

./bigramm_statistik.py --svg --svg-output neo2.svg -l "xvlcw khgfqß´
uiaeo snrtdy
üöäpz bm,.j"

(die Belegung wird zwischen den Anführungszeichen eingefügt)

Parameter

Zur Zeit (2010-08-05) optimiert es auf

  • Gute Tastenpositionen (auf der Grundlinie ist z.B. besser als links unten).
  • Möglichst wenige Fingerwiederholungen (einen Finger mehrfach hintereinander nutzen).
  • Handwechsel bei Richtungswechsel (horizontal).
  • Wenige Zeilenwechsel auf der gleichen Hand.
  • Handwechsel, wenn eine Hand aus ihrer Grundposition gezogen wird.
  • Gleichmäßige Fingerbelastung (aber nur halbe Last auf dem Kleinen, weil er sonst frühzeitig aussteigen kann).
  • Minimierung bestimmter Fingerübergänge (z.B. Mittel- auf Ringfinger).

Funktionsweise

  1. Annahme: Es gibt eine Idealtastatur. Auf ihr braucht Tippen weder Zeit noch strengt es an. Für jede Abweichung davon werden der Tastatur Kosten berechnet.
  2. Es wird eine zufällige Belegung erstellt oder eine vorgegebene durch zufällige Vertauschungen geändert.
  3. Zwei zufällig gewählte Tasten werden vertauscht (Mutation). Dann werden die Kosten der Tastatur berechnet. Sind sie geringer, wird die Mutation behalten, ansonsten wird sie verworfen. Das wird etwa 4000 mal wiederholt (mit Abweichung: Stichwort „Simulated Annealing“).
  4. Optional werden am Ende nochmal alle möglichen Vertauschungen geprüft und jeweils diejenigen gemacht, die die Kosten am stärksten reduzieren. Das läuft so lange, bis es keine Vertauschungen mehr gibt, die die Kosten reduzieren würden.
  5. Mit den erstellten Tastaturbelegungen werden Texte generiert, mit denen Tipper testen können, wie sich das Tippen mit diesen Belegungen anfühlen würden. Die Erfahrungen aus den Tipptests werden genutzt, um die Parameter zu optimieren (Gewichtung und Suche nach weiteren relevanten Parametern).

Details dazu findest du in der Quelldatei (sollte auch ohne Programmierkenntnisse recht lesbar sein), weitere Informationen zur Optimierung auf EvolvedLayouts und Neo3 im Neo-Wiki.

> *UPDATE: Zur Zeit nutze ich das Cry-Layout:* > > - *[Layout-Bild mit Qualitätsvisualisierung](https://bytebucket.org/ArneBab/evolve-keyboard-layout/raw/8ae830ce6b69bb8b0c67b2d9f2096d7f7bd267dc/empirie/cry.svg) (für Inkscape!
AnhangGröße
dvorak_klein.png37.4 KB
haeik_klein.png38.43 KB
neo2_klein.png38.19 KB
qwertz_klein.png40.05 KB
tnrs_klein.png37.7 KB
฿ Donate with Bitcoin 1F67m2Ekk2YCrsX8FE6SpsrioHiYfLwYou (donated: )

Use Node:

⚙ Babcom is trying to load the comments ⚙

This textbox will disappear when the comments have been loaded.

If the box below shows an error-page, you need to install Freenet with the Sone-Plugin or set the node-path to your freenet node and click the Reload Comments button (or return).

If you see something like Invalid key: java.net.MalformedURLException: There is no @ in that URI! (Sone/search.html), you need to setup Sone and the Web of Trust

If you had Javascript enabled, you would see comments for this page instead of the Sone page of the sites author.

Note: To make a comment which isn’t a reply visible to others here, include a link to this site somewhere in the text of your comment. It will then show up here. To ensure that I get notified of your comment, also include my Sone-ID.

Link to this site and my Sone ID: sone://6~ZDYdvAgMoUfG6M5Kwi7SQqyS-gTcyFeaNN1Pf3FvY

This spam-resistant comment-field is made with babcom.

Kommentare

Darstellungsoptionen

Wählen Sie hier Ihre bevorzugte Anzeigeart für Kommentare und klicken Sie auf „Einstellungen speichern“ um die Änderungen zu übernehmen.

Daumen

Ich frage mich zunehmend, warum in der ganzen Diskussion die Daumen immer außer Acht gelassen werden. Diese sind

  • die stärksten
  • die beweglichsten
  • die unabhängigsten

Finger der Hand.

Ich kann z.B. jeden Daumen relativ beliebig positionieren und trotzdem ungehindert mit den anderen Fingern in der Grundstellung weiterarbeiten.

Außerdem erreichen die Daumen die QWERTZ-Tasten vb / nm besser als jeder andere Finger (N.B.: auch als die Zeigefinger!). Für mich wäre das Anlass, dort einfach mal die Modifier zu plazieren (Shift und Ebene 3).

Mit den (meines Erachtens teils grob ungenauen) Annahmen, die COST_PER_KEY zugrunde liegen, steht und fällt die ganze Angelegenheit. Gibt es irgendwo fundierte Studien, die unabhängig von einer bestehenden Tastatur die Beweglichkeit und Geschwindigkeit der einzelnen Bewegungsabläufe (einzelne Finger, Kombinationen) erforscht haben und dokumentieren?

Hi Ingo,Die Daumen werden

Hi Ingo,

Die Daumen werden nicht außer Acht gelassen. Wer haben Leute in der Gruppe, die Hardware-Design machen, und andere experimentieren mit abmontiertem Leerzeichen, so dass sie auf normalen Tastaturen Daumentasten haben. Solange das sich nicht stabilisiert hat, läuft die Optimierung der Grundebene allerdings auf Normaltastaturen, weil die bei uns die Infrastruktur darstellen.

Und ich beispielsweise kann mit meinen Daumen Tasten über der Leertaste kaum erreichen (dafür aber Alt sehr gut). Bei der Truly Ergonomic will ich dagegen Mods und Funktionstasten auf den Daumen legen: Da habe ich effektiv mindestens 5 mit den Daumen gut erreichbare Tasten.

Die Cost-per-key wirklich unabhängig von bestehenden Layouts empirisch festzustellen geht leider rein konzeptuell kaum, da alle Tipper bereits von ihrer Belegung vorgeprägt sind. Wessen Hand willst du nehmen? Die eines Klavierspielers oder die eines Eisenarbeiters, der den ganzen Tag in groben Schutzhandschuhen steckt?

Die Cost per key ist daher zum Glück nicht das einzige Kriterium. Wir haben Experimente gemacht, was deutlich andere cost-per-key bewirken und passen sie seit 1,5 Jahren immer wieder an, um sie näher an die realen Kosten zu bringen.

Für die Geschwindigkeit nutzen wir übrigens v.a. Tastenübergänge: linker Ringfinger unten zu Mittelfinger oben ist grausig, egal wie gut der Ringfinger oben bewertet wird.

Die Studien, die wir als Grundlage nehmen konnten, sind im Quellcode der config.py dokumentiert.

Liebe Grüße

Dumme Frage: Kann man so was

Dumme Frage: Kann man so was nicht mathematisch/deterministisch berechnen? Eigentlich ist das Problem ja eher eine Frage, die man mit Wörterbuch und einem etwas komplexerem Gleichungssystem lösen können sollte. Klar, evolutionäre Algorithmen sind zur Zeit voll angesagt und haben auch einen gewissen Reiz - aber man muss auch wissen, wo es sich irgendwann nicht mehr lohnt :)

Kosten der deterministischen Rechnung

Hi Unerkannt :)

Erstmal: Ich konnte deinen Kommentar erst jetzt freischalten, weil ich im Diplomstress war und die Benachrichtigung nicht gesehen habe…

Das Problem am Deterministischen rechnen sind die Kosten.

Etwas vereinfacht: Es gibt 32 Buchstaben auf 32 Positionen.

Für den ersten Buchstaben haben wir 32 Möglichkeiten ihn zu plazieren. Der zweite gibt weitere 31, der dritte nochmal 30, …

323130…21 ~ 2,6 * 10³⁵ Möglichkeiten.

Also eine Zahl mit 35 nullen, und das geht weit über die aktuellen Rechenmöglichkeiten. Nehmen wir an, wir hätten eigens dafür geschriebene Hardware, die mit 1Ghz in jedem Rechentakt eine Belegung berechnen kann.

2.6e+35/60/60/24/365/1024/1024/1024 7.770791746379158e+18

Also würde es immernoch 10¹⁸ Jahre dauern, länger als die Dauer des Uniiversums.

Deswegen nutzen wir überhaupt den evolutionären Code :)

Zusatzinfos (für die Neo Liste)

Hi,

Ich habe in den letzten Wochen an meinem evolutionären Optimierungscode gebastelt und bin jetzt so weit, dass ich auf eine große Zahl Bedingungen prüfen kann.

Das Grundprinzip ist, jedem Tastendruck einen Kostenfaktor zuzuweisen, dazu weitere Kosten für Fingerwiederholungen u.ä.

Theoretisch kann ich einen Großteil der Bedingungen abbilden, die einzelne Buchstaben, Bigramme und/oder Trigramme nutzen und dann die Tastatur so lange zufällig variieren, bis die Kosten um einen Text zu schreiben minimal werden (inklusive Beginn mit zufälliger Tastatur). Bisher allerdings nur für Ebene 1 plus Großschreibung mit Shift (heißt auch, dass Sonderzeichen bisher einfach ignoriert werden).

Ich brauche allerdings sinnvolle Kostenfaktoren, sonst ist das ganze Modell sinnlos.

Aktuell sieht das Grundmodell der Tastatur so aus:

NEO_LAYOUT = [

[("^"),("1"),("2"),("3"),("4"),("5"),("6"),("7"),
            ("8"),("9"),("0"),("-"),("`"),()], # Zahlenreihe (0)

[(),("x"),("v"),("l"),("c"),("w"),("k"),("h"),("g"),
            ("f"),("q"),("ß"),("´"),()], # Reihe 1

[("⇩"),("u"),("i"),("a"),("e"),("o"),("s"),("n"),
            ("r"),("t"),("d"),("y"),("⇘"),("\n")], # Reihe 2

[("⇧"),(),("ü"),("ö"),("ä"),("p"),("z"),("b"),
            ("m"),(","),("."),("j"),("⇗")],        # Reihe 3

[(), (), (), (" "), (), (), (), ()] # Reihe 4 mit Leertaste

]

( http://bitbucket.org/ArneBab/evolve-keyboard-layout/src/25da1c40e553/che... )

Dazu gibt es für jede Position der Finger fixe Kosten (pro Tastendruck):

COST_PER_KEY = [ # 0 heißt nicht beachtet

    [0,0,0,0,0,0,0,0,0,0,0,0,0,0], # Zahlenreihe (0)  
    [0,6,3,3,3,4,4,3,3,3,6,7,8,0], # Reihe 1  
    [0,3,2,2,1,3,3,1,2,2,3,6,0,9], # Reihe 2  
    [0,5,5,5,5,5,7,7,5,5,5,5,0],     # Reihe 3  
    [0,0,0,     9     ,0,0,0,0] # Reihe 4 mit Leertaste  

]

( http://bitbucket.org/ArneBab/evolve-keyboard-layout/src/25da1c40e553/che... )

D.h. Die Tasten unter dem Zeigefinger kosten 1 (keine Einheit), die Tasten unter Mittel und Ringfinger kosten 2 und die Tasten unter dem Kleinen Finger kosten 3, usw. - Tasten mit Kosten 0 sollte es nicht geben, allerdings wird jedes Zeichen mit Kosten 0 zur Zeit ignoriert ( genauer: Tasten die geändert werden: http://bitbucket.org/ArneBab/evolve-keyboard-layout/src/783b6489128f/che... ).

Zusätzlich kosten Fingerwiederholungen je 5 (zusätzlich zu den Kosten der Einzeltasten).

(wer sich daran stört, dass die Kosten keine Einheit haben, kann einfach uke nehmen: Unteilbare Kosteneinheit :) ).

Was ich jetzt brauche:

  • Wieviel soll welche Taste kosten? (Grundlage: 0 bedeutet, dass das Zeichen ohne Zeitaufwand und Belastung sofort im Rechner ist => theoretische telepathische Idealtastatur; die Minimalkosten pro Taste sind 1 (aus technischen Gründen). => Ich brauche einen Konsens darüber, wie COST_PER_KEY aussehen soll.

  • Wieviel soll eine Fingerwiederholung kosten (relativ zu den Kosten der Tasten)? „Was ist teurer, eine Fingerwiederholung oder zusätzlich mit dem kleinen Finger nach rechts oben greifen zu müssen?” => Welche Kosten pro Fingerwiederholung?

  • Was gibt es sonst an Kosten? (Beispiele: Zweimal die gleiche Hand verwenden. Bei drei Tasten mit der dritten Taste auf der gleichen Hand zu sein wie bei der ersten, aber weiter innen. … ) => Welche zusätzlichen Kostenfaktoren?

Prinzipiell können zusätzliche Kostenfaktoren so gefunden werden:

  • Was ist die ideale Art, die 2 oder 3 Tasten hintereinander zu drücken? Das kostet nur das, was die Tasten einzeln kosten (keine Zusatzkosten).

  • Welche anderen Arten gibt es, die Tasten zu drücken? Wie viel schlechter sind die als die ideale Art? Im Vergleich dazu, eine einzelne Taste zusätzlich zu drücken? => Kosten für diese Art die Tasten zu drücken.

Beispiel: - Ideal: Zwei Tasten hintereinander sollten auf unterschiedlichen Fingern liegen. - Kosten: Wenn sie auf dem gleichen Finger sind, kostet das 5 zusätzlich; soviel, als müsste ich mit einem Finger zusätzlich in die untere Reihe runter.

Und solche Kosten brauche ich zur Optimierung. Was das Programm nämlich (etwas vereinfacht) macht ist, die Kosten aller Zeichen, Bigramme und Trigramme aus den verschiedenen Faktoren zu addieren und dann zufällig Tasten zu vertauschen (zwei oder mehr) und danach zu schauen, ob die Kosten des neuen Layouts niedriger sind. Wenn ja wird es beibehalten und dann von der Basis aus weiter gemacht. Wenn nein wird die Änderung verworfen.

Also: Was gibt es an Kosten, auf die ein Layout optimiert sein sollte? (Ja, ich möchte dazu eine Diskussion lostreten - dadurch können wir die Anforderungen an eine Tastatur teilweise quantisieren.

Wenn ich das habe, kann ich sie integrieren und dann nach diesen Kosten optimierte Layouts rechnen lassen.

Da der Code evolutionär arbeitet, kommt am Ende kein einzig perfektes Layout heraus, sondern viele unterschiedlich stark optimierte, aus denen dann ein bestes ausgewählt werden kann. Was ich persönlich als Vorteil empfinde, weil alle Aussagekraft sowieso durch die Qualität der Kostenfaktoren bedingt wird. Da ist es ganz gut, dass das Programm gar nicht erst vorspiegelt, ein perfektes Ergebnis zu finden.

Zur Geschwindigkeit: Aktuell kann ich binnen eines Tages etwa 100 zufällige Tastaturlayouts so weit optimieren, dass eine Vertauschung von Tasten keinen weiteren Vorteil bringt, oder 100 mal Neo evolutionär entwickeln (mit mehr Kostenfaktoren vermutlich etwas weniger). Das Programm rechnet dabei auf meinem schon etwas älteren Rechner etwa einen Evolutionsschritt pro Sekunde; normalerweise ist ein Layout nach 100 Schritten recht stabil und nach 1000 tut sich selten noch was.

Liebe Grüße,
Arne

PS: Wenn ihr das Programm selbst ausprobieren wollt:
- http://bitbucket.org/ArneBab/evolve-keyboard-layout/

Direkter Download der aktuellen Version:
- http://bitbucket.org/ArneBab/evolve-keyboard-layout/get/tip.bz2

Oder über Mercurial ( http://mercurial.selenic.com ):
- hg clone https://ArneBab@bitbucket.org/ArneBab/evolve-keyboard-layout/

Da dann ./check_neo.py --help

Beispiel 1: Neo 100 Schritte weit evolutionär entwickeln: ./check_neo.py --evolve 100

Beispiel 2: Neo vs. Qwertz mit beliebigem Text: ./check_neo.py --file beispieltext-prosa.txt

Beispiel 3: Neo vs. Qwertz mit 1gramme.txt und 2gramme.txt ./check_neo.py

Beispiel 4: Zufälliges Layout 100 Schritte weit entwickeln ./check_neo.py --evolve 100 --prerandomize 100000

(damit das läuft braucht ihr außerdem Python 3.x -> http://python.org )

PPS: Ich tippe inzwischen fast nur noch mit Neo weil es sich einfach natürlicher anfühlt, auch wenn mir noch manchmal über mehr als ein Jahrzehnt eintrainierte Reflexe in die Quere kommen :)

PPPS: Wenn das Prog in ein lokales Minimum rutscht und Einzeländerungen nichts mehr bringen, geht es nach 1000 erfolglosen Einzelersetzungen zu Zweifachersetzungen über, nach 10000 dann zu Dreifachersetzungen, …

P4S: Die Ausgabe des Evolutionsdurchgangs kann direkt wieder als neues Layout in der Datei genutzt werden. Mit "-q" werden Zwischenstatusinfos weggelassen (nützlich für Mehrfachausführung in einer Schleife, um nicht von der Ausgabe erschlagen zu werden).