Recherche avancée

Médias (2)

Mot : - Tags -/kml

Autres articles (39)

  • Keeping control of your media in your hands

    13 avril 2011, par

    The vocabulary used on this site and around MediaSPIP in general, aims to avoid reference to Web 2.0 and the companies that profit from media-sharing.
    While using MediaSPIP, you are invited to avoid using words like "Brand", "Cloud" and "Market".
    MediaSPIP is designed to facilitate the sharing of creative media online, while allowing authors to retain complete control of their work.
    MediaSPIP aims to be accessible to as many people as possible and development is based on expanding the (...)

  • Ajouter notes et légendes aux images

    7 février 2011, par

    Pour pouvoir ajouter notes et légendes aux images, la première étape est d’installer le plugin "Légendes".
    Une fois le plugin activé, vous pouvez le configurer dans l’espace de configuration afin de modifier les droits de création / modification et de suppression des notes. Par défaut seuls les administrateurs du site peuvent ajouter des notes aux images.
    Modification lors de l’ajout d’un média
    Lors de l’ajout d’un média de type "image" un nouveau bouton apparait au dessus de la prévisualisation (...)

  • Websites made ​​with MediaSPIP

    2 mai 2011, par

    This page lists some websites based on MediaSPIP.

Sur d’autres sites (7819)

  • Evolution #3589 (Fermé) : Modification au pointage des résultats de recherche...

    9 mars 2021, par cedric -

    J’ai intégré en adaptant parce que :
    - le patch proposé est buggué en se basant uniquement sur $regs[0][0] qui est le premier résultat trouvé : il faudrait donc itérer sur chaque résultat
    - pour le résultat multi-mots, l’algo ne marche pas si bien car si par exemple je cherche "tempete de sable" le "de" est supprimé des regexp car trop court, et donc je n’ai que des match sur tempete et sable
    - la distinction mot entier/partie de mot est quand même lourde car il faut donc refaire une preg dans un foreach (sans oublier d’échapper le résultat pour reconstruire une preg) et discutable car si je trouve "baton" dans le mot "batons" au pluriel en quoi ce serait moins bien que dans "baton" au singulier ? Il faudrait donc pousser plus loin l’analyse ce qui va in fine être très couteux

    Tout bien pesé et regardé, j’ai donc tiré la substantifique moelle du patch qui est de dire "plus le résultat trouvé est long mieux c’est" et ça donne https://git.spip.net/spip/spip/commit/c1ab59cb72c77102ea9b75309c2062ab8d8aa51a : je pondère le poids par la longueur totale des matchs trouvés et non par le nombre de match.

    Effet de bord, tous les #POINTS vont fortement augmenter, si quelqu’un utilisait un seuil pour filtrer ses résultats ça va tomber à l’eau (mais c’est pas très grave...)

  • Anomalie #4543 : Accessibilité des chargements ajax (live regions)

    22 septembre 2020, par nicod _

    nicod _ a écrit :

    C’est bien ce que je comprends des recos, oui, attribut aria sur le premier résultat et redonner le focus sur cet élément.

    J’ai dit une bêtise : retirer l’attribut aria-live et juste gérer le focus.

    Précisions :

    (D’ailleurs, pour effectuer cela, afin de donner le focus à un élément qui normalement ne le reçoit pas, il faut lui ajouter un attribut tabindex="-1".)
    Enfin, il est vraiment important de voir en contexte leur nécessité, si je reprend l’exemple donné sur le github de la disic, à propos d’un panier d’achats, ce n’est pas aussi simple qu’ils l’ont écrit. Tout va dépendre du comportement global. Exemples, après avoir mis un article dans le panier :

    - je suis redirigé vers la page du panier s’affiche (rechargement de page) > alors pas d’aria-live
    je reste sur ma page produit et une "animation" montre mon article qui va dans le panier où le nombre d’article est incrémenté > là on utilise une live region qui va dire un truc du style "3 articles dans le panier" (ou qui peut être plus précise même : "l’article "x" a été ajouté, vous avez 3 articles dans le panier")
    - le panier s’affiche comme une modale (souvent c’est un panneau à droite de l’écran) -> là non plus, a priori pas d’aria-live nécessaire, comme il y a forcément une gestion du focus à prévoir pour amener l’utilisateur dans la bonne zone, on va donner le focus à un titre du style "votre panier (3 articles)"
    etc.

  • Evolution #3966 (Nouveau) : Date de création des contenus

    26 juin 2017, par tcharlss (*´_ゝ`)

    Il n’y a pas longtemps j’ai eu besoin de faire des statistiques éditoriales : on voulait connaître l’évolution du nombre d’articles publiés chaque année.
    Mais les données ne sont pas fiables : les utilisateurs avaient pour habitude de faire des « remises en avant » en changeant la date de publication de vieux articles pour les refaire apparaître en page d’accueil. Donc un article écrit en 2014 mais remis en avant en 2017 se retrouve compté comme ayant été publié en 2017.

    Et c’est valable pour tout les objets éditoriaux en fait : on ne conserve pas leur date de création / 1ère publication.
    Certains objets ont une date de publication, mais elle peut être changée. Et d’autres objets n’ont tout simplement pas de date (hormis maj).

    Donc je me demandais s’il ne serait pas pertinent d’avoir cette information de façon générique pour tous les objets éditoriaux, un champ date_creation par exemple qui serait rempli soit à la création, soit à la 1ère publication, et qui ne bougerait pas ensuite.

    Ci-dessous, un tableau récapitulatif de ce qu’on a actuellement pour les principaux objets.

    Objet Champ de date Date pérènne ?
    Articles date Non : peut être modifiée manuellement
    Brèves date_heure Non : peut être modifiée manuellement
    Rubriques date Oui
    Auteurs X X
    Mot-clé X X
    Groupe de mots-clés X X
    Document date Oui
    Forum date_heure oui
    Pétition X X