Reading/Web/Desktop Improvements/Frequently asked questions/fr

Lisibilité
Notre principale motivation pour limiter la largeur du contenu est d'améliorer la lisibilité des contenus passionnants de nos wikis. Les tests d'utilisation sur nos projets, aussi bien pour la lecture que pour la contribution, montrent que l'efficacité de la lecture est un critère-clé. Bien que la lisibilité dépende de facteurs multiples - taille de la police, contraste et longueur de lignes - nous avons décidé de nous concentrer dans un premier temps sur ce dernier facteur. Les recherches cognitives sur la lecture de textes imprimés recommandent une longueur de ligne entre 45 et 90 caractères par ligne (cpl) Les recherches récentes sur la lecture de sites web se concentrent principalement sur des largeurs de 35 à 100 cpl, avec des recommandations tendant vers des lignes plus courtes. De fait, sans limitation de la largeur des articles, les internautes peuvent se retrouver avec un nombre de caractères par ligne qui dépasse de beaucoup la largeur recommandée. Une étude de 2005 résume déjà les arguments des recherches les plus récentes : "une ligne plus courte est plus facile à lire", d'autant que, en matière d'apprentissage et de rétention de l'information, "les sujets qui lisent les paragraphes plus étroits retiennent mieux que ceux qui lisent les paragraphes plus larges".

Enfin, même s'il est toujours important à nos yeux de faire nos propres recherches pour tirer nos propres conclusions, nous pensons également pertinent de noter l'écrasante majorité de sites web qui ont déjà adopté des limitations similaires sur la largeur du contenu. Par exemple : des journaux académiques tels que Nature, des sites d'information tels que le New York Times, des sites gouvernementaux ou intergouvernementaux comme l'ONU, des documents académiques comme LaTeX, et des traitements de texte tels que Google Docs et Etherpad. Ces exemples, ajoutés à une recherche approfondie, nous confortent dans cette décision.

En bref, limiter la largeur du contenu permet une meilleure lisibilité, une meilleure rétention de l'information, et limite la fatigue oculaire.

Mais pourquoi autant d'espace blanc ?
Nous avons reçu des commentaires d'une trentaine de contributeurs (en particulier des personnes avec des écrans larges) qui sont agacés par la quantité d'espace blanc laissé sur le côté des pages, quoique certains conviennent que la limitation de la largeur améliore l'expérience de lecture. Nos raisons sont les suivantes : Notre objectif est de créer la meilleure expérience de lecture possible, pas de remplir chaque pixel de l'écran. Et dans cette perspective, moins c'est mieux : on lit mieux avec des lignes plus étroites, et on se concentre plus facilement sans la présence des éléments de la barre latérale. Si la meilleure mise en page suppose de laisser de l'espace blanc, ce n'est pas grave : les espaces blancs n'ont rien d'intrinsèquement mauvais.
 * 1) The white space feels like wasted space
 * 2) The white space is bright and distracting

De plus, à mesure que le projet avance, nous espérons utiliser une partie de cet espace pour d'autres fonctionnalités. Nous avons fait des tests pour figer le menu latéral à gauche de la page (https://di-collapsible-sidebar-2.firebaseapp.com/Lute lien vers le prototype). Plus tard dans le projet, nous pensons tester d'inclure le sommaire et/ou les outils liés à l'article dans cet espace blanc. Par ailleurs, comme l'a suggéré, limiter la largeur du contenu nous ouvre de nouvelles possibilités en matière de mise en page, par exemple dédier la colonne de droite à l'infobox et aux images.

Les internautes ne peuvent pas juste rétrécir leurs fenêtres ?
Plusieurs personnes ont argumenté en disant : si les gens veulent que le contenu soit plus étroit, ils n'ont qu'à rétrécir la taille de la fenêtre de leur navigateur, ou cliquer sur l'option "version mobile" en bas de page. Comme mentionné ci-dessus : comme nous savons que la plupart des internautes viennent pour lire les articles, nous devons optimiser la mise en page au service de ce besoin. La première impression est la plus importante, et notre but doit être d'offrir la meilleure expérience possible dès l'arrivée sur le site, sans obliger les internautes à procéder à des ajustements.

Les tableaux et d'autres modèles ne rentrent pas dans la largeur limite.
Il nous a été rapporté des cas de tableaux comportant de longues barres de défilement horizontal, ou de modèles qui excèdent la largeur maximale. Nous tenons à préciser qu'un pourcentage important des internautes, qui n'ont pas d'écran large et consultent Wikipédia depuis des ordinateurs portables, avaient déjà des problèmes d'affichage avec les tableaux et modèles, même avant le changement. Nous devons travailler pour nous assurer que tous nos contenus sont aussi responsive que possible, afin de s'adapter à tout appareil.

Pourquoi ne pas en faire une préférence ?
L'une des grandes qualités de l'interface MediaWiki est qu'elle est hautement configurable. Cela étant, même si nous pourrions créer une préférence pour la largeur du contenu, nous nous demandons s'il ne serait pas plus productif de favoriser une expérience commune entre les contributeurs et les lecteurs. Cela pourrait notamment aider les contributeurs et contributrices à faire des choix de mise en page. Actuellement, il est possible de modifier une page à une largeur de 1500px, alors qu'elle sera lue avec une largeur de 1200px. En mettant en place une largeur maximale, nous ne supprimons pas complètement les écarts (il y aura toujours des internautes dont les écrans sont encore plus étroits), mais nous réduisons grandement l'ampleur des variations.

