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.

Un bidule optimisé pour la main mais codé avec les pieds

EDIT : Infos plus récentes ici.

S’il y a bien un moment où je n’ai pas envie d’utiliser mes faibles capa­ci­tés de cal­cul men­tal, mais plu­tôt un arte­fact cog­ni­tif adap­té (en fran­çais : dégai­ner une cal­cu­lette), c’est quand il s’agit de payer en tickets res­tau­rant. Étant tou­jours à la recherche d’occasions concrètes d’apprendre à pro­gram­mer, j’ai donc bri­co­lé un petit outil qui affiche le nombre de tickets à don­ner et le reste en liquide.

Le bidule est pen­sé pour une uti­li­sa­tion sur petit écran et une sai­sie au pouce. J’ai essayé de rendre le for­mu­laire dyna­mique, pour empê­cher la sai­sie de lettres ou des mon­tants mal for­ma­tés. C’est un par­ti pris ergo­no­mique (blo­cage ver­sus mes­sage d’erreur), mais c’est éga­le­ment ins­truc­tif de voir à quel point le déve­lop­pe­ment de web app peut être CHIANT si on tombe sur la mau­vais com­bi­nai­son de cas – en l’occurrence, com­bi­ner un contrôle à la sai­sie et un cla­vier adap­té à la sai­sie numé­rique sur mobile. Par exemple, l’outil bloque la sai­sie d’une seconde vir­gule après « 1,01 », mais après « 1, » ou « 1,00 ».

Avertissement : on parle d’un truc opti­mi­sé pour la main mais codé avec les pieds. Donc pas de sup­port de Safari <9 ni d’Internet Explorer (et tem­po­rai­re­ment de Firefox sur Android, grrr). et un code d’une qua­li­té très rela­tive.

C’est ici.

Screenshot_2016-01-03-00-05-00

Meta Axure : un outil de maquettage créé avec un outil de maquettage

Vous voyez les gens qui recréent un ordi­na­teur dans Minecraft ? Si vous ne voyez pas, voi­ci une intro et un exemple en vidéo ici.

J’ai fait un truc du même genre, en beau­coup plus modeste : un outil de maquet­tage réa­li­sé grâce à un outil de maquet­tage. Pour être hon­nête, il s’agit plu­tôt d’un outil de zoning très pri­mi­tif. Il per­met de pla­cer des rec­tangles, de les redi­men­sion­ner, de les effa­cer, de les renom­mer et de les mettre à l’avant-plan ou à l’arrière-plan.

Il est tes­table en ligne à cette adresse et le fichier source est ici (il n’est pas du tout docu­men­té et néces­site Axure 8).

Meta Axure

Le flat design de la Grèce antique à nos jours

Le 04 décembre, j’ai don­né une pré­sen­ta­tion à Lille dans le cadre du qua­trième Welsh Design, qui m’a gen­ti­ment don­né l’opportunité de par­ler de mes lubies.

L’angle est très proche de cet article sur l’éternelle que­relle du mini­ma­lisme, mais le conte­nu est lar­ge­ment rema­nié. A l’origine, il y a ma frus­tra­tion face au débat du flat desi­gn, débat néces­saire mais man­quant à mon sens cruel­le­ment de recul. D’une part, j’ai vou­lu appor­ter quelques repères his­to­riques, mon­trer que l’opposition entre le char­gé et le sobre ne date pas d’hier. D’autre part, j’ai ten­té de dis­tin­guer des concepts dif­fé­rents mais sou­vent confon­dus, car ayant tous à voir avec l’historicité du desi­gn et de la tech­nique : skeuo­mor­phisme, méta­phore, signe, kitsch et ce que j’ai appe­lé « exap­ta­tion », faute d’une meilleure tra­duc­tion pour repur­po­sing.

Vu les limites de temps et de mes capa­ci­tés ora­toires, le conte­nu était un peu ambi­tieux, mais enfin voi­là les dia­po­si­tives vague­ment anno­tées de la pré­sen­ta­tion. (Je tente un lec­teur de PDF embar­qué, dites-moi si ça déconne.)

Vu les limites de temps et de mes capa­ci­tés ora­toires, le conte­nu était un peu ambi­tieux, mais enfin les dia­po­si­tives vague­ment anno­tées de la pré­sen­ta­tion sont dis­po­nibles ici.

