Windows 8.1からタイルの種類も増え、アプリケーションの独自性や機能などを表現しやすくなったので、ユーザー環境のスクリーンサイズやタイルサイズを考慮したデザインの自由度が向上しました。しかしながら、タイルやバッジの設置は、アプリケーション作成時に1度しか作業しない為おろそかになりがちな作業です。バッジとタイルのこれらの設定は、工数やフローの複雑さに大きく関係するため、開発者はMicrosoft Azure Notification Hubsを含めた設計に関わる必要があります。
・通知内容と通知先
アプリケーションの目的や機能と通知内容、通知先、ライフサイクルの関係
バッジを含むタイルのUIデザインを設計する際は、通知のライフサイクルを考慮することが重要です。さまざまな検討要素が依存関係を持つからです。
検討要素はいくつかありますが、「ロゴとアプリケーション名のタイルへの配置」「ライブ・タイル、セカンダリ・タイル、サイズ」「バッジの必要性」「 通知内容と通知先、ライフサイクル」「アプリケーションの目的と機能」は依存関係にあることに注意してください。
そのため、まず「アプリケーションの目的と機能」が明確化されている必要があります。業務アプリケーションであっても要求仕様が明確化されていないケースが多々あり、要件定義が機能の羅列になっているケースすらあります。
要求仕様は、要求仕様書のような大げさなものである必要はありません。まずは「バッジが必要かどうか」を検討できる範囲の要求仕様が明確化されていればいいわけです。要求が明確化されていてれば、続いて「セカンダリ・タイルが必要かどうか」を検討できますし、「ライブ・タイルを使うべきかどうか」「どのタイル・サイズが適切か」が明確化されていきます。
そうすることで「バッジ・タイルの設計、ロゴの配置」ができるようになるので、検討の順番が重要だということを理解してください。
通知の必要性:そのアプリケーションには個別通知や全体通知が必要ですか?
アプリケーションに認証機能がある&パーソナライズが目的である | → | 個別通知が必要 |
アプリケーションの機能拡張やデータの追加・更新など | → | 全体通知が必要 |
特定地域や特定のグループ(ある範囲のデータを利用など) | → | グループ通知が必要 |
バッジの必要性:そのアプリケーションでは情報の数が重要ですか?
コンテンツ数、情報数に意味を持つアプリケーションの場合 | → | 要約通知※を使う |
コンテンツ数、情報数よりもその有無や多さに意味がある場合 | → | システム・グリフを使う |
数値から複数の意味を想像でき、通知の意味を失う場合 | → | システム・グリフを使う |
※ひとつのバッジイメージとひとつの数値の組合せ
タイルの機能の検討:そのアプリケーションでは情報が多様であることが重要ですか?
異なるコンテンツ・スコープのコンテンツ提供・更新をウリにしている | → | セカンダリ・タイルを使う |
機能提供のアプリではなく、コンテンツ提供を目的としている | → | ライブ・タイルを使える |
複数の情報や詳細情報の通知がユーザーにとって有益である | → | ワイド/大・タイルを使う |
最後にライフサイクルを検討することになります。
配信方法の検討:そのアプリケーションでは情報がどのように更新されますか?
即時性が重要な通知がある | → | プッシュ/スケジュール |
ユーザーがアプリから離れる可能性がある | → | ローカル |
時間が通知の重要なファクターである | → | スケジュール |
固定的な定期的通知がユーザーに有用である | → | 定期的ポーリング |
ユーザーは情報の更新を予測できない | → | プッシュ |
併せてmsdnも参照してください(通知配信方法の選択 (Windows ランタイム アプリ))。
このように「アプリケーションの目的と機能」、「通知内容と通知先、ライフサイクル」、「ライブ・タイル、セカンダリ・タイル、サイズ」「バッジの必要性」が検討できたら、実際に「ロゴとアプリケーション名のタイルへの配置」を行っていきます。
No responses yet