
Recherche avancée
Médias (91)
-
GetID3 - Boutons supplémentaires
9 avril 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Image
-
Core Media Video
4 avril 2013, par
Mis à jour : Juin 2013
Langue : français
Type : Video
-
The pirate bay depuis la Belgique
1er avril 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Image
-
Bug de détection d’ogg
22 mars 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Video
-
Exemple de boutons d’action pour une collection collaborative
27 février 2013, par
Mis à jour : Mars 2013
Langue : français
Type : Image
-
Exemple de boutons d’action pour une collection personnelle
27 février 2013, par
Mis à jour : Février 2013
Langue : English
Type : Image
Autres articles (84)
-
Le profil des utilisateurs
12 avril 2011, parChaque utilisateur dispose d’une page de profil lui permettant de modifier ses informations personnelle. Dans le menu de haut de page par défaut, un élément de menu est automatiquement créé à l’initialisation de MediaSPIP, visible uniquement si le visiteur est identifié sur le site.
L’utilisateur a accès à la modification de profil depuis sa page auteur, un lien dans la navigation "Modifier votre profil" est (...) -
Dépôt de média et thèmes par FTP
31 mai 2013, parL’outil MédiaSPIP traite aussi les média transférés par la voie FTP. Si vous préférez déposer par cette voie, récupérez les identifiants d’accès vers votre site MédiaSPIP et utilisez votre client FTP favori.
Vous trouverez dès le départ les dossiers suivants dans votre espace FTP : config/ : dossier de configuration du site IMG/ : dossier des média déjà traités et en ligne sur le site local/ : répertoire cache du site web themes/ : les thèmes ou les feuilles de style personnalisées tmp/ : dossier de travail (...) -
Configurer la prise en compte des langues
15 novembre 2010, parAccéder à la configuration et ajouter des langues prises en compte
Afin de configurer la prise en compte de nouvelles langues, il est nécessaire de se rendre dans la partie "Administrer" du site.
De là, dans le menu de navigation, vous pouvez accéder à une partie "Gestion des langues" permettant d’activer la prise en compte de nouvelles langues.
Chaque nouvelle langue ajoutée reste désactivable tant qu’aucun objet n’est créé dans cette langue. Dans ce cas, elle devient grisée dans la configuration et (...)
Sur d’autres sites (9055)
-
Anomalie #4813 : Liens "(+) Plus d’info" et "(-) Moins d’info"
7 juin 2021Pour l’instant le + et le moins c’est faute de mieux en attendant les icônes symboliques.
Il faut imaginer que dans l’avenir ça sera remplacé par une icône caret ou autre, qui montrera proprement que le truc est dépliable.Les outlines servent uniquement pour l’accessibilité à la prise de focus. Si dans certaines situations ça fait pas très "joli", c’est pas bien grave, c’est pas le but premier. Là on est dans un groupe de boutons, seules les extrémités ont des arrondis.
Nb : c’est exactement pareil que dans bootstrap, si tu met .btn-link au lieu de .btn-primary dans le 1er exemple, tu auras le même résultat : https://getbootstrap.com/docs/5.0/components/button-group/
-
Evolution #4753 : Styles du privé : listes d’objets (suite des boîtes et des formulaires)
4 mai 2021Un 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
<small></small>
é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 :
-
Evolution #4753 (Nouveau) : Styles du privé : listes d’objets (suite des boîtes et des formulaires)
30 avril 2021Les boîtes et les formulaires ont été visuellement « raccordés » ensembles.
Je pense que logiquement les listes d’objets devraient suivre.
En fait ce sont 3 variations d’un même composant : une boîte avec entête, corps et pied.Pour les listes on peut séparer la question en 2 aspects :
1) L’emballage extérieur¶
Là il s’agirait de reprendre les choix graphiques propres à « l’emballage extérieur » des boîtes et formulaires : bordure, arrondi, espacements.
Exemple sur l’image suivant où les 3 sont visibles (nb : ceux en colonne sont automatiquement « ressérés », d’où la différence de padding etc.)Après en fonction de l’un ou de l’autre, il y aura peut-être lieu d’ajuster le padding ou la taille du titre. Mais pour l’instant ce sont ceux en place.
2) L’intérieur¶
Ensuite je propose de procéder à quelques ajustements à l’intérieur de ces listes.
Je pense que certains choix ont été faits pour s’accommoder du manque de place en largeur à l’époque, et ne sont plus nécessaires maintenant.Pour me faire un idée de ce qui fonctionnerait le mieux, et comprendre les détails visuels qui me gênaient un peu, j’ai parcouru quelques articles de recommandations sur l’ergonomie des data tables.
Alors ils traitent plutot des fonctionnalités de ces tables dans leur ensemble, mais il y a aussi quelques guidelines visuelles intéressantes.- https://uxdesign.cc/data-table-for-enterprise-ux-cb48fb9fdf1e
- https://medium.com/nextux/design-better-data-tables-4ecc99d23356
- https://www.uxbooth.com/articles/designing-user-friendly-data-tables/
- https://uxdesign.cc/lets-design-data-tables-bf065a60e588
Je retiens quelques règles simples :
- Des espacements suffisants et consistants (le padding quoi)
- Une taille de police identique partout (au moins dans le tbody). C’est fatiguant pour l’oeil et moins lisible quand on passe sans arrêt d’un taille de police à l’autre sur une même ligne. Et je ne suis pas sûr qu’il y ait forcément besoin de gras pour certains éléments comme les titres ou autres.
- À quelques exceptions près (id, picto), pas de largeur fixes sur les colonnes, laisser faire le navigateur.
Donc voilà, c’est pas grand chose à ajuster non plus.
Les colonnes des tables ont des classes .importante et .secondaire.
À mon avis elle ne devraient plus avoir d’incidence en vue « normale », mais juste décider quelles colonnes afficher et masquer en vue réduite, dans les colonnes ou ailleurs.Donc dans les grandes lignes ça donnerait quelques chose comme ça (juste une maquette) :
3) Détails¶
Enfin pour ces 3 composants, je propose qu’il y ait une classe modificatrice commune pour produire un affichage compact, c’est à dire ressérer tout le contenu.
Cette classe serait automatiquement appliquée dans les colonnes.Ça pourrait être « compact », mais sur d’autres composants pour varier les tailles je suis parti sur mini / large. Donc mini aussi ?