Projet UI - Ergonomie

A pardon, j’avais interprété « en pleine largeur » dans le sens « une unique colonne ». Je vais voir ce que je peux faire.

  • Quand on change la géolocalisation d’un point de passage, il faudrait que les géolocalisations.des itis associés par défaut (localisation non spécifiée à la création) changent elles aussi:

@BorutK Ca va être très très compliqué. Il y a toujours une localisation sur les itinéraires, que ce soit sur la V6 ou la maquette.

Sur la V6, elle est calculée en fonction des points de passages associés. Du coup, quand tu modifies un point de passage, il ne se passe rien de spécial.

Puis, plus tard lorsque quelqu’un va modifier un itinéraire, le recalcul est fait. A noter qu’une modification de la localisation créé une version linguistique pour toute les langues existantes sur l’itinéraire. Ceci explique la grosse duplication des modifications dans les autres langues.

Sur la maquette, le seul calcul fait est à la création. Puis la localisation est laissé explicitement à la main des contributeurs.

En clair, Il n’y a pas de moyen sur de discerner les itinéraires qui n’ont pas été retouchés.

C’est un peu bâtard ces champs oui/non. Ils ont en fait trois états :

  • Oui : pas d’ambiguïté, oui, c’est oui
  • Non : ok, non, c’est non
  • null (correspond à rien de coché). Et la c’est la merde. Est-ce que null, ca veut dire non? Alors c’est comme la V6, puisque dans les deux cas, on n’affiche rien. Mais le souci, c’est qu’à la création, la valeur par défaut est null. Ce qui voudrait dire que si le contributeur ne touche pas à ce champ, alors on doit traduire par non, alors que ce n’est pas forcément le cas.

J’ai un peu envie pour ces champs d’adopter la logique suivante : trois choix possible :

  • Oui => on affiche Oui dans le document final
  • Non => on affiche Non dans le document final
  • Non connu/non pertinent => on affiche rien, car dans les deux cas, il n’y a rien à afficher.

A la création, c’est Non connu/non pertinent,et tant que personne ne vient modifier le champ, ca reste à Non connu/non pertinent. Il est possible de revenir à cet état si besoin.

Les champs qui auraient ce comportement serait :

  • Couverture hors gardiennage
  • gaz hors gardiennage
  • chauffage hors gardiennage
  • matelas hors gardiennage
  • remontées mécaniques
  • intervention des secours (c’est un champs des rapports d’incidents)

Et ceux qui ne l’auraient pas (ie c’est soit oui, soit non; et à la création, c’est non ET on n’affiche le chmap qu’en cas de oui) seraient :

  • parcours partiel
  • sortie en mobilité douce

Des avis ?

3 Likes

Bravo !

Je suis tout à fait pour cette solution (LA solution), pour tous les champs mentionnés.

C’est déjà implémenté comme ceci dans la V6 pour les champs que tu mentionnes.

Ah ouais. En effet. Petit moment de solitude…

:smiley:

@Bubu Y a t-il d’autres trucs de ce type à remarquer et que l’on n’a pas encore découvert ?

Ce serait bien de profiter de la grosse dispo de Charles, qui ne dure plus qu’une semaine, si je ne me trompe.

Peut être mais il y a déjà eu des remarques sur beaucoup de sujet, tous ceux qui ont testé ont balayé une grande partie des fonctionnalités.

S’il y a un truc à vérifier, c’est l’affichage/masquage des champs dans le formulaire d’édition d’un WP, en fonction du type de WP. Il y a déjà eu des vérifs, mais pas sur que ce fut exhaustif.

Il y a aussi une différence entre v6 et maquette dans les itinéraires : quand le champ « remontée mécanique » est à « non » ou « null », rien n’est affiché sur la V6, alors que sur la maquette c’est affiché quand c’est à « non ».
Je préfère quand ce n’est pas affiché quand c’est « non » car ça concerne 95% des itinéraires.

Une amélioration utile à faire (qui n’est pas sur la V6 mais était sur la V5) : à la création d’un itinéraire, il est utile que la durée en jour soit présélectionnée à 1 jour, car ça concerne la plupart des itinéraire, et souvent les contributeurs ne le renseigne pas, empêchant de pouvoir filtrer efficacement dessus (on perd trop d’itinéraires).

1 Like

Ah oui très juste. Je ne me sers pas de cette fonctionnalité de recherche pour cette raison exactement.

Ca c’est tout facile, je vais le faire en meme temps.

