Leitura/Web/Melhorias da Área de Trabalho/Recursos/Limitando a largura do conteúdo
Um dos objetivos principais do projeto é deixar a Wikipédia, e outras wikis da Wikimedia, mais atraentes para novatos. Uma maneira que pretendemos atingir este objetivo é deixar a leitura de artigos mais confortável.
O que significa ter uma experiência de leitura confortável (ou desconfortável)? De acordo com pesquisas, existem vários fatores que contribuem, e um dos mais importantes é a largura das linhas. O estudo Largura das linhas de texto em computadores afeta leitura e aprendizado, por Peter Orton, doutor no Centro de Aprendizado Avançado da IBM, chegou à conclusão de que quanto mais longa a linha, maior a dificuldade de leitura e, assim, de aprendizado e retenção da informação. Vários outros estudos relacionados podem ser encontrados no artigo da Wikipédia sobre largura da linha (em inglês), todos os quais recomendam entre 40 e 75 caracteres por linha.
Apesar de não ser particularmente fácil atingir as larguras recomendadas nas wikis da Wikimedia, estaremos limitando a largura do conteúdo utilizando uma largura máxima para que a maioria do texto das wikis estejam dentro do recomendado.
Você pode ler mais detalhes sobre a pesquisa e considerações por detrás deste recurso.
Plano de lançamento
Começamos a implantação da primeira versão em maio de 2020 nas wikis da Fundação e de testes, e pretendemos passar para as wikis de participação antecipada nos próximos meses. Veja nossa página principal de recursos para maiores detalhes.
Descrição do recurso e requisitos
A função mais importante deste recurso é a limitação da largura do conteúdo do artigo. Entretanto, para garantir que os outros elementos da página (como a barra lateral e o cabeçalho) não fiquem distante demais do conteúdo, adicionar dois containers a mais. O segundo container garante que a barra lateral permaneça próxima ao conteúdo. Então, para impedir que o cabeçalho fique longe demais tanto do conteúdo quanto da barra lateral, existe um terceiro container que limita a largura máxima do cabeçalho.
De um ponto de vista técnico: o conteúdo da maioria das páginas é colocado dentro de um container de conteúdo com uma largura máxima de 960px. Existem dois containers adicionais que ajudam a manter a largura de outras partes da interface, tais como o cabeçalho e a barra lateral: container da área de trabalho (largura máx. de 1440px) e container da página (1650px). Abaixo estão diagramas que ilustram como os containers funcionam. Existem certas páginas cujo conteúdo não será limitado pelo container de conteúdo, incluindo histórico, mudanças recentes e outras páginas de registro. Para explorar uma demonstração interativa deste recurso, favor ver este protótipo.
Diagrama exibindo três camadas de containers, com a barra lateral fechada
Diagrama exibindo três camadas de containers, com a barra lateral aberta
Diagrama exibindo três camadas de containers, em uma página especial
Diretrizes de design e requisitos
Aqui está um GIF que ilustra a diferença entre o layout atual e o layout atualizado, com as várias limitações de largura descritas acima:
O problema principal aqui é que certas páginas de registro, como o histórico e as mudanças recentes, ficam mais difíceis de serem lidas quanto mais estreita for a tela devido à quebra de linha. Portanto, decidimos tratar estas páginas de maneira especial, limitando elas somente ao container da área de trabalho (1440px), ao invés do container de conteúdo (960px). Aqui está um GIF de um protótipo que mostra a diferença entre uma página de conteúdo e sua página de histórico:
Teste com editores
We performed a feedback round with a prototype of the limited content width with editors across multiple wikis. Editors were invited to explore the prototype and provide their feedback using a central notice banner. There were mixed feelings about the feature: many editors appreciated the shorter line lengths and agreed that the feature created a more comfortable reading experience. Some editors disliked the whitespace around the content and felt that it was wasted space. We are balancing all of that feedback with the extensive existing research about line-lengths and reading comfort.
Goals and Motivation
The primary reason is to improve readability of Wikimedia wiki pages. 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.
Without studying readability of Wikimedia wiki pages directly we can’t know what is optimal, but in an attempt to make an educated guess we start with the research on optimal line length for readable text. 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).
In comparison, a Wikimedia wiki page on a browser window at 1280px* has a character count of ~170 characters per line, and that’s at the small end of the screen size spectrum. (*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.
The question then becomes: why not limit the width of Wikimedia content such that we achieve the recommended line length, as other online content sites seem to? The short answer is: because our pages are different, and therefore people read them differently. 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.
Moon article at 550px wide, uninterrupted paragraph with a character count per line of ~83
Moon article at 750px wide, paragraph next to infobox with a character count per line of ~72
So how do we find a width for the content that accommodates both focused/engaged reading (shorter line lengths, less density) and scanning/searching/skimming (longer line lengths, more density)? 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. As stated earlier, without studying this directly (which we hope to be able to do during the course of this project) it is impossible to know what the optimal width is, but we can make an educated guess. While Wikimedia wiki pages are not uniform and contain a huge amount of variation in terms of layout, there are two common experiences we might want to anchor around when making this consideration.
- The top of an article, a paragraph of text situated next to an infobox
- The middle of an article, a paragraph with no elements interrupting it
We can consider these two experiences at various widths, counting the character length per line for each:
|Content width||Paragraph next to an infobox||Uninterrupted paragraph|
|600px||~30 characters per line||~94 characters per line|
Based exclusively on the recommended line length it seems like somewhere around 700px is a reasonable width. However we are trying to find a width that strikes a balance, and retains some of the density of the page to allow for easier scanning (with less scrolling). At 1000px wide an uninterrupted paragraph of text is ~154 characters long, just about double the upper limit of the recommended range. Other things we might want to factor in here are: sometimes there are floated elements that are wider than infoboxes, resulting in more narrow columns of text next to them. Also up until now there has not been a max-width, so while some editors might edit on narrower screens (or check how pages look on narrower screens) there’s likely content on pages that won’t look great at a narrower width (yet), simply because it might not have been a consideration (e.g. large tables).
Another consideration that might inform our approach here is thinking about a grid-based layout (for an overview of the topic please see Building Better UI Designs With Layout Grids). This is an approach that aims for both visual harmony on the page, and making decisions about spacing, widths, etc. easier. While the Vector skin does not currently use a grid, something we could do is think about the width of the infobox as a grid column (since they are such common elements), and then use a multiple of that to determine the content width.
India article with content at 3x infobox width
India article with content at 4x infobox width
Establishing a common reading experience
The second reason we think introducing a max-width could be beneficial to the reading experience is because it would work towards establishing a common experience, which hopefully would be helpful to editors when making decisions about page layouts (note: 1024px is mentioned as a minimum size to consider in the WP:Manual of Style/Layout page, though that’s not quite the same thing). 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.
After thinking all of that through we’ve come to two conclusions:
- It seems that a max-width in the range of 800–1000px is a sensible starting point.
We will center the content on the page to ensure that it looks good with the sidebar both open and closed.
- 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.
Showing content with a max-width of 960px (sidebar collapsed)
Showing content with a max-width of 960px (sidebar open)
Breaking templates / content / special pages / etc.
Part of what makes Wikipedia, and other Wikimedia wikis, a powerful tool for sharing knowledge is that there are very few constraints on how information is presented. 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:
- Work with our test Wiki communities to identify issues and discuss solutions using template styles or other existing tools.
- 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.
This topic has been discussed in the past. Please feel free to add additional links to past conversations here.
- Computer text line lengths affect reading and learning By Peter Orton, Ph.D. IBM Center for Advanced Learning