Fandom


すべての物事に変化はつきものです。時を超えて不朽の価値が残るものもあれば、一方では流行りすたりが激しいもの、あるいは必要に応じて機能性が進化するものもあります。コミュニティを作り上げる私たちにとって、読者に提供する魅力的なコンテンツのデザインも時に大きな課題となります。世界中のFANDOMのユーザーは、今ではモバイルをはじめとする「セカンドスクリーン」体験に移行しつつあります。スマートフォンあるいはタブレットであれ、読者は単にテレビやゲーム画面で見るコンテンツ以上のものを求めています。ファンは没入型の体験を欲しがっており、状況や背景、攻略ガイド、仮説、また一部はネタバレすら欲求しているのです。今やほとんどのコミュニティにおいてモバイルのユーザー層が顕著であること、それも時には合計ページビューの60%がモバイルであることは、もはや無視できない状況です。

では、コミュニティの長期的な健全性のためにも、どうすれば最高のユーザー体験を実現できるのでしょうか? 答えは、モバイルユーザーを確実に引き込むために考えられた、良質なコンテンツデザイン用ガイドラインの策定と採用です。デスクトップでの体験が小さな画面には適さないことは一目瞭然です。今回の記事では、FANDOMで今でも散見される、必ずしも観客にとってベストな体験につながらない古い慣習をひとつずつ検証していき、改善策を提案していきます。

ナビゲーション機能を再考する

Wikipediaや、初期のWikiによく見られる過去の遺産がNavboxです。一連の短縮URLをレイアウトテーブルに詰め込んだNavboxは、モバイルユーザーにとって決して使いやすいものではありません。最近まで、見た目の問題からWikipediaのモバイルフォームにおいても表示されていませんでした。Navboxの代わりに、記事から記事へのナビゲーションをしやすくするいくつかの方法として、正しいカテゴリモバイルのメインページの使用、また、モバイル用記事の主な要素として、ポータブル・インフォボックス<navigation>タグを採用することが推奨されます。

コミュニティによってコーディングが異なる等の理由で、現時点では横方向のリストの完全な表示方法は無く、結果的にかなり長いNavboxが存在してしまいます。Mercuryにおいて書式設定ができない現状、Navboxに画面を割くのは難しく、代替策となる方法があることから、モバイル端末においてNavboxは表示していません。

基本原則:

  • 1つの記事がまとまったグループに含まれている場合、またそれが順不同の場合、Navboxグループではなく、カテゴリへの置き換えを検討してみましょう。カテゴリはMercuryおよびモバイルのメインページから簡単にナビゲーションでき、ウィキテキストへリンクすることも可能です。また、Mercuryでも見られるように、通常の記事と同じ文章やデータコンテンツを保持することができます。ユーザーや検索エンジンにとって、単に多くのリンクを貼るより、背景情報やそのグループに関する説明のほうが重要な要素となります。ユーザーに理解してもらうためには、グループ内記事の相関性がカギになります。
  • 記事がグループに属すもので、順序も関係する場合(前の記事・次の記事など)は、インフォボックス内でのナビゲーションが最適です。
  • 記事が並行して存在する別の記事と1対1の関係を持つ場合(ギャラリーやメインの記事のサブページとリンクする場合など)は、ポータブル・インフォボックスの<navigation>タグ内でのリンク使用が理想的です。

サブ記事や、並行する記事の間を行き来するために使うページ上のタブは、今でも多くのコミュニティで一般的に使用されていますが、デザインとしては扱いにくい面があります。場合によって、ナビゲーション用のタブがモバイル端末上で空白のページとして表示されてしまうことがあります。ほとんどの記事において、別の記事にリンクする簡単な方法としては、上記と同様にインフォボックス内で固有の関係性を持たせることが推奨されます。

Tabberを再考する

正しく使えば、Tabberは情報の表示と整理において効果的な方法です。ただし、問題の1つとして多くのコミュニティがtabberを適切に使用していない例が見られます。コミュニティの中には、FANDOM特有の<tabber>拡張機能ではない特殊なバージョンやカスタマイズされたtabberを採用しているところがあります。ただし、以下のヒントは上記のtabberバリエーションにも適用できます。

