Projet UI - Ergonomie de saisie d'une sortie

#30

je ne suis pas sûr que cette logique soit bcp plus ergonomique car il faut tout de même respecter la logique thématique.
un peu dans cette logique, voilà une proposition avec 3 onglets thématiques avec les infos basiques plus ou moins indispensables et un 4e expert.
NB. Je propose sans vraiment être convaincu du résultat…
A partir de la proposition de Charles ça donnerait :

  • onglet 1
  • :heavy_minus_sign: condition_rating
  • :heavy_minus_sign: participants
  • :heavy_minus_sign: fields.description
  • :heavy_minus_sign: fields.disable_comments
  • :heavy_plus_sign: fields.partial_trip (c’est important !)
  • :heavy_plus_sign: fields.route_description
  • onglet 2
  • :heavy_plus_sign: condition_rating
  • :heavy_minus_sign: _sign: fields.route_description
  • nouvel onglet 3 avec les info perso (comme sur la V6 )
  • regrouper les onglet 3 et 4 proposés par Charles dans un onglet n° 4 « Champs experts »
#31

L’ordre des champs correspondant à mon 1er post :

La logique de base est que lorsqu’un champ a une action sur un autre champ, il est mis avant.
Par exemple le choix de l’itinéraire modifie le titre => il faut mettre l’outil d’association avant le titre.
Sinon on a tendance à remplir le titre, avec des noms voies sans nom de secteur, etc.
Il peut y avoir des dépendance insolubles, il faut juste essayer de faire le meilleur compromis.
Il y a des champs avec peu de dépendances, avec plus de liberté de position.
Pour ce champs, je fais une proposition évidemment critiquable, mais avec une certaine logique. Par exemple les champs de l’accès routier sont mises avant les champs conditions, simplement parce que la sortie débute souvent par un accès routier.
Quand on saisit sa sortie, on déroule la journée dans l’ordre, et les champs pertinents nous tombent sous les yeux juste en scrollant un peu, avec parfois un champ chiffré, et un champ texte dessous pour ajouté des précisions si nécessaires.

J’ai mis certains champs sur la même ligne, en indentant d’un cran. Il a fallu que je mette un titre à la ligne, mais dans le formulaire il n’y a rien de plus que les champs et leur intitulé.

map :exclamation: => toujours visible , à droite ou à gauche - sur mobile, un bouton toujours visible permet de basculer entre carte et formulaire

  1. Itinéraire, activité, date, participants
    • bouton Ajouter une trace GPS
    • fields.activities :exclamation: :star:
    • fields.routes :exclamation: :star:
    • fields.partial_trip :exclamation:
    • fields.route_description :exclamation:
    • fields.users :exclamation: :star:
    • participants
      • fields.participant_count :exclamation:
      • fields.participants :exclamation:
    • fields.title :exclamation: :star:
    • Dates
      • fields.date_start :exclamation: :star:
      • fields.date_end
    • fields.timing :exclamation:
  • Altitudes, dénivelés, cotations
    • Elevation
      • fields.elevation_min :exclamation:
      • fields.elevation_max :exclamation:
    • fields.length_total :exclamation:
    • height_diff
      • fields.height_diff_up :exclamation:
      • fields.height_diff_down :exclamation:
    • fields.height_diff_difficulties
    • fields.global_rating
    • fields.rock_free_rating
    • fields.engagement_rating
    • fields.equipment_rating
    • fields.ski_rating
    • fields.labande_global_rating
    • fields.snowshoe_rating
    • fields.ice_rating
    • fields.via_ferrata_rating
    • fields.hiking_rating
    • MTB rating
      • fields.mtb_down_rating
      • fields.mtb_up_rating
  • Accès routier / TC
    • Ligne 1
      • fields.elevation_access :exclamation:
      • fields.access_condition :exclamation:
    • Ligne 2
      • fields.lift_status :exclamation:
      • fields.public_transport :exclamation:
    • fields.access_comment :exclamation:
  • Conditions
    • fields.elevation_up_snow
    • fields.elevation_down_snow
    • Snow
      • fields.snow_quantity
      • fields.snow_quality
      • fields.glacier_rating
    • Condition rating
      • fields.condition_rating :exclamation:
      • fields.frequentation :exclamation:
    • fields.weather :exclamation:
    • fields.conditions_levels
    • fields.conditions :exclamation:
    • fields.avalanche_signs
    • fields.avalanches
    • fields.hut_status :exclamation:
    • fields.hut_comment :exclamation:
  • Commentaires
    • fields.description :exclamation:
    • fields.disable_comments :exclamation:

