Reading/Web/Desktop Improvements/Features/Limiting content width/fr

L'un des principaux objectifs de ce projet est de rendre Wikipédia, et les autres projets Wikimédia, plus accueillants pour les novices. L'une des façons d'atteindre ce but est de rendre l'expérience de lecture des articles plus confortable.

Comment évalue-t-on si une expérience de lecture est confortable (ou inconfortable) ? Selon les recherches effectuées dans ce domaine, plusieurs facteurs y contribuent, en particulier la longueur des lignes. Dans une étude intitulée Computer text line lengths affect reading and learning (La longueur des lignes sur ordinateur affecte la lecture et l'apprentissage), Peter Orton, professeur au IBM Center for Advanced Learning, conclue que plus une ligne est longue, plus il est difficile de lire, et par conséquent d'apprendre et de retenir, des informations textuelles. Plusieurs autres études peuvent être trouvées dans les sources de l'article Wikipédia anglophone Line length, qui recommandent toutes entre 40 et 75 caractères par ligne.

Quoiqu'il ne soit pas simple d'aboutir aux largeurs recommandées sur les wikis Wikimédia, nous limiterons la largeur du contenu grâce à une largeur maximale afin de contenir l'essentiel du texte plus près de ces recommandations.

Vous pouvez explorer plus de détails sur les recherches et les considérations qui ont motivé cette fonctionnalité.

Plan de déploiement
Nous avons commencé à déployer les premiers changements en mai 2020 sur Office Wiki et Test Wiki, et avons depuis commencé à les déployer sur nos wikis primo-adoptants. Voir notre page principale sur les Fonctionnalités pour plus de détails.

Description et prérequis de la fonctionnalité
La principale fonction de cette fonctionnalité est de limiter la largeur du contenu des articles. Cependant, afin de nous assurer que les autres éléments de la page (en particulier la barre latérale et l'entête) ne s'éloignent pas trop du contenu, nous avons ajouté deux conteneurs supplémentaires. Le deuxième conteneur permet de s'assurer que la barre latérale reste proche du contenu. Puis pour empêcher l'entête de trop s'éloigner de ces deux éléments, un troisième conteneur contraint la largeur maximum de l'entête.

D'un point de vue technique : le contenu de la plupart des pages est placé à l'intérieur d'un conteneur de contenu d'une largeur maximale de 960px. Deux conteneurs additionnels permettent de gérer la largeur d'autres parties de l'interface telles que l'entête et la barre latérale : le conteneur espace de travail (laargeur maximale 1440px) et le conteneur page (1650px). Ci-dessous, vous pouvez voir des schémas qui illustrent le fonctionnement de ces conteneurs. Sur certaines pages, la largeur du contenu ne sera pas contrainte, notamment pour l'Historique, les Modifications récentes, et autres pages du type suivi. Pour explorer une démo interactive de cette fonctionnalité, vous pouvez tester ce prototype.

Prérequis et recommandations visuelles
Voici un GIF qui illustre la différence entre l'ancienne mise en page actuelle et la version actualisée en prenant en compte les diverses limitations de largeur décrites précédemment :

Contraintes
La principale complication est que certaines pages de suivi de modifications, telles que l'Historique et les Modifications récentes, deviennent plus difficiles à lire quand l'écran est plus étroit à cause du retour à la ligne. Nous avons donc décidé de traiter ces pages séparément, en ne les contraignant qu'à l'intérieur du conteneur d'espace de travail (1440px) au lieu du conteneur de contenu (960px). Voici un GIF d'un prototype qui montre la bascule entre une page d'article et la page d'historique associée :



Tests utilisateur avec des contributeurs
Nous avons réalisé une consultation autour d'un prototype de limitation de la largeur du contenu auprès de contributeurs et contributrices issues de différents wikis. Le test consistait à explorer le prototype et à le commenter via une annonce sur la bannière du site. Les avis étaient divisés : beaucoup ont apprécié les lignes plus étroites et reconnu que la fonctionnalité permettait une lecture plus confortable. Mais certains contributeurs n'aimaient pas l'espace blanc laissé autour du contenu et avaient le sentiment d'espace gâché. Nous prenons en compte ces retours en même temps que les études et recherches existantes autour de la longueur des lignes et du confort de lecture.

Lisibilité
Notre objectif principal est d'améliorer la lisibilité des pages des wikis Wikimédia. So perhaps the first question is: how can we know what the optimal width of the content area is? There are research-based recommendations regarding optimal line lengths for readability of text, so we should probably start there. But then again Wikimedia wiki articles are different from common articles or web pages in certain ways. They are unique both in how long they are and in the variability of layout from one article to the next. Both of these factors may lead to a larger than usual need for scanning and searching for content (rather than linear reading). Our design must take into account these distinctions. We need to therefore ask, are Wikimedia wiki pages unique enough to warrant a line-length different from what is generally recommended? Below we explain how we’ve arrived at our design recommendation for what the max-width should be.

Il est difficile de savoir ce qui est optimal sans étudier la lisibilité des pages des wikis Wikimédia elle-même, mais dans une volonté de faire une hypothèse éclairée, nous avons d'abord commencé par consulter les études sur la longueur optimale des lignes pour les textes écrits. Les études et recommandations dans ce domaine semblent bien établies. La page Wikipédia anglophone Line Length contient une bonne vue d'ensemble, de même que l'essai [$link1 Size Matters: Balancing Line Length And Font Size In Responsive Web Design] de la Professeure Laura Franz. L'étude [$link2 Computer text line lengths affect reading and learning] de By Peter Orton, docteur à l'IBM Center for Advanced Learning est une recherche académique plus rigoureuse encore. Il est aisé de constater que la plupart des sites les plus populaires se conforment à ces recommandations. Sur le journal de science numérique [$link4 Nature], les articles ont une largeur maximale d'environ 76 caractères par ligne, ceux du [$link5 New York Times] ~64 caractères par ligne, le [$link6 Times of India] pratique ~100 caractères par ligne (en hindi), les articles du [$link7 Oxford Academic journal] en ont ~75, et les articles sur le site de l'[$link8 Oraganisation Mondiale de la Santé] en ont, selon les alphabets ~96 (alphabet latin), ~46 (idéogrammes chinois), ou ~85 (alphabet cyrillique). Il est également intéressant de remarquer que, lorsque l'on utilise le mode lecture dans Safari ou Firefox, le texte est rendu avec une largeur de respectivement ~73 et ~77 caractères par ligne (alphabet latin). The research and recommendations in this area seem to be well established. The Wikipedia page on Line Length provides a good overview, as does the essay Size Matters: Balancing Line Length And Font Size In Responsive Web Design by Professor Laura Franz. The research study Computer text line lengths affect reading and learning by By Peter Orton, Ph.D. IBM Center for Advanced Learning is a more rigorous, academic study. The popular recommendation is that there should be between 40 and 75 characters per line. The findings of multiple studies conclude that "short line lengths are easier to read", and furthermore regarding learning and information retention "Subjects reading the narrow paragraphs had better retention than those reading the wide paragraphs". One can find many popular sites that conform to these guidelines. Articles on the online science journal Nature have a max-width resulting in ~76 characters per line, New York Times articles are ~64 characters per line, Times of India articles are ~100 characters (Hindi), Oxford Academic journal articles are ~75, and articles on the World Health Organization’s website are ~96 (Latin alphabet), ~46 (Chinese alphabet), and ~85 (Cyrillic alphabet). It is also worth noting that when using reading mode in Safari or Firefox text is rendered at ~73 and ~77 characters per line respectively (Latin alphabet).

En comparaison, une page sur les projets Wikimédia, dans une fenêtre de navigateur de 1280px*, compte environ 170 caractères par ligne - alors qu'on se trouve déjà sur la fourchette basse des tailles d'écran. (*La largeur d'écran la plus commune, concernant 22% des internautes, est de 1366px selon [$link1 StatCounter]. En imaginant une fenêtre de navigateur pratiquement en pleinn écran, on obtient une largeur d'environ 1280px). Ajoutez à cela que le nombre de caractères par ligne va augmenter à mesure qu'augmente la largeur de l'écran (alors que sur les autres sites cités, la largeur contrainte maintient la moyenne constante). Résultat, sur la deuxième largeur d'écran la plus répandue, 1920px (21% des internautes), le nombre de caractères par ligne est d'environ 262 (là aussi en estimant que la fenêtre du navigateur est presque en plein-écran), c'est-à-dire plus de trois fois le valeur recommandée. Nous savons donc que pour des paragraphes de plein textes, nous sommes largement au-dessus de la limite recommandée. (*The most common computer screen size, accounting for 22% of users, is 1366px wide according to StatCounter; imagining a browser window at nearly full width you end up with ~1280px). Then factor in that on Wikimedia wiki the character count per line grows as the screen width grows (whereas on the other sites mentioned the character count per line remains the same, the result of max-width constraints). So on the second most popular screen-size, 1920px (21% of users), the character count per line is ~262 (again assuming a browser window at nearly full-width), more than three times the recommended value. So as a starting point we know that for paragraphs of uninterrupted text we are well over the recommended limit.

La question devient donc : pourquoi ne pas limiter la largeur des contenus sur les projets Wikimédia de sorte à coller aux recommandations, comme semblent le faire les autres sites ? Réponse courte : parce que nos pages sont différentes, et que les internautes les consultent différemment. Les pages des wikis Wikimédia sont souvent longues, contiennent de nombreuses informations, et ne sont pas construites ou mises en page de manière uniforme. Par conséquence, les internautes ont davantage besoin de parcourir et d'explorer les pages, contrairement à une lecture linéaire d'un article en ligne ou d'un livre (cet argument est soutenu par notre étude sur le temps de lecture sur Wikipédia). Ainsi, même si les recommandations académiques sont un bon point de départ, nous devons aussi prendre en compte le fait que, plus le contenu est étroit, plus la page s'allonge, ce qui la rendra peut-être plus difficile à survoler (nécessiter de scroller davantage, etc.) (pour plus d'information sur les différents types d'usages de lecture en ligne, vous pouvez consulter cette [$link1 étude menée par le groupe Nielsen Norman] en 2006). Par ailleurs, du fait que les pages des wikis Wikimédia contiennent de nombreux éléments qui sont inclus dans les lignes à côté du texte (images, schémas, tableaux...), il n'est pas aisé d'atteindre un nombre spécifique de caractères par ligne. Wikimedia wiki pages are very long, contain a large amount of information, and they are not uniform from one page to the next. As a result, people have a greater need to skim and search within pages than they would when reading a typical online article or book (this is supported by our research around reading time on Wikipedia). So while the line length recommendations provide a good starting point, we also must consider that the more narrow we make the content, the longer the page gets, and perhaps the more difficult scanning becomes (involves more scrolling, etc.) (for more information regarding different types of online reading please see this 2006 study conducted by the Nielsen Norman Group). Additionally, because Wikimedia wiki pages contain many elements that are floated inline alongside text it is not straightforward to achieve a specific number of text characters per line.

Créer une expérience de lecture commune
La deuxième raison pour laquelle nous pensons qu'introduire une largeur maximale est une bonne chose pour l'expérience de lecture, c'est que cela aiderait à créer une expérience de lecture commune, qui, nous l'espérons, aiderait les contributeurs et contributrices dans leurs choix de mise en page. Actuellement, on peut modifier une page avec un affichage de 1500px, alors qu'elle sera lue à 1200px. Avec une largeur maximale, on ne supprime pas complètement les écarts (il y aura toujours des internautes dont les écrans sont plus étroits), mais on limite cependant beaucoup les variations possibles. Currently an editor might be editing a page at a width of 1500px, while a reader reads it at a width of 1200px. By implementing a max-width we don’t remove this discrepancy completely (because there would still be variation below the fixed-width, for people with narrower screens), however we would be greatly limiting the range of variation.

Conclusion
Après toutes ces réflexions, nous sommes arrivés à deux conclusions :


 * 1) Une largeur maximale de 800 à 1000px semble être un bon point de départ. Nous centrerons le contenu dans la page pour nous assurer que la mise en page soit esthétique, que la barre latérale soit dépliée ou repliée.
 * 2) Il paraît pertinent de mener une étude dédiée spécifiquement à la lisibilité des articles Wikipédia. Nous espérons rassembler les ressources pour ce faire.

