モーダルとベース画面で異なるアクションボタンの配置
IPadとWindows用の製品を再設計していますが、現在、アプリケーションでボタンが配置される方法を検討しています。
ベース画面
一般的な「ベース画面」は次のようになります。特別なことは何もありません。いくつかのアクションが右側に配置され、コンテンツが下に表示されるだけのナビゲーションです。コンテンツは編集可能であるため、変更した場合は、保存ボタンをクリックして保存する必要があります。この範囲を超えた自動保存。
モーダル
ナビゲーションのリンクの1つをクリックすると、編集用のフォームを含む小さなモーダルが表示されます。
現在のデザイン
現在、フォームに入力するか、フォームを編集してから、モーダルの右上にある2つのアイコンをタップして、変更を受け入れるかキャンセルします。これにはすぐに明らかな制限がいくつかあります。
- アイコンはあいまいであり、意味を明確にするためにラベルを付ける必要があります
- 破壊的なアクション（キャンセル）と建設的なアクション（完了）のスタイルが似すぎており（同じレベルの目立つ場合）、互いに近すぎます。
- アクションはフォームの後に表示されるため、ユーザーはフォームを上から下に入力し、上に戻ってアクションを実行します。
提案された設計
- アイコンは、各アクションがラベルで何をするかを明確に指定するボタンに置き換えられます。
- キャンセルボタンと完了ボタンが分離され、スタイルが変更されました。最も重要なのは、破壊的なアクション「キャンセル」がボタンになっている「完了」ではなく、リンクとしてのみスタイルが設定されていることです。これにより、キャンセルではなくフォームの完成が促進されます。
- アクションはフォームの下部にあります。
問題
提案されたモーダルのデザインでは、フォーム（その下のコンテンツを保存する保存ボタン）の前に基本画面のアクションがあるのは奇妙だと指摘されています。
この理由は、単にスペースを節約するためです。これらのワイヤーフレームが反映していないのは、このような小さな場所に入力する必要があるコンテンツの量です。そのため、保存ボタンをメインナビゲーションに揃えることは理にかなっています。これを行わなかった場合は、代わりに新しい行を含めて、保存ボタンと、おそらく1つまたは2つ以上のボタンを収容することにより、コンテンツ領域を犠牲にする必要があります。ほとんど価値がないようです。
私の質問はこれです。誰か他の人がこの問題に遭遇しましたか、それについてあなたは何をしましたか？私の提案は、ベース画面のボタン配置とモーダルの間のこの不整合を考慮しても大丈夫ですか、それとも本当に修正する必要がありますか？
制限事項
- 現時点でのユーザーテストは残念ながら範囲外です。
- タッチだけでなくマウスでも機能する必要があります。
現在のデザインに関するあなたのすべての点は完全に正しいので、私はそれから離れることを強くお勧めします。
モーダルの下部にボタンを配置することは一般的な方法であるため、ユーザーは、ベース画面との一貫性に関係なく、このパターンに非常に精通している可能性があります。ユーザーがあまり技術に精通していない場合でも、コンテンツの後にアクションを実行させるのは非常に自然なパターンです。
画面の領域について本当に心配している場合は、Atlassianで示されている「フォーカスタスク」アプローチを検討します。 https://www.atlassian.design/server/patterns/focused-tasks/ =
コンテンツの上の一番上の行にツールバーの目的がある場合は、[保存]ボタンを左に移動します。このようにして、他のほとんどのアプリケーションと一貫性を保ちます。ツールバーのボタンの重要性は左から右に向かって減少するのが一般的です（重要性：たとえば使用頻度に関して）。典型的な例は、Microsoft Officeなどのオフィスアプリケーションです。
さらに、多くのアプリケーション（Officeなど）は、上で説明した方法でツールバーと提案された設計のようなモーダルダイアログを同時に使用していることに気付くでしょう。これは典型的な設計であり、多くのユーザーがそれに精通しています。私の意見では、ここで一貫性を強制する必要はありません。