タブ列は1つのみに限定しましょう。タブ列が複数に分かれるとUI要素が飛び飛びになってしまい、 空間記憶に悪影響を及ぼすため、ユーザーはすでに訪問したタブを覚えることができなくなってしまいます。また列が複数あること自体、デザインが複雑すぎる証拠です。タブの数が1つの行に収まりきらない場合は、デザインの簡素化を検討しましょう。 Jakob Nielsen, Ph.D.、世界のUI/UXデザイン研究者の中でも第一人者であるwikipedia:ja:ヤコブ・ニールセン(ユーザビリティ・コンサルタント)

ユーザーにオプションを明示することが重要です。論理的には、これらオプションは同等レベルでなければいけません。たとえば音楽に関するコンテンツの場合、音楽ジャンルのタブ化は自然なデザイン選択です。あるいはニュースアプリの場合、カテゴリやトピック別にまとめることができます。様々なカテゴリから組み合わせないようにしましょう。ユーザーにとって混乱しやすいページになり、整理されていないリストから選ぶことが難しくなってしまいます。 Mobiscroll、ウェブコンポーネントを扱うUIデザイン会社

タブは、関連するコンテンツの上部に1行にして表示しましょう。タブに付けるラベルは、含まれるコンテンツを簡潔に説明するものが推奨されます。 — Google提供のデザイン・ガイドラインMaterial Design Guidelines

Tabberはシンプルかつ効果的でなければならず、互いの中でネスティング(入れ子)するようなデザインは避けましょう。特にインフォボックス内で画像用にtabberを使うコミュニティの場合は、記事全体に渡って画像を分散する、もしくはキャプションが付いた<gallery>の中に移し替えることが推奨されます。デスクトップ版では画像のラベル化および書式設定が可能なギャラリーが存在します。一方モバイルの場合、横方向にスクロールする帯域幅利用の効率化を図った画像の列が存在し、1つずつタップして隔離とズーム(およびキャプションの表示)ができます。上記のヒントを基に、ユーザーにとって分かりやすくするためにも、tabberで横並びにする項目は常に同等レベルであることを確認しましょう。

コンテンツ内でtabberを使用すると、コンテンツが整理されたタブが記事内に(ラベルやキャプションなしで)挿入されます。Tabberセットに入れるコンテンツは、tabberが外された場合でも分かりやすい内容でなければいけません。コンテンツをさらに整理させる必要がある場合、セクション/チャプターヘッダの下に置くことをおすすめします。記事が長くなること自体、決して悪いことではありません!😀まずは、tabberを使ってコンテンツを本当に非表示にすべきかどうか、その必要性をよく検討しましょう。

TabViewは、インタラクティブタブの中にある追加記事のコンテンツを埋め込むための拡張機能です。デスクトップ版では、これにより高密度な機能セクション間の切り替えが可能となり、モバイルでは利用可能なセクションへのリンク一覧として表示されます。これ自体はコンテンツすべてにアクセスできるため慣習として悪くはありませんが、検索エンジンはこの場合ユーザーを最初の記事ページではなく、リンク先のページに飛ばします。そのため、メインの記事にナビゲーションする方法が明確でなければいけません。TabView経由でコンテンツを埋め込んだ記事はすべて、メインの記事(例:[[キャラクター/シーズン1]])のサブページとして記事をリンクすることを推奨します。こうすれば、ページヘッダー上で明確なナビゲーション方法が常にユーザーに提供されます。

データを再考する

コミュニティの中には、コミュニティで扱っている記事にはデータやインフォボックスが無いと誤解し、文章のコンテンツのみに目を向ける場合が多く見られます。FANDOMでは要素の中にタイトル、および1つ以上の画像が存在し、記事のトピック説明に値が付随するプロパティがある場合は、その要素を「事実上の」インフォボックスとして(レイアウトに関係なく)認識します。その時点で、インフォボックスは記事において最も明確な基準点になります(そのため、ポータブル・インフォボックスがモバイルページ上でのプライマリ要素になります)。また、インフォボックスの各パート(<navigation>以外のタイトルや画像を含む)はデータ項目として認識されます。

