Projet UI - Ergonomie de saisie d'une sortie

Ergonomie de la saisie d’une sortie

C’est bien sûr LE sujet crucial concernant les contributions, étant donné que la plupart des contributions sont des sorties, et que la plupart des nouveaux contributeurs commencent à contribuer via des sorties.

Le principe de base n’a pas changé depuis le début de c2c : trouver un compromis entre facilité de saisie, et facilité de consultation (après filtrage, donc sur des champs permettant ce filtrage).

Organisation général du formulaire

Champs

Les évolutions de c2c ont amené tout un tas de champs dans les sorties.
Pour ne pas noyer le contributeur dans ces champs, l’idée est de les afficher progressivement au fur et à mesure de l’avancée dans la saisie. Et on essaie autant que possible de pré-remplir certains champs.
Pour cela, on impose un ordre de saisie, pour que le pré-remplissage et l’affichage des champs selon les activités soient le plus efficaces et pertinents possible. Le but n’est pas d’embêter le contributeur, c’est bien de lui faciliter la saisie en réduisant le nb de champs affichés et à remplir pour son cas particulier.

Je pense qu’il est préférable de supprimer les onglets, mais de mettre des pictos ou un menu visible en permanence permettant de se balader rapidement d’une section du formulaire à l’autre.

Par ailleurs, on essaiera autant que possible de placer les champs du même thème ensemble, avec les champs chiffrés au dessus du champs texte, pour inciter à saisir le champ chiffré au lieu d’écrire la même chose à la main dans le champ texte.

Carte

Il est bien utile d’avoir la carte tout le temps visible. Sur desktop, ce serait dans la partie droite (ou gauche ?), avec des boutons pour agrandir en plein largeur, ou au contraire la masquer complètement pour laisser la place au reste du formulaire (utile sur desktop petit écran). Quand la carte et les champs sont affichés, il est utile de pouvoir choisir la largeur de la carte (et implicitement des champs) pour un réglage fin selon l’écran ou pour d’autres raisons.
Sur mobile, ce serait un bouton tout le temps visible qui permettrait d’afficher/masquer la carte par dessus le formulaire (comme dans le filtre du topoguide).

La carte comporte un bouton « centrer sur ma position » qui centre la carte sur sa position avec une étendue de 20km à la ronde par exemple.

On peut dessiner une trace sur la carte.
L’idéal serait de pouvoir ajouter des altitudes selon un modèle de terrain, et aussi à la main.
Et aussi de pouvoir ajouter une date/heure à certains points, les points intermédiaires étant mise à jour linéairement

La carte comporte un bouton « réinitialiser », qui annule les modifications faites depuis l’ouverture de la page (avec une demande de confirmation).

1. Choix de l’activité et des itinéraires

La 1ere étape consiste à choisir l’activité et les itinéraires associés à la sortie.
Il est préférable de les choisir ensemble, car le choix de l’activité peut faciliter le choix de l’itinéraire, ou l’inverse. Du coup le formulaire ne peut pas imposer un ordre de saisie pour ces 2 infos.

Tant qu’aucune activité n’est sélectionnée, ou qu’aucun itinéraire n’est associé, tous les autres champs sont masqués. C’est comme cela qu’on impose un ordre de saisie.
Cet ordre ne convient pas à une saisie tout au long de la sortie (choix de l’itinéraire à la fin, car on ne sait pas forcément d’avance où on va). Mais la saisie au cours de la sortie est réservée à l’appli c2c. On pourra quand même faire une saisie au cours de la sortie avec c2c sur navigateur en choisissant un itinéraire +/- bidon pour avoir accès aux autres champs.

Quand on arrive sur le formulaire depuis le bouton « ajouter une sortie » en haut de page, aucune itinéraire n’est associé.
On a la carte à droite ou à gauche, et des champs et boutons de l’autre côté.

1.1. Ajouter une trace GPS

1.1.1 Bouton