La section « Accès routier » peut être en dessous des conditions, en y mettant aussi les champs sur le refuge.
Mais avec toutes les fioritures que j’ai décrites dans le 1er post, je trouvais quand même pratique de renseigner l’altitude de l’accès, puis qu’il suffise de cocher une case « Chaussage / déchaussage au départ » pour copier l’altitude dans les 2 champs « Altitude de chaussage / déchaussage ».
Tant qu’il n’y a pas ce système, on peut déplacer les champs « Accès routier » après les conditions.

1 Like
#33

… et aux itinéraires associés.
Ce champ ne sert pas pour une sortie en suivant un itinéraire simple (sans variante).
Quand il y a des variantes, ou qu’on a fait un enchainement, on le précise dans ce champ.
Idem quand on s’est arrêté avant le sommet : on coche la case « parcours partiel » puis on donne une précision dans le champ texte.
C’est pour ça que j’ai rassemblé la liste des itinéraires, la case parcours partiel et le champ itinéraire emprunté.
Avec bien sûr la trace GPS, mais qui est toujours visible sur la carte à gauche ou à droite. De toute façon on a besoin de la carte pour toutes les sections, si on la coince dans une section on sera gêné dans toutes les autres.

Si on veut faire simple au début, on met la carte au début, sous le bouton « ajouter une trace GPS ».

#35

Condition rating perdu au fond du 4eme onglet est une erreur à mon avis : cette info est archi présente dans le rendu de camptocamp, directement sur la page d’accueil, et en couleur sur la carte des sortie. c’est peut etre le champ le plus important -> il faut le mettre très en avant si on veut qu’il soit rempli.

#36

On s’en fout qu’il y ait une trace GPS ou non, la carte set à plei de choses.
Perso j’étais tout le temps en train de scroller vers la carte pour la regarder, pour voir les orientations, les altitudes, les nom des combes où j’ai vu des traces, etc.
Maintenant j’ouvre l’itinéraire dans un autre onglet et j’agrandis la carte. Mais ça oblige quand même à changer d’onglet.
Je me rends compte que ce serait mieux d’avoir la carte sur une moitié ou 1/3 de l’écran, et le formulaire sur le reste. La proportion pouvant se régler en cliquant sur la limite. Et avec un bouton permettant de basculant en carte pleine fenêtre ou formulaire pleine fenêtre.
Idem pour le formulaire des itinéraires.

Su la V6, le titre est le 1er champ, et pourtant on a régulièrement des utilisateurs qui demandent comment modifier le titre !
Ca ne marche pas de mettre des champs en tête en espérant qu’ils soient plus remplis.
D’autant plus que la 1ere partie est là pour saisir les champs obligatoires, mais qui ne correspondent pas aux infos qu’on est venu saisir (sauf si on saisit des sorties vides).
Donc on remplit rapidement et on passe à la suite (quand on vient d’un itinéraire, il y a juste la date à remplir, qu’on pourrait pré-remplir à la date du jour mais par expérience de la V5 c’est une mauvaise idée)
La suite, c’est entre autres les conditions. Et ça me semble naturel de mettre l’évaluation des conditions juste à côté du champ texte « condition ».
Et c’est encore plus pertinent si c’est séparé en onglets : quand on va dans l’onglet « conditions », on compte y trouver le champ « évaluation des conditions ».

1 Like
#37

J’aime bien (avec qq ajustements à faire)
En tout cas, je suis assez pour la logique « le plus important » dans les 1ers onglets, tout en respectant la logique thématique et la logique qui consiste à mettre avant un champ qui remplit automatiquement un champ suivant.

Et je pense qu’il faut garder les onglets pour ne pas « effrayer » les gens avec une liste impressionnante de champs (et en plus ça les perturbera moins par rapport à la V6).

Par rapport à la proposition de José (qui est un amendement de celle de Charles), je propose les ajustements suivants :

  • onglet 1 :

    • mettre la date en tout 1er (idem V6)
    • puis choix de l’activité
    • puis trace (avec carte)
    • puis choix de l’iti
    • puis titre (ou plus bas)
    • puis description iti
    • parcours partiel
      [jq ici hormis l’ajout du titre, c’est comme la V6, les champs suivants étant reportés dans l’onglet expert]

  • onglet 2

    • condition_rating (c’est bien l’évaluation chiffrée des conditions ça ?)
    • champ conditions
    • [autres champs sur les conditions : tableau d’enneigement par zones, qualité/quantité de neige, avalanches, altitude chaussage/déchaussage,…]
    • météo (important de le garder à proximité des conditions)

  • onglet 3 : idem V6, sauf le titre qui est sur l’onglet 1

  • onglet 4 : tout ce qui reste, càd les champs remplis automatiquement, la rubrique « accès routier/TC et refuge/cabane » de la V6

