Quelques expérimentations

You do the meth : tous les jeux de mots des génériques de Bob’s Burger

Vous voyez dans le générique des Simpsons le texte que Bart écrit depuis 25 saisons ? Dans Bob’s Burgers c’est pareil, il y a deux jeux de mot dans le décor, presque toujours nouveaux. Je me suis amusé à les extraire avec un petit script basé sur ffmpeg (et peu d’huile de coude pour capturer les photogrammes ayant des timecode différents).

Il y a 126 photogrammes pour 134 épisodes (de la S1 au milieu de la S8), ce qui fait 8 épisodes sans générique.

VOIR LES IMAGES EN PLEIN ÉCRAN – – – Lire la suite

Leçons ergonomiques et techniques d’un projet perso

Il y a quelques mois j’ai publié un outil pour calculer une addition en terme de tickets resto (le post de l’époque est ici). Je sais, rien ne m’arrête. Voici une mise à jour, avec notamment des visuels plus travaillés, ainsi qu’un clavier sur mesure et toujours présent à l’écran. Vous pouvez le tester directement dans le cadre ci-après ou l’ouvrir depuis votre ordiphone préféré.

Pourquoi un thème sombre ?

Parce que c’est reposant pour les yeux, surtout 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 limiter à ce que fournit l’OS oblige à utiliser :

  • sur iOS, un clavier pensé pour la saisie de numéros de téléphone, donc pas top
  • Sur Windows Phone et Android, un clavier plus adapté, sans caractères inutiles et avec un séparateur décimal. Malgré cela je n’aime pas trop leur disposition (voir plus bas).

De plus, le clavier natif apparait à l’appui sur un champ. C’est bien dans une page complexe, mais ici il est plus pertinent d’avoir une mise en page sans scroll, avec les champs fixes et le clavier toujours présent.

Enfin, pour utiliser le clavier numérique natif, il faut que l’élément <input> soit de type number. Ca pose certaines contraintes, car l’API a été pensée pour un contrôle de validité dynamique mais après coup : c’est seulement quand l’utilisateur sort du champ que le champ signale l’erreur, par exemple s’il a saisi des lettres au lieu de chiffre. Ca rend difficile le contrôle a priori que je voulais, puisqu’on n’a aucun accès programmatique au texte invalide d’un champ (value devient vide). De plus, une valeur du genre « 10, » est considérée comme invalide, alors qu’il faudrait qu’elle corresponde à un état « en cours de saisie », comme c’est le cas dans les bonnes bibliothèques de gestion des masques de saisie.

Ajoutons qu’en français le séparateur décimal correct est la virgule mais certains navigateurs (Firefox Mobile) ne le localisent pas correctement.

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

Totalement. C’était justement instructif pour moi de voir le nombre de choses qu’il faut réimplémenter comme on peut. Le cheminement a ressemblé à ça :

  1. Je ne voulais pas du clavier, alors qu’il apparait par défaut, un comportement théoriquement non modifiable.
  2. Du coup, on triche en faisant perdre le focus à un champ dès qu’il le gagne.
  3. Du coup, il faut en garder en mémoire quel champ on a sélectionné. Un focus custom, quoi. Il faut également recréer un curseur et le placer au bon endroit.
  4. Ah merde, il faut calculer à la main la position du curseur.
  5. Et bien sûr ça oblige de bidouiller pour obtenir la largeur d’un caractère (l’unité ch aurait été parfaite mais Chrome ne la supporte pas). Donc l’outil ne marche qu’avec des polices à chasse fixe (monospace).

Je vous passe les subtiles différences de comportement entre navigateurs, notamment dans la gestion des évènements focus et click. Bref, le tout marche mais n’est pas ultra robuste ni franchement réactif et le code est sans doute encore moins propre et modulaire que la dernière fois.

Pourquoi cette disposition de clavier ?

Vu qu’on est dans la saisie de monnaie je me suis rapproché de la convention des calculettes, avec le 9 en haut à droite. En plus, la progression des chiffres du bas vers le haut suit le mouvement 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 capacités de calcul mental, mais plutôt un artefact cognitif adapté (en français : dégainer une calculette), c’est quand il s’agit de payer en tickets restaurant. Étant toujours à la recherche d’occasions concrètes d’apprendre à programmer, j’ai donc bricolé un petit outil qui affiche le nombre de tickets à donner et le reste en liquide.

