Modif de site -> modif d'horaires -> pas de diff d'horaires

publié le 4 octobre 2026, mis à jour 4 octobre 2026

laem

Je suspecte un conflit entre le setDiff ? À voir.

n4n5
Non c'est que le openning_hours a son propre bouton valider qui ne trigger par le computeDiff

Par ailleurs, je trouve le comportement de l'edition assez louche
1. j'edit une place
2. j'edit le site
3. je valide => un changement apparait
4. je clique sur la description => le changement apparait
5. j'edit => le changement disparait
6. je valide => changements apparaissent
Pour moi il faudrait au choix
- changer le comportement du point 5. pour que les changements apparaissent tout le temps
- changer le comportement du point 4. pour les changements apparaissent uniquement avant l'envoi
pmiossec
@n4n5 wrote in https://codeberg.org/cartes/web/issues/2710#issuecomment-22099021:

Par ailleurs, je trouve le comportement de l'edition assez louche

De ce que je me rappelle, je crois même que c'est pire que çà. St tu enregistres les changements et que après tu en fais un autre car tu avais oublié, il affiche tous les précédents changements (et j'ai pas investigué si ils sont aussi encore renvoyés)
etienneJr
Dans sa présentation, le gars de MapComplete discutait des frictions inutiles. Je me suis dit que ce formulaire, en agrégeant toutes les modifs en 1 changeset, rentre dans cette catégorie. Ca n'a de sens que pour le spécialiste d'OSM. Pour le grand public, ça parait plus normal d'avoir une UX : je veux faire une modif -> je choisis laquelle -> je rentre la donnée -> j'envoie. Alors oui, si l'utilisateur changer le tel puis le siteweb, ça fera 2 changeset, mais est-ce que c'est si grave ?
n4n5
@etienneJr wrote in https://codeberg.org/cartes/web/issues/2710#issuecomment-22140154:

Alors oui, si l'utilisateur change le tel puis le siteweb, ça fera 2 changeset, mais est-ce que c'est si grave ?

Je ne suis pas expert OSM, donc je ne sais pas si c'est grave. Moi je parlais juste d'un point de vue UI/ Experience utilisateur, je trouve que c'est améliorable

. Ca n'a de sens que pour le spécialiste d'OSM.

Hum, pour le coup, je dirais que le spécialiste OSM utilise un autre éditeur plutôt que cartes.app grand public non? Car techniquement, je suppose que le spécialiste OSM se retrouvera rapidement limité car on a que 4-5 champs modifiable !

Je ne sais pas si l'UI de "modification rapide" est voué a être augmenté (plus de champs) ou non?
pmiossec
@etienneJr wrote in https://codeberg.org/cartes/web/issues/2710#issuecomment-22140154:

je veux faire une modif -> je choisis laquelle -> je rentre la donnée -> j'envoie

Oui et on pourrait afficher le diff à la volée. Ça aurait aussi le mérite de permettre de générer un message de changeset ayant plus de sens...
etienneJr
@n4n5 wrote in https://codeberg.org/cartes/web/issues/2710#issuecomment-22141873:

Je ne suis pas expert OSM, donc je ne sais pas si c'est grave.

