v2:Idées

Page en cours de construction

Objectifs

Page dédiée : v2:Objectifs.

Placement des mains et utilisation du clavier

C'est une question primordiale, mais qui n'a pas été totalement tranchée dans la version 1.

Rangée de garde

• QSDF et JKLM
• QZEF et JIOM
• QSDF et KLMÙ

Méthode de saisie

Méthodes de saisie

Zones de frappe

v2:Zones de frappe

Accessibilité des touches

Carte d'accessibilité des touches

Accessibilité des digrammes

Carte d'accessibilité des digrammes

Contraintes

Il s'agit de répertorier toutes les contraintes, y compris incompatibles, qu'il faut tenter de satisfaire au mieux. Ces contraintes devront être intégrées à un algorithme afin de les combiner de façon optimale en testant les différentes possibilités. La liste est également utile pour expérimenter « à la main » et ne rien oublier.

Force des contraintes

Contraintes « dures » : Intégrées à l'algorithme dans les prérequis, vérifiées quoi qu'il arrive par construction. Exemple : contraintes liées aux positions des touches sur les types de clavier existants.

Contraintes « douces » : Caractérisées par une fonction de coût quantifiant l'importance de la contrainte. Exemple : contraintes liées aux fréquences des caractères et aux accessibilité des touches.

Types de contraintes

Contraintes liées aux enchaînements de caractères :

• Enchaînements typographiques, par exemple placer la ponctuation haute et les guillemets en shift pour l'enchaînement avec l'espace insécable ;
• Enchaînements de caractères allant ensemble à l'usage.

Contraintes dues à l'appariement logique des caractères.

• Par exemple mettre « ( » et « ) » côte à côte et dans cet ordre. À déterminer : comment les intégrer au mieux. On peut par exemple considérer ces deux caractères en bloc, inséparables, et cumuler accessibilité et fréquences sur les deux touches.
• Autre appariements logiques : « . » et « : », « , » et « ; » que l'on peut placer l'un au dessus de l'autre.

Liste des contraintes

Il s'agit dans cette section de lister les contraintes dans un formalisme d'expression commun, nécessaire si on veut pouvoir les combiner. Les contraintes « dures » sont simplement listées afin de pouvoir être prises en compte dans l'algorithme. Les contraintes « douces » sont exprimées comme suit :

• Fonction de coût : Permet de quantifier la contrainte en lui donnant une valeur, ici entre 0 et 1. Ce faisant, permet aux différentes contraintes d'êtres combinées. La somme de ces valeurs pour toutes les contraintes pondérées par leur poids respectif est appelée fonction objective. C'est cette dernière que l'on souhaite optimiser.
• Paramètres : Ce dont la fonction de coût à besoin pour être exprimée. Par exemple, une accessibilité de touches, ou une fréquence. Les paramètres peuvent avoir dans certains cas une influence importante sur la fonction de coût et par conséquent sur le résultat final.

Auquel il faudrait rajouter un poids : Un nombre exprimé sur une échelle arbitraire, indiquant l'importance relative de cette contrainte par rapport aux autres. Peut être converti en % en divisant par la somme de tous les poids. Cependant il faut faire attention de ne pas appliquer les poids pour faire une fonction de cout unique. Mais plutôt optimiser chaque fonction indépendamment et utiliser les poids pour choisir un emplacement sur le front de Paréto (cf. section « optimisation multicritères » ci-dessous. Les poids peuvent également être déterminés a posteriori en présentant diverses solutions « optimales » (sur le front de Paréto) a des utilisateurs en via un mécanisme de sélection comme celui utilisé dans les duels d’accessibilité.

Contraintes « dures »

• Tenir compte des différents types de clavier ;
• Tenir compte des différents placements des mains ;
• Place des chiffres
• Choix entre touche morte et caractères précomposés, en particulier pour è, à et ù.
• Accessibilité des caractères
• Proposition : les apostrophes droite et typographique devraient être en accès direct
• À compléter.

Contraintes « douces »

Alternance

La répartition des digrammes sur les deux mains.

Paramètres :

• A : ensemble des digrammes sur 2 mains
• D : ensemble de tous les digrammes
• f(d) : fréquence du digramme d

Fonction de coût : C = ( ∑_d∊Af(d) ) / ( ∑_d∊Df(d) )

Note : Où met-on qu’un digramme facile à un doigt peut parfois être préférable à une alternance ?

Charge des doigts

La répartition des frappes sur chacun des doigts.

Facteurs à prendre en compte :

• Le corpus n’est pas représentatif de la charge des auriculaires, surtout le droit qui est utilisé pour Entrée, Backspace, et pour les deux les Shifts et les Contrôles pour les raccourcis claviers, etc… Il faut donc compenser en donnant une charge à atteindre moindre pour les auriculaires dans la fonction de coût, surtout le droit ;
• De même, l’index droit est sollicité pour la souris (ou l’index ou majeur gauche pour une minorité de personnes avec la souris à gauche).
  • Je ne suis pas d’accord pour que nous tenions compte des contraintes engendrées par la souris pour la création d’un clavier. Ce n’est pas le même usage biomécanique, ce n’est pas la même contrainte mécanique (touche de l’ordinateur contre bouton de la souris). Il est impossible d’objectiver un rapport de l’un à l’autre, ni un moyenne d’usage de la souris. Laissons les ergonomes de la souris se charger de cette question.

