Recommendations for mobile friendly articles on Wikimedia wikis/ja

本文書では、MediaWiki のウィキの経験から、どうすればモバイル端末利用者に最も役立つ編集者になれるかアドバイスを行います. この文書の執筆はモバイル用アプリとウェブの複数の開発者で、MediaWiki のコンテンツ担当歴はそれぞれ6年以内です. モバイルに適したコンテンツから選んだいくつかの要点に基づき、実用的なガイドにまとめてあります.

ウィキメディアのウィキでは、訪問者の過半数がモバイル版サイトにアクセスしており、多くの地域ではウィキメディアのコンテンツにアクセスできる主要な手段は、モバイル版になっています.

Category:モバイルに適していないテンプレート（wikipedia:Category:Templates that are not mobile friendly）など、テンプレート管理用のカテゴリの使用が推奨されており、モバイル版で問題のあるテンプレートにフラッグを立て、修正の手間を分担するために役立つ方策です.

Wrap wide images and tables
If an image or table is larger than 600px consider how it will display on mobile or smaller monitors. If the image should scale down, consider the use of TemplateStyles to define that behaviour. If the image should become horizontally scrollable you will need to use a `noresize` class on the image to disable Minerva optimisations as well as provide a containing element with overflow scrolling set. See w:Template:Wide image as an example.

 Bad example 

 Good example 

プロジェクト横断的なテンプレートのHTMLは標準的なクラス名を使ってマークアップ
メッセージ用テンプレートのチェコ語版は、出力は見た目は英語版に似ていても、HTMLマークアップは全く異なります.

モバイル版サイトは、同じ用語を使って書かれたコンテンツに依拠しています. モバイル版の使用感を異なる言語間で一貫させるには、意味論的に類似した用語を使うことが重要です.

多くの言語版でテンプレートを英語版ウィキペディアからコピー&amp;ペーストしている現状から、「標準的」名前のほとんどが英語優先という傾向があるものの、名前には最も広く使われるクラスを反映するような方向転換を大いに検討したいと考えています. とりわけ、ambox の名前は意味論的定義を改良する必要があります.


 * .infobox - 事項 (例 dob = 2018-12-25; name = Santa Claus Junior) の要旨を構成要素で示す. 例えばTemplate:Infoboxなど.
 * .hatnote - リダイレクトや類似の記事名があることをページ冒頭に示す. ja:Template:Hatnote (頭注) など.
 * .ambox - ページに問題点があると示す. ja:Template:Amboxなど.
 * .ambox .mbox-image - 問題点ごとにアイコンを割り当てる. ja:Template:Amboxなど.
 * .ambox .mbox-text-span - 問題点のみ記述する（修正法はなし）.
 * .ambox .hide-when-compact - 問題点の修正法を説明. （訳注:おそらくモバイルでは非表示にする）

悪い例
 * （訳注：おそらく、意味論的に非常にあいまいなクラス名を使っている）

Template:Infobox

良い例

可能であれば基礎情報ボックスをウィキテキストの上に配置しない
infobox（基礎情報ボックス）を記事の最初に配置すると、モバイル版での記事の可読性と読み込み時間に影響します. 現在のモバイル版ソフトウェア はこの問題を修正処理しますが、時には失敗することもあるため、可能なら常に以下の並べ方にしてください. さもなければ正しい順序に修正できたか、実際にモバイル機器で編集結果を確認してください.

infobox を最初に置く場合の可読性の点では、閲覧者がその主題の導入文や文脈に触れないうちに詳細情報を読むことになり、しばしば混乱をもたらします. 特に閲覧者がよく知らない主題では、わざわざ infobox の内容をスクロールしないと自分が読みたかった記事を読んでいるかすら確認できない事態が露見しました. モバイル版とデスクトップ版はサイト表示の一貫性を実現し（デスクトップ版も第1段落をページの上位に配置）、閲覧者は先に記事の主題に触れてからinfobox をスクロールすればよいように変更しました.

読み込み性能の観点から、 infobox を2番目の位置へ移動して平均読み込み時間が大幅に減少すると、閲覧者に対してコンテンツを以前よりも早く表示できるようになります.

詳細情報:

悪い例

良い例

メタデータ（座標を含む）は記事の末尾に
デスクトップ版表示では座標テンプレート(coordinate)を記事の右上に置く傾向があり、その位置はモバイル版だと実用的ではありません. 画面サイズのせいで上部にスペースが確保できないからです. こうした情報を記事本文の例えば末尾などに配置すると、モバイル版機能の選択肢を増やし、同時にモバイル版でも表示位置を確保できます.

メタデータを末尾に配置することの恩恵は他にもあり - （ポップアップ）アルゴリズムを助け、モバイル版サイトの第1段落の検出処理を早めて記事の要約作成を支えます.

悪い例

良い例

頭注、ambox、infoboxはテンプレートの使用順を統一
モバイル版のコンテンツは、表示スタイルは変更できても、コンテンツ自体の移動はできません. 要素を種類別にグループ分けすると、それに従ってデータ処理するモバイル版サイトやアルゴリズムに適合します.

モバイル版の構成要素はいわゆる頭注と呼ばれるもの(Template:Hatnoteなど)の次にambox (ページの問題点を示すTemplate:Amboxなど)が続き、配置はページの最上部だと想定されています. Infobox や他の要素はこれらの後に置かれます.

