La fiche qu'on peut corriger à la main

Une fiche dictée a toujours un mot de travers, et jusqu'au 12 mai la seule correction possible était de tout redire. Ce jour-là, chaque mot de la fiche est devenu touchable et réécrivable, les étapes d'une recette se cochent, et la fiche se supprime depuis elle-même. Il a fallu redessiner une case à cocher qu'Android n'affichait pas, et rattraper trois fois la dernière phrase que le bouton « Terminé » avalait.

Une fiche qu'on ne pouvait que redicter

La veille, la fiche avait appris à se remplir dans des cases déclarées : un titre, des badges, des sections d'ingrédients, des étapes. Elle s'affichait proprement. Elle avait un défaut que personne ne voyait tant qu'on ne l'utilisait pas pour de vrai : elle était en lecture seule.

Or une fiche dictée n'est jamais tout à fait juste. « Huit cents grammes » devient « huit grammes ». Une étape s'est glissée au mauvais endroit. Le badge de préparation dit trente minutes alors qu'il en faut soixante avec le repos de la pâte. Ce sont des erreurs d'une seconde, et la seule réponse disponible était de reprendre la parole pour tout redire, en espérant que la deuxième dictée ne fasse pas une autre faute ailleurs.

C'est le genre de défaut qui décide de l'usage réel d'un objet. Une fiche qu'on ne peut pas corriger est une fiche qu'on finit par ne plus consulter, parce qu'on n'a plus confiance dans ce qu'elle dit.

Le matin : une recette qu'on cuisine vraiment

La journée a commencé par le cas d'usage le plus concret : cuisiner avec la fiche ouverte.

Les ingrédients avaient déjà leurs cases à cocher. Les étapes, elles, n'étaient qu'une liste numérotée. On les a rendues touchables : un doigt sur une étape, et son numéro passe du bleu au gris, le texte se raye et s'estompe. Les étapes restantes gardent leur numéro bleu, si bien que l'œil trouve tout seul la prochaine chose à faire. Les deux compteurs sont volontairement séparés : ce qu'on a sorti du frigo et ce qu'on a déjà fait ne se mélangent pas.

Un détail a demandé plus de réflexion qu'il n'en a l'air. Une deuxième barre de progression, pour les étapes, n'apparaît qu'au moment où l'on coche la première. Tant qu'on n'a pas commencé à cuisiner, la fiche reste calme, avec une seule barre pour les ingrédients. Une fiche qui affiche deux jauges vides à l'ouverture ressemble à un tableau de bord, et personne ne veut d'un tableau de bord dans sa cuisine.

Deux ajustements ont suivi. La fiche s'est posée sur un fond légèrement crème pendant que ses cartes d'ingrédients restaient d'un blanc pur, pour que les cartes flottent au lieu de se fondre dans la page. Et la mémoire a reçu une consigne stricte pour ses recettes : les ingrédients sont regroupés par famille, la viande, le poisson, les légumes, les féculents, les produits laitiers, les épices, la finition, jamais en une seule liste à plat. Une liste à plat de dix-huit ingrédients se lit mal au supermarché. Sept petites listes se lisent rayon par rayon.

La case qui n'existait pas sur Android

Le premier accroc de la journée était visuel, et il était instructif.

La case cochée devait afficher un petit dégradé, du cyan au bleu, avec une coche blanche dedans. Elle était dessinée avec une bibliothèque de dessin vectoriel, placée dans un cadre qui coupait ce qui dépassait de ses bords arrondis, et posée sur une ombre légère. Sur iPhone, parfait. Sur Android, la case cochée montrait son halo bleu et rien à l'intérieur : ni dégradé, ni coche. Un carré vide avec une ombre.

La cause est une combinaison connue des gens qui font des applications Android, et inconnue de tous les autres. Sur Android, une ombre portée est calculée par le système à partir d'une élévation, et cette élévation ne fait pas bon ménage avec un cadre qui rogne son contenu. Le dessin vectoriel à l'intérieur n'était simplement jamais rendu. Rien ne plantait, rien ne prévenait.