Paramètres :

• d_ij : le doigt « i » avec i=1…5 pour aller du pouce vers l’auriculaire (notation anatomique) sur la main « j » où j 1 ou 2 pour gauche ou droite respectivement.
• T={t} : l'ensemble de toutes les touches t∊T.
• p:T→D : placement des mains: la correspondance touche / doigt correspondant
• T_ij={t∊T/p(t)=d_ij} : chaque sous-ensemble de toutes les touches accessibles par chaque doigt d_ij.
• f(t): fréquence de frappe pour chaque touche
• A(d_ij): objectif à atteindre pour le doigt d_ij, mesuré en % sur tous les doigts hors pouces : ∑_j=1…2 ∑_i=2…4 A(d_ij) = 100%

Fonction de coût :

• P = ∑_j=1…2 ∑_t∊T1j f(t)
• C = ∑_j=1…2 ∑_i=2…4 ∣A(d_ij) − (∑_t∊Tij f(t))/(1-P)∣

Notes :

• Les pouces ne sont pas pris en compte dans cette fonction car il n'est non seulement pas facile de leur donner une valeur de charge pertinente à atteindre mais en plus les possibilités de réaffectations de touches aux pouces sont limitées. Le pouce droit en particulier pourrait faire l'objet d'un calcul séparé pour la prise en compte des caractères en AltGr.
• On peut choisir pour la fonction de coût autre chose comme la norme 2 (carrés) au lieu de la norme 1 (valeurs absolues). Ce qui donne : C = ∑_j=1…2 ∑_i=2…4 (A(d_ij) − (∑_t∊Tij f(t))/(1-P))². Ce choix n'est pas critique.
• Exemples de valeurs à atteindre pour les charges des doigts (j=1,2; i=5,4,3,2, 2,3,4,5) : 12% 13% 13% 13%   12% 13% 13% 11%. Ceci pour prendre en compte les remarques précédentes sur les auriculaires et l'index droit.

Groupes de caractères

Il s'agit ici de prendre en charge les différentes contraintes engendrée par les différents digrammes allant par paire comme par exemple la ponctuation haute (?,!,:) qui est précédée d'une espace insécable en Français. Ces caractères doivent êtres placé si possibles sur les mêmes niveaux de modificateurs (en accès direct, en Shift sur la même main, en AltGr).

Paramètres :

• A : ensemble de tous les caractères supportés
• P = { {a,b} ⊂ A } : paires (non ordonnées) de caractères allant ensemble
• m(a) : modificateurs utilisés pour pouvoir taper le caractère a ∊ A (en séparant Shifts gauche et droit)

Fonction de coût : C = card( { {a,b} ∊ P / m(a) = m(b) } ) / card(P)

Notes :

• Il est possible de pondérer les paires par leur fréquence d'utilisation. Cependant il faudrait étudier les interférences entre cette pondération et la prise en compte des fréquences dans une autre fonction de coût.
• De même il serait redondant d’introduire ici une pénalité pour les digrammes à un doigt, si une autre fonction de coût le prends en compte. La seule utilité serait de compenser une faible représentativité des paires « qui vont bien ensemble » dans le corpus considéré.
• Il est possible de pondérer les paires par degré de priorité du projet (paire utilisée en Français, en programmation, etc) indépendamment de leur fréquence. Cependant il vaudrait dans ce cas mieux tout simplement créer de fonctions de coûts séparées et les utiliser en optimisation multi-critères (pondération a posteriori) que de pondérer les paires a priori dans une fonction de coût unique.

Accessibilité / fréquence

À compléter

Multi-critères

Cette section se veut introductive de la notion, compréhensible par un lecteur non-initié aux techniques d'optimisation multi-critères, et lisible en bon Français. Si ce n'est pas le cas merci de le signaler sur le canal IRC ou la liste de discussion.

L'idée de l'optimisation multi-critères est de répondre au mieux à différents critères parfois contradictoires. Dans un tel problème, il n'y a souvent pas de solution unique qui serait « la meilleure ». Il y a au contraire de nombreuses solutions correspondant chacune a un compromis particulier sur les contraintes.

Ce genre de configuration est ce que l'on trouve en fait le plus souvent dans la vie réelle, à savoir qu'il n'existe pas de solution parfaite mais plutôt un ensemble de compromis. Exemple :

Chaque carré est une disposition clavier possible. Voir l'explication dans le texte principal.

Commentaire de l'image : Selon que l'on accorde plus d'importance au critère 1 ou au critère 2 on peut choisir l'une des dispositions A ou B. Ici les deux dispositions A et B sont « optimales » : d'autres solutions comme C peuvent être améliorées dans un des deux critères, mais pour A et B on ne peut pas améliorer un critère sans perdre sur un autre. L'ensemble de toutes les solutions « optimales » forme ce qu'on appelle le front de Pareto. On y retrouve tous les meilleurs compromis possibles.

