開発者なら知っておきたいモード, モーダルのこと
OOUIの時代だからこそ重要な「モード」への理解を広め、良いプロダクトを設計しよう。
最近、OOUIの普及した今だからこそ、モードを適切に使いこなせることは良いUIや体験を作る上で重要だと感じています。
モードは使い方によって毒にも薬にもなりますが、その塩梅はよく知られていません。
そこでモードやモーダルについて周囲のメンバーにも浸透する機会を設け、この理解を促進する勉強会を行いました。
モードやモーダルは、案外奥深く歴史深いプラクティスも多い分野です。勉強しないのは車輪の再発明になりかねず、もったいない！
社外の開発者さんにも知ってもらえるといいなと思い、私の行った勉強会の動画とドキュメントを公開しました。
以下、文章でも軽く解説します。勉強会でも触れている箇所には🎥の絵文字をつけておきましたのでご参照ください。公開物は文末をご覧ください。
🎥 モーダル
語義
あなたはモーダルと言われると、何をイメージしますか？
いまお手伝いしているチームに同じ質問を問いかけてみたところ、彼らは「ユーザーの行動を止めるもの」「オーバーレイをともなってUIの前面に出てくるもの」といった答えを返してくれました。
実際のところは、「モーダル」は現在、厳密な言葉としては機能していません。大まかに分けても次の2つの使われ方をしています。
1つの事柄に閉じ込めコンテキストを中断させる、という状態や挙動のことを「モーダルだね」「モードだね」などと表現します。
また、ダイアログやアノテーションといった、画面上に浮かび上がってくるモノのことを「モーダル」と表現することもあります。
この多義性によって、現場では語義ほど単純ではなく、よりハイコンテキストな言葉です。
単に「ここはモーダルにしよう」と言っただけでも、それが ”モードな機能や遷移を提供すること” なのか ”ダイアログやアノテーションを出すこと” なのか不明瞭です。
今回行った勉強会では、既にチームにモードへの理解が多少あったため、より具体であるダイアログやアノテーションについて話しました。
Modality
ダイアログやアノテーションといった “モードな” 性質を持つ具体的なUIコンポーネントには、ルールが必要です。そうでなければ、ユーザーの操作をブロックするふるまいが乱発される、悪いUXを許容してしまうからです。
このルールやプラクティスはModalityと呼ばれます。
モード、そしてModalityは、GUIが誕生して間もない頃から存在する概念です。既に多くのプラクティスがありますので、ここは知の高速道路に乗ってみましょう。
今回参照するのに選んだのは、マイクロソフト, グーグル, アップルの権威あるデザインシステムです。彼らはどのようなModalityを定義しているのでしょうか？
🎥 モーダルのプラクティス
控えめに使う
例えばMicrosoftのダイアログの節では、次のように記述されています。
伝える情報の重要度が、ユーザーを中断させる必要があるものかどうかを、よく検討する必要があります。 また、情報の表示頻度を検討し、 (中略) 代わりにプライマリ UI でこの情報用の領域を割り当てることを検討します。
ユーザーが特定の操作を頻繁に実行することが想定される場合には、ユーザーがアクションを毎回確認する必要があるようにするよりも、誤って操作した場合に、ユーザーが元に戻せる方法を提供することを検討します。1
さらにGoogleのMaterial Designでも、次のように記述されています。
ダイアログは意図的に割り込みを行うため、慎重に使用する必要があります。混乱の少ない代替手段は、ユーザーエクスペリエンスを中断することなくオプションを提供するメニューを使用することです。2
AppleのHuman Interface Guidelineでは記述が様々な箇所にありますが、Alertの節の記述を要約すると次のように記述されています。3
情報を提供するためだけにアラートを使用しないこと。人々は、有益であるが実用的ではないアラートによる中断を歓迎しません
破壊的なものであっても、一般的な元に戻せるアクションにはアラートを表示しないこと
アプリの起動時にアラートを表示しない。ユーザーがアプリを開いた瞬間に新しい情報や重要な情報を知らせる必要がある場合は、情報を簡単に見つけられるようにする方法を設計すること
複数のデザインシステムにおけるModalityで、極力使わないことが傾向として共通していることが分かります。
モードレスであれ
近年、国内のUIデザイン界隈では「モード」と「モードレス」という言葉が急速に普及しました。その中で「モーダル」は、UIデザインにおいて以前よりも敬遠されるようになっています。
ユーザーの操作をブロックしたり閉じ込めたりする「モードな状態」は多くのプロダクトにとって必要であり、ダイアログ等も同じく必要なコンポーネントです。しかしその用途には慎重である必要があります。
ユーザーのコンテキストを中断させる必要があるものかどうかをしっかり検討し、どうしても中断させなければならない場合とモードである方が良い合理的な理由がある場合にだけ、使わなければなりません。
モーダルを検討できるケース
そもそもモーダルであるべきケースというのはそれほど多くありません。モーダルを検討できるパターンを大別すると、次の3つです。
アラート。問題や現在の状況の変化について人々に伝える
選択肢。意図的なアクションを提供する
ツール。コンテキストに密接に関連する簡単なタスクを実行を可能にする
しかしながら、少なくとも1についてはユーザーの行動をブロックしないModalityを作ることはできるので、これを目的にユーザーの操作を中断させるのは、現代においていい選択ではありません。4
また、現代では没入感のためのModalityも存在します。4つ目の検討パターンと言えるでしょう。
一部の動画サイトや音楽サイト、書籍サイトで利用されており、モーダル然とした振る舞いでありながら充実したマイクロインタラクションを備えることでプライマリUIとして採用されています。
これは比較的新しいModalityで、現時点で唯一といってもいい歓迎されるモーダルです。
この体験差は、コンテキストを中断させているか、より深くコンテキストに集中させているかの違いにあるでしょう。
モーダル勉強会
私の所属するチームでは、よりよいModalityを検討する素地を作るための活動の一貫として、モーダルについての勉強会を行いました。
より多くのコンポーネントについて触れつつ、得た知識を使って自社プロダクトの既存のモーダルをみんなで添削するワークも行いました。これは自社プロダクトのUIを見直す良い試みだったと思います。
勉強会の様子を、社外の方でも見れる範囲を動画にしています。ドキュメントを開きながら動画をご覧いただくことで、勉強会に参加した気分になれるかもしれません。ぜひご覧ください。
動画：
例えば、Material DesignのSnackBarは中断させないアラートの提示方法と言えます。