Lecture/Web/Améliorations du bureau/Fonctionnalités/Limitation de la largeur du contenu

Présentation

Fonctionnalités

Dépôt

FAQ

« Précédent

Suivant »

Suivi dans Phabricator
Tâche T246420

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é.

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. Il existe des pages dont le contenu n'est pas contraint par le conteneur de contenu y compris l'Historique, les Modifications récentes, et autres pages similaires de types de journaux.

• 
  Schéma montrant trois conteneurs de mise en page, avec la barre latérale repliée
• 
  Schéma montrant trois conteneurs de mise en page, avec la barre latérale dépliée
• 
  Schéma montrant trois conteneurs de mise en page sur une page spéciale

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 :

GIF comparant l'ancienne mise en page et la version actualisée qui limite la largeur du contenu

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 :

GIF montrant la largeur d'un article et d'une page d'historique dans la nouvelle mise en page de Vector

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.

Objectifs et motivations

Lisibilité

Recherche

Notre objectif principal est d'améliorer la lisibilité des pages des wikis Wikimédia. We decided to work on the width of the content area. Il existe des études qui recommandent sur cette question.

• La page Wikipédia anglophone Line Length contient une bonne vue d'ensemble.
• de même que l'essai de la Professeure Laura Franz.
• Optimal Line Length in Reading - A Literature Review (2005), from the peer reviewed journal Visible Language – "studies concluded that moderate line length in between 50 to 70 cpl [characters per line] are the easiest to read and users do not prefer extreme line lengths (very short or very long) while reading from screen. There was no significant effect of line length found on comprehension, though fast readers benefit from narrow columns with short lines due to specific reading patterns (with one contradictory finding)".
• Effects of Surrounding Information and Line Length on Text Comprehension from the Web (2002), from Canadian Journal of Learning and Technology – "Comprehension was affected by whitespace; participants had better comprehension for information surrounded by whitespace than for information surrounded by meaningless information", which is more likely to happen if the text stretches to the edge of the browser.
• The influence of reading speed and line length on the effectiveness of reading from screen (2001), from International Journal of Human-Computer Studies – "A line length of 55 cpl appears to support e!ective reading in terms of both rate and comprehension. However, as the line lengths used in this study were spread across a wide range, there may be a more optimal setting than this. By varying the range and extremes of line lengths in future research, it may be possible to more precisely identify an optimal format and to explore the relative contributions of mechanical and cognitive factors."
• Shorter Lines Facilitate Reading in Those Who Struggle (2013), from PLOS One – "short lines reduce the number of regressions, and generally improve reading speed and comprehension, simply by reducing the probability that crowded text in locations previously fixated can be perceived."
• The Effects of Line Length on Children and Adults' Online Reading Performance (2002), from Software Usability Research Laboratory (SURL) at Wichita State University – "This study examined the effects of line length on reading performance. Reading rates were found to be fastest at 95 cpl. Readers reported either liking or disliking the extreme line lengths (35 cpl, 95 cpl)".
• The Effects of Line Length on Children and Adults' Perceived and Actual Online Reading Performance (2003), from Proceedings of the Human Factors and Ergonomics Society Annual Meeting – "No differences were found for either reading time or efficiency for either adults or children. However, adults preferred shorter line lengths to full-screen line lengths." and "The narrowest line length condition was perceived as promoting the highest amount of reader concentration, while the medium line-length condition was considered to be the most optimally presented length for reading."
• Reading Online Text: A Comparison of Four White Space Layouts (2004), unclear if this was peer reviewed – "Results from this study showed that the manipulation of the Margin white space affected both reading speed and comprehension; participants read the Margin text slower, but comprehended more than the No Margin text. In general, the results favored the use of Margins."

La recommandation populaire est qu'il devrait y avoir entre 40 et 75 caractères par ligne. The findings of multiple studies conclude that "short line lengths are easier to read". Regarding learning and information retention: "Subjects reading the narrow paragraphs had better retention than those reading the wide paragraphs".

Web Content Accessibility Guidelines (WCAG)

