Recherche avancée

Médias (91)

Autres articles (67)

  • Les vidéos

    21 avril 2011, par

    Comme les documents de type "audio", Mediaspip affiche dans la mesure du possible les vidéos grâce à la balise html5 .
    Un des inconvénients de cette balise est qu’elle n’est pas reconnue correctement par certains navigateurs (Internet Explorer pour ne pas le nommer) et que chaque navigateur ne gère en natif que certains formats de vidéos.
    Son avantage principal quant à lui est de bénéficier de la prise en charge native de vidéos dans les navigateur et donc de se passer de l’utilisation de Flash et (...)

  • Amélioration de la version de base

    13 septembre 2013

    Jolie sélection multiple
    Le plugin Chosen permet d’améliorer l’ergonomie des champs de sélection multiple. Voir les deux images suivantes pour comparer.
    Il suffit pour cela d’activer le plugin Chosen (Configuration générale du site > Gestion des plugins), puis de configurer le plugin (Les squelettes > Chosen) en activant l’utilisation de Chosen dans le site public et en spécifiant les éléments de formulaires à améliorer, par exemple select[multiple] pour les listes à sélection multiple (...)

  • Emballe médias : à quoi cela sert ?

    4 février 2011, par

    Ce plugin vise à gérer des sites de mise en ligne de documents de tous types.
    Il crée des "médias", à savoir : un "média" est un article au sens SPIP créé automatiquement lors du téléversement d’un document qu’il soit audio, vidéo, image ou textuel ; un seul document ne peut être lié à un article dit "média" ;