Il ne faut pas afficher ce bouton avec la carte (ne pas l’afficher tout le temps), car l’ajout ou le changement de trace GPS a de grosses implications pour tout un tas de champs, et donc il ne faut pas pourvoir faire ça à la légère. Et surtout il faut bien montrer qu’il faut l’ajouter en premier.
D’ailleurs comme la trace GPS n’est pas obligatoire, il faudrait peut être ajouter une phrase pour inciter à la saisir en premier, au lieu de remplir en premier tout un tas de champs à la main, alors que ces champs auraient pu être remplis automatiquement d’après la trace si elle avaient été saisie en premier.

1.1.2 Nettoyage de la trace GPS

Il serait pertinent qu’au chargement de la trace GPS, il y ait un outil éliminant les points abérents, et lissant les altitudes, avec des seuils réglables (distance max entre 2 points pour éliminer les points abérents, etc).

1.1.3 Données extraites de la trace GPS

Si on ajoute une trace GPS, ça extrait des données et ça remplit des champs avec ces données, si les champs sont vides.
Dans ce cas, à coté de ces champs (ou d’une autre façon), il est indiqué « d’après la trace GPS ». Dès qu’on modifie un de ces champs, cette indication disparait pour le champ modifié.
On pourrait aussi ajouter un bouton « Forcer la mise à jour des données », qui écraserait les données déjà existantes.
Lors d’une modification d’une sortie existante, on n’affiche rien (on pourrait refaire l’extraction des infos depuis la trace et les comparer aux infos provenant de la base pour afficher l’indication « d’après la trace GPS » quand les infos sont identiques, mais ce n’est pas indispensable).

Si on modifie la trace GPS (suppression de points abérents, etc), un bouton « Mettre à jour les données issues de la trace » apparait à côté de « Ajouter une trace GPS ». En cliquant dessus, ça met à jour les champs qui sont encore considérés comme provenant de la trace GPS initiale, mais pas les champs qu’on a déjà modifié à la main.

Les champs remplis d’après la trace GPS (même s’ils sont encore cachés) :

  • Date de la sortie si la trace est horodatée (début et fin si les dates des points de la trace est sur plusieurs jours)
  • Champ texte « horaire », s’il est vide (en gérant un horaire par jour si la trace est sur plusieurs jours).
  • Altitudes minimale et maximale
  • Dénivelés montée et descente
  • Longueur totale
  • Altitude de l’accès routier : altitude du 1er point de la trace.

Par ailleurs, ça recentre la carte autour de la trace GPS.

Si on commence par ajouter une trace GPS, tous ces champs sont encore cachés (sur la maquette actuelle ils sont dans d’autres onglets, ça revient au même). Ce n’est pas grave, l’utilisateur pourra corriger ces champs ensuite, qu’il repérera facilement grâce à l’indication « d’après la trace GPS ».
Par contre ça suppose que la trace GPS est assez clean, et qu’on ne souhaite pas vérifier immédiatement les données extraites pour faire plusieurs itérations en corrigeant la trace GPS sur un outil externe.

1.2. Choix de l’activité

Sous le bouton « Ajouter une trace GPS », il y a les boutons de choix des activités.
Avec l’indication suivante : « Si vous ne choisissez pas d’activité, elle vous sera proposée d’après l’activité de l’itinéraire ».

1.3. Choix de l’itinéraire

Quand on arrive sur le formulaire depuis un itinéraire, cet itinéraire est déjà associé dans le formulaire.
Sinon, il faut en associé au moins un. Et on peut en ajouter autant qu’on veut.

1.3.1. Recherche des itinéraires

Sous les boutons de choix des activité, il y a l’outil d’association des itinéraires. En dessous, il y a la liste des itinéraires associés, sous forme de liste et non de card (ou alors des cards toutes plates).

