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

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

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

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

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

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

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

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

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

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

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

最大規模のウィキ群ではいつごろ導入されますか？
今年後半には、変更点をすべてのウィキで既定にしたいと考えています. 早めの導入に参加するコミュニティを募集中です.

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

これらの変更がデフォルトで有効になるのはどのウィキですか？
現在は次の場所で有効になります.


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


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


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


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

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

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

自分の (サード パーティ) ウィキで有効にするにはどうすればよいですか？
まず初めに、を確実にダウンロードします. 安定版は2021年半ばに公表される点にご留意ください. それでもリスクを承知で変更点を確認したい場合は、最後尾にに以下の文字例を追記します.

これら改善がお役に立ったようなら、なりよりです！

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

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



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

コミュニティとの協調の方法は？

 * 1) 実装の前段階：
 * 2) 利用者調査を行い、ガジェットユーザースクリプトを査定しました. 詳細はをご参照ください.
 * 3) さまざまなウィキに連絡を取り、早期の採用への参加を呼びかけました.
 * 4) ウィキマニア2019で円卓会議にかけました (成果をご参照ください. )
 * 5) 試作版のテストグラウンドを2件実施しました. 編集者にとって当チームの構想を伝えるもので、評価できる点とわかりにくい点を共有するために使えます.
 * 6) Shortly after the deployment of each feature improvement, we collect usage data via  for each early adopter wiki.
 * 7) We run A/B tests for logged-in users. A half of them can experience the changed interface, and a half does not see any difference. Next, we compare the statistics. In the case of negative results, we improve the change or roll it back.
 * 8) For logged-out, we compare before and after. Unfortunately, we are not able to perform A/B tests on logged-out users.
 * 9) We watch the project talk page. We also engage in discussions on individual wikis regularly.
 * 10) Our  make it easier for us to work with a few communities more closely, react more quickly and effectively.

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

無効にするリンクを除去してくれませんか？
それはできません. Legacy Vector (従来版のベクター外装) はそのリンク下に結びついており、たとえば Monobook など、過去に既定だった他の外装と処理は同じです.

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

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

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


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

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

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

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

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


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


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

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