Web アプリを実装しやすくする UI 部品の選び方
同じ「モバイルアプリっぽい」UI デザインでも、プラットフォーム（Web と iOS ネイティブと Android ネイティブ）によって標準で用意された UI 部品が異なるため、それぞれ実装のしやすさが異なります。
端的に言うと Web では
- HTML 標準のフォーム部品とボタン、アンカーリンクを使ってください。
- モーダルよりもページのほうが実装しやすいです。
- というより Z 軸方向に重なっている表現全般が Web は苦手です。
少しでも実装を軽くしたいときに意識してみてください。大抵の場合、実装が楽になるだけでなく、アクセシビリティも向上します（これは健常者にとっても、UI 操作の選択肢が広がるので、良いことです）。
具体例
最近リリースされた Srush というサービスを例に説明します（私はフロント開発者として関わりました）。
ピッカー（プルダウン、ドロップダウンとも）
複雑になりがちな UI 部品の筆頭ではないでしょうか。たとえば次の画面では、商談時間と業務時間が該当します。
👍商談時間を選ぶピッカー
👍業務時間を選ぶピッカー
これらはそれぞれ標準の select 要素と input 要素 (type=time) を使っているので、実装が楽で使いここちもよい状態です。デスクトップとモバイルの出し分けも自動で行われます。
しかし、この UI がこういうデザインでやってくると、標準の部品は使えません。
🤦♀️選択肢を入力したり増やしたりできる難しいピッカー
対処としては、ボタンを分離してやるか
👍ボタンを分離した例
datalist 要素で値をサジェストしつつ自由入力も許可するかです。
モーダル（ダイアログ、アラート、プロンプトとも）
メインの画面の手前に浮いて表現されるサブ画面的な部品です。
Human Interface Guidelines より引用
これもよく使われますが、Web にこの部品は用意されていません[1][2]。見かけたらそれらは一つ一つ手作りです。温かみがありますね。
画像左の Alert のように「ちょっと文字を出すだけ」ですら制限がかかります。タイトルは指定できないし、ボタンも OK のみか OK と キャンセル くらいしかなく、ラベル指定はできません。文字の装飾や画像も無理です（window.alert や window.confirm のことです）。さらに、それらの表示中はプロセスが一切停止して体験が悪化するうえ、場合によってはアラートを抑制するオプションを使われることすらあります。
🤦♀️アラート抑制オプション
とはいえ、すべてのモーダルをなくすことは現実的ではないでしょう。Srush でも、日程調整をする過程でハーフモーダル的な UI が登場します。
日程選択の UI
こういった UI の利用は最低限にするのがよいでしょう。開発初期の Srush は、ほとんどの画面がモーダルでデザインされていました。これは iOS ネイティブでは正解かもしれませんが、Web ではページのほうが実装しやすいので、デザインを変更してもらいました[3]。
ページにすることで、実装が楽になるだけでなく、ユーザーにとっても使いやすくなります。
- ページに URL が対応するので、URL を使ったアクションが可能です（URL をシェアしたり、別アプリから特定の画面を開いたりできる）。
- 標準の戻る／進むボタンやジェスチャーが使えます。
- 下手なモーダルの実装のせいでスクロールやピンチイン／アウトの操作が妨げられるといった可能性が低下します。
Web の画面は上から下へ一方向に UI パーツを並べていくのが最も素直です。この並びに逆らい、Z 軸方向へ浮かせたパーツをスクロール位置によらず特定の位置に配置するというのは、Web は基本的に苦手なのです（独自のピッカーを実装するのが手間なのも同様の理由です）。
エンジニア、デザイナー、ステークホルダーはそれぞれどうすべきか
（ここでは要件の決定権を持つ人をステークホルダーと呼んでいます）
エンジニア
標準部品に何があって何がないか、デザイナーとステークホルダーに伝えましょう。そのうえで、標準部品がどこまで拡張可能か、代替 UI として何が可能なのか、できるだけ引き出しを用意しておきましょう。
デザイナー
どれが標準部品で可能な UI なのか、エンジニアに聞きましょう。Web/iOS/Android の特性に合わせてデザインを変えられると、エンジニアからは崇められると思います。
ステークホルダー
小洒落た UI デザインよりも、標準部品を使うことによるコスト低減とユーザビリティ向上に価値を置きましょう。プログレッシブエンハンスメントとグレースフルデグラデーションの考えも取り入れてみてください。
Srush の開発チームは柔軟だったので、感謝しています。
Discussion