Recherche avancée

Médias (3)

Mot : - Tags -/image

Autres articles (64)

  • Les autorisations surchargées par les plugins

    27 avril 2010, par

    Mediaspip core
    autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs

  • Support de tous types de médias

    10 avril 2011

    Contrairement à beaucoup de logiciels et autres plate-formes modernes de partage de documents, MediaSPIP a l’ambition de gérer un maximum de formats de documents différents qu’ils soient de type : images (png, gif, jpg, bmp et autres...) ; audio (MP3, Ogg, Wav et autres...) ; vidéo (Avi, MP4, Ogv, mpg, mov, wmv et autres...) ; contenu textuel, code ou autres (open office, microsoft office (tableur, présentation), web (html, css), LaTeX, Google Earth) (...)

  • Support audio et vidéo HTML5

    10 avril 2011

    MediaSPIP utilise les balises HTML5 video et audio pour la lecture de documents multimedia en profitant des dernières innovations du W3C supportées par les navigateurs modernes.
    Pour les navigateurs plus anciens, le lecteur flash Flowplayer est utilisé.
    Le lecteur HTML5 utilisé a été spécifiquement créé pour MediaSPIP : il est complètement modifiable graphiquement pour correspondre à un thème choisi.
    Ces technologies permettent de distribuer vidéo et son à la fois sur des ordinateurs conventionnels (...)

Sur d’autres sites (8733)

  • Revision 30163 : Code mort (normalement)

    24 juillet 2009, par kent1@… — Log

    Code mort (normalement)

  • Revision 36037 : s’assurer que la class ffmpeg_movie est disponible sinon cela ne sert pas ...

    9 mars 2010, par kent1@… — Log

    s’assurer que la class ffmpeg_movie est disponible sinon cela ne sert pas à grand chose

  • 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 ?

Navigation