Reading/Web/Desktop Improvements/よくある質問

From mediawiki.org
Jump to navigation Jump to search
This page is a translated version of the page Reading/Web/Desktop Improvements/Frequently asked questions and the translation is 81% complete.
Other languages:
Bahasa Indonesia • ‎Deutsch • ‎English • ‎Tiếng Việt • ‎Türkçe • ‎español • ‎euskara • ‎français • ‎polski • ‎português • ‎português do Brasil • ‎svenska • ‎српски / srpski • ‎עברית • ‎فارسی • ‎తెలుగు • ‎中文 • ‎日本語 • ‎한국어

コンテンツの幅を制限するのはなぜですか? 余白が大きすぎるのでは?

読みやすさ

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

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

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

でも、空白スペースはどうも気になってしまいますけど!?

ページのコンテンツの欄外に見出し一覧を表示した場合。ファルシ語版ウィキペディアの利用者SereniPityさんからの提案です。プロジェクトの目的によく適合しています。

これまで編集者 30 名ほどから(特に大型スクリーンの利用者)、ページの左右に余白が広く出るのが嫌だという意見を聞き、その人たちの中にも行の幅が狭い方が読みやすいという意見がありました。 このイライラの原因は主に2つに分けられそうです。

  1. The white space feels like wasted space
  2. The white space is bright and distracting

私たちの課題はできるだけ優れた閲読体験を提供することで、画面をびっしりとピクセルで埋めつくすことではありません。 またこの事例では少ないほど得るものが多い — 行が短いほど人はたくさんの量を読めること、またサイドバーほかの要素に目移りしたいため、集中しやすいことがわかります。 最適なレイアウトが余白が含まれるものだとしたら、それで構いません— '余白そのものは本質的には悪くないからです

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

利用者が小さいモニターに取り替えればいいのでは?

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

表その他のテンプレートは、行の幅を制限するとフィットしません。それじゃ困るのでは?

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

設定項目にすればよいのでは?

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

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

960px を幅の基準にした理由は?

このページに決定の背景について詳細を記述しましたので、読んでいただけるでしょうか。 Reading/Web/Desktop_Improvements/First_Prototype_Feedback_Report#Introducing_a_max-width

私たちのウィキの対応は?

最大規模のウィキ群ではいつごろ導入されますか?

We hope to see the changes set as default on all wikis later in the year. Each community is welcome to join the early adopters.

この改善は姉妹プロジェクト群やラテン文字以外のウィキにも実装されますか?

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

これらの変更がデフォルトで有効になるのはどのウィキですか?

現在は次の場所で有効になります。

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

どうすれば自分のホームであるウィキメディア ウィキで導入できますか?

デスクトップの改善案を既定で表示するには、次の方法があります。

  1. コミュニティで相談してから同意を形成。
  2. サポートを受けるには連絡担当 SGrabarczuk (WMF)に知らせる。 email: sgrabarczuk@wikimedia.org

自分の (サード パーティ) ウィキで有効にするにはどうすればよいですか?

First, make sure you have downloaded MediaWiki 1.36 . Be mindful that the stable version will be released in mid 2021. If you accept the risk and would like to see our changes anyway, add following lines in your LocalSettings.php :

$wgVectorDefaultSkinVersion = '2';
$wgVectorDefaultSkinVersionForExistingAccounts = '2';
$wgVectorDefaultSkinVersionForNewAccounts = '2';
$wgVectorIsSearchInHeader = true;
$wgVectorLanguageInHeader = true;
$wgVectorUseWvuiSearch = true;

We are glad to learn that you appreciate our improvements!

プロジェクトの対象範囲はどこまでですか?

モノブックやタイムレス(Monobook、Timeless)に影響はありますか?

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

表や地図、通知ボックス(a-/f-/o-/tmboxes)、情報ボックスやナビゲーションボックスその他のテンプレートは改善しないのですか?

対象外です。薄いグレーの背景がかかる記事のコンテンツ に相当する要素は変更しません (例外は目次のみ)。

Annotated Wikipedia Vector interface (logged-out).png

改善の提案はどのように行えばいいですか?

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

How do you work with the communities?

  1. Prior to the deployments:
    1. We performed user research, and reviewed gadgets and user scripts. See the Repository page for more details.
    2. We have been reaching out to various wikis asking to join the early adopters.
    3. We had a roundtable discussion at Wikimania in 2019 (see the outcomes).
    4. We have run two prototype testing rounds. Editors could gain an understanding of our ideas, and share what they appreciate or find confusing.
  2. Shortly after the deployment of each feature improvement, we collect usage data via API for each early adopter wiki.
    1. 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.
    2. For logged-out, we compare before and after. Unfortunately, we are not able to perform A/B tests on logged-out users.
  3. We watch the project talk page. We also engage in discussions on individual wikis regularly.
  4. Our contracted ambassadors make it easier for us to work with a few communities more closely, react more quickly and effectively.

技術面のその他の質問

どうすれば無効にできますか?

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

Will you remove the link that allows to opt-out?

We will not remove the opt-out link. Legacy Vector will continue to be available through that link, similar to other skins that have been default in the past, such as Monobook.

バグ報告の方法は?

遭遇したバグが既に報告されたものかどうか、ページを開くとReading/Web/Desktop Improvements/Breaking changes でチェックできます。

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

新しい外装を作っては? レガシーのベクターはどうなりますか?

確かに新しい外装の作成はアイデアとして秀逸ですが、ウィキメディアの外装の場合、既存のものの改変の方がゼロから新規作成するよりも楽です。理由は次のようにいろいろあります。

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

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

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

ベータ機能だけにしぼればよいのでは?

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

この機能が成功したと見なす指標は?

既存の観衆の実用性を高めるため、次の方法を行います。

  • 他の人とのやりとり
    • セッション単位の検索回数が本プロジェクト期間に 5% 増加
    • プロジェクト単位の言語切り替えが本プロジェクト期間に 5% 増加
  • 親近感を感じる
    • サイトに対してポジティブでなじみやすいという感想の増加(アンケートと利用者テストで集計)
    • 信頼性と信用が増えたという感想(アンケートと利用者テストで集計)

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

脚注

  1. "Calculating Line Length: an arithmetic approach" by Ernesto Peña, PhD, Visible Language Journal 、エルネスト・ペーニャ著「行の長さの研究:計算学的な視点から」
  2. Computer text line lengths affect reading and learning by Peter Orton, Ph.D. IBM Center for Advanced Learning(IBM高度学習センター ピーター・オルトン著「コンピューターの行の長さが閲読と学習に与える影響」)