データの分離性の保証こそ、質の高いページメンテナンスの真髄です。これを行う最も簡単な方法の1つが、たとえば「陸上車」と「航空機」など、インフォボックスを用途別に別々のテンプレートに分けることです。Wikiが複雑になればなるほど、さらに分ける必要が出てくる可能性もあります(たとえば同じ陸上車でも「四駆」と「軽トラ」に分けたり、同じ航空機でも「ヘリコプター」と「飛行機」に分けるなど)。

現実的には、個別のデータ値は種類・フォーマットともに単一でなければいけません。つまり、数字や文字、日付のフォーマットはできる限り1つに限定しましょう。オブジェクトの値が「金貨100枚」だとしたら、記事のインフォボックスに書き込まれる値も「100」にします。テンプレート自体に、値を再フォーマット化して必要な背景情報を追加することができます。

インフォボックスでは、値が含まれたリストもよく見られます。データを中心に考えた時、カンマ(もしくはセミコロン)区切りのリストよりも、ウィキテキストリストのほうが有効と言えます。現時点で横方向のリストを作る共通方法は一般的にはありませんが、FANDOMではいくつかの方法を推奨しています。また、アイテムがイコールの関係にある場合、複数のパラメータを持つよりもリストのほうが効果的です。

つまり:

| アイテム1 = リンゴ | アイテム2 = バナナ

上記ではなく、代わりに以下のような使用を優先しましょう。

| アイテム = 
* リンゴ
* バナナ

見た目的に即座のメリットはないかもしれませんが、このようにデータ項目を区切ることによる長期的な利点は、スクリプトやクローラーエンジンが検知しやすくなり、またスクリーンリーダーデバイス(視覚障害をお持ちのユーザーなどが使うデバイス)も正しく読み取ってくれます。リストを使うことにより、翻訳やその他言語的な理由による不確実性も回避できます(Oxfordが定義するコンマで見られる議論などを考えても)。また、CSSに精通するデザイナーがいれば、交互のリスト項目を視覚的に特別処理することもできます。

ポータブル・インフォボックスの魅力の1つはコードの単純さであり、サーバー側の性能にもメリットがあります。1度にすべて構成されるため、複数のサブテンプレートで構成されるウィキテキストインフォボックスよりも、サーバーへの負荷は少ないものになります。各テンプレートは、限定された目的1つを効率良く果たすためにデザインされています。サーバー上での優先的な処理状態やランクを踏まえ、インフォボックスを互いの中にネスティングすることは難しいです。ただし、各インフォボックスは1つのオブジェクトのみ説明すべきだと考える場合は、関連性のある(別個の)サブトピックを個別セクションに入れることを検討ましょう。

最後に、メイントピックの様々なレベルやプラットフォームを説明するために、記事内に複数のインフォボックスを入れることはおすすめしていません。ユーザーにとって、モバイル上での表示結果が非常に判断しにくいからです。コミュニティの中には、インフォボックスをtabberやドロップダウン内に置く場合があります。現時点で上記のネイティブサポートはありませんが、多くのコミュニティは、単一インフォボックス内に整理した論理的グループの中に統計値を置いています。たとえば「プレイステーション」の統計情報に対し、同類の属性を持つ「PC」の統計情報を折りたたみ可能な<group>に設定したほうが、別個のインフォボックスに置くよりも有効な手段と言えます。

画像を再考する

Spock-truncated-infobox

スポックの新旧の外見を2枚だけの画像で効率的に表示している点にご注目ください

デザイナーは時に、画像は多いほうが良いと考えることがあります。そのため、1つのギャラリーにできるだけ多くの画像を詰め込みます。ただしこれは読者にとって過剰な情報量でしかなく、画像の体系、関連性、あるいは重要なコンテンツへのナビゲーション方法を理解する方法を与えないことになります。

