Recherche avancée

Sur d’autres sites (7250)

• Anomalie #4562 : Suite #4468 : Unification des CSS pour les boutons et les icônes

  9 octobre 2020, par RastaPopoulos ♥

  Ça me fait penser que c’est un bug ergonomique (plutôt grave) qui est reproché depuis le début au style "totalement flat". En effet, quand les boutons on vraiment un aspect visuel de bouton = soit en 3D, soit au moins avec un ombrage, et bien même quand la couleur du bouton ressemble à la couleur du bloc où il est placé : on voit quand même le bouton et on le reconnait comme un bouton.

  Tandis qu’avec le "totalement flat", et bien ça pète complètement le concept visuel du bouton, ça ne se détache plus, et parfois c’est même moche.

  C’est bien pour ça que dans la conception "material design" de Google, même en étant moins 3D brut que les anciennes interfaces, il y a toujours le fait que les boutons doivent se détacher quelque soit leur couleur.

  Du coup ya peut-être (sûrement) une réflexion encore à avoir là-dessus.

  (Je n’ai jamais été pour le totalement flat, justement car je considère les arguments le critiquant très pertinents depuis le début.)

• Evolution #4628 : Intégrer la fonction slugify

  14 janvier 2021, par RastaPopoulos ♥

  Si on reste bien dans le cadre "dev", alors je ne vois que peu de confusion possible : dans nos divers API absolument nulle part on n’utilise le mot "identifiant" dans les fonctions et variables pour parler des autoincréments SQL. On parle soit de "id", soit de "id_objet", soit de "clé", mais jamais d’identifiant, et cela depuis le tout début de SPIP. Même dans une doc plus publique : https://www.spip.net/fr_article5477.html. Les quelques fois où c’est utilisé pour le noyau, c’est que dans du PHPDoc, et ça si on veut être sûr de clarifier, on peut toujours remplacer en masse sans rien casser, pour mettre "ID" ou "Identifiant SQL" à la place.

  "identifiant" est en revanche :
  - la traduction officielle de slug en français pour son sens informatique (les québécois sont plus fort que la "french tech" du gouvernement français, pour les traductions !)
  - utilisé depuis des années dans divers plugins pour nommer un identifiant textuel contrôlable par un humain (ce qu’est précisément un slug)

  En tout cas je ne vois que deux possibilités pour ma part :
  - soit on garde "slug" et on ne traduit rien, et basta :)
  - si on change pour autre chose, alors forcément "identifiant" au regard des arguments ci-dessus

• Nomenclature #4626 (Nouveau) : Renommer le menu "Squelettes"

  13 janvier 2021, par RastaPopoulos ♥

  Un petit pavé en début d’année, comme ça peut-être qu’en décembre on aura un début d’idée de quoi faire. :D

  Constat : dans mon expérience, 100% des gens à qui on apprend à utiliser éditorialement SPIP, admins et rédacs donc, n’ont strictement aucune fichue idée de ce que veut dire "Suqelettes", ni quel est le rapport avec le contenu qu’il y a à l’intérieur. Passer du temps à devoir expliquer un terme qui n’aura jamais aucun sens dans leurs activités quotidiennes est une perte de temps pour tout le monde, et 3 mois plus tard illes l’auront oublié vu que ça n’a de rapport avec rien dans leur vie d’admins/rédacs.

  Le fait de faire une référence à l’histoire technique de SPIP, ça ne parle qu’aux devs/intégrateurices : fort peu de gens par rapport à la masse des admins et rédacs qui vont l’utiliser au quotidien.

  Quand on se retire, en tant que devs/ingégrateurices, alors en gros 99% des utilisateurices de l’interface d’admin sont des gens qui ne savent rien du tout de comment c’est techniquement derrière, et même pour beaucoup qui n’ont jamais choisi spécialement ce CMS, et même allons plus loin : assez souvent qui ne savent même pas quel est le CMS utilisé !

  Et point important : ces gens ne devraient avoir aucune obligation de le savoir pour utiliser pourtant comme il faut l’interface.

  Si on leur apprend, parce que nous on aime SPIP et qu’on est enthousiaste à raconter son histoire et comment il marche, c’est super. Mais ça ne doit PAS être une obligation pour comprendre l’interface du premier coup.

  Mon idée (toute relative, c’est pour démarrer quoi) : revenir à des choses simples et couramment utilisées. Il n’y a aucun intérêt spécial à vouloir être original quand on parle quand même du menu principal d’admin.

  Le fait de changer l’intitulé, va forcément changer légèrement le sens, donc quelques plugins qui s’insèrent dedans devront possiblement être déplacés ailleurs. Mais il me semble que ça restera très à la marge, et que la majorité ça correspond toujours. Ça ne doit pas bloquer pour changer. Donc :
  - Mise en page
  - Présentation
  - …

  Dans WP il y a une entrée principale "Apparence", mais ce n’est justement pas notre cas : il faut un terme plus large, qui couvre à la fois les choix graphiques (changer ou configurer un thème, choisir la boite modale…) et les choix de structuration générale, de navigation (Compositions, Menus…).

  Dans ma tête "Mise en page" est pour le moment le terme le plus vaste qui me vient à l’esprit, et qui regroupe plusieurs notions à la fois, pas juste l’apparence graphique. S’il y a mieux tant mieux, du moment que ça regroupe bien ces différentes notions. L’autre jour sur spip-dev Laurent (c-real) disait surcharger avec ce terme aussi pour ses utilisateurices.

  On ne trouvera sûrement jamais le mot parfait à 100%, mais ça sera toujours 1000 fois mieux que "Squelettes" qui vraiment, après 10 ans à devoir l’expliquer en permanence, ne signifie rien pour personne à part nous.