• The Web Accessibility Initiative (WCAG) guideline 1.4.8 states that, in order to be accessible to all users, lines of text should be 80 or fewer characters (or 40 or fewer characters if the text is Chinese, Japanese, or Korean)."

Sites populaires avec une largeur limitée

On peut trouver de nombreux sites populaires qui se conforment à ces directives.

• 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.
• Articles on the World Health Organization’s website are ~96 (Latin alphabet), ~46 (Chinese alphabet), and ~85 (Cyrillic alphabet).
• When using reading mode in Safari or Firefox text is rendered at ~73 and ~77 characters per line respectively (Latin alphabet).

Comparaison avec les wikis Wikimédia

Une page de Wikipédia en anglais affichée dans une fenêtre de navigateur à 1280px compte environ 170 caractères par ligne. Ce correspond à l'extrémité inférieure du spectre des tailles d'écran.

Sur Wikimédia wiki, le nombre de caractères par ligne augmente avec la largeur de l'écran. Ainsi, sur la deuxième taille d'écran la plus populaire, 1920px (21% des utilisateurs), le nombre de caractères par ligne est de ~262, soit plus de trois fois la valeur recommandée.

Pourquoi ne pas choisir la solution « la plus simple »

En se basant exclusivement sur la longueur de ligne recommandée, il semble qu'une largeur d'environ 700px soit raisonnable. 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 ?

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. This is different than linear reading a typical online article or book. Cet argument est soutenu par notre étude sur le temps de lecture sur Wikipédia.
• Plus le contenu est étroit, plus la page s'allonge. Peut-être c'est plus difficile à survoler aussi, car cela implique plus de scroller, etc. Pour plus d'information sur les différents types d'usages de lecture en ligne, vous pouvez consulter cette étude menée par le groupe Nielsen Norman.
• Par ailleurs, il n'est pas aisé d'atteindre un nombre spécifique de caractères par ligne. C'est parce que les pages des wikis Wikimédia contiennent de nombreux éléments qui sont inclus dans les lignes à côté du texte.

Article "Moon" à 550px de largeur, avec un paragraphe de plein texte de ~83 caractères par ligne

Article "Moon" à 750px de largeur, avec un paragraphe de plein texte de ~72 caractères par ligne

Notre design doit prendre en compte ces distinctions et spécificités.

• We should limit the width by some amount to accommodate focused/engaged reading. This means shorter line lengths, and less density.
• At the same time, we should still enable readers to skim and search around, obtaining a visual map of the page without having to scroll too much This is an argument for longer line lengths, and more density.

Comment allons-nous faire?

Notre solution

Il y a deux expériences communes que nous pourrions vouloir envisager.

1. Le haut d'un article, généralement composé d'un paragraphe situé à côté d'une infobox
2. Le milieu d'un article, un paragraphe de texte sans élément d'interruption

On peut envisager ces deux situations avec plusieurs largeurs différentes, en comptant le nombre de caractères par ligne pour chacune :

Largeur du contenu	Paragraphe à côté d'une infobox	Paragraphe de plein texte
600px	~30 caractères par ligne	~94 caractères par ligne
700px	~59	~109
800px	~76	~125
900px	~89	~142
1000px	~105	~154

