Elles n'étaient accessibles que dans l'infobulle de la ligne, où l'on ne pense
pas à aller les chercher et d'où l'on ne peut rien copier. Or une note est
précisément ce qu'on va lire quand on fait le point — « pourquoi cette phase
est-elle bloquée ».
Un triangle en tête de ligne les déplie en dessous, sur les phases qui en
portent. C'est celui qui plie un projet sur la frise, au même endroit et avec
la même rotation : ce qui s'apprend d'un côté vaut de l'autre. La gouttière se
lit ainsi d'un coup d'œil comme la liste de ce qui a quelque chose à dire.
Toute la ligne déplie, pas seulement le triangle. Une première version faisait
de l'intitulé lui-même le bouton, avec un chevron à sa suite : la cible était
trop petite pour un geste aussi banal, et rien ne justifiait cette parcimonie
dans une vue où le clic n'a aucun autre effet. Le triangle reste comme
indicateur plutôt que comme cible, le curseur et le fond au survol disent que
la ligne réagit. Les lignes sans notes, elles, ne réagissent pas : promettre un
geste qui ne fait rien est pire que ne rien promettre.
Il n'en reste pas moins un vrai button : la ligne n'est pas focusable, c'est
donc le seul chemin clavier vers les notes.
Les notes restent repliées par défaut pour deux raisons. La densité d'abord :
trois lignes sous chaque intitulé étalent un mois sur deux écrans et ruinent la
lecture en diagonale. Et parce qu'une phase sur trois seulement en porte, les
afficher d'office donnerait des lignes de hauteurs inégales, ce qui casse
l'alignement des colonnes sur lequel repose tout le balayage du regard.
L'état déplié vit dans le DOM et nulle part ailleurs : il ne survit pas à un
changement de filtre, qui reconstruit la liste. Le remonter dans l'état de
l'application achèterait cher une continuité que personne ne réclame — quand la
liste change, on la relit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La frise répond mal à « qu'est-ce qui arrive le mois prochain » : la question
traverse les projets, alors que la frise les range précisément en couloirs
séparés. Il fallait balayer une colonne de dates à travers tous les couloirs
en gardant en tête ce qu'on avait vu plus haut — d'où le tableur ressorti à
côté.
Deux boutons dans la barre d'outils basculent vers une liste qui déroule
toutes les phases, projets mêlés, dans l'ordre du calendrier. Chaque ligne se
lit quand, chez qui, puis quoi : période, projet et ses tags, intitulé,
statut.
Une phase est rattachée au seul mois de son début. La répéter dans chaque mois
traversé aurait donné un tableau de charge — utile, mais c'est une autre vue,
et le doublon coûte la lecture en diagonale qui fait tout l'intérêt de
celle-ci. Sa fin est écrite sur la ligne, ce qui suffit à voir qu'elle
déborde. Les mois sans rien ne sont pas représentés : l'absence se lit déjà
dans le saut d'un titre au suivant.
La liste ne s'édite pas, et ce n'est pas une lacune à combler : déplacer une
phase demande de voir ce qu'elle chevauche et ce qu'elle repousse, or c'est
justement ce voisinage que l'ordre chronologique dissout. Seules les pastilles
de tags restent cliquables — filtrer ne change pas les données.
Le filtre par tags vaut pour les deux vues, sans rien changer à sa mécanique,
si bien qu'on ne se demande jamais si l'une montre plus que l'autre. L'œil
(hidden) écarte un projet de la liste comme il écarte ses barres.
La vue choisie n'est pas enregistrée, contrairement à la largeur de la colonne
des libellés : cette largeur est un réglage d'écran, la vue est un geste de
consultation. L'outil s'ouvre donc sur la frise, celle où l'on modifie. Le
défilement horizontal de la frise, lui, est mémorisé le temps de
l'aller-retour, puisque masquer un élément lui fait perdre son scrollLeft.
Deux extractions au passage, chacune parce que deux vues sœurs en ont besoin
et qu'aucune n'a à importer l'autre : les noms de mois et le formatage des
dates rejoignent model.js, les pastilles de tags un module tags.js.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