A droite de l’outil, il y a 3 cases à cocher :

  1. limiter les résultats aux activités sélectionnées
    Si on a sélectionné une activité, cette case est cochée automatiquement. Sinon, elle est inactive et grisée.
  • limiter les résultats à la carte visible
    Si on a bougé la carte (en la déplaçant, en changeant le zoom, ou en utilisant le bouton « centrer sur ma position »), cette case est cochée automatiquement.

  • limiter les résultats proches de la trace GPS
    Si on a importé ou dessiné une trace GPS, cette case est cochée automatiquement. Sinon, elle est inactive et grisée.

Ces cases permettent d’ajouter des critères de recherche dans l’outil d’association.
Si la case 2 ou 3 est cochée, à droite de ces cases apparait un bouton « rechercher sans mot clé », qui permet de filtrer sans donner de mot clé.

Si on vient d’importer une trace GPS, la recherche sans mot clé est automatiquement lancée.
Si on saisi un mot clé, la recherche avec mot clé (et avec les critères selon les cases cochées) est lancée.
Si on (dé)coche une case, la recherche est automatiquement relancée, sans effacer les mot clés.

Si aucune activité n’est sélectionnée, le tri des résultats change selon la saison et l’hémisphère où on se trouve (celui-ci étant déterminé par la trace GPS, où par le recentrage de la carte sur sa position, ou par défaut mis à hémisphère N).
Dans l’hémisphère N :

  • Du 22 octobre au 21 mai : les activités ski, raquette, cascade et alpi neige sont mises en tête des résultats.
  • Du 22 mai au 21 octobre : les activité ski, raquette et cascade sont mises en queue des résultats (et non, ce n’est pas symétrique).

Les dates sont inversés dans l’hémisphère S.

1.3.2. Sélection d’un itinéraire

Quand on sélectionne un itinéraire parmi les résultats, des vérifications sont faites :

  • Si aucune activité n’est sélectionnée mais que l’itinéraire comporte plusieurs activités, un popup demande quelle activité choisir. Ou alors un autre système. Le but étant d’éviter d’avoir une sortie rando pédestre + raquette + ski juste à cause de la copie des activités de l’itinéraire.
  • Si on a sélectionné une ou plusieurs activités, dont aucune n’est présente dans l’itinéraire, un popup (ou autre chose) demande ou averti qu’aucun activité de l’itinéraire ne correspond aux activités sélectionnées. Ceci ne peut avoir lieu que si la case 1 n’est pas sélectionnée.
1.3.3 Données extraites des itinéraires

Quand on associe un itinéraire, ça extrait des données et ça remplit des champs avec ces données, si les champs sont vides.
Dans ce cas, à coté de ces champs (ou d’une autre façon), il est indiqué « d’après l’itinéraire ». Dès qu’on modifie un de ces champs, cette indication disparait pour le champ modifié.
Lors d’une modification d’une sortie existante, on n’affiche rien (on pourrait refaire l’extraction des infos depuis la trace et les comparer aux infos provenant de la base pour afficher l’indication « d’après l’itinéraire » quand les infos sont identiques, mais ce n’est pas indispensable).

Si on modifie la liste des itinéraires associés (ajout/suppression), un bouton « Mettre à jour les données » apparait en haut de la liste. En cliquant dessus, ça met à jour les champs qui sont encore considérés comme provenant des itinéraires, mais pas les champs qu’on a déjà modifié à la main.

Les champs remplis d’après les itinéraires (même s’ils sont encore cachés) :

  • Activités (voir 1.3.2)
  • Altitudes minimale et maximale. Si plusieurs itinéraires sont associés, ça prend le min des altitudes mini, et le max des altitudes max (? à discuter).
  • Dénivelés montée, descente, et des difficultés. Si plusieurs itinéraires sont associés, ça prend le max de chacun des dénivs (? à discuter).
  • Cotations. Si plusieurs itinéraires sont associés, ça prend le max de chacune des cotations.
  • Altitude de l’accès routier : copie de l’altitude minimale
  • Titre de la sortie, en copiant le titre de l’itinéraire. Si plusieurs itinéraires sont associés, ça prend le titre de l’itinéraire comportant l’altitude maximale la plus élevé, et si des altitudes sont égales, le 1er associé (ou alors celui avec la cotation la plus élevée, etc).

