Que signifient les 2 picto (point d’exclamation et étoile) ?
Projet UI - Ergonomie de saisie d'une sortie
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.
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.
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.
(message supprimé par son auteur, sera supprimé automatiquement dans 100 heures à moins qu’il ne soit signalé)
L’optique onglets sera la moins dépaysante.
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
- condition_rating
- participants
- fields.description
- fields.disable_comments
- fields.partial_trip (c’est important !)
- fields.route_description
- onglet 2
- condition_rating
- _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 »
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
=> toujours visible , à droite ou à gauche - sur mobile, un bouton toujours visible permet de basculer entre carte et formulaire
-
Itinéraire, activité, date, participants
- bouton Ajouter une trace GPS
-
fields.activities
-
fields.routes
-
fields.partial_trip
-
fields.route_description
-
fields.users
- participants
-
fields.participant_count
-
fields.participants
-
-
fields.title
- Dates
-
fields.date_start
fields.date_end
-
-
fields.timing
-
Altitudes, dénivelés, cotations
- Elevation
-
fields.elevation_min
-
fields.elevation_max
-
-
fields.length_total
- height_diff
-
fields.height_diff_up
-
fields.height_diff_down
-
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
- Elevation
-
Accès routier / TC
- Ligne 1
-
fields.elevation_access
-
fields.access_condition
-
- Ligne 2
-
fields.lift_status
-
fields.public_transport
-
-
fields.access_comment
- Ligne 1
-
Conditions
fields.elevation_up_snow
fields.elevation_down_snow
- Snow
fields.snow_quantity
fields.snow_quality
fields.glacier_rating
- Condition rating
-
fields.condition_rating
-
fields.frequentation
-
-
fields.weather
fields.conditions_levels
-
fields.conditions
fields.avalanche_signs
fields.avalanches
-
fields.hut_status
-
fields.hut_comment
-
Commentaires
-
fields.description
-
fields.disable_comments
-
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.
… 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 ».
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.
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 ».
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
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.
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
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 !
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.
Hola,
aucun lien, mais merci pour cette astuce, je connaissais pas et c’est top
Petit lien : et la carte qui s’ouvre dans une pop up ? aussi difficile ?
Carine