Pour corriger l’existant, il faut un passage de bot.

Livraison

  • :runner: champs « triple état » (oui/non/inconnu).
  • :runner: par défaut, la durée d’un iti est initialisée à 1 à la création d’un itinéraire.
4 Likes

C’est aussi le cas pour la relation Itinéraire_Sortie :
Si le géoréférencement de l’itinéraire a été modifié, les géoréférencements par défaut des sorties ne suivent pas. Le contributeur doit effacer la carto de sa sortie, puis enregistrer (« à vide ») afin que la carto de la sortie soit mise à jour.

Exemple (pas le même massif)
https://c2corg.github.io/c2c_ui/#/routes/1065114/fr/roblekov-dom-depuis-begunje-draga-
https://c2corg.github.io/c2c_ui/#/outings/1065121/fr/roblekov-dom-boucle-draga-roblek-prevala-draga

La V6 ne recalcule pas non plus. Mais par ailleurs, sur la carte, elle inclut les icônes des photos associées (si géoréférencées ?) :
https://www.camptocamp.org/outings/1065121/fr/roblekov-dom-boucle-draga-greatergreater-roblek-greatergreater-prevala-greatergreater-draga

Pour la carto, il y a un bouton pour agrandir la carte. Ce bouton ne fait pas juste agrandir la carte comme sur la V6, il la passe en plein écran.
C’est plus grand mais l’inconvénient est qu’on n’a plus accès à rien, même pas aux autres onglets du navigateur ni à l’interface de l’OS.
Donc quand on veut passer à un autre onglet, il faut quitter le mode plein écran (touche échap ou clcic sur un bouton sur la carte), puis changer d’onglet (clic, roulette ou raccourci clavier). Et quand on veut revenir sur la carte, elle est en petit format, et il faut cliquer de nouveau pour l’agrandir.
Ca fait beaucoup de clic ou touche du clavier en plus quand on navigue entre plusieurs onglets dont 2 ont une carte centrés sur des zones différentes qu’on souhaite regarder.
Alors que sur la V6, pour faire ça il suffit de jouer de la roulette de la souris sur la barre d’onglet (0 clic, 0 clavier, ou juste des raccourcis clavier).
L’idéal serait un 1er agrandissement en pleine page, en laissant visible la barre du haut et le menu de gauche, et un 2ème agrandissement possible en plein écran.

Dans un WP site d’escalade, il serait préférable de déplacer le champ texte « Restriction d’accès » entre le résumé et le champ Description.
Car actuellement on est obligé de copier le texte en tête de la description pour qu’il soit visible : Camptocamp.org developement builds
J’ai peut être eu un avis différent lors de la conception de la V6 (je ne suis pas allé vérifier), mais après qq années de pratique ça me semble mieux de donner de la visibilité au champ « restriction d’accès ». Même si ça entraine une baisse d’ergonomie pour les utilisateurs qui connaissent les restrictions d’un site (en place depuis 10 ans sans modification) mais qui viennent chercher une info précise dans la description.

1 Like

Je suis d’accord avec toi. Quand ces restrictions existent, il est important que le contenu soit très visible. Le point de passage que tu pointes est un bon exemple : si le bandeau est en dessous de la description, il y a peu de chance qu’il soit lu.

1 Like

Petit bémol, je ne suis pas chaud pour changer la place du champ en fonction du type de point de passage (complexité, tout ça…). En plus clair, ce champ peut signifier, selon le type de point de passage :

  • période d’accès
  • restriction d’accès
  • Heure d’ouverture
  • Période de gardennage

On remonte entre résumé et description, ou on laisse en bas ?

Perso, je suis d’avis pour remonter : dans les autres cas de figure, l’info est quand meme assez centrale.

4 Likes

sur la home affichage de « date non valide » dans la card de la création d’un itinéraire, mais en fait cette card a un lien vers une sortie ???
et je ne trouve pas la trace d’un nouvel itinéraire ?

un autre exemple avec une card au titre « a ajouté un nouvelle sortie » alors que cette fois ci ça pointe vers nouvel itinéraire :

Oula, c’est hyper bizarre, tu vois toujours le souci ?

Ca ressemble soit à un gros foirage coté maquette, soit des données non cohérentes de l’API

C’est bizarre un itinéraire qui s’appelle « sommet »…

J’ai regardé hier soir, mais je n’ai pas remarqué de bug sur le feed (depuis Firefox)…