Quelques expérimentations

Expérimenter avec une tétière inversée

Résumé : sur mobile j’ai changé la barre de menu du blog.

Pendant longtemps, quand on ouvrait mon blog sur téléphone on voyait ça :
Navigation blogmobile v1

Ça fait un gros pâté de texte non ? Nom du blog, puis liens, puis titre de l’article. Les liens du menu, notamment, sont plus directs et efficaces qu’un menu-burger, mais ils font très lourds sans vraiment être parlants ou inciter à cliquer. Comment rendre ce menu plus discret sans perdre en utilisabilité ? Une solution : un menu-tiroir masqué par défaut, mais pas un menu-burger pour autant. Pour l’ouvrir, il suffit de scroller vers le haut ou d’appuyer sur la manicule. Essayez de vous-même sur un téléphone, une fenêtre étroite ou regardez cette vidéo :

Pourquoi ce choix ? J’avais envie d’expérimenter autour de l’idée de la page web comme canevas infini (pour reprendre une expression de Scott McCloud). Une page web n’est pas un rectangle avec des frontières claires ni un sens de lecture prédéfini.

Image prise à Frank Chimero

Ça ne veut pas dire qu’on peut faire n’importe quoi : les limites sont celles de la compréhension du lecteur. Ici on reste sage et ce menu inversé est même plus ergonomique qu’un menu-burger. D’abord il est tout à fait découvrable : la manicule est bien mise en évidence, on peut appuyer dessus ou sur toute la largeur de l’écran et le menu est suggéré par une saillie. Ensuite, parce qu’au lieu de devoir repérer et viser un bouton, il suffit d’un simple geste de scroll. Comme le dit Joshua Porter, « le défilement est une continuation, le clic une décision ». Enfin, ce geste n’est pas arbitraire mais cohérent avec la manière dont le menu apparait : scroller vers le haut fait apparaitre progressivement plus de page, c’est le principe même du scroll. Alors que dans l’absolu un bouton-burger pourrait être placé n’importe et le menu pourrait apparaitre n’importe comment.

Bref, je trouve ça pas mal. Me bercé-je d’illusions ? Un avis ? Avez-vous croisé des idées similaires ?

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