SEOは、画像を正しくラベル化することによって向上します。Wikiでできるだけ多くの人に来てもらうためにも、SEOは大事です。ただし、いくらラベルを正しく貼っても、情報量がそもそも過剰だと意味がありません。ギャラリーに画像が100個もあると、ラベルの意味がそもそもなくなってしまいます。最善の解決策はできるだけギャラリーサイズを小さくする、あるいはギャラリー自体なくすことです。画像を何枚か記事の本文内にインラインで挿入し、関連するテキストの近い場所に置きましょう。こうすることで、モバイルだと特に発生しがちな指の操作や、果てしなく感じるスクロールによるイライラを軽減することができます。また、テキストと見比べるものではなく、テキストを補完するイラストとして、本来の目的通りに画像を使うことができます。

インフォボックスはギャラリーではありません。理論的にもギャラリーの代わりにすることもできません。目的は一般的なデータが読者にとって読みやすくなり、魅力的でコンパクトなパッケージにすることです。言い換えれば、インフォボックスはあくまでもページのトピックを単に紹介するだけの目的を持っています。

だからこそ、インフォボックスはメインの記事トピックの画像を見せるのみにとどめ、同等のレベル感でなければいけません。たとえば、服装やアクセサリー一式ではなく、マンガとアニメ版と言ったように。

画像テキストの追加

  • 「画像の使用だけでは有効なSEO対策にはならない」画像は役には立ちますが、ページのテキストだけでも、ユーザーにとって十分価値のあるコンテンツです。画像だけが何ページも続いてしまうと、コンテンツとしての質が低下してしまう可能性があります。
  • 「イメージギャラリーを上質なページにする」画像は1つのトピックに絞って表示しましょう。できれば記事本文に関連するトピックが最善です(たとえば「ナルトとラーメン/画像」など、対になるようなギャラリーを作成し、それを「ナルトとラーメン」記事ページにリンクさせるなど)。
  • 「画像の名称は分かりやすい言葉を使う」検索エンジンは画像の違いを識別できないため、ファイル名をできるだけ分かりやすい説明書きにすることをおすすめしています。たとえばSEO対策を考えた場合、img012.jpgよりもspiderman_slinging_webs.jpgのほうが得策です。
  • 「ファイルページの概要説明には時間をかける」概要の説明は、検索エンジンに画像をより理解させるための有効な手段です。画像リンクの「広告コピー」として考えることができるため、広告コピーの質が高いほどクリック数やページへのユーザーアクセス数を増やすことができます。

レイアウトとデザインを再考する

ページは時に、モバイル上での見た目がまったく失敗してしまうケースがあります。このような場合、コードをよりレスポンシブに変えることで改善することができます。覚えていただきたいのが、デスクトップの体験はCSSとJavaScriptを使ってカスタマイズできる一方で、モバイルユーザーは固定かつ書式設定されていないコンテンツしか見えない点です。

テーブルはFANDOMで人気の手法です。テーブルは正しく使えば効率的にデータを収集・比較できますが、スマートフォンの場合は画面が小さいため、モバイル端末上の利用は限られてしまいます。