この順序が守られない状況では、モバイル版サイトによるコンテンツの最適化はできず、コンテンツはモバイル向けに最適化されません.

悪い例

良い例

サイズと配置に影響するプロパティをインラインの書式に使わない
CSSのプロパティのうち width、float、height を含む値はモバイル版で問題の原因になりやすいです.

大きな値が指定された場合、padding、border、margin も問題を起因しやすくなります.

通則的に、CSSのプロパティにて 100px 以上のピクセル値を使う場合、モバイル版で表示テストを行う必要があります.

理想的には、これらのプロパティに関連する要素はすべて、クラスと とメディアクエリを使い、モバイル版とデスクトップ版の2通りの異なる処理を提供できるようにするべきです.

悪い例

良い例

表の使用はデータに限定
説明のために表 (tabel) を使用することはやめてください. 表をモバイル用に最適化するには非常に手間がかかる上、説明用の要素は通常、モバイル向けの最適化処理で壊れてしまいます. 表 (訳注： タグ) のレイアウトを、 タグを使ったレイアウトに変更すべきです.

よい解決策を適用する代わりに、モバイル版では残念ながらこれらの要素を非表示にするしかありません. 例えばナビゲーションボックスがもっとも顕著です.

Nested tables
If you do need to use tables, note they are designed in responsive design/flex in Mobile version.

メインページは必ずモバイル最適化する
は検討課題が非常に多いため、説明があります.

テンプレートは単一ルートの要素に限定し認識可能なCSSクラスを持たせる
ウィキペディアのコンテンツの大部分は構造化されていません. コンピュータ解析と表示向けに最適化するヒントとしては、テンプレートの最も外側は必ず単一のHTML要素にし、その要素には固有のCSSクラス名を与え、このクラス名を全言語版のウィキで共有させる方法があります. この方法により、モバイル版ウェブサイトなどのソフトウェア (コンテンツサービス、Andoroid や iOSのネイティブなアプリなど) のコンテンツ認識が劇的に改善します.

悪い例

良い例

複数の問題点テンプレートの折りたたみ
記事に複数の問題点がある場合、それらを単一の「問題テンプレート」にまとめてから、折りたたみを指定します. モバイル版の問題点テンプレートは数値空間を占有してしまいますが、折りたたみを指定するとモバイルに適した外装に選択を増やします.

このことは特に、削除依頼に出された記事で問題になります.

悪い例

良い例

画像、情報ボックス、表の配置を限定しない
記事の表示の仕方をあらかじめこうであるべきだと限定しないよう、注意してください. デスクトップ版では2つの画像を置いても文の回り込みを特定できますが、モバイル版でそれと同じ表示ができるわけではありません. つまり「右の表」とか「左に示した画像」のような文は使わないでください.

記事の表示は、それぞれのパソコン、モバイル端末で流動的に異なると考えることが大事です.

文中で画像の参照が説明に必要ならば、縦に配置する方が安全です.



悪い例

良い例

ページ内の画像数を制限する
モバイル用サイトでは画像の遅延読み込み (lazy load) を行うため、大量の画像がある記事をモバイル端末で開こうとするとタイムアウトが発生することがあります.

画像の数を決めるには、ブラウザの開発者ツール（デベロッパーツール）で次の JavaScript を実行するとヒントが得られます. 理論上、単一のページに掲載する画像の上限は100枚です（サイズの大小に無関係）. 画像点数が1万超のページは、モバイル機器ではアクセスできないので要注意です.

以下の例では表の中で画像の代わりに、UnicodeのEmojiやシンボルを使っています.

悪い例

良い例

モバイルに適した「ページの問題点」（amboxテンプレート）の作り方
「ページの問題点」のテンプレートをモバイルに適合させるには、いくつかのルールがあります.

ambox クラスを使う
クラスには「ページの問題点」の最も重要度が高い要素を選びます.

amboxクラスを使って重大性を明確にする
Minerva の外装との適合性のために、これらのテンプレートのクラスによって指定されたメタデータから取得して表示されます. 画像の場合は、 クラスです. （または  クラスの要素の中に入れる）クラスを追加して（以下に示す）重大性の正確性に従って、その問題の種類が取得されるようにできます.

悪い例

良い例

このクラス指定が存在すれば、Minervaスキンは適切なアイコンを使います.

問題についての文章を2行に制限する
2行を超えたら、 クラスを指定した要素の中に入れます.

悪い例

良い例

問題点のテキスト部分をマーク付けする
「ページの問題点」のテンプレートには画像、メタデータなど複数の要素があり、どの部分でその問題点を説明しているかを、コンピューターが認識できるということが実に重要となってきます.

そのため、ほとんどのプロジェクトではクラスの  か   を使っています. このことでメッセージの重要部分を抜き出すことができ、モバイル用の低い解像度の画面において乱雑に表示される部分を減らします.

悪い例

良い例

Do not wrap infoboxes
A commonly observed pattern/mistake is to wrap an infobox either by incorrectly using wikitext or intentionally via HTML tags. The problem with this is it makes it difficult for mobile optimisations to apply as the infobox cannot be properly identified. If you must wrap them use the `infobox-container` class.

 Bad example 

 Good example