Reading/Web/Desktop Improvements/Features/Limiting content width/ha
One of the main goals of the project is to make Wikipedia, and other Wikimedia wikis, more welcoming to newcomers. One way in which we aim to do this is by making the experience of reading articles more comfortable.
What does it mean to have a comfortable (or an uncomfortable) reading experience? According to research there are several contributing factors, a major one being line-length. The study Computer text line lengths affect reading and learning by Peter Orton, a Ph.D. at the IBM Center for Advanced Learning, concludes that the longer the line-length is the more difficult it becomes for someone to read, and ultimately learn and retain, textual information. Several other related studies can be found on the Wikipedia article Line length, all of which recommend between 40 and 75 characters per line.
While it's not particularly straightforward to achieve the recommended line lengths on Wikimedia wikis, we will be limiting the width of the content using a max-width in order to get the majority of text on the wikis closer to the recommendation.
You can learn more details on the research and consideration behind this feature.
Feature description and requirements
The main functionality of this feature is to limit the width of the article content. However in order to ensure that the other elements on the page (namely the sidebar and header) don't drift too far from the content we've added two additional containers. The second container ensures that the sidebar remains close to the content. Then to protect against the header drifting too far from both the content and the sidebar, there is a third container that constrains the maximum width of the header.
From a technical perspective: the content on most pages is placed inside a content container with a max-width of 960px. There are two additional containers that help manage the width of other parts of the interface such as the header and the sidebar: workspace container (max-width 1440px), and page container (1650px). Below are diagrams that illustrates how these containers work. There are certain pages whose content will not be constrained by the content container including History, Recent changes, and other similar log-type pages. To explore an interactive demo of this feature please see this prototype.
Diagram showing three layout containers, with the sidebar closed
Diagram showing three layout containers, with the sidebar open
Diagram showing three layout containers, with a special page
Design requirements and guidelines
Here is a GIF that illustrates the difference between the current layout and the updated layout with the various width limitations described above:
The main complication here is that certain log pages, such as History and Recent changes, become more difficult to read the more narrow the screen is due to line wrapping. Therefore we've decided to treat these pages in a special manner, constraining them only to the workspace container (1440px) rather than the content container (960px). Here is a GIF of a prototype that shows switching between an article page and the associated history page:
User testing with editors
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 objective is to improve readability of Wikimedia wiki pages. We decided to work on the width of the content area. There are research-based recommendations on this issue.
- English Wikipedia article on Line length provides a good overview.
- So does the essay by Professor 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."
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". 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)."
Popular sites with limited width
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.
- 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).
Comparison with Wikimedia wikis
Currently, an English Wikimedia wiki page on a browser window at 1280px has a character count of ~170 characters per line. That’s at the small end of the screen size spectrum.
On Wikimedia wiki the character count per line grows as the screen width grows. So on the second most popular screen-size, 1920px (21% of users), the character count per line is ~262, more than three times the recommended value.
Why not to choose "the simplest" solution
Based exclusively on the recommended line length, it seems like somewhere around 700px is reasonable. Why not limit the width such that we achieve the recommended line length, as other online content sites seem to?
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 need to skim and search within pages. This is different than linear reading a typical online article or book. This is supported by our research around reading time on Wikipedia.
- The more narrow we make the content, the longer the page gets. Perhaps the more difficult scanning becomes as well, because it 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, it is not straightforward to achieve a specific number of text characters per line. That is because Wikimedia wiki pages contain many elements that are floated inline alongside text.
Our design must take into account these distinctions.
- 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.
How do we do that?
There are two common experiences we might want to consider.
- 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|
At 1000px wide an uninterrupted paragraph of text is ~154 characters long, just about double the upper limit of the recommended range. Sometimes there are floated elements that are wider than infoboxes, resulting in more narrow columns of text next to them. Also there has not been a max-width. 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), because it might not have been a consideration (e.g. large tables).
Another approach is thinking about a grid-based layout. This is an approach that aims for both visual harmony on the page, and making decisions about spacing, widths, etc. easier. 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.
Establishing a common reading experience
Introducing a max-width would work towards establishing a common experience. Hopefully, it 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. That’s not quite the same thing, though.
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 difference completely. 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.
A note on 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. We have dealt with the challenges of designing the mobile site, and got the content to look good. This is why we do 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 intended for “reading”. They often function more as lists or dashboards. Until we have time to work through the details about 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: https://di-collapsible-sidebar-5.firebaseapp.com/Tea
This topic has been discussed in the past.
Please feel free to add additional links to past conversations here.
We began deploying the first iteration in May 2020 to Office Wiki and Test Wiki, and plan to continue to our early adopter wikis in following months.
See our main Features page for more details.
- Size Matters: Balancing Line Length And Font Size In Responsive Web Design
- Cite error: Invalid
<ref>tag; no text was provided for refs named
- Why 1280px? As of mid-2020, according to StatCounter, the most common computer screen size is 1366px wide, accounting for 22% of users. Imagining a browser window at nearly full width you end up with ~1280px.
- Again, we assume a browser window at nearly full-width.
- K. Pernice, K. Whitenton, J. Nielsen, "How People Read Online: The Eyetracking Evidence", 2nd edition
- Overview of the topic: Building Better UI Designs With Layout Grids