1 Like
#38

Dans ma pratique de saisie de sorties, ce serait un vrai plus (au moins sur les écrans larges) : pour ma part, j’ouvre toujours une carto dans un onglet à coté. La cartographie m’est utile que ce soit pour décrire les conditions ou les commentaires : donner précisément les altitudes et/ou orientations de mes observations de terrain, faire référence à la toponymie officielle pour que tout le monde comprenne… La présence de la carto serait pour moi un vrai gain d’efficacité dans la saisie des sorties.
Avec le formulaire actuel de l’UI officielle, il y a par exemple plein de place non utilisé avec un écran de 1980px de large.

2 Likes
#40

Ce n’est pas forcément le futur (proche).

Pareil que @Bubu.

#41

Sauf que l’ergonomie générale que vous décrivez impose, pour être un minimum pratique, de devoir coder de nouvelles fonctionnaités d’interface : (proportion réglable, bascule carte/pas carte). Rien d’impossible bien sur, mais je rapelle les conditions du projet :

nouvelles fonctionnalités si consensuelles et rapides à coder.

Ce n’est pas le cas ici. Il faudra remettre à plus tard la liste au père Noel. Nous devons nous en tenir à ces conditions, si on veut délivrer, et se permettre par la suite ces améliorations de fond.

Donc, pour être tout à fait clair, si nous ne sommes pas capable, dans un temps raisonnable et sans pugilat, de sortir de cette discussion une décision concernant l’organisation (ie quels onglets/champs, et dans quel ordre), je reproduis l’ordre des champs et des onglets de la v6 à l’identique. Dead line le 30 janvier.

Désolé de faire le rabat joie et de brider votre enthousiasme :wink:

#42

En l’occurence, la carte est actuellement présente, il s’agit d’une fonctionalité à préserver. Même hors C2C, la carte est l’élément de base pour expliquer ou prévoir une sortie montagne.

Pour ma part, j’estime que supprimer une bonne fonctionalité sous prétexte qu’elle est peu utilisée est un nivellement par le bas dommageable. Si on veut de bonnes contributions pertinentes, il faut donner les bons outils pour le permettre. Tanpis s’il ne sont pas utilisé, à nous via la modération, les forums et l’exemple de montrer qu’ils sont utiles pour changer la donne !

#44

Hola,
aucun lien, mais merci pour cette astuce, je connaissais pas et c’est top :slight_smile:

Petit lien : et la carte qui s’ouvre dans une pop up ? aussi difficile ?
Carine

#45

Merci pour ces petites corrections tout à fait logique.
J’ai quand même un doute à la cohérence qu’on pourra donner au dernier onglet dans lequel se retrouve pas mal de champs avec des thèmes différents.
Une autre question que je me posais : on a surtout en tete la saisie de sortie ski, est-ce que ça tient la route pour des sorties escalades ?

Sinon moi aussi je m’ouvre une carte dans une autre fenêtre pour remplir ma sortie. Ce serait un plus de pouvoir l’intégrer à l’interface, mais je comprends que ce n’est pas trivial. > à ajouter par la suite…

#46

pour moi c’est rattaché à l’itinéraire et à la trace GPS (j’avais omis de la mentionner dans le 1er onglet, Loic a corrigé) mais pas tellement au conditions. Pour détailler les conditions, je n’ai pas besoin de la description de l’itinéraire mais par contre j’ai besoin de la carte (pour retrouver les altitudes et les lieux dit correspondant aux observations)

C’est le champ des commentaires subjectifs, on ne se fait pas de soucis sur le fait qu’il sera remplit, et s’il ne l’ai pas, ce n’est pas grave.
Il me semble important de regrouper dans un onglet « perso » tout ce qui a trait à l’aspect vraiment perso (et qui à mon avis ne devrait pas etre en licence CC mais en copyrigth, mais c’est un autre débat).
De plus, comme l’a expliqué bubu, il est important de le mettre après les conditions, sinon les utilisateurs racontent tout dedans y compris les conditions…

En fait il n’y a vraiment que le dernier onglet qui est « optionel » à la saisie, les 3 premieres restent assez indispensables.

2 Likes
#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.