[UI] Suggestion: Uniformisation de l'interface / experience utilisateur #2194

7ute commented 2026年05月21日 11:02:25 +02:00

Décrivez votre problème, votre suggestion

Tout d'abord: un grand bravo @laem et au contributeurs de ce projet. C'est une belle réalisation, et une excellente alternative aux mastodontes du domaine. Et le fait de vous voir régulièrement documenter l'avance sur Bluesky, c'est top!

Quelques petites choses me font un peu ticker à l'usage, d'où ce... ticket 😅 exposant quelques suggestions.
Même si plus cablé VueJS, je peux contribuer avec quelques PR si les modifications suggérés ci-dessous vont dans la direction souhaitée.

TL;DR

L'interface de Cartes affiche AMA un manque de cohérence visuelle sur certains aspects.
Les composants UI étant stylés indépendamment, s'appuyer sur un framework comme TailwindCSS + PrimeReact pourrait aider à harmoniser l'ensemble.
Côté icônes, dont les origines sont variées, une librairie telle qu'Iconify + choix d'un pack serait une piste intéressante.
Enfin, l'adoption d'une police commune à large couverture de glyphes (ie: Plus Jakarta Sans ) permettrait d'unifier la typo.

Uniformisation des composants

J'ai l'impression que certains élements d'interface n'ont pas de cohésion visuelle.
L'utilisation de composants stylés indépendamment (mentionné en #336) fait qu'il y a une grande diversité de rendus, parfois au sein même d'un groupe de composants. Par exemple: les taille de typo et arrondis de certains boutons diffèrent, les alignements/interlignages/paddings sont inégaux, et il y a des différences notable entre navigateurs (ie: sur Firefox, la suggestion "Installer l'app sur cet ordi" contient 2 tailles de typo, et le texte adjacent à l'icone n'est pas aligné).
À ce que je lis (notamment en fin de discussion sur #201), ça peut rendre la concrétisation d'un prototype plus ardue. Et l'absence de guidelines méticuleusement précises (à la Apple ou Google) fait que chaque création de compose alimente cette diversité / ce manque de cohésion visuelle.

Je suggère de s'appuyer sur un framework de style et un framework de composant ayant déjà fait leurs preuves, qui puisse uniformiser l'expérience utilisateur, et la consistence entre les différents éléments d'interface.
Il est mentionné l'interêt porté pour Next-Yak. J'aurais tendance à suggérer l'adoption de TailwindCSS et d'un framework tel que PrimeReact qui s'appui sur ce dernier. On utilise PrimeVue de notre côté (avec VueJS) et ce sont des composants assez souple pour être adaptés à tous les cas d'usage, et en même temps apporter une uniformisation de l'UI/UX. Tailwind est également assez flexible, et cotoie le CSS sans problème ce qui permet une transition progressive. L'utilisation de classes utilitaire permet un prototypage rapide, et son adoption par beaucoup fait qu'il est facile de trouver exemples de composants (ou de les faire haluciner par votre LLM favorite).

Uniformisation des icones

Dans le même ordre d'idée, les icones sur Cartes n'ayant pas d'origine commune, en dehors de ce qui semble être fontawesome pour certains éléments d'UI, elles présentent des épaisseurs de trait différentes, et des style peu concordants.

Je suggère de s'appuyer sur une (ou plusieurs) librairie d'icones, en plus de celle propre à Cartes (cas des icones maki, temaki et OsmAnd pour les POI par exemple). Je suggère l'adoption de Iconify qui possède un composant React notamment. La contrepartie étant que les icones sont récupérées à la demande (mais dans le cadre d'une application de cartographie qui doit charger les tiles, je pense pas que ce soit un facteur discriminant). Les set d'icones pris en charge peuvent être parcourus sur le site Icones.js, d'où il est même possible d'exporter des SVG individuels si besoin.
Il faut bien sûr trouver le (ou les) set(s) qui correspond(ent) le plus à la direction graphique voulue.

Uniformisation de la typo

Cette section rejoint le besoin d'identité exprimé en #264 et doit surement faire l'objet d'un ticket à part entière, mais je le mentionne ici aussi, parce qu'une police a un impacte sur l'homogénéité visuelle, et peut dicter le rendu de certains composants (padding, vertical-align variant suivant l'interlignage et la chasse de la police utilisée par exemple).
Comme Google ("Roboto"), Apple ("San Francisco"), Here ("FireGO"), Mappy ("Fira"), pourrait avoir sa police de titre (et/ou police de corps). Idéalement, une police ayant un large panel de glyphes couverts serait le mieux, pour éviter les soucis avec l'i18n, et une variante "variable", pour ne pas avoir à inclure une famille de polices trop lourde. Une font comme Plus Jakarta Sans (auto-hébergeable) pourrait faire l'affaire.

Système d'exploitation

No response

Navigateur

No response