À 1000px de large, un paragraphe de texte ininterrompu compte ~154 caractères, soit environ le double de la limite supérieure de la fourchette recommandée. Il arrive que des éléments flottants soient plus larges que les infobox, ce qui entraîne des colonnes de texte plus étroites à côté d'eux. De plus, il n'y avait pas de largeur maximale. Si certains éditeurs peuvent éditer sur des écrans plus étroits (ou vérifier l'aspect des pages sur des écrans plus étroits), il y a probablement du contenu sur les pages qui ne sera pas (encore) parfait sur une largeur plus étroite, parce que cela n'a pas été pris en compte (par exemple, les grands tableaux).

Une autre approche possible qui peut nous influencer est de se baser sur une mise en page par grilles (grid layout). Il s'agit d'une approche qui vise à améliorer l'harmonie visuelle de la page et à faciliter les choix techniques en termes d'espacement, de largeur, etc. L'habillage Vector n'utilise pour l'instant pas de grille. Nous pourrions par exemple prendre la largeur de l'infobox comme étalon d'une colonne de grille, et ensuite utiliser un multiple de cette largeur pour déterminer la largeur du contenu.

Article Inde avec un contenu de 3x la largeur de l'infobox

Article Inde avec un contenu de 4x la largeur de l'infobox

Créer une expérience de lecture commune

Création d'une largeur maximale aiderait à créer une expérience de lecture commune. Nous espérons que c'aiderait les contributeurs et contributrices dans leurs choix de mise en page.

Note: 1024px is mentioned as a minimum size to consider in the WP:Manual of Style/Layout page. That’s not quite the same thing, though.

Actuellement, un éditeur peut éditer une page à une largeur de 1500 px, tandis qu'un lecteur la lit avec une largeur de 1200 px. En mettant en place une largeur maximale, nous ne supprimons pas complètement cet écart. il y aurait toujours une variation en dessous de la largeur fixe, pour les personnes dont l'écran est plus étroit. Pourtant nous limiterions considérablement la gamme de variations.

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.

Exemple de largeur limitée à 960px (barre latérale repliée)

Exemple de largeur limitée à 960px (barre latérale dépliée)

Notes supplémentaires

Déstructuration des modèles, contenus, pages spéciales, etc.

Une partie de ce qui fait de Wikipédia, et des autres wikis Wikimédia, un outil puissant de partage des connaissances est qu'il y a très peu de contraintes sur la façon dont les informations sont présentées. Il en résulte une grande variété d'éléments différents sur les pages : tableaux, galeries d'images, diagrammes, images panoramiques, graphiques, formulaires, cartes, boîtes à catégories, etc. We have dealt with the challenges of designing the mobile site, and got the content to look good. C'est pourquoi nous reconnaissons qu'il y aura des situations où le contenu de la page n'aura pas l'air bien, compte tenu de l'affichage maximal. Notre plan actuel est le suivant :

• 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. Pages spéciales ne sont pas véritablement destinées à être « lues ». Elles fonctionnent davantage comme des listes ou des tableaux de bord. 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 : https://di-collapsible-sidebar-5.firebaseapp.com/Tea

Anciennes discussions

Ce sujet a déjà été discuté par le passé.

• 2014 – discussion sur le projet Typography Refresh

N'hésitez pas à ajouter ici des liens vers d'autres conversations antérieures.

Gérer la pleine largeur

The fullscreen toggle

Until October 2022, logged-in users were only able to switch between the limited and full content width using gadgets. According to the English Wikipedians, this was insufficient. We decided to build a toggle. (On the right, you can see a screenshot of this toggle.) It needed to be visible and available to both logged-out and logged-in users. As a result, we have:

1. Built a preference for logged-in users. It allows for the width to be set across pageviews and wikis. The preference is available in the appearance section of the preferences page (Activer le mode de largeur limitée). It may also be set as a global preference.
2. Built a toggle for logged-in and logged-out users. The toggle is available on every page if the width of the screen is larger than 1400px. Selecting the toggle increases the width of the content area.
   • For logged-in users, the toggle also controls the preference mentioned in 1 above. For example, if you click the toggle on the page and visit your preferences page, you will notice that the enable limited width mode checkbox is unchecked.
   • For logged-out users, initially, the toggle set the width on a per-page basis. This means that after refreshing the page or opening a different page the width would return to the default (limited) state.
   • After making our skin the default on English Wikipedia, we heard concerns about the setting for logged-out users. After coordinating with many teams, we made a change. Since February 2023, all users see the width setting of their choice despite refreshing pages or opening new ones.

Why did the toggle work on a per-page basis initially? This was because in principle, preferences are not available for logged-out users. The lack of preferences for logged-out users doesn't only apply to this skin. (You may learn more about the technical limitations.) We have managed to find a short-term bypass. We have more work to do to make sure this solution may be maintained. We might use a better solution in the future. This could be applied to settings such as font size or dark mode.