Reading/Web/Desktop Improvements/Frequently asked questions/ja

== コンテンツの幅を制限するのは？ 余白が大きすぎるのでは？ ==

読みやすさ
コンテンツの幅を制限する主な理由は、私たちのウィキにある素晴らしいコンテンツの読み心地を向上するためです. 私たちのプロジェクト群では、閲読も編集も利用事例として、文章を効率的な方法で読むことが非常に需要です. 読みやすさを左右する要素はいくつかあり – フォントの大きさ、コントラスト、フォントの種類、行の長さ – この中から、第一に行の長さに集中することにしました. 調査によると紙にプリントした文章の読みやすさは、1行あたり欧文で45 文字から 90 文字 (単位を cpl という). ウェブサイトの文章の読みやすさに関する最近の調査によると、基本的に35 – 100 cpl の範囲に注目し、推奨値はその下限に近い値です. しかしながら記事の行の長さに上限がない現状では、閲読者に対して推奨値よりもかなり長い行を読ませる結果になる可能性があります. これについて2005年の調査から、最近の研究をよく反映しています. 「行は短いと読みやすい」わけで、さらに言うなら、学習と情報の習得の視点では「行の幅を制限した文章を読んだ被験者は、行幅の広い文章を読んだ被験者よりも内容が頭に残った」.

Lastly, while it’s always important for us to do our own research and form our own conclusions, we think it’s worth noting the overwhelming amount of major websites that have similar limitations on content width. For example: academic journals like Nature, news websites like The New York Times, government and intergovernmental websites like the UN, academic documents like LaTeX, and word processors like Google Docs and Etherpad. Those examples, combined with the extensive research, gives us confidence in this decision.

In short, limiting the width of the content allows for better readability, less eye strain, and better retention of the information itself.

でも、空白スペースはどう処理すれば良いでしょう？！
We have heard from around 30 editors (particularly people with large screens) who are frustrated by all of the white space created on the sides of the page, though some of them agree that the width limitation is better for reading. There seem to be two main causes of this frustration: Our goal is to create the best reading experience we can, not to fill every pixel of the screen with content. またこの事例では少ないほど得るものが多い — 行が短いほど人はたくさんの量を読めること、またサイドバーほかの要素に目移りしたいため、集中しやすいことがわかります. If the best layout is one that includes white space that is okay — there is nothing inherently wrong with white space.
 * 1) The white space feels like wasted space
 * 2) The white space is bright and distracting

Additionally, as the project proceeds, we are hoping to begin utilizing some of this space for other functionality. We have started experimenting with making the sidebar sticky to the left side of the page (link to prototype). プロジェクトが進行したら、目次一覧および/あるいはページツールをコンテンツの横に並べる形式も試す計画です. また、、コンテンツの幅を制限すると、コンテンツのレイアウトについても、右欄に基礎情報ボックスや画像のために専用の欄を作るなど、新しい選択肢が生まれます.

Why can’t readers just make their browser windows smaller?
Several people have pushed back saying: if people want the content to be more narrow they can make their browser window smaller, or click the “Mobile view” link at the bottom of the page. As mentioned above: since we know that the majority of people come to read articles we should optimise the layout around that use case. We only have one chance to make a first impression and we should aim to give people a great experience as soon as they arrive, without them having to make adjustments.

Tables and other templates don’t fit within the limited width, isn’t that bad?
We have received several reports of tables with long horizontal scroll bars, or templates that expand past the limited width. We’d like to point out that a large percentage of our users, who don’t have large screens and are accessing Wikipedia from their laptops, already had issues with tables and templates even before the change. We should work to make sure that all of our content is as responsive as possible to accommodate all visitors.

Why don’t we just make it a setting?
One of the best parts of the MediaWiki interface is how configurable it is. And while we could make a setting for content width we wonder if it might be beneficial to encourage a common experience that is shared between editors and readers. This could potentially be helpful to editors when making decisions about page layouts (note: 1024px is mentioned as a minimum size to consider in the English Wikipedia Manual of Style, 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 max-width, for people with narrower screens), however we would be greatly limiting the range of variation.

That said, we are not inherently against configurability. If you would like to continue using the new version of the Vector skin without the limited width, you can use a local user script or gadget to do so. We can recommend this one.

How did we decide on 960px for the width?
Please review this page to learn more about how we made this decision:

When will these changes be available on the largest wikis?
Not in 2020, unless a community volunteers to join our testing. Currently, we are focusing on the development of our first features based on data we have already collected, and on the tests on the early adopter wikis. We do hope to see the changes set as default on all wikis in 2021.

Are the improvements to be implemented on sister projects and on non-Latin script wikis?
Yes. We have already made a list of early adopter wikis which represents various sizes and scripts. We also wanted to ensure that at least one non-Wikipedia project is selected.

Which wikis these changes are available on?
Currently, these are:


 * 姉妹プロジェクト群:
 * 
 * 


 * 非ラテン文字のウィキ群:
 * he:
 * fa:


 * ラテン文字のウィキペディア群:
 * eu:
 * fr:


 * 上記のほか：
 * Office Wiki（事務局ウィキ）

We are open to add more wikis to this list!

How can this be deployed on my wiki?
If you are interested to see the Desktop Improvements as default on your wiki,
 * 1) ask your community and reach the consensus,
 * 2) contact SGrabarczuk (WMF), email: sgrabarczuk-ctr@wikimedia.org if you need support.

Will Monobook or Timeless be affected?
No. These changes will be applied to Vector only. [ Vector] has been the default interface on Wikimedia wikis since 2010. No other skins will be affected, including [ Monobook], [  Timeless], [  Minerva] or [  Modern].

Will you improve charts, maps, a-/f-/o-/tmboxes, infoboxes, navboxes, other templates?
No. We will not change anything that's within the light gray article content area (except for the table of contents):

改善点の提案があるんですが？
タスクを Phabricator で立てて[ このプロジェクトのメインページ]に新しい節を作って投稿するか、連絡担当者 SGrabarczuk (WMF) にお知らせもしくはメール sgrabarczuk-ctr@wikimedia.org をお願いします.

無効にする方法は？
改善版は利用者の個人設定で有効にも無効にもできます. 左欄外のサイドバーには無効にするボタンを置きました (どのページにも置いてあるボタンの名前):.

バグ報告の方法は？
遭遇したバグが既に報告されたものかどうか、ページを開くとでチェックできます.

タスクを Phabricator で立ててDesktop Improvements project tag をタグ付けするか、連絡担当者 SGrabarczuk (WMF) にお知らせもしくはメールをお願いします. sgrabarczuk-ctr@wikimedia.org.

新しい外装を作っては？ レガシーのベクターはどうなりますか？
確かに新しい外装の作成はアイデアとして秀逸ですが、ウィキメディアの外装の場合、既存のものの改変の方がゼロから新規作成するよりも楽です. 理由は次のようにいろいろあります.


 * 既存の拡張機能、ガジェット、ユーザースクリプトに新規の外装を組み込む作業は非常に複雑であり、互換性の保持を管理するにはコストがかかりすぎること.
 * 新規の外装をビルドして管理し続けるのはしんどすぎること (まったくの置換は選択肢にならないこと).
 * 新しい外装の作成について、さまざまなコミュニティからの協力を効果的に引き出せる可能性が低いこと.

技術上、「デスクトップの改善」プロジェクトはこれまでの取り組みのうち や  と共通点があります. 唯一の相違点は今回の場合、条件が多いことです. ベクターの説明文書はほぼ変わらないままです.

レガシー版のベクターは残し、メンテナンスを続けます. 廃止の予定はありません.

ベータ機能だけにしぼればよいのでは？
ベータ機能は登録した利用者しか使えないところ、この機能は私たちの閲読者にも登録していない利用者にも役立つものです. そこでベータ機能のみに限定すると、ごく限られたタイプの利用者からしかフィードバックを得られず、私たちの利用者の基盤全体を反映しません. それに加えて、実装の初期の段階から閲読者にも匿名利用者にもフィードバックを寄せてもらうことを目指します.

この機能が成功したと見なす指標は？
既存の観衆の実用性を高めるため、次の方法を行います.


 * 他の人とのやりとり
 * セッション単位の検索回数が本プロジェクト期間に 5% 増加
 * プロジェクト単位の言語切り替えが本プロジェクト期間に 5% 増加


 * 親近感を感じる
 * サイトに対してポジティブでなじみやすいという感想の増加（アンケートと利用者テストで集計）
 * 信頼性と信用が増えたという感想（アンケートと利用者テストで集計）

この変化につき、さらに詳細を定義するため、このリストを拡充するなど今後も検討を続けるよ予定です.