Reading/Web/Desktop Improvements/Features/Limiting content width/ja

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

このプロジェクトの主な目的の 1 つは、ウィキペディアや他のウィキメディアのウィキ群を、新規参入者にとってより快適なものにすることです。 One way in which we aim to do this is by making the experience of reading articles more comfortable.

快適な (あるいは不快な) 読書体験とは何か? 調査によると、いくつかの要因があるようですが、その中でも特に重要なのが行の長さです。 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. 他にも関連するいくつかの研究がウィキペディアの記事 Line length に記載されていますが、いずれも 1 行あたり 40 文字から 75 文字を推奨しています。

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



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


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

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


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

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


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

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

User testing with editors

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



主な理由は、ウィキメディアのウィキ群のページの読みやすさを向上させるためです。 そのため、おそらく最初の質問は: コンテンツ領域の最適な幅をどうすれば把握できるか? 文章を読みやすくするための最適な行の長さについては、研究に基づいた推奨事項があるため、まずはそこから始めてみましょう。 しかし、ウィキメディアのウィキ群の記事は、一般的な記事やウェブ ページとは異なる点があります。 They are unique both in how long they are and in the variability of layout from one article to the next. これらの要因により、(直線的な読書とは異なり) コンテンツのスキャンや検索の必要性が通常よりも大きくなる可能性があります。 これらの違いを考慮して設計しなければなりません。 そこで私たちは、ウィキメディアのウィキ ページは、一般的に推奨されているものとは異なる行の長さを必要とするほど固有なものなのか、と問う必要があります。 以下では、私たちがどのようにして設計上の推奨値である最大幅を決めたかを説明します。

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 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]. このガイドラインに準拠している人気サイトは数多くあります。 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). さらに、ウィキメディアのウィキでは、画面の幅が大きくなるにつれて、1 行あたりの文字数が増えていきます (一方、前述の他のサイトでは、1 行あたりの文字数は変わらず、最大幅の制約の結果となっています)。 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. 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:

Line widths and character counts
コンテンツの幅 Paragraph next to an infobox Uninterrupted paragraph
600px 1 行に 30 文字以下 1 行に 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.

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:

  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.

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