Mode itinéraire, la suite #504

laem commented 2024年08月02日 10:54:08 +02:00

À titre d'exemple pour ce que je considère comme cruellement manquant ajd en termes de fonctionnalités (cf fil sur le redesign), il y a beaucoup de choses sur le transport.

Toutes ces fonctionnalités sont déjà disponibles dans le back ou codées ailleurs, mais cachées ou pas intégrées par manque de temps pour les implémenter dans l'interface :

La saisie de l'itinéraire

Améliorer l'écran d'étapes

• #584

Choix "arriver à", choix "partir maintenant" vs date,

On peut envisager 3 choix : partir à | arriver à | aperçu large / voyage / préparation. Ce dernier déclencherait le calcul PreTrip. Trouver le bon terme.

• Dans un premier temps, pas de "arriver à" et on choisit automatiquement le ontrip si date diff < 1h

Je ne comprends pas si l'on peut augmenter la plage de temps d'une requête onTrip. C'est important pour l'utilisateur, mais aussi pour calculer les itinéraire optimaux, une fonctionnalité que j'aime beaucoup. Si on ne peut pas, il faudra la réserver au mode preTrip. À moins que le onTrip soit assez intelligent pour nous donner un bon aperçu des solutions ?

• 🔴 implémenter un auto-mécanisme de recherche secondaire en pretrip si pas de résultat trouvé en ontrip. Peut-être aussi ajouter un bouton "rechercher plus" qui déclenche le même pretrip. Cas d'usage

• implémenter le "partir plus tard" : est-ce possible dans onTrip ? Ou est-ce que c'est à nous de simplement changer la date dans le futur genre 30 minutes plus tard ?

C'est pratique quand même. G et A ne le font pas, mais Breizhgo oui. Le faire près des dates avec un rappel tout en bas ? Reprendre les codes des lecteurs vidéo : flèche rond avance avec à l'intérieur +10 min et debounce pour permettre 3 clics ?

• si départ dans le futur, moins besoin de "partir plus tôt" car forcément preTrip et donc calcul large

Intermodalité au départ et arrivée

Plus le temps de complément intermodal est long, plus la recherche est lente. Donc commencer petit, et laisser l'utilisateur choisir 1h de vélo s'il le désire !

Exemple : cette requête casse en prod, à cause des 2h de trajet en vélo autorisés, il cherche trop de trucs alors que la solution est simple pour 0.2 heures !

Très important aussi : proposer à l'utilisateur des modes non symétriques : s'il a un vélo pliant, il est envisageable de faire vélo + transports + vélo. L'option peut s'appeler "vélo à l'arrivée (pliant, location)". À l'inverse, vélo ou voiture au départ, c'est beaucoup plus probable, il suffit de le garer.

Aussi voir l'option motis voiture + parking relais, si on peut la mettre en avant c'est génial !

• mode de départ et d'arrivée (voiture / vélo / marche / PMR), choix du temps max de vélo / marche etc. Tout fait aussi le jeu du calcul de gare en gare

• on a activé le mode fauteuil roulant (mot clef "marchereduite" dans le code), mais pas d'intérêt de l'activer avant d'avoir implémenté le le dessin précis des trajets d'approche cf https://github.com/laem/cartes/issues/598

Correspondance

• Fonctionnalité trop cool : définir le temps de correspondance minimum entre 2 étapes https://github.com/motis-project/motis/pull/522#issuecomment-2301552131

• Sur la carte, afficher un marker "C1 > 11" à l'endroit de la correspondance

Les résultats

Détailler l'itinéraire

• Affichage des étapes de l'itinéraire TeC, puis également vélo si possible et voiture (possible) #598

La frise de résultat

