À propos de la désactivation de composants sur l'iframe
publié le , mis à jour@etienneJr @pmiossec je fais suite à cette PR https://codeberg.org/cartes/web/pulls/1756
Je suis pas convaincu par ce changement, pour plusieurs raisons.
D'abord parce que chaque exception de ce type entrainera de la confusion et de la complexité. Déjà que les divergences bureau/mobile le font...
D'autre part, car l'iframe peut avoir des usages très larges !
Ça peut être un événement qui donne l'adresse de son lieu, ça peut être un bar, ça peut être La Poste qui intègre une carte de chaque bureau de poste. Sans oublier juste l'iframe tout court, sans paramétrer l'URL.
Et du coup désactiver les lieux similaires me semble trop spécifique, par exemple pour ce dernier exemple ou c'est hyper utile.
Idem pour l'édition du lieu : si un commerce intègre cartes.app sur son site et qu'en tant qu'utilisateur je constate que les horaires sont pas bons, l'iframe est l'endroit parfait pour faire la correction !
Pour les avis aussi : j'imagine bien un commerce proposer à ses clients d'aller déposer des avis via sa page "contacts" (la redirection bluesky à mon avis ouvrira cartes.app en onglet à part dans tous les cas, enfin à tester !).
Donc à mon avis faut revenir en arrière sur ces règles générales.
Certes un bar qui nous intègre aura pas forcément envie de voir une liste de ses concurrents sous sa fiche. Mais si ça s'avère problématique, on pourra intégrer une exception dans l'URL ? Et même, je pense que ça mérite réflexion : est-ce qu'on autorise ce genre de chose qui se fait (un peu) au détriment de l'utilisateur ?
pmiossec
@laem wrote in https://codeberg.org/cartes/web/issues/1777#issue-3822862:
Mais si ça s'avère problématique, on pourra intégrer une exception dans l'URL ?
👍 C'est ce que j'avais en tête egalement (particulierement pour les similaires)
@laem wrote in https://codeberg.org/cartes/web/issues/1777#issue-3822862:
Idem pour l'édition du lieu : si un commerce intègre cartes.app sur son site et qu'en tant qu'utilisateur je constate que les horaires sont pas bons, l'iframe est l'endroit parfait pour faire la correction !
Là, par contre, je pense que la probabilité joue contre ton argument. Il faut que la personne veuille contribuer puis qu'elle ait un compte OSM ou le crée en live, qu'elle se logue car la session n'est pas partagée avec cartes.app --qui est la vraie raison pour laquelle je pense que c'est utopique d'offrir cette fonctionnalité dans l'iframe-- (Presque) Personne pour moi va contribuer dans ces conditions et la plus-value d'avoir tout çà dans l'iframe pour qqchose qui n'arrivera qu'extremement rarement.
Je suis largement plus enthousiasmé par un lien invitant pour ces cas là à ouvrir cartes.app.
etienneJr
je n'ai pas d'avis vraiment tranché, donc je n'ai aucun pb à ce que revert si tu penses que c'est mieux.
laem
qu'elle se logue car la session n'est pas partagée avec cartes.app --qui est la vraie raison pour laquelle je pense que c'est utopique d'offrir cette fonctionnalité dans l'iframe--
Je ne pige pas trop la différence ici entre iframe et non iframe. Les freins sont les mêmes dans les deux cas, à l'exception près que dans un iframe, l'écran est plus petit. Mais dans beaucoup de cas, l'édition se fera sur mobile donc dans un équivalent iframe en termes de largeur.
Non ?
Pour moi, il y a plusieurs raison qui font que ce n'est pas le même cas d'usage qui font que c'est surement mieux que l'édition soit désactivé.
Point de vue du site qui l'intègre:
- pour lui, l'édition c'est plus une gène car ça complexifie l'interface et dilue l'information à passer
- s'il intègre l'iframe, surement qu'il a mis à jour les infos préalablement (p-ê que dans la page "intégrer", il faudrait encourager à les vérifier et les mettre à jour) et donc ça risque de pas servir beaucoup
Point de vue utilisateur qui ne sait pas vraiment qu'il voit cartes.app: il n'a pas choisi délibérément d'y aller, ne connait pas les principes :
- idem, que point 1) Cet utilisateur est pour moi encore plus "consommateur" de l'info qu'un utilisateur de cartes.app et je prêt à parier que le taux de transformation en contributeur est largement plus faible que sur cartes.app (qui ne doit pas être énorme non plus)
- Si l'utilisateur est déjà contributeur ou veut contribuer, il ne sera pas loggué avec son compte OSM et devra se logguer pour chaque contribution en iframe. L'UX consistant à ouvrir cartes.app et potentiellement être déjà loggué ou avoir ses credentials déjà mémorisés me parait largement meilleur.
Un lien vers cartes.app, potentiellement exactement vers la même page, me parait beaucoup mieux. ça aurait même le potentiel avantage pour ceux qui cliqueraient de découvrir et de gagner un nouvel utilisateur. On pourrait même imaginer un welcome screen pour les utilisateurs provenant d'une iframe avec un petit texte explicatif avec les principes de contribution lorsque c'est la 1ère ouverture.
Si l'utilisateur est déjà contributeur ou veut contribuer, il ne sera pas loggué avec son compte OSM et devra se logguer pour chaque contribution en iframe.
Ah non, l'iframe c'est vraiment juste le site dans un cadre restreint. Si t'es connecté sur cartes.app, tu le seras sur un iframe car t'es tout simplement sur cartes.app.
Pour le reste, je suis assez d'accord, mais du coup je te propose une chose : garder le bouton de modification du lieu mais en retrait, plus petit, sous forme de lien, qui ouvre une nouvelle fenêtre entière cartes.app.
Et en réservant ces limitations à un iframe d'intégration de lieu, pas un iframe en général : rappelons-nous que quelqu'un peut utiliser la technologie iframe justement pour proposer à ses utilisateurs de modifier des lieux. On ne doit pas présumer de l'usage de l'iframe en général.
@laem wrote in https://codeberg.org/cartes/web/issues/1777#issuecomment-11718729:
Ah non, l'iframe c'est vraiment juste le site dans un cadre restreint. Si t'es connecté sur cartes.app, tu le seras sur un iframe car t'es tout simplement sur cartes.app.
Sûr de çà? Car j'avais verifié avant de désactiver. Bon du coup je peux plus reverifier maintenant 🫤 mais le fait que mes favoris n'aparaissent pas dans l'iframe me font penser que non les données du localstorage ne sont pas partagées...
Edit: le site de test 😅 https://www.radiateurs-carre.fr/
Ah mince ça semble avoir changé. Pour des raisons assez évidentes de sécurité.
Et puis là je viens de tester (en modifiant l'URL de l'iframe dans les devtools) et la connexion à OSM ne fonctionnera jamais en iframe car osm.org refuse de se faire iframer.
Donc bien vu, tu as raison. Inutile d'espérer un comportement connecté de nos utilisateurs dans l'iframe.
Je serais donc partisan de remplacer ces boutons (modifier / laisser un avis) par un lien <a href> vers la même page mais directement sur cartes.app.
@laem wrote in https://codeberg.org/cartes/web/issues/1777#issuecomment-11748291:
Je serais donc partisan de remplacer ces boutons (modifier / laisser un avis) par un lien vers la même page mais directement sur cartes.app.
👍
@laem wrote in https://codeberg.org/cartes/web/issues/1777#issuecomment-11748291:
Je serais donc partisan de remplacer ces boutons (modifier / laisser un avis) par un lien vers la même page mais directement sur cartes.app.
Fait avec #1821