Multimedia Usability Project Meeting France/fr/ideas

Cette page a pour objectif de recenser les réflexions des contributeurs francophones des projets Wikimédia à propos des soucis et potentielles améliorations du multimedia sur les projets, en lien avec le projet de Multimedia Usability Project Meeting d'octobre 2009

Si vous pensez qu'on peut commencer à trier les réflexions par thèmes, surtout n'hésitez pas... à créer des paragraphes. Cela permettra une meilleure lecture des choses.

Recherche et Navigation

• actuellement, pour la géolocalisation, en tombant sur une image contenant de telles données, on peut accéder à une carte qui nous montre l'emplacement d'où la photo a été prise. Ça serait bien de pouvoir faire l'inverse. D'avoir une carte du monde, de pouvoir définir une période, et en cliquant au hasard sur la carte, obtenir la liste des photos prises à cet endroit, à cette époque
• proposer différents paramètres de tri dans les catégories ou lors des recherches :
  • alphabétique, tel qu'utilisé actuellement ;
  • afficher dans les premiers résultats les photos élues par la communauté comme étant de qualité ;
  • afficher les votes populaires en premier, qui ne refléteront pas forcément la qualité.
  • par date (paramètre date= de commons:template:information et/ou la date de métadonnée EXIF)
• Fabriquer un outil de recherche de duplication, non plus sur le code binaire du média, mais sur son apparence tel que l'homme le voit (comme le fait Tineye)
• fonctionnement en tag plutôt qu'en catégorie
  • Non car c'est démagogique (on incite les gens à utiliser des descripteurs très vagues "ruines" au lieu de "temples gemminés à Glanum, Saint-Rémy-de-Provence" ?)
  • Au lieu de détruire les catégories, il faut les améliorer :
    • faire en sorte que les recherches du type keyword incategory:"<categoryname>" explorent aussi les sous-catégories de la catégorie mentionnée.
    • faire en sorte que les recherches du type keyword incategory:"<categoryname>" fonctionnent lorsque la catégorie a été incluse avec un modèle (bug bien connu mais non résolu à ce jour, me semble-t-il).
