maximus/Simpl-Resultat

Fork 0

Onboarding phase 2 : parcours guidé — bandeau de démarrage sur chaque page et carte d'étape avec mise en évidence #391

New issue

Closed

opened 2026-10-06 23:14:46 +00:00 by maximus · 1 comment

maximus commented

2026-10-06 23:14:46 +00:00

Owner

Constat (test de Max, 2026-10-06, v0.17.0)

Max a testé la phase 1 (#351 à #357, PRs #377 à #383). Il en ressort trois constats :

L'étape 5 ne se coche pas. C'est un bug isolé, traité en #390.
L'embarquement reste insuffisant. La liste de démarrage n'existe que sur le tableau de bord : elle se perd dès qu'on quitte cette page, et l'utilisateur n'a pas le réflexe d'y revenir.
Chaque étape guide trop peu. Une ligne de la liste n'est qu'un lien vers une page (to dans computeChecklist), et rien sur la page d'arrivée ne dit quoi faire.

Décisions de Max (2026-10-06)

D1, persistance : un bandeau en haut de chaque page. Il affiche « Démarrage n/6 · Étape suivante : <libellé> → » et « Masquer ». Il reste visible sur toutes les pages tant que la liste n'est ni complète ni masquée. Options écartées : une entrée dans la barre latérale (la recommandation de départ) et un bouton flottant.
D2, guidage : une carte d'étape et la mise en évidence du contrôle à utiliser. Sur la page de l'étape courante, la carte dit quoi faire en 2-3 phrases et met en évidence le contrôle à utiliser. Elle détecte la réussite en direct et propose « Étape suivante → ». Les pages s'enchaînent ainsi sans retour au tableau de bord. Exemple : à l'étape 5, Transactions s'ouvre filtrée sur « Non classées ». Options écartées : la carte seule, et un tour en surimpression (driver.js).

Contraintes relevées dans le code

Rafraîchissement. Les compteurs ne sont relus qu'au montage du tableau de bord (useOnboardingChecklist, un seul effet). Un bandeau présent partout et une réussite détectée en direct demandent deux choses :
- un état partagé au niveau de l'app, avec un fournisseur dans AppShell (src/components/layout/AppShell.tsx, qui rend aujourd'hui Sidebar et <Outlet />) ;
- une relecture après chaque action concernée : dossier choisi, source configurée, import terminé, catégorie changée, budget saisi.
Course hide() / refresh(). #384 relève qu'un hide() lancé pendant un refresh() en vol peut être annulé par le snapshot de ce chargement (useOnboardingChecklist.ts:92-113). Le constat restait sans effet tant que la liste n'était relue qu'au montage. Avec des relectures fréquentes, il devient réel.
Réaffichage. Paramètres → Utilisateurs réaffiche une liste masquée en appelant le service directement (UsersSettingsPage.tsx:44). Le fournisseur partagé doit l'apprendre, sinon le bandeau reste caché jusqu'au prochain chargement.
Mise en évidence. Viser des ancres explicites (data-onboarding="<clé>") sur les contrôles plutôt que des sélecteurs CSS. Ainsi, la refonte d'un écran fait rougir un test au lieu de casser le parcours en silence.
Un seul emplacement en haut de page. Sur la page de l'étape courante, la carte remplace le bandeau. Ailleurs, le bandeau mène à la page de l'étape.
Budget verrouillé en Gratuite. computeChecklist compte alors 5 cases sans Budget. Le bandeau et la carte suivent la même règle, avec la même attente de budgetReady que la liste compacte, pour ne pas afficher 5/5 puis 5/6.
Filtre « Non classées ». Transactions n'a aujourd'hui aucune entrée par la route : uncategorizedOnly ne se règle que dans la barre de filtres (TransactionFilterBar.tsx). L'ouverture filtrée demande un paramètre de route ou un état de navigation.
Dépendance. La détection de l'étape 5 repose sur #390.
Tests sans jsdom (renderToStaticMarkup et appel direct du composant). Garder en fonctions pures la logique qui décide de l'étape, de la page et du texte.

Questions ouvertes pour la spec

Le texte de chaque carte (6 étapes, FR et EN) et le contrôle mis en évidence à chaque étape.
« Passer » une étape : la marquer comme faite, ou passer à la suivante sans la cocher ?
Sur un profil vide, le bandeau s'ajoute-t-il aux états vides guidés de la phase 1 (Import, Transactions, Budget), ou les remplace-t-il ?
À 6/6 : un message de fin, puis la disparition du bandeau ?
L'ordre avec la phase 2 d'origine (docs/analyse-onboarding-2026-09.md : données de démo D2, guide source unique E). D2 de ce ticket rend caduc le tour guidé C de la phase 3.

