WIP: Deplacement bouttons pour laissez plus de place à IndoorEqual
publié le , mis à jour⚙️ Ceci est une proposition de changement de code.
Rendez-vous sur sa page Coderberg pour l'osculter.
lorsqu'il y a pleins de niveaux (ex: Paris Saint-Lazare) i.e. remontée des 3 bouttons "Favoris", "Itineraires" et "Style" vers le haut
Avant:
Après (plus d'échelle IndoorEqual est visible):
pmiossec
3 points à discuter/améliorer (qui ne font pas particulièrement partis de cette PR):
- decalage de la météo vers la gauche qd IndoorEqual est visible
- IndoorEqual ne peut pas être affiché plus haut car il faut de la place pour les boutons qui s'agrandissent. Je trouve ce compoprtement bizarre (d'autant plus qu'ils acquière une bordure que je trouve amplement suffisant) : quel est l'objectif d'un tel comportement? qu'ils soient bien visible ou plus facilement clickable? Est-ce changeable ou un choix fort?
- IndoorEqual à l'air assez capricieux : j'ai pas trouvé la logique de quand il s'affiche et dès fois j'ai l'impression qu'il s'affiche pas :/ un bug? Vous confirmez?
laem
Ce problème n'est à mon avis pas résoluble comme ça, car dans tes captures il manque des boutons optionnels MapLibre tout en haut. Par exemple sur bureau les + et - s'ajoutent. Ensuite avec le style rand, le bouton maplibre relief apparait.
Le souci est donc côté IndoorEqual : vu que les niveaux peuvent aller très loin comme tu le montres dans ta capture, il faut simplement leur limiter leur hauteur, par exemple à 4 propositions, et demander à l'utilisateur de scroller pour voir le reste. S'il existe des niveaux pas affichés, lui montrer en coupant visuellement les niveaux, ou avec un indicateur lui donnant l'indice qu'il en existe d'autre. Dans une v1, juste parier qu'il saura penser à défiler.
Je pense aussi que les niveaux indoor devraient apparaitre en horizontal pour éviter tout conflit avec les autres boutons. Car sur les petits téléphones, le conflit est inévitable même en optimisant les autres boutons.
Il faudrait donc recoder le widget... ce qui tombe bien car, dans tous les cas, je suis convaincu qu'indorequal ne devrait être chargé qu'à la demande via un bouton "voir l'intérieur" qui apparaitrait si la couche "heatmap" d'indoorequal nous montre qu'il y a possibilité d'afficher l'intérieur. Actuellement, on impose à l'utilisateur un surpoids (logiciel et donnée) dont il n'a souvent pas besoin : on passe très souvent près d'une gare sans y explorer l'intérieur.
En termes d'UX, ce serait bien mieux : on signalerait explicitement à l'utilisateur qu'on peut afficher les niveaux. L'implicite d'aujourd'hui n'est pas bon je trouve.
quel est l'objectif d'un tel comportement? qu'ils soient bien visible ou plus facilement clickable? Est-ce changeable ou un choix fort?
Oui les deux : plus visibles et cliquables. Non pas un choix fort, mais je pense que c'est un sujet orthogonal aux défaut du widget indoorequal.
@laem wrote in https://codeberg.org/cartes/web/pulls/1346#issuecomment-9003309:
Ce problème n'est à mon avis pas résoluble comme ça, car dans tes captures il manque des boutons optionnels MapLibre tout en haut. Par exemple sur bureau les + et - s'ajoutent. Ensuite avec le style rand, le bouton maplibre relief apparait.
Je l'ai géré dans la PR
Je l'ai géré dans la PR
Tu es sûr ? J'ai le pb sur cette branche. Dans tous les cas, indoorequal étant cassé, cette PR peut être mise en retrait.
C'est réglé ça ! On utilise un petit select maintenant.