Cela étant, nous ne sommes pas intrinsèquement contre la configurabilité. Si vous souhaitez continuer à utiliser la nouvelle version de Vector, mais sans la limitation de la largeur du contenu, vous pouvez utiliser un script ou un gadget. Nous vous recommandons celui-ci.

Comment avons-nous opté pour 960px de large ?
Pour comprendre cette décision, veuillez visiter cette page :

Quand ces changements seront-ils disponibles sur les grands wikis ?
Pas en 2020, sauf si une communauté choisit de rejoindre nos tests. Actuellement, nous nous concentrons sur le développement de nos premières fonctionnalités sur la base des données collectées et des tests sur les wikis "primo-adoptants". Nous espérons que les changements deviendront l'expérience par défaut sur tous les wikis courant 2021.

Est-ce que les améliorations seront déployées sur les projets frères et les wikis en caractères non-latins ?
Oui. Nos wikis "primo-adoptants" ont différentes tailles et différents alphabets. Nous avons également des projets frères autres que Wikipédia.

Sur quels wikis ces changements sont-ils disponibles ?
Actuellemment, les wikis primo-adoptants sont :


 * Projets frères
 * 
 * 


 * Wikis en caractères non-latins
 * he:
 * fa:


 * Wikipédias en caractères latins :
 * eu:
 * fr:


 * Ainsi que :
 * Office Wiki

Nous sommes ouverts à ajouter davantage de wikis à cette liste !

Comment faire pour déployer ce projet sur mon wiki ?
Si vous souhaitez que les Améliorations Bureau deviennent l'expérience par défaut sur votre wiki,
 * 1) discutez-en avec votre communauté et trouvez un consensus,
 * 2) contactez SGrabarczuk (WMF), email: sgrabarczuk-ctr@wikimedia.org si vous avez besoin d'aide.

Est-ce que Monobook ou Timeless seront affectés ?
Non. Ces changements vont être appliqués uniquement à Vector. [ Vector] est l'habillage par défaut de l'interface des wikis Wikimédia depuis 2010. Aucun autre habillage ne sera affecté, ni [ Monobook], ni [  Timeless], ni [  Minerva], ni [  Modern].

Améliorerez-vous les graphiques, cartes, infoboxes et autres modèles ?
Non. Nous ne changerons rien qui se trouve à l'intérieur de la ligne grise "contenu de l'article" (à part le sommaire).

Comment puis-je suggérer des améliorations ?
Ajoutez une section à la [ page de discussion de la page d'accueil du projet] ou contactez SGrabarczuk (WMF), email: sgrabarczuk-ctr@wikimedia.org.

Comment désactiver les changements ?
Il est possible d'activer ou de désactiver les améliorations dans vos user préférences. Nous avons également créé un bouton de retour à l'ancien habillage dans la barre latérale (accessible sur toutes les pages) :.

Comment signaler un bug ?
Vérifiez cette page pour savoir si votre bug a déjà été signalé.

Vous pouvez ajouter une tâche sur Phabricator en ajoutant le tag Desktop Improvements project tag, ou contacter SGrabarczuk (WMF), email: sgrabarczuk-ctr@wikimedia.org.

Pourquoi ne pas faire un nouvel habillage ? Qu'adviendra-t-il de Legacy Vector ?
It would be an excellent idea to make a new skin, but in the case of Wikimedia skins, it's easier to change an existing one than to create a new one from scratch. There are various reasons:


 * it would be too complex to make the existing extensions, gadgets, and user scripts compatible with yet another skin, and too costly to maintain their compatibility,
 * it would be too challenging to build and maintain yet another skin (as a total replacement is not an option),
 * it would be less likely for the communities to collaborate effectively in the process of building a new skin.

Technically, Desktop Improvements are similar to previous features or projects such as or. The only difference is that this time, there will be more of them. Vector documentation should remain relevant.

Nous garderons et maintiendrons Legacy Vector. Nous n'avons pas l'intention de le supprimer.

Pourquoi ne pas utiliser seulement les fonctionnalités bêta ?
Beta features are available for registered users only, and the improvements are intended to serve our readers and unregistered users as well. Therefore, using beta features only would give us feedback from a very specific type of user that is not representative of our entire base of users. And moreover, we wish to receive the readers' and anonymous users' feedback from the earliest deployments.

Quelles sont les métriques de succès des fonctionnalités ?
Increase utility among our existing audiences, proxied by:


 * Interactions
 * Increase searches per session by 5% over the course of the project
 * Increase language switching per project by 5% over the course of the project


 * Affinity
 * Increase in positive and welcoming sentiments towards the site (via surveys and user testing)
 * Increase in sentiments of trust and credibility (measured via surveys and user testing)

As we define the changes we want to make with more specificity, we will expand and iterate on this list.