Web アプリを実装しやすくする UI 部品の選び方

3 min read読了の目安(約3500字

同じ「モバイルアプリっぽい」UI デザインでも、プラットフォーム(Web と iOS ネイティブと Android ネイティブ)によって標準で用意された UI 部品が異なるため、それぞれ実装のしやすさが異なります。

端的に言うと Web では

  • HTML 標準のフォーム部品とボタン、アンカーリンクを使ってください。
  • モーダルよりもページのほうが実装しやすいです。
    • というより Z 軸方向に重なっている表現全般が Web は苦手です。

少しでも実装を軽くしたいときに意識してみてください。大抵の場合、実装が楽になるだけでなく、アクセシビリティも向上します(これは健常者にとっても、UI 操作の選択肢が広がるので、良いことです)。

具体例

最近リリースされた Srush というサービスを例に説明します(私はフロント開発者として関わりました)。

https://www.srush.co.jp/

ピッカー(プルダウン、ドロップダウンとも)

複雑になりがちな UI 部品の筆頭ではないでしょうか。たとえば次の画面では、商談時間と業務時間が該当します。

プルダウン UI
👍商談時間を選ぶピッカー

時刻を入力する UI
👍業務時間を選ぶピッカー

これらはそれぞれ標準の select 要素input 要素 (type=time) を使っているので、実装が楽で使いここちもよい状態です。デスクトップとモバイルの出し分けも自動で行われます。

しかし、この UI がこういうデザインでやってくると、標準の部品は使えません。


🤦‍♀️選択肢を入力したり増やしたりできる難しいピッカー

対処としては、ボタンを分離してやるか


👍ボタンを分離した例

datalist 要素で値をサジェストしつつ自由入力も許可するかです。

モーダル(ダイアログ、アラート、プロンプトとも)

メインの画面の手前に浮いて表現されるサブ画面的な部品です。


Human Interface Guidelines より引用

https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/modality/

これもよく使われますが、Web にこの部品は用意されていません[1][2]。見かけたらそれらは一つ一つ手作りです。温かみがありますね。

画像左の Alert のように「ちょっと文字を出すだけ」ですら制限がかかります。タイトルは指定できないし、ボタンも OK のみか OKキャンセル くらいしかなく、ラベル指定はできません。文字の装飾や画像も無理です(window.alertwindow.confirm のことです)。さらに、それらの表示中はプロセスが一切停止して体験が悪化するうえ、場合によってはアラートを抑制するオプションを使われることすらあります。


🤦‍♀️アラート抑制オプション

とはいえ、すべてのモーダルをなくすことは現実的ではないでしょう。Srush でも、日程調整をする過程でハーフモーダル的な UI が登場します。


日程選択の UI

こういった UI の利用は最低限にするのがよいでしょう。開発初期の Srush は、ほとんどの画面がモーダルでデザインされていました。これは iOS ネイティブでは正解かもしれませんが、Web ではページのほうが実装しやすいので、デザインを変更してもらいました[3]

ページにすることで、実装が楽になるだけでなく、ユーザーにとっても使いやすくなります。

  • ページに URL が対応するので、URL を使ったアクションが可能です(URL をシェアしたり、別アプリから特定の画面を開いたりできる)。
  • 標準の戻る/進むボタンやジェスチャーが使えます。
  • 下手なモーダルの実装のせいでスクロールやピンチイン/アウトの操作が妨げられるといった可能性が低下します。

Web の画面は上から下へ一方向に UI パーツを並べていくのが最も素直です。この並びに逆らい、Z 軸方向へ浮かせたパーツをスクロール位置によらず特定の位置に配置するというのは、Web は基本的に苦手なのです(独自のピッカーを実装するのが手間なのも同様の理由です)。

エンジニア、デザイナー、ステークホルダーはそれぞれどうすべきか

(ここでは要件の決定権を持つ人をステークホルダーと呼んでいます)

エンジニア

標準部品に何があって何がないか、デザイナーとステークホルダーに伝えましょう。そのうえで、標準部品がどこまで拡張可能か、代替 UI として何が可能なのか、できるだけ引き出しを用意しておきましょう。

デザイナー

どれが標準部品で可能な UI なのか、エンジニアに聞きましょう。Web/iOS/Android の特性に合わせてデザインを変えられると、エンジニアからは崇められると思います。

ステークホルダー

小洒落た UI デザインよりも、標準部品を使うことによるコスト低減とユーザビリティ向上に価値を置きましょう。プログレッシブエンハンスメントグレースフルデグラデーションの考えも取り入れてみてください。

https://developer.mozilla.org/ja/docs/Glossary/Progressive_Enhancement
https://developer.mozilla.org/ja/docs/Glossary/Graceful_degradation

Srush の開発チームは柔軟だったので、感謝しています。

脚注
  1. iOS には用意されているような書き方ですが、詳しくは知りません。実は意外と大変かも。 ↩︎

  2. 新しめの要素に dialog 要素がありますが、Safari に対応していないので実質使えません。 ↩︎

  3. 結構な画面数変えてもらってデザイナーの方には感謝しかないです。 ↩︎