モバイル用に最適化されたアプリについての説明
Power Apps からモバイル用に最適化されたキャンバス アプリをデザインおよび作成する場合は、複数のデザイン コンポーネントを考慮する必要があります。
モバイル用に最適化されたキャンバス アプリには、以下のデザイン特性が必要です。
明確に定義された目的
レスポンシブ デザイン [Bring your own device (BYOD)]
シンプルなユーザー インターフェース
直感的なナビゲーション
外部周辺機器は必要ない
オフライン機能
接続アラート
シームレスな設定
パフォーマンスのために最適化されている
明確に定義された目的
モバイル用に最適化されたアプリケーションには、明確に定義された目的が必要です。 ユーザーがモバイルのキャパシティでアプリを使用する場合、タスクを達成するために必要なアクションを最小限にすることが、より良いユーザー エクスペリエンスに直接的に関連します。
在庫管理のためのすべてのアクションを行うモバイル倉庫アプリケーションのように、さまざまなアクションを持つ単一のアプリが必要かどうかを判断します。 あるいは、顧客の作成など、特定の目的のために単一のアプリケーションが必要な場合もあります。 次に、以下の明確化の質問を自分に問いかけます。
異なるアクションを完了するためにホームページに戻る方が容易か? または、別のアクションを完了するためにアプリを終了する方が容易か?
組織内のユーザーにとっては、複数のアプリを操作した方がより良いエクスペリエンスになるか?
単一のアプリケーションが存在する場合、実行する操作が多すぎると目的が複雑化するか?
アプリ用のフォームをデザインする際は、各フォームに 1 つの簡単な文で定義できる目的が用意されている必要があります。 顧客や顧客コンタクトの作成など、単一のフォームに多すぎる目的を持たせることは避けましょう。 代わりに、それぞれが固有の目的を持つ、複数のフォームの作成を検討します。
レスポンシブ デザイン
モバイル用に最適化されていると考えられるモバイル アプリケーションや Web サイトは、表示するアプリケーションに適合している必要があります。
たとえば、Microsoft.com などの Web サイトはデスクトップおよびモバイル ビューで表示できます。 アプリケーションまたは Web サイトは、表示するデザインのレイアウトを調整します。 以下の例では、Microsoft.com を最初にデスクトップビューで表示してから、モバイル用に最適化されたビューで表示しています。
シンプルなユーザー インターフェース
フォームに多くのフィールドや入力コントロールが含めようとする衝動に負けないでください。
キャンバス アプリは、顧客作成などのタスクで使用する可能性のあるすべてのフィールドを含めると、包括的であるように思われるかもしれません。 ただし、ユーザーがあまり使用しない余分なコントロールをいくつも用意すると、インターフェースが乱雑になり、最も頻繁に使うフィールドを見つけるためのスクロールや「フィールド ハンティング」が増えることになります。 その代わり、簡潔なフォームを作成し、ユーザーがめったに使用しない高度なフィールド入力用のフォームを新たに作成することを検討します。
ユーザーが複数の画面を移動しなければならない場合、ネガティブなエクスペリエンスをする可能性があります。
送信ボタンなどのボタンが必要な場合は、ユーザーが最も選択しやすい場所との関係で、ボタンを配置する場所を検討します。
シンプルなデザイン:
画面上にボタンやフィールドが多すぎると、ユーザーが誤ってボタンやフィールドを選択してしまう可能性があります。
フィールドの周囲にバッファスペースを設け、送信ボタンがユーザー エラーの差異を許容することを検討します。
直感的なナビゲーション
モバイル用に最適化されたアプリには、複雑なユーザー マニュアルは必要ありません。 その代わり、タスクやビジネスアクションを整理して、ユーザーの日常的な操作をガイドするようにします。
メモ
ユーザー インターフェイスを作成するための唯一の正しい方法は存在しません。
これまでに定義された目的に基づいて、ユーザーのタスクを整理する最も論理的な方法を決定します。 以下の 2 つのデザイン シナリオを検討してください。
チームがこのモバイル アプリを使用すると、販売注文書を 90% の時間で作成し、新しい顧客を 20% の時間で作成できます。 その結果、最初のナビゲーション ボタンは販売注文書の作成フォームに、2 番目のナビゲーション ボタンは顧客作成フォームに追加する必要があります。
チームはモバイル アプリを使用して、最初の注文を作成するか、または最初に顧客を検索してから注文フォームの自動入力を使用して、新しい顧客を見つけます。 したがって、最初のナビゲーション ボタンは販売注文書の作成フォームに、2 番目のナビゲーション ボタンは顧客作成フォームに追加する必要があります。
ユーザーは、簡単にメイン画面に戻りたいと常に考えています。 したがって、戻るためのナビゲーションの作成する際は、以下の点に留意してください。
各フォームには、別のアクションを実行するためにメイン画面に戻る簡単な方法を含める必要があります。
複数の操作により中心となる場所に戻ることを求めると、ユーザー エクスペリエンスが悪くなります。
ユーザーが特定のタスクを終了し、新たなタスクがない場合、そのアプリは自動的にホーム画面を再表示して次のアクションを実行できる必要があります。
外部周辺機器の除外
スマホやタブレット PC を使っているユーザーは、マウスやキーボードを持っていない可能性が高くなります。
アプリケーションのユーザーインターフェースを設計する際には、自分が特定のデバイスを手に持ってアプリケーションを操作している様子を想像してみると、それが良いエクスペリエンスかどうかを判断するのに役立ちます。 たとえば、ユーザーがフィールド情報を入力する際には、画面上にキーボードが表示されるため、その要素がユーザーのエクスペリエンスに影響を与えるかどうかを判断する必要があります。
オフライン機能を含める
モバイル アプリケーションのユーザーは、携帯電話サービスや Wi-Fi が利用できない場合があります。 そのため、どのような場合にユーザーがオフライン機能を必要とするかを判断するために、以下の質問を自問してください。
ユーザーがインターネットに接続することなくアクションを実行しなければならない環境でそのアプリを必要としているか?
キャンバス アプリにオフライン機能を含めると手間がかかる場合があります。 アクションのオフライン対応には、その手間に見合う価値があるか?
特定の場所でしか利用できないデータの読み取り/書き込みなど、オフラインで行う必要があるアクションがデバイス上で利用できないか?
接続アラート
クラウドファーストのソリューションでは、クラウドへの接続は必須です。 多くのユーザーは、キャンバス アプリにアクセスする際、インターネットに接続していることを前提にしています。
インターネット接続の要件があるさまざまなフォームやアクションには、フォームの検証を含める必要があります。 ユーザーがデータを入力しようとする前に、このフォーム検証によって、モバイル アプリケーションがオフライン モードであり、アクションが利用できないことをユーザーに警告できます。 たとえば、顧客を作成するアクションが接続を必要とする場合、アプリケーションは、モバイル アプリケーションがオフラインの際に、ユーザーが顧客作成フォームにアクセスしてデータを入力することを許可すべきではありません。
できるだけ早くユーザーにアラートを出すことで、データ入力の再作業を減らすことができます。 モバイル アプリケーションに接続できないことを示すバナーを画面上部に表示するなど、アラート インジケーターを含めることを検討する必要があります。
シームレスな設定
シームレスな設定は、アプリを採用するユーザーにとって重要です。 Microsoft の Power Apps はシームレスに展開できますが、それらのアプリを必要なデータ ソースやユーザー アクセスに接続するシナリオでは、設定が必要な場合があります。
アプリケーションや API の URL など、必要なデータの入力をユーザーに求める場合、ユーザーがそのデータを見つけるためのヒントを含めることを検討する必要があります。 ユーザーは初めてアプリを使用するため、ガイダンスを必要としていることを想定しましょう。
また、どのようなアプリが使われているかをユーザーに伝えるために、モバイル アプリケーションの包括的かつ直接的な説明を含めることも検討すべきです。
パフォーマンスの最適化
モバイル アプリケーションのパフォーマンスは、デスクトップ アプリケーションよりも重要です。 携帯電話では複数の作業を行うマルチ タスクの制約があるため、パフォーマンスが重要な要素になります。 デスクトップ ユーザーは、キャンバス アプリで特定のタスクを行っている間に、他のアプリケーションに容易に移動することができます。
アプリケーションのパフォーマンスを最適化する場合は、以下を行う必要があります。
データ ソースと、取得するデータの複雑さを検討する。
アプリケーションで使用されているデータ コネクタを評価する。
複雑で不必要なデータ ソースの削除を試みる。
特定のアクションに必要な特定の数のレコードのみの取得を試みる。
要するに、モバイル アプリケーションの作成を計画している場合は、作成する前に設計について考慮するのが賢明だということです。 すでに構築されたアプリを修正するよりも、開始前にその道筋を明確にする方が簡単です。