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é. If you would like to continue using the new version of the Vector skin without the limited width, you can use a local user script or gadget to do so. Nous pouvons recommander celui-ci.

Comment avons-nous décidé d'une largeur de 960 pixels ?
Please review this page to learn more about how we made this decision:

When will these changes be available on the largest wikis?
Not in 2020, unless a community volunteers to join our testing. Currently, we are focusing on the development of our first features based on data we have already collected, and on the tests on the early adopter wikis. We do hope to see the changes set as default on all wikis in 2021.

Are the improvements to be implemented on sister projects and on non-Latin script wikis?
Yes. We have already made a list of early adopter wikis which represents various sizes and scripts. We also wanted to ensure that at least one non-Wikipedia project is selected.

Which wikis these changes are available on?
Actuellement ce sont :


 * les projets frères :
 * 
 * 


 * non-Latin script wikis:
 * he:
 * fa:


 * Latin script Wikipedias:
 * eu:
 * fr:


 * additionally:
 * Office Wiki

We are open to add more wikis to this list!

How can this be deployed on my wiki?
If you are interested to see the Desktop Improvements as default on your wiki,
 * 1) ask your community and reach the consensus,
 * 2) contact SGrabarczuk (WMF), email: sgrabarczuk-ctr@wikimedia.org if you need support.

Monobook ou Timeless seront-ils concernés ?
No. These changes will be applied to Vector only. [ Vector] has been the default interface on Wikimedia wikis since 2010. No other skins will be affected, including [ Monobook], [  Timeless], [  Minerva] or [  Modern].

Will you improve charts, maps, a-/f-/o-/tmboxes, infoboxes, navboxes, other templates?
No. We will not change anything that's within the light gray article content area (except for the table of contents):

Comment suggérer des améliorations ?
Add a section on the [ talk page of the main page of the project] or contact SGrabarczuk (WMF), email: sgrabarczuk-ctr@wikimedia.org.

Comment le désactiver ?
It's possible to turn the improvements on and off within user preferences. We have also provided an opt-out button in the left sidebar (accessible on each page):.

Comment rapporter un bogue ?
Vérifiez sur la page suivante si votre bogue est un problème déjà connu.

You can add a task on Phabricator and add Desktop Improvements project tag or contact 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.

We will keep and maintain the Legacy Vector. There is no intention of its removal.

Why not use beta features only?
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.