Résumé compact et cadrage exact d'un parcours sélectionné (E-04)

Contexte

Epic : #8
Maquette : E-04 · validée le 2026-09-28 (D-071), règle du résumé compact du 2026-10-14 (D-089)
Ecrans › E-04 · Direction-Artistique › Accessibilité · E-04 · D-084 · D-089

Découverte de CODE pendant #224 / PR #301 (Inbox, 2026-10-06) : sur Android à 150 % de texte, un parcours sélectionné était recadré très au large (Pierrefitte et Charonne au lieu du centre de Paris). CODE a mesuré le 2026-10-09 (mesures et captures) que le cadrage par bounds de main est faux sur les deux systèmes, et qu'avec un cadrage exact, la tooltip du départ et le résumé ne laissent au tracé que 55 pt sur iPhone 17 Pro à 100 %, 103 pt sur Android 420 dpi à 100 % et 32 pt sur Android à 150 %.

Règle retenue par Ilan le 2026-10-14 (D-089) : pendant la sélection, la sheet garde au repos un résumé compact (titre, note, « Voir le parcours »), à toutes les tailles de texte ; le reste du résumé suit sous le bouton et se lit en remontant la sheet. La carte cadre tout le tracé dans la place ainsi libérée, sans limite de zoom (D-084).

Comportement attendu

