あやね
ボトムシートは、モバイル画面の下端から短い作業を表示し、元の画面とのつながりを保つUIです。受取場所の選択、少数の絞り込み条件の変更、施設情報の確認などに向いています。背景を操作できるようにするか、内容に対してどの高さが必要か、選択を確定せずに閉じたらどうなるかを先に決めます。上端の角丸よりも、こうした動作のほうが使いやすさを左右します。
この記事では、注文商品の受取場所を選ぶ画面を例にします。利用者は地図を開き、近くの受取場所を比較して一つ選び、注文内容の確認画面へ戻ります。PixsoのUIデザインツールで地図、シート、選択状態を並べると、実装前に一連の流れを確認できます。
地図を操作できる状態にするか決める
地図を操作できるシートは、周辺を探す場面に向いています。利用者は画面下部の施設概要を見ながら地図を移動できます。一方、モーダルのシートは、受取場所を選び、確定またはキャンセルしてから注文へ戻るような、区切りのある判断に向いています。
MaterialのAndroid向けドキュメント（英語）では、標準のボトムシートとモーダルのボトムシートを区別しています。モーダルには背景を暗くするオーバーレイがあり、標準のシートでは周囲のコンテンツを操作できます。一方の見た目に、もう一方の動作を組み合わせないようにします。
ここではモーダルを使います。「受取場所を選択」という見出し、閉じるボタン、検索欄、受取場所の行、「この場所で受け取る」ボタンを配置します。背景の地図は位置関係を示しますが、シートを閉じるまでは移動できません。地図を動かしながら選ぶことが重要なら標準のシートを使い、地図のピンを選ぶと表示中の施設情報が更新されるようにします。
ボトムシートは表示位置の選択肢であり、あらゆる作業を重ねて表示する理由にはなりません。長い住所フォーム、本人確認、支払いをまとめて行うなら、独立したページが適しています。オーバーレイの種類は、表示したい形ではなく、利用者が行う作業に合わせて選びます。
割合ではなく、作業に必要な高さを決める
最初に開く高さは、見出し、検索欄、少なくとも受取場所一行の全体、主要な操作を表示できる大きさにします。一行目が途中で切れていると、何を選べる画面なのか判断しにくくなります。反対に、必要もなく画面全体を覆うと、地図を残す利点が薄れます。
一覧が短ければ、内容に合う高さで開きます。件数が多い場合は展開とスクロールに対応させます。見出しと閉じる操作の位置は安定させ、その下の領域で一覧をスクロールできるようにします。主要な操作は端末のセーフエリアより上に置き、システムのジェスチャー領域に重ならないようにします。
| 状況 | シートの表示 | 使える状態を保つもの |
|---|---|---|
| 近くの受取場所が3件 | 各行を省略せずに表示するコンパクトなシート | 見出し、閉じる操作、選択、確定 |
| 検索に一致する場所が多い | 一覧をスクロールできる展開状態 | 検索と確定の操作に引き続き手が届く |
| 画面の高さが低い、または文字を拡大している | ほぼ全画面のシート、または独立した選択画面 | 固定の表示比率よりも、読める文字と操作できるコントロールを優先する |
ドラッグハンドルは展開できることを示せますが、内容を増やす唯一の手段にはできません。分かりやすい展開操作を用意するか、通常のスクロールで一覧全体へ到達できるようにします。シートのドラッグと一覧のスクロールが同じジェスチャーを取り合い、予測できない動きにならないことが大切です。
確定するまでは仮の選択として扱う
現在の注文には「中央駅」が設定されているとします。利用者がシートを開いて「リバーサイド店」を選んだら、シート内ではリバーサイド店を選択状態にします。ただし、「この場所で受け取る」の処理が成功するまでは、注文に保存された場所を中央駅のままにします。シートを閉じた場合は、この仮の選択を取り消します。
この区別により、確定ボタンがあるのに行を押しただけで注文が変わる、という食い違いを防げます。選んだ時点で反映する仕様なら、重複する確定操作をなくし、即時に反映されることを明確にします。二つの方式を混在させてはいけません。
選択に必要な情報として、施設名、住所、受け取り可能な日時などを表示します。距離も参考になりますが、位置情報の取得元が分かっている場合に限ります。位置情報の使用が拒否された場合や検索地域が変わった場合に「最寄り」と表示すると誤解を招きます。その場合は検索した地域を示し、別の場所を入力できるようにします。
注文を受け取れない施設では、理由をその行に表示します。「本日は受け取りできません」であれば、別の場所を選ぶ理由が分かります。施設名が灰色になっているだけでは、表示の不具合にも見えます。候補を比較している間も、入力した検索条件は残します。
キーボードを開いた状態で設計する
検索欄を使うと、利用できる表示領域が変わります。レイアウトを確認するときはキーボードを表示し、必要に応じてシートを展開して、入力欄と選択に使える検索結果をキーボードの上に残します。デスクトップのような構図を保つために文字を小さくしないでください。
キーボードを閉じる操作と、受取場所の選択をやめる操作は分けます。利用者は検索結果を広く見るためにキーボードを閉じただけで、選択を続けたいかもしれません。ネイティブアプリではプラットフォームの戻る操作やキーボードの慣例に従い、Webでは外側を押す操作が常にキャンセルを意味すると決めつけず、動作を明示します。
検索結果は、現在の入力に対応している必要があります。「リバー」の検索が完了する前に入力が「中央」へ変わった場合、後から届いた古い結果で中央の結果を置き換えてはいけません。検索中も入力内容を残します。失敗時は入力を消さずに再試行できるようにし、検索が成功しても一致する場所がない場合は、施設名や地域の変更を案内します。
確定操作は作業の近くに置きますが、固定フッターで最後の行を覆わないようにします。スクロール領域の下端に余白を設け、想定する最も小さな画面で確認します。キーボードによって選択に必要な領域がほとんど残らない場合は、細い隙間でスクロールさせるよりも、検索専用の全画面状態に切り替えたほうが明快です。
閉じる操作と戻り先を予測できるようにする
この例では、閉じるボタンと、許可する場合の外側タップは、どちらも仮の受取場所を取り消します。再び開くと、注文に現在設定されている場所を表示します。まだ設定していなければ、未選択の状態で開きます。スワイプを追加の閉じ方として用意しても、画面上の閉じる操作は残します。
Webのモーダルでは、WAI-ARIAのダイアログパターン（英語）に沿って、フォーカスをダイアログ内へ移し、背景を操作できない状態にして、閉じた後に適切な場所へ戻します。背景を暗くするだけで、これらの動作が実現するわけではありません。ダイアログに意味の分かる名前を付け、キーボードですべての操作へ到達できるようにします。
確定に失敗した場合は、シートを開いたまま仮の選択を残し、操作の近くに理由を示します。何も伝えずに閉じて、注文内容だけが元のまま残る状態は避けます。成功したらシートを閉じ、確認画面に新しい場所を表示し、場所の変更操作または次の適切な操作へフォーカスを戻します。
Pixsoで受取場所の選択を組み立てる
注文内容、選択画面を開いた状態、仮の選択、確定後の注文内容を、それぞれ別のフレームに作成します。受取場所は一貫して「中央駅」「リバーサイド店」「マーケット広場」の3件を使います。仮の選択ではリバーサイド店を選びながら、変更前の注文内容には中央駅を残します。これにより、選ぶことと確定することの違いが見えるようになります。
Auto Layoutを使って、長い住所や大きな文字でも収まるか確認します。画面下部にキーボードを配置した検索の展開状態と、リバーサイド店の選択を残した確定失敗の状態も追加します。主要な操作をプロトタイプでつなぎ、フォーカスの戻り先、閉じ方、保存済みの値と仮の値の区別を、短いメモとしてフレームの横に置きます。
レビューでは、場所を変更して確定せずに閉じ、もう一度開いてもらいます。その後、変更を最後まで完了してもらいます。どちらの結果も注文内容から理解できる必要があります。小さな作業を終えても、注文全体の状況を見失わないことが、ボトムシートを使う価値です。
