Projet UI - Ergonomie de saisie d'une sortie

#22

J’ai répondu dans le corps du message.

1 Like
#23

:+1:

#24

Je préfère la disposition de la V6 avec éventuellement qqs ajustement à la marge :

1er onglet

  • Ajouter « Titre de la sortie » (au dessus d’itinéraire emprunté ?)
  • Case parcours partiel plus visible : au dessus de Description de l’itinéraire ?

2e onglet

  • déplacer Météo à la fin du bloc ‹ météo et conditions ›
  • déplacer le champ textuel de Conditions en dessous de Signes d’avalanches
  • séparer en 2 blocs acces rouiter et refuges, avec la logique champ numérique au dessus de champ textuel

Si simple à faire : rendre la carte visible sur la moitié de l’écran tout au long de la saisie (pour les grand ecran)

mais bon je suggérerais surtout de ne pas perdre de temps à débattre la dessus, je ne crois pas qu’on puisse converger dans un temps raisonnable.

#25

On avait déjà fait un travail similaire pour le V6, mais tout n’avait pas été implémenté. Il faut absolument récupérer ce travail, ça fournira une base de départ. J’essaye de retrouver le document ce soir.

1 Like
#26

Ta liste traduit une vision de développeur : les champs sont rangés par type (chiffré /texte, obligatoire ou non, dépendant de l’activité ou non, etc).
Ce que j’essaie d’expliquer, c’est de rassembler les champs concernant le même thème ensembles.
Dès que j’ai accès à un pc je ferai une liste.

#27

Voici un screen du post initial de Projet UI - Ergonomie.

image.png965×222 19.2 KB

#28

Pour la sérénité des débats, merci d’éviter les pré-suppositions ad-hominem.

La logique de cette proposition est axée facilité d’utilisation :

  • Onglet 1 :
    • champs obligatoires
    • champs très souvent utilisés
    • champs stratégiques (conditions, et disable_comments)
  • Onglet 2 : champs utiles pour le partage d’informations
  • Onglet 3 : champs qui relèvent plus des statistiques, et qui sont/seront calculé en auto
  • Onglet 4 : champs pour les férus de fiches complètes
#29

L’optique onglets sera la moins dépaysante.

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

Je suis d’accord avec cela, mais du coup, je ne comprend pas très bien pourquoi tu met route_description dans le premier onglet : la description de l’iti est selon moi (:smile:) structurellement rattaché à la trace GPS, et aux autres champs décrivant les conditions terrain (neige, etc). A partir du moment ou l’utilisateur prend le temps de détailler les infos autour de l’iti, il doit avoir tous les champs dans le meme bloc non ?

Sinon, le champ description est le plus utilisé, et de loin, pourquoi le repousser si loin ?

Pour tes autres modifs, cela me va.

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

#34

Vraiment pas convaincu : de fait, rare sont les sorties avec une trace GPS. Ca met en tout premier plan un champ utilisé dans une minorité de sorties.

Pourquoi ? L’avoir systématiquement visible va rendre impossible d’avoir un ecran synthétique, vu la place enorme que ca prend.

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

Je comprend bien. Mais il faut aussi voir que cet usage (carte visible sur la rentrée de sortie) est celui de quelques très rares power users. L’immense majorité des contributeurs, une fois rajouté une trace GPS si il y en a une, ne vont pas utiliser la carte. (*)

Du coup, ca nous ferait faire une interface compliquée à faire, et qui ne serait pertinente pour les power-users qui auraient un écran très large. Ca me semble peu proportionné.

(*) PS : avec un écran 1900px, tu peux ouvrir deux fenetre différentes, et les splitter une à droite et une à gauche (touche windows + fleche sur windows).

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