• améliorer la frise des TeC https://github.com/laem/cartes/issues/503
• Vélo : afficher le % sécurisé
• et le graphique du dénivelé / plus de profils Brouter
• Voiture : choix d'éviter les autoroutes pour les véhicules à faible rendement autoroutier ; coût en € des autoroutes et surtout du trajet entier via futur.eco/cout-voiture ; empreinte CO2 via le modèle nosgestesclimat;
• Meilleure page par défaut (la frise) pour le résumé de tous les transports, avec des messages personnalisés notamment sur les transports genre "oulah, en transport en commun ça va être compliqué / passage par Paris obligatoire ouin / etc https://github.com/laem/cartes/issues/500
• Résoudre les problèmes débiles qui bloquent l'intégration de nouvelles métropoles / aggrégats de réseaux, cf laem/gtfs
• Passer à france.ts légèrement modifié pour le fond de cartes transport, en y ajoutant les gares, cf apple maps
• plein de petits bugs à corriger tel que https://github.com/laem/cartes/issues/497 https://github.com/laem/cartes/issues/498

À titre d'exemple pour ce que je considère comme cruellement manquant ajd en termes de fonctionnalités (cf fil sur le redesign), il y a beaucoup de choses sur le transport. Toutes ces fonctionnalités sont déjà disponibles dans le back ou codées ailleurs, mais cachées ou pas intégrées par manque de temps pour les implémenter dans l'interface : ## La saisie de l'itinéraire ### Améliorer l'écran d'étapes - [x] #584 ### Choix "arriver à", choix "partir maintenant" vs date, On peut envisager 3 choix : partir à | arriver à | aperçu large / voyage / préparation. Ce dernier déclencherait le calcul PreTrip. Trouver le bon terme. - [x] Dans un premier temps, pas de "arriver à" et on choisit automatiquement le ontrip si date diff < 1h Je ne comprends pas si l'on peut augmenter la plage de temps d'une requête onTrip. C'est important pour l'utilisateur, mais aussi pour calculer les itinéraire optimaux, une fonctionnalité que j'aime beaucoup. Si on ne peut pas, il faudra la réserver au mode preTrip. À moins que le onTrip soit assez intelligent pour nous donner un bon aperçu des solutions ? - [ ] 🔴 implémenter un auto-mécanisme de recherche secondaire en pretrip si pas de résultat trouvé en ontrip. Peut-être aussi ajouter un bouton "rechercher plus" qui déclenche le même pretrip. [Cas d'usage](localhost:8080/?style=france&allez=Point+sur+la+carte||-1.7131|48.0211->Point+sur+la+carte||-1.6721|48.1368&mode=commun&choix=5#11.35/48.0772/-1.6982) - [ ] implémenter le "partir plus tard" : est-ce possible dans onTrip ? Ou est-ce que c'est à nous de simplement changer la date dans le futur genre 30 minutes plus tard ? C'est pratique quand même. G et A ne le font pas, mais Breizhgo oui. Le faire près des dates avec un rappel tout en bas ? Reprendre les codes des lecteurs vidéo : flèche rond avance avec à l'intérieur +10 min et debounce pour permettre 3 clics ? - [ ] si départ dans le futur, moins besoin de "partir plus tôt" car forcément preTrip et donc calcul large ### Intermodalité au départ et arrivée Plus le temps de complément intermodal est long, plus la recherche est lente. Donc commencer petit, et laisser l'utilisateur choisir 1h de vélo s'il le désire ! Exemple : [cette requête](http://localhost:8080/?allez=Point+sur+la+carte||-1.6860|48.1124->Point+sur+la+carte||2.3062|48.8510#6.61/48.483/0.31) casse en prod, à cause des 2h de trajet en vélo autorisés, il cherche trop de trucs alors que la solution est simple pour 0.2 heures ! Très important aussi : proposer à l'utilisateur des modes non symétriques : s'il a un vélo pliant, il est envisageable de faire vélo + transports + vélo. L'option peut s'appeler "vélo à l'arrivée (pliant, location)". À l'inverse, vélo ou voiture au départ, c'est beaucoup plus probable, il suffit de le garer. Aussi voir l'option motis voiture + parking relais, si on peut la mettre en avant c'est génial ! - [x] mode de départ et d'arrivée (voiture / vélo / marche / PMR), choix du temps max de vélo / marche etc. Tout fait aussi le jeu du [calcul de gare en gare](https://github.com/laem/cartes/issues/416) - [ ] on a activé le mode fauteuil roulant (mot clef "marchereduite" dans le code), mais pas d'intérêt de l'activer avant d'avoir implémenté le le dessin précis des trajets d'approche cf https://github.com/laem/cartes/issues/598 ### Correspondance - [x] Fonctionnalité trop cool : définir le temps de correspondance minimum entre 2 étapes https://github.com/motis-project/motis/pull/522#issuecomment-2301552131 - [ ] Sur la carte, afficher un marker "C1 > 11" à l'endroit de la correspondance ## Les résultats ### Détailler l'itinéraire - [x] Affichage des étapes de l'itinéraire TeC, puis également vélo si possible et voiture (possible) #598 ### La frise de résultat - [ ] améliorer la frise des TeC https://github.com/laem/cartes/issues/503 - [x] Vélo : afficher le % sécurisé - [ ] et le graphique du dénivelé / plus de profils Brouter - [ ] Voiture : choix d'éviter les autoroutes pour les véhicules à faible rendement autoroutier ; coût en € des autoroutes et surtout du trajet entier via futur.eco/cout-voiture ; empreinte CO2 via le modèle nosgestesclimat; - [ ] Meilleure page par défaut (la frise) pour le résumé de tous les transports, avec des messages personnalisés notamment sur les transports genre "oulah, en transport en commun ça va être compliqué / passage par Paris obligatoire ouin / etc https://github.com/laem/cartes/issues/500 - [ ] Résoudre les problèmes débiles qui bloquent l'intégration de nouvelles métropoles / aggrégats de réseaux, cf laem/gtfs - [x] Passer à france.ts légèrement modifié pour le fond de cartes transport, en y ajoutant les gares, cf apple maps - [ ] plein de petits bugs à corriger tel que https://github.com/laem/cartes/issues/497 https://github.com/laem/cartes/issues/498

