Revisions : SPIP

Les articles publiés sur le site

• Evolution #4753 : Styles du privé : listes d’objets (suite des boîtes et des formulaires)

  4 mai 2021

  Un point étape.
  Cette fois-ci j'aimerais bien un historique pas trop cassé, donc discussion avant de balancer du code.
  Maintenant les captures ne sont plus des maquettes, mais du vrai code.

  Emballage extérieur¶

  Donc pour la partie « emballage extérieur », les boîtes, formulaires et listes sont unifiés et réutilisent les mêmes variables CSS.
  Elles ont toutes une variante .mini pour tout ressérer. Cette variante est automatiquement appliquée en certains endroits (dans les colonnes, etc.).

  

  Intérieur¶

  Pour l'intérieur, j'ai donc appliqué ces quelques règles :

  • Padding un peu plus grand
  • Plus de largeur fixe, à l'exception de quelques colonnes précises (id, statut, picto)
  • Même taille de texte dans toutes les colonnes, à l'exception des éventuels

  Dans les colonnes latérales (.lat), toutes les colonnes du tableau sont masquées à l'exception des .principale et de quelques autres choisies à la main (id, statut).

  J'ai testé avec toutes les listes de la dist, il faudra bien continuer à tester avec d'autres cas de figure.

  

  Listes, formulaires et +¶

  Le sujet des listes objets-lies et objets-associer m'a amené à déborder un peu du sujet initial. Mais tout est un peu lié, un sujet en amène un autre.

  Donc ces 2 listes sont utilisées dans le formulaire editer_liens, j'en ai profité pour essayer de le remettre d'aplomb.
  Là j'ai vu qu'avec l'apparence par défaut (bordure grise + fond blanc), quand plusieurs formulaires de liens se suivaient, on avait du mal à voir où finissait l'un et où commençait l'autre (pas de capture, croyez moi sur parole :).
  En mettant un fond gris, on les distingue beaucoup mieux.
  Et j'ai bien insisté quand ils sont "dépliés", pour distinguer les 2 zones.

  

  

  Mais ça a également un autre avantage : en scannant la fiche objet dans son ensemble, on voit mieux où commence le « vrai » contenu de l'objet, par rapport aux bidules de configuration (date, liens, etc.).
  D'abord les formulaires et autres sur fond gris, puis ensuite le texte de l'objet.

  Donc je pense qu'on pourrait généraliser ça : au lieu de dire « les formulaires editer_liens sont sur fond gris », on pourrait étendre à « tous les formulaires ajoutés par afficher_milieu sont sur fond gris ». Ça reste une règle graphique assez légère, normalement ça ne devrait pas poser de problème avec les formulaires à cet endroit.
  Le problème c'est qu'actuellement il n'y a aucun moyen de cibler en CSS ce qui est ajouté par affiche_milieu, il faut encapsuler tout ça dans un div.afficher_milieu (ce que j'ai fait pour tester le principe).

  Et donc, la fiche objet dans son ensemble pour illustrer :

  

  Ah, et un test pour le formulaire de traductions :

  

• Anomalie #4765 : Listes d’auteurs : liens de messagerie en 404

  4 mai 2021

  La description de auteur_lien_messagerie dit :

  1. si la messagerie est activée [...], lien vers la messagerie interne
  2. sinon lien vers un email
  3. sinon rien

  Mais en l'absence du lien de messagerie, moi j'ai jamais le 2). Et de toute façon les emails sont déjà affichés dans une colonne suivante.
  Donc la colonne entière semble n'avoir d'effet que si le plugin est présent.

  Si on peut éviter les colonnes vides c'est mieux, ça fait des espacements disgracieux (j'ai vu ça en travaillant sur les styles des listes d'objets).

• Anomalie #4765 : Listes d’auteurs : liens de messagerie en 404

  4 mai 2021, par b b

  Captures avant/après.

• Anomalie #4765 (En cours) : Listes d’auteurs : liens de messagerie en 404

  4 mai 2021, par b b

  Je vois que c'est aussi utilisé dans la liste des visiteurs, j'ai testé en conditionnant les colonnes concernées dans la liste, ça fait que le nom de l'auteur est plus proche de son picto de statut, pas bien grave je pense. Autre piste, comme ça passe forcément par `auteur_lien_messagerie()` on pourrait effectuer le test dans cette fonction directement, mais ça laisserait les colonnes en question vides dans les listes. Votre avis ?

  PS : l'avantage de fixer ça dans la fonction, est qu'on corrige aussi les éventuelles listes définies dans les plugins.

• Evolution #4766 : Passer le menu d’ajouts rapides dans un sous-menu

  4 mai 2021, par RastaPopoulos ♥

  Cédric commentait :

  c'est un bandeau d'accès rapide à l'écriture de contenus : c'est pas pour planquer les trucs dans un sous menu, donc ça me parait une mauvaise idée en terme d'interface même si ça semble plus simple pour les devs

  Ce sur quoi je ne suis pas d'accord :)

  C'est un bandeau d'accès rapide essentiellement pour créer un nouveau contenu, au final jamais personne n'y a mis autre chose que de la création. Donc pas pour n'importe quels accès rapides : que de la création, c'est super cohérent.

  Ce menu permet donc de créer sans quitter la page actuelle, c'est-à-dire sans naviguer sur plusieurs pages + devoir chercher et trouver un autre lien sur ces autres pages (exemple, aller dans Édition (ou autre) => Patates puis ensuite trouver un lien).

  Le fait que ce soit une entrée unique qui se déroule n'est pas planqué du tout :
  1) c'est plus facilement identifiable, car UN bouton à connaitre quand on veut accéder à une création sans quitter la page : réduction de la charge mentale, ya pas plein de choses affichées, sans label en plus, mais un seul : plus facile à former, et plus facile à mémoriser ensuite quand on l'a utilisé une fois
  2) à l'intérieur du sous-menu, on a désormais des labels pour chaque entrée, donc là aussi, bien plus facilement accessible à tout le monde, il n'y a pas à se souvenir des icones, ni a les compter comme RealET (cliquez sur la 3ème icones etc : super BAD pour la formation justement, le fait qu'il n'y ait pas de label), là une fois le menu ouvert, tout le monde sera capable de s'y retrouver sans l'aide de la formatrice

  Bref, c'est mieux. :)