阅读/网页/桌面版改进/功能/有限制的宽度

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 59% complete.
Other languages:
English • ‎français • ‎中文 • ‎日本語

本项目的主要目标之一是使维基百科和其他维基媒体的维基更加欢迎新来者。我们的其中一个目标是让阅读文章的体验更舒适。

什么是舒适(或不舒适)的阅读体验?根据研究,有几个促成因素,其中一个主要因素就是行长。 IBM高级学习中心Peter Orton博士的研究“计算机文本行长影响阅读和学习”的结论是,行长越长,某人阅读并最终学习且保留文本信息就越困难。 在维基百科的文章行长中可以找到其他一些相关的研究,所有这些研究都建议每行40到75个字符。

虽然在维基媒体维基上实现推荐的行长并不是特别容易,但我们将使用最大宽度来限制内容的宽度,以使维基上的大部分文字更接近推荐值。

你可以了解更多关于这个功能背后的研究和考虑

发布计划

我们于2020年5月开始向办公维基(Office Wiki)和测试维基部署第一次变更,并计划在接下来的几个月中继续在我们的早期采用者维基部署。有关更多详细信息,请参见我们的主功能页面

功能描述及要求

该功能的主要功能是限制文章内容的宽度。 然而为了确保页面上的其他元素(即侧栏和头部)不会与内容漂移太远,我们增加了两个额外的容器。 第二个容器确保侧边栏保持靠近内容。 然后为了防止头部与内容和侧边栏漂移得太远,还有第三个容器来限制页眉的最大宽度。

从技术角度来看:大多数页面的内容都被放置在一个最大宽度为960px的内容容器中。 还有两个额外的容器来帮助管理界面其他部分的宽度,如标题和侧边栏:工作区容器(最大宽度为1440px)和页面容器(1650px)。 以下是说明这些容器如何工作的图表。 有些页面的内容将受到内容容器的限制,包括历史记录、最近更改和其他类似的日志类型页面。 要浏览此功能的交互式演示,请[$ prototype参见此原型]。

设计要求及准则

这是一个GIF,说明了当前布局和更新后的布局与上述各种宽度限制的区别。

将当前布局与限制内容宽度的更新布局进行比较的GIF。

限制

这里主要的复杂之处在于,某些日志页面,如历史记录和最近更改,由于换行的原因,屏幕越窄将越难以阅读。 因此,我们决定以一种特殊的方式处理这些页面,将它们限制在工作空间容器(1440px)而不是内容容器(960px)中。 这里是一个原型的GIF,显示了在文章页面和相关历史页面之间的切换:

在新的Vector布局上显示条目页面与历史页面的宽度的GIF

使用编辑器进行用户测试

我们与多个维基站点的编辑进行了一轮反馈,并与编辑们一起讨论了有限制宽度内容的原型。 我们邀请编辑们对原型进行探索,并使用中央通知横幅提供他们的反馈。 大家对这个功能的感受不一:许多编辑对较短的行长表示赞赏,并认为这个功能创造了更舒适的阅读体验。 一些编辑不喜欢内容周围的空白,认为这是浪费空间。 我们正在平衡所有这些反馈意见和现有的关于行长和阅读舒适度的广泛研究。

目标和动机

可读性

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"[1]. 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.

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.

  1. 文章的顶部,位于信息框旁边的一段文字。
  2. 文章的中间,一个没有元素干扰的段落。

我们可以考虑这两种不同宽度的体验,分别计算每行的字符长度。

Line widths and character counts
内容宽度 信息框(infobox)旁边的段落 不间断的段落
600px 每行约30个字符 每行约94个字符
700px 约59个 约109个
800px 约76个 约125个
900px 约89个 约142个
1000px 约105个 约154个

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

建立共同的阅读体验

我们认为引入最大宽度对阅读体验有益的第二个原因是,它将致力于建立一个共同的体验,希望这将有助于编辑在做出页面布局的决定(注意:1024px在WP:格式手册/版面布局中被提到是一个需要考虑的最小尺寸,尽管这不是一回事)。 当前,编者可能在编辑一个1500px宽度的页面,而读者则在阅读一个1200px宽度的页面。 通过实施最大宽度,我们无法完全消除这种差异(因为对于屏幕较窄的人,仍会存在低于最大宽度的变化),但是我们将极大地限制变化范围。

结论

After thinking all of that through we’ve come to two conclusions:

  1. 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.
  2. 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.

补充资料

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.

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