### Décrivez votre problème, votre suggestion Tout d'abord: un grand bravo @laem et au contributeurs de ce projet. C'est une belle réalisation, et une excellente alternative aux mastodontes du domaine. Et le fait de vous voir régulièrement documenter l'avance sur Bluesky, c'est top! Quelques petites choses me font un peu ticker à l'usage, d'où ce... ticket 😅 exposant quelques suggestions. Même si plus cablé VueJS, je peux contribuer avec quelques PR si les modifications suggérés ci-dessous vont dans la direction souhaitée. > **TL;DR** > > L'interface de Cartes affiche AMA un manque de cohérence visuelle sur certains aspects. > Les composants UI étant stylés indépendamment, s'appuyer sur un framework comme TailwindCSS + PrimeReact pourrait aider à harmoniser l'ensemble. > Côté icônes, dont les origines sont variées, une librairie telle qu'Iconify + choix d'un pack serait une piste intéressante. > Enfin, l'adoption d'une police commune à large couverture de glyphes (ie: Plus Jakarta Sans ) permettrait d'unifier la typo. ## Uniformisation des composants J'ai l'impression que certains élements d'interface n'ont pas de cohésion visuelle. L'utilisation de composants stylés indépendamment (mentionné en #336) fait qu'il y a une grande diversité de rendus, parfois au sein même d'un groupe de composants. Par exemple: les taille de typo et arrondis de certains boutons diffèrent, les alignements/interlignages/paddings sont inégaux, et il y a des différences notable entre navigateurs (ie: sur Firefox, la suggestion "Installer l'app sur cet ordi" contient 2 tailles de typo, et le texte adjacent à l'icone n'est pas aligné). À ce que je lis (notamment en fin de discussion sur #201), ça peut rendre la concrétisation d'un prototype plus ardue. Et l'absence de guidelines méticuleusement précises (à la [Apple](https://developer.apple.com/design/human-interface-guidelines) ou [Google](https://m3.material.io/)) fait que chaque création de compose alimente cette diversité / ce manque de cohésion visuelle. Je suggère de s'appuyer sur un framework de style et un framework de composant ayant déjà fait leurs preuves, qui puisse uniformiser l'expérience utilisateur, et la consistence entre les différents éléments d'interface. Il est mentionné l'interêt porté pour [Next-Yak](https://yak.js.org/). J'aurais tendance à suggérer l'adoption de [TailwindCSS](https://tailwindcss.com/) et d'un framework tel que [PrimeReact](primereact.org/) qui s'appui sur ce dernier. On utilise PrimeVue de notre côté (avec VueJS) et ce sont des composants assez souple pour être adaptés à tous les cas d'usage, et en même temps apporter une uniformisation de l'UI/UX. Tailwind est également assez flexible, et cotoie le CSS sans problème ce qui permet une transition progressive. L'utilisation de classes utilitaire permet un prototypage rapide, et son adoption par beaucoup fait qu'il est facile de trouver exemples de composants (ou de les faire haluciner par votre LLM favorite). ## Uniformisation des icones Dans le même ordre d'idée, les icones sur Cartes n'ayant pas d'origine commune, en dehors de ce qui semble être fontawesome pour certains éléments d'UI, elles présentent des épaisseurs de trait différentes, et des style peu concordants. Je suggère de s'appuyer sur une (ou plusieurs) librairie d'icones, en plus de celle propre à Cartes (cas des icones maki, temaki et OsmAnd pour les POI par exemple). Je suggère l'adoption de [Iconify](https://github.com/iconify/iconify) qui possède un composant React notamment. La contrepartie étant que les icones sont récupérées à la demande (mais dans le cadre d'une application de cartographie qui doit charger les tiles, je pense pas que ce soit un facteur discriminant). Les set d'icones pris en charge peuvent être parcourus sur le site [Icones.js](https://icones.js.org/), d'où il est même possible d'exporter des SVG individuels si besoin. Il faut bien sûr trouver le (ou les) set(s) qui correspond(ent) le plus à la direction graphique voulue. ## Uniformisation de la typo Cette section rejoint le besoin d'identité exprimé en #264 et doit surement faire l'objet d'un ticket à part entière, mais je le mentionne ici aussi, parce qu'une police a un impacte sur l'homogénéité visuelle, et peut dicter le rendu de certains composants (padding, vertical-align variant suivant l'interlignage et la chasse de la police utilisée par exemple). Comme Google ("Roboto"), Apple ("San Francisco"), Here ("FireGO"), Mappy ("Fira"), pourrait avoir sa police de titre (et/ou police de corps). Idéalement, une police ayant un large panel de glyphes couverts serait le mieux, pour éviter les soucis avec l'i18n, et une variante "variable", pour ne pas avoir à inclure une famille de polices trop lourde. Une font comme [Plus Jakarta Sans](https://github.com/tokotype/PlusJakartaSans) ([auto-hébergeable](https://github.com/iamkentleom/plusplusjakartasans)) pourrait faire l'affaire. ### Système d'exploitation _No response_ ### Navigateur _No response_

laem commented 2026年05月21日 12:38:32 +02:00

