Projet UI - Ergonomie de saisie d'une sortie

#49

Simplement parce que dans la V6, quand on associe un itinéraire, la carte n’est pas recentrée sur l’itinéraire. Si c’était le cas, en voyant la carte se recentrer en directe car visible à côté de l’outil d’association d’itinéraire, les utilisateurs l’utiliseraient plus pour donner des infos moins vagues.
Pas besoin d’être un power user de c2c pour comprendre qu’une carte est utile pour saisir une sortie, de la même façon qu’elle a été utile pour la préparer.
Mais pas de problème pour faire une première version avec des onglets et juste un ordre différent des champs.
Bien sûr pour une sortie escalade en couenne ou grande voie classique sans problème d’accès/retour, la carte est peu utile une fois l’itinéraire associé.

Par ailleurs, la carte sera utile plus tard pour de nouvelles fonctionnalités.
Par exemple définir des points ou des zones pour des traces d’avalanche observées, ou associer un point ou une zone à une ligne de l’enneigement par zone, le point pouvant provenir de l’appli c2c dans laquelle on aura saisi un draft de condition à un moment donné, ou plein d’autres trucs de ce genre.

Mais quand on souhaite le modifier, c’est pour concaténer les voies enchainées : Sommet Toto : voie 1 + voie 2 + voie 3
Il faut donc recopier un nom de voie à la main. Mais pas de bol, la liste des itinéraires associés est sur le 1er onglet, on a la flemme d’aller le voir et de se souvenir du nom (dont l’orthographe peut être non intuitive, comme « Shesep Ankh »), donc on écrit un peu n’importe quoi, ou plutôt on ne modifie pas le titre pour ne pas risquer de faire de faute (c’est l’excuse qu’on se donne).

#50

d’un point de vue thématique, ça serait pas trop cohérent. Je considère que tous les utilisateurs balayeront les 3 premiers onglets, comme il est en premier du 2e onglet, il est déjà en bonne position (peut-etre meilleure que noyé au milieu du 1er)
De plus, je ne suis pas fan de ce champ qui est ultra subjectif et pas très porteur d’information. Il est mis en avant dans l’interface car il a le mérite d’être synthétique et universel pour toutes les activités, mais c’est bien son seul mérite…

je pense qu’il faut le mettre plus en avant pour que les utilisateurs l’utilisent mieux en le modifiant plus souvent pour que le titre de la sortie reflète mieux l’itinéraire suivi. c’est un champ qui peut être très informatif puisqu’il apparait dans toute les listes…
C’est HS, mais je pense qu’une évolution de la base de donnée devrait aller vers une réduction assez drastique du nombre d’itinéraire (typiquement suppression de la plupart des enchainements et des traversées) la conséquence serait que pour les sorties le champ titre et description de l’iti suivi prendrait une importance plus importante

1 Like
#51

C’est ce qu’on fait depuis 2007, mais c’est à la main, il y a encore du boulot, et pour l’instant on ne supprime pas les étapes de raid (qui par définition sont des traversées), donc ce n’est pas une suppression systématique.
D’autant plus qu’en compensation, il faut indiquer les traversées et boucles possible, avec les liens vers les itinéraires, dans chacun des itinéraires en AR. Il ne suffit pas de faire des fusions à la chaine. Sans parler de l’association des sorties en traversée aux 2 itinéraires en AR à la place de l’itinéraire en traversée (généralement avec la fusion il en manque juste 1).

1 Like
#53

je mettrais par cohérence le champ durée avec la date, et je laisserais le titre sur le premier onglet.

#54

L’ergonomie de saisie d’une sortie dépend de l’ergonomie de l’itinéraire. Il faudrait commencer par l’ergonomie de saisie d’un itinéraire.

(edit : typo)

#55

Est-ce qu’il y aurait moyen de conserver le regroupement en bloc au sein des onglets comme sur la V6 ?