以下をヒントにしてみましょう:

  • テーブルはエクセルシートの一種ととらえる。
  • テーブルは必ず、実際のモバイル端末を縦方向に置いて確認する。
  • カラム数は4つ、あるいは約600pxに限定する(それ以上になると、ユーザーは指を使って左右にスクロールしなければならず、大きなテーブルの場合だと位置が分かりづらくなります)。
  • colspanもしくはrowspanは使用しない。
  • テーブルは互いの中にネスティング(入れ子)しない
  • テーブルのキャプションが同テーブルの「タイトル」になります。安全に使用できます。
  • キャプションがカラムもしくは列に該当する場合、scope="col"またはscope="row"を使用する。
  • テーブルは、カスタムクラスの代わりにインラインCSSの使用を推奨する数少ない要素です。ただし、編集者にとってより簡単に使える一定のビジュアルをご希望の場合は、既存の公式テーブルクラスの書式を再設定したほうが有効な手段です: "article-table"、 "WikiaTable"、および"wikitable"(Wikia.css)。
  • 次のCSSクラスも許可されています: "mw-collapsed"、"mw-collapsible"、"noprint"、"nowraplinks", "plainlinks"、"sortable"。
  • 必要でない限り、テーブル内に画像は含めないようにしましょう。特に小さな画面の場合、ユーザーにとって画像よりテキストのほうが分かりやすいです。ゲームWikiでテーブルを作成される場合、および、そのテーブルにゲーム内で使うアイコンを含める場合、アイコンを小さくし、すべて同じサイズにしましょう。22から25pxの幅が最善です。そうすることにより、画像はモバイル端末上で拡大されません。
  • テンプレートを使って新しい列を作らないようにしましょう。コンテンツを追加する際にサーバーが何度か実行を試さなければならない場合、表示画面に対してテーブルを正しくサイズ設定することができません。
  • これら手順を正しく実行すると、モバイル端末でのテーブルは「ゼブラ柄」で表示され、各列の色が交互に変わることで見やすくなります。

FANDOMの一部のWikiでは、レイアウトとデザイン目的でテーブルを使用してきた経緯があります。この手段は避けましょう。テーブルはあくまでも、データのためにあるものです。 これは2004年当時から事実として言われてきていることです。

600px以上の固定画面レイアウトを持つ要素は、その要素が「ポータブル」な性質を持つ・持たないを問わず、モバイル画面で必ず問題が起きてしまいます。CSSを使ってフル画面幅に拡大されたポータブル・インフォボックスの場合でも、読みにくい列を数ピクセルほど幅広に厳密に定めてしまう可能性があるため、モバイル端末では意図通りに行かないことがあります。Mercuryにおいて全幅のインフォボックスをうまく設定することは非常に難しく、時間がかかる上に、多くの場合は不可能です。ご自身のWikiにおいて、ボックス幅をフルにする必要性をよくご検討されることをおすすめします。 実際FANDOMでは、インフォボックスのデフォルトサイズを変更しないことを推奨しています。変更によって画像の拡大・縮小の問題が起きてしまう可能性があるからです。現在のポータブル・インフォボックスのデフォルトサイズ(270pxおよび300px)は、FANDOMネットワークで分析したサンプル間で最も共通して使われる平均サイズです。

FANDOMでは、<infobox>以外にもポータブル要素は存在し、それらはすべて、様々な画面上で解釈できるようデザインされています。その中でも最も汎用的な要素は<gallery>タグです。イメージギャラリーはナビゲーションポータル用や、ダイナミックかつポータブルな環境で画像を表示することができます。このタグはまた帯域幅効率の維持に優れており、モバイル端末の通信プランにも優しいです。<references>タグは脚注のためにも使うことができるため、長くなりがちなツールチップの代替として最適です。これらタグは常に、ウィキテキストやJavaScriptでのタグよりも使い勝手としては良く、安全です。

レガシーテンプレートの多くはインライン書式設定を使い、記事の中で使う要素の色を決定しています。FANDOMではさらに先進的なアプローチを採用し、記事への荒らし行為やミスタイプされた16進数コードなど、様々な危険性から記事を守っています。CSSクラスの一種である、一定のテーマを使うことにより、多くの場合は適切な形で要素のスタイルを設定することができます。アドミンレベルの権限で設定するためスタイルは限定されますが、セキュリティの確保と一貫性、およびコミュニティ全域に渡る変更のしやすさは、大きなメリットとなります。

正しく使えば、色はとても強力なツールになります。ただし、思い付きやランダムに使用すべきではなく、よく検討した上で使いましょう。単に使いたいから明るいピンクにするのではなく、使う色がサイト上でその他の色を自然に補完する場合のみに限定します。「カラーコード」、つまり色による意味をそれぞれの要素に与えようとするのは、たとえば色覚異常を持つユーザーにとって理解できなくなる可能性があります。代わりに、背景色とテキスト文字色の高コントラクト比、およびシンプルなカラーパレットこそ、すべての人がWikiを読みやすくするために必要です。同様にぺージの不透過度もできる限り高く、通常は90%以上に設定してユーザーの利用性を保証しましょう。ごちゃごちゃした背景が見えてしまう透明なページだと、どんな色でもテキスト文字が非常に読みにくくなってしまいます。

最後に、Wikiのトピックに関連する色にも特に注目し、取り入れてみましょう。たとえば『SUPERGIRL/スーパーガール』のWikiの場合、赤や黄や青をデザインに採用する選択肢がおのずと出てきます。あるいは『ウォーキング・デッド』のWikiの場合、深緑や茶系の色の使用が自然な選択となります。トピックの公式ロゴ、メインのタイトルデザインやその他の特徴的な要素から使うべき色を検討しましょう。正しい色使いには、読みやすく魅力的なサイトにするためにも、一貫性のあるカラーパレットがカギとなります。

双方向性を再考する

JavaScriptは様々な理由から、モバイル端末で利用することができません。コンテンツと呼ばれるもの(実際の文章、その他テキスト、画像、動画など)は通常、記事の中に挿入されます。

双方向性を考えたとき、ユーティリティは当然ながら役に立つ一方で、通常はブラウザを通じてよりも、アプリの範囲内で使用したほうが有益です。

コミュニティの中には、Javascriptが記事内に双方向的なインタラクティブ要素(グラフなど)とコンテンツを組み合わせる例が存在します。このような手法が取られる場合、問題が起きた時に無理なく代替策に切り替えられる方法が必要です。理想を言えば、情報はすべてのプラットフォームで問題なく表示されるべきですが、要素が大幅にJavaScriptで作成されている場合、必ずしもうまくいかないことがあります。ナビゲーション分類のテンプレート内にアンカーコードを区分化することを優先し、モバイルプラットフォーム上で要素を回避あるいは明示的に表示するために、CSSクラスを使用することは推奨されません(Mercury上では非表示になるが、デスクトップ上では悪影響を及ぼさない)。

ページ上の内容をJavaScriptがすべて生成している状況において、ある意味それはコンテンツではなく、そのサイトのある機能を表していると理解することができます。コミュニティ全体で使うJavaScriptコードはMediaWiki名前空間に含める必要があります。コードからの出力は、統計電卓など固定のコンテンツを一切含まない、完全に双方向性なコンテンツの場合、メインの記事の名前空間ではなく、Special:Project:など、非コンテンツ用名前空間に含めましょう。

最後に必ず、編集内容のプレビューとご自身のモバイル端末の両方で、Mercuryにてページの確認を行うことをおすすめします。JavaScriptが原因で重要なデータが消えてしまっている場合(あるいは最悪、モバイル上で記事全体が空白の場合)、潜在的なユーザー層の半分を失ってしまう可能性があります。 根本原因がわからない場合、ポータビリティ・ハブまでご遠慮なくお知らせください。ボランティアの方々が必ず、最適な解決策まで導いてくれます。

長期的に続けられるデザインこそ、良質なデザインである

永続的なデザインを保つためには、多少なりとも先を見越した計画が必要となります。コミュニティは数年先まで、大きな変更を毎回行うことなく円滑に運用できなければいけません 。すべてのプラットフォームで効果的に機能するデザインを賢く選択することが、デバイス問わず、またサイトにたどり着いた方法を問わず、ユーザーを魅了し続けるカギとなります。本ブログで説明したガイドラインを一部でも導入していただき、皆さまのコミュニティの長期的な健全性に貢献できることを願っております。

本ブログは英語版Portability HubProgressive Designを翻訳したものです
特に記載のない限り、コミュニティのコンテンツはCC-BY-SA ライセンスの下で利用可能です。