Sur la carte sont affichés tous les WP associés aux itinéraires associés, ainsi que le point de chaque itinéraire (correspondant à l’attaque de la voie pour l’itinéraire décrivant une voie).
Si aucune trace GPS n’a été importée ou dessinée, la carte est recentrée sur l’ensemble de ces WP.

2. Itinéraire emprunté, participants, titre, date

Une fois qu’un itinéraire est sélectionné, on a la garantie qu’au moins une activité est renseignée, et on peut passer à l’étape suivante.

Les champs suivants s’affichent :

  • La case « parcours partiel » est mise à droite de la liste des itinéraires associés, ou en dessous.
  • Le champ texte « Précision sur l’itinéraire emprunté » s’affiche sous cette case (donc à droite de la liste des itinéraires si la case s’y trouve aussi), avec une hauteur de 2 lignes sur desktop, qui s’agrandit à 4 ou 5 lignes si on met du texte dedans. L’idée est de bien faire comprendre que ce champ doit être laissé vide si on a associé un seul itinéraire qui ne comporte pas de variante, et qu’on l’a suivi.
  • En dessous de la liste des itinéraires, l’outil d’association des participants, avec la liste des participants. Quand on clique dans la zone de saisie de mot clé, ça affiche la liste de ses amis.
  • Puis le champ texte « participants non inscrits ».
  • Puis le champ « Nombre de participants ». Il est mis à 1 par défaut, et in/dé-crémenté d’1 à chaque a/di-ssociation de participants.
  • En dessous, le champ « Titre de la sortie ».
  • En dessous, les champs date de début et fin.
  • En dessous, le champ texte « Horaires / durée ».

Une fois que le titre et la date sont renseignés, tous les champs obligatoires sont renseignés.
Tous les autres champs sont alors affichés (en tenant compte des activités sélectionnées).
Si on crée une sortie à partir de la page d’un itinéraire, ces 2 premières étapes n’imposent que de choisir la date de la sortie, tout le reste est automatique.

Pour les champs suivants, on n’impose plus un ordre de saisie, seul l’ordre d’affichage des champs incite à en renseigner certains avant d’autres.

3. Dénivelé et cotations

Section rassemblant les champs chiffrés dépendant de l’itinéraire emprunté, mais indépendant des conditions :

  • Altitude min et max
  • Dénivelés
  • Cotations

4. Accès routier / TC

  • Altitude du parking
  • Conditions de l’accès routier
  • Remontées mécaniques
  • Sortie en mobilité douce
  • Champ texte « Commentaire sur l’accès routier »

5. Conditions

Section rassemblant tous les champs dépendant des conditions

5.1. Altitude de chaussage / déchaussage

Si l’altitude du parking est renseignée, on la prend en référence. Sinon, si l’altitude minimale est renseignée, on la prend en référence.
Si l’activité sélectionnée est le ski ou la raquette, une case à cocher est affichée au dessus des champs « Altitude de chaussage / déchaussage », avec l’intitulé : « Chaussage / déchaussage au départ (xxxx m) », avec xxxx = altitude de référence définie au-dessus.

  • Si la case est cochée, l’altitude de référence est copiée dans les 2 champs Altitude de chaussage / déchaussage, et ces champs sont masqués.
    De plus, si la case est cochée, et si l’altitude du parking n’est pas renseignée, l’altitude de référence est copiée dans l’altitude du parking.
    Si l’altitude du parking est modifiée ultérieurement, les altitudes de chaussage / déchaussage seront mis à jour.

  • Si la case n’est pas cochée, les champs « Altitude de chaussage / déchaussage » restent visibles.

5.2 Champs chiffrés des conditions