Sur d’autres sites (6101)

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

    30 avril 2021

    Les 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.

    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 ?

  • Evolution #4749 (Nouveau) : [UX] Comportement des labels : quoi par défaut, quoi ponctuel ?

    27 avril 2021, par RastaPopoulos ♥

    Ce ticket sert à réfléchir et possiblement reconcevoir les choix par défaut pour les labels des formulaires.

    État des lieux

    On le sait, l’ergo c’est normalement beaucoup d’objectif : certains placements, certaines tailles, épaisseurs, etc fonctionnent mieux que d’autres, et ceci est prouvable par tests utilisateurs.

    Or cela fait des années que les tests par eye-tracking montrent que les formulaires sont
    1) lu plus rapidement
    2) avec une meilleure compréhension
    lorsque les labels sont au-dessus des champs.

    Ça ne veut pas dire qu’il faut totalement interdire autrement mais : ça veut clairement dire que ça devrait être le comportement par défaut. Et seulement ponctuellement, par choix explicite, pouvoir mettre les labels sur le côté.

    Par ailleurs les pros de l’ergo (sur base des mêmes tests) préconisent tou⋅tes : dans les rares cas où on met les labels sur le côté, ça devrait être calé à droite sur le champ, pour les mêmes raisons de compréhension.

    Les avantages des labels au-dessus :
    - prouvé que c’est bien mieux compris par tout le monde
    - lecture plus rapide
    - fonctionne de base sur tous les écrans, pas d’adaptation à faire
    - polyvalent et générique sur le contenu des labels : marche mieux quelque soit la longueur, et donc à prioriser dans un contexte multilingue
    => cela correspond bien au maximum de notre utilisation : un CMS multi-lingue, allant enfin vers le responsive, se souciant d’accessibilité.

    Le seul désavantage : allonge la hauteur des formulaires, mais ça n’a un impact surtout que pour les formulaires ayant vraiment vraiment beaucoup de champs, ce qui est rare !
    Quand un formulaire est extrêmement long, il y a même plusieurs méthodes qui peuvent être utilisées sans pour autant passer les labels sur le côté :
    1) placer certains champs sur le même ligne (prénom + nom, etc)
    2) découper le formulaire en plusieurs étapes.

    Proposition pour le futur

    - tous les labels doivent être au-dessus comme comportement par défaut
    - pour certains cas, une classe permet de mettre sur le côté : valable uniquement en grand écran, ça reste au-dessus en mobile first
    - si sur le côté : c’est mieux si aligné sur le champ (donc à droite en LTR)
    - ex de rare formulaire candidat : changement des dates

    Quelques sources

    Tests utilisateurs
    https://www.uxmatters.com/mt/archives/2006/07/label-placement-in-forms.php

    Placing a label above an input field works better in most cases
    Placing labels above input fields is preferable
    In most cases, when placing labels to the left of input fields, using left-aligned labels imposes a heavy cognitive workload on users
    if you choose to place them to the left of input fields, at least make them right aligned

    Chez le très connu cabinet d’ergo Nielsen Group
    https://www.nngroup.com/articles/form-design-white-space/

    We recommend placing field labels above the corresponding text fields [en gras chez eux !]
    it makes the form easier to scan, because users can see the text field in the same fixation as the label. Top placement also allows for longer field labels
    If the labels are too far to the left, it can be difficult to associate the correct label with its corresponding field

    Chez Adobe, ils préconisent de suivre les recommandations de la première source
    https://xd.adobe.com/ideas/principles/web-design/best-practices-form-design/

    Matteo Penzo’s 2006 article on label placement suggests that forms are completed faster if labels are on top of the fields. Top-aligned labels are good if you want users to scan the form as quickly as possible.
    The biggest advantage of top-aligned labels is that different-sized labels and localized versions can more easily fit the UI.
    Takeaway : If you want users to scan a form quickly, put labels above the fields. The layout will be easier to scan because the eye will move straight down the page. However, if you want users to read carefully, put labels to the left of the fields. This layout will slow down the reader and make them scan in a Z-shaped motion.

    Chez une appli de conception d’interface
    https://phase.com/magazine/usability-of-forms/

    from a cognitive point of view, the association is powerful
    Also, the eyes move only in one direction since the scanning is top down as compared to Z shape (left-right and top-bottom) for inline labels
    Design is space efficient and hence adaptable to all resolutions ; in short, responsive in nature
    We also get flexibility regarding the length of labels. This proves useful while working with variable label lengths like multilingual support for applications
    One drawback of this approach is the increased height of the form. However, it can be solved with alternate designs like a grouping of fields or stepper forms

  • Anomalie #4756 (Nouveau) : Régressions liées aux évolutions des styles du privé

    1er mai 2021

    Merci de rapporter ici les régressions liées aux évolutions des styles du privé.
    Pour simplifier je suggère de tout regrouper ici, même les choses concernant les plugins-dist.

    Cela concerne principalement les boutons, les formulaires, les boîtes, le bandeau et les choses indirectement liées.
    Je m’attaquerai à tout cela après la PR sur les listes d’objets.

    Formulaires

    • [ ] Formulaire de traduction : tout est décalé.
    • [ ] Formulaire de dates : il reste des espacements à corriger.
    • [ ] Formulaire instituer : la couleur de fond doit coller aux bords de la boîte.
    • [ ] Formulaire editer_liens : problèmes d’espacements et de lisibilité en général.
    • [ ] Formulaire logo + bigup : le bouton de validation étant caché, le conteneur .boutons visible fait bizarre.

    Boutons

    • [ ] Unifier les boutons de suppression dans les listes d’objets liés (mots-clés, etc.)
    • [ ] Boutons formulaire traitements des images : ajuster couleurs, survol notamment.

    Boîtes

    • [ ] Boîte auteur : la couleur de fond du champ biographie doit coller aux bords.
    • [ ] Boîtes (toutes) : dans une .fiche_objet, régler la marge interne quand il n’y a pas de titre (visible sur la boîte « article proposé pour publication » par exemple).
    • [ ] Boîtes erreurs et cie : aligner le picto sur la 1ère ligne de texte quand il n’y a pas de titre.

    Alertes

    • [ ] Mieux aligner le bouton de fermeture

Navigation