Plutôt que de chercher la combinaison de réglages qui satisfait les deux plateformes, la case a été redessinée d'un bloc dans un moteur de rendu graphique qui peint directement à l'écran : le rectangle arrondi, le dégradé et le trait de la coche sont tracés dans un seul canevas, en un seul passage natif. Le cadre qui rognait a disparu, l'ombre est restée sur la vue extérieure, là où Android l'attend. La coche est une courbe tracée à la main, trois points reliés d'un trait arrondi, plutôt qu'un caractère de police dont l'aspect change selon le téléphone.

La leçon est simple : quand deux couches d'une interface se disputent le même pixel, il vaut mieux qu'une seule le dessine.

Toucher un mot pour le changer

Puis est venu l'éditeur, qui est le cœur de la journée.

Un petit menu en haut à droite de la fiche propose deux choses : modifier, supprimer. « Modifier » ne fait pas apparaître un formulaire. La fiche reste exactement la même, à ceci près que tout ce qui peut se changer se souligne d'un pointillé discret : le titre, la citation d'origine, la note de mémoire, chaque badge, chaque titre de section, chaque nom d'ingrédient et sa quantité, chaque titre d'étape, son texte, sa durée. On touche un mot, il se transforme en champ de saisie avec le curseur dedans. On tape, on sort du champ, c'est enregistré.

Le choix d'un seul champ actif à la fois n'est pas qu'esthétique. Un champ de saisie coûte bien plus cher à afficher qu'un simple texte, surtout sur Android et surtout s'il accepte plusieurs lignes. Une fiche de recette avec quarante champs tous actifs en même temps se met à ramer au défilement, et le clavier surgit dès qu'on l'effleure. Un seul champ à la fois, c'est une fiche qui reste une fiche jusqu'au moment précis où l'on veut y écrire.

Autour de ce geste de base, quelques ajouts : un badge en plus, une croix pour en retirer un, un ingrédient ou une étape en plus dans n'importe quelle section, une section entière en moins, une liste ou une suite d'étapes toute neuve en bas de fiche. Et une pastille « Terminé » en haut à gauche pour ressortir du mode édition.

Chaque modification part immédiatement vers le serveur. La route qui n'acceptait jusque-là qu'un changement d'état d'un souvenir, actif, archivé, mis en sourdine, accepte maintenant aussi son contenu, ses métadonnées et ses thèmes, avec la même règle qu'avant : on ne modifie que ce qui vous appartient, le serveur le vérifie lui-même. La transformation profonde d'un souvenir, celle qui en garde l'histoire dans la mémoire neuronale, passe toujours par la conversation. Cette route est faite pour les retouches, pas pour les révisions.

Supprimer, enfin, demande une confirmation puis efface la fiche pour de bon et referme le panneau. C'est la seule opération vraiment destructive de toute la journée, et elle est la seule à poser une question avant d'agir.

Le titre qui revenait en arrière

Le deuxième accroc était plus sournois, parce qu'il ressemblait à une panne alors que tout fonctionnait.

On touche le titre, on le corrige, on sort du champ : l'ancien titre réapparaît. On ferme la fiche, on la rouvre : le nouveau titre est là. La modification était bien enregistrée, elle refusait juste de s'afficher tout de suite.

L'explication tient à qui possède la donnée à l'écran. La fiche gardait une copie locale de son contenu pour afficher la correction sans attendre le serveur, et se réalignait sur ce que lui donnait son parent à chaque fois que celui-ci changeait. Or le parent se redessine pour mille raisons qui n'ont rien à voir avec le contenu, et à chaque fois, il tendait à la fiche un objet techniquement nouveau, au contenu identique. La fiche prenait ce nouvel objet pour une vraie mise à jour et écrasait sa correction fraîche avec la version d'avant. La correction ne revenait qu'à la réouverture, quand le parent avait enfin rechargé la vraie donnée.

La solution n'est pas un correctif, c'est un déménagement. La copie locale a quitté la fiche pour monter d'un étage, dans le panneau qui l'affiche : c'est lui qui applique la correction à l'écran d'abord, envoie l'enregistrement ensuite, et ne se resynchronise que quand on change réellement de souvenir. La fiche est redevenue ce qu'elle aurait toujours dû être, un afficheur pur de ce qu'on lui donne.