En dessous sont affichés les champs « liste à choix » :

  • Quantité de neige
  • Qualité de neige
  • Etat du glacier
  • Evaluation des conditions
  • Fréquentation

5.3 Champs texte des conditions

En dessous sont affichés les champs texte :

  • Météo
  • Enneigement par zone
  • Conditions : l’intitulé change selon l’activité. Si une activité grimpante est sélectionné, c’est « Conditions, équipement et qualité du rocher »

5.4 Avalanches

En dessous sont affichés les champs :

  • Signes d’avalanche
  • Observations relatives aux avalanches : ce champ est masqué tant qu’aucune option de « Signes d’avalanche » n’est sélectionnée.

6. Commentaires

Section rassemblant les champs concernant les commentaires persos :

  • Champ texte « Commentaires ».
  • Case à cocher « Désactiver les commentaires »

Pour le champ texte « commentaires », quand il y a plusieurs participants inscrits, il serait affiché autant de zones de texte que de participants inscrits, avec en intitulé de chaque champ le pseudo topoguide de chaque participant. A l’enregistrement, ça concatène tout, avec en titre de chaque section non vide : ### Pseudo_topoguide
Mais lors d’une modification d’une sortie, il faudrait redispatcher les différentes sections dans les champs de chaque participant, pas forcément simple.

Conclusion

On a demandé des remarques sur l’ergonomie, je fais des remarques sur l’ergonomie :slight_smile:
Et il y a encore les itinéraires.

C’est compliqué, mais c’est normal. Si on veut que ce soit simple pour l’utilisateur, il faut que ce soit l’UI qui gère la complexité. Et ce post décrit ce que fait l’UI, pas ce que fait l’utilisateur.
Pour l’utilisateur c’est très simple, en qq clics il peut saisir une sortie avec pas mal d’infos sans saisir le moindre texte.

2 Likes

Est-il possible d’extraire de ta proposition la mise en page,qui pourrait être faite rapidement, des traitements automatiques qui pourront prendre plus de temps à être implémenter?
Si on doit tout faire d’un bloc, je crains qu’on attende trop de temps et que ce ne soit jamais fini. Il faut arriver à découper le travail en morceaux.

J’ai extrait des trucs (au sujet de la carte) et les ai ajoutés aux wikis.

Le idées de Bubu sont visionnaires, ça va mettre du temps, mais c’est beau.

@bubu : et également mettre de coté les fonctionnalités non triviales qui ne sont pas dans la v6 ? Pour le moment, il faut s’en tenir à :

  • quels onglets, dans quel ordre
  • quels champs, dans quel ordre

On peut toujours faire une liste au père noel pour l’après projet, mais si on veut que ce dernier délivre dans les temps, il faut s’en tenir à la roadmap. Je rappelle que sans spec claire et réalisable dans les temps, je reproduis la V6, et repousse toute modification à l’après projet.

Sur le fond, je n’ai pas encore lu le texte de Bubu, je le ferais ce soir. Mais en avant de rentrer dans les détails, un point me semble important, pour ne pas dire vital :

Sur le premier onglet doit se trouver les champs obligatoires, ainsi que quelques (peu) champs choisis en fonction de leurs fréquences d’utilisation / importance pour c2c (je pense au champ historique).

Sur les autres onglets, vu le nombre de champ, nous n’arriverons de toute façon pas à faire des formulaires idéaux. Mais ce premier onglet est à mon sens celui sur lequel nous devons porter le plus d’attention.

Je supprimerait les o.glets pour les remplacer par des liens internes vers des sections.
Ça permet de saisir les infos sans tenir compte des sections, tout en permettant de revenir facilement au début d’une section.
Je ferai la liste des champs dans l’ordre.

Personnellement pas convaincu : ca fera une unique page immense qui va en rebuter plus d’un.

Par contre, avoir deux (ou trois onglets), avec en premier l’essentiel, et dans le, ou les deux, suivants le reste, je suis pour.