Merci pour ton ticket !

En effet, tout le monde ici est convaincu je pense qu'il faut mieux travailler l'expérience utilisateur.

Mais le périmètre de l'app est déjà vaste, plus que ça en a l'air (à titre d'exemple, la partie itinéraire à elle seule est un projet à part entière pour de nombreuses entreprises de transport public qui paient des presta à 500 000 euros tous les x années, or c'est juste un tiers max de cartes.app).

D'où l'importance d'une approche brique par brique, même si derrière guidée par une vision d'ensemble nécessaire pour le design bien sûr.

Donc n'hésite pas à proposer des changements, idéalement d'abord avec un ticket pour qu'on en discute, car le projet a déjà de l'historique et certains designs sont déjà une troisième, quatrième itération passée par une bonne idée. Sur d'autres angles, l'actuel n'est qu'une première itération, un POC, sans trop de reflexion donc avec une marge de d'amélioration très accessible !

Merci pour ton ticket ! En effet, tout le monde ici est convaincu je pense qu'il faut mieux travailler l'expérience utilisateur. Mais le périmètre de l'app est déjà vaste, plus que ça en a l'air (à titre d'exemple, la partie itinéraire à elle seule est un projet à part entière pour de nombreuses entreprises de transport public qui paient des presta à 500 000 euros tous les x années, or c'est juste un tiers max de cartes.app). D'où l'importance d'une approche brique par brique, même si derrière guidée par une vision d'ensemble nécessaire pour le design bien sûr. Donc n'hésite pas à proposer des changements, idéalement d'abord avec un ticket pour qu'on en discute, car le projet a déjà de l'historique et certains designs sont déjà une troisième, quatrième itération passée par une bonne idée. Sur d'autres angles, l'actuel n'est qu'une première itération, un POC, sans trop de reflexion donc avec une marge de d'amélioration très accessible !

laem commented 2026年05月21日 12:42:08 +02:00

TailwindCSS

Hors de question pour moi d'utiliser Tailwind. C'est un langage créé au-dessus du CSS souvent par manque d'effort d'apprendre la spec universelle CSS pourtant très bien faite et moderne dans ses versions actuelles. Tailwind impose d'écrire du code complexe dans des chaines de caratères concaténées dans des attributs class HTML, c'est aberrant. je comprends l'intérêt pour quelqu'un qui se met au HTML et qui n'a pas le temps d'apprendre le CSS, mais soyons honnête, n'importe quelle LLM aux poids libres sait aujourd'hui parfaitement écrire du beau CSS, comme tu le dis bien. Autant écrire à la source, celle que comprend les navigateurs, un langage déclaratif très puissant.

Mais tu as raison sur le manque de mise en commun de nos composants. On itère là-dessus, en essayant de mutualiser nos propres composants. Par exemple, j'ai codé la demande d'autorisation d'utiliser la boussole en réutilisant le bloc de l'install PWA (PWAInstallUI.tsx). C'est à mon avis la marche à suivre. On pourrait exposer tout ça dans un livre de design mais c'est beaucoup de boulot que je préfère personnellement consacrer à implémenter des v1 de nouvelles fonctionnaltiés (le mode GPS par exemple) ou des v3, v4 de fonctionnalités clef (les commentaires de lieux par exemple).

Au-delà de Tailwing, je ne suis pas pour utiliser un framework CSS non plus, car dans mon expérience, pour développer un projet d'ampleur, c'est toujours un frein technique à un moment donné, quand on veut faire un truc qui sort du carcan initial. Il y a forcément un carcan, c'est le principe du framework, sinon CSS suffirait. Je comprends donc le choix d'un framework CSS, mais je pense qu'on a tous les ingrédients pour en obtenir ses avantages dans la stack choisie aujourd'hui. Avec l'avantage à mon avis immense de ne pas être conformiste : de sortir de l'ordinaire par rapport à la ribambelle d'interfaces calées sur le même "material design" imposée par les tergiversations souvent contradictoires dans le temps des géants de l'informatique. CF la controverse du liquid glass chez Apple, ou l'équivalent chez Google et son Material Design "emotion design".

Mais encore une fois, cet avis n'empêche pas qu'on a des centaines de trucs à faire pour rendre l'app plus utilisable. Par exemple récemment, on se disait que sur mobile, il faudrait rendre de nombreux boutons et textes plus gros.

C'est plus ou moins une ligne de CSS avec une media query, mais ça doit être fait et testé.