kevinvennitti commented 2024年08月05日 17:56:00 +02:00 (Migrated from github.com)

Quelques pistes d'interface pour ton premier point :

• Personnaliser l'heure de départ/arrivée sous forme de phrase (Partir maintenant, Arriver à 17h15, Partir demain à 8h) avec une liste déroulante (Partir/Arriver) et un sélecteur de date/heure
• Une section dépliable pour personnaliser son trajet (vocable à affiner : Mode expert ? Plus d'options ?)
• Une sous-section "Mon trajet" pour les options génériques (PMR, mode de transport du début/fin de trajet, et les futurs paramètres génériques)
• Une sous-section par moyen de transport, activable et désactivable, avec leurs paramètres respectifs (limiter l'usage, restreindre à un certain usage, etc)

Cette structure apporte de la souplesse pour intégrer les prochaines évolutions de Cartes. Vos avis ?

screencapture-2024年08月05日-17 54 18@2x

Quelques pistes d'interface pour ton premier point : - Personnaliser l'heure de départ/arrivée sous forme de phrase (_Partir maintenant, Arriver à 17h15, Partir demain à 8h_) avec une liste déroulante (Partir/Arriver) et un sélecteur de date/heure - Une section dépliable pour personnaliser son trajet (vocable à affiner : _Mode expert_ ? _Plus d'options ?_) - Une sous-section "Mon trajet" pour les options génériques (PMR, mode de transport du début/fin de trajet, et les futurs paramètres génériques) - Une sous-section par moyen de transport, activable et désactivable, avec leurs paramètres respectifs (limiter l'usage, restreindre à un certain usage, etc) Cette structure apporte de la souplesse pour intégrer les prochaines évolutions de Cartes. Vos avis ? 

laem commented 2024年09月28日 12:19:21 +02:00

@kevinvennitti dans mes itérations sur #592 je teste une interface d'options de transport en commun qui a pour but de tenir en une ligne. J'essaie de ne pas adopter un système de modal mais plutôt d'options compacts. Ma réflexion est la suivante : pour l'utilisateur, le cout de la découverte des options n'est pas très important par rapport à la répétition des usages à la longue. Ce sont des boutons qui vont être normalement utilisés des dizaines de fois par mois.

Personnellement, dans mon usage de Cartes, l'un des trucs les plus frustrants c'était le fait de pas pouvoir voir à la fois les résultats et options de transport, et le dessin sur la carte. Dans un idéal, les infos et boutons les plus importants tiendraient sur 50 % du bas de l'écran, quand la carte tiendrait sur les 50 % du haut, sur des téléphones classiques de 6 pouces.

À ce titre, l'information "bus optimal" prend bcp trop de place et pourrait être placé tout en bas.

Cela dit, Motis a plein d'options : une approche modal avec explicitation des options avancées (par ex. les 5 profils marche existants) pourra être complémentaire.

image

@kevinvennitti dans mes itérations sur #592 je teste une interface d'options de transport en commun qui a pour but de tenir en une ligne. J'essaie de ne pas adopter un système de modal mais plutôt d'options compacts. Ma réflexion est la suivante : pour l'utilisateur, le cout de la découverte des options n'est pas très important par rapport à la répétition des usages à la longue. Ce sont des boutons qui vont être normalement utilisés des dizaines de fois par mois. Personnellement, dans mon usage de Cartes, l'un des trucs les plus frustrants c'était le fait de pas pouvoir voir à la fois les résultats et options de transport, et le dessin sur la carte. Dans un idéal, les infos et boutons les plus importants tiendraient sur 50 % du bas de l'écran, quand la carte tiendrait sur les 50 % du haut, sur des téléphones classiques de 6 pouces. À ce titre, l'information "bus optimal" prend bcp trop de place et pourrait être placé tout en bas. Cela dit, Motis a plein d'options : une approche modal avec explicitation des options avancées (par ex. les 5 profils marche existants) pourra être complémentaire. 

kevinvennitti commented 2024年09月29日 21:02:54 +02:00 (Migrated from github.com)

• Intéressante ta mécanique de configuration du trajet : j'entends l'approche orientée "l'utilisateur comprend par l'usage" plutôt que l'approche "interface détaillée pour l'utilisateur", mais se pose alors la question 1) de la compréhension intuitive de chaque paramètre et 2) la réactivité de l'interface (feedback) suite à un changement de valeur de paramètre. En l'état, le 1) est encore expert (switcher les modes de transport et leur durée : les paramètres sont liés mais sont dissociés) et le 2) amène un temps de chargement de l'interface qui ralentit la découvrabilité des paramètres
• Je te suis complètement sur la densité de l'interface : l'objectif du 50%/50% semble très bien. Je te joins une proposition qui va dans ce sens
• L'information "bus optimal" peut, IMO, être une pastille qui labellise un trajet, plutôt qu'un encart dédié. Cela pourrait mener à d'autres labels de type "Trajet le plus rapide", "Trajet avec le moins de correspondance", etc.

itineraire3

- Intéressante ta mécanique de configuration du trajet : j'entends l'approche orientée "l'utilisateur comprend par l'usage" plutôt que l'approche "interface détaillée pour l'utilisateur", mais se pose alors la question 1) de la compréhension intuitive de chaque paramètre et 2) la réactivité de l'interface (feedback) suite à un changement de valeur de paramètre. En l'état, le 1) est encore expert (switcher les modes de transport et leur durée : les paramètres sont liés mais sont dissociés) et le 2) amène un temps de chargement de l'interface qui ralentit la découvrabilité des paramètres - Je te suis complètement sur la densité de l'interface : l'objectif du 50%/50% semble très bien. Je te joins une proposition qui va dans ce sens - L'information "bus optimal" peut, IMO, être une pastille qui labellise un trajet, plutôt qu'un encart dédié. Cela pourrait mener à d'autres labels de type "Trajet le plus rapide", "Trajet avec le moins de correspondance", etc. <img width="390" alt="itineraire3" src="https://github.com/user-attachments/assets/9c08bccf-4cb9-4985-873a-2c0406b11ea5">