Une proposition de réorganisation de l’onglet 4

  1. general informations : données obligatoire et courantes
    • Dates
      • fields.date_start :exclamation: :star:
      • fields.date_end
    • fields.activities :exclamation: :star:
    • map & trace :exclamation:
    • fields.routes :exclamation: :star:
    • fields.title :exclamation: :star: :robot:
    • fields.route_description :exclamation:
    • fields.partial_trip :exclamation:
  • Terrain informations : informations autour du terrain et des conditions
    • condition_rating
      • fields.condition_rating :exclamation:
      • fields.glacier_rating
    • fields.conditions_levels
    • fields.elevation_up_snow
    • fields.elevation_down_snow
    • Snow
      • fields.snow_quantity
      • fields.snow_quality
    • fields.conditions :exclamation:
    • fields.avalanches
    • fields.avalanche_signs
    • fields.weather :exclamation:
  • Personnal
    • fields.users :exclamation: :star:
    • participants
      • fields.participant_count :exclamation:
      • fields.participants :exclamation:
    • fields.description :exclamation:
    • fields.disable_comments :exclamation:
  • Expert
  • Bloc Timing et fréquentation
    • fields.timing :exclamation:
    • fields.frequentation :exclamation:
  • Bloc Accès & Refuges
    • fields.elevation_access :exclamation:
    • fields.access_condition :exclamation:
    • fields.access_comment :exclamation:
    • fields.public_transport :exclamation:
    • fields.lift_status :exclamation:
    • fields.hut_status :exclamation:
    • fields.hut_comment :exclamation:
    • Bloc données chiffrées relatives à l’itinéraire suivi
      • fields.length_total :exclamation:
      • height_diff
        • fields.height_diff_up :exclamation: :robot:
        • fields.height_diff_down :exclamation: :robot:
    • fields.height_diff_difficulties :robot:
    • Elevation
      • fields.elevation_min :exclamation: :robot:
      • fields.elevation_max :exclamation: :robot:
    • fields.global_rating :robot:
    • fields.rock_free_rating :robot:
    • fields.engagement_rating :robot:
    • fields.equipment_rating :robot:
    • ski rating
      • fields.ski_rating :robot:
      • fields.labande_global_rating :robot:
    • fields.snowshoe_rating :robot:
    • fields.ice_rating :robot:
    • fields.via_ferrata_rating :robot:
    • fields.hiking_rating :robot:
    • MTB rating
      • fields.mtb_down_rating :robot:
      • fields.mtb_up_rating :robot:
#56

Le mieux c’est de reproduire la V6 le plus à la lettre possible.

Comme ça au moins on sait ce qu’on est en train de faire.

Le but du projet, c’est d’avoir une UI accessible, modifiable.

Les idées nouvelles, on peut les noter, en discuter post-projet, puis éventuellement les adapter à une interface utilisateur devenue plus aisément maléable.

#58

Oui, meme si d’un point de vue design, c’est discutable : ca fait trois axes de rangements (onglet, section, ligne) qui est difficilement maitrisable, et qui illustre souvent l’adage « le mieux est l’enemi du bien »

Une fois qu’on se sera arrété sur l’ordre, on pourra faire des tests en ce sens pour voir si ca clarifie le formulaire.

#59

et pour les itinéraires, ce sera plus simple ?

#62

Le champ durée/horaire, je le mettrais plutôt avec les conditions (après la météo ?), car son remplissage donne de l’info sur les conditions (c’est important de savoir à quelle heure le gars est descendu s’il a eu une moquette tip-top).
Et le titre, je n’ai pas d’avis tranché entre 1er onglet ou 3e onglet (idem V6).

La dernière proposition de José Projet UI - Ergonomie de saisie d'une sortie avec la réorg de l’onglet expert me va bien.

J’ai l’impression qu’on commence à converger :slight_smile: (entre power users certes, mais c’est déjà ça, même si l’objectif est que ça attire des newbies).

Autre idée (fastoche) : renommer le champ « Description de l’itinéraire » en « Précisions sur l’itinéraire ». On trouve trop souvent des sorties où les gars donnent toutes les infos sur les conditions dans ce champ et rien dans le champ idoine.

PS : pour l’histoire de la carte, pareil je l’ouvre à côté pour saisir ma sortie, donc ce serait un plus de l’avoir facilement sur tous les onglets, mais je comprends aussi qu’on repousse ça à plus tard. Pour moi la priorité « post-projet » sur la saisie des sorties est de faciliter le choix de l’iti (filtrer sur l’activité choisie, choix proposés en fonction de la trace,…)

1 Like
#64

test depuis mobile / android

Changer le nommage de certains champs ?
Conditions -> renommer en « conditions de terrain » ?
Participants -> « Participants membres » et « rechercher pseudo » (d’ailleurs l’info bulle est trop large sur écran mobile)
Participants sans compte c2c : du coup le champ est trop large. en grisé « participants » -> « lister les noms » ?

Informations générales je mettrais bien le dénivelé et les altitudes sous la carte et l’itinéraire, c’est quand même lié et autant avoir les deux sous les yeux c’est plus pratique à compléter.

Sur le reste l’ordre me semble logique.

Carine

EDIT
Test rapide sur PC / Chrome
C’est vraiment obligé les onglets, on peut pas réduire le nb par 2 et scroller un peu plus plutôt que cliquer ?
Même remarque pour le champ dénivelé / longueur qui est perdu au fond du dernier onglet -> sera jamais rempli :slight_smile:

#65

A savoir que ces deux informations sont remplis automatiquement à partir des valeurs de l’itinéraire.

