Explications de certaines décisions d'interface

Ici je liste quelques réponses à des questions posées par la communauté sur des choix d'interface, d'UX dans Cartes.

Le but est de consolider une sorte de FAQ interface :)

:pencil2: Pour contribuer, n'hésitez pas à créer une autre issue référençant celle-ci. On verra par la suite s'il faut évoluer vers un Wiki ou une documentation consolidée en ligne directement sur cartes.app.

Pourquoi pas une interface avec 2 cases origine destination ?

Je pense que Google Maps a craqué le truc avec son approche inspirée de son succès historique, le moteur de recherche : une seule saisie dans une interface toute blanche autour. Pour GMaps, ils ont mis une seule barre de recherche, dans laquelle on peut renseigner aussi bien le lieu où l'on est (origine) que le lieu où on veut aller (destination), ou encore des recherches de lieux. Voir l'état de leur interface en 2013, après le gros redesign. Ensuite, ils ont complexifié l'interface, avec de multiples boutons qui sont apparus. Ensuite Apple Maps est arrivé et a proposé à nouveau une interface épurée, avec la particularité d'avoir une barre de recherche en bas, là où les doigts des gens sont, sur smartphone.

Sur Cartes, je suis cette tendance générale. Là où Géovélo propose une interface origine destination "à l'ancienne", Komoot également, ici on va rester sur un champs de recherche unique, et si possible intelligent, voir https://github.com/laem/futureco/issues/265.

Géovélo

Komoot

Apple Maps

Google Maps

Le débat a également fait rage suite à la décision de SNCF Connect d'abandonner la saisie "origine". SNCF Connect a donc renversé l'UX de recherche d'un train : dis-moi où tu va d'abord. Et c'est tout à fait logique selon moi : dans 90 % des cas, on part toujours du meme endroit, de chez soi, qui est ensuite renseigné soit par la géoloc (ils le font pas...), soit par ta gare principale mise en favori. Ce que les designers que j'ai entendu critiquer cette décision ont bien omis de mentionner, c'est que SNCF Connect s'est simplement calée sur la décision historique (10 ans avant !) de Google Maps, le leader incontesté des apps de voyage, en plus d'ajouter des fonctionnalités NLP "Rennes Marseille demain 16h direct", qu'on ajoutera de façon plus simple https://github.com/laem/futureco/issues/265.

Le but de Cartes est d'etre à la fois une app de voyage et déplacements locaux, et de l'autre une app de base de carto pour trouver cafés, restos, horaires, explorer différents fonds, etc. Donc ne pas spécialiser l'interface de base pour le voyage ou à l'inverse pour la recherche de points d’intérêts.

En bref, vous l'aurez compris, j'ai un avis assez tranché sur la simplicité nécessaire de l'interface par défaut, avec un seul champ de recherche :) Cela dit, la complexité de l'interface actuelle avec ses multiples boutons peut déjà etre légitimement critiquée !

Pourquoi activer la vue 3D automatiquement ?

Je trouve que la vue 3D, activée par défaut quand on cherche un lieu, est une belle "démo tech", un "effet waou" dont j'estime avoir besoin à ce stade pour montrer une fonctionnalité que Google Maps n'a pas sur le Web, et qu'OSM.org n'a absolument pas. Notons aussi qu'Apple mis à fond sur la 3D, une 3D presque enfantine aux contours arrondis. J'aime bien ce qu'ils font, c'est un plus intéressant.

Deux utilisateurs @leryj @kubic6 ont déjà fait la remarque que c'est inutile voir distrayant. Un autre utilisateur en a parlé récemment, voir l'issue créée pour le résoudre Je sais que le débat fait rage aussi chez OSMand qui l'a activé par défaut en fin 2023.

En solution intermédiaire, il faudrait rendre plus visible l'option de remise à plat, et l'enregistrer quand l'utilisateur l'a utilisée une fois. Ça fait partie des personnalisations de l'interface stockées dans la mémoire du navigateur que je n'ai pas encore commencé. Idem pour la vitesse à vélo, des trucs comme ça :)

Pourquoi les lignes de transport en commun ne suivent pas les routes ou les rails ?

Il a eu lieu à plusieurs endroits, ici j'explique un peu pourquoi github.com/laem/cartes/issues/

En bref :

• les tracés ne sont pas publiés par les autorités et quand ils le sont, souvent complètement foireux. Les recréer est couteux et hasardeux
• ça n'a aucune utilisé informationnelle pour l'utilisateur, sauf exception (bus avec descente flexible)
• les plans de bus bien faits (ceux des métropoles) sont symboliques, pas géographiques, car ils sont arrivés à la même conclusion AMHA

Voir notamment https://github.com/laem/cartes/issues/261

:england: In english.

Well first, most agencies in France don't provide good shapes, or any shapes at all. Using tools like Loom to build shapes using OSM data is a heavy and error-prone process.

I'm not yet convinced that users need shapes, except for routes where asking the driver to stop is possible, but they're quite rare. Transportation maps that work well today are hand-drawn or highly symbolic London-style maps. Shapes need to be heavily transformed e.g. by Freiburg's loom to make them bearable in dense regions. See Google Maps's enormous failure to draw transit maps in Frankfurt 😅

So I'm going the other way around : building custom symbolic "straight" (from stop to stop) shapes for any agency with the same common algorithm using only no-shapes GTFS data. I believe we can get somehting very interesting out of these.