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

From mediawiki.org
Jump to navigation Jump to search
This page is a translated version of the page Reading/Web/Desktop Improvements/Features/Limiting content width and the translation is 77% complete.
Outdated translations are marked like this.
Other languages:
English • ‎français • ‎中文 • ‎日本語 • ‎한국어

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. One way in which we aim to do this is by making the experience of reading articles more comfortable.

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. According to research there are several contributing factors, a major one being line-length. 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. See our main Features page for more details.

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 :

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é

Notre objectif principal est d'améliorer la lisibilité des pages des wikis Wikimédia. La première question est donc peut-être : comment savons-nous quelle est la largeur optimale de la zone de contenu ? Il existe des études qui recommandent une longueur de ligne optimale pour la lecture de textes, donc nous avons commencé par là. There are research-based recommendations regarding optimal line lengths for readability of text, so we should probably start there. Cependant, les articles sur les wikis Wikimédia sont par certains aspects assez différents des articles qu'on peut trouver sur d'autres sites. Ils sont uniques à la fois par leurs variations en terme de longueur et de types de mise en page selon les articles. Ces deux facteurs peuvent nécessiter une largeur plus ample pour pouvoir visualiser plus de contenu et rechercher l'information souhaitée (par opposition à une lecture linéaire). Notre design doit prendre en compte ces distinctions et spécificités. Nous devons donc nous demander : est-ce que les pages des projets Wikimédia sont suffisamment spéciales pour que les recommandations générales sur la largeur des lignes ne s'y appliquent pas ? Nous expliquons ci-dessous comment nous sommes arrivés à notre propre recommandation sur la largeur maximale sur nos wikis. 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 Size Matters: Balancing Line Length And Font Size In Responsive Web Design de la Professeure Laura Franz. L'étude 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. 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", and furthermore regarding learning and information retention "Subjects reading the narrow paragraphs had better retention than those reading the wide paragraphs"[1]. 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, 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).

À titre de comparaison, une page wiki Wikimédia affichée dans une fenêtre de navigateur à 1280px* compte environ 170 caractères par ligne, ce qui correspond à l'extrémité inférieure du spectre des tailles d'écran. (*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). Il faut ensuite tenir compte du fait que sur Wikimédia wiki, le nombre de caractères par ligne augmente avec la largeur de l'écran (alors que sur les autres sites mentionnés, le nombre de caractères par ligne reste le même, ce qui est le résultat des contraintes de largeur maximale). 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 (en supposant à nouveau que la fenêtre du navigateur est presque pleine largeur), soit plus de trois fois la valeur recommandée. Nous savons donc, pour commencer, que pour les paragraphes de texte ininterrompu, nous dépassons largement la limite recommandée.

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. The short answer is: because our pages are different, and therefore people read them differently. 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 é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.

Comment trouver une largeur de contenu qui permette à la fois une lecture ciblée/engagée (lignes plus courtes, moins de densité) et un balayage/recherche/écrémage (lignes plus longues, plus de densité) ? Sur la base des informations ci-dessus, on peut supposer que la largeur doit être limitée dans une certaine mesure, tout en permettant aux lecteurs de parcourir et de chercher, afin d'obtenir un plan visuel de la page sans avoir à la faire défiler trop longtemps. Based on the above information it seems safe to assume we should limit the width by some amount, while still enabling readers to skim and search around, obtaining a visual map of the page without having to scroll too much. Comme nous l'avons déjà dit, sans étudier directement cette question (ce que nous espérons pouvoir faire au cours de ce projet), il est impossible de savoir quelle est la largeur optimale, mais nous pouvons faire une supposition éclairée. Alors que les pages wiki de Wikimédia ne sont pas uniformes et contiennent une énorme quantité de variation en termes de mise en page, il y a deux expériences communes que nous pourrions vouloir ancrer autour de cette considération.

  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 :

Line widths and character counts
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

En se basant exclusivement sur la longueur de ligne recommandée, il semble qu'une largeur d'environ 700px soit raisonnable. Nous essayons toutefois de trouver une largeur qui permette de trouver un équilibre et de conserver une partie de la densité de la page pour faciliter la lecture (avec moins de défilement). À 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. D'autres éléments à prendre en compte sont les suivants : 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, jusqu'à présent, il n'y avait pas de largeur maximale. Ainsi, 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, simplement 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) (pour une présentation globale du concept, voir Building Better UI Designs With Layout Grids). 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. Quoique 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.

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. 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 (car il y aurait toujours une variation en dessous de la largeur fixe, pour les personnes dont l'écran est plus étroit), mais 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.

We will center the content on the page to ensure that it looks good with the sidebar both open and closed.

  1. It seems worthwhile to conduct a study focusing on the readability of Wikipedia articles specifically.

We hope to be able to find the resources to do this.

Notes additionnelles

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. Après avoir relevé les défis de la conception du site mobile et de la présentation du contenu, 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. 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. [$link1 Voici un prototype initial] montrant comment cela fonctionnerait : vous pouvez alterner entre "historique" et "lire" pour voir la différence.
  • Not to implement the max-width on Special pages.

Special pages are not necessarily intended for “reading”, they often function more as lists or dashboards, and until we have time to work through the intricacies of more responsive layouts for these pages we will be leaving them alone.

Here is an initial prototype of how this would work — you can switch between "View history" and "Read" to get a sense for it.

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.

Please feel free to add additional links to past conversations here.

  1. Computer text line lengths affect reading and learning By Peter Orton, Ph.D. IBM Center for Advanced Learning