Monthly Archives: mai 2016

Leçons ergonomiques et techniques d’un projet perso

Il y a quelques mois j’ai publié un outil pour cal­cu­ler une addi­tion en terme de tickets res­to (le post de l’époque est ici). Je sais, rien ne m’arrête. Voici une mise à jour, avec notam­ment des visuels plus tra­vaillés, ain­si qu’un cla­vier sur mesure et tou­jours pré­sent à l’écran. Vous pou­vez le tes­ter direc­te­ment dans le cadre ci-après ou l’ouvrir depuis votre ordi­phone pré­fé­ré.

Pourquoi un thème sombre ?

Parce que c’est repo­sant pour les yeux, sur­tout quand l’arrière-plan est très pré­sent, comme ici, et que mon télé­phone et son OS (Moto G et Android vanillé) sont déjà sombres.

Pourquoi un clavier sur mesure ?

Se limi­ter à ce que four­nit l’OS oblige à uti­li­ser :

  • sur iOS, un cla­vier pen­sé pour la sai­sie de numé­ros de télé­phone, donc pas top
  • Sur Windows Phone et Android, un cla­vier plus adap­té, sans carac­tères inutiles et avec un sépa­ra­teur déci­mal. Malgré cela je n’aime pas trop leur dis­po­si­tion (voir plus bas).

De plus, le cla­vier natif appa­rait à l’appui sur un champ. C’est bien dans une page com­plexe, mais ici il est plus per­ti­nent d’avoir une mise en page sans scroll, avec les champs fixes et le cla­vier tou­jours pré­sent.

Enfin, pour uti­li­ser le cla­vier numé­rique natif, il faut que l’élément <input> soit de type number. Ca pose cer­taines contraintes, car l’API a été pen­sée pour un contrôle de vali­di­té dyna­mique mais après coup : c’est seule­ment quand l’utilisateur sort du champ que le champ signale l’erreur, par exemple s’il a sai­si des lettres au lieu de chiffre. Ca rend dif­fi­cile le contrôle a prio­ri que je vou­lais, puisqu’on n’a aucun accès pro­gram­ma­tique au texte inva­lide d’un champ (value devient vide). De plus, une valeur du genre « 10, » est consi­dé­rée comme inva­lide, alors qu’il fau­drait qu’elle cor­res­ponde à un état « en cours de sai­sie », comme c’est le cas dans les bonnes biblio­thèques de ges­tion des masques de sai­sie.

Ajoutons qu’en fran­çais le sépa­ra­teur déci­mal cor­rect est la vir­gule mais cer­tains navi­ga­teurs (Firefox Mobile) ne le loca­lisent pas cor­rec­te­ment.

C’est pas une mauvaise pratique de réinventer des comportements natifs ?

Totalement. C’était jus­te­ment ins­truc­tif pour moi de voir le nombre de choses qu’il faut réim­plé­men­ter comme on peut. Le che­mi­ne­ment a res­sem­blé à ça :

  1. Je ne vou­lais pas du cla­vier, alors qu’il appa­rait par défaut, un com­por­te­ment théo­ri­que­ment non modi­fiable.
  2. Du coup, on triche en fai­sant perdre le focus à un champ dès qu’il le gagne.
  3. Du coup, il faut en gar­der en mémoire quel champ on a sélec­tion­né. Un focus cus­tom, quoi. Il faut éga­le­ment recréer un cur­seur et le pla­cer au bon endroit.
  4. Ah merde, il faut cal­cu­ler à la main la posi­tion du cur­seur.
  5. Et bien sûr ça oblige de bidouiller pour obte­nir la lar­geur d’un carac­tère (l’unité ch aurait été par­faite mais Chrome ne la sup­porte pas). Donc l’outil ne marche qu’avec des polices à chasse fixe (mono­space).

Je vous passe les sub­tiles dif­fé­rences de com­por­te­ment entre navi­ga­teurs, notam­ment dans la ges­tion des évè­ne­ments focus et click. Bref, le tout marche mais n’est pas ultra robuste ni fran­che­ment réac­tif et le code est sans doute encore moins propre et modu­laire que la der­nière fois.

Pourquoi cette disposition de clavier ?

Vu qu’on est dans la sai­sie de mon­naie je me suis rap­pro­ché de la conven­tion des cal­cu­lettes, avec le 9 en haut à droite. En plus, la pro­gres­sion des chiffres du bas vers le haut suit le mou­ve­ment de la main ou du doigt propre au mobile.