9
102
Fork
You've already forked web
30

WIP: "Recherche ici" en haut à gauche #1772

Closed
pmiossec wants to merge 1 commit from pmiossec/cartes-web:rechercher_ici_avant_resultats into master
pull from: pmiossec/cartes-web:rechercher_ici_avant_resultats
merge into: cartes:master
cartes:master
cartes:abostats
cartes:SynchroM-master
cartes:gps
cartes:embeddings
cartes:lysios-patch-5
cartes:lysios-patch-4
cartes:lysios-patch-3
cartes:lysios-patch-2
cartes:lysios-patch-1
cartes:abo-serveur2
cartes:clim
cartes:zone-en-favori
cartes:categories_toujours_visibles
cartes:rechercher_ici_avant_resultats
cartes:test-2365
cartes:panoramax-contribution
cartes:add-categories-validations
cartes:gel-bug-prod
cartes:osm-note-2
cartes:broken
cartes:wikidata_booking
cartes:fuse7.3
cartes:lysios-patrimoine-3
cartes:gps2
cartes:atproto-fix-2
cartes:styles-secondaires-mais-maison
cartes:atproto-scopes
cartes:itineraire-printemps-2026
cartes:modal-sheet-5.6
cartes:nlnet-cost-climate-perf
cartes:pb-icones-religieux
cartes:couvoiture
cartes:etiennejr-patch-2
cartes:meteo-fainéante
cartes:logo-static-url
cartes:poc-page-vitrine
cartes:remove-compass
cartes:test-reproduce-1795
cartes:display-cycleway-lanes-2
cartes:poc-image
cartes:add-media-condition
cartes:mapterhorn
cartes:test-indoor-equal
cartes:outdoors-VS-indoorEqual
cartes:hiking-colors
cartes:fix-blog-typing
cartes:poc-next-international
cartes:fix-map-style-modal-not-closing
cartes:i18n
cartes:hide-odd-zoom-levels
cartes:filter_categories
cartes:resume_wikipedia
cartes:deplacement_bouttons
cartes:fix-1095
cartes:mobile_permettre_selection
cartes:position-carte-initiale
cartes:dégradé-icônes
cartes:better_wikipedia
cartes:affichage_donnees_wikidata
cartes:mobile-permettre-selection
cartes:avis-details
cartes:perf-seo
cartes:modal-sheet-5
cartes:plans-novembre
cartes:display-cycleway-lanes
cartes:fix-1227
cartes:fix-1234
cartes:etiennejr-patch-1
cartes:update-1240
cartes:fix-1236
cartes:fix-1131
cartes:photon-search-street
cartes:fix-1221
cartes:article-avis
cartes:net-haut-zoom
cartes:baies-moins-visibles
cartes:belles-fiches-lieu
cartes:fix-1157
cartes:bug-page-vie-privée
cartes:use-watername
cartes:fix-1176
cartes:carte-du-onde
cartes:fix-1166
cartes:page-news
cartes:tchou
cartes:add-icon-alias
cartes:vitesse
cartes:photon-opensearch
cartes:private-in-italic
cartes:bâtiments-3D
cartes:merge-categories
cartes:handle-private-highway
cartes:improve-findcategory
cartes:injection-pmtiles
cartes:fix-1128
cartes:check-icons
cartes:update-readme
cartes:category-rugby
cartes:bug-position-carte-vs-lieu
cartes:limites-vitesse
cartes:improve-find-category-from-tags-v2
cartes:integrer
cartes:document-osmfeature
cartes:translate-document
cartes:velo-fin-aout-25
cartes:velo-ete-2025
cartes:moins-de-maptiler
cartes:planet-pmtiles-tilemaker
cartes:fix-1048
cartes:panoramax-leger
cartes:plume
cartes:horaires-i18n
cartes:planet
cartes:maj-deps-juillet-2025
cartes:improve-find-category-from-tags
cartes:bug-encart
cartes:interactions-encart-mobile
cartes:clic-on-station
cartes:fix-1028
cartes:fix-1014
cartes:edit
cartes:add-big-rivers
cartes:add-shortbread-tiles
cartes:handle-deleted-osm-elements-v2
cartes:codeberg
cartes:improve-useEffect
cartes:immoloc
cartes:update-dashboard
cartes:analyze
cartes:terradraw
cartes:sombre2
cartes:calendar
cartes:poi-sprites-using-svg
cartes:style-sombre
cartes:sprites
cartes:annuaire
cartes:motis-gtfs-attributes
cartes:next-styled-components
cartes:dev
cartes:cool2
cartes:cool
cartes:panoramax-angle
cartes:env-static-urls
cartes:borders-only
cartes:panoramax2
cartes:intelligence
cartes:debug-iles
cartes:nouveau-serveur
cartes:france-protomaps
cartes:turbo
cartes:fouss/cartes-#338
cartes:blog2
cartes:legislatives
cartes:presentation
cartes:pas-de-geoloc-si-hash-different
cartes:protomaps
cartes:vaul
cartes:carte-trains
cartes:citiz
cartes:maj-paquets
cartes:icones
cartes:ui2
cartes:bblog
cartes:voyagevoyage
cartes:test-image-origine
cartes:bugimagefin
cartes:searchParams
cartes:voyage
cartes:avion
cartes:perf
cartes:studio
cartes:piscine
cartes:journée
cartes:année
cartes:journée-transition
cartes:score-dès-acceuil
cartes:fix-space-problem
cartes:rebase-5août
cartes:correspondance
cartes:règles-séparées
cartes:indeps-acre
cartes:demo
cartes:indeps
cartes:indeps-cachés
cartes:indication-temps-plein
cartes:indeps-refactor-simulations
cartes:indeps-vue-comparaison
cartes:indeps-inversion
cartes:barème-continu
cartes:indeps-démo
cartes:textes-branches-sécu
cartes:engine-enum
cartes:2019
cartes:transport
cartes:publicodes
cartes:as
cartes:infrance-nouvelle-landing
cartes:better-translation
cartes:co2
cartes:simplifATMP
cartes:controle-SMIC
cartes:webi18n
cartes:bug-avantages-en-nature
cartes:revert-352-infrance-navigation-v2
cartes:laem-patch-1
cartes:robots.txt
cartes:improve-perf
cartes:iframe-bugfix
cartes:quickfixes
cartes:lib
cartes:irsimple
cartes:hiringinfrance.com
cartes:dégradé
cartes:refstate
cartes:johan
cartes:zrr
cartes:logo-interactif
cartes:revert-216-improve-tracking
cartes:redesign2
cartes:zrr2
cartes:fixtrad
cartes:correction-salaire-brut
cartes:petit-state
cartes:alien-consolidate
cartes:translate-ui
cartes:npm
cartes:alien-brut-net
cartes:translatable
cartes:différent
cartes:ir18
cartes:fix-typo
cartes:add-tracking
cartes:fix-collect-missing
cartes:défauts-partout
cartes:fix-double-unfold-three
cartes:fix-double-unfold
cartes:versement-transport
cartes:blocker-questions

