Recherche avancée

Sur d’autres sites (12465)

• Nomenclature #4626 : Renommer le menu "Squelettes"

  30 avril 2021

  Ça me fait d’ailleurs très penser à un sketch de "La stratégie de l’échec", où il faut apprendre à mal ranger : "Je classe les factures débiteurs dans le dossier Antilope"
  Ya un mot inconnu de la plupart des users, qui ne correspond à rien pour elleux, et on leur demande se souvenir que tel config est dedans, juste par mémoire, et non parce que c’est compréhensible en soi.

  Tiens, bonne analogie :)
  Oui mon impression c’est également que celles et ceux qui s’y retrouvent y arrivent malgré le terme utilisé : on finit par associer « squelettes » avec ces entrées de menu... Parceque c’est comme ça, on a pas le choix.
  Ça ne dispense pas de trouver quelque chose de plus approprié.
  Difficile de trouver un terme court qui recouvre tout ce qu’on peut trouver dans ce menu, mais en tout cas les 2 propositions sont déjà bien plus parlantes (moi toujours une préférence pour « mise en page » pour l’instant).

• Nomenclature #4626 : Renommer le menu "Squelettes"

  30 avril 2021, par RastaPopoulos ♥

  Absolument aucune utilisateurice finale des sites que je fais, ne sait ce qu’est un template quel qu’il soit, donc encore moins un squelettes. Ce sont juste des personnes qui utilisent l’interface pour rédiger, valider des contenus, et configurer des fonctionnalités de leur site (surtout d’affichage).

  La personne veut :
  - configurer l’apparence de la box dans son site => aucun besoin de savoir ce qu’est un squelette/template
  - configurer des menus => aucun besoin non plus
  - configurer la taille et le comportement (lazyload ou pas etc) des images adaptives => aucun besoin non plus
  - configurer les noisettes du site, pour dire quoi afficher sur chaque page => aucun besoin non plus
  - etc etc

  Pour 99% des fonctionnalités qui sont insérées dans ce menu, les gens n’ont donc absolument pas à savoir ce qu’est le terme "squelettes", et on n’a pas à leur expliquer, ça n’a aucun rapport avec leur quotidien et avec cette liste de fonctionnalités. Elles peuvent parfaitement configurer tout ça sans jamais avoir entendu ce terme (et sans même savoir quel logiciel elles sont en train d’utiliser !).

  Avoir des client⋅es/utilisateurices finales qui savent ce qu’est un template et/ou un squelettes SPIP, c’est une infime infime minorité des cas. Les gens qui l’utilisent à la toute fin n’ont pas à savoir ça à priori. Tant mieux si elles connaissent par ailleurs, mais c’est complètement annexe, ça ne doit pas être un pré-requis du tout pour comprendre et utiliser ce menu.

  Ça me fait d’ailleurs très penser à un sketch de "La stratégie de l’échec", où il faut apprendre à mal ranger : "Je classe les factures débiteurs dans le dossier Antilope". Ya un mot inconnu de la plupart des users, qui ne correspond à rien pour elleux, et on leur demande se souvenir que tel config est dedans, juste par mémoire, et non parce que c’est compréhensible en soi.

  Que ce soit pour "Mise en page" ou pour "Présentation", les propositions ne sortent pas de nulle part mais ont une argumentation :
  1) doit avoir un rapport avec la liste des plugins qui ajoutent des choses dans ce menu actuellement
  2) suivant les comparaisons avec les autres CMS du même genre

  C’est suivant ces deux points qu’il faut trouver un terme regroupant le maximum (ça ne collera jamais à 100%). Mais clairement suivant ce "cahier des charges" très basique : le mot "squelettes" n’a aucun rapport.

• Evolution #4468 : Unification des CSS pour les boutons et les icônes

  15 septembre 2020

  @b_b : Super, merci

  @jluc : Ah je pensais qu’on pouvait au moins éditer ses propres tickets sur trac, même sans être admin. Je viens de voir que j’aurais pu le faire moi-même d’ailleurs, mais je me suis encore fait avoir par l’UX : faut d’abord cliquer sur modifier, et ensuite sur la petite icône « changer la description ». Mon cerveau refuse de retenir ce truc.

  Alors en fin de compte j’ai fait en sorte de ranger un minimum, mais en essayant de pas toucher à trop de choses non plus :

  • Tout ce qui a trait aux boutons est dans un nouveau module boutons.css : les boutons de formulaires, les boutons d’action, et la nouvelle classe lambda .bouton.
  • Je n’ai pas touché au bando rapide, donc pour les nouveaux boutons le sélecteur CSS inclus le tag : a.bouton. Je disais que c’est sale parcequ’en dehors des règles de base (reset, typo…), la règle générale c’est d’éviter de cibler un tag en particulier.

  En parlant de rangement, le module icons.css contient aussi les onglets (barre + onglets simples). À mon avis le composant .icone.horizontale|verticale ça rentre dans la famille des boutons, donc à déplacer dans le module boutons.css, et le module icons pourrait ensuite être renommé en onglets.css.
  Mais bon, j’y touche pas, ça pourra faire l’objet d’un autre ticket spécifiquement pour le découpage et le rangement des modules.

  Je vais essayer de boucler ça demain, y a moyen de faire un PR pour tenter de squeezer ça dans l’alpha de la 3.3 amha.
  J’y mettrai un description complète de la prop incluant les derniers correctifs.