[UI] Suggestion: Uniformisation de l'interface / experience utilisateur
publié le , mis à jourDé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
laem
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 !
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
classHTML, 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é.
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.
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
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.
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
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 ?
@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
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 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
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 :)
</details>/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 Sansdonné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.
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 @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 😅
salut @7ute finalement est ce que tu auras un peu de temps pour faire une PR avec de premières améliorations ?
Hello @etienneJr, je suis très pris jusqu'à Juillet. Je me chaufferais pour une première passe sur le design à ce moment là.
(au passage, merci pour l'expression bikeshedding, je ne connaissais pas et j'adore :) )
@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 😁😇😅
Liombe
@7ute Je suis grave motivée pour faire une refonte ou à minima uniformiser l'UI de l'app.
Je suggère une base avec Ark UI, qui est un set de composants headless où on pourra faire notre propre CSS, mais avoir des composants qui respectent déjà les normes d'accessibilité.
Ensuite la création de tokens design (palette de couleurs, gap, bg, text, radius...) avec lesquels ont pourra implémenter des composants de base à réutiliser dans toute l'app.
@Liombe je ne pense pas que la bonne méthode soit de refondre l'app. C'est un travail trop important et pas assez ciblé.
Mieux vaut identifier un problème dans un composant, le régler et expliquer pourquoi l'ajout d'une bibliothèque tierce aide, et ensuite itérer.
@laem L'utilisation d'une bibliothèque tierce aide à ne pas réinventer la roue pour chaque composant, c'est un vrai gain de temps. Aussi ça permet d'avoir un cadre et de mieux garantir l'homogénéité de l'UI. Enfin, certaines librairies ont déjà des comportement d'accessibilité poussée, ce qui est un plus je trouve pour un outil ouvert à tous.
Ce que je propose avant tout c'est de mettre à disposition un set de composants qu'on utilisera comme des legos. Ce qui dimuera la charge mentale de penser les petits éléments d'UI.
Je ne dis pas qu'il faut faire une grosse branche de release, mais cette transformation UI doit se commencer au niveau des fondations et pas composants par composants pour qu'elle soit efficace.
Quelques exemples d'UI qui pourraient bénéficier de centralisation
Titres et textes
Des font-size très proches les unes autres et pas souvent les mêmes quand ce sont des petits textes
Boutons Pas le même radius, même taille, couleurs, parfois le hover n'est pas définit
Listes
Overlays
L'utilisation d'une bibliothèque tierce aide à ne pas réinventer la roue pour chaque composant,
Je comprends ton point de vue, mais on ne réinvente pas vraiment la roue, car on se base sur les standards du Web au maximum. Cet article sorti la semaine dernière montre bien à mon avis à quel point les éléments natifs du Web sont déjà des petites merveilles de complexité, notamment pour l'accessibilité, dans son sens large.
En allant sur ark-ui.com, le premier composant exposé est un accordéon... qui n'utilise pas le composant natif
<details/>du Web.Il est composé de
<div><div><button/><div/>[...].Ça pourrait se défendre s'il y avait un gros en-tête orange disant "Sachez que le composant
<details/>du Web existe mais pour ces raisons x, y nous vous déconseillons de l'utiliser au profit de notre composant et ses centaines de lignes", mais je ne vois pas de mention de cette balise :/Il y a sûrement des bibliothèques CSS qui tâchent de réduire la taille de leur code et donc maximiser rigoureusement l'utilisation des standards du Web, mais je trouve que le gain par rapport à la friction qu'introduit le branchement d'une de ces bibliothèques est assez faible, par rapport à simplement utiliser des composants CSS.
Les possibilités de CSS évoluent constamment, on n'en utilise aujourd'hui qu'une petite partie :)
Bien sûr, il y a plein de composants, balises et fonctions CSS manquantes, pour tout ça, on peut intégrer des composants déjà faits.
Au sujet de notre projet : oui sur cartes.app on a beaucoup de boutons différents, et certains se chevauchent, c'est clair, tu as raison.
Mutualisons-les brique par brique, en créant des fichiers UI.tsx globaux pour ce qui est générique, locaux pour quand c'est des codes visuels propres à des segments de l'app (par exemple le dossier /bookmarks que je travaille dans la branche
gps), vianext-yaknotre librairie à la styled-components. Avançons pas à pas, car chaque composant peut avoir besoin d'un design unique, quand d'autres méritent d'être partagés.Au sujet des polices, on a commencé une discussion sur les problèmes de la gestion actuelle des polices dans le ticket #2387.
Pour les couleurs on a un début de palette dans globals.css, qui était déjà une grosse étape d'amélioration de notre gestion des couleurs, et qui permet en une ligne de changer le thème bleu vers une autre couleur (on n'a jamais utilisé cette possibilité cependant).
@laem Je suis complètement d'accord avec toi sur la maîtrise du CSS, personnellement je n'utilise pas de librairie quand j'en code.
Ark UI ou autres librairies de composants headless ne proposent que des comportements JS qui pourrait nous aider notamment pour tout ce qui est tooltip, popover, dropdown etc... Je ne pense pas utiliser tout Ark UI, en effet la balise details pour des accordéons fait déjà le taff
Et pour ce qui est de réinventer la roue, je ne parle pas que des éléments HTML par exemple le dropdown de langue de l'app, mais aussi du CSS. Les titres et paragraphes de beaucoup de sections / feature ont un CSS local au composant où ils se situent.
La palette actuelle est un bon début mais elle a des limites. Notamment rien n'indique quelle couleur de texte peut aller sur quelle couleur de fond. On ne sait pas quelle couleur utiliser pour le hover ou pour le active, ou encore pour le texte secondaire.
On peut commencer petit par exemple les boutons, il n'y aura pas de Ark UI, juste du CSS.
par exemple le dropdown de langue de l'app
Oui c'est un bon exemple de composant à améliorer, cf ce commentaire.
Salut, je lis cette conversation avec 3 jours de retard, et je suis embêté, j'ai l'impression que ça fait plusieurs fois que :
- quelqu'un arrive plein de bonne volonté et une motivation d'enfer
- il propose d'utiliser un framework (je sais même pas si c'est le bon terme)
- Mael dit bof
- et ça s'arrête là, la motivation est retombée d'un coup 😥
En général, j'adore ces situations où il faut chercher un compromis entre des gens pas d'accord, mais là je suis d'autant plus embêté que je ne comprends tellement rien techniquement que je suis incapable de faire des propositions de compromis.
ou alors j'ai rien compris à la conversation et @Liombe et @7ute vous êtes ok avec @laem et vous restez motivés ? Est-ce qu'il y a besoin, pour se mettre d'accord et mettre les choses au clair, de formaliser les principes avec lesquels on veut coder l'UI de cartes.app ?
@laem pour la pérennité, et faciliter les contributions futures sur l'UI, je pense qu'il y a quand même grand besoin d'adopter "quelque chose" qui rende la contribution UI facile. Je ne sais pas si ce "quelque chose" doit être un framework ou juste des principes écrits, ou un truc intermédiaire, mais ça me parait nécessaire.
Tu as raisons, je n'ai peut-être pas assez posé à l'écrit les principes de développement que je veux promouvoir ici. J'avais copié-collé discrètement un guide que j'avais rédigé pour l'équipe NosGestesClimat ici https://codeberg.org/cartes/principes-dev/src/branch/main/LISEZMOI.md.
Je viens de commencer à l'adapter et le MAJ pour cartes.app.
Sur le sujet précis qui anime cette discussion : en bref, proposer d'intégrer un framework design comme première étape d'une contribution à notre projet d'ampleur qui a déjà 3 ans d'historique, ça pose le risque de conduire à des débats sans fin, car les implications sont nombreuses (centaines de fichiers, poids de l'application, qui pour nous est 100x plus contraint que pour Google Maps, oui 100 x, quelques mo vs ~ 1 go), etc.
Le guide insiste sur l'itération, et c'est valide sur le dev comme sur le design. Ma PR sur le GPS illustre exactement ce qu'il faut pas faire 😅. Je suis très distrait en ce moment, j'essaie de converger en mettant en ligne une version partielle dès que je peux.
@etienneJr wrote in 2194#issuecomment-18387824">https://codeberg.org/cartes/web/issues/2194#issuecomment-18387824:
@7ute wrote in #2194 (commentaire):
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 :grin::innocent::sweat_smile:
Alors, en effet, je me suis pas trop chauffé, étant donné les discussions en cours ^^'
J'ai regardé rapidement (maintenant que la contribution au projet est débloquée sur Mac - merci @severo sur #1646) et en substance, je comprends les réticences de @laem concernant la "friction qu'introduit le branchement d'une de ces bibliothèques". La stack du projet est assez inflexible, et là où sur deux des projets que j'ai dû refondre graphiquement, il s'agissait juste de glisser une ligne de code dans la config Vite pour avoir un framework, et une autre pour du css JIT (UnoCSS), il semblerait qu'avec Turbopack ce soit galère (et ça à l'air d'être le cas pour d'autres ).
Comme mon temps de dispo en ce moment est assez limité, je ne pense pas me lancer dans la cuisine de la stack, ni pousser des morceaux de CSS qui ne vont rien solutionner en l'état ("Il y a 18 styles différents de bouton! Je vais un créer un pour les unifier! Il y a maintenant 19 styles de boutons!" - XKCD)
Voilà les deux suggestions d'approches qui font sens à mes yeux (pour étoffer ce que dit @etienneJr dans son dernier post d'ailleurs) :
- Première approche : Framework / Tooling CSS: @laem ou un contributeur arrive à faire du code-fu pour l'inclure à la stack. Après congratulage, les nouvelles contributions se font avec, et petit à petit les anciens composants sont "rénovés" pour coller aux guidelines. Ma préférence est là. Gros effort de bootstrapping, mais simplicité pour la suite.
- Seconde approche: Les règles de composants et le tooling sont établies et référencées dans un kitchensink sur un Storybook ou un Figma/PenPot. Les nouvelles contributions s'appuient dessus. Petit à petit, chaque composant est ajusté pour être uniformisé et les ajustements sont répercuté sur le code. C'est plus chronophage sur le long terme, mais mène peu ou prou au même résultat.
Sidenotes : quelques avis sur des bouts sur cette longues discussion :
on ne réinvente pas vraiment la roue, car on se base sur les standards du Web au maximum
Je pense que c'est un Non sequitur: se baser sur les standards du web n'empêche pas chaque contributeur d'avoir à faire à la main le design d'un composant, en se basant sur son propre environnement ("ça rend bien chez moi") et c'est ce qui a mené à l'interface de Cartes (et à mon post initial). ie: Définir un bouton simple, un bouton "accentué" n'empêche en rien un contributeur de créer son propre bouton déroulant. Par contre, s'il s'appuie sur le design du premier en ne faisant que l'agrémenter fonctionnellement, et sans avoir à le réecrire visuellement dans son intégralité, ça servira l'application qui aura une apparence plus cohérente. Vous utilisez des "classes", qui servent plus ou moins à ça, en plus du CSS-in-JS, peut-être faut-il les "imposer" (guidelines + l'une des propal du dessus) ?
centaines de fichiers, poids de l'application
La mise en cache par les devices et, le fait que, les tiles de la carte sont bien plus lourdes, font que je pense que l'impact est très limité. Cf. la discussion sur les polices. Le trade-off est AMA bénéfique. Aussi, le fait que le code (et les styles) soit découpé en plusieurs fichier me semble bénéfique, en permettant d'avoir des unités cacheable plus nombreuses, et donc un nombre de fichiers modifiés (et donc à télécharger de nouveau par l'utilisateur) plus réduit après chaque déploiement.
[/pavé - déso]
Bon, je suis bien perdu techniquement, mais je comprends que :
- la 1ère approche est trop de boulot d'un coup au début
- le 2e approche correspond plus à la demande de Maël de travailler par itérations
c'est ça ?
@Liombe tu avais fait plus haut plein de captures d'éléments problématiques. Est-ce que tu serais partant pour choisir 1 menu de l'app (celui que tu veux, mais juste 1 menu) et le retravailler, en mettant en place ce qui va bien pour que les contributions suivantes puissent s'appuyer sur ce que tu as fait ? Comme ça on commence par 1 menu et on voit ce que ça donne ?
@etienneJr Les deux approches permettent d'itérer. La première demande un bricolage de la stack, et la seconde plus d'entretien au long terme car il faut maintenir à jour les composants et outils chartés. Dans les deux cas, (et passé la phase d'adaptation de la stack dans le premier) les modifications de la base de code peuvent se faire petit à petit, au grès des disponibilités / motivations.
Sur l'un des deux projets mentionnés dans mon post précédent, le code "dette historique" côtoie sans problème les nouveaux composants (et classes utilitaires). Dans ce cas, on les a préfixées, et donc toute classe commençant par "tw-" est un utilitaire Tailwind / Uno (dans ce style). Idem pour le framework, les nouveaux composants sont créés avec, et lorsqu'on re-passe sur les anciens, on les adaptes. C'est assez souple comme fonctionnement.
parfait ! et donc, est-ce que vous êtes prêt à vous lancer dans ces conditions ? ou bien il y a encore quelque chose qui vous freine ?
Au passage, j'ai fait une adaptation avec des classes utilitaire d'un petit composant (
components/comments/Avatar.tsx- ici avec les classes non-préfixées), pour donner un exemple avec du code existant, l'histoire de se faire une idée plus précise de leur potentielle utilité.Quelques remarques :
- En regardant un bloc, on voit son style d'un coup d'oeil, ça réduit la gymnastique occulaire.
- Tous les espacements sont uniformisés (
gap-2,mb-2,lesautrestrucsen-2feront toujours la même taille, et celle-ci est facteur d'une unité de base. Changer cette unité de base permet d'adapter tout le projet d'un coup, et le fine-tuner) - L'IDE sait, peut suggérer et "hint" les éléments en cas de doute. Il affiche les couleurs du projet pour éviter les confusions, et permet aux LLM qui bouffé ces utilitaires en long en large et en travers de générer du code (si c'est votre truc…).
- Ces utilitaires peuvent tout à fait être faits à la main, comme suggéré par @Liombe, mais du coup, on s'assoit sur les aides de l'IDE, le tree-shaking, etc (sauf à coder ses plugins pour IDE, …).
Je pensais avoir été clair ci-dessus : pas de pseudo-CSS dans des classnames à rallonge, pas de Tailwind, pas de nouvelle dépendance globale, framework CSS ou autre. Pas de réécriture même partielle en Vue ni en Astro ni en Svelte, ni en Rust.
Les composants CSS qu'on utilise actuellement sont tout à fait à même de nous accompagner dans ce projet. Gardons cette logique de composants CSS / React et mettons en commun les composants dans le projet quand c'est pertinent, plutôt que de copier coller et remixer des classnames.
Si un jour ces technos deviennent un plafond de verre pour la progression du projet, on évoluera.
@etienneJr wrote in https://codeberg.org/cartes/web/issues/2194#issuecomment-19995550:
parfait ! et donc, est-ce que vous êtes prêt à vous lancer dans ces conditions ? ou bien il y a encore quelque chose qui vous freine ?
@laem wrote in https://codeberg.org/cartes/web/issues/2194#issuecomment-20000635:
[…], on évoluera.
Et je me ferais un plaisir à ce moment là de contribuer.
@etienneJr Toujours motivée, j'attendais justement le weekend pour faire un showcase de l'utilisation des boutons.
Je suis globalement d'accord avec @7ute, donc je vais éviter de paraphraser. La stratégie que j'ai en tête c'est :
-
Construire les composants atomiques (boutons, input, chips, avatars...), notamment au niveau de l'utilisation des tokens css. Ensuite on pourra faire prendre des composants plus gros (popover, tooltip, dropdown...) qui demandent plus de JS.
-
Mettre à disposition un kitchen sink très sommaire pour l'instant. J'ai déjà commencé avec les boutons justement
-
Remplacer tous les composants au fur et à mesure, migrer les devs spécifiques vers ces composants qu'ils utiliseront comme base. Ce que j'ai fait notamment pour les boutons de connextion Bluesky et Comaps. Comme ça chaque bouton à un hover, un active, un même disablede etc...
Le mieux bien sûr d'écrire aussi des guidelines d'implémentation et d'utilisation. Toujours dans l'exemples de boutons, si c'est une action principale, on va éviter d'utiliser le size xs, variant ghost.
-