Suite

Lancer /plan-run sur ce sujet, avec #390 en tête de pile ou en correctif séparé.

## Constat (test de Max, 2026-10-06, v0.17.0) Max a testé la phase 1 (#351 à #357, PRs #377 à #383). Il en ressort trois constats : 1. L'étape 5 ne se coche pas. C'est un bug isolé, traité en #390. 2. L'embarquement reste insuffisant. La liste de démarrage n'existe que sur le tableau de bord : elle se perd dès qu'on quitte cette page, et l'utilisateur n'a pas le réflexe d'y revenir. 3. Chaque étape guide trop peu. Une ligne de la liste n'est qu'un lien vers une page (`to` dans `computeChecklist`), et rien sur la page d'arrivée ne dit quoi faire. ## Décisions de Max (2026-10-06) - **D1, persistance : un bandeau en haut de chaque page.** Il affiche « Démarrage n/6 · Étape suivante : <libellé> → » et « Masquer ». Il reste visible sur toutes les pages tant que la liste n'est ni complète ni masquée. Options écartées : une entrée dans la barre latérale (la recommandation de départ) et un bouton flottant. - **D2, guidage : une carte d'étape et la mise en évidence du contrôle à utiliser.** Sur la page de l'étape courante, la carte dit quoi faire en 2-3 phrases et met en évidence le contrôle à utiliser. Elle détecte la réussite en direct et propose « Étape suivante → ». Les pages s'enchaînent ainsi sans retour au tableau de bord. Exemple : à l'étape 5, Transactions s'ouvre filtrée sur « Non classées ». Options écartées : la carte seule, et un tour en surimpression (driver.js). ## Contraintes relevées dans le code - **Rafraîchissement.** Les compteurs ne sont relus qu'au montage du tableau de bord (`useOnboardingChecklist`, un seul effet). Un bandeau présent partout et une réussite détectée en direct demandent deux choses : - un état partagé au niveau de l'app, avec un fournisseur dans `AppShell` (`src/components/layout/AppShell.tsx`, qui rend aujourd'hui `Sidebar` et `<Outlet />`) ; - une relecture après chaque action concernée : dossier choisi, source configurée, import terminé, catégorie changée, budget saisi. - **Course `hide()` / `refresh()`.** #384 relève qu'un `hide()` lancé pendant un `refresh()` en vol peut être annulé par le snapshot de ce chargement (`useOnboardingChecklist.ts:92-113`). Le constat restait sans effet tant que la liste n'était relue qu'au montage. Avec des relectures fréquentes, il devient réel. - **Réaffichage.** Paramètres → Utilisateurs réaffiche une liste masquée en appelant le service directement (`UsersSettingsPage.tsx:44`). Le fournisseur partagé doit l'apprendre, sinon le bandeau reste caché jusqu'au prochain chargement. - **Mise en évidence.** Viser des ancres explicites (`data-onboarding="<clé>"`) sur les contrôles plutôt que des sélecteurs CSS. Ainsi, la refonte d'un écran fait rougir un test au lieu de casser le parcours en silence. - **Un seul emplacement en haut de page.** Sur la page de l'étape courante, la carte remplace le bandeau. Ailleurs, le bandeau mène à la page de l'étape. - **Budget verrouillé en Gratuite.** `computeChecklist` compte alors 5 cases sans Budget. Le bandeau et la carte suivent la même règle, avec la même attente de `budgetReady` que la liste compacte, pour ne pas afficher 5/5 puis 5/6. - **Filtre « Non classées ».** Transactions n'a aujourd'hui aucune entrée par la route : `uncategorizedOnly` ne se règle que dans la barre de filtres (`TransactionFilterBar.tsx`). L'ouverture filtrée demande un paramètre de route ou un état de navigation. - **Dépendance.** La détection de l'étape 5 repose sur #390. - **Tests sans jsdom** (`renderToStaticMarkup` et appel direct du composant). Garder en fonctions pures la logique qui décide de l'étape, de la page et du texte. ## Questions ouvertes pour la spec - Le texte de chaque carte (6 étapes, FR et EN) et le contrôle mis en évidence à chaque étape. - « Passer » une étape : la marquer comme faite, ou passer à la suivante sans la cocher ? - Sur un profil vide, le bandeau s'ajoute-t-il aux états vides guidés de la phase 1 (Import, Transactions, Budget), ou les remplace-t-il ? - À 6/6 : un message de fin, puis la disparition du bandeau ? - L'ordre avec la phase 2 d'origine (`docs/analyse-onboarding-2026-09.md` : données de démo D2, guide source unique E). D2 de ce ticket rend caduc le tour guidé C de la phase 3. ## Suite Lancer `/plan-run` sur ce sujet, avec #390 en tête de pile ou en correctif séparé.