Le bidule est pensé pour une utilisation sur petit écran et une saisie au pouce. J’ai essayé de rendre le formulaire dynamique, pour empêcher la saisie de lettres ou des montants mal formatés. C’est un parti pris ergonomique (blocage versus message d’erreur), mais c’est également instructif de voir à quel point le développement de web app peut être CHIANT si on tombe sur la mauvais combinaison de cas – en l’occurrence, combiner un contrôle à la saisie et un clavier adapté à la saisie numérique sur mobile. Par exemple, l’outil bloque la saisie d’une seconde virgule après « 1,01 », mais après « 1, » ou « 1,00 ».

Avertissement : on parle d’un truc optimisé pour la main mais codé avec les pieds. Donc pas de support de Safari <9 ni d’Internet Explorer (et temporairement de Firefox sur Android, grrr). et un code d’une qualité très relative.

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 ordinateur dans Minecraft ? Si vous ne voyez pas, voici une intro et un exemple en vidéo ici.

J’ai fait un truc du même genre, en beaucoup plus modeste : un outil de maquettage réalisé grâce à un outil de maquettage. Pour être honnête, il s’agit plutôt d’un outil de zoning très primitif. Il permet de placer des rectangles, de les redimensionner, de les effacer, de les renommer et de les mettre à l’avant-plan ou à l’arrière-plan.

Il est testable en ligne à cette adresse et le fichier source est ici (il n’est pas du tout documenté et nécessite Axure 8).

Meta Axure

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

Le 04 décembre, j’ai donné une présentation à Lille dans le cadre du quatrième Welsh Design, qui m’a gentiment donné l’opportunité de parler de mes lubies.

L’angle est très proche de cet article sur l’éternelle querelle du minimalisme, mais le contenu est largement remanié. A l’origine, il y a ma frustration face au débat du flat design, débat nécessaire mais manquant à mon sens cruellement de recul. D’une part, j’ai voulu apporter quelques repères historiques, montrer que l’opposition entre le chargé et le sobre ne date pas d’hier. D’autre part, j’ai tenté de distinguer des concepts différents mais souvent confondus, car ayant tous à voir avec l’historicité du design et de la technique : skeuomorphisme, métaphore, signe, kitsch et ce que j’ai appelé « exaptation », faute d’une meilleure traduction pour repurposing.

Vu les limites de temps et de mes capacités oratoires, le contenu était un peu ambitieux, mais enfin voilà les diapositives vaguement annotées de la présentation. (Je tente un lecteur de PDF embarqué, dites-moi si ça déconne.)

Vu les limites de temps et de mes capacités oratoires, le contenu était un peu ambitieux, mais enfin les diapositives vaguement annotées de la présentation sont disponibles ici.

Le guide relativement exhaustif et raisonnablement ultime des outils de prototypage

J’ai commencé un guide des différents logiciels de prototypage, sous forme de matrice de fonctionnalités. Elle est sur Wikipedia et toutes suggestions et contributions sont les bienvenues.

Pour y voir plus clair, il y a trois sections : généraliste, wireframing (zoning) et animation (souvent des outils dédiés au mobile). Je pensais au départ faire un guide plus large, afin d’inclure des outils pouvant être pratiques pour du prototypage mais dont ce n’est pas le but premier : frameworks CSS, logiciels de design UI (Fireworks, Sketch), IDE web avec des fonctions de templating et de préprocesseur, aides au prototypage papier, etc. Finalement l’article est limité aux logiciels dédiés, ce qui fait tout de même quarante-six items. Cela permet d’éviter le coté fourre-tout et de permettre la comparaison de fonctionnalités à terme à terme. Une liste brute des outils exclus se trouve dans la page de discussion.

Évidemment, ce choix et les catégories retenues sont discutables, tout comme la manière dont j’ai tenté de normaliser les atouts de chaque logiciel en les faisant rentrer dans des cases. Certains services ont certes des concepts propres et sont remplis de petites astuces qui peuvent les démarquer, mais ils sont pourtant globalement assez homogènes. Si vous avez des idées de meilleur découpage ou s’il y a des points obscurs, n’hésitez pas.

Nota bene : les tableaux sont scrollables horizontalement. Ce n’est pas idéal mais c’est la présentation que j’ai trouvé la plus optimale.

À faire :

  • Remplir la section Wireframing.
  • Trouver un découpage pour la section Animations.
  • Je compte faire quelques posts pour mettre en valeur des logiciels méconnus ou des fonctionnalités que j’ai trouvé cool.
  • J’envisage de faire un flowchart qui servirait de vrai guide pour choisir le logiciel le plus adapté à ses besoins. Un arbre de décision 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 proposition d’interaction pour écran tactile.

