Projet UI - Ergonomie de saisie d'une sortie

#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 !

#43

Mais je n’ai jamais dit que je voulais la supprimer. J’ai juste dit que je ne n’aurais pas le temps de faire mieux qu’une ré-organisation de la localisation de chaque champ.

  • Dans la v6, elle est sur le premier onglet en troisième position.
  • Dans la première version livrée en prod pour ce projet :
    • elle sera dans un onglet X à la place Y si nous nous mettons d’accord sur X/Y,
    • et dans le premier onglet/3ème position si nous n’arrivons pas à trouver un compromis avant le 30/01.

Mais il n’y aura pas pour cette première version d’interface une carte toujours visible/switch d’affichage de carte/taille réglable, ou autre raffinements qui n’existent pas sur la v6.

Désolé pour l’incompréhension.

#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
#47

Si je concatène vos amendements, ça donne ceci :

  • :exclamation: champ visible quelque soit l’activité
  • :star: champ obligatoire
  • :robot: champ calculé automatiquement (mais pouvant être surchargé).
  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
    • fields.length_total :exclamation:
    • Elevation
      • fields.elevation_min :exclamation: :robot:
      • fields.elevation_max :exclamation: :robot:
    • height_diff
      • fields.height_diff_up :exclamation: :robot:
      • fields.height_diff_down :exclamation: :robot:
    • fields.height_diff_difficulties :robot:
    • fields.global_rating :robot:
    • fields.rock_free_rating :robot:
    • fields.engagement_rating :robot:
    • fields.equipment_rating :robot:
    • 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:
    • fields.public_transport :exclamation:
    • fields.frequentation :exclamation:
    • fields.hut_comment :exclamation:
    • fields.hut_status :exclamation:
    • fields.elevation_access :exclamation:
    • fields.access_condition :exclamation:
    • fields.access_comment :exclamation:
    • fields.lift_status :exclamation:
    • fields.timing :exclamation:

J’aime bien beaucoup, à ces deux détail près :

  • je mettrais le champ condition_rating dans le premier onglet : il a une place prépondérale dans le reste de l’interface, et son absence est préjudiciable pour le reste de l’interface. Pour tout dire, je serais tenté de modifier l’API pour le rendre obligatoire. Quitte à le mettre aussi dans l’onglet n°2.
  • et je laisserai le champ titre dans l’onglet 3 : il est rempli automatiquement, et rare sont les cas ou l’on souhaite le modifier.

Edit également, au sien de l’onglet n°4, tous les champs auto en bas.

#48

Rien d’infaisable, mais même réponse : entre le temps de discussion, plus le temps de code, il n’est pas raisonnable de se lancer la dedans pour ce projet, sous peine de ne pas finir dans les temps. Ca ne remet pas en question l’idée, bien au contraire, mais il faut la garder pour l’après projet.

Promis, si il se trouve que j’ai fait tous les points et que j’ai du rab, on en discute. Mais je ne vais pas te mentir : il y a peu de chance.

#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
#52

Tu as peut être raison. Par contre, j’insiste sur son interet : de par son coté synthétique, il permet une première approx sur la carte des sorties. Ca en fait un outil, aussi imprécis soit-il, qui a une énorme plus-value à l’usage.

Ok, ca roule, j’achète :slight_smile:

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

#57

Sur le principe général, oui. Juste, si on arrive sans trop d’effort, avec une réorganisation de la place des champs, à améliorer l’erognomie des sorties, je suis pret à investir un peu de temps dessus, tellement le sujet est important.

Mais oui, si on n’arrive pas à se mettre d’accord facilement, on reproduit la V6.

#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 ?

#60

Pas forcément dit, mais surtout moins critique : tu as bien plus de contributeurs qui éditent les sorties que ceux qui éditent les itinéraires. Pour leur donner envie d’éditer les itinéraires, il faut deja que le premier outil qu’ils ont sous les yeux soit agréable. Et en effet, le formulaire d’édition des itinéraire est le second plus urgent (puis points de passage, et ainsi de suite).

1 Like