> TailwindCSS Hors de question pour moi d'utiliser Tailwind. C'est un langage créé au-dessus du CSS souvent par manque d'effort d'apprendre la spec universelle CSS pourtant très bien faite et moderne dans ses versions actuelles. Tailwind impose d'écrire du code complexe dans des chaines de caratères concaténées dans des attributs `class` HTML, c'est aberrant. je comprends l'intérêt pour quelqu'un qui se met au HTML et qui n'a pas le temps d'apprendre le CSS, mais soyons honnête, n'importe quelle LLM aux poids libres sait aujourd'hui parfaitement écrire du beau CSS, comme tu le dis bien. Autant écrire à la source, celle que comprend les navigateurs, un langage déclaratif très puissant. Mais tu as raison sur le manque de mise en commun de nos composants. On itère là-dessus, en essayant de mutualiser nos propres composants. Par exemple, j'ai codé la demande d'autorisation d'utiliser la boussole en réutilisant le bloc de l'install PWA (PWAInstallUI.tsx). C'est à mon avis la marche à suivre. On pourrait exposer tout ça dans un livre de design mais c'est beaucoup de boulot que je préfère personnellement consacrer à implémenter des v1 de nouvelles fonctionnaltiés (le mode GPS par exemple) ou des v3, v4 de fonctionnalités clef (les commentaires de lieux par exemple). Au-delà de Tailwing, je ne suis pas pour utiliser un framework CSS non plus, car dans mon expérience, pour développer un projet d'ampleur, c'est toujours un frein technique à un moment donné, quand on veut faire un truc qui sort du carcan initial. Il y a forcément un carcan, c'est le principe du framework, sinon CSS suffirait. Je comprends donc le choix d'un framework CSS, mais je pense qu'on a tous les ingrédients pour en obtenir ses avantages dans la stack choisie aujourd'hui. Avec l'avantage à mon avis immense de ne pas être conformiste : de sortir de l'ordinaire par rapport à la ribambelle d'interfaces calées sur le même "material design" imposée par les tergiversations souvent contradictoires dans le temps des géants de l'informatique. CF la controverse du liquid glass chez Apple, ou l'équivalent chez Google et son Material Design "emotion design". Mais encore une fois, cet avis n'empêche pas qu'on a des centaines de trucs à faire pour rendre l'app plus utilisable. Par exemple récemment, on se disait que sur mobile, il faudrait rendre de nombreux boutons et textes plus gros. C'est plus ou moins une ligne de CSS avec une media query, mais ça doit être fait et testé.

laem commented 2026年05月21日 12:53:47 +02:00

Je suggère l'adoption de Iconify qui possède un composant React notamment.

Beaucoup d'icônes qu'on utilise sont déjà issues d'Iconify. Mais c'est une librairie géant, hétéroclite. Aucun jeu d'icônes qu'on a testé ne contient tout ce dont on a besoin. Une grande partie des icônes de l'interface sont même modifiés à la main, adaptés pour notre usage :) J'en ai probablement designé ou redesigné déjà 3 bonnes dizanes via Inkscape.

image

Mais oui, une cohérence entre tous ces icônes serait super, mais là encore, aucune librairie sur étagère n'est une solution concrète à notre problème.

> Je suggère l'adoption de Iconify qui possède un composant React notamment. Beaucoup d'icônes qu'on utilise sont déjà issues d'Iconify. Mais c'est une librairie géant, hétéroclite. Aucun jeu d'icônes qu'on a testé ne contient tout ce dont on a besoin. Une grande partie des icônes de l'interface sont même modifiés à la main, adaptés pour notre usage :) J'en ai probablement designé ou redesigné déjà 3 bonnes dizanes via Inkscape.  Mais oui, une cohérence entre tous ces icônes serait super, mais là encore, aucune librairie sur étagère n'est une solution concrète à notre problème.

laem commented 2026年05月21日 12:57:02 +02:00

Concernant la police, j'ai fait le choix réfléchi de ne pas en imposer une à l'utilisateur, car ça implique un téléchargement de plusieurs dizaines voir centaines de ko. Le bénéfice net ne me semble pas évident, car notre app n'a pas tant de texte que ça (ce n'est pas un journal en ligne comme lemonde.fr où la police fait beaucoup). D'autant plus que la carte impose déjà le chargement de plusieurs polices (pas le choix ici, à ma connaissance), incompatible avec la police Web, donc en doublon.

On utilise donc font-family: Helvetica,Arial,sans-serif, qui sont incluses par défaut, ou avec équivalent (par exemple chez moi c'est Nimbus) sur tous les appareils modernes.

Concernant la police, j'ai fait le choix réfléchi de ne pas en imposer une à l'utilisateur, car ça implique un téléchargement de plusieurs dizaines voir centaines de ko. Le bénéfice net ne me semble pas évident, car notre app n'a pas tant de texte que ça (ce n'est pas un journal en ligne comme lemonde.fr où la police fait beaucoup). D'autant plus que la carte impose déjà le chargement de plusieurs polices (pas le choix ici, à ma connaissance), incompatible avec la police Web, donc en doublon. On utilise donc `font-family: Helvetica,Arial,sans-serif`, qui sont incluses par défaut, ou avec équivalent (par exemple chez moi c'est Nimbus) sur tous les appareils modernes.

etienneJr commented 2026年05月21日 14:05:31 +02:00

Merci pour ce ticket et ces propositions !!

@7ute wrote in #2194 (comment):

Uniformisation des composants

