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

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

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

最後に、自前の調査をして自分たちで結論を出すやり方はどんなときも重要ですが、大手のウェブサイトの大多数ではコンテンツの表示幅に同様の制限を設けている点にも、配慮する価値があると考えます. 例をあげます. 学術専門誌の『ネイチャー』、報道の『ニューヨークタイムズ』紙、政府と政府を結ぶウェブサイトの「国際連合」、学術論文作成の「LaTeX」、文書作成機能のグーグルドキュメント（Google Docs）あるいはイーサーパッド（Etherpad）を調べました. 前述の例はその他の調査に加えて、私たちの決定を後押ししてくれるものです.

つまり、'''コンテンツの幅を制限すると読みやすくなり、目が疲れにくく、情報の定着が改善します. '''

でも、空白スペースはどうも気になってしまいますけど？！
これまで編集者 30 名ほどから（特に大型スクリーンの利用者）、ページの左右に余白が広く出るのが嫌だという意見を聞き、その人たちの中にも行の幅が狭い方が読みやすいという意見がありました. このイライラの原因は主に2つに分けられそうです. 私たちの課題はできるだけ優れた閲読体験を提供することで、画面をびっしりとピクセルで埋めつくすことではありません. またこの事例では少ないほど得るものが多い — 行が短いほど人はたくさんの量を読めること、またサイドバーほかの要素に目移りしたいため、集中しやすいことがわかります. 最適なレイアウトに余白が含まれるとしたらそれでよい — 余白そのものは悪くないから.
 * 1) The white space feels like wasted space
 * 2) The white space is bright and distracting

上記に加え、プロジェクトの進展につれて余白の一部を他の用途に利用することも考えています. 既に画面左の余白にサイドバーを置いて常置する（スクロールしてもねばっこく常に表示される実験を始めました (リンク先に試作版があります. ) プロジェクトが進行したら、目次一覧および/あるいはページツールをコンテンツの横に並べる形式も試す計画です. また、、コンテンツの幅を制限すると、コンテンツのレイアウトについても、右欄に基礎情報ボックスや画像のために専用の欄を作るなど、新しい選択肢が生まれます.

利用者が小さいモニターに取り替えればいいのでは？
確かに、そういう意見もありました. もしコンテンツを狭い幅で表示させたいなら、自分でブラウザのウィンドウを小さくするなり、ページの最下部に「モバイルビュー」ボタンがあるから、クリックすればよいという考え方です. 前述したとおりです. 利用者の多くは記事を読むために私たちのプロジェクトを開くのですから、画面レイアウトはその使用事例に最適化する必要があるのです. 第一印象はたった1回で決まるわけで、サイトに来た人々にその瞬間から最高の経験をしてもらうため、細かな調整など不要なほうが良いのです.

表その他のテンプレートは、行の幅を制限するとフィットしません. それじゃ困るのでは？
表にスライドバーをつけて、横に長く伸ばしてあり、幅が今回の変更後の設定値を上回る事例はいくつか報告されています. ここでご指摘したいのは、私たちの利用者の大部分は大型画面を利用せず、ウィキペディアの閲読にラップトップを使っているため、表やテンプレートには今回の変更以前に悩まされてきた点です. 私たちには、あらゆるコンテンツがどんな訪問者にも必ず読みやすくなるように努力する責任があります.

設定項目にすればよいのでは？
MediaWiki インターフェースの優れた点のひとつは、利用者が自分で設定できる部分が多いことです. またもしコンテンツの表示幅を設定項目にして変更できるようにした場合、編集者と閲読者の共通の経験として、果たして役に立つのか疑問があります. 編集者にとっては、これはページのレイアウトを決めるときに便利なはずです（注記：英語版ウィキペディアのスタイル・マニュアルには幅の値を 1024px と記載していますが、ここの話題とは別件です. ） 編集者にとって、現状ではページ幅を 1500px にして作業をするかもしれませんが、閲読者への表示幅は 1200px です. 最大幅の導入により、この差異を全く排除しようとしているのではありません（もちろん最大幅よりも狭い画面で閲読する利用者もいるでしょう）が、バリエーションの幅をかなり縮めることにはなります.

こういう背景があり、設定項目にするという案に絶対に反対という立場ではありません. もし新しい版のベクター外装をずっと使いたいけれど幅の上限は不用な場合は、ローカルのユーザースクリプトもしくはガジェットをご利用ください. こちらをおすすめします.

960px を幅の基準にした理由は？
このページに決定の背景について詳細を記述しましたので、読んでいただけるでしょうか.

最大規模のウィキ群ではいつごろ導入されますか？
それぞれのコミュニティの皆さんがテストに参加される場合を除き、2020年は無理です. 現在までに収集したデータと早期導入者 のテスト結果に基づき、最初の機能の開発に特化しています. 今後、変更を既定として2021年には取り入れたいと考えています.

姉妹プロジェクト群とか、ラテン文字以外のウィキでの導入は？
導入します. これまでに早期導入 ウィキの一覧を作り、さまざまな規模や表示文字のウィキがあります. あるいはまた、ウィキペディア以外のプロジェクトも1件以上、選択するように留意しました.

どのウィキで変更が反映されるのですか？
現状の対象とは次のとおりです.


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


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


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


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

このリストにどんどんウィキを増やしていこうとしています.

私がいるウィキで導入したいんですが？
デスクトップの改善案を既定で表示するには、次の方法があります.
 * 1) コミュニティで相談してから同意を形成.
 * 2) サポートを受けるには連絡担当 SGrabarczuk (WMF)に知らせる.  email: sgrabarczuk-ctr@wikimedia.org.

モノブックやタイムレスに影響は？（Monobook、Timeless）
影響しません. ベクターのみ変更します. 2010年以来、[ ベクター]（Vector）はウィキメディアのウィキで既定のインターフェースです. 他の外装は、[ モノブック]、[  タイムレス]、[  ミネルヴァ]、[  モダン]のいずれも左右しません.

表や地図、通知ボックス（a-/f-/o-/tmboxes）、情報ボックスやナビゲーションボックスその他のテンプレートは改善しないのですか？
対象外です. 薄いグレーの背景がかかる記事のコンテンツ に相当する要素は変更しません (例外は目次のみ).

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

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

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

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

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


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

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

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

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

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


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


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

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