Dans la foulée, une quantité un peu longue, « quatre morceaux, huit cents grammes » à côté d'un nom d'ingrédient un peu long lui aussi, débordait de sa ligne et sortait de la carte. Le nom et la quantité ont été empilés en colonne au lieu d'être alignés côte à côte : la quantité passe sous le nom, et plus rien ne dépasse.

« Terminé » avalait la dernière phrase

Le troisième accroc a résisté trois fois, et il est le plus intéressant de la journée pour qui construit des interfaces.

Le scénario : on modifie une durée d'étape, on tape « quarante minutes », et sans sortir du champ, on touche directement « Terminé ». La fiche revient en mode lecture. La durée affiche l'ancienne valeur. Rien n'est parti vers le serveur.

Ce qui se passait : le champ de saisie enregistre sa valeur au moment où il perd le focus. Mais « Terminé » démonte le mode édition d'un coup, et le champ est retiré de l'écran avant d'avoir perdu le focus. Les caractères tapés vivaient dans un brouillon, et le brouillon disparaissait avec le champ.

Première réponse : le champ surveille désormais le signal d'édition de son parent. S'il passe à « lecture » alors que le champ a encore le focus, celui-ci enregistre son brouillon avant d'être retiré. Deuxième réponse, en ceinture et bretelles : le bouton « Terminé » commence par rabaisser le clavier, ce qui fait naturellement perdre le focus au champ actif, et ne bascule le mode qu'ensuite.

Ça a suffi pour le titre, les badges, les ingrédients. Pas pour les étapes.

Les étapes avaient une particularité : en mode lecture, chaque ligne d'étape est un élément touchable, pour pouvoir la cocher. En mode édition, c'est un simple conteneur. Deux natures différentes. Quand on bascule de l'une à l'autre, le système d'affichage ne met pas à jour la ligne, il la détruit et en fabrique une nouvelle. Le champ de saisie à l'intérieur est détruit avec elle, avant même que sa surveillance du signal d'édition ait eu le temps de réagir. La première réponse était juste, elle arrivait trop tard.

La troisième réponse s'exécute au moment même de la destruction du champ : si le champ avait le focus et que son brouillon diffère de sa valeur d'origine, il enregistre le brouillon dans son dernier souffle. Un point technique compte ici : à cet instant, l'état capturé au moment du dernier affichage n'est plus fiable, il faut lire les valeurs dans des références tenues à jour en continu. Le même mécanisme couvre au passage la suppression d'une section pendant qu'on y écrit, et tout autre cas où l'arbre d'affichage change de forme autour d'un champ actif.

Deux miettes pour finir. Un badge de préparation qui disait « trente minutes, plus repos » était bloqué à vingt-huit caractères et refusait la frappe : la limite est passée à soixante. Et le serveur écrit désormais une ligne dans son journal à chaque retouche reçue, et une autre si la base la refuse. La prochaine fois qu'une modification « n'a pas l'air d'être enregistrée », on saura en une lecture si la requête n'est jamais partie ou si elle a été rejetée à l'arrivée. Ce sont deux pannes différentes, et jusque-là elles avaient le même visage.

Ce que la journée aura changé

Ces chantiers ont l'air de bricolage d'interface. Ils tiennent ensemble par une idée.

Une fiche que la mémoire remplit à votre place n'a de valeur que si vous pouvez la reprendre en main. Dicter va vite, et c'est précisément pour ça qu'on y laisse des fautes. Le jour où corriger une faute coûte moins cher que de la laisser, la fiche devient un objet auquel on se fie. Le jour où une liste se coche étape par étape avec les mains pleines de farine, elle a quitté le téléphone pour entrer dans la cuisine.

Le reste, la case invisible, le titre qui reculait, la phrase avalée, ce sont les frais de la promesse. Chacun de ces trois défauts avait le même symptôme, « ma modification n'est pas prise », et trois causes sans aucun rapport. C'est ce qui a rendu la journée longue : chaque fois qu'on croyait le sujet clos, le même symptôme revenait par une autre porte. On a appris à ne plus se fier au symptôme, et à chercher la cause à chaque fois comme si c'était la première.