Le guide relativement exhaustif et raisonnablement ultime des outils de prototypage

J’ai com­men­cé un guide des dif­fé­rents logi­ciels de pro­to­ty­page, sous forme de matrice de fonc­tion­na­li­tés. Elle est sur Wikipedia et toutes sug­ges­tions et contri­bu­tions sont les bien­ve­nues.

Pour y voir plus clair, il y a trois sec­tions : géné­ra­liste, wire­fra­ming (zoning) et ani­ma­tion (sou­vent des outils dédiés au mobile). Je pen­sais au départ faire un guide plus large, afin d’inclure des outils pou­vant être pra­tiques pour du pro­to­ty­page mais dont ce n’est pas le but pre­mier : fra­me­works CSS, logi­ciels de desi­gn UI (Fireworks, Sketch), IDE web avec des fonc­tions de tem­pla­ting et de pré­pro­ces­seur, aides au pro­to­ty­page papier, etc. Finalement l’article est limi­té aux logi­ciels dédiés, ce qui fait tout de même quarante-six items. Cela per­met d’éviter le coté fourre-tout et de per­mettre la com­pa­rai­son de fonc­tion­na­li­tés à terme à terme. Une liste brute des outils exclus se trouve dans la page de dis­cus­sion.

Évidemment, ce choix et les caté­go­ries rete­nues sont dis­cu­tables, tout comme la manière dont j’ai ten­té de nor­ma­li­ser les atouts de chaque logi­ciel en les fai­sant ren­trer dans des cases. Certains ser­vices ont certes des concepts propres et sont rem­plis de petites astuces qui peuvent les démar­quer, mais ils sont pour­tant glo­ba­le­ment assez homo­gènes. Si vous avez des idées de meilleur décou­page ou s’il y a des points obs­curs, n’hésitez pas.

Nota bene : les tableaux sont scrol­lables hori­zon­ta­le­ment. Ce n’est pas idéal mais c’est la pré­sen­ta­tion que j’ai trou­vé la plus opti­male.

À faire :

  • Remplir la sec­tion Wireframing.
  • Trouver un décou­page pour la sec­tion Animations.
  • Je compte faire quelques posts pour mettre en valeur des logi­ciels mécon­nus ou des fonc­tion­na­li­tés que j’ai trou­vé cool.
  • J’envisage de faire un flow­chart qui ser­vi­rait de vrai guide pour choi­sir le logi­ciel le plus adap­té à ses besoins. Un arbre de déci­sion moins rude que les tableaux actuels. À voir.

Un menu radial inspiré des jeux de tir

Résumé : Plein de mots arides sur les modes en IHM, puis une modeste pro­po­si­tion d’interaction pour écran tac­tile.

Rappels sur les modes

En IHM, un mode est un para­mètre qui per­met de pro­duire dif­fé­rents résul­tats avec le même input, selon que ce mode soit acti­vé ou non. C’est en fait très simple : par exemple enclen­cher la touche Caps Lock fait bas­cu­ler les autres touches en mode « lettre capi­tale ».

On consi­dère clas­si­que­ment que c’est une tech­nique utile mais à manier avec pré­cau­tion. C’est pra­tique pour aug­men­ter l’éventail des pos­si­bi­li­tés. Les touches Shift et Caps Lock per­mettent de dou­bler le nombre de carac­tères que l’on peut entrer, alors que les pre­mières machines à écrire avaient un cla­vier dédou­blé ou devaient se conten­ter d’une seule casse. Le pro­blème est que cela risque d’égarer l’utilisateur. Vous vous sou­ve­nez sans doute de l’inénarrable mode « refrappe » : on pou­vait l’activer avec la touche Insert et ce n’était signa­lé que par un minus­cule RFP en bas de la fenêtre de Microsoft Word. Il était facile d’entrer dans ce mode sans le vou­loir mais net­te­ment plus dif­fi­cile d’en sor­tir, quand on ne connais­sait pas le truc.

Jeux vidéo et quasi-modes