maximus added the

status:triage

type:feature

source:human

labels 2026-10-06 23:14:46 +00:00

maximus referenced this issue

2026-10-07 23:49:58 +00:00

Onboarding : état partagé du parcours, relecture en direct et canal d'événements de données (ADR 0022) #396

maximus referenced this issue

2026-10-07 23:49:58 +00:00

Onboarding : bandeau de démarrage sur chaque page #397

maximus referenced this issue

2026-10-07 23:50:07 +00:00

Onboarding : carte d'étape, mise en évidence du contrôle, et carte de la page Import #398

maximus referenced this issue

2026-10-07 23:50:08 +00:00

Onboarding : carte de l'étape « Classer une transaction à la main » (Transactions) #399

maximus referenced this issue

2026-10-07 23:50:08 +00:00

Onboarding : carte de l'étape « Saisir un premier budget » (Budget) #400

maximus referenced this issue

2026-10-07 23:50:08 +00:00

Onboarding : guide, architecture et liste QA du parcours guidé #401

maximus commented

2026-10-07 23:51:03 +00:00

Author

Owner

Découpée lors de la séance /plan-run du 2026-10-06 en six issues empilées, dans la milestone planned-2026-10-06-onboarding-parcours-guide :

#396 : état partagé, relecture en direct, canal d'événements de données (ADR 0022).
#397 : bandeau de démarrage sur chaque page.
#398 : carte d'étape, mise en évidence, carte de la page Import.
#399 : carte Transactions.
#400 : carte Budget.
#401 : guide, architecture, liste QA.

Les décisions D1 (bandeau) et D2 (carte et mise en évidence) de cette issue y sont reprises, avec douze autres prises en séance : « Passer » comptée, message de fin, profils déjà actifs masqués d'office, une seule carte qui suit l'assistant d'import, cible du budget, entre autres.

La revue /review-spec du plan a relevé 2 critiques et 13 améliorations, toutes intégrées dans les corps d'issue (verdict final : approuvé). Les plus importantes :

un verrou de carte : sans lui, la carte disparaissait à sa propre réussite ;
un canal dataEvents qui couvre les insertions d'un import ;
une préférence par étape passée ;
la règle des profils actifs, rendue transactionnelle.

Exécution : /autopilot planned-2026-10-06-onboarding-parcours-guide. Le prérequis, #394, est mergé.

Je ferme cette issue : le travail vit désormais dans les six issues.

Découpée lors de la séance `/plan-run` du 2026-10-06 en six issues empilées, dans la milestone `planned-2026-10-06-onboarding-parcours-guide` : 1. #396 : état partagé, relecture en direct, canal d'événements de données (ADR 0022). 2. #397 : bandeau de démarrage sur chaque page. 3. #398 : carte d'étape, mise en évidence, carte de la page Import. 4. #399 : carte Transactions. 5. #400 : carte Budget. 6. #401 : guide, architecture, liste QA. Les décisions D1 (bandeau) et D2 (carte et mise en évidence) de cette issue y sont reprises, avec douze autres prises en séance : « Passer » comptée, message de fin, profils déjà actifs masqués d'office, une seule carte qui suit l'assistant d'import, cible du budget, entre autres. La revue `/review-spec` du plan a relevé 2 critiques et 13 améliorations, toutes intégrées dans les corps d'issue (verdict final : approuvé). Les plus importantes : - un verrou de carte : sans lui, la carte disparaissait à sa propre réussite ; - un canal `dataEvents` qui couvre les insertions d'un import ; - une préférence par étape passée ; - la règle des profils actifs, rendue transactionnelle. Exécution : `/autopilot planned-2026-10-06-onboarding-parcours-guide`. Le prérequis, #394, est mergé. Je ferme cette issue : le travail vit désormais dans les six issues.

maximus removed the

status:triage

label 2026-10-07 23:51:03 +00:00

maximus closed this issue

2026-10-07 23:51:03 +00:00