Avant:

image

Après:
image

Proposition alternative:

image

Avant: ![image](/attachments/847f947c-1154-486a-8901-3b2ed2b2b4d9) Après: ![image](/attachments/63f89108-34b9-4e5c-b733-594a28dccccc) Proposition alternative: ![image](/attachments/7609acc8-b413-4220-be1e-94dbc304e728)
Author
Member
Copy link

Pour lancer la discussion car pas mal de fois, des utilisateurs disent n'avoir pas vu le bouton et quand on leur fait remarquer, ils disent qu'il faut le mettre en haut.

Autres propositions:

  • Décoché avec le label "Chercher globalement" / "Chercher partout"
  • Egalement : enlever la coche (i.e. transformer en bouton) et faire varier le label et pourquoi pas une icone.
Pour lancer la discussion car pas mal de fois, des utilisateurs disent n'avoir pas vu le bouton et quand on leur fait remarquer, ils disent qu'il faut le mettre en haut. Autres propositions: * Décoché avec le label "Chercher globalement" / "Chercher partout" * Egalement : enlever la coche (i.e. transformer en bouton) et faire varier le label et pourquoi pas une icone.

Merci d'avoir démarré l'action !

En desktop, pas de pb, on a la place qu'on veut. Mais gaffe au mobile, il y a peu de place, surtout que le clavier virtuel est ouvert. Il faut trouver un visuel qui prend le moins de place possible

D'accord avec toi que cette case à cocher fait trop old school. Oui pour la transformer en boutons, dont 1 seul est sélectionnable à la fois). Et en anticipant de possibles boutons supplémentaires "adresse", "ville", "magasin", "France", qui permettraient des recherches photon plus ciblées, et qui pourraient s'activer tout seuls quand un mot clé est détecté dans la requête.

Merci d'avoir démarré l'action ! En desktop, pas de pb, on a la place qu'on veut. Mais gaffe au mobile, il y a peu de place, surtout que le clavier virtuel est ouvert. Il faut trouver un visuel qui prend le moins de place possible D'accord avec toi que cette case à cocher fait trop old school. Oui pour la transformer en boutons, dont 1 seul est sélectionnable à la fois). Et en anticipant de possibles boutons supplémentaires "adresse", "ville", "magasin", "France", qui permettraient des recherches photon plus ciblées, et qui pourraient s'activer tout seuls quand un mot clé est détecté dans la requête.
Owner
Copy link

Ticket pertinent : #803

Également, ce ticket plus récent où je propose un design pour ce bouton : #1644 (comment)

Ticket pertinent : https://codeberg.org/cartes/web/issues/803 Également, ce ticket plus récent où je propose un design pour ce bouton : https://codeberg.org/cartes/web/issues/1644#issuecomment-10693184
Owner
Copy link

D'accord avec toi que cette case à cocher fait trop old school. Oui pour la transformer en boutons, dont 1 seul est sélectionnable à la fois)

C'est un input type="radio" :)