Pour info, voici la structure actuelle*

  • niveau 1 = onglet, niveau 2 = ligne, niveau 3 si plusieurs champ par ligne
  • Les champs avec un :exclamation: sont visibles dans toutes les sorties, peut importe l’activités.
  • Les champs obligatoire sont indiqués par :star:

  1. general informations
    • fields.title :exclamation: :star:
    • Dates
      • fields.date_start :exclamation: :star:
      • fields.date_end
    • fields.description :exclamation:
    • fields.users :exclamation: :star:
    • fields.routes :exclamation: :star:
  • GPS Track
    • map :exclamation:
  • detailed informations
    • fields.activities :exclamation: :star:
    • fields.partial_trip :exclamation:
    • fields.length_total :exclamation:
    • Elevation
      • fields.elevation_min :exclamation:
      • fields.elevation_max :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
  • weather and conditions
    • condition_rating
      • fields.condition_rating :exclamation:
      • fields.glacier_rating
    • 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:
    • fields.conditions_levels
  • access
    • 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:
  • comments
    • participants
      • fields.participant_count :exclamation:
      • fields.participants :exclamation:
    • fields.route_description :exclamation:
    • fields.timing :exclamation:
    • fields.disable_comments :exclamation:

la vision de Bubu me parait pour autant meilleure. Certains champs ne sont en effet pas obligatoires, mais sont fortement liés à des champs quasi obligatoires. par exemple, la description de l’itinéraire a du sens en lien avec les conditions, il ne faut pas le reléguer à la fin (sinon, ça fait doublon).
Pour moi, il faut plutôt partir de la (très bonne) proposition de Bubu, et voir comment suggérer à l’auteur les champs importants en jouant sur le design.

1 Like

Suis-je autorisé pour dire que je suis aussi rebuté par les onglets et que je préférai de loin remplir mes sorties sur smartphone (défilement continu du formulaire) ?

T’as le droit. D’ailleurs, sur smartphone, y’a plus d’onglet, mais un gros formulaire tout vertical. J’ai livré ça il y a quelques semaines.

1 Like

Déjà, au début de la saisie le formulaire est court étant donné que la plupart des champs sont masqués.
Ensuite, avec les onglet c’est super chiant de devoir utiliser la souris pour revenir au champ précédent pour corriger un truc, et qui se trouve à la fin de l’onglet precedent.
Alors que si on peut défiler en continu, il suffit de remonter un peu (éventuellement avec la roulette de la souris, mais sans avoir à la deplacer).
Avec un menu vers des sections, qui peut avoir le même design que les titres d’ongles, on a l’avantage des 2.

Je répète : je ne vais pas avoir le temps d’implémenter un truc trop compliqué. Ce qui veut dire qu’au début, quoi que tu fera, tu auras les 31 champs visibles ici, ce qui fait pas loin de 4 pages écrans sur un ordi normal.

Edit : J’ai mis dans mon message ci dessus des :exclamation: pour indiquer les champs toujours visibles. Le post est en wiki pour que vous récuperer le code, et faire des propositions.

Alors je vois 2 options :

  • On maintient le formulaire sur 3 onglets avec son ordre actuel
  • On commence par les 31 champs sur une page et qu’on améliore ensuite sur la base des recommandations de Bubu.

Mais je ne suis pas convaincu par la proposition actuelle sur la maquette de la nouvelle UI

une remarque d’ordre générale concernant l’interface de saisie des sortie : à moins que l’on soit capable de converger rapidement vers une nouvelle interface de saisie, je pense qu’il vaut mieux livrer une version quasi identique à la V6.
En tout cas, il faudrait éviter de livrer une version intermédiaire que nous serions amenés à réorganiser une fois encore, ça risquerait de perdre un peu plus les contributeurs…

Même s’il y a des idées intéressantes dans la version proposée dans la nouvelle UI, je n’en suis pas trop fan, ça fait beaucoup de changements, pour un gain minime en ergo

