Améliorations UI des fiches lieu

[kevinvennitti]

👋

Suite aux échanges sur une nouvelle maquette pour les fiches lieu (accessibles ici sur Figma), voici un tout premier jet d'intégration en CSS directement dans le code de Cartes :

Ce n'est qu'un début, de nombreux points sont encore à traiter :

• [x] Styliser la croix de fermeture
• [x] Supprimer le style du bouton "Y aller" (soulignement)
• [x] Réussir à styliser les icônes existantes en CSS (avec filter() ou autre)
• [x] Uniformiser la liste des détails du lieu :
• [x] Intégrer la première icône de chaque lieu comme icône sur fond bleu dans la liste des lieux :
• [ ] Réorganiser les boutons pour tester deux groupes différents : un groupe "Y aller / Appeler / Site web / Envoyer un mail" (actions directes) et un groupe "Favori / Partager" (méta-actions), l'objectif étant d'avoir le meilleur affichage en fonction des données de chaque lieu :

[kevinvennitti]

Mise à jour disponible ici :

Des questions pour toi @laem :

• Est-ce souhaitable / possible / préférable que les nouveaux styles que j'expérimente (qui s'intègrent pour la plupart dans un design system partagé entre les éléments) soient regroupés dans une feuille CSS ? Ou je continue en inline ?
• Est-ce souhaitable / utile de créer de nouveaux composants (pour Mérimée, pour les numéros de téléphone, etc. à la manière de <Address /> ?)
• J'ai créé un fork (branche "design") : n'hésite pas à me demander si ça t'intéresse de la tester de ton côté un jour 👍

[kevinvennitti]

Mise à jour en vidéo cette fois :

https://github.com/user-attachments/assets/4ba02ab5-c89a-41e9-831c-cbe4ca65aa14

[laem]

Mince je n'avais pas vu ton fork !

Alors pour le CSS j'ai adopté des principes qui me semble optimaux par rapport à tout ce que j'ai testé. Je sais que les opinions diffèrent largement entre les équipes mais personnellement j'apprécie ce mode :

• 1. pour les composants uniques, la balise css={``} de styled-components est parfaite. Si on créée un composant pour l'instant unique mais qui devrait être réutilisé ailleurs dans le futur, le mettre direction dans 2)
• 2. des fichiers de style par convention nommés UI.tsx ou MonComposantUI.tsx qui regroupent des définitions export const MonComposantStylé= styled.xx``
• 3. un style global.css où sont définis les styles très très larges (body, a, h1 etc)

Cette méthode s'affranchit totalement des class="xx yy" et mise un maximum sur le web sémantique en utilisant la balise adéquate. L'utilisation de paramètres de composants évite la multiplication des classes et donne toute la puissance d'un vrai langage.

[kevinvennitti]

Ok parfait, ça me va de suivre cette logique ! Je vais modifier en conséquence 👍

Pareil, quelle est ta logique conditionnelle ?

a) Conditionner l'affichage d'un composant avant son appel dans le code

{uneVariable && <Composant var={uneVariable}></Composant>}

b) Appeler un composant dans le code sans condition, et conditionner le return s'il y a des données ou pas au sein du composant ?

Composant.tsx

export function Composant({ var }) {
  if(!var) return

  return ( ... )
}

(Désolé s'il y a des coquilles, message composé sur téléphone ;) )

[laem]

Bonne question ! Je crois que j'utilise les deux. Je trouve que la deuxième version est plus sympa quand on calcul une variable d'affichage (var = var1 || var2 && var3 > 29) locale à ce composant, et la première version est meilleure quand ton "unevariable" est locale au composant appelant :)

[etienneJr]

Salut @kevinvennitti je découvre seulement aujourd'hui cette issue qui date d'avant mon implication dans le projet (j'avais vu #201 il y a qq temps mais j'avais raté celle là) Et je suis hyper impressionné : le design que tu as préparé est tellement classe, tellement pro ! Je trouve que ça changerait d'un coup la stature de l'app. Je ne sais pas pourquoi ça n'a pas abouti l'an dernier, mais peu importe, j'aimerais vraiment qu'on puisse l'intégrer dans le code aujourd'hui. Est-ce que toi tu aurais du temps pour adapter tes modifs dans le repo actuel sur codeberg ? Si oui, on te donnera les droits pour bosser directement dans le repo, ça sera plus facile que dans un fork pour pouvoir tester en live et contribuer à plusieurs. Si non, bah j'essayerai de le faire, mais c'est tellement pas ma compétence que ça me prendrait sûrement un temps fou de comprendre et transposer, et je crois que je ne saurais même pas par quoi commencer... Qu'en penses tu ? Merci !

[laem]

ça me prendrait sûrement un temps fou de comprendre et transposer,

Justement, il ne faut pas que ça prenne un temps fou, il faut avancer pas à pas, bloc par bloc. Un redesign complet prendra trop de temps et (dans mon expérience) impliquera trop de regressions qui bloquent la mise en ligne.

Par exemple, déplacer les images des lieux sous le bloc d'en-tête qui contient le titre, ce n'est pas anodin car les images sont multiples : Panoramax, Wikimedia, image og, image OSM. De mémoire. Le code qui instrumente tout ça n'est pas parfait et est couteux à modifier, d'où l'importance d'en faire une issue, d'en discuter si possible avec une démo, et de le mettre en ligne indépendamment de tous les autres changements indépendants. Bien sûr pour certains changements, c'est dépendant d'autres éléments, donc il faut les faire en même temps mais c'est plus une exception qu'une règle :)