> D'accord avec toi que cette case à cocher fait trop old school. Oui pour la transformer en boutons, dont 1 seul est sélectionnable à la fois) C'est un input type="radio" :)
Owner
Copy link

J'avance dans une autre PR pour avoir la main !1867

image

J'avance dans une autre PR pour avoir la main !1867 ![image](/attachments/5c5abdba-9c2e-46e4-99f4-dbb31b38106a)
Owner
Copy link

Autre copie plus discrète

image

Autre copie plus discrète ![image](/attachments/2e578b73-0b7d-44b3-a044-7f1bb9ee061f)
283 KiB
Owner
Copy link

image

![image](/attachments/c18092a6-e207-45e0-bfa8-ac968fd30ea7)
Owner
Copy link

Qu'en pensez-vous ?

Qu'en pensez-vous ?
Owner
Copy link
  • enlever le {(true || isMyInputFocused || step.results) && (
- [ ] enlever le {(true || isMyInputFocused || step.results) && (

@laem wrote in #1772 (comment):

Qu'en pensez-vous

Hum, j'aime pas trop... Ça fait trop geek non ?
Les termes local et global ne me paraissent pas si clair.
Les boutons radio éclaté à gauche et droite : on comprend pas que c'est un sélecteur avec 2 options.
L'emplacement sous les catégories : on comprend pas que ce périmètre concerne la recherche et pas les catégories...

@laem wrote in https://codeberg.org/cartes/web/pulls/1772#issuecomment-12029283: > Qu'en pensez-vous Hum, j'aime pas trop... Ça fait trop geek non ? Les termes local et global ne me paraissent pas si clair. Les boutons radio éclaté à gauche et droite : on comprend pas que c'est un sélecteur avec 2 options. L'emplacement sous les catégories : on comprend pas que ce périmètre concerne la recherche et pas les catégories...

J'imaginais quelque chose comme ça, avec des boutons, et intégrés dans le champ de recherche.
image

J'imaginais quelque chose comme ça, avec des boutons, et intégrés dans le champ de recherche. ![image](/attachments/25bc4009-1090-43cb-995e-44d9e9205c0d)
Author
Member
Copy link

@etienneJr wrote in #1772 (comment):

Les boutons radio éclaté à gauche et droite : on comprend pas que c'est un sélecteur avec 2 options.
L'emplacement sous les catégories : on comprend pas que ce périmètre concerne la recherche et pas les catégories...

Je dois avouer que je partage ce constat : j'ai mis un petit moment avant de comprendre que c'était des radios. On n'a pas l'habitude de les avoirs écartées...

Pour moi, soit cela s'affiche après la 1ère recherche comme actuellement et la position peut être bonne car à côté des résultats.
Mais si on décide de l'avoir avant la recherche (et je trouve cela mieux), alors comme @etienneJr propose, je pense qu'il faut que cela soit collé au champ de recherche. ET moi aussi, je verais bien un fond qui engloberait les 2 (voir même l'icone pour que ça fasse plus harmonieux)

@etienneJr wrote in #1772 (comment):

Les termes local et global ne me paraissent pas si clair.

Un peu d'accord mais je vois pas de proposition meilleur: ici, autours de moi, au alentours, mondial, mondialement, partout, ... pas folichon 🫤
En tout cas, "Périmètre" me semble peu parlant. "Périmètre de recherche"?

@etienneJr wrote in https://codeberg.org/cartes/web/pulls/1772#issuecomment-12030096: > Les boutons radio éclaté à gauche et droite : on comprend pas que c'est un sélecteur avec 2 options. > L'emplacement sous les catégories : on comprend pas que ce périmètre concerne la recherche et pas les catégories... Je dois avouer que je partage ce constat : j'ai mis un petit moment avant de comprendre que c'était des radios. On n'a pas l'habitude de les avoirs écartées... Pour moi, soit cela s'affiche après la 1ère recherche comme actuellement et la position peut être bonne car à côté des résultats. Mais si on décide de l'avoir avant la recherche (et je trouve cela mieux), alors comme @etienneJr propose, je pense qu'il faut que cela soit collé au champ de recherche. ET moi aussi, je verais bien un fond qui engloberait les 2 (voir même l'icone pour que ça fasse plus harmonieux) @etienneJr wrote in https://codeberg.org/cartes/web/pulls/1772#issuecomment-12030096: > Les termes local et global ne me paraissent pas si clair. Un peu d'accord mais je vois pas de proposition meilleur: ici, autours de moi, au alentours, mondial, mondialement, partout, ... pas folichon 🫤 En tout cas, "Périmètre" me semble peu parlant. "Périmètre de recherche"?
Owner
Copy link

Ah oui j'aime bien ton vocabulaire "ici" vs "partout". L'adresse, j'avais pas envie de coder cette fonctionnalité dans une première PR.

Ah oui j'aime bien ton vocabulaire "ici" vs "partout". L'adresse, j'avais pas envie de coder cette fonctionnalité dans une première PR.

@laem wrote in #1772 (comment):

L'adresse, j'avais pas envie de coder cette fonctionnalité dans une première PR.

oui oui. Je l'avais mis pour dire qu'il faut anticiper un menu avec plus de 2 choix possibles.

@laem wrote in https://codeberg.org/cartes/web/pulls/1772#issuecomment-12124452: > L'adresse, j'avais pas envie de coder cette fonctionnalité dans une première PR. oui oui. Je l'avais mis pour dire qu'il faut anticiper un menu avec plus de 2 choix possibles.
Owner
Copy link

oui oui. Je l'avais mis pour dire qu'il faut anticiper un menu avec plus de 2 choix possibles.

Oui de mon côté aussi, c'était le but de mon design qui prend toute la largeur, pouvoir accueillir un niveau intermédiaire par la suite.

> oui oui. Je l'avais mis pour dire qu'il faut anticiper un menu avec plus de 2 choix possibles. Oui de mon côté aussi, c'était le but de mon design qui prend toute la largeur, pouvoir accueillir un niveau intermédiaire par la suite.

@laem @pmiossec finalement on fait quoi de cette PR (et de #1867). Peut-être du lien à faire avec #2001 ?

@laem @pmiossec finalement on fait quoi de cette PR (et de #1867). Peut-être du lien à faire avec #2001 ?
Owner
Copy link

Faut qu'on en fasse une v1 qui nous satisfasse tous les 3, ce sera déjà bien :)

Faut qu'on en fasse une v1 qui nous satisfasse tous les 3, ce sera déjà bien :)
Owner
Copy link

Nouvelle proposition ! Je me suis rendu compte grâce à ta capture @etienneJr que le titre "Périmètre" ou "Rechercher" était inutile, car déjà affiché dans le champ de recherche. Et puis quand on le remplit avec par exemple "Cinéma" ou "12 rue Victor Hugo", ça garde assez de sens je trouve.

image

image

Nouvelle proposition ! Je me suis rendu compte grâce à ta capture @etienneJr que le titre "Périmètre" ou "Rechercher" était inutile, car déjà affiché dans le champ de recherche. Et puis quand on le remplit avec par exemple "Cinéma" ou "12 rue Victor Hugo", ça garde assez de sens je trouve. ![image](/attachments/65055862-c344-4494-93bd-0a97e781b783) ![image](/attachments/b539f505-3950-47c7-ad09-44684d9a0d12)
Owner
Copy link

ET moi aussi, je verais bien un fond qui engloberait les 2 (voir même l'icone pour que ça fasse plus harmonieux)

Ça me semble assez casse gueule en termes d'UI, et compliqué à coder correctement : mélanger une saisie et des boutons assez larges.

Je vous propose d'envoyer ça en ligne tel quel, c'est déjà une nette amélioration par rapport au vieux existant :)

> ET moi aussi, je verais bien un fond qui engloberait les 2 (voir même l'icone pour que ça fasse plus harmonieux) Ça me semble assez casse gueule en termes d'UI, et compliqué à coder correctement : mélanger une saisie et des boutons assez larges. Je vous propose d'envoyer ça en ligne tel quel, c'est déjà une nette amélioration par rapport au vieux existant :)
Owner
Copy link

Je mets en ligne ma PR #1867 en gardant celle-ci pour continuer de débattre.

Je mets en ligne ma PR #1867 en gardant celle-ci pour continuer de débattre.
Owner
Copy link

Je mets en ligne ma PR #1867 en gardant celle-ci pour continuer de débattre.

Je mets en ligne ma PR #1867 en gardant celle-ci pour continuer de débattre.

@laem wrote in #1772 (comment):

Je mets en ligne ma PR #1867

le déploiement n'a pas marché. [edit] je vois que tu l'avais remarqué, j'ai relancé le déploiement et ça a marché, c'est en ligne.

Nouvelle proposition !

hum, comme le bouton change de couleur quand il est sélectionné, je ne vois pas l'intérêt du bouton radio en plus. (Et d'une manière générale, les boutons radios c'est interdit désormais, non ? 😀​)

Ça me semble assez casse gueule en termes d'UI, et compliqué à coder correctement : mélanger une saisie et des boutons assez larges.

ah bon ? J'aimerais bien l'avis de @7ute sur le sujet ! (on parle de ma proposition dans ce commentaire)

@laem wrote in https://codeberg.org/cartes/web/pulls/1772#issuecomment-17947559: > Je mets en ligne ma PR #1867 le déploiement n'a pas marché. [edit] je vois que tu l'avais remarqué, j'ai relancé le déploiement et ça a marché, c'est en ligne. > Nouvelle proposition ! hum, comme le bouton change de couleur quand il est sélectionné, je ne vois pas l'intérêt du bouton radio en plus. (Et d'une manière générale, les boutons radios c'est interdit désormais, non ? 😀​) > Ça me semble assez casse gueule en termes d'UI, et compliqué à coder correctement : mélanger une saisie et des boutons assez larges. ah bon ? J'aimerais bien l'avis de @7ute sur le sujet ! (on parle de ma proposition dans [ce commentaire](https://codeberg.org/cartes/web/pulls/1772#issuecomment-12030477))

@laem maintenant que c'est déployé et que j'ai testé :

  • quand on clique pour changer de ici à partour, les 2 boutons disparaissent le temps que la recherche aboutisse. C'est très perturbant, surtout quand il y a des catégories affichées entre les 2 !
  • une fois que j'ai cliqué sur un bouton, j'ai la barre clignotante "|" (le curseur de position du clavier) qui se retrouver dans le bouton, c'est perturbant aussi
@laem maintenant que c'est déployé et que j'ai testé : - quand on clique pour changer de ici à partour, les 2 boutons disparaissent le temps que la recherche aboutisse. C'est très perturbant, surtout quand il y a des catégories affichées entre les 2 ! - une fois que j'ai cliqué sur un bouton, j'ai la barre clignotante "|" (le curseur de position du clavier) qui se retrouver dans le bouton, c'est perturbant aussi
First-time contributor
Copy link

@etienneJr wrote in #1772 (comment):

@laem wrote in #1772 (commentaire):

Ça me semble assez casse gueule en termes d'UI, et compliqué à coder correctement : mélanger une saisie et des boutons assez larges.
ah bon ? J'aimerais bien l'avis de @7ute sur le sujet ! (on parle de ma proposition dans ce commentaire)

Je ne pense pas que ce soit tant casse-gueule que ça, dans le sens où c'est un ajustement contextuel (lorsqu'on fait une recherche, donc que l'on va faire une saisie, on est face au choix du local / global) et que ces boutons peuvent donc être groupé avec le champ.
Et c'est faisable, en utilisant un conteneur supplémentaire (avec :focus-within tu peux garder le comportement de la mise en focus du champ si besoin, même si ça n'est pas nécessaire, l'apparition du champ + disparition du placeholder convoyant déjà cette information). Cf. petit mockup fait sur un coin de nappe.
Idéalement, et pour que ça soit compréhensible, il faudrait que les boutons s'affiche avec un transition (assez courte, mais pas une apparition soudaine).

Nota: l'icone Cartes gagnerait à atterir dans la barre latérale, pour dédier ce panneau uniquement à la recherche (mais je peux rajouter ça au ticket "coup de pelleteuse dans l'UI/UX" si vous voulez)

@etienneJr wrote in https://codeberg.org/cartes/web/pulls/1772#issuecomment-17969873: > @laem wrote in #1772 (commentaire): > > Ça me semble assez casse gueule en termes d'UI, et compliqué à coder correctement : mélanger une saisie et des boutons assez larges. > ah bon ? J'aimerais bien l'avis de @7ute sur le sujet ! (on parle de ma proposition dans [ce commentaire](https://codeberg.org/cartes/web/pulls/1772#issuecomment-12030477)) Je ne pense pas que ce soit tant casse-gueule que ça, dans le sens où c'est un ajustement contextuel (lorsqu'on fait une recherche, donc que l'on va faire une saisie, on est face au choix du local / global) et que ces boutons peuvent donc être groupé avec le champ. Et c'est faisable, en utilisant un conteneur supplémentaire (avec :focus-within tu peux garder le comportement de la mise en focus du champ si besoin, même si ça n'est pas nécessaire, l'apparition du champ + disparition du placeholder convoyant déjà cette information). Cf. petit mockup fait sur un coin de nappe. Idéalement, et pour que ça soit compréhensible, il faudrait que les boutons s'affiche avec un transition (assez courte, mais pas une apparition soudaine). Nota: l'icone Cartes gagnerait à atterir dans la barre latérale, pour dédier ce panneau uniquement à la recherche (mais je peux rajouter ça au ticket "coup de pelleteuse dans l'UI/UX" si vous voulez)
Owner
Copy link

le déploiement n'a pas marché. [edit] je vois que tu l'avais remarqué, j'ai relancé le déploiement et ça a marché, c'est en ligne.

Oui, Codeberg ne marchait plus :/ Merci !

> le déploiement n'a pas marché. [edit] je vois que tu l'avais remarqué, j'ai relancé le déploiement et ça a marché, c'est en ligne. Oui, Codeberg ne marchait plus :/ Merci !
Owner
Copy link

hum, comme le bouton change de couleur quand il est sélectionné, je ne vois pas l'intérêt du bouton radio en plus. (Et d'une manière générale, les boutons radios c'est interdit désormais, non ? 😀​)

À mon avis c'est important de respecter les standards du Web. Ici, c'est clairement un bouton radio, qui signale : c'est soit l'un soit l'autre, pas les deux, ni aucun. Si on passe à un bouton, on enlève du sens sémantique à cet élément.

Je vais regarder pour tes deux bugs, ça me parait en effet pas normal.

Merci pour la maquette @7ute. Attention, le logo cartes.app, qui est aussi un bouton et qui devient l'icône de l'utilisateur une fois connecté, ne doit pas être dans le champ de recherche. Là aussi, il faut qu'on ne quitte pas trop les standards du Web : le champ de recherche, l'endroit où l'utilisateur clique pour saisir du texte, doit rester bien identifié avec son arrière-plan coloré.

Je comprends l'idée de mettre toutes les saisies utilisateur dans ce champ, mais ça me semble complexe.

> hum, comme le bouton change de couleur quand il est sélectionné, je ne vois pas l'intérêt du bouton radio en plus. (Et d'une manière générale, les boutons radios c'est interdit désormais, non ? 😀​) À mon avis c'est important de respecter les standards du Web. Ici, c'est clairement un bouton radio, qui signale : c'est soit l'un soit l'autre, pas les deux, ni aucun. Si on passe à un bouton, on enlève du sens sémantique à cet élément. Je vais regarder pour tes deux bugs, ça me parait en effet pas normal. Merci pour la maquette @7ute. Attention, le logo cartes.app, qui est aussi un bouton et qui devient l'icône de l'utilisateur une fois connecté, ne doit pas être dans le champ de recherche. Là aussi, il faut qu'on ne quitte pas trop les standards du Web : le champ de recherche, l'endroit où l'utilisateur clique pour saisir du texte, doit rester bien identifié avec son arrière-plan coloré. Je comprends l'idée de mettre toutes les saisies utilisateur dans ce champ, mais ça me semble complexe.
Owner
Copy link

une fois que j'ai cliqué sur un bouton, j'ai la barre clignotante "|" (le curseur de position du clavier) qui se retrouver dans le bouton, c'est perturbant aussi

Alors ça, je comprends pas. Tu pourrais filmer ?

Pour le 1), c'est corrigé, mais reste un problème : je clique sur le champ de recherche -> les boutons apparaissent -> je change de ici à partout avant de saisir une recherche -> on perd le focus du champ de recherche -> les boutons disparaissent.

> une fois que j'ai cliqué sur un bouton, j'ai la barre clignotante "|" (le curseur de position du clavier) qui se retrouver dans le bouton, c'est perturbant aussi Alors ça, je comprends pas. Tu pourrais filmer ? Pour le 1), c'est corrigé, mais reste un problème : je clique sur le champ de recherche -> les boutons apparaissent -> je change de ici à partout *avant* de saisir une recherche -> on perd le focus du champ de recherche -> les boutons disparaissent.

@laem wrote in #1772 (comment):

Tu pourrais filmer ?

J'avais mis une capture vidéo dans mon message. C'est pas hyper visible. Mais ne te prends pas la tête avec ça. C'était ptet spécifique de mon navigateur.

@laem wrote in https://codeberg.org/cartes/web/pulls/1772#issuecomment-17993633: > Tu pourrais filmer ? J'avais mis une capture vidéo dans mon message. C'est pas hyper visible. Mais ne te prends pas la tête avec ça. C'était ptet spécifique de mon navigateur.

@laem wrote in #1772 (comment):

respecter les standards du Web

Euh, un bouton radio, c'est un standard du web 1.0 ! Y'a sûrement plus moderne et plus standard aujourd'hui, non ? Typiquement on dit qu'on fait une UI/UX de type app native, et je n'ai jamais vu un bouton radio dans une app native.

@laem wrote in https://codeberg.org/cartes/web/pulls/1772#issuecomment-17992904: > respecter les standards du Web Euh, un bouton radio, c'est un standard du web 1.0 ! Y'a sûrement plus moderne et plus standard aujourd'hui, non ? Typiquement on dit qu'on fait une UI/UX de type app native, et je n'ai jamais vu un bouton radio dans une app native.

@7ute wrote in #1772 (comment):

atterir dans la barre latérale

Attention aussi au fait qu'il n'y a pas de barre latérale sur mobile. Donc si on fait ça pour le desktop (et ça serait logique) alors faut trouver où le mettre sur mobile.

@7ute wrote in https://codeberg.org/cartes/web/pulls/1772#issuecomment-17989751: > atterir dans la barre latérale Attention aussi au fait qu'il n'y a pas de barre latérale sur mobile. Donc si on fait ça pour le desktop (et ça serait logique) alors faut trouver où le mettre sur mobile.
First-time contributor
Copy link

@etienneJr wrote in #1772 (comment):

@7ute wrote in #1772 (commentaire):

atterir dans la barre latérale

Attention aussi au fait qu'il n'y a pas de barre latérale sur mobile. Donc si on fait ça pour le desktop (et ça serait logique) alors faut trouver où le mettre sur mobile.

La présence du logo sur mobile n'est pas forcément nécessaire (c'est plus le role de l'icone de l'application, présent sur le launcher ou lors d'un switch d'application qui permet son identification rapide). Et la plupart des icones à l'écran peuvent atterir sous un speed-dial dans la version mobile qui peut tout à fait avoir le logo comme bouton.

@etienneJr wrote in https://codeberg.org/cartes/web/pulls/1772#issuecomment-17997287: > @7ute wrote in #1772 (commentaire): > > > atterir dans la barre latérale > > Attention aussi au fait qu'il n'y a pas de barre latérale sur mobile. Donc si on fait ça pour le desktop (et ça serait logique) alors faut trouver où le mettre sur mobile. La présence du logo sur mobile n'est pas forcément nécessaire (c'est plus le role de l'icone de l'application, présent sur le launcher ou lors d'un switch d'application qui permet son identification rapide). Et la plupart des icones à l'écran peuvent atterir sous un speed-dial dans la version mobile qui peut tout à fait avoir le logo comme bouton.
Owner
Copy link

J'avais mis une capture vidéo dans mon message. C'est pas hyper visible. Mais ne te prends pas la tête avec ça. C'était ptet spécifique de mon navigateur.

Ah merci, j'avais pas vu ! Tu es sur Windows ? Au-delà du bug très curieux du curseur, je remarque plein de choses qui vont pas en termes de marges intérieures. Aucun des boutons de catégorie n'est aligné, et le texte de saisie non plus ! C'est fou ça, la différence de rendu. Pourtant on n'utilise aucune propriété CSS spécifique à Linux (donc Ubuntu, Android, etc.) ou iOS. Je créée un nouveau ticket : #2387.

> J'avais mis une capture vidéo dans mon message. C'est pas hyper visible. Mais ne te prends pas la tête avec ça. C'était ptet spécifique de mon navigateur. Ah merci, j'avais pas vu ! Tu es sur Windows ? Au-delà du bug très curieux du curseur, je remarque plein de choses qui vont pas en termes de marges intérieures. Aucun des boutons de catégorie n'est aligné, et le texte de saisie non plus ! C'est fou ça, la différence de rendu. Pourtant on n'utilise aucune propriété CSS spécifique à Linux (donc Ubuntu, Android, etc.) ou iOS. Je créée un nouveau ticket : #2387.
Owner
Copy link

À propos du logo sur mobile : j'ai repris le design d'Apple maps, qui met barre de recherche et image de profil utilisateur en haut de la barre. Je trouve le design excellent. Et Google de son côté met le logo de l'app au même endroit que nous (je pense que là aussi, je m'en suis inspiré). Ça me semble très important pour que l'utilisateur sache bien qu'il est sur cartes.app et identifie le logo de l'app.

À propos du logo sur mobile : j'ai repris le design d'Apple maps, qui met barre de recherche et image de profil utilisateur en haut de la barre. Je trouve le design excellent. Et Google de son côté met le logo de l'app au même endroit que nous (je pense que là aussi, je m'en suis inspiré). Ça me semble très important pour que l'utilisateur sache bien qu'il est sur cartes.app et identifie le logo de l'app.
Owner
Copy link

Euh, un bouton radio, c'est un standard du web 1.0 ! Y'a sûrement plus moderne et plus standard aujourd'hui, non ? Typiquement on dit qu'on fait une UI/UX de type app native, et je n'ai jamais vu un bouton radio dans une app native.

Ah non, du Web tout court ;) Il ne faut pas confondre standard au sens de "les choses qu'on doit faire", et standard au sens de ce qui se fait couramment. Par exemple sur le Web dans notre cas, c'est une erreur d'utiliser des <button au lieu d'un <input type="radio". Par contre, beaucoup de développeurs stylisent l'input pour lui enlever son rond de sélection. C'est une pratique courante, mais critiquable. C'est cette pratique qui fait que l'utilisateur doit s'adapter à tant de styles d'interface différents. C'est important d'imposer un style identifiable à une app, mais dans la limite des standards. À mon avis, ça reste important de ne pas confondre dans notre librairie d'interface un bouton et un radio. Ce sont des choses bien différentes.

Notre StyleChooser par exemple est dans l'idée un gros bloc form radio. On ne l'a pas codé comme ça, mais on aurait du. Après, vu la spécificité aigüe du truc, ça me semble cohérent de pas y mettre les ronds, car les images + leur bord font office de trou. C'est un truc assez naturel : on présente des vignettes, l'utilisateur choisis la vignette qui lui plait.

De même pour lien vs bouton : un lien change l'URL de façon prédictible, un bouton fait une action éphémère ou contextuelle (un effet interne) ou effet extérieur, comme aller modifier un lieu OSM.

Sur mobile, Google & Apple ont pris tellement de poids qu'ils développent leurs propres "standards" visuels, certains extrêmement critiqués comme le dernier d'Apple, le liquid glass.

Ce que je remarque, c'est que sur mobile, ce qui s'est imposé c'est plutôt deux design : pour remplacer un radio à 2 éléments, c'est une case à cocher qui est utilisée. Comme on le faisait avant, sauf que là j'en suis sorti pour préparer le futur "chercher dans cette zone", la troisième option.

L'autre design de type radio c'est un select à trois éléments dont tous les éléments sont affichés, en plein écran, par opposition à un select de type modal (genre une liste de 200 pays). Les menus d'option en sont blindés. Il y a une coche explicite qui fait office de radio, pour dire : "voilà ce qui est sélectionné actuellement".

Les radios classiques sont toujours utilisés, par exemple le switch "theme sombre" sur Android a une option supplémentaire "standard" vs "étendu".

Maintenant, comment Apple & Google auraient fait dans notre cas ? Sûrement juste un bouton, qui cliqué s'ouvre sur une modale qui prend tout l'encart (ou tout l'écran) et qui explique les choix possibles. C'est un design possible, on devra peut-être l'adopter quand on ajoutera la recherche par zone, mais il a le défaut de nécessiter deux clics au lieu d'un.

> Euh, un bouton radio, c'est un standard du web 1.0 ! Y'a sûrement plus moderne et plus standard aujourd'hui, non ? Typiquement on dit qu'on fait une UI/UX de type app native, et je n'ai jamais vu un bouton radio dans une app native. Ah non, du Web tout court ;) Il ne faut pas confondre standard au sens de "les choses qu'on *doit* faire", et standard au sens de ce qui se fait couramment. Par exemple sur le Web dans notre cas, c'est une *erreur* d'utiliser des <button au lieu d'un <input type="radio". Par contre, beaucoup de développeurs stylisent l'input pour lui enlever son rond de sélection. C'est une pratique courante, mais critiquable. C'est cette pratique qui fait que l'utilisateur doit s'adapter à tant de styles d'interface différents. C'est important d'imposer un style identifiable à une app, mais dans la limite des standards. À mon avis, ça reste important de ne pas confondre dans notre librairie d'interface un bouton et un radio. Ce sont des choses bien différentes. Notre StyleChooser par exemple est dans l'idée un gros bloc form radio. On ne l'a pas codé comme ça, mais on aurait du. Après, vu la spécificité aigüe du truc, ça me semble cohérent de pas y mettre les ronds, car les images + leur bord font office de trou. C'est un truc assez naturel : on présente des vignettes, l'utilisateur choisis la vignette qui lui plait. De même pour lien vs bouton : un lien change l'URL de façon prédictible, un bouton fait une action éphémère ou contextuelle (un effet interne) ou effet extérieur, comme aller modifier un lieu OSM. Sur mobile, Google & Apple ont pris tellement de poids qu'ils développent leurs propres "standards" visuels, certains extrêmement critiqués comme le dernier d'Apple, le liquid glass. Ce que je remarque, c'est que sur mobile, ce qui s'est imposé c'est plutôt deux design : pour remplacer un radio à 2 éléments, c'est une case à cocher qui est utilisée. Comme on le faisait avant, sauf que là j'en suis sorti pour préparer le futur "chercher dans cette zone", la troisième option. L'autre design de type radio c'est un select à trois éléments dont tous les éléments sont affichés, en plein écran, par opposition à un select de type modal (genre une liste de 200 pays). Les menus d'option en sont blindés. Il y a une coche explicite qui fait office de radio, pour dire : "voilà ce qui est sélectionné actuellement". Les radios classiques sont toujours utilisés, par exemple le switch "theme sombre" sur Android a une option supplémentaire "standard" vs "étendu". Maintenant, comment Apple & Google auraient fait dans notre cas ? Sûrement juste un bouton, qui cliqué s'ouvre sur une modale qui prend tout l'encart (ou tout l'écran) et qui explique les choix possibles. C'est un design possible, on devra peut-être l'adopter quand on ajoutera la recherche par zone, mais il a le défaut de nécessiter deux clics au lieu d'un.
Owner
Copy link

Comaps en a quelques uns aussi, dans le style que j'ai décrit plus haut : modale sur tout l'écran.

Comaps en a quelques uns aussi, dans le style que j'ai décrit plus haut : modale sur tout l'écran.
pmiossec closed this pull request 2026年07月07日 18:48:30 +02:00

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
No reviewers
Labels
Clear labels
🎨 Design
À propos de l'interface et de l'UX
💡 Idée
Nouvelle feature à intégrer
❓ question
Further information is requested
🌍 OSM
À propos de l'affichage et l'édition des éléments OSM
🌱 Amélioration
Amélioration/fix de l'existant
🐞 Bug
Something isn't working
📊 SEO
📋 Catégories
À propos des catégories de recherche et de l'annuaire
📖 Wiki
📝Avis
A propos de la fonction avis et de bluesky
📢 Oyez
📷 Photos
A propos des photos (sources, affichage)
🔍Recherche
A propos de la barre de recherche et de photon
🔥 Actuel
🔧 tech
🖌 Styles
Styles de la carte
🧝i18n
🧪 R&D
🚍 Transports
🚙 Voiture
🚨Prioritaire
Ticket à traiter rapidement
🚲Vélo
Cartes
climat
Communication
demo
Cette branche doit être déployée comme une démo
dependencies
Pull requests that update a dependency file
javascript
Pull requests that update javascript code
Pas urgent
Plein-air
Tuiles
Verso
Vieux
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
4 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
cartes/web!1772
Reference in a new issue
cartes/web
No description provided.
Delete branch "pmiossec/cartes-web:rechercher_ici_avant_resultats"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?