Reading/Web/Desktop Improvements/機能/コンテンツ幅の制限

This page is a translated version of the page Reading/Web/Desktop Improvements/Features/Limiting content width and the translation is 98% complete.

このプロジェクトの主な目的の 1 つは、ウィキペディアや他のウィキメディアのウィキ群を、新規参入者にとってより快適なものにすることです。 そのためには記事をより快適に読むことができるようにすることが大切です。

快適な (あるいは不快な) 読書体験とは何か? 調査によると、いくつかの要因があるようですが、その中でも特に重要なのが行の長さです。 ピーター・オートン(IBM高等学習センター)の研究「画面で読む文章の長さは読解と理解に影響する」(Computer text line lengths affect reading and learning by Peter Orton, a Ph.D. at the IBM Center for Advanced Learning)では、1行が長くなるほど、読解が困難になり、究極的には文章の情報を学んだり記憶したりことが難しくなると結論づけています。 他にも関連するいくつかの研究がウィキペディアの記事 Line length に記載されていますが、いずれも 1 行あたり 40 文字から 75 文字を推奨しています。

ウィキメディアのウィキ群で推奨される行の長さを実現することは特に簡単ではありませんが、ウィキ上のテキストの大部分を推奨に近づけるために、max-width (最大幅) を使用してコンテンツの幅を制限する予定です。

この機能の背景にある研究や考察の詳細を参照してください。

機能の説明と要件

この機能の主なものは、記事コンテンツの幅を制限することです。 しかし、ページ上の他の要素 (サイドバーやヘッダー) がコンテンツから離れすぎないようにするために、2 つのコンテナーを追加しました。 2 つめのコンテナーは、サイドバーがコンテンツの近くに保持されるようにします。 さらに、ヘッダーがコンテンツとサイドバーの両方から離れすぎないように、ヘッダーの最大幅を制限する 3 つめのコンテナーがあります。

技術的な観点から言うと、ほとんどのページのコンテンツは、最大幅 960px のコンテンツ コンテナー内に配置されています。 さらに、ヘッダーやサイドバーなどのインターフェイスの他の部分の幅を管理するための 2 つのコンテナーがあります:「ワークスペース コンテナー」(最大幅 1440px) と「ページ コンテナー」(1650px) です。 以下は、これらのコンテナーがどのように機能するかを示す図です。 コンテンツ コンテナーによってコンテンツが制限されないページがあります: 「履歴」「最近の更新」などの記録型のページがこれにあたります。 この機能の対話的なデモを試すには、こちらのプロトタイプを参照してください

デザイン要件とガイドライン

ここでは、現在のレイアウトと、上述したさまざまな幅の制限を受けた更新後のレイアウトの違いを示す GIF を示します:

 
現在のレイアウトと、コンテンツの幅を制限した更新後のレイアウトを比較した GIF

制約

ここでの主な問題点は、履歴や最近の更新などの特定の記録ページが、行の折り返しによって画面が狭くなるにつれて読みづらくなることです。 そのため、これらのページを特別な方法で扱い、コンテンツ コンテナー (960px) ではなく、ワークスペース コンテナー (1440px) にのみ制約をかけることにしました。 ここでは、記事ページと関連する履歴ページの切り替えを示すプロトタイプの GIF を示します:

 
新しいベクター レイアウトでの記事ページと履歴ページの幅を示す GIF

エディターによるユーザーテスト

複数のウィキで活動する編集者を対象に、コンテンツの幅を制限したプロトタイプでフィードバック ラウンドを行いました。 編集者にはプロトタイプを見てもらい、中央管理の通知バナーを使用してフィードバックを提供してもらいました。 この特集についてはさまざまな意見がありました: 多くの編集者は、行の長さが短くなったことを評価し、この機能がより快適な読書体験をもたらすことに同意しています。 編集者の中には、コンテンツの周りにある空白を嫌い、無駄な余白だと感じる人もいました。 これらのすべての意見と、行の長さや読みやすさに関する既存の研究結果とのバランスをとっています。

目標と動機

Readability

Research

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.

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

Web Content Accessibility Guidelines (WCAG)

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.[3] それでも画面幅のばらつきでは、小さいほうに寄っています。

Wikimedia のウィキの場合、画面幅が広がると1行単位の文字数も増加します。 そこで普及率第2位のスクリーンサイズとして、1920px (利用者の21%が使用) の場合には1行単位の文字数は最大半角262文字となり、推奨値の 3倍相当です[4]

いちばん「単純な」解決策を選べば良いのに

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.[5]
  • 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.
 
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

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?

Our solution

There are two common experiences we might want to consider.

  1. The top of an article, a paragraph of text situated next to an infobox
  2. 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
700px ~59 ~109
800px ~76 ~125
900px ~89 ~142
1000px ~105 ~154

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.[6] 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.

 
India article with content at 3x infobox width
 
India article with content at 4x infobox 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.

Conclusion

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.
 
Showing content with a max-width of 960px (sidebar collapsed)
 
Showing content with a max-width of 960px (sidebar open)

リリースの日程

私たちは、2020年5月に最初のイテレーションを Office Wiki と Test Wiki に展開し始め、以降の数か月間でアーリー アダプターのウィキ群にも展開する予定です。 詳細はメインの機能ページを参照してください。

References

  1. Size Matters: Balancing Line Length And Font Size In Responsive Web Design
  2. Cite error: Invalid <ref> tag; no text was provided for refs named Orton
  3. 1280px の根拠は? Template:時点で集計カウンターのStatCounterによると、パソコン画面のもっとも普及しているサイズは幅 1366pxで、利用者の 22% を占めています。 ブラウザのウインドウをほぼ画面いっぱいに表示するなら、1280px 以下に落ち着きます。
  4. Again, we assume a browser window at nearly full-width.
  5. K. Pernice, K. Whitenton, J. Nielsen, "How People Read Online: The Eyetracking Evidence", 2nd edition
  6. Overview of the topic: Building Better UI Designs With Layout Grids