Déstructuration des modèles, contenus, pages spéciales, etc.
L'une des forces de Wikipédia, et des autres projets Wikimédia, est qu'il y a très peu de contraintes sur la présentation de l'information. Par conséquent, il peut y avoir une variété d'éléments différents sur la page : tableaux, galeries d'images, diagrammes, images panoramiques, graphiques, schémas, cartes, boîtes de catégories, et bien d'autres. Ayant eu à gérer le design du site mobile, pour lequel il a fallu obtenir un rendu esthétique satisfaisant, nous reconnaissons qu'il y aura certaines configurations dans lesquelles la largeur maximale ne donnera pas un résultat visuellement satisfaisant. Notre plan est actuellement de : The result of this is a wide variety of different elements on the pages: tables, image galleries, diagrams, panoramic images, graphs, forms, maps, category boxes, and more. Having dealt with the challenges of designing the mobile site, and getting the content to look good, we recognize that there are going to be some situations where page content doesn’t look great given the max-with. Our plan currently is:


 * Travailler avec nos communautés Wiki tests pour identifier les problèmes et discuter de solutions reposant sur les styles de modèles et autres outils existants.
 * Ne pas appliquer la largeur maximale aux pages spéciales. Ces dernières ne sont pas véritablement destinées à être "lues", et fonctionnent davantage comme des listes ou des tableaux de bord. Ainsi, tant que nous n'aurons pas le temps de travailler sur toutes les implications d'une mise en page plus responsive, nous laisserons ces pages en l'état. Voici un prototype initial montrant comment cela fonctionnerait : vous pouvez alterner entre "historique" et "lire" pour voir la différence.

Anciennes discussions
Ce sujet a déjà été discuté par le passé. N'hésitez pas à ajouter ici des liens vers d'autres conversations antérieures.
 * 2014 – discussion sur le projet Typography Refresh