Blomios
917777e18b
Regroupe l'état de travail en cours réalisé dans un même worktree sur plusieurs tickets/sprints (#85, #136, #145, #155-160, #162-164), mélangeant des tickets QA et inProgress. Ne constitue pas une feature terminée : commit de sauvegarde avant triage/split par ticket en branches feature/* dédiées. Exclut les dossiers d'environnement de build locaux et le heap dump parasite (.gitignore mis à jour). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
4.8 KiB
issueRef, version, updatedBy, updatedAt
| issueRef | version | updatedBy | updatedAt | ||||
|---|---|---|---|---|---|---|---|
| #123 | 3 |
|
1785137390347 |
#123 — Cadrage transparent des statistiques issues de la montre (UX, 2026-07-26)
Statut : CADRAGE UNIQUEMENT, ne pas ouvrir l'implémentation. Comme décidé dans le carnet #106 (Main), ce ticket doit se combiner avec le cadrage Architect #124 (permissions capteurs, disponibilité partielle, modèle de persistance) avant tout lot d'implémentation. Ce document fixe le quoi côté UX, pas le quand/comment technique.
Cadre produit
Demande utilisateur explicite : si la donnée n'est pas disponible (pas de montre, capteur non supporté, capteur refusé), aucune notification, aucun message, aucun vide visible — silence total. C'est la contrainte structurante de tout le cadrage.
Métriques MVP proposées (à valider par Architect côté faisabilité capteur Wear OS)
Périmètre volontairement réduit à ce qui a une valeur de lecture immédiate pour un utilisateur de musculation/sport, sans dupliquer un tracker cardio dédié :
- Fréquence cardiaque moyenne de la séance (bpm) — métrique la plus universellement disponible sur Wear OS, et la plus lisible pour l'utilisateur.
- Fréquence cardiaque max de la séance (bpm) — complète la moyenne à peu de coût de lecture supplémentaire.
- (optionnel, second temps, pas bloquant pour le MVP) Calories estimées si le capteur/API le fournit nativement sans calcul maison — GameTime n'est pas une app de fitness tracking, ne pas construire de modèle de calcul propre.
Explicitement hors MVP pour ce cadrage : VO2 max, zones d'intensité cardio, SpO2, ECG, tout ce qui relève d'un tracker santé complet — hors du produit GameTime (app de séances de sport, pas app santé).
Surface de restitution
- Écran de fin de séance / résumé (le même écran qui affiche déjà la durée totale et le récap des séries) : nouveau bloc optionnel "Fréquence cardiaque" avec deux valeurs (moyenne / max), même traitement visuel que les autres stats du résumé (Anton pour les chiffres, cf. gametime-visual-identity).
- Historique de séance (détail d'une séance passée) : même bloc, affiché dans le détail si la donnée existe pour cette séance.
- Pas d'affichage temps réel pendant la séance dans ce périmètre MVP — pas de graphique cardio live sur l'écran d'exécution téléphone, ni sur la montre. Justification : ajouterait une surface supplémentaire à concevoir et à tester pour une valeur d'usage secondaire (l'utilisateur suit son exercice, pas son cardio, pendant l'effort) ; peut être réévalué plus tard si demande explicite.
Silence UX si donnée absente
- Montre non appairée, capteur cardio absent, permission refusée, ou données insuffisantes pour un calcul fiable → le bloc "Fréquence cardiaque" n'apparaît simplement pas dans le résumé ni l'historique. Pas de placeholder grisé "Non disponible", pas d'icône barrée, pas de bouton "Connecter une montre" inséré au milieu du résumé de séance.
- Aucun état d'erreur dédié à concevoir : l'absence de la donnée n'est pas un état de l'écran, c'est une variation normale de contenu (comme une séance sans note, ou sans photo) — cohérent avec gametime-online-layer-philosophy (silence sur l'indisponibilité, jamais de message intrusif).
- Un seul endroit où la fonctionnalité peut être rendue découvrable sans être intrusive : dans les réglages de compte/appareils (là où l'utilisateur configure déjà l'appairage montre, hors scope de ce ticket) — pas sur l'écran de séance lui-même.
Hiérarchie des métriques (si plusieurs disponibles un jour)
Ordre de priorité de lecture déjà anticipé pour ne pas re-arbitrer plus tard si le périmètre s'étend : Fréquence cardiaque (moyenne, max) > Calories > toute métrique additionnelle. La fréquence cardiaque reste toujours la première ligne du bloc, jamais noyée sous des métriques secondaires.
Ce qui reste à trancher par Architect (#124) avant ouverture de l'implémentation
- Faisabilité et API Wear OS Health Services pour lire bpm moyenne/max sur la durée d'une séance.
- Modèle de permission (demande à quel moment du parcours, cohérent avec le principe "jamais de blocage du parcours principal").
- Modèle de persistance (nouveau champ sur l'entité séance, ou table séparée) et comportement en cas de séance déjà terminée sans cette donnée (pas de migration rétroactive à inventer).
Definition of done de ce ticket UX
Ce cadrage est terminé pour la partie UX : personne ne doit revenir vers l'utilisateur pour une question de restitution ou de silence UX. La suite (ouverture des lots d'implémentation) dépend uniquement du retour d'Architect sur #124, pas d'un nouvel arbitrage UX.