Rappels sur les modes

En IHM, un mode est un paramètre qui permet de produire différents résultats avec le même input, selon que ce mode soit activé ou non. C’est en fait très simple : par exemple enclencher la touche Caps Lock fait basculer les autres touches en mode « lettre capitale ».

On considère classiquement que c’est une technique utile mais à manier avec précaution. C’est pratique pour augmenter l’éventail des possibilités. Les touches Shift et Caps Lock permettent de doubler le nombre de caractères que l’on peut entrer, alors que les premières machines à écrire avaient un clavier dédoublé ou devaient se contenter d’une seule casse. Le problème est que cela risque d’égarer l’utilisateur. Vous vous souvenez sans doute de l’inénarrable mode « refrappe » : on pouvait l’activer avec la touche Insert et ce n’était signalé que par un minuscule RFP en bas de la fenêtre de Microsoft Word. Il était facile d’entrer dans ce mode sans le vouloir mais nettement plus difficile d’en sortir, quand on ne connaissait pas le truc.

Jeux vidéo et quasi-modes

Si on veut avoir le beurre et l’argent du beurre, Jeff Raskin recommande l’utilisation de ce qu’il appelle des quasi-modes, c’est-à-dire des modes qui demandent une intervention constante de la part de l’utilisateur. Citons le cas du pédalier d’un piano ou la touche Shift d’un clavier : elle n’a pas d’effet si elle n’est pas pressée. Cela demande plus de coordination motrice, mais en contrepartie les deux actions (ici, shift + lettres) sont liées et concomitantes. L’utilisateur a ainsi plus de contrôle sur le système et cela diminue les risques de rester 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 capture d’écran supra). Si on veut par exemple changer d’arme, on maintient une touche (souvent la molette de la souris) pour faire apparaitre un cercle d’items. Diriger la souris dans la direction d’un item permet de le sélectionner. C’est une très bonne idée qui fait intervenir plusieurs concepts :

  • La mémoire musculaire (ou apprentissage moteur). Au début, il faut apprendre à situer et reconnaitre le pictogramme de l’item souhaité, mais avec l’habitude tout ce qu’il y a savoir, c’est un mouvement de la main selon un certain 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 éloignement (je schématise). Ici la distance est infime (il faut à peine bouger la souris) et la taille angulaire est grande (plus ou moins, selon le nombre d’items).
  • Le quasi-mode. Ici, le fait de devoir maintenir la touche est une force plutôt qu’un pis-aller, car ce genre de menu sert d’accès rapide. Il est utilisé souvent et brièvement. Ce ne serait pas adapté pour l’inventaire d’un jeu de rôle, dans lequel on s’attarde plus.

Le design d’interfaces pourrait s’inspirer de cette idée. Cela fait longtemps que les menus radiaux sont utilisés ici et là, mais ce n’est pas toujours convaincant. Dernièrement, on peut citer l’excellente application OneNote sur la Surface de Microsoft, ou bien les widgets s’inspirant de Path – lesquels qui brillent surtout par leur animation.

Je trouve l’idée particulièrement adaptée aux écrans tactiles, donc j’ai en tête un modèle d’interaction de ce genre : presser deux doigts pour faire apparaitre un menu, puis les faire glisser vers l’item désiré. Décoller les doigts de l’écran suffit à sélectionner ce dernier. L’interaction conjugue la facilité des gestes tactiles et l’immédiateté du feedback visuel. Le résultat est fluide puisque les doigts ne quittent pas l’écran. Dans l’animation ci-après (oui c’est juste un Gif pourri), le menu apparait vers le haut pour ne pas être caché par la main. L’exemple est assez limité (partager un article vers divers services), mais au-delà ce genre d’interaction me semble prometteur.

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

Cela pourrait être utilisé soit comme menu contextuel, soit comme menu global (ie qui permettrait d’accéder aux même actions quelque soit l’endroit où j’appuie). Le premier cas serait utile avec beaucoup de cibles potentielles distinctes (par exemple une page pleine de liens), tandis que le second serait plus avantageux avec des actions répétitives (par exemple accéder à une palette d’outils dans une application de dessin). Je suis preneur d’avis et de critiques. L’utilisabilité aussi bien que l’utilité de cette proposition sont certainement critiquables et j’ai pu passer à coté de travaux semblables.