C’est une solution. Pour moi, le point hyper important, c’est d’avoir un premier onglet simple et suffisant (ie, pas besoin d’aller sur les suivants si on ne le souhaite pas).

Après, j’aime bien le découpage actuel qui me semble un bon compromis, et je trouve efficace d’avoir un second onglet avec les infos non obligatoires, mais qu’on aimerait bien voir remplies (je rajouterai bien sur le titre une petite icone :heart: avec une petite phrase au survol : Merci pour le partage).

Mais la solution avec deux onglets, et le second découpé en sections me semble acceptable aussi.

#66

D’où l’utilité (selon moi) de les avoir sous les yeux pour les corriger si besoin :slight_smile: sinon on zappe et hop c’est faux.

j’ai po les coeurs :stuck_out_tongue:

#67
  • Une étoile ? :star:,
  • un pouce ? :thumbsup:
  • Rien, c’est pas une bonne idée ?

C’est sur. Mais c’est vrai pour tous les champs auto liés au terrain : 6 champs, auxquels on peut également rajouter les altitudes de chaussage/déchaussage, et les conditions d’enneigement par zone pour le ski de rando (ces trois dernières n’étant pas automatique, d’ailleurs).

Il n’y a malheureusement pas de solution idéale : plus on rajoute des champs sur le premier onglet, plus on augmente la proba qu’ils soient (correctement) remplis, et plus on diminue la simplicité d’usage.

D’autres avis ? Pour infos, les champs non textuels) ou il serait utile d’avoir la carte sous les yeux pour bien les compléter sont :

  • Longueur totale
  • :robot: Dénivelé positif/négatif
  • :robot: Dénivelé des difficultés (seulement pour RHM et mixte)
  • :robot: Altitude Min/max
  • et seulement pour le ski de rando :
    • Conditions d’enneigement par zones
    • Altitude de chaussage/déchaussage
#68

Test depuis PC bureau

bouton prévisualiser

bouton visualiser pas avec les boutons enregistrer/annuler comme c’est le cas actuellement. Je ne sais pas ce qui vaut le mieux, mais on a dit comme la V6. Je le signale donc comme écart.

Titre champ Description itinéraire

+1

Fait dans Transifex. A noter que dans la V5, c’était « Itinéraire emprunté ». Il y a un moment que ce titre de champ me paraissait bizarre, mais je n’avais pas cherché pourquoi. @Miko et @CharlesB, je vous ai mis ces chaîne en suggestion attendu qu’on les trouve dans les deux répertoires main et V6 du projet.

J’ai donc mis « Précisions sur l’itinéraire emprunté »

champs association document

Devrait être en premier sous le titre car cela permet de préremplir le reste

champs avalanche

Je clique sur « non »
Si je reclique sur « non », le champ n’est pas déselectionné
Si je clique sur une autre case, alors le champ « non » se déselectionne si j’ai cliqué un nombre paire de fois et ne se déselectionne pas si j’ai cliqué un nombre impaire de fois.

Et ce comportement est conservé si je clique trois champs etc … ensuite la selection ou la déselection du champ apparait aléatoire selon le nombre paire ou impaire de clic sur le bouton.

image.png1477×143 6.94 KB

image.png1477×150 11.1 KB

image.png1439×119 7.11 KB

champs avalanche / refuge / accès

Ne faire apparaître ces champs que si on rempli le début : avalanche oui/non, l’accès déneigé ou non, etc … ?

Projet UI - Ergonomie des boutons de sauvegarde
#69

T’es sous firefox ?

#70

Non

#79

Si l’objectif est le newbie, alors le premier onglet ne doit contenir que l’indispensable de l’indispensable qu’on puisse cliquouiller sur enregistrer tout de suite.

#81

un petit ajustement : permuter les deux champs fields.avalanches et fields.avalanche_signs

si on conserve les onglets, il faudrait trouver un moyen de pouvoir circuler facilement de l’un à l’autre (en particulier en bas de page) : quand on finit de remplir le premier onglet, on ne voit pas qu’il y en a d’autre :
-> on risque de cliquer sur enregistrer sans finir la saisie
-> même si on sait qu’il y a d’autre onglet, il faut scroller vers le haut, ce n’est pas pratique

bref je préfère la position toujours visible des boutons sur la V6 actuelle

une autre idée ? ajouter des boutons « étapes suivantes » et « étape précédente » à coté des boutons 'enregistrer" et « annuler » et les dupliquer en haut

2 Likes
#82

J’ai une question bête: est-il prévu de laisser une période de test pour les utilisateurs ? On pourrait mettre l’info sur le bandeau bleu histoire que les utilisateurs soient au courant et puissent donner leur avis. Je doute que beaucoup d’entre eux viennent se promener ici. La discussion ne fait intervenir quasiment que des modérateurs.

1 Like