En fait en y repensant, quand on consulte l'historique des modifs sur un objet, c'est quand même bien bien plus pratique quand il y a peu de changesets. Donc (je change d'avis) si on peut rester sur le principe de tout envoyer dans le même changeset, ça serait quand même mieux.

Je propose donc de légèrement modifier l'UX comme ceci :
- tu veux faire une modif, je te propose la liste des modifs qu'on gère, tu choisis celle que tu veux
  - bouton annuler pour revenir en arrière
  - bouton valider qui envoie sur une page avec un choix :
    
    envoyer maintenant qui poste le changeset
    
    ajouter une modif supplémentaire qui renvoie sur la liste des modifs qu'on gère.
vous voyez l'idée ?
etienneJr
@pmiossec wrote in https://codeberg.org/cartes/web/issues/2710#issuecomment-22144300:

Oui et on pourrait afficher le diff à la volée.

le gars de mapcomplete a raconté comment il a fait, j'ai trouvé ça bien, mais pas faisable facilement chez nous : lors des x premières utilisations, il masque la complexité d'osm (les tags, les changesets, ...), puis il les fait apparaitre petit à petit pour former petit à petit l'utilisateur et lui donner envie d'aller explorer osm plus finement.
waterced
Les boutons "envoyer maintenant" et "ajouter une modif supplémentaire" rajoutent un peu de friction, non ?

Le wiki mentionne: "A changeset may be closed either explicitly (see the documentation for the editor you are using), or automatically (after a period of inactivity, currently one hour)."

Serait-il possible/souhaitable:
- ouvrir le changeset
- envoyer les modifs au fur et à mesure que chaque élément est modifié
- laisser un bouton temporaire "annuler mes modifs" tant que le changeset est ouvert
- fermer le changeset lors de la fermeture de la fiche lieux / après minutes sans nouvelle modification
- si l'utilisateur quitte l'appli avant la fermeture du changeset celle-ci aura de toute façon lieu côté OSM après 1h d'inactivité
etienneJr
@waterced wrote in https://codeberg.org/cartes/web/issues/2710#issuecomment-22157989:

automatically (after a period of inactivity, currently one hour

ah intéressant, je savais qu'on pouvait pousser des choses petit à petit dans un changeset, mais je ne savais pas qu'il serait fermé automatiquement après 1h. Néanmoins, le fonctionnement que tu proposes m'inquiète un peu ... je préfère que ça soit une vraie action de l'utilisateur qui ferme le changeset. Sinon ya trop de risque qu'il y ait des modifs non voulues qui soient poussées.

fermer le changeset lors de la fermeture de la fiche lieux

typiquement, j'ai commencé à modifier les horaires, mais je m'y perds, alors je laisse tomber, et je ferme la fiche lieu (dans ma tête, le bouton [X] qui ferme la fiche et aussi un bouton annuler. Idem si je ferme la fenêtre de mon navigateur)
laem
À mon avis c'est assez peu naturel pour un utilisateur grand public de valider les changements section par section plutôt qu'en une fois.

D'autre part, je pense aussi que le "diff", qui est en fait une étape de vérification avant d'envoyer le truc en ligne, est nécessaire. Pour se relire. L'actuel est évidemment très brut, par manque de temps pour mieux faire, mais ça me semble important de garder ça. Au pire, la personne l'ignore et clique valider. Au mieux elle trouve des fautes.

J'ai l'impression que l'expérience actuelle mais sans bugs serait quand même plutôt intuitive.
etienneJr
on converge ! je corrige ma proposition :
- tu veux faire une modif, tu cliques sur le bouton "modifier cette fiche"
- je te propose la liste des modifs qu'on gère, sous le message "choisis ce que tu veux modifier"
- tu choisis celle que tu veux en cliquant dessus, je t'affiche
  - le formulaire
  - un bouton annuler pour revenir en arrière
  - un bouton valider qui t'affiche :
    
    le diff + un bouton envoyer maintenant qui poste le changeset
    
    la même listes des modifs qu'on gère, mais cette fois-ci sous le message "ajouter une autre modif?"
    
    je peux mettre en forme cette liste pour afficher un peu différemment les items qui sont déjà dans le diff
en pratique c'est quasiment comme aujourd'hui, sauf qu'on n'affiche pas en même temps le diff et le formulaire.

n4n5

@etienneJr wrote in https://codeberg.org/cartes/web/issues/2710#issuecomment-22159828:

on converge ! je corrige ma proposition :

* tu veux faire une modif, tu cliques sur le bouton "modifier cette fiche"

* je te propose la liste des modifs qu'on gère, sous le message "choisis ce que tu veux modifier"

* tu choisis celle que tu veux en cliquant dessus, je t'affiche
  
  * le formulaire
  * un bouton `annuler` pour revenir en arrière
  * un bouton `valider` qui t'affiche :
    
    * le diff + un bouton `envoyer maintenant` qui poste le changeset
    * la même listes des modifs qu'on gère, mais cette fois-ci sous le message "ajouter une autre modif?"
      
      * je peux mettre en forme cette liste pour afficher un peu différemment les items qui sont déjà dans le diff

en pratique c'est quasiment comme aujourd'hui, sauf qu'on n'affiche pas en même temps le diff et le formulaire.

Je met un +1 sur le fait d'avoir un changement dans les boutons. Actuellement on a "Valider" puis "Enregistrer"

Je pense qu'il faudrait "Valider" puis "Envoyer" ou "Valider" puis "Envoyer le changement" ou encore "Valider cette modification" puis "Envoyer le changement" (pour être bien clair)

laem

un bouton valider qui t'affiche :

le diff + un bouton envoyer maintenant qui poste le changeset

La crainte que j'ai dans ton scénario c'est que la personne clique sur envoyer par réflexe avant de se rendre compte qu'il y avait encore des choses à faire ?

je te propose la liste des modifs qu'on gère, sous le message "choisis ce que tu veux modifier"

Est-ce que ce n'est pas un design qui serait moins intuitifs que des onglets ? Je ne sais pas, je pose la question. Peut-être que c'est plus facile pour la première modification d'une personne, mais par la suite les onglets me semble quand même plus intuitifs.

J'ai beaucoup étudié l'écran de modification de Google pour créer le nôtre. Je me demande si ce que tu proposes c'est pas plus ou moins ce qu'ils font : les onglets sous forme verticale comme la première action d'une modification ("l'entrée") puis les onglets pour compléter plus de choses dans l'action.
laem

edit edit 2

EDITED by @n4n5
etienneJr
@n4n5 wrote in https://codeberg.org/cartes/web/issues/2710#issuecomment-22161217:

ou encore "Valider cette modification" puis "Envoyer le changement" (pour être bien clair)

j'y ai réfléchi, c'est "Suivant" qu'il faut mettre à la place de "Valider"

@laem wrote in https://codeberg.org/cartes/web/issues/2710#issuecomment-22254304:

la personne clique sur envoyer par réflexe avant de se rendre compte qu'il y avait encore des choses à faire

bah, au pire ça fera 2 changesets au lieu d'1 la première fois que la personne utilise le formulaire, c'est grave ? En mettant le bouton "envoyer tout" sous les autres boutons, ça limitera.

@laem wrote in https://codeberg.org/cartes/web/issues/2710#issuecomment-22254304:

Je me demande si ce que tu proposes c'est pas plus ou moins ce qu'ils font : les onglets sous forme verticale comme la première action d'une modification ("l'entrée") puis les onglets pour compléter plus de choses dans l'action.

ah oui, marrant, je n'avais jamais testé sur gmaps, mais en effet ça ressemblerait à ça. Je n'aime pas les onglets à l'horizontale quand il y a trop d'éléments, il faut penser à scroller, et quand on va rajouter d'autres clés modifiables, ça va devenir ingérable. Un autre point : le menu à la verticale permet aussi d'avoir des UX différentes selon les boutons :
- au clic sur le bouton "autre chose ? poster une note" on pourra afficher des propositions d'autres éditeurs plus poussés avant le formulaire pour poster la note
- on pourrait regrouper des clés dans les groupes, par exemple un bouton "coordonnées" qui affiche tel et website et socials.
esmenard
J'aime bien l'écran de modification de CoMaps, on a un écran d'accueil de la page de modification avec tous les attributs modifiables, puis on clique sur l'attribut qu'on veut modifier, on modifie, on clique sur valider, ça nous renvoie sur l'écran d'accueil et une fois qu'on a modifié tout ce qu'on voulait on clique sur le bouton valider sur l'écran d'accueil pour envoyer le changeset.
laem

J'aime bien l'écran de modification de CoMaps, on a un écran d'accueil de la page de modification avec tous les attributs modifiables, puis on clique sur l'attribut qu'on veut modifier, on modifie, on clique sur valider, ça nous renvoie sur l'écran d'accueil et une fois qu'on a modifié tout ce qu'on voulait on clique sur le bouton valider sur l'écran d'accueil pour envoyer le changeset.

Attends, j'ai pas du tout cette expérience sur Comaps. J'ai tous les champs en bloc, puis valider, et voilà pas d'écran de confirmation. Version Android.
pmiossec
@etienneJr wrote in https://codeberg.org/cartes/web/issues/2710#issuecomment-22285426:

Je n'aime pas les onglets à l'horizontale quand il y a trop d'éléments, il faut penser à scroller, et quand on va rajouter d'autres clés modifiables, ça va devenir ingérable.

Avis partagé. Une autre possibilité serait d'avoir un accordéon vertical comme cela le scroll est vertical au lieu d'horizontal qui n'est pas intuitif.
esmenard
@laem wrote in https://codeberg.org/cartes/web/issues/2710#issuecomment-22297093:

Attends, j'ai pas du tout cette expérience sur Comaps. J'ai tous les champs en bloc, puis valider, et voilà pas d'écran de confirmation. Version Android.

Ah oui pardon, c'est que les horaires et le numéro de téléphone qui ont un écran dédié pour les modifier.
n4n5
@etienneJr wrote in 2710#issuecomment-22285426">https://codeberg.org/cartes/web/issues/2710#issuecomment-22285426:

@n4n5 wrote in #2710 (comment):

ou encore "Valider cette modification" puis "Envoyer le changement" (pour être bien clair)

j'y ai réfléchi, c'est "Suivant" qu'il faut mettre à la place de "Valider"

Arhg je suis pas sûr, car si tu as devant toi l'interface avec le slider horizontal, je pense que mettre "suivant" pourrait indiquer "éditer l'onglet suivant" ^^

Je pense qu'au final un simple "OK" puis "envoyer le changement" ferais peut-être le taf, a voir
n4n5
original issue fixed by https://codeberg.org/cartes/web/pulls/2939

Aussi fix de mon commentaire https://codeberg.org/cartes/web/issues/2710#issuecomment-22099021
n4n5
Il faudrait
- soit close l'issue
- soit renommer l'issue pour garder le ticket à propos du côté "design"

✏️ Participer à la discussion