Je suis super-enthousiaste pour les modifs de maquette, sauf certains aspects des listes d’articles introduits dans a7b8b76f33 (Refacto des listes d’objets).
Essentiellement: je ne suis pas d’accord avec la règle «une seule taille de texte», je ne vois pas ce que ça apporte. Au contraire ça apporte des effets négatifs sur les listes d’articles, sans être pour autant totalement cohérent.
=> Les titres d’articles sont désormais plus petits (14px au lieu de 15px).
=> Mais les sous-titres sont bien affichés plus petit (ce qui immédiatement contredit la règle «une seule taille»)
=> Les dates deviennent énormes (14px au lieu de 10px)
On passe de quelque chose qui était hiérarchisé à quelque chose qui l’est moins, et qui est moins lisible.
Le <strong> des titres d’articles est annulé.
=> La liste est moins rythmée et différenciée.
=> On perd la différence de graisse entre le numéro d‘article et le titre (10. Gras…) qui était du meilleur effet.
=> Le titre d’article est moins visible…
J’avais forcé un height:45px sur la case nologo, qui a disparu, alors qui permettait de forcer une hauteur de ligne minimale même en l’absence de logo. L’ensemble était à la fois plus aéré, et moins irrégulier.
Je ne sais pas pourquoi, mais les largeurs de colonnes sont moins rythmées, la colonne du titre principal est écrasée et la colonne de la date occupe une place énorme.
Ce sont des détails par rapport à l’énorme boulot pour lequel je suis vraiment admiratif et reconnaissant, hein.
Certes, mais des PR avec de nouvelles propositions seraient peut être mieux que de commiter directement des corrections qui ne sont pas forcément partagées ? Ne serait-ce que pour comprendre avec des captures d’écrans ?
sauf certains aspects des listes d’articles introduits
Merci des ces retours argumentés, par contre ça aurait pu être bien de suivre au fil de l’eau car ya eu une PR exprès pour en discuter avant que ce soit fusionné (ça sert à ça les PR :p). Et même sans t’embêter à installer/tester toi-même puisque @tcharlss a pris le temps de faire des captures à chaque avancée dans la PR
mieux que de commiter directement des corrections qui ne sont pas forcément partagées
Ah mais j’avais pas vu les commits en même temps en plus, c’est encore pire que commenter après la PR ça !
Désolé hein mais ça va pas du tout là, vraiment… @tcharlss a fait une branche de dev exprès pour ensuite faire une PR à discuter, où tout le monde a donné son avis argumenté. Et là une fois fusionné, tu commits des modifs inverses sans aucune discussion de PR. C’est pas super poli pour les gens qui ont débattu en amont
Je fais ce que je peux aussi. Je ne sais pas ce que sont les PR, je ne sais pas où les suivre.
Du coup je me doute que c’est pas idéal parce que le post de Charles était important et bienvenu, aussi j’ai fait deux commits séparés (un pour le rythme, un pour la largeur des colonnes), et un mail explicatif sur la liste. Pour les copies d’écran, la dernière fois que j’ai essayé, le mail a été bloqué.
En tant que membre du noyau, dans la forge Git, une fois connecté, tu devrais normalement avoir tous les projets de l’équipe noyau, donc de l’orga « spip », en mode « Suivre » : bouton en haut à droite de chaque projet.
Cela fait, tu es censé recevoir une notification pour chaque Pull Request créé et les commentaires qui s’en suivent. Et donc savoir les discussions en cours.
L’orga « spip » avec les projets à suivre, au moins les plus important : le core, Médias, etc : spip · GitLab
Toutes ces remarques sont valables, les changements introduits sur les listes sont bien entendus sujets à discussion.
Par contre j’avais :
D’abord fait un ticket pour expliquer et présenter ces changements. Toutes les remarques que tu soulèves y ont été adressées. Et j’avais bien attendu d’avoir des retours et un « bon pour accord » avant de commiter quoi que ce soit.
Après le ticket il y a eu une PR, avec à nouveau les explications et les motivations derrière chaque changement. Elle est aussi restée ouverte le temps nécessaire pour récolter et prendre en compte les avis, faire les modifs en fonction de ces retours, etc.
Et donc je me permets de subodorer que tu ne les as pas vus, sinon je suis sûr qu’on aurait eu des discussions supers intéressantes pendant le processus de validation et surtout avant d’intégrer la PR.
Et donc là, j’ai un peu l’impression qu’après chaque changement d’interface, même en faisant tout bien pour que tout le monde puisse donner son avis -quitte à ne pas être d’accord, ce qui fait partie du jeu-, et bien ça ne suffit pas. Il y a des commits qui tombent après comme si de rien n’était, et on est mis devant le fait accompli. Comme si tous les efforts entrepris pour bosser collégialement ne servaient à rien.
Bref, ces remarques ne sont pas sur les changements que tu as introduits, pour l’UX/UI tout s’argumente et ce discute, mais c’est la méthode qui est un peu décourageante, pour être honnête.
Et une pull request, c’est une demande de fusion entre deux branches Git en gros. C’est-à-dire qu’on fait le développement D’UNE avancée précise dans une branche git de dev, càd pas dans le « master », par exemple une branche « dev/issue_123 » ça c’est une branche pour corriger un ticket existant, ou « dev/ma_super_fonctionnalite » si c’est pour un ajout fonctionnel qui n’a pas de ticket lié. Et ensuite quand on pense que la branche est testable par les autres, on faire une PR pour en discuter : depuis l’interface de la forge il y a un bouton pour ça, où tu configures entre quelle et quelle branche est la PR. Ensuite on met un descriptif, et ensuite on peut tous débattre de la modif proposée.
Charles, encore une fois, je répète toute mon admiration et ma reconnaissance pour ton boulot, c’est incroyable le boulot que tu as fait. Et à nouveau, je m’excuse de poster mes modifs de cette façon, mais pour l’instant je ne sais pas faire autrement. J’essaie d’apprendre (la dernière fois tu te souviens que j’ai mis un bazar juste épouvantable), mais entretemps je poste mes contributions en essayant de les expliquer par les voies que je connais (le mail).
Ah et j’ajoute : évidemment on peut se prévoir une visio pour t’aider ! En premier lieu pour être sûr que tu aies toutes les notifs importantes qui concerne le noyau et les plugins-dist afin que tu participes aux discussions sur les PR. Et dans un deuxième temps pour que tu saches en faire toi-même.