L'optimisation multi-critères est un champs de recherche qui vise a établir le même genre de dessin que ci-dessus, avec potentiellement bien plus de deux critères à optimiser. Il existe différente techniques pour y arriver. Un des buts est alors « d'explorer » le front de Pareto. C'est à dire demander à l'ordinateur de trouver des solutions « optimales » comme ci-dessus. Une technique simple mais qui ne permet d'explorer qu'une partie limitée du front est tout simplement de recommencer plusieurs fois les calculs avec différents poids pour les contraintes. Des techniques plus avancées d'échantillonage statistique (dont les algorithmes génétiques) permettent de répartir plus équitablement les solutions obtenues sur l'ensemble du front.

Pour comprendre ce que cela signifie ici, imaginez que l'algorithme vous donne 5 dispositions candidates, réalisant chacune un compromis entre les différents critères. L'expérimentateur humain (ou de façon collective via IRC, etc) reste au centre de la boucle et peut choisir le solution qui lui plait. Mieux, on peut aussi voir l'influence d'un paramètre ou d'un autre. Si on a fait une erreur dans les paramètres des différentes contraintes on la retrouve parfois de façon évidente ici. On peut alors règler ces paramètres pour qu'ils correspondent aux mieux à ce que l'on attends.

Au final bien sûr on doit obtenir une disposition unique. Cependant cette méthode permet non seulement de trouver des compromis auxquels on aurait pas forcément pensé, mais aussi de les trouver de façon systématique et bien plus efficace qu'une recherche « à la main ».

Enfin, un dernier point est également la qualité des solutions obtenues. Prenons l'exemple du Corpus de texte qui sert à établir des statistiques. Si on réalise un Corpus unique avec des proportions diverses prédéfinies (un peu de Français littéraire, des mails, du code, quelques langues étrangères…) on a de grandes chances d'obtenir une solution comme le point C ci-dessus. Alors que si on sépare les Corpus en différents usages et que l'on calcule les solutions compromis « optimales » pour ces usages, on obtient des solutions comme A et B. L'optimisation multi-critères permet dans ce cas de trouver de meilleures solutions.

Algorithme incrémental

Lorsqu'un changement apparaît, une nouvelle idée, une meilleure carte d'accessibilité des touches, de nouvelles contraintes auxquelles ont aurait pas pensé, l'idée est de les intégrer à l'algorithme et de recalculer une solution. Malheureusement cela peut potentiellement provoquer un layout complètement différent. Autant ce n'est pas un problème dans les phases initiales de développement d'une nouvelle version (mieux vaut alors une version optimale), autant cela peut être un point bloquant dans une branche destinée à être stabilisée (mais si on découvre un point critique, la contrainte peut être assouplie).

Pour ne pas avoir ce problème il faut trouver un algorithme qui préserve en partie le layout actuel lorsque de nouvelles contraintes sont ajoutées.

Une première idée est de se limiter à l'espace de toutes les inversions ou permutations de 3 touches maximum. Le problème est que cela ne tient pas compte de l'importance relative des touches en question.

Une idée plus avancée est :

• Définir une métrique de « distance de disposition »

• Les caractères principaux ont plus grand poids
• Les caractères secondaires plus de latitude de mouvement

• La métrique est sensée mesurer le degré de changement dans un critère correspondant à ce qui serait perçu de façon acceptable pour un degré de changement donné.
• Ajouter une contrainte « douce » à la liste des contraintes en utilisant cette métrique

bépo@home

L'idée est d'utiliser le moteur de calculs distribués BOINC afin de réaliser l'optimisation pour les placements de touches.

Avantages :

• Ça permettrait à chacun de contribuer utilement au projet en faisant tourner un « bépo@home » équivalent du « seti@home ». Non seulement les participants se sentent (et sont) utiles au projet, mais en plus cela permet à chacun de contribuer facilement ;
• une puissance de calcul suffisante pour explorer plus largement l'espace des dispositions possibles, ce qui signifie potentiellement de meilleurs résultats ;
• possibilité de rajouter des contraintes / changer les calculs à effectuer de façon transparente pour l'utilisateur (sans qu'il n'ait rien à faire) et de façon sécurisée via le mécanisme prévu à cet effet du moteur BOINC ;
• ce qui donne la possibilité d’explorer séparément différentes voies en diffusant sur bépo@home les paramètres/binaires correspondants. Par exemple, on peut envisager les positions pour la place des chiffres et recenser les meilleures solutions trouvées dans chaque cas ;
• possibilité de « voire où ça en est rendu » de façon interactive via interface Web. On pourrait en dériver, par exemple, une page mise à jour en temps réel avec la liste des 5 meilleures dispositions actuellement trouvées candidates pour une v2 ;
• possibilité de garder différentes solutions optimales en parallèle sur le front de Pareto. On peut en déduire sur une page web les points forts et faibles (contraintes les mieux et moins bien respectées) pour chacune des solutions candidates trouvées.

Inconvénients :

• Mise en place assez lourde.

Polyvalence multilingue et placement de M,Z,W

Voir sur Utilisateur:Merlin et sur Utilisateur:Kaze/Bépo-intl.