Tastaturlayout prüfen und evolutionär entwickeln

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?

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 :)

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.

• http://bitbucket.org/ArneBab/evolve-keyboard-layout/

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).