• Un outil "category tree" inversé (c'est à dire qui explore les catégories mères) serait très utile sur chaque image : vous voyez une image de maison. Elle est catégorisée dans [[:category:Saint-Pouilleux-sur-Binouze]]. Mais le nom de ce village ne vous dit absolument rien, donc vous avez envie très vite de remonter l'arborescence des catégories pour savoir dans quel département le village est situé.

• Gros point d'interrogation : ne doit-on pas avouer au lecteur, à l'utilisateur, que malgré nos velléités multilingues, Commons est en réalité principalement anglophone et que si sa recherche porte sur un nom commun (ou même pour certains noms propres qui ont une graphie différente en anglais qu'en français), il lui est fortement recommandé de chercher avec le mot anglais correspondant à ce qu'il cherche, plutôt qu'avec le mot français ? (En même temps il ne faut pas dire qu'une recherche en français est forcément infructueuse, puisqu'il y a des gens qui font l'effort d'ajouter des descriptifs en français aussi). Par exemple si vous cherchez des documents sur les typhons au Japon, vous pouvez chercher typhon + Japon, mais je ne suis pas sûr que cela donne beaucoup de résultats. Donc il faut peut-être plutôt chercher en anglais typhoon + Japan. Teofilo 04:03, 22 August 2009 (UTC)

Interface de visualisation

• galeries navigables (boutons back-forward). Si possible, pouvoir effectuer une navigation au clavier (barre espace pour la photo suivante, page-up / page-down pour les photos précédentes ou suivantes, début et fin...), permettant ainsi de pouvoir naviguer, même si l'on regarde des photos dans leur taille réelle en plein écran.
  • rendre paramétrable le nombre d'images par pages dans les catégories (passer de 200 actuellement à un nombre plus raisonnable : 24 par exemple, pour les utilisateurs qui le souhaitent). En revanche, rendre optionnel un choix de taille de vignette peut-être un peu plus grand (180 au lieu de 120 pixels, mais au choix)
• diaporama, pour que les images puissent défiler automatiquement sans intervention humaine, avec la possibilité de régler le nombre de secondes entre chaque image
• vignettes redimensionnables rapidement par les utilisateurs non enregistrés
  • C'est ce que fait actuellement le gadget "Choose Resolution" : rendre ce gadget disponible pour tous les utilisateurs, même non inscrits. Rendre ce gadget disponible directement depuis Wikipédia ?
• redimensionnement (galeries et pages image) sans artefacts

Aspects techniques des medias

• prise en charge des profils colorimétriques
• la vidéo sera bientôt de plus en plus présente sur Commons. Pour êtres comprises par le plus grand nombre, certaines auront besoin de sous-titres. Le lecteur multimédia devra donc choisir les bons sous-titres par rapport aux préférences utilisateur ou à la langue du navigateur pour ceux qui ne seraient pas enregistrés, mais il faudra également proposer les outils adéquats pour faciliter leur traduction de façon collaborative. Il ne s'agit pas de seulement traduire des chaînes de caractères. Par exemple, selon les langues, il faut plus ou moins de mots pour dire la même chose, et le timing (qui fixe la durée durant laquelle une réplique est affichée à l'écran) a donc besoin d'être retravaillé. Voir ce que propose dotSUB.

Téléchargement

• pouvoir télécharger facilement tout le contenu d'une catégorie, plutôt que de charger une à une les images dans leur taille réelle pour les sauvegarder ensuite.
  • Question évoquée sur commons:Commons:Village_pump/Archive/2009Jul#Downloading all images in a category
• Pouvoir déplacer facilement et proprement un média depuis Wikipédia ou tout autre projet de la fondation vers Commons, directement depuis MediaWiki, sans passer par des outils externes tel que Commons Helper, qui ne respectent que très mal l'historique du fichier. L'inverse devrait également être possible quand on se rend compte que la photo est libre, mais que le sujet ne l'est pas (oeuvre architecturale récente). Ce type de fichier, qui n'est pas autorisé sur Commons, peut l'être sur certaines versions de Wikipédia.
• Pour faciliter l'utilisation, il y a deux fonctionnalités à activer en priorité : renommage d'un fichier, et téléversement directement depuis le web (en ajoutant l'URL source directement dans le modèle). Ces fonctionnalités existent déjà, et fonctionnent sur d'autres wikis.
• De façon générale il faut définir ce qu'on entend par "télécharger". S'agit-il d'un téléchargement de l'image brute ou de l'image avec sa description et sa licence ? Voir commons:Commons:Village_pump/Archive/2009Jul#Downloading all images in a category et plus bas dans #Licences la proposition "Zitiervorschlag". Pour une utilisation privée, le téléchargement brut peut suffire, mais pour une utilisation publique, cela parait aberrant de ne pas proposer simultanément la description et la licence.
• Un truc tout bête : avoir une barre de statut qui indique le pourcentage de chargement d'un fichier quand on le dépose sur commons.

Métadonnées

Réorganiser les pages de description d'image

• Réfléchir à l'ordre de présentation des informations, en essayant de définir les priorités. Ce qui suit n'est qu'une ébauche de réflexion, à affiner :
  • Les licences doivent aller dans le bas de la page, car c'est seulement dans le cas où l'utilisateur a décidé de réutiliser l'image que c'est intéressant. Dans un premier temps l'utilisateur feuillette la bibliothèque d'images Wikimedia Commons à la recherche d'une image qui corresponde à son besoin. Il n'est pas nécessaire d'embêter l'utilisateur avec les licences à ce stade.
  • En revanche, les catégories sont nécessaires très tôt dans toutes les opérations de recherche. Donc les catégories doivent être en haut de la page ! Pas tout en bas !
    • Soit vraiment tout en haut
    • Soit juste sous l'image
    • Soit quelque part dans l'environnement du champ "description=" de commons:template:information)
      • Mesure transitoire (à mettre en oeuvre très vite, avant que l'architecture globale de la page soit définitivement arrêtée) : ajouter un lien ancré vers les catégories dans la barre des liens ancrés (le sommaire) au dessus de l'image.

Il faudrait peut-être aussi un petit lien "modifier" pas trop loin des catégories pour donner aux gens envie de s'impliquer dans l'amélioration des catégories. Et pourquoi pas installer le gadget "hotcats" par défaut ? Pour ne pas alourdir inutilement les pages des gens qui ne s'impliqueront jamais dans ce travail, pourquoi ne pas activer "hotcats" uniquement à partir du moment où l'utilisateur manifeste son intention de travailler sur les catégories ? Cela revient à avoir 2 liens : un lien "modifier" tout court et un lien "modifier avec hotcats (fonctionnement plus intuitif)".

• • Normalement, il faut lire la licence avant de télécharger. Donc le ou les liens de téléchargement devraient être situés sous les licences. Si on pense que c'est trop bas, on peut créer une sous page dédiée "tailles disponibles" comme le fait Flickr (par exemple http://www.flickr.com/photos/dynamosquito/3677462763/sizes/ ).

IPTC, EXIF

• Lorsque les métadonnées IPTC ou EXIF contiennent déjà toutes les informations utiles : description, source, auteur, licence, remplir automatiquement commons:template:information, sans qu'il soit nécessaire pour l'utilisateur de les resaisir à nouveau au clavier (il suffit de lui demander de les relire et de les approuver en cliquant sur un bouton - éventuellement ne poser la question qu'une fois pour toute une série de photos téléchargées au même moment pour les photographes qui sont confiants dans le fait que leurs photos sont convenablement décrites dans les métadonnées)
• Réciproquement, permettre une mise à jour de ces mêmes métadonnées dès que les informations de commons:template:information, sont modifiées par un utilisateur, tout en gardant une trace dans l'historique, pour pouvoir éventuellement revenir en arrière en cas de vandalisme ou d'erreur.
• Inclure les métadonnées dans toutes les images redimensionnées : Cf https://bugzilla.wikimedia.org/show_bug.cgi?id=18871

Licences

• La gestion des droits d'auteur est un casse-tête innommable. D'abord il serait utile que la politique des droits d'auteur soit vérifiée par un juriste professionnel. Le coût est à mon avis largement inférieur aux bénéfices possibles, autant pour limiter les images qui dont la licence est incorrecte (y compris les risques de procès et de mauvaise publicité), que pour assurer aux utiliseurs un meilleure réception de leurs fichiers. Par exemple, il serait utile de vérifier et de traduire commons:Commons:Image casebook. Il faudrait particulièrement vérifier les conditions concernant les œuvres dérivées et les œuvres orphelines.
• Gérer le système linguistique des modèles de licence existante afin d'avoir une cohérence au niveau des texte et/ou nuances juridique (utilisation du système proposé par le translatewiki. Permettre que ces texte soit aussi utilisable par les wiki autres que Wikimedia Commons et de la fondation (par le biais d'une extension)
• Puisque Wikimedia Commons est un dépôt partagé et donc utilisé par des milliers d'autres possible wiki. Wikipédia n'est qu'un utilisateur du dépôt partagé. Wikimedia Commons doit garder sa vocation de bibliothèque numérique libre, et non un moyens de support de média encyclopédique.
• Générer et faire apparaître clairement sur la page de chaque média un "Zitiervorschlag" (dsl, en français j'ai suggestion de citation mais ça ne me convient qu'à moitié) qu'il n'y aurait plus qu'à copier-coller pour créditer auteur et licence.
  • C'est ce que fait actuellement le gadget "Choose Resolution" (à éventuellement critiquer et améliorer : il se préoccupe uniquement de la reprise de l'image sur média web, et non sur papier)

Dates et auteurs

Cela concerne une amélioration de commons:template:information. A présent ce cadre ne permet de saisir qu'un seul auteur et une seule date . (il n'est pas interdit d'ajouter plusieurs noms à la suite séparés par "et" ou explication détaillée, mais ce n'est pas très clair, et surtout on n'invite pas le téléverseur à être précis dans ce domaine, ce qui est dommage).

Exemple : le scan d'une gravure dans un livre du XIXe siècle, qui reprend un tableau du XVIIIe siècle.

Il vous faut donc indiquer :

• nom du peintre
• nom du graveur
• références du livre (auteur du livre, éditeur, numéro de page)
• date de la peinture
• date de la gravure
• date de parution (achevé d'imprimer) du livre
• date du scan
• la date du téléversement sur Commons sera indiquée dans l'historique.

Donc ici il y a 5 dates. Il faudrait donner un cadre, un modèle plus ou moins élastique ou rigide pour que les téléverseurs sachent de quelle façon tout cela doit être indiqué.

En plus il est souhaitable d'indiquer la date de décès du peintre et celle du graveur pour certifier le statut du fichier par rapport au droit d'auteur. Donc les modèles "Creator" doivent être utilisés pour le peintre et le graveur (exemple commons:Creator:Paul Cézanne utilisé sur commons:File:Paul Cézanne - Les Joueurs de cartes.jpg)

Chose bête, un certain nombre d'utilisateurs remplissent le champ "date=" avec... la date d'aujourd'hui. Un moyen très simple d'éviter cela serait de préremplir la date de téléversement en la rendant visible aux yeux de l'utilisateur au moment où on lui demande la date de création de l'oeuvre.

Autre exemple d'image complexe : File:Gudea of Lagash Girsu.png, où il faut documenter à la fois un transfert de Wikipédia vers Commons et un travail de retouche. Il y a une sorte de fusion d'historiques à faire. Comment faire pour que l'auteur principal, qui est quand même, après le sculpteur, le photographe, ne soit pas noyé dans ce magma d'information ?

Outils de génération d'images enrichies

• L'une des fragilités actuelles de l'utilisation des images sur les différents projets est le recours à des pseudos-images cliquables ou légendées reposant sur le positionnement via CSS de texte HTML sur une image (fond de carte, diagramme, etc.). Voir par exemple fr:Aide:Tutoriel de création de cartes complétées et fr:Aide:Tutoriel de création d'images complétées. Cette technique conduit à des problèmes d'interopérabilité, de réutilisabilité et d'accessibilité du contenu, en violant le principe de séparation du contenu (l'information) et de sa mise en forme (la couche CSS). Cependant, elle constitue indéniablement un atout pour les contributeurs, en leur épargnant le recours à des éditeurs graphiques pour produire de véritables images complètes.
  Pour éviter de pérenniser cette situation problématique, le développement d'outils (extension) facilitant la production d'images en ligne (intégration de texte sur un fond de carte par exemple) devrait être considéré comme une priorité.

Intégration avec les autres projets

• améliorer la synergie entre les projets : par exemple, lister les images manquantes dans Wikipédia
• automatiser les liens entre entre Commons et les autres projets Wikimédia : par exemple en apposant automatiquement le modèle {{commonscat}} quand une catégorie nouvelle est créée sur Commons. Par exemple, une [[Category:Trifouillis-les-Oies]] est créée sur Commons ⇒ le modèle {{commonscat}} est apposé sur tous les articles [[Trifouillis-les-Oies]] existant dans les projets.
• Les catégories doivent être visibles depuis Wikipédia (sans qu'il soit nécessaire d'aller sur Commons)
  • Cela pose le problème du multilinguisme pour les descripteurs de catégories. Comme cela prendra du temps de développer cet outil multilingue, prévoir pour Wikipédia francophone et les Wikipédias en langues à alphabet latin de récupérer très vite au moins les noms propres et les catégories de biologie avec des descripteurs en latin.

Interactivité

• rendre Commons un peu plus populaire en permettant de bloguer une image ou de la partager sur les réseaux sociaux
• permettre aux utilisateurs de noter les images (par exemple, de une à cinq étoiles)

Divers

• Mettre en œuvre des outils du toolserver afin de mieux travailler sur la charge de travail que représente Wikimedia commons : Traduire dans toutes les les langues (translatewiki) les meilleurs outils (choix des utilisateurs, volonté finale de l'outil) ceci afin de répartir la charge de travail à plus de personnes