Une autre manière de dire les choses : avant d’introduire un changement, il faut aussi se poser la question si le gain en ergonomie dépasse la « nuisance » lié au changement…

Par rapport à la proposition de bubu, il y a beaucoup de bonnes idées mais je trouve qu’elle privilégie un peu trop la logique d’un remplissage exhaustif des champs et le remplissage automatique imposant une certaine chronologie qui se fait au détriment de l’importance de certains.

Typiquement je mettrais les conditions en 3 (et dans les conditions les avalanches en 3.1)

Edit :

je n’avais pas vu la réponse de Charles ci dessus, donc je pense qu’il faut rester sur une interface quasi identique à la V6. Et ouvrir un chantier de réflexion sur une interface pus ergonomique pour la suite

1 Like

+10

+1 aussi

J’abonde. Il y a clairement une logique sous-jacente sur laquelle il faut que nous nous accordions, sans quoi le débat sera stérile : Faut-il privilégier

  • l’incitation à remplir le plus de champs, quitte à avoir un formulaire complexe ?
  • la facilité de saisie, quitte à pénaliser certains champs ?

Pour préciser :

  • Changer l’ordre, et la place des champs, le nombre d’onglet : facile à faire, je prend si on se met d’accord :thumbsup:
  • passer d’un affichage onglet à une liste verticale : facile à faire aussi, également si on est d’accord :thumbsup:
  • avoir des champs qui s’affiche conditionnellement selon l’activité, comme sur la V6 : done :white_check_mark:
  • avoir des champs qui se complètent automaiquement à partir de l’itinéraire, comme sur la v6 : done :white_check_mark:
  • Le reste : on oublie pour le moment. :frowning:

pour moi s’il y avait un truc à ajouter : faciliter l’association des iti par exemple en filtrant sur l’activité si elle est sélectionnée.

L’outil d’association du formulaire utilise la recherche simple qui ne travaille que sur du texte. C’est la même moulinette que celle qui est en haut de la page d’accueil. Il faut soit mettre à la place la recherche avancée (i.e. celle du topoguide) et faire des modifs pour simplifier, soit faire une modif de la recherche simple dans l’API pour qu’elle prenne en compte l’activité. Dans les 2 cas, ce n’est pas une opération simple à implémenter et à tester. Ce n’est pas insurmontable non plus.

+1 @Miko, ce point est listé en post-projet

Allez, je me lance à une tentative de réorg de champ sans présupposer si ca doit être des onglets, ou tout dans une page verticale :

  • :exclamation: champs visibles dans toutes les sorties, peut importe l’activité.
  • :star: champ obligatoire

  1. general informations : données obligatoire et courantes
    • fields.title :exclamation: :star:
    • Dates
      • fields.date_start :exclamation: :star:
      • fields.date_end
    • fields.activities :exclamation: :star:
    • condition_rating
      • fields.condition_rating :exclamation:
      • fields.glacier_rating
    • participants
      • fields.participant_count :exclamation:
      • fields.participants :exclamation:
    • fields.users :exclamation: :star:
    • fields.routes :exclamation: :star:
    • fields.description :exclamation:
    • fields.disable_comments :exclamation:
  • Terrain informations : informations autour du terrain et des conditions
    • map :exclamation:
    • fields.conditions_levels
    • fields.elevation_up_snow
    • fields.elevation_down_snow
    • Snow
      • fields.snow_quantity
      • fields.snow_quality
    • fields.route_description :exclamation:
    • fields.conditions :exclamation:
    • fields.avalanches
    • fields.avalanche_signs
  • Figures and ratings : données plutot numériques/cotations
    • fields.partial_trip :exclamation:
    • fields.length_total :exclamation:
    • Elevation
      • fields.elevation_min :exclamation:
      • fields.elevation_max :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
  • Miscs : les autres champs
    • fields.weather :exclamation:
    • 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: