Windows アプリ
目次を折りたたむ
目次を展開する

生産性アプリ

Windows 8.1 は生産性アプリにとってすばらしいプラットフォームです。 既にある生産性アプリが正常に動作する 従来のデスクトップ環境に加えて、Windows ストア アプリの新しい環境を使うと、新しい現代的な生産性アプリを作成できます。 ここでは、生産性アプリで Microsoft デザイン スタイルと Windows 8.1 の機能を 活用した場合に、生産性アプリを改善できるさまざまな方法を紹介します。

概要

Windows 8.1 には、タッチとペンが中心のタブレットから高解像度のノート PC やデスクトップ PC まで、これまでにない範囲の多様なデバイスが用意されています。つまり、生産性アプリでは、ユーザーがさまざまなシナリオや使用事例で生産性を上げることができるように異なる入力が使われます。

また、Windows ストアは、アプリを配布、宣伝、販売する機会を提供します。最小限のコーディングでアプリ内購入や試用版などのシナリオがサポートされるため、すぐに収益を得始めます。  

ここでは、生産性アプリにとって特に重要な Windows 8.1 の機能に注目します。  

  • Windows ストア アプリ: アプリの新しいデザイン言語です。全画面のコンテンツの作成とイマーシブな生産性シナリオに重点を置いています。Windows は邪魔になることなく、コンテンツに非常に強い影響力を持たせることができます。
  • ライブ タイル: ユーザーが使っていた最新のコンテンツを表示するライブ タイルを作ることで、ユーザーがアプリに戻ってくるように関心を最大限に引きます。また、セカンダリ タイルを使うと、簡単にコンテンツに深くリンクでき、ユーザーはアプリ内でよく使うコンテンツをピン留めすることができます。
  • 共有コントラクト: Windows 8.1 ではアプリ間の共有と共同作業が簡単になります。そのため、ユーザーが生産性を維持するために行う必要があることをすべて実行できるように、アプリを他のアプリと連携させることができます。
  • 検索コントラクト: 新しいトップレベルの OS 機能です。ユーザーは以前よりも簡単にコンテンツを検索、整理できます。コンテンツの検索時にユーザーの意識を高めるために、アプリが検索結果に含まれます。
  • 検索ボックス: ユーザーはアプリ内のコンテンツを検索し、カスタム結果ビューを表示できます。
  • ファイル ピッカー: ファイル ピッカーを使うと、生産性アプリのユーザーは、ファイル システムから、またはファイル ピッカー コントラクトに参加している他のアプリやサービスから、ファイル、ドキュメント、写真を簡単に使うことができます。
  • セマンティック ズーム: この Windows 8.1 のネイティブの機能を使うと、ユーザーはアプリの詳細のピンチ操作と縮小表示を行って、コンテンツや操作対象の概観を理解することができます。スタート画面でセマンティック ズームを使って、実際の動作を確認してみてください。
  • サイズ変更できるウィンドウ: ユーザーはアプリのサイズを変更することで、複数のアプリを左右に並べて同時に実行できます。また、ユーザーはマルチタスクを実行して常にアプリでの生産性を維持できます。

全画面

Windows ストア アプリの生産性についての利点のうち最も明白なのは、他のアプリケーションや Windows の UI と領域が競合しないことです。 アプリは、画面上に表示されるすべてのピクセルを 使ってコンテンツを表すことができます。 不要または煩わしいと感じる UI はすべて非表示にし、 シンプルなジェスチャで表示できます。つまり、アプリには、現在のタスクについて最も重要な情報を表示するため の十分な領域が常にあるということです。 また、"クロムよりもコンテンツを優先させる" という 設計哲学が生産性アプリにも適用されます。この哲学は、雑誌アプリまたは動画アプリにおいて、とても新鮮味があり楽しめるものです。 邪魔なものが取り除かれると、アプリで表示されるコンテンツの操作に集中しやすくなります。

生産性アプリを設計するときに、まずはユーザーのコア タスクを識別します。 次に、画面のすべての ピクセルを使って、アプリでそのタスクを実際に実行できるようにします。 より多くの領域を確保して、そのタスクをより簡単で、高速で、楽しめるものにする方法 を考えてみましょう。 データの静的な 表現ではなく、興味を引き、アクション可能な情報の視覚エフェクトについて考えてみましょう。 アプリで領域と配置を使って意図を伝える方法を考えてみましょう。 現在使っている規則とコントロールの多くは、デスクトップ コンピューターのディスプレイの解像度が 現在のスマート フォンの解像度よりも低かったときに開発されたものです。 Windows ストア アプリでは、ユーザー が情報を交換、分析、操作して作業を完了する方法を再定義する機会が提供されます。

生産性アプリでは、興味深いことに、コンテンツの作成シナリオとコンテンツの使用シナリオが混ざり合っているのが 一般的です。たとえば、生産性アプリは、ドキュメントの作成と読み取りの両方に使ったり、To Do リストの作成と管理の両方に使ったりすることができます。 また、生産性アプリは、単純かつ軽量の To Do アプリから、無数のオプ ションをホストする階層化されたメニューが備わった、機能豊富で複雑なコンテンツ作成アプリに至るまで、ナビゲーションを処理する 方法、やコマンドとエクスペリエンスの公開において、複雑さが大きく異なります。魅力的な Windows 8.1 生産性アプリでは、このようなエクスペリエンス間のナビゲーションが軽快かつ柔軟、そして 魅力的な方法で実現できます。

生産性アプリのレイアウトとナビゲーション

選んだナビゲーション パターンは、 アプリがサポートしているシナリオの種類によって示されます。アプリに充実したエクスペリエ ンスが複数備わっている場合 (複数のドキュメントを表示するなど)、エクスペリエンス間の組織や構造では、階層パターンは、 すべてのコンテンツをメニューやタブの背後に隠すのではなく、トップレベルに 配置するのに役立ちます。ただし、アプリに階層と構造が必要な 多数の情報密度とシナリオがない場合は、フラット パターンを検討してください。この パターンを使うと、ユーザーはアプリ内のエクスペリエンス間をすばやく移動できます。"マスター/詳細" ビューのアプリ (メール アプリやメッセージング アプリ など) では、コンテンツを最適に表示するリスト ビューを使うことがあります。一部の 生産性アプリでは、特定のシナリオでさまざまな種類のデータ入力 (フォームなど) が 必要になる場合があり、それらのデータ入力にはこの記事の後半に記載されているフォーム レイアウトを利用できます。ユーザーが 目的のコンテンツをすばやく確実に見つけられるようにパターンを選んでください。

アプリのナビゲーション パターンについて詳しくは、「ナビゲーション パターン」をご覧ください。

フラット ナビゲーション パターンの実際の使い方については、「アプリの機能の概要」シリーズをご覧ください。

階層パターン

階層構造と大きなデータ セットが含まれている生産性アプリ (多数のメモ帳とノートを含む メモ アプリなど) では、トップ レベルにユーザーのすべてのコンテンツを 表示する階層パターンを使うことができます。 このモデルでは、ユーザーの目の前にすべてのコンテンツを配置することによってユーザーを喜ばせます。

アプリのハブ ページ

ハブ ページはさまざまなセクションで構成され、それぞれがアプリの個別のセクションにマップ されます。各セクションでコンテンツや機能を公開できます。ハブで多様なビジュアル を提供し、ユーザーの関心を集め、アプリのさまざまな部分に引き込みます。 たとえば、以下のメモ アプリでは、各メモ帳の最新のメモのいくつかをトップレベルに表示して います。 次の画像は、ハブ ページの例を示しています。

ハブ ページの例

各メモをタップすると、ユーザーはそのメモに直接移動します。ヘッダー ("Travel - NYC" など) をタップすると、ホーム ページに表示されているもの以外にメモ帳に関連付けられているコンテンツ がある場合は、そのメモ帳のセクション ページが表示されます。

ユーザーにコンテンツの並べ替え方法を選ばせることを考えてみましょう。たとえば、アルファベット順、 日付順、コンテンツの種類別、コンテンツが共有されているかどうか別に並べ替える ことができます。適切な並べ替えの方法は、アプリで表示されているコンテンツやユーザーの通常の使用パターンに よって異なります。 次の画像は、メモの並べ替えの例を示しています。

メモを並べ替えたアプリの例

上部のアプリ バー

上部のアプリ バーを使うと、ユーザーがアプリのセクション間をすばやくジャンプできるようにすることができます。たとえば、あるメモ帳に含まれているメモを読んでいるユーザーが 上部のアプリ バーを使って別のメモ帳に含まれているメモに すばやく簡単に移動できます。 次の画像は、ユーザーが上端または下端をスワイプしたときにメモ アプリに表示される上部のアプリ バーを示しています。

ドロップダウン ヘッダー付きのメモ帳アプリ¾

セマンティック ズーム

セマンティック ズームを使うと、コンテンツの拡大や縮小のビューを視覚的に示すことで、ユーザーが 1 つのビュー内ですばやく移動できます。たとえば、メモ アプリでは、ユーザーはすばやくピンチとパンを行って、メモ帳間を移動できます。 また、ユーザーがメモを日付順に表示する ことを選んだ場合、ユーザーは最新のメモから最も古いメモにすばやく移動 できます。

次の画像は、縮小したときのコンテンツのグループ化を示しています。

セマンティック ズームでタイトル別にグループ化したコンテンツ。

特定のセクション ページでセマンティック ズームを使って、そのセクション またはカテゴリ内のコンテンツ間を移動することもできます。たとえば、メモ アプリでは、ユーザーが セマンティック ズームを使って同じメモ帳内の異なるメモ間をすばやく ジャンプできます。

セマンティック ズームについて詳しくは、「セマンティック ズームのガイドライン」をご覧ください。

フラット レイアウト パターン

アプリのコンテンツのほとんどが、多くの階層を使わずに同じレベルにある場合、 フラット ナビゲーションを使うことを検討してください。 このパターンを使うと、 ユーザーはすべて同じ階層レベルにあるドキュメント、ページ、タブ、またはモード間を軽快 かつ柔軟に移動できます。フラット パターンについて詳しくは、 「Windows ストア アプリ のナビゲーション デザイン」をご覧ください。

また、アプリにマルチドキュメント インターフェイスを活用するシナリオがある場合は、 フラット パターンを使うことをお勧めします。上部のアプリ バーは、 複数のコンテンツを切り替えるのに便利です。たとえば、スプレッドシート作成アプリでは、フラット パターンによって、ユーザーが作業中の複数の スプレッドシート間をすばやく切り替えることができます。

アプリによっては、上部のアプリ バーの右側に新しいスプレッドシートを作るための プラス ("+") ボタンを追加するなど、上部のアプリ バーにその他の機能を追加することができます。この例を、次のブラウザー (Windows ストア アプリ) に示しています。

ナビゲーション機能が追加されたブラウザー。

リスト レイアウト パターン

生産性アプリに、"マスター/詳細" ビュー (選んだ項目によって詳細ウィン ドウの表示内容が決まる) の概念を含むシナリオがある場合は、マスター ウィンドウにリスト レイアウトを使うことを検討します。 たとえば、プロジェクト管理アプリでは、マスター ウィンドウにマイルストーンと 納期を表示し、そこで項目を選んだときに、詳細セクションに関連する詳細を表示できます。メール アプリでは、次に示すように、画面の左側に受信トレイを、右側に閲覧ウィンドウを配置できます。

リスト レイアウトのメール アプリ

フォーム レイアウト パターン

生産性アプリのシナリオでは、ユーザーが情報を入力する必要 のあるフォーム レイアウトが必要になることがよくあります。 たとえば、カレンダー アプリで会議の招集を作る場合、ユーザーは場所、開始時刻、終了時刻、日付、 出席者などの情報を入力する必要があります。このようなレイアウトでは、一般的に、 複数の異なる種類のコントロールを組み合わせて使い、列単位のデザインで最適に動作します。

使うフォーム レイアウトを決めるときは、ユーザーに実行させたいタスク のフローと、そのフロー内でスクロールが必要な場所を考慮に入れ てください。 タッチ キーボードが表示されている場合、横方向の 利用可能な画面スペースの約 50% をこのキーボードが占めるため、スクロールが大幅に 増えます。 インライン エラー通知が表示された場合も、コンテンツが長くなり、 スクロールの必要が増します。

すべてのコントロールを 1 つの非常に長いフォームに収めようとするのではなく、タスクを一連の複数のフォームに分けることを検討してください。

1 列のレイアウトは、長さを問わず、縦方向のスクロール フォームに 対応しています。次の 1 列のレイアウトの例では、読む方向とタブ オーダーは上から下へ、次に左から右へとなっています。

フォーム レイアウトの例

2 列のフォーム レイアウトでは、表示できる横長のスペースを 横方向に最大限に活用します。ユーザーがスクロールする必要性を 最小限に押さえるには、読む方向とタブ オーダーが左から右へ、次に上から下へ進むようにしてください。

次の図は、2 列のレイアウトを示しています。

2 列のレイアウトでのコンテンツの適切なレイアウト

スクロールする 2 列の長いレイアウトの場合は、読む方向とタブ オーダーを 上から下へ、次に左から右へとしないでください。 これは非常に面倒です。ユーザーは、フォーム全体に 入力するために、最初の列の下までスクロールし、2 番目の列の先頭までスクロールして から、もう一度下へスクロールする必要があります。 また、2 列のレイアウトは、 列が狭くなりすぎるため、縦長ではあまり効果がありません。

次の例は、スクロールする長い 2 列のレイアウトでは避けた方が良い構成を示しています。

2 列のレイアウトでのコンテンツの誤ったレイアウト

生産性アプリのコンテンツのナビゲーション

生産性アプリには、ユーザーがアプリ内のさまざまな種類のコンテンツ 間を切り替えるマルチタスクが含まれていることがよくあります。たとえば、 ユーザーは、課題に取り組んでいるときに論文や以前の宿題などの複数の ドキュメントを切り替える場合があります。ユーザーが 軽快かつ柔軟にこのコンテンツすべてにすばやく アクセスできるようにすると、アプリ内の生産性が最大になります。最近使った ドキュメント、現在開いているドキュメント、 ユーザーの現在のワーキング セットに関連する アプリ内の任意の種類のコンテンツに対しては、 「Windows ストア アプリのナビゲーション デザイン」 に記載されている上部のアプリ バーを使うことを検討してください。 また、ユーザーがアプリのさまざまな部分にわたるマルチタスクを実行できるように、複数のウィンドウをサポートすることを検討してください。詳しくは、「複数のウィンドウのガイドライン」をご覧ください。

コマンド実行

生産性アプリには、他の種類のアプリよりも多くのコマンドがある傾向があり ます。これにより、見つけやすいうえにユーザーのコンテンツを最初に配置する形でコマンドを うまく表示する方法について、興味深い質問が浮上します。 ユーザーはアプリのキャンバスを使うだけで、アプリの主なシナリオ (アプリの "1 番の特徴" の説明文を容易にする シナリオ) を完了できる必要があります。 できる限り、コンテンツを操作するコマンドを用意せず、キャンバス上でユーザーが直接コンテンツを操作できるようにします。たとえば、 ユーザーはドキュメントを閲覧するときに、キャンバス上で直接ピンチとストレッチを行って表示フォント サイズを大きくしたり 小さくしたりできます。そのためのコントロールを配置するのではありません。コマンド実行について詳しくは、 「コマンド パターン」をご覧ください。

一部のコマンドとボタンはアプリに不可欠なので、画面上に表示されない状況があることは考えられません。 たとえば、一時停止されている動画アプリの [Play] (再生) ボタンが非表示になることはありません。 しかし、多くのコマンドは常時画面に表示する必要はありません。 ユーザーがコンテンツを使って生産性を高めることに集中できるように、多くの煩わしいコマンドは画面から削除し、よくある単純なジェスチャを使って必要なときだけ再び表示することができます。

下部のアプリ バーは、アプリケーションの下端に表示できる一般的なツール バーです。 アプリ バー は通常邪魔にならないよう非表示になっていますが、指で上端または下端からスワイプするか、マウスを右ク リックするか、キーボードの Windows ロゴ キーを押しながら Z キーを押して表示できます。 また、アプリのコンテンツ 内で選択が行われるたびに自動的に表示されます。 下部のアプリ バーに表示される ツールはコンテキストに依存するため、関連するコマンドだけが常に表示されます。 たとえば、単語を選ぶと、 下部のアプリ バーには、テキストの書式設定コマンドが自動的に表示されます。 また、 画像を選ぶと、下部のアプリ バーには画像編集コマンドが表示されます。 コンテキストに依存するという アプリ バーの特性により、無関係のコマンドに注目することがなくなります。 つまり、必要なツールは 常に身近にありますが、必要になるまで邪魔にならないようになっています。

アプリ バーを手動で呼び出すと、上部のアプリ バーも表示されます。 ユーザーはアプリケーション内のさまざまな場所にジャンプできるようになります。 たとえば、ブラウザーでは、 このバーを使って、現在開いているタブのサムネイルを表示できます。 ワード プロセッシング アプリでは、 このバーを使って、開いているさまざまなドキュメント間をジャンプできます。 ショッピング アプリでは、この領域を使って、ストアの さまざまな売り場間をジャンプできます。

上部と下部のアプリ バーでは共に、ボタンとメニューをホストできます。 同時にすべてが状況的に関連している コマンドが多数ある場合、バーから開くことができる 1 つのメニューにそれらのコマンドを配置するのが適しています。

下部のアプリ バー

非常に多くの コマンドでユーザーが困惑しないように、一貫性があるように系統立ててコマンドを 整理して表示することが重要です。たとえば、メモ アプリでは、ユーザーが 新しいメモやメモ帳を作ったり、メモ帳をアルファベット順や日付順に並べ替えたり、 メモのテキストの書式設定オプションを変更したり、オーディオ ノートを挿入したり、 場所を指定したり、タグや画像を追加したりすることができます。アプリ バーを使うと、すべてのアプリ コマンドをユーザーが 予測できる一貫したサーフェイスに配置できるため、ユーザーは 1 つの場所ですべてのコマンド を見つけることができます。

アプリでは、すべてのアプリ コマンドのインベントリを完成させたら、使用シナリオを 検討します。アプリ バーに表示されるコマンドを減らす 1 つの方法として、 コマンドを 2 つのカテゴリ (アプリにグローバルなコマンドと、選択時のみに 役に立つコマンド) に分類することです。選択時のみに役立つコマンド では、状況依存のコマンドを常にアプリ バーに表示しないようにしてください。状況依存の コマンドは、ユーザーがなんらかの項目を選んだとき、またはそれらのコマンドが関連 するアプリのコンテキストでのみ表示されます。

アプリ内で場所を問わず表示されるグローバルなコマンド ("同期" や "新規作成" 操作など) は アプリ バーの右側に配置します。特に、[New] (新規作成) コマンド (新しいメモやメモ帳などの新しいコンテンツを作るコマンド) はバーの右端に配置します。こうすることで、すべての [New] (新規作成) コマンド が特定のアプリやコンテキストとは関係なく一定の場所に配置され、親指を使った タッチ入力でのアクセスが簡単になります。

メール アプリのように、特定のアプリケーションの外部で永続する個々のエンティティをアプリが管理する場合は、[Delete] (削除) コマンドと [New] (新規作成) コマンドを使います。[Delete] (削除)[New] (新規作成) は、常に次に示す順序で表示します。

[Delete] (削除) ボタン (左側) と [New] (新規作成) ボタン (右側)

アプリが To Do リストなどのリストを管理する場合は、[Remove] (削除) コマンドと [Add] (追加) コマンドを使います。 [Remove] (削除)[Add] (追加) は、常に次に示す順序で表示します。

[Remove] (削除) ボタン (左側) と [Add] (追加) ボタン (右側)

選択内容に影響するコマンドは他にもあります。そのようなコマンドは、 選択時に表示される状況依存のコマンドであっても、書式設定オプション、 [すべて選択]、[選択をクリア] のように既にある選択内容に影響するコマンドで あっても、常に左端に表示します。

どのコマンドが機能的に関連していて、互いに近くに配置する必要があるかを検討します。できる限り、一貫性を持ってコマンドを配置します。また、コマンド セットを作ってアプリ バーに表示される コマンドの数を管理し、できる限りコマンド セットに対応するコマンド メニューを作ることを検討します。たとえば、メモ アプリでは、 メモをアルファベット順や日付順に配置する操作を、それぞれコマンド メニューを使って 1 つの コマンドで行います。次に示すように、コマンド メニューを使うと、アプリ バー上 のコマンドを整理してコマンドの数を大幅に減らすことができます。最初の画像では、 New が付いた各コマンドはアプリ バー上の個別のコマンドです。2 番目の画像では、New が付いたすべてのコマンドが単一の New コマンドのメニューにグループ化されています。

コマンド バーにコマンドが表示される例。

アプリ バーのポップアップ付きコマンド

設定がアプリ バーではなく、設定コントラクトに表示されることを確認して ください。これにより、ユーザーは使い慣れた一般的なメカニズムでアプリを 構成できます。

アプリ バーの拡張

両方のアプリ バーでボタンとメニューをホストできます。 同時にすべてが状況的に関連しているコマンド が多数ある場合、バーから開くことができる 1 つのメニューにそれらのコマンドを配置するのが適しています。 アプリ バーは、ボタンとメニューに限定されません。どちらのアプリ バーでも独自のコントロールを作ることができます。 独自のコントロールを作る場合は、作った新しいコントロールをタッチ、マウス、キーボードのユーザーが最適に操作できる 方法を考えます。

大量のコマンドがあるアプリでは、さまざまな方法でアプリ バーを拡張することを検討してください。 システムの他の部分との一貫性をできる限り保つために、次のガイドラインに従ってください。

  • ユーザーをコンテンツに集中させる—ほとんどの対話式操作はキャンバスの直接的な操作で始まると考えます。 すべてでなくてもほとんどのコマンドは、ビューに組み込むために、通常は表示可能な アフォーダンスのないオフ スクリーンに配置されることが予想されます。 アプリ バーの表示と非表示を行うためのシステム全体のジェスチャを 使って、UI の表示と非表示を切り替えます。 別の呼び出し方法で、代わりとなる独自の非表示の UI を追加する と、ユーザーに説明する際に、より多くのボタン、ウィジェット、矢印を画面に配置できます。 システム ジェスチャを使うと、ユーザーのコンテンツから注意をそらす邪魔なものを画面に 追加するのを防ぐことができます。
  • コマンドを下部のアプリ バーに表示しておく—Windows ストア アプリでは、コマンドが表示されることが予想される自然な 場所は、アプリの下端 (またはタッチ キーボードのすぐ上) です。 この場所では、タッチ ユーザーは コンテンツの表示を遮らずにコマンドを操作できます。 また、この場所は、コマンドを 手動で表示するために使われるタッチ ジェスチャにも関連しています。 コマンドを他の場所に表示することは、あまり予想できず、 ユーザーが表示または操作しようとしているコンテンツに影響を与える可能性があります。
  • 上部のアプリ バーにナビゲーション コントロールを保持する—Windows ストア アプリでは、ナビゲーションが表示される ことが予想される自然な場所は、画面の上端です。 このバーはユーザーが現在使っているコンテンツから離れた場所に 表示されるので、ユーザーがバーを使っているときにそのユーザーの手で画面が見えにくくなっても問題ありません。 上部のアプリ バーには、一般的に、ボタンではなく、サムネイルが表示されます。これにより、下部の アプリ バーと区別しやすくなります。
  • 非表示のコマンドをすべてアプリ バーに表示しておく— 画面で非表示になっているコマンドはすべて、同じ場所で 非表示にする必要があります。 システム ジェスチャには、非表示のコマンドを画面上に表示するための単純で標準化 された方法が 1 つ用意されています。 複数の場所でコマンドが非表示になっている場合は、それらの非表示のサーフェ イスを呼び出す方法が複数必要になります。 この場合、ユーザーがコマンドを見つけるためにチェックする必要の ある場所がすぐに作られますが、その数は膨大です。 そのうえ、各サーフェイスは別のシークレット ジェスチャや他の UI トリックの背後で 非表示になる可能性があるため、ユーザーは、それらすべてが見つかったかどうかを把握するのが難しくなります。

ショートカット メニュー

選んだテキストに対するクリップボード コマンド ([切り取り][コピー][貼り付け] など) と、 URL をコピーしてそのリンクを開くコマンドでは、システムに既定で用意されている ショートカット メニューを使うことができます。 ショートカット メニューに含まれているクリップボード コマンドの例を次に示します。

ショートカット メニューに含まれているクリップボード コマンド。

生産性アプリでのデータ入力

生産性アプリでは、多くのデータ入力シナリオが必要になる場合があります。たとえば、 To Do リストや別の新しいドキュメントの作成、既にあるスプレッドシートの編集、 カレンダーの招待の作成には、すべて入力が必要です。できる限り軽快かつ柔軟にデータ入力を行うことにより、 ユーザーは自分の作業をすばやく効率的に完了できます。

シナリオを検討し、できる限り、ユーザーがシステムに入力する 必要のあるテキストの量を減らしてください。この方法を次に示します。

  • コモン コントロール— 形式が厳密に指定されているか、検証が必要な入力 (日付、時刻、場所 など) には、選択 コントロール、ドロップダウン リスト ボックス、オプション ボタン、チェック ボックス、日付と時刻の選択コントロールなどのコモン コントロールを使います。
  • オートコンプリート— できる限りオートコンプリートを使って、ユーザーがすぐに満足感を得られるようにします。 これにより、ユーザーはより効率的に入力できるようになります。

次の図は、連絡先選択ツールの候補を示しています。

メール アドレス選択ツールに表示されている候補。

タッチ キーボード

キーボード入力への反応」のガイドラインに従って、 キーボードが適切に動作するようにアプリを設計します。 次のガイドラインに従って、タッチ キーボードが適切に動作するように アプリを設計します。

  • できるだけ、アプリのキャンバスの上の方にテキスト入力コントロー ルを配置します。そうすると、タッチ キーボードが表示されたときに、ユーザーのコンテキス トまたは表示可能な領域は変更されません。
  • キャンバスの上部に配置しきれないテキスト入力がある場合、ユーザーがテキスト入力コントロールをタップするか Tab キーを使って テキスト入力コントロールを選んだときに、アプリでは、コントロールが表示される場所まで自動的にスクロールされるため、 ユーザーは入力時にテキストを確認できます。 ウィンドウは、フォーカスがあるコントロールと、画面の両端とタッチ キーボード の上部との間に 30 ピクセル以上あるようにスクロールして、さまざまな端ジェスチャ、UI 要素、テキスト選択 グリッパー用にスペースを残しておく必要があります。テキストの選択に ついて詳しくは、 「テキストと 画像の選択のガイドライン」をご覧ください。
  • 画面にキーボードを表示しておくためだけに、キーボードを表示したままにし ないでください。テキスト入力が想定されていない場面では、入力フィールドを 読み取り専用にしたり、フォーカスを移動することによって、 キーボードを非表示にします。

タッチ キーボードを次に示します。

アプリのタッチ キーボード

アプリに、一般に編集コントロール (テキスト ボックス) と他のコントロール (オプション ボタンやチェック ボックスなど) が組み合わされた、フォームのような画面がある 場合、タッチ キーボードが点滅し続けるという問題が生じます。Windows 8 ではこの問題が解決されており、ユーザーが フォーム内にいて、オプション ボタン、テキスト ボックス、選択コントロール、アプリ バーなどの 特定のコモン コントロール間を移動しているときは、タッチ キーボードが非表示にならないようになっています。標準のコントロールを使うと、アプリにスムーズなエクスペリエンスを無料で提供できます。 ユーザーがコントロール間を移動するときにタッチ キーボードが維持されるようすを次の図に示します。

標準のコントロールが配置されたフォーム。

スペル チェック

アプリのスペル チェックを有効にします。スペル チェックを使うと、ユーザーはすばやく確実にテキストを入力できます (スペル チェックは、RichEdit コントロールを使って有効にできます)。ユーザーが辞書にない単語を入力して、 スペース バーを押すと、スペルに誤りのある単語の下に赤い下線 (波線) が表示されます。 スペルに誤りのある単語をタップすると、次に示すように、ユーザーがスペル ミスを 修正または無視できるスペル チェック メニューが呼び出されます。

スペル チェック エクスペリエンスの例

手描き入力と手書き認識

ユーザーは生産性アプリに複数のテキスト入力モードを使うことがよくあるため、ペン入力など、代わりのテキスト入力方法をサポートすることを検討してください。ユーザーがアプリでテキストを "インク入力" し、ノートやドキュメントにいたずら書きできるようにすると、ユーザーは楽しくなり、 ペンを使ってすばやく自然にテキストを入力できます。さまざまな入力方法について詳しくは、 「一般的なユーザー操作のガイドライン」 をご覧ください。

テキスト選択

ドキュメントの作成と使用など、多くの生産性シナリオでは、ユーザーがテキストを 選ぶ必要があります。ユーザーが入力したテキストを編集できるように選択を有効にします。他のユーザーから取得するテキストには、 コピーされることも多い電子メールの本文などのテキストがあります。 テキスト選択エクスペリエンスを次に示します。

選択ツールの 2 つの領域間で選ばれた単語を示すテキスト選択の例

テキスト選択を有効にすると、テキストの両側にグリッパーの幅の半分のサイズ (4 mm) の余白、テキストをスクロールできない場合はその領域の下部に 1 つの グリッパーの高さ (8 mm) が割り当てられます。これにより、グリッパーは あらゆる場合にタッチ操作できるようになり、画面の端での操作が妨げられることはありません。 次の画像は、テキストの選択を有効にした場合に保持する正しい余白を示しています。

タッチ テキスト選択の余白サイズの例

生産性アプリの文字体裁

生産性アプリで文字体裁のグリッドとサイズの見本を使うと、ユーザーが 多くの情報をすばやく簡単にスキャンして使用できる視覚的な階層が作られます。 書体見本 (type ramp) で指定された Segoe UI フォントを使うことは、生産性アプリのコンテンツ には適していますが、Calibri (推奨される "最新のドキュメント" のフォント) または Cambria (推奨される "従来のドキュメント" のフォント) を使うことを検討してみてください。Calibri は Microsoft Office の既定の sans-serif フォントで、Cambria は既定の serif フォントなので、どちらのフォントも生産性アプリと強く関連しています。 文字体裁について詳しくは、 「フォントのガイドライン」をご覧ください。

別のシステム フォントを指定する場合は、そのフォントが Windows 8 と共に インストールされていることを確認し、Microsoft Office などの個別の アプリケーションをインストールする必要がないようにしてください。独自のフォントや ライセンスを取得したフォントを使う場合は、そのようなフォントをアプ リに含めるための十分な法的権利があることを確認してください。どのフォントを選ぶかに関係なく、 Windows 8 の書体見本 (type ramp) では、使うサイズやスタイルの最大数に対して 適切なガイダンスを提供します。

Windows 8 UI の特徴として、見出しに文スタイルの大文字表記を使う必要があるので、生産性アプリにも これをお勧めします。ただし、場合によっては、タイトルの大文字表記も適しています。すべて小文字のテキストは生産性アプリではくだけすぎている印象を受けることがあり、すべて大文字の 場合は、怒りの電子メール メッセージを無意識に思い出させることがあります。これらの文字の 文字体裁の扱いは多くのローカライズされた言語には反映されません。また、 一貫して大文字表記スタイルを使うようにしてください。大文字表記スタイルを使うと、アプリの文書体裁 に視覚的な関心を引く効果を加えるだけでなく、コンテンツのさまざまな部分を区別できます。

アプリ全体で少数のフォント サイズを使うと、書体見本 (type ramp) のガイダンスで 推奨されているように、コンテンツに構造とリズムが生まれます。アプリ 内の複数の要素で書体見本 (type ramp) の同じフォント サイズを使って、 さまざまな種類の情報を伝える場合、色とフォントの太さを使って情報階層を 示すことを検討してください。

コントラクト

Windows ストア アプリは、コントラクトを通じて他の Windows ストア アプリやシステム UI に結び付けられます。同じコントラクトを実装した 2 つのアプリを連携させて、大きなシナリオや複雑なシナリオを実現することができます。アプリ コントラクトの全一覧については、「アプリ コントラクトと拡張機能」をご覧ください。

共有

コンテンツの共有は、今日の生産性アプリの鍵となる要素であり、生産性アプリとの共有には魅力的なシナリオが多数あります。ユーザーがアプリからのコンテンツを共有できるようにする場合、アプリを共有ソースにします。アプリが他のアプリからのデータを使えるようにする場合、アプリを共有ターゲットにします。

アプリからの共有

生産性はコンテンツの作成と密接な関わりがあることが多く、ユーザーはごく普通に他のユーザーとコンテンツを共有します。また、Windows 8.1 では、アプリ間でのシームレスな共有エクスペリエンスを実現します。 ユーザーが入手したアプリの数が増えるにつれ、この相互運用性により、アプリ コンテンツのさまざまな可能性が広がります。

たとえば、 少しだけ共有シナリオの例を挙げると、ユーザーは連絡先アプリを使って To Do リストや買い物リストを家族と共有したり、グループ作業アプリを使ってドキュメントを 同僚と共有したり、ブログ作成アプリを使ってブログで記事を共有したりできます。 次のスクリーン ショットは、生産性アプリで共有する方法を示しています。

生産性アプリでの共有

生産性アプリでのメールを介した共有

アプリを共有ソースにすると、そのアプリのコンテンツ (形式は URI、ビットマップ、HTML、テキスト、記憶域の項目、カスタム データ型など) を、これらの形式に対応した他のアプリで利用できるようになります。ソース アプリでは、ユーザーに共有してもらいたいコンテンツに必要な数だけ、データ型をサポートすることが重要です。そうすれば、ユーザーは幅広い共有ターゲット アプリとアプリのコンテンツを共有できるようになります。

共有ソース コントラクトをサポートすると、"タップして送信" で有効にした近距離近接通信で、アプリのコンテンツをデバイスと直接共有できます。

アプリとの共有

コンテンツの作成はコンテンツの使用から始まることがよくあるため、生産性アプリでは、通常、他のアプリからコンテンツを共有するのに適したターゲットも設けられます。アプリが共有ターゲットの場合、ユーザーはコンテンツをアプリにシームレスにインポートできます。その際、実行中の操作からコンテキストを切り替える必要はありません。生産性アプリを共有ターゲットとして使うための魅力的なシナリオが数多くあります。 たとえば、ブラウザーから URL、テキスト スニペット、写真を共有したり、書籍からコンテンツを共有したりすることは、宿題の参照元 としてドキュメント作成アプリをターゲットにすることができます。また、ユーザーはクーポン アプリから To Do アプリの買い物リストに クーポンを共有することもできます。 次のスクリーン ショットでは、共有ターゲットとしてのアプリの例を示します。共有コントラクトを使って相互にデータを共有する一連の生産性アプリケーション間の相互運用性を引き上げることもできます。

Web ページをメモとしてメモ アプリに共有。

Web ページをメモとしてメモ アプリに共有

検索

検索は、生産性アプリにとって重要なシナリオです。アプリでは検索結果として多くの データを表示することが必要になる場合があります。Windows 8.1 の検索ボックス コントロールを使って キャンバス上で検索 UI を提供できます。検索ボックスは、ユーザーのニーズに応じたエクスペリエンスをアプリで提供できるように、エクスペリエンスを強化し大幅なカスタマイズを可能にする検索コントラクトと統合されています。

アプリの検索エクスペリエンスを設計するときは、次のことを念頭に置いてください。

  • クエリの候補を提供することで、ユーザーが自動的に検索クエリを完成させ、検索文字列全体を 入力する必要なく、すばやく検索できるようにします。
  • 結果ビューに検索フィルターを提供する。
  • 結果ビューに検索クエリを表示する。
  • 見つかった結果の合計数を表示する。
  • アプリの状態を維持して、ユーザーが検索の前に行っていた操作に戻れるようにする。
  • 結果が検索に一致した理由を示す。
  • 結果の候補を表示して、ユーザーが最も関連する結果をすばやく取得できるようにすることも検討してください。 結果の候補を選ぶと、ユーザーには、結果の詳細が表示されます。候補の数は 5 個に制限します。一覧が短い方がユーザーが解析しやすいためです。

検索ボックス コントロールについて詳しくは、「検索の更新」を参照してください。

次のスクリーン ショットでは、メモ アプリでの検索の使用を示します。

メモ アプリ内での検索。

ページ内検索

検索に加えて、 "ページ内検索" は、生産性アプリでは一般的なシナリオです。たとえば、特定のドキュメント内である単語のすべてのインスタンスを 検索するとします。 アプリにページ内検索機能を実装する際は検索チャームを使いません。 代わりに、検索ウィンドウではなく、アプリのコマンド バー内に実装します。ページ内検索を使うと、ユーザーは現在の ビューに含まれているすべてのインス タンスを見つけることができます。ドキュメントで検索結果を強調表示し、アプリ バーに [次へ] ボタンと [前へ] ボタンを表示してユーザーが見つかった単語や語句のインスタンス間をすばやく ジャンプできるようにします。生 産性アプリでは、主に、検索は置換エクスペリエンスを補完するために使われることがよくあります。次に 示すように、検索は常に現在のビューに限定されます。

ページ内検索エクスペリエンス。

設定

生産性アプリに適用できるすべての設定 (プライバシーの設定、通知の 設定、表示の基本設定など) は、設定チャームに配置する必要があります。設定チャームは、ユーザーが 1 か所で設定を調整できる場所であり、また、アプリの UI がさまざまな設定で雑然となるのを防ぐことができます。 設定について詳しくは、 「アプリ設定のガイドライン」をご覧ください。

デバイス

ドキュメントやメモの印刷は、生産性アプリでは一般的なシナリオです。 シームレスな印刷エクスペリエンスを実現するために、ユーザーが デバイス チャームから印刷機能を使用できるようにします。 印刷のデバイス エクスペリエンスを次に示します。

印刷のデバイス エクスペリエンス。

デバイスは、生産性アプリがプラグインとして使用できる、興味深いコントラクトです。 アプリに多数のメディアや使われる可能性のあるプレゼンテーションのシナリオ が数多く用意されている場合、ユーザーは共有メディア エクスペリエンスのテレビでそれを表示できます。デバイス コントラクトと統合すると、ユーザーはそれを行うことができるようになります。

ファイル ピッカー

生産性アプリには、他のアプリからコンテンツを使うための興味を引くシナリオが 多数含まれていることがあります。ファイル ピッカーを使うと、アプリは、ローカル PC、 接続した記憶装置、ホームグループ、ファイル ピッカー コントラクトを実装して いる他のアプリケーションにあるユーザーのファイルやフォルダーにアクセスできます。 これにより、ユーザーは他のアプリのコンテンツを自分のアプリに挿入できる ため、ユーザーのエクスペリエンスが向上します。たとえば、メモ アプリでは、ユーザーは写真アプリから写真を挿入したり、サウンド レコーダー アプリからオーディオ ノートを挿入したりできます。

また、アプリでは、ファイル ピッカーのさまざまな側面をカスタマイズできます。 具体的には、次のとおりです。

  • ファイル ピッカーのモード: ファイル ピッカーのモードをタスクに合わせ て設定できます。 ファイル ピッカーでは、ファイルの選択、ファイルの保存、 フォルダーの選択がすべてサポートされています。 たとえば、ユーザーがフォルダーを選択できるようにする と、ユーザーはフォルダー全体を選んでクラウド記憶域にアップロードできます。
  • 表示モード: ユーザーに写真や動画を選ばせる場面で、ファイル ピッカーを カスタマイズして、サムネイル表示モードでファイルを表示できます。 他のすべての ファイルの種類では、タイル表示モードを使います。

また、生産性アプリのコンテンツを他のコンテキストのユーザーにとって意味のあるもの にすると、他のアプリからこのコンテンツにアクセスしたときに、ユーザーに対して高度な シナリオを実現できます。ファイル ピッカー コントラクトを使うと、アプリケーション内の コンテンツを他の Windows 8 アプリで使うことができます。 これ により、ユーザーは、最初にファイルをローカル コンピューターに保存する などの中間プロセスを介さずに、アプリからコンテンツにアクセスできます。 アプリでこのエクスペリエンスが実現すると、ユーザーは ファイル ピッカーで場所の一覧からアプリを選ぶことができます。アプリを選ぶと、ユーザーは、 ファイル ピッカーのビューを使って、アプリのコンテンツにアクセスできるよう になります。このビューは、アプリに固有のものであり、アプリ作成者によって制御されます。

ファイル ピッカーを使うと、いくつかの魅力的なシナリオが実現します。たとえば、ユーザーがメモ アプリ内で 作ったメモをメールで友人に送る場合、メモ アプリから直接コンテンツを添付できます。 最初にローカルに保存する必要はありません。

また、アプリにも直接保存できます。これにより、本当に興味 を引くシナリオを実現できます。たとえば、ユーザーは別のアプリで作った電子メール メッセージや いたずら書きをアプリにメモとして直接保存できます。 ファイル ピッカーをカスタマイズする方法を次に示します。

カスタマイズできるコンポーネント

つながりとライブ

Windows 8.1 で動作するアプリでは、アプリを引き立たせるエクスペリエンスと特徴を統合する必要があります。タイル、通知、ローミング、コントラクトを使うことにより、アプリが Windows 8.1 エコシステムにスムーズに適合します。

タイルと通知

最新のカスタマイズされたコンテンツをアプリのタイルに表示すると、ユーザー は再び魅了され、タイルで興味を引くコンテンツを見つけたときにアプリに引き込まれます。魅力的なシナリオには、共有コンテンツが更新されたとき、 新しいメモをユーザーと共有したとき、または、買い物リストを編集して新しい商品をチェックして 追加したときに、タイルの通知を表示することが含まれます。また、通知では、次の例のように、関心のあるスポットの場所を示すこともできます。

通知が表示されているタイル

ユーザーがお気に入りのメモやコンテンツにすばやくアクセスできるように セカンダリ タイルをピン留めできるようにすると、そのコンテンツ用にカスタマイズした 通知を表示して、もう一度ユーザーをアプリに引き込むことができます。

即時性が必要なアラーム シナリオ (月末に支払う To Do リストの項目など) を 伴う生産性アプリでは、ユーザーはアラームと完了日をタスクと関連付けることができます。通知する時刻に スケジュールされているトースト通知をユーザーに表示することを検討してください。見逃したトースト通知 については、次に示すように、タイル上にそのアラームを表示することもお勧めします。

見逃した通知が表示されているタイル

トースト通知のベスト プラクティスについて詳しくは、 「トースト通知のガイドラインとチェック リスト」をご覧ください。タイルのベスト プラクティスについて詳しくは、 「タイルのガイドラインとチェック リスト」をご覧ください。

ローミング

ほとんどの人は Microsoft Windows PC を複数所有しています。ユーザーのすべての Windows PC 間で 一貫したユーザー エクスペリエンスをアプリが提供することにより、ユーザーが期待するエクスペリエンスが 実現します。アプリの設定、ユーザーがアプリで最後に行った操作についての情報、すべての PC 間でユーザーに役立つアプリの その他の設定をローミングできます。ローミングのベスト プラクティスについて詳しくは、 「アプリケーション データのローミングのガイドライン」をご覧ください。

画面の向きとウィンドウのサイズ

Windows 8.1 はさまざまな種類のデバイスで動作し、新しいマルチタスク モデルを搭載しているため、アプリが横向きと縦向きに対応し、最小幅までの任意のサイズで正しく動作することを確認してください。

Windows 8.1 用の生産性アプリを設計する際は、さまざまな画面解像度やデバイス サイズなど、アプリのすべてのビューを検討してください。Windows 8.1 では、デバイスの サイズに合わせてアプリに コンテンツを含めることで、デザインを簡単にサイズに合わせることができます。縦長で幅の狭いレイアウトに合わせてサイズ変更されたメモ アプリを次に示します。

メモ アプリの縦向きのビュー

縦長で幅の狭いレイアウトと縦方向は、大量のコンテンツを読み取って使うのに最適です。 ウィンドウのサイズに合わせてアプリでコンテンツを並べ替えられるようにしてください。

ユーザーがアプリのサイズを変更する場合は、ユーザーのコンテキストと状態を失わないようにしてください。このことは、ユーザーが手間をかけてコンテンツを作成している可能性のある生産性アプリでは特に重要です。ユーザーがアプリのサイズを変更しても、それまでのテキスト入力、スクロール位置、選択内容を維持してください。

アプリの幅が狭くなる場合、アプリ バー コントロールでは自動的にラベルが削除され、コマンド間のパディングが少なくなります。コマンドが多数ある場合は、コマンドの表示方法について創造力を働かします。たとえば、アプリ バーで 2 行のコマンドを使ったり、コマンドにポップアップを使ったりします。詳しくは、「アプリ バーのガイドライン」をご覧ください。

さらに、アプリの価値を引き上げ、こうしたシナリオの実用性を高める方法を考えてください。 アプリが他のアプリと適切に連動する理由をユーザーに示します。 たとえば、メモ帳アプリやリスト作成アプリが他のアプリと連動することは簡単に想像できます。 調査中または作成中は、主な作業の横の画面に参照アプリや分析アプリを保持しておくのが一般的です。 リーダー アプリや作成アプリは、幅が狭いと、別の作業を行いながら参照できて非常に便利です。 従来のデスクトップではアプリが常に最大化されないことについて考えてみましょう。狭い幅にサイズ変更された状態のアプリでサポートする必要のあるシナリオを次に示します。

狭い幅で正しく動作するようにアプリを設計することは、アプリが画面に表示されている時間を長くし、より長くユーザーの関心を 集めておくのに効果的な方法です。ブラウザーの横に並べられたメモ アプリの例を次に示します。

幅が狭いメモ アプリ

関連トピック

Windows ストア アプリの紹介
Windows ストア アプリの UX ガイドライン

 

 

表示:
© 2017 Microsoft