[Cahier des charges][UX] Carte plus grande

#1

Actuellement:

Screenshot_20220208_021627
Screenshot_20220208_021627835×641 151 KB

Screenshot_20220208_021716
Screenshot_20220208_021716826×724 476 KB

  • Par défaut en layout « bureau » (>768 pixels de large, image#1) la carte est trop petite pour une vue confortable, que ce soit pour les topos ou sorties, en particulier avec POI ou gpx. Dans mes tests, en layout « mobile » <768 pixels, image#2, la carte est en pleine largeur (donc jusqu’à 705 pixels), mais en « bureau » elle ne fait jamais plus que 365 pixels même sur écran full HD.
  • Et le mode plein écran n’est pas appropprié quand on veut lire le descriptif en parallèle, ou changer d’onglet (ce qui enlève le plein-écran au moins sur Chrome)

Quelques propositions:
1a. Permettre de redimensionner la carte avec la souris. Elargir impacte tout le bandeau gauche (carte + métadonées). Eventuellement, mémoriser la valeur dans le local storage du navigateur.
1b. Redimensionnement en largeur uniquement, avec ratio L:h fixe (~1.15:1 actuellement).
2. Afficher un bouton toggle « ←→ » à côté bouton plein-écran, permettant de mettre la carte en pleine largeur au dessus du texte (aka forcer le mode « mobile ».
3. Donner au bandeau de gauche une taille par défaut proportionnelle à la largeur de la fenêtre, par exemple de 30%, avec toujours ratio 1.15. Cela aiderait uniquement sur grand-écran.
4. Afficher une 2e carte « plein écran » (à la taille de la fenêtre) tout en bas, comme sur data-avalanche. Pas forcément top pour lire le topo en même temps.

D’un point de vue technique, je peux essayer de contribuer mais je ne suis pas expert web ni familier avec la lib css utilisée. La solution (2) est peut-être faisable en changeant class de column à block?

#2

En premier, il faudrait surtout supprimer des marges et en réduire d’autres.
Les marges sont énormes et bouffent tout l’espace.
Sur ton exemple, si la carte prend toute la largeur de sa boîte + pas de marge à gauche de la boîte + réduction de la marge a droite de la boite, la largeur de la carte est augmentée de 50% !
Idem pour la hauteur.

#3

Bon, j’ai essayé de trouver une solution à ce problème, de plus en plus épineux maintenant que le composant carte est devenu tellement bien :wink: … en implémentant un prototype, en gros une variante de ma solution 2 ci dessus.

J’ai rajouté un bouton « Épingler la carte en haut de l’écran » qui permet de consacrer la moitié haute de l’écran à la carte, tout en pouvant faire défiler le site sur la moitié basse. Ca permet de pouvoir lire le topo avec toujours une grande carte en vue.

J’ai testé sur quelques pages (recherche sorties, une sortie, édition), en mode bureau et mobile, et ça marche plutot bien meme si cela n’a pas forcément de sens sur toutes les cartes du site donc il faudra ajuster.

Exemple sur une sortie: page par défaut avec le nouveau bouton (sous le bouton plein-écran), et après clic:

image
image1496×1560 562 KB

Screenshot_20231030_110232-1
Screenshot_20231030_110232-1748×780 262 KB

Exemple sur mobile:

image
image646×1435 644 KB

C’est forcément plus adapté quand le site est en format « portrait » (par exemple sur un téléphone, ou la moitié gauche d’un ordi). On pourrait avoir un bouton « Épingler la carte à droite de l’écran », mais je pense que 2 boutons c’est trop ? Un menu c’est bof? du coup lequel choisir ?

Bref, je cherche un retour pour savoir si je continue à avancer là dessus pour contribuer, et si oui, quoi :wink:

Pour tester le rendu chez vous, aller sur une page c2c avec une carte, ouvrir les « outils développeur » du navigateur, et rentrer dans la console le code suivant (puis la touche ):

Code 
  var div = document.querySelector('.map-container');
  div.style.position = 'fixed';
  div.style.top = '3.25rem';
  div.style.marginTop = 0;
  div.style.left = '200px';
  div.style.right = '0px';
  div.style.zIndex = 10;
  div.style.height = '50%';
  document.body.style.paddingTop = '50vh';

Pour les devs, le code complet est ici Comparing c2corg:master...eddy-geek:pin · c2corg/c2c_ui · GitHub

PS: @Bubu ça n’empeche pas de diminuer les marges, je suis bien d’accord qu’il y en a trop, mais bon faut décider ou/combien pour pas nuire à l’esthétique (j’imagine) et je souhaitais quelque chose de plus drastique :wink:

3 Likes
#4

Salut
Mon retour: clairement une super fonctionnalité. Sur ordinateur, j’ouvre souvent plusieurs onglets pour faire ca.

Le rendu sur Chrome / MacOS / 1920x1080

image
image960×464 540 KB

C’est très bien. Pour être picky, je rajouterais bien un cadre (bordure) autour de la carte. En scrollant vers le bas, ca fait un rendu bizarre.
Il y a deja la ligne orange en haut, je verrais bien la meme en bas et a droite et a gauche.
Merci bcp

1 Like
#5

Si tu créés une PR et qu’il n’y a pas de problème d’intégration, ton travail sera visible par tous en un seul clic sans avoir à passer par les outils développeurs (donc bien plus accessible).

1 Like
#6

@Florence_B merci, c’est fait c2c_ui#3688 refait sur c2c_ui#3694
il faut un aproval pour être sur Camptocamp.org developement builds ?

1 Like
#7

Je viens d’approuver et de lancer le processus. Même si tout est au « vert », il faut un peu de temps pour que ça soit disponible dans la liste des builds (généralement je lance l’intégration le soir avant de fermer l’ordi, donc je ne sais pas si c’est 30 min ou 4h).

1 Like
#8

je rajouterais bien un cadre (bordure) autour de la carte

ok c’est fait.
J’ai réglé au passage tous les petits soucis qu’il y avait.

Je viens d’approuver et de lancer le processus

Toujours rien… et j’ai une 2e PR maintenant :wink:
Pas d’urgence bien sur.

1 Like
#9

Ca doit venir du fait que tu développes sur ton répertoire. Chiotte.
Je travaille sur le répertoire de c2c_ui en créant directement mes branches dessus. Si tu peux faire pareil ça nous simplifiera la vie je pense.

#10

Avec plaisir, mais je viens d’essayer et il faut que tu me donnes les droits de push sur le repo :slight_smile:

#11

Pas sûr que j’ai les droits…
@b_b ?

#12

Je t’ai donné les droits en te mettant dans le groupe developers, qui donne aussi accès à d’autres dépots (api, …).
Tu as du recevoir un mail de github.

3 Likes
#13

Ca y est la branche de test est en ligne!
par exemple Camptocamp.org
merci aux devs :slight_smile:

Bon point, c’est fait…aux 3-quarts, j’ai pas (encore?) mis la bordure droite.

4 Likes
#14

Top !
La bordure à droite me semble inutile.
En fait la bordure est inutile (à part pour la bordure haute car c’est la bordure basse de la bande du haut), le contraste d’un fond de carte avec le reste est largement suffisant pour matérialiser une limite. La bordure sert éventuellement à voir qu’il est censé y avoir qqch lorsque le fond de carte est inaccessible (serveur surchargé ou en rade), ou lorsqu’on est hors zone de définition de la carte. Mais pour le 1er cas (pas de tuiles) on peut aussi mettre une image ou du texte par défaut en fond de la boite de la carte.

Sinon, on peut aussi imaginer une amélioration pour les écrans larges : un 2e clic sur le bouton afficherait la carte sur toute la hauteur (sous la bande du haut), mais le 1/3 de la largeur (à droite du menu de gauche).
L’affichage du reste du doc se ferait en mode tablette : les boites de la colonne de gauche sont déplacées après les boites du corps du doc.
On peut même améliorer l’ergonomie : selon la taille de l’écran, le 1er clic agrandit la carte sur la largeur comme sur la démo, ou en hauteur comme décrit ci-dessus, un 2e clic passerait dans l’autre mode, et un 3e clic revient à la petite carte.

#15

oui je vais mettre un fond (css beige?), après la bordure reste utile/esthétique en cas de texte tronqué? comme là:

image

ah oui c’est bien, ça évite 2 boutons.

Ok… là je vais pas essayer de garder la bonne icone sur le bouton par contre :smiley:

Oui c’est la complexité, en « 1/3 largeur », les interactions avec les différents modes (la colonne de gauche qui se cache, en « largeur tablette » puis le mono-colonne en « largeur smartphone » qui devrait surement désactiver ce mode).

Et du coup, à moins que je mette la carte tout à droite et que j’utilise la même astuce du document.body.style.padding, il y a de potentielles interactions avec le css des autres composants Vue qui avaient l’air pas évidentes, avec mon petit niveau en tous cas.

#16

Oui, à droite ou à gauche c’est similaire, met là où c’est le plus simple pour le CSS.
Par conte je viens de tester, réduire la largeur du body ne change pas la mise en page des block, ça réduit leur largeur seulement.

#17

L’agencement des pages se fait majoritairement via des classes css suivant la largeur de l’écran, et un peu sur du conditionnel vuejs toujours sur la largeur de l’écran.
Il faudra donc probablement outrapasser ça en rajoutant des classes css ou conditions « conditionnées » à un paramètre suivant que la carte est affichée en grand ou non.
Sinon, je ne sais pas si c’est plus simple ou pas de repartir sur un nouveau module, qu’on pourrait afficher où l’on veut avec les conditions qui vont bien (voir affichage de l’encart association en page d’accueil qui est géré via bouton dédié).

#18

oui voilà, c’est parce que:

  1. on utilise des @media(... max-width ...) qui utilisent le viewport-width. j’essaie de faire la même chose basé sur la largeur du composant, en remplaçant ça par des callbacks sur resize, du $el.width, et des classes css.
  2. pour le passage sur 1 seule colonne en mobile, c’est parce qu’on utilise du column qui comme son nom ne l’indique pas du tout, a aussi un breakpoint automatique à 769px (merci à Copilot ou à la doc), aussi basé sur du max-width mais encore plus galère à changer :wink:

@Florence_B tu parles de quel encart? la on a deja 2 modules « éloignés » qui pour faire vraiment propre devraient en fait communiquer entre eux – donc je pense pas que plus de modules aide?

#19

BoardAnnouncementWidget ou HomeBanner

1 Like
#20

Peut être une ombre sous la carte plutôt qu’une bordure, ça matérialise mieux que la carte passe au dessus du texte.
Capture d’écran 2023-11-03 095532
J’ai repris l’ombre du menu de gauche :

box-shadow: 0 1px 4px 0 rgba(0,0,0,.2);

Mais c’est déjà très bien et très utile tel quel.

1 Like