Au tap sur un parcours, la sheet revient au repos avec le résumé compact : titre, note et bouton « Voir le parcours », à toutes les tailles de texte. La vignette, ambiance · quartier, le créateur, le prix et les tags durée et distance suivent sous le bouton et se lisent en remontant la sheet ; à partir de 130 %, l'étape que la tooltip ne montre plus s'y ajoute.
La carte cadre tout le tracé entre la tooltip du départ et le résumé, avec le cadrage exact (centre et zoom calculés par l'app) : les étapes arrivent là où screenPointOnFit les prévoit, sur Android comme sur iOS. Pas de limite de zoom : un long parcours peut sortir de son quartier.
La tooltip du départ reste entière dans l'écran, sous la barre du haut, et sa flèche ne touche pas le bord de la sheet, à toutes les densités (dont 480 dpi).
En revenant de la fiche par « Voir sur la carte », le premier cadrage suit la même règle : la tooltip du départ reste dans l'écran (cas de la PR #390).

Critères d'acceptation

iPhone 17 Pro et Android 420 dpi, texte à 100 % : « De la Cité à Montparnasse » sélectionné, résumé compact, tout le tracé visible entre la tooltip et la sheet ; captures avant/après dans la PR
Android, 150 % de texte, démarrage à froid puis changement de taille app ouverte : même cadrage, centré sur le parcours ; captures
Étape 5/5 à 480 dpi et 150 % : flèche de la tooltip entièrement visible au-dessus de la sheet
Sheet remontée pendant la sélection : vignette, ambiance · quartier, créateur, prix et tags entiers au-dessus de la barre d'onglets ; le lecteur d'écran lit le résumé comme avant (région « Parcours sélectionné »)
Retour de la fiche par « Voir sur la carte » (iPhone 17 Pro, 100 %) : tooltip du départ entière dans l'écran
iOS XXXL : aucune régression (voir aussi Faire tenir la tooltip du départ sous les chips au plus grand texte iOS (E-04) #329)
Test à 150 % de texte système mentionné dans la PR

Notes techniques

Le correctif de caméra est prêt sur la branche issue/305-route-frame-camera, commit bab02fc : à reprendre tel quel, après rebase sur main.
Le cran repos s'ajuste déjà à son contenu (sheetSnapPoints, peekHeight) : c'est la hauteur du résumé compact qui libère la place. Le contenu sous le pli existe déjà à partir de 130 % (RouteSummaryMore) ; il devient la règle à toutes les tailles.
Estimation de la bande du tracé avec le résumé compact : de l'ordre de 200 pt sur iPhone 17 Pro à 100 % (contre 55) et sur Android à 150 % (contre 32), à mesurer dans la PR.
La PR peut aussi fermer Faire tenir la tooltip du départ sous les chips au plus grand texte iOS (E-04) #329 (tooltip du départ sous les chips en XXXL) et Rendre lisible la ligne budget et durée du résumé à 150 % de texte sur iOS (E-04) #370 (ligne budget et durée lisible à 150 %) si elle en coche les critères : tous deux dépendent de ce ticket.

fix(mobile): keep the tooltip of a selected route under the top bar

🔨 Démarrage — diagnostic avant tout réglage, sur l'émulateur Android (Medium_Phone, 420 dpi) depuis main (8d498e0), en comparant la position prévue des étapes (screenPointOnFit) à celle que la carte donne une fois posée (getPointInView) :

Le cadrage sur bounds passe par cameraForCoordinateBounds (Android) et camera(for:padding:) (iOS) de @rnmapbox/maps 10.3.5, des API dépréciées du SDK Mapbox. Sur Android, la marge demandée s'ajoute à la marge que la caméra a déjà. Mesures sur « De la Cité à Montparnasse », mêmes bounds et marge 413/225 demandées : partie d'une caméra sans marge, le départ arrive à y = 413 comme prévu ; partie d'une marge haute de 50, il arrive à y = 463. Avec 300/300 et une marge préalable de 100 : bande réelle de 399 à 614 au lieu de 318 à 597.
À la sélection, la caméra a la marge de la vue d'accueil, puis celle du premier cadrage au recadrage autour du résumé : les deux marges se cumulent et le tracé ne tient plus dans la bande prévue. À 100 %, départ prévu en (259, 413), réel en (310, 321) : la tooltip du départ sort de l'écran à droite et passe sous la barre du haut. C'est aussi la cause de la découverte à 100 % (Inbox, 2026-10-09).

Plan : cadrer avec le centre et le zoom calculés par l'app (la même projection que screenPointOnFit) et la marge complète, sans bounds. Le placement réel suit alors exactement la prévision, sur les deux systèmes. Ensuite, mesurer la bande du tracé à 150 % : si elle ne suffit pas, je reviens ici avec les mesures, sans inventer de règle. Branche issue/305-route-frame-camera. Je traite ce ticket avant #155 : on ne peut pas vérifier le critère « tooltip entièrement dans l'écran » de #155 tant que ce cadrage est faux.

⛔ Bloqué : question de maquette. Un cadrage lisible n'est pas atteignable dans la bande que la règle actuelle laisse au tracé, à 150 % comme à 100 %. Pas de PR, comme le demande la note technique.

1. Le cadrage sur main est faux, sur les deux systèmes (diagnostic dans le commentaire précédent). Parcours « De la Cité à Montparnasse », positions en pt, prévues par screenPointOnFit puis lues sur la carte posée (getPointInView) :

	Départ prévu	Départ réel	Bande prévue	Bande réelle
Android 420 dpi, 100 %	(259, 413)	(310, 321)	413 → 516	321 → 524
iPhone 17 Pro, 100 %	(229, 422)	(304, 318)	422 → 477	318 → 516

C'est un hasard : la marge du premier cadrage s'ajoute à celle du recadrage, et le tracé paraît plus grand que la règle ne le permet, mais la tooltip du départ sort de l'écran à droite et passe sous la barre du haut. Le correctif (centre et zoom calculés par l'app, sans bounds) est sur la branche issue/305-route-frame-camera, commit bab02fc, testé, sans PR. Une fois appliqué, le réel suit la prévision au point près sur Android comme sur iOS.

2. Avec un cadrage exact, la règle ne laisse presque rien au tracé. Hauteur de la carte, réserve haute (max(moitié haute, barre + 8 + tooltip), plafonnée à la sheet moins 44), couverture de la sheet du résumé + 14 pt de pastille :

Cas	Carte	Barre du haut	Tooltip du départ	Réserve haute	Bas (sheet + 14)	Bande du tracé
Android 420 dpi, 100 %	914	140	243	413 (moitié haute)	398	103
iPhone 17 Pro, 100 %	874	178	236	422 (barre + tooltip)	397	55
Android 420 dpi, 150 % (démarrage à froid)	914	142	257	413 (moitié haute)	469	32

À 150 %, avec la bande de 32 pt, la carte va de Pierrefitte au 16e : c'est exactement le constat du ticket, et il vient de la règle elle-même, pas d'un défaut de code. Même avec une réserve haute réduite à la seule tooltip mesurée (barre + 8 + tooltip = 407), la bande ne passe qu'à 38 pt. La tooltip à 312 pt de #155 la raccourcit d'environ une ligne de titre, ce qui ne suffit pas non plus. À 480 dpi et 150 %, la sheet du résumé monte au tiers haut de l'écran : il ne reste pas la hauteur de la tooltip entre la barre et la sheet (capture).

Question pour DESIGN : où va la place du tracé à la sélection quand le résumé est haut (hauteur de la sheet à la sélection, position de la tooltip du départ, part minimale de carte pour le tracé) ? Je n'ai fixé aucune règle.

Android 100 %, `main`	Android 100 %, cadrage exact	iOS 100 %, `main`	iOS 100 %, cadrage exact

Android 150 %, à froid, `main`	Android 150 %, taille changée app ouverte, `main`	Android 150 %, à froid, cadrage exact	Android 480 dpi, 150 %, `main`

Vérifié au démarrage à froid à 150 % et en changeant la taille app ouverte : même cadrage. Environnement : émulateur Medium_Phone API 34, simulateur iPhone 17 Pro, API locale, base seedée.

Chef de projet (point du 2026-10-13) : needs-design posé, status:ready retiré, retour en Cadrage, comme demandé par Paul dans l'Inbox : le cadrage d'un parcours sélectionné n'est pas lisible avec la règle actuelle (mesures dans ce commentaire). Le correctif de caméra attend sur la branche issue/305-route-frame-camera. Jalon v0.2 → v0.6 avec le reste de la finition de la découverte.

Chef de projet (2026-10-13, suite) : jalon v0.6 retiré, ticket remis au backlog, priorité inchangée. Orientation retenue ce jour avec Ilan et Paul : séparer le périmètre du temps, avec des sprints d'une semaine (champ Sprint du Project, à partir du 19/10). Un ticket de finition découvert en cours de route va au backlog et entre dans un sprint selon sa priorité. Le placer en v0.6 ce matin faisait déborder son epic sur une date sans rapport avec le travail.

📋 MANAGER (2026-10-13) : nouveau cas rattaché à ce cadrage, découvert pendant #37 (PR #390, Inbox) : en revenant de la fiche par « Voir sur la carte », parcours sélectionné (iOS, iPhone 17 Pro, texte à 100 %), la tooltip de départ déborde à droite de l'écran au premier cadrage. Le cadrage est celui de E-04 (RouteMap), déclenché par la sélection du store ; piste : le viewport de la carte est peut-être mesuré pendant que la modale la recouvre. Capture dans la PR #390. À vérifier avec le correctif de ce ticket.

Chef de projet (2026-10-14) : règle tranchée par Ilan, D-089, sur ta préférence. Pendant la sélection, le résumé reste compact au repos (titre, note, « Voir le parcours »), à toutes les tailles de texte ; le reste se lit en remontant la sheet. La carte cadre tout le tracé dans la place libérée, sans limite de zoom : un long parcours peut sortir de son quartier. Ton correctif bab02fc s'applique tel quel.

Ticket réécrit sur cette règle, passé status:ready (Prêts). #329 (tooltip en XXXL) et #370 (ligne budget à 150 %) dépendent maintenant de ce ticket : ta PR peut les fermer si elle en coche les critères. Le retour par « Voir sur la carte » (PR #390) fait partie des critères. Wiki : E-04 et Direction-Artistique › Accessibilité mis à jour ; la maquette « tap parcours » n'est pas refaite, le texte prime.

Chef de projet (point du 19/10/2026) : Status Prêts → En cours, la branche issue/305-route-frame-camera existe (dernière activité le 14/10). Si le travail est abandonné, supprimer la branche ou le dire ici.

Chef de projet (point du 20/10/2026) : priorité P3 → P2. Il bloque #329 (P2) : un bloqueur ne peut pas être moins prioritaire que ce qu'il bloque.

📋 MANAGER, 2026-10-22 : recette sur appareil du build 99a29087 (Paul, Redmi Note 9) : la tooltip du départ d'un parcours sélectionné passe derrière la barre de recherche et les filtres, depuis une vignette comme depuis un badge « 1 ». Ticket : #626. Ce ticket-ci porte déjà « La tooltip du départ reste entière dans l'écran, sous la barre du haut » : si sa PR corrige aussi ce cas, le dire dans la PR, et MANAGER rattache ou ferme #626 en conséquence.

🔨 CODE, 2026-10-22 : PR #629 (ticket #626) reprend le correctif de caméra de ce ticket. C'est le commit bab02fc de issue/305-route-frame-camera, repris par cherry-pick sur main avec son auteur. Les conflits avec D-041 (tooltipWidth, tooltipPlacement) sont résolus. La PR change aussi la règle de routeFramePadding :

la tooltip du départ reste toujours sous la barre du haut, avec 16 pt d'écart ;
le tracé prend toute la bande qui reste au-dessus du résumé, sans limite de zoom.

Ce qu'elle ne reprend pas, et qui reste ici :

le résumé compact de D-089 au repos ;
les critères Android à 150 % et à 480 dpi ;
le retour par « Voir sur la carte » ;
iOS XXXL, en partie seulement : la tooltip est bien sous les chips, mais la bande du tracé est très étroite tant que le résumé n'est pas compact.

Une fois #629 fusionnée, la branche issue/305-route-frame-camera n'apporte plus rien : la PR de ce ticket peut repartir de main. Je n'ai pas supprimé la branche.

Chef de projet (23/10/2026) : glissé du Sprint 1 au Sprint 2, non terminé.

Navigation Menu

Repository navigation

Résumé compact et cadrage exact d'un parcours sélectionné (E-04) #305

Contexte

Comportement attendu

Critères d'acceptation

Notes techniques

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Résumé compact et cadrage exact d'un parcours sélectionné (E-04) #305

Description

Contexte

Comportement attendu

Critères d'acceptation

Notes techniques

Activity

PaulThiberville commented on Oct 9, 2026

PaulThiberville commented on Oct 9, 2026

IlanAMG commented on Oct 13, 2026

IlanAMG commented on Oct 13, 2026

PaulThiberville commented on Oct 13, 2026

IlanAMG commented on Oct 14, 2026

IlanAMG commented on Oct 19, 2026

IlanAMG commented on Oct 20, 2026

PaulThiberville commented on Oct 22, 2026

PaulThiberville commented on Oct 22, 2026

IlanAMG commented on Oct 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions