Projet UI - Ergonomie de lecture d'une sortie

#1

Voir aussi le sujet principal concernant l’ergonomie.

Les améliorations demandées dans ce sujets ne seront peut être pas toutes mises en place avant la mise en prod de la 1ère version de la nouvelle UI de c2c.
Elles feront l’objet de développements ultérieurs.

De la même façon que pour le formulaire, je trouve bien plus pratique et logique d’afficher les infos par thèmes.
Typiquement, toutes les infos conditions (altitudes de chaussauge, quallité de neige, glacier, etc) devraient être affiché sous le titres de section « Conditions », avant le texte.
Actuellement on a des champs conditions en haut, et le texte plus bas. On va directement lire le texte parce qu’il y a les infos les plus précises. Puis on oublie de lire les infos chiffrés.
Par exemple, je renseigne l’altitude de chaussage, mais je ne la répète pas dans le texte. Des fois je la met par erreur dans le texte, je la supprime ensuite. Celui qui ne lis que le texte perd des infos. Idem avec l’état de la route.

En plus, ça permet d’alléger le 1er encart, où ne devrait se trouver que les champs (ordre arbitraire) :

  • participants (inscrits, non inscrits, nb)
  • la liste des itinéraires
  • les cotations pour la sortie
  • parcours partiel
  • Précision sur l’itinéraire
  • altitudes min/max
  • dénivelés
  • longueur total.

Puis :

  • Météo
  • Durée, idéalement à droite du précédent - ou alors à droite de « Précisions sur l’itinéraire » ? Mais ce dernier peut être long (exemple, où on constate aussi que les commentaires persos contiennent quasi aucune info utile, mais sont pourtant placées avant les infos utiles sur l’accès, l’itinéraire, etc…).

Section Conditions :

  • Evaluation des conditions
  • Altitude de chaussage / déchaussage
  • Quantité de neige, Qualité de neige, Etat du glacier
  • Fréquentation
  • Enneigement par zone
  • champ texte Conditions
  • signes d’avalanches
  • observation sur les avalanches

Section Accès routier :

  • Altitude d’accès, Etat de la route
  • champ texte Commentaire sur l’accès routier

Section Refuge :

  • Etat du refuge
  • commentaire sur le refuge

Commentaires perso

Exemple avec les champs chiffrés rassemblés avec les champs texte du même thème, par contre l’ordre des champs texte est celui en cours.
Bien regarder la version démo : Camptocamp.org developement builds

Projet UI - Ergonomie
#2

Pas hyper convaincu, tu pourrais tenter de faire un screen approx du rendu de ta proposition histoire qu’on se rende compte? J’ai peur que le mélange champs textes/champs courts donne un effet bizarre.

L’avantage de la solution V5/V6/maquette (champs courts tous en haut), c’est que c’est simple à appréhender à la lecture.

Sinon, au passage, le champ commentaire, son utilité est relative à l’usage que le lecteur fait de C2C : en première approche, les sorties C2C font voyager grâce à la prose de certains contributeurs. C’est un atout majeur de C2C pour son audience.

Quand le lecteur est dans cette optique (surf au hasard), le mode de navigation est au « flanage », le regard est attiré par ce qui est attirant : d’ou l’importance de mettre suffisamment en lumière ce passage (et avoir une belle photo en haut) :

A vrai dire, si cela ne tenait qu’a moi, l’ordre serait :

  1. une photo jolie (pas encore possible sur la v6, c’est pour cela que j’ai mis toute la galerie en haut).
  • bloc d’info comme sur la V6
  • commentaires personnels
  • le reste, selon un ordre logique à déterminer, et à ne pas changer tous les quatre matin.
  • le reste des photos (quand on pourra choisir manuellement la photo jolie du haut).

Après, quand j’ai besoin d’une info précise, je sais comment la trouver rapidement.

#3

Parce que tu sais qu’il y a (peut être) des infos utile 3 écrans plus bas ! Mais justement le novice ne le sais pas, ou même celui qui ne connait pas si ce contributeur a l’habitude de saisir des conditons.
Et pour celui qui n’a rien à faire des commentaire nombrilistes de 3 pages, c’est vraiment pète couille de devoir scroller pour trouver 3 lignes de conditions.
Le pire étant de scroller pour se rendre contre qu’il n’y a pas d’infos conditions car le champ est vide. C’est vraiment le pompon de l’anti-ergonomie…
Par ailleurs, l’ordre des champs (conditions puis commentaires) est celui en vigueur depuis 1997. Des centaines de milliers de sorties ont été saisies en tenant compte du fait que les conditions étaient avant les commentaires, et donc qu’il était inutile de répéter des infos déjà données dans les conditions. En inversant les champs, on ne comprend plus rien, ou on devine qqch, mais ce n’est pas du tout ce qu’a voulu écrire le contributeur.
Je trouve d’ailleurs irrespectueux envers les contributeurs de changer l’ordre de leurs écrits.
Enfin, mettre les commentaires en premier, ça met en avant les sorties ne donnant aucune info conditions mais où le contributeur se la pète dans les commentaires. Alors qu’il faut plutôt faire le contraire. Il y a déjà une certaine dérive avec des commentaires de 2 pages et 1 ligne de conditions, inutile de l’amplifier.
Imagine ce que ça donne de mettre les conditions en bas avec ce genre de sorties : Camptocamp.org developement builds

3 Likes
#4

On ne peux pas pointer une page en particulier pour argumenter pour ou contre une solution, tu trouveras toujours un document ou le meilleur compromis ne rend pas top.

Mais bref, je te rejoins sur le principe de ne pas trop modifier l’ordre, autant pour l’auteur, que pour le principe de moindre surprise (c’est ce que j’ai fait sur la maquette je crois?).

Par contre, si tu peux prendre le temps de faire un screen pour ta proposition, parce que la, je n’arrive vraiment pas à me projeter dedans.

#5

Particulièrement avec la recherche sur le titre : on veut voir si les résultats correspondent à ce qu’on veut quand on tape la moitié du nom d’un sommet par exemple, ou s’il faut affiner.
Pour voir les résultats, faut cliquer pour fermer la boite, puis pour affiner faut recliquer 2 fois (ouverture de la boite puis clic dans la zone de saisie).

Voilà (sur la version démo) : Camptocamp.org developement builds
N’oubliez pas d’aller tout en bas pour voir les champs accès routiers et refuges (ah ben oui, tout en bas, après ma prose inutile).

Le design est surement à revoir (moins d’espacement entre les lignes, petite séparation (ou pas) lorsqu’il y a une liste en début du champ texte, etc).
On voit que juste avec les champs chiffrés, il y a déjà pas mal de texte avec des infos.
C’est particulièrement vrai avec les « signes d’avalanches », étant donné que les intitulés des options ont été conçues pour être intégrées au champ texte comme sur cet exemple, et non pas pour être empilé au km dans une petite colonne ou une longue ligne.

C’est aussi pour cette raison que ce ne serait pas gênant la plupart du temps si on déplace la section « accès routier » avant les conditions. Cette section contiendrait la plupart du temps uniquement les champ chiffrés, parfois 2 lignes de texte, et rarement une dizaine de lignes. Ca reviendrait quasiment au même qu’aujourd’hui, avec les champs chiffrés de l’accès routier dans la boite des infos générales (donc avant les conditions texte).

#6

J’aime bien ! (pensez à aller sur la démo, je me suis fait avoir en allant d’abord sur la prod)
Et ça résout le pb de la lisibilité des champs chiffrés à la pelle au début.

#7

globalement j’aime bien la proposition de bubu c’est plus lisible que le gros amas de champs chiffrés au début.

  • Pour la partie condition je suis complétement convaincu, essayer de mettre les champs chiffrés sur 2 colonnes ?
  • Pour Refuge et Accés, ça dépend du design associé :
    • si on met ces rubriques avant le champ de com perso (ma préférence), il faut arriver à avoir un affichage de ces rubriques assez compact pour ne pas repousser les com perso trop bas. De plus souvent les champs textes de ces rubriques ne sont pas remplis, donc il y aura peu de place occupé par ces champs, il faut que ça reste agréable à l’oeuil dans tout les cas. Peut-etre mettre ces deux rubriques sur deux colonnes pour les ecran larges)
  • sinon ça ne me choque pas trop si on bascule ces deux rubriques (y compris les champs chiffrés) apres les com perso (le design est moins critique car c’est en bas de page)
  • pour le champ description de l’iti suivi, je pense qu’il faut qu’il soit juste avant les conditions (ou éventuellement juste apres)
1 Like
#8

+1, c’est l’enchaînement logique (du moins en ski, raquettes et rando pédestre)

1 Like
#9

+1 également

J’ai une petite préférence pour ça. Typiquement en escalade le champ comment’ perso est souvent plus important que refuge et accès (qui de toute façon est déneigé…).

#10

sur mobile les champs « Conditions d’enneigement par zones » débordent de l’écran. Pour éviter cela sur la V6, au lieu d’etre en tableau ils sont les un en dessous des autres pour les tout petits ecrans

#11

J’aime pas du tout du tout avoir la description de l’itinéraire en bas : je préfère en haut, au moins on sait de quoi on parle c’est le basique de la sortie.
Météo / durée ça tiendrait pas en 2 colonnes ? sinon je trouve mieux au dessus des conditions, idem ça fait partie du contexte pour savoir de quoi il retourne.
Pour le reste OK.

Sur mobile la partie « appli mobile » prend vachement de place, on peut la masquer ?

Carine

1 Like
#12

Sur quelle page ?

#13

Dans un premier temps, je vais reproduire la disposition V6. Puis si il sort une disposition claire et conensuelle de cette discussion, et que j’ai le temps (je met ça en gras, car le timing est serré), je l’implémenterai pour la première livraison en prod.

#14

autant pour moi la croix si petite en haut à droite n’étais pas dans mon champ de vision (fatiogué, certainement, ce champ de vision !)
Donc RAS.
Carine