KeyboardEvaluator

De Disposition de clavier bépo
Révision datée du 11 avril 2018 à 12:11 par Marcel (discussion | contributions) (mise à jour lien Subversion → Git)


KeyboardEvaluator est un outil écrit en java par Rémi Emonet contenant différents systèmes d'évaluation pour les dispositions de clavier :

  • un évaluateur basé sur le modèle de Klay (lancer l'interface graphique qui expose une partie des fonctionnalités)
  • un évaluateur basé sur les coûts des ditouches (frappe successives de deux touches)
  • d'autres outils

Il est présent sur Git à l'adresse : https://git.tuxfamily.org/dvorak/keyboard_evaluator.git/

Propositions de règles pour les coûts des di-touches

L'évaluateur basé sur les coûts des ditouches sera décrit ici, pour l'instant il est décrit uniquement sur la liste de diffusion. À faire :

  • décrire le principe ici
  • lister les outils ($1.row(), $1.isI(), ...)
  • illustrer la numérotation des doigts, des colonnes et des lignes

Voici un exemple de jeu de règles utilisé pour se faire une idée de ce que peut donner la méthode. Toute proposition d'affinage, de correction ou de nouveau jeu de règle est la bienvenue.

FADE 0.5 0.1 0

....
// variables de configuration pour la suite des règles
var distanceToHomeRowMalus = 1.0;
var exteriorMalus = 0.5;
var rowChangeMalus = 3.0;
var sameFingerMultiplier = 1.5;

// coût de base
value = 0.5;

///////////////////////////
if (!($1.isI() || $2.isI())) { // pas de pouce en jeu

   // Math.abs => valeur absolue
  
   // malus quand on est hors de la home row (pour la première touche)
   value += distanceToHomeRowMalus * Math.abs($1.row());
   
   // malus si le ditouche est vers l'extérieur (mais pas avec le même doigt)
   if ($2.fingerNumber() > $1.fingerNumber()) value += exteriorMalus;
   
   // malus pour le changement de ligne
   // basé aussi sur la distance entre les doigts (plus les numéros de doigts sont proches plus c'est difficile)
   var divider = 0. + Math.abs($1.fingerNumber() - $2.fingerNumber());
   if ($1.fingerNumber() == $2.fingerNumber()) divider = 1.0;
   value += rowChangeMalus * Math.abs($1.row() - $2.row()) / divider;


///////////////////////////
} else { // cas avec un pouce
   
   // ditouches avec espace (ou altgr)
   if ($1.isI() && $2.isV()) value += 2.5;
   if ($2.isI() && $1.isV()) value += 2.5;
   if ($1.isI() && $2.isIV()) value += 2;
   if ($2.isI() && $1.isIV()) value += 2;
   if ($1.isI() && $2.isIII()) value += 1.3;
   if ($2.isI() && $1.isIII()) value += 1.3;
   if ($1.isI() && $2.isII()) value += 1;
   if ($2.isI() && $1.isII()) value += 1;
 
///////////////////////////
}

// ditouche avec un seul doigt (on multiplie le coût calculé)
if ($1.fingerNumber() == $2.fingerNumber()) value *= sameFingerMultiplier;


// légende/outils (À faire : illustration)
//$1.isLeftHand()
//$1.isRightHand()
//$1.row() // access row as defined before in this file
//$1.column() // access column as defined before in this file
//$1.isKey("1C") //e.g. return key
//$1.fingerNumber() // access integer version for finger's roman number (I->1, II->2, ...)
//$1.isI()   // Finger I (Thumb)
//$1.isII()  // Finger II (index)
//$1.isIII() // Finger III ...
//$1.isIV()  // Finger IV ...
//$1.isV()   // Finger V (little finger)
..

Commentaires

La règle :

// malus pour le changement de ligne
// fondée aussi sur la distance entre les doigts (plus les numéros de doigts sont proches plus c'est difficile)

Doit être nuancée voici des exemples : les digrammes [FE], [FZ], [JI] et [JO], dans les deux sens sont équivalents, il me semble. De même (mais un peu moins faciles) [QZ], [QE], [MO] et [MI]. Un peu moins facile encore : [:K] ou [KO]. Ces digrammes ne peuvent pas être notés de la même façon qu'un [KU], un [;L] ou un [LP].

Les règles (en langage compréhensible par Olivier)

Rien de formalisé pour l’instant. Ce sont des idées à critiquer. Rappel : numérotation des doigts I (pouce), II (index), III (majeur), IV (annulaire), V (auriculaire ou petit doigt).

  • Un digramme à une main _n'est_pas_ une catastrophe : s'il est facile à faire, il peut se faire vite et être plus facilement intégré dans un schéma moteur qu'un digramme à deux main (pensez à UI, ST, PO…) ;


  • Un digramme est d'autant plus facile que le doigt d'arrivé est à un rang éloigné de celui du doigt de départ (à l'exception du digramme V-II en descendant ??) ;


  • Digrammes à deux doigts, d'une main, sur une même ligne :
    • Ce sont les digrammes les plus faciles sauf si le doigt de départ et celui d'arrivé sont hors des colonnes de repos ;
    • un digramme est d'autant plus facile qu'il se fait de l'extérieur vers l'intérieur (minimisées par la règle 2) ;
    • la difficulté augmente si l'un des deux doigt sort des colonnes de repos (minimisées par la règle 2) ;


  • Digrammes à deux doigts, d'une main, en changeant de ligne :
    • « Sauter » une ou deux lignes est toujours plus difficile ;
    • la difficulté augmente si l'un des deux doigt sort des colonnes de repos  ;
    • un digramme montant est d'autant plus facile qu'il se fait d'un doigt court vers un doigt plus long ;
    • un digramme descendant est d'autant plus facile qu'il se fait d'un doigt long vers undoigt plus court ;
    • les 4 règles ci-dessus sont minimisée par la règle numéro 2.


  • Digrammes à un doigt, sur une seule touche : accessibilité de la touche en frappe simple, pas de perte de vitesse — ou alors dans les très grande vitesse, mais pas certain.


  • Digrammes à un doigt, à l'exception des doubles lettres (Cf ci-dessus) :
    • Ce sont les digrammes les plus coûteux ;
    • la difficulté augment avec la diminution d'accessibilité des touches (cherchez le petit doigt) ;
    • Ils sont plus faciles en descendant qu'en montant… à moins que ce ne soit l'inverse !
    • ils sont plus facile vers l'intérieur… à moins que ce soit vers l'extérieur !
    • Un doigt préfèrera toujours un digramme un peu plus difficile que beaucoup de digrammes moins difficiles (c’est une contrainte très difficile à juger, mais qui me paraît assez logique : on entre dans le fameux domaine de ce que je n’arrive pas à appeler autrement que la charge mentale).


  • Trigrammes. On ne conserve que ceux formés de 3 touches consécutives (type AUI).


  • Relation entre deux mains / deux doigts
    • Je ne sais pas comment fonctionne l’algorithme : à partir de quel moment se « permet-il » encore de passer une touche d’une main vers l’autre ?
    • comment déterminer qu’un digramme courant d’une main (deux doigts) est préférable à beaucoup d’autres moins courants : Cf le cas du CH (mon courriel n’est pas sur les archives de la liste, je le met dans une page à part) Inversion X/H
    • À parir de quel moment est-il préférable qu’un doigt face un digramme plutôt que son voisin (décharge du travail des petits doigts qui ont le plus de touche à gérer).

Autres questions

Touches « pré-définies »

Doit-on, dès le départ, fixer certains « couples » de caractères sur les touches. Par exemple :

  • ’ et ;
  • . et :
  • , et ?
  • ^ et !
  • ù et u Dans ce cas là, il faut « simplifier » le corpus pour que « ù » soit assimilé à « u ».
  • ¨ et i
  • fixer la place du « - » qui, sans être un caractère n’en est pas moins très présent en français

Autoriser une (des) lettres à passer sur la rangée supérieur

Accepter — ce qui n’était pas le cas pour la première version de l’algorithme — que des caractères peu courant passent sur la rangée du haut (des chiffres) tel que Gaëtan ou Olivier le testent. C’est particulièrement intéressant pour pouvoir placer le « - » en bas. Je trouve qu’il serait mieux de réserver ça à un caractère assez spécifique du français, tel que le « ç ». Ça n’empêche pas de conserver la règle du symbole majuscule en position Maj de la touche sur laquelle se trouve sa minuscule.