Please do not mark this page for translation yet.
该功能的主要功能是限制文章内容的宽度。 然而为了确保页面上的其他元素（即侧栏和头部）不会与内容漂移太远，我们增加了两个额外的容器。 第二个容器确保侧边栏保持靠近内容。 然后为了防止头部与内容和侧边栏漂移得太远，还有第三个容器来限制页眉的最大宽度。
从技术角度来看：大多数页面的内容都被放置在一个最大宽度为960px的内容容器中。 还有两个额外的容器来帮助管理界面其他部分的宽度，如标题和侧边栏：工作区容器（最大宽度为1440px）和页面容器（1650px）。 以下是说明这些容器如何工作的图表。 有些页面的内容将不受到内容容器的限制，包括历史记录、最近更改和其他类似的日志类型页面。 To explore an interactive demo of this feature please see this prototype.
这里主要的复杂之处在于，某些日志页面，如历史记录和最近更改，由于换行的原因，屏幕越窄将越难以阅读。 因此，我们决定以一种特殊的方式处理这些页面，将它们限制在工作空间容器（1440px）而不是内容容器（960px）中。 这里是一个原型的GIF，显示了在文章页面和相关历史页面之间的切换：
我们与多个维基站点的编辑进行了一轮反馈，并与编辑们一起讨论了有限制宽度内容的原型。 我们邀请编辑们对原型进行探索，并使用中央通知横幅提供他们的反馈。 大家对这个功能的感受不一：许多编辑对较短的行长表示赞赏，并认为这个功能创造了更舒适的阅读体验。 一些编辑不喜欢内容周围的空白，认为这是浪费空间。 我们正在平衡所有这些反馈意见和现有的关于行长和阅读舒适度的广泛研究。
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.
- The research study is more rigorous.
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".
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.
- Size Matters: Balancing Line Length And Font Size In Responsive Web Design
- Computer text line lengths affect reading and learning by Peter Orton, Ph.D. IBM Center for Advanced Learning).
- 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