Ca serait vraiment super si tu avais un peu de temps à y consacrer ! Mais clairement le code actuel fait que la marche est haute. Il y a déjà plusieurs personnes qui ont dit qu'elles aimeraient participer à améliorer ça, ça serait super chouette si vous pouviez travailler en équipe là dessus ! même si je me doute qu'en pratique ça doit pas être évident de mettre en place une équipe sur un tel projet hobby.

• dans le salon matrix (es tu dessus ?), il y a gnoblet qui en avait parlé (je ne sais pas si il est ici)
• je suis sûr qu'il y a au moins 1 autre personne qui avait posté un message dans un ticket, mais je n'arrive pas à retrouver.

En pratique si vous êtes plusieurs, on peut par exemple créer un salon matrix dédié dans l'espace Cartes pour vous faciliter la tâche, qu'en penses tu ? (on en a déjà plusieurs sur différents sujets, en plus du salon Général)

@laem wrote in #2194 (comment):

ça implique un téléchargement de plusieurs dizaines voir centaines de ko

En pratique ça ferait combien ? (avec le normal, le gras, l'italique, ...) c'est vraiment pas acceptable ? parce que c'est sûr que ça faciliterait le réglage des composants.

Merci pour ce ticket et ces propositions !! @7ute wrote in https://codeberg.org/cartes/web/issues/2194#issue-5206211: > Uniformisation des composants Ca serait vraiment super si tu avais un peu de temps à y consacrer ! Mais clairement le code actuel fait que la marche est haute. Il y a déjà plusieurs personnes qui ont dit qu'elles aimeraient participer à améliorer ça, ça serait super chouette si vous pouviez travailler en équipe là dessus ! même si je me doute qu'en pratique ça doit pas être évident de mettre en place une équipe sur un tel projet hobby. - dans le salon matrix (es tu dessus ?), il y a gnoblet qui en avait parlé (je ne sais pas si il est ici) - je suis sûr qu'il y a au moins 1 autre personne qui avait posté un message dans un ticket, mais je n'arrive pas à retrouver. En pratique si vous êtes plusieurs, on peut par exemple créer un salon matrix dédié dans l'espace Cartes pour vous faciliter la tâche, qu'en penses tu ? (on en a déjà plusieurs sur différents sujets, en plus du salon Général) @laem wrote in https://codeberg.org/cartes/web/issues/2194#issuecomment-15526304: > ça implique un téléchargement de plusieurs dizaines voir centaines de ko En pratique ça ferait combien ? (avec le normal, le gras, l'italique, ...) c'est vraiment pas acceptable ? parce que c'est sûr que ça faciliterait le réglage des composants.

laem commented 2026年05月21日 14:15:25 +02:00

Je viens de tester mappy.fr : 250 ko pour les polices (recherche "font" dans l'onglet réseau)

Mapy.com : 370 ko. Wego.here.com : 530 ko.

C'est massif. Mais pour ces entreprises, c'est un moindre mal : leur version Web n'est presque qu'accessoire et pour certaines, blindées de trackeurs et de pubs.

Notre approche est radicalement différente.

Par contre ça veut pas dire qu'on n'a pas de gros efforts à faire chez nous pour alléger l'app, même si une PR de 100 commits a déjà été faite cette année courante :)

Je viens de tester mappy.fr : 250 ko pour les polices (recherche "font" dans l'onglet réseau) Mapy.com : 370 ko. Wego.here.com : 530 ko. C'est massif. Mais pour ces entreprises, c'est un moindre mal : leur version Web n'est presque qu'accessoire et pour certaines, blindées de trackeurs et de pubs. Notre approche est radicalement différente. Par contre ça veut pas dire qu'on n'a pas de gros efforts à faire chez nous pour alléger l'app, même si une PR de 100 commits a déjà été faite cette année courante :)

waterced commented 2026年05月21日 16:23:10 +02:00

Ces polices sont téléchargée une seule fois ou bien régulièrement ? Car finalement qq centaines de ko c'est l'ordre de grandeur d'une ou deux images (ex wikipédia) d'un carrousel d'une fiche lieu. Ça semble plutôt marginal, non ?

Ces polices sont téléchargée une seule fois ou bien régulièrement ? Car finalement qq centaines de ko c'est l'ordre de grandeur d'une ou deux images (ex wikipédia) d'un carrousel d'une fiche lieu. Ça semble plutôt marginal, non ?

etienneJr commented 2026年05月21日 16:48:29 +02:00

@waterced wrote in #2194 (comment):

Ces polices sont téléchargée une seule fois ou bien régulièrement ? Car finalement qq centaines de ko c'est l'ordre de grandeur d'une ou deux images (ex wikipédia) d'un carrousel d'une fiche lieu. Ça semble plutôt marginal, non ?

Certes il y a normalement beaucoup de choses mises en cache (mais faudrait quand même vérifier que ça marche bien, je n'ai jamais vérifié). Mais dans tous les cas, pour les néo-utilisateurs, il faut à tout prix éviter un chargement initial trop long. Tu peux regarder #1077 et #1366 dans lesquels Maël a documenté pas mal de choses. (ce genre d'analyse serait à mettre à jour car il y a eu pas mal d'optimisations depuis)

@waterced wrote in https://codeberg.org/cartes/web/issues/2194#issuecomment-15622694: > Ces polices sont téléchargée une seule fois ou bien régulièrement ? Car finalement qq centaines de ko c'est l'ordre de grandeur d'une ou deux images (ex wikipédia) d'un carrousel d'une fiche lieu. Ça semble plutôt marginal, non ? Certes il y a normalement beaucoup de choses mises en cache (mais faudrait quand même vérifier que ça marche bien, je n'ai jamais vérifié). Mais dans tous les cas, pour les néo-utilisateurs, il faut à tout prix éviter un chargement initial trop long. Tu peux regarder #1077 et #1366 dans lesquels Maël a documenté pas mal de choses. (ce genre d'analyse serait à mettre à jour car il y a eu pas mal d'optimisations depuis)

severo commented 2026年05月21日 17:48:33 +02:00

Je serais plutôt pour utiliser une webfont, parce que c'est important d'avoir la même identité visuelle pour tout le monde, et ça peut donner un peu plus de caractère. Là, on ne sait pas ce qui va s'afficher, concrètement, et sur mon ordi (Ubuntu), le rendu du texte est un peu "cheap". Je suis d'accord que pour une app de carte, le poids d'une police est négligeable.

Je serais plutôt pour utiliser une webfont, parce que c'est important d'avoir la même identité visuelle pour tout le monde, et ça peut donner un peu plus de caractère. Là, on ne sait pas ce qui va s'afficher, concrètement, et sur mon ordi (Ubuntu), le rendu du texte est un peu "cheap". Je suis d'accord que pour une app de carte, le poids d'une police est négligeable.

laem commented 2026年05月21日 18:54:50 +02:00

Je n'avais pas en tête les différences de rendu entre les OS. C'est si différent que ça ? Il faudrait à mon avis documenter rapidement 1 ou deux fâcheuses conséquences que ça peut avoir, je n'avais pas remarqué ça.

Car au contraire, en termes de réflexion design, je trouve qu'utiliser une police standard, et respecter le choix la diversité des OS (même débat sur les emojis, il y avait une mode d'utiliser une bibliothèque d'image pour remplacer des caractères, mauvaise idée je pense) c'est sympa.

Après je suis pas contre choisir une police, mais ça demande du travail et je ne suis pas d'accord sur le fait que 200 ko c'est négligeable. Ça "annule" pas mal de travail fait pour les gagner. J'ai plutôt l'idée inverse : il faut en gagner encore plus, on a plein de sources de réduction encore.

Je n'avais pas en tête les différences de rendu entre les OS. C'est si différent que ça ? Il faudrait à mon avis documenter rapidement 1 ou deux fâcheuses conséquences que ça peut avoir, je n'avais pas remarqué ça. Car au contraire, en termes de réflexion design, je trouve qu'utiliser une police standard, et respecter le choix la diversité des OS (même débat sur les emojis, il y avait une mode d'utiliser une bibliothèque d'image pour remplacer des caractères, mauvaise idée je pense) c'est sympa. Après je suis pas contre choisir une police, mais ça demande du travail et je ne suis pas d'accord sur le fait que 200 ko c'est négligeable. Ça "annule" pas mal de travail fait pour les gagner. J'ai plutôt l'idée inverse : il faut en gagner encore plus, on a plein de sources de réduction encore.

7ute commented 2026年05月21日 20:37:28 +02:00

Merci pour ces retours!

Concernant Tailwind et PrimeReact,

Sans rentrer dans le bikeshedding...

... de la pertinence de l'utilisation de Tailwind ( ça a déjà été fait là : https://www.reddit.com/r/reactjs/comments/1hey5ma/why_almost_everyone_i_see_uses_tailwind_css_whats/ ), je pense qu'il y a un petite méprise sur la finalité de son utilisation dans un projet comme Cartes. Je ne le suggérais pas en remplacement de tout le CSS, mais juste pour apporter une fondation de style permettant une homogénéités des composants, progressivement et sans friction. Tailwind (comme PrimeReact pour les composant) apportent des jeux de contraintes ajustables, qui permet une homogénéité d'apparence des différents composants. Et par homogénéité, je ne veux pas dire "qui se ressemblent tous", mais "qui n'ont pas plusieurs valeurs de padding / margin / align" différentes au sein d'une même vue / d'un même bloc ou pour deux éléments ayant une fonction identique. Il est tout à fait possible de l'utiliser en parallèle du CSS. Il faut plus le voir comme une sous-couche permettant d'uniformiser les différences entre les navigateurs, et faciliter les ajustements à l'échelle d'un projet, avec plusieurs contributeurs ayant différentes plateforme de production.

Avec l'avantage à mon avis immense de ne pas être conformiste

On peut tout à fait faire de l'original, en se conformant à des principes de design d'IHM, tout comme on peut choisir des palettes de couleurs originales sans sacrifier l'accessibilité pour les malvoyants.
De l'espacement visuel des blocs au crénage des polices, ces frameworks préparent le terrain et au final on n'a plus qu'une poignée de variables à ajuster pour modeler l'interface à souhait (au lieu de devoir passer sur chacun des composants).

On pourrait exposer tout ça dans un livre de design mais c'est beaucoup de boulot que je préfère personnellement consacrer à implémenter des v1 de nouvelles fonctionnaltiés

C'est justement pour cette raison que je suggérais l'utilisation d'une librairie de composants (aussi basique soit-elle). Pour éviter d'avoir à réinventer la roue, devoir re-coder à la main le comportement d'une modale sur 4 plateformes différentes (avec tous les quirks que ça entraine), et se concentrer sur le fonctionnel.

Ceci-dit, je respecte totalement le parti pris de s'en passer :)

/bikeshedding

---

Mais oui, une cohérence entre tous ces icônes serait super, mais là encore, aucune librairie sur étagère n'est une solution concrète à notre problème.

Aucun soucis, c'est plus l'affaire de guidelines dans ce cas: définir des tailles standard (nano, icône, large) et leur épaisseur de trait correspondantes pour éviter ce sentiment de patchwork, et les confusions dans certains cas ("cette icone pleine signifie que c'est actif, ou non?").
Sur un projet sur lequel je travaille, nous nous appuyons sur deux set (Hugicons et Lucid) qui, à tailles d'affichage adaptées, présentent une épaisseur de trait identique ce qui est assez plaisant. Et pour les icones spécialisées que nous avons fait ou fait faire, nous nous sommes assurés qu'elle respectaient les même contraintes.

Concernant les polices :
Les fonts variables sont souvent plus légères que leurs contreparties à poids défini. Par exemple, la font variable Plus Jakarta Sans donnée en exemple fait 350ko complète (càd sans en prendre un sous-jeu de caractères), mais surtout seulement 170ko sans l'italique. Et elle contient toutes les variantes de graisse là où son équivalent statique fait plus d'1,3Mo. Ça peut être chargé après tout le reste avec une stratégie de remplacement post chargement, et ça se dégrade correctement en cas de mauvaise connexion (surtout si la font n'est pas drastiquement différente d'une Helvetica, et est correctement dimensionnée avec le size-adjust qui va bien).

Pour ce qui est des contributions, @etienneJr, ce sera avec plaisir quand j'aurais un petit plus de bande passante :)
Je vais déjà m'installer le projet en local, pour prendre la température.

Merci pour ces retours! Concernant Tailwind et PrimeReact, <details> <summary>Sans rentrer dans le bikeshedding... </summary> ... de la pertinence de l'utilisation de Tailwind ( ça a déjà été fait là : https://www.reddit.com/r/reactjs/comments/1hey5ma/why_almost_everyone_i_see_uses_tailwind_css_whats/ ), je pense qu'il y a un petite méprise sur la finalité de son utilisation dans un projet comme Cartes. Je ne le suggérais pas en remplacement de tout le CSS, mais juste pour apporter une fondation de style permettant une homogénéités des composants, progressivement et sans friction. Tailwind (comme PrimeReact pour les composant) apportent des jeux de contraintes ajustables, qui permet une homogénéité d'apparence des différents composants. Et par homogénéité, je ne veux pas dire "qui se ressemblent tous", mais "qui n'ont pas plusieurs valeurs de padding / margin / align" différentes au sein d'une même vue / d'un même bloc ou pour deux éléments ayant une fonction identique. Il est tout à fait possible de l'utiliser en parallèle du CSS. Il faut plus le voir comme une sous-couche permettant d'uniformiser les différences entre les navigateurs, et faciliter les ajustements à l'échelle d'un projet, avec plusieurs contributeurs ayant différentes plateforme de production. > Avec l'avantage à mon avis immense de ne pas être conformiste On peut tout à fait faire de l'original, en se conformant à des principes de design d'IHM, tout comme on peut choisir des palettes de couleurs originales sans sacrifier l'accessibilité pour les malvoyants. De l'espacement visuel des blocs au crénage des polices, ces frameworks préparent le terrain et au final on n'a plus qu'une poignée de variables à ajuster pour modeler l'interface à souhait (au lieu de devoir passer sur chacun des composants). > On pourrait exposer tout ça dans un livre de design mais c'est beaucoup de boulot que je préfère personnellement consacrer à implémenter des v1 de nouvelles fonctionnaltiés C'est justement pour cette raison que je suggérais l'utilisation d'une librairie de composants (aussi basique soit-elle). Pour éviter d'avoir à réinventer la roue, devoir re-coder à la main le comportement d'une modale sur 4 plateformes différentes (avec tous les quirks que ça entraine), et se concentrer sur le fonctionnel. Ceci-dit, je respecte totalement le parti pris de s'en passer :) `/bikeshedding` </details> --- > Mais oui, une cohérence entre tous ces icônes serait super, mais là encore, aucune librairie sur étagère n'est une solution concrète à notre problème. Aucun soucis, c'est plus l'affaire de guidelines dans ce cas: définir des tailles standard (nano, icône, large) et leur épaisseur de trait correspondantes pour éviter ce sentiment de patchwork, et les confusions dans certains cas ("cette icone pleine signifie que c'est actif, ou non?"). Sur un projet sur lequel je travaille, nous nous appuyons sur deux set (Hugicons et Lucid) qui, à tailles d'affichage adaptées, présentent une épaisseur de trait identique ce qui est assez plaisant. Et pour les icones spécialisées que nous avons fait ou fait faire, nous nous sommes assurés qu'elle respectaient les même contraintes. Concernant les polices : Les fonts variables sont souvent plus légères que leurs contreparties à poids défini. Par exemple, la font variable `Plus Jakarta Sans` donnée en exemple fait 350ko complète (càd sans en prendre un sous-jeu de caractères), mais surtout seulement 170ko sans l'italique. Et elle contient toutes les variantes de graisse là où son équivalent statique fait plus d'1,3Mo. Ça peut être chargé après tout le reste avec une stratégie de remplacement post chargement, et ça se dégrade correctement en cas de mauvaise connexion (surtout si la font n'est pas drastiquement différente d'une Helvetica, et est correctement dimensionnée avec le size-adjust qui va bien). Pour ce qui est des contributions, @etienneJr, ce sera avec plaisir quand j'aurais un petit plus de bande passante :) Je vais déjà m'installer le projet en local, pour prendre la température.

7ute commented 2026年05月21日 20:46:15 +02:00

Et pour illustrer ce que j'entends par homogénéité des fonts / kerning / padding, j'ai fait un petit essai en bricolant la css.
À gauche, l'apparence (en première connexion navigation privée) sur Firefox Mac, à droite, la version avec padding uniformisés, kerning et alignements verticaux ajustés, ombrage inversé, arrondis ajusté et contraste des boutons revus (et un depliant plus discret).

avant	exemple de maquette
avant-firefox	apres-firefox

Et pour illustrer ce que j'entends par homogénéité des fonts / kerning / padding, j'ai fait un petit essai en bricolant la css. À gauche, l'apparence (en première connexion navigation privée) sur Firefox Mac, à droite, la version avec padding uniformisés, kerning et alignements verticaux ajustés, ombrage inversé, arrondis ajusté et contraste des boutons revus (et un depliant plus discret). | avant | exemple de maquette | |-|-| |  |  |

etienneJr commented 2026年05月21日 21:05:27 +02:00

@7ute wrote in #2194 (comment):

Et pour illustrer ce que j'entends par homogénéité des fonts / kerning / padding, j'ai fait un petit essai en bricolant la css.

c'est très chouette ! N'hésite pas à faire des petites PR pour itérer petit à petit, hein, t'as pas obligé de remettre d'aplomb toute l'app d'un coup 😅​

@7ute wrote in https://codeberg.org/cartes/web/issues/2194#issuecomment-15632141: > Et pour illustrer ce que j'entends par homogénéité des fonts / kerning / padding, j'ai fait un petit essai en bricolant la css. c'est très chouette ! N'hésite pas à faire des petites PR pour itérer petit à petit, hein, t'as pas obligé de remettre d'aplomb toute l'app d'un coup 😅​

etienneJr commented 2026年06月08日 08:12:47 +02:00

salut @7ute
finalement est ce que tu auras un peu de temps pour faire une PR avec de premières améliorations ?

salut @7ute finalement est ce que tu auras un peu de temps pour faire une PR avec de premières améliorations ?

7ute commented 2026年06月08日 08:51:32 +02:00

Hello @etienneJr, je suis très pris jusqu'à Juillet.
Je me chaufferais pour une première passe sur le design à ce moment là.

Hello @etienneJr, je suis très pris jusqu'à Juillet. Je me chaufferais pour une première passe sur le design à ce moment là.

laem commented 2026年06月10日 09:15:48 +02:00

(au passage, merci pour l'expression bikeshedding, je ne connaissais pas et j'adore :) )

(au passage, merci pour l'expression bikeshedding, je ne connaissais pas et j'adore :) )

etienneJr commented 2026年07月01日 15:57:46 +02:00

@7ute wrote in #2194 (comment):

Hello @etienneJr, je suis très pris jusqu'à Juillet.
Je me chaufferais pour une première passe sur le design à ce moment là.

Ah mais on est déjà le 1er juillet là ! Je suis impatient de voir tes propositions 😁😇😅

@7ute wrote in https://codeberg.org/cartes/web/issues/2194#issuecomment-16813619: > Hello @etienneJr, je suis très pris jusqu'à Juillet. > Je me chaufferais pour une première passe sur le design à ce moment là. Ah mais on est déjà le 1er juillet là ! Je suis impatient de voir tes propositions 😁😇😅