Si on veut avoir le beurre et l’argent du beurre, Jeff Raskin recom­mande l’utilisation de ce qu’il appelle des quasi-modes, c’est-à-dire des modes qui demandent une inter­ven­tion constante de la part de l’utilisateur. Citons le cas du péda­lier d’un pia­no ou la touche Shift d’un cla­vier : elle n’a pas d’effet si elle n’est pas pres­sée. Cela demande plus de coor­di­na­tion motrice, mais en contre­par­tie les deux actions (ici, shift + lettres) sont liées et conco­mi­tantes. L’utilisateur a ain­si plus de contrôle sur le sys­tème et cela dimi­nue les risques de res­ter dans un mode sans s’en rendre compte.

Dishonored
Dishonored (ZeniMax / Arkane Studios, 2012)

Certains jeux vidéo croisent cette idée avec celle des menus radiaux (cf. la cap­ture d’écran supra). Si on veut par exemple chan­ger d’arme, on main­tient une touche (sou­vent la molette de la sou­ris) pour faire appa­raitre un cercle d’items. Diriger la sou­ris dans la direc­tion d’un item per­met de le sélec­tion­ner. C’est une très bonne idée qui fait inter­ve­nir plu­sieurs concepts :

  • La mémoire mus­cu­laire (ou appren­tis­sage moteur). Au début, il faut apprendre à situer et recon­naitre le pic­to­gramme de l’item sou­hai­té, mais avec l’habitude tout ce qu’il y a savoir, c’est un mou­ve­ment de la main selon un cer­tain angle.
  • La loi de Fitts, selon laquelle le temps mis par l’utilisateur pour atteindre une cible dépend de sa taille et de son éloi­gne­ment (je sché­ma­tise). Ici la dis­tance est infime (il faut à peine bou­ger la sou­ris) et la taille angu­laire est grande (plus ou moins, selon le nombre d’items).
  • Le quasi-mode. Ici, le fait de devoir main­te­nir la touche est une force plu­tôt qu’un pis-aller, car ce genre de menu sert d’accès rapide. Il est uti­li­sé sou­vent et briè­ve­ment. Ce ne serait pas adap­té pour l’inventaire d’un jeu de rôle, dans lequel on s’attarde plus.

Le desi­gn d’interfaces pour­rait s’inspirer de cette idée. Cela fait long­temps que les menus radiaux sont uti­li­sés ici et là, mais ce n’est pas tou­jours convain­cant. Dernièrement, on peut citer l’excellente appli­ca­tion OneNote sur la Surface de Microsoft, ou bien les wid­gets s’inspirant de Path – les­quels qui brillent sur­tout par leur ani­ma­tion.

Je trouve l’idée par­ti­cu­liè­re­ment adap­tée aux écrans tac­tiles, donc j’ai en tête un modèle d’interaction de ce genre : pres­ser deux doigts pour faire appa­raitre un menu, puis les faire glis­ser vers l’item dési­ré. Décoller les doigts de l’écran suf­fit à sélec­tion­ner ce der­nier. L’interaction conjugue la faci­li­té des gestes tac­tiles et l’immédiateté du feed­back visuel. Le résul­tat est fluide puisque les doigts ne quittent pas l’écran. Dans l’animation ci-après (oui c’est juste un Gif pour­ri), le menu appa­rait vers le haut pour ne pas être caché par la main. L’exemple est assez limi­té (par­ta­ger un article vers divers ser­vices), mais au-delà ce genre d’interaction me semble pro­met­teur.

2x\_Press\_Hold
Cliquer sur l’animation pour l’arrêter.

Cela pour­rait être uti­li­sé soit comme menu contex­tuel, soit comme menu glo­bal (ie qui per­met­trait d’accéder aux même actions quelque soit l’endroit où j’appuie). Le pre­mier cas serait utile avec beau­coup de cibles poten­tielles dis­tinctes (par exemple une page pleine de liens), tan­dis que le second serait plus avan­ta­geux avec des actions répé­ti­tives (par exemple accé­der à une palette d’outils dans une appli­ca­tion de des­sin). Je suis pre­neur d’avis et de cri­tiques. L’utilisabilité aus­si bien que l’utilité de cette pro­po­si­tion sont cer­tai­ne­ment cri­ti­quables et j’ai pu pas­ser à coté de tra­vaux sem­blables.