Windows Storeアプリはタッチデバイス、モバイルデバイスでの使用を意識する必要があります。そのようなWindows Storeアプリの特性を考慮したコンテンツ提供を行うためには、これまでのアプリケーションに比べ、情報設計がアプリケーションの操作性に大きく影響することを意識する必要があります。この記事では、情報設計の具体的な手順を解説しています。

日本語資料

Article in English

Windows Storeアプリの特徴

タッチデバイス

深い階層構造を持つアプリケーションであってはいけない

細かい画面分割による大量の情報提供をすべきでない

モバイルデバイス

ローミングデータはオブジェクトモデルとして整備されていると扱いやすい

コンテンツが提供する情報は、適切に整理されている必要がある。

インフォメーションアーキテクチャ

■理解の巨匠

リチャード・ソール・ワーマン(1935.3.26~)が提唱した情報の分類に関する概念が基になっており、コンテンツ提供時の情報の設計手法の一つ。

・情報の分類は5つ(Information anxiety 1)

時系列、アルファベット、カテゴリー、位置、階層によって多くの情報は分類できる。(LATCH)

・近年の情報アーキテクチャ(Information anxiety 2)

時系列、アルファベット、カテゴリー、位置、連続量により情報を分類する。

・階層化やタグ付けが情報アーキテクチャに含まれないわけ

階層化はタグ付けで代替えでき、階層化とタグ付けは、情報を扱うユーザーによって変化する。また、情報が利用される場所においてもその構成が変化するため、一時的な分類や一意的な分類に有用。

例:会議の議事録をファイルサーバーに保存(下図の左の階層化)→下図の右のタグ付けで表現可。

情報のタグ付けによる表現は、階層による情報の表現を代替えできるが、その逆はできない。

誰もがファイルの場所をわかるようにするために

■コンテンツ・スコープが変わらない階層化

情報アーキテクチャの情報分類に則った分類のひとつで構成される階層構造では、誰もが簡単に情報に到達できる(下図)。これをコンテンツ・スコープといい、これが混在する階層構造(上図左)では、下の階層に行ってから初めて次の操作がわかる(2013年4月27日の議事録にたどり着くためには、NECフォルダを開かないとWindows Phone app開発案件というフォルダがあることがわからない)。

■コンテンツ・スコープが変わらないところまでメニュー等でナビゲートする

情報を見せるときには、それぞれに最も重要な分類がある(ニュース速報の場合は時系列等)ため、他の分類についてはメニュー等で補助する。ニュース速報の場合は補助として「国内/海外」(位置)や「政治/犯罪」(カテゴリー)などが考えられる。しかしながら、過去ニュース・アーカイブのような場合は、時系列を補助とし、カテゴリーや位置を重要な分類とする見せ方が考えられる。

情報を提供する目的によって分類の優先度が変わる

オブジェクトモデルのアンチ・パターン

コンテンツ・スコープに一貫性のある(情報アーキテクチャの分類を横断しない)情報群は、オブジェクト・モデルで情報特性としてアプリケーションに提供することが可能。MVVM、MVCにおけるモデルとして、オブジェクトとオブジェクトモデルの転送による業務ロジックの実装に分離できる。

■階層化やタグ付けをオブジェクトモデルで提供することのデメリット

オブジェクトモデルは、正規化モデル(DBなどに永続化される情報の形)からビジネス・ロジックを実現するために転送するデータの組み合わせの形であり、コンテンツ・スコープの一貫性がないモデルは、開発者がモデルをすべて理解する必要があるため開発効率が悪い。そのため、情報を扱うユーザーが自由に決められる階層化やタグ付けといった分類に関しては、オブジェクトモデルとして、情報特性をアプリケーションから固定的に提供すべきでない。

■オブジェクトモデルは変化できない

アプリケーションで提供するオブジェクトモデルを変更するためにはアプリケーションの改変が必要になり、UXを提供するWindows Store Appの場合、ユーザーの操作の変化やアプリケーションの進化にオブジェクトモデルは追従できない。そのため上記の開発視点としての非効率性に加え、エンドユーザーの情報操作の自由度のためにも階層化、タグ付けに関してオブジェクト・モデルで提供することはない。

ユーザーが情報を操作する際の自由度を提供するのはオブジェクト・モデルではなく、アプリケーション・ロジック

オブジェクトモデルのパターン

■一意的な分類と一時的な分類

階層化やタグ付けはオブジェクトモデルでなく機能として提供すべきで、それによってユーザーの操作の変化やアプリケーションの進化に対応することが可能になる。

例:楽曲情報の分類における一時的な分類と企業内の部署管理における一意的な分類

■特定の業務に対するオブジェクトの提供

企業で部署を分類する場合は、情報の形の変化(部署の改変など)が少なく、異動や入退社が頻繁でなければ固定的な階層をオブジェクト・モデルとして提供することが可能(会社の組織構成はその会社の社員であれば知っておくべき情報であり、社外の人がその情報を操作する必要がない社内システムなどでは一意的なオブジェクト・モデルとして実装可能)。また、毎週注目曲を発信するような特定の目的にしか使わないアプリケーションの場合、一時的な情報の形をオブジェクト・モデルとして実装することが可能。

これら特定の条件下以外では、一時的な分類や一意的な分類はオブジェクトモデルとして実装を行うのではなく、アプリケーション機能として、ユーザーが自由に設定できるようにしておく。

限られた状況下でのみ、一時的または一意的なオブジェクト・モデルを提供できる

設計時の注意事項

■情報アーキテクチャの分類のプロパティを用意する

情報アーキテクチャの分類にアプリケーションの業務ロジックを最低1つ当てはめる。

情報アーキテクチャの分類である位置モデルを継承してアーティストのメンバーの出生地情報をオブジェクト化した例

Tags:

No responses yet

Leave a Reply

Your email address will not be published. Required fields are marked *

位置 Store(置き場所)、アーティスト出身地、活動中心地
アルファベット アルファベット、五十音、多言語対応
時系列 発表日、発売日、データ更新時
カテゴリー 音楽ジャンル、言語
連続量 発表曲数、売上枚数、放送回数