📱

Webしか知らないエンジニアが色んなアプリのWebUIとモバイルUIを見比べながらモバイルUIについて考えてみた

2022/01/24に公開

Web しか知らない人がモバイルアプリを作るにあたってモバイルっぽさを追及しようと試行錯誤する過程で考えたことを書いていきます。

タイトルにもありますが筆者は Web をメインにしているので、実際の現場とは異なる見解である可能性がありますし、主観による部分が大いにありますので、その辺りご了承いただきたく存じます🙇‍♂️

個人的に趣味の延長でモバイルを触ってみて、Web の感覚をそのまま当てはめた際に感じたコレジャナイ感などを言語化していきます。

似てるけどデバイスが異なるWebとモバイル

昨今の Web アプリはレスポンシブデザインを要求されたり、モバイルアプリを意識した SPA や SSR が主流になったり、PWA が登場するなど、スマホアプリの影響を大いに受けているように見受けられます。
文脈にも依りますが双方とも大きな括りでフロントエンドと呼ばれたりもします。

しかし、一方で Web とモバイルで明確に異なる部分もあります。

一番大きな部分はデバイスが異なることでしょう。
当然と言えば当然ですが基本的には PC は横長で十分な広さがあり、モバイルは縦長で狭いスペースになります。
フロントエンドエンジニアやデザイナーが作成した画面以前にデバイスがあります。
user_device_ui
ユーザーとデバイスとUIの関係

個人的には特にレスポンシブな Web やクロスプラットフォーム等に対応する際、普段から自分が使っているデバイス等(自分の場合は主に PC)であれば動作を確認しやすいですが、そうでない場合はユーザーの前にデバイスがあるという意識が欠如してしまうことがあります。

もう少し具体的な話をすると、例えばレスポンシブにするにあたって、明らかにレイアウトが崩れている等でない限り、「これはモバイルでは実際使いやすいのだろうか?」といった疑問が出てきにくい気がしています。
(エミュレータや Chrome の開発者ツール等の PC 画面上では問題ないが、実機で動かしてみた場合にボタンが小さすぎるように感じるなど。)

こういった UX 的な面から、モバイルについては実機テストの重要度が特に高い気がしています。
(もちろん Web においても重要な場合はあると思います)

ハンバーガーメニュー(ドロワー)を採用しているアプリが少ない

Web でレスポンシブデザインをしようとしたとき、画面上部にハンバーガーメニューを配置するというパターンをよく見ます。が、UX 的にはあまりよろしくないと言われることがあります。
https://www.sidethree.co.jp/blog/memo/202002-1.html
https://www.hp-maker.net/magazine/hamburger/

参考に自分のスマホにインストールされているアプリをざっと見てみたのですが、たしかに少なかった印象です。
(Youtube, LINE, Facebook, Paypay, Amazon, Slack...etc、単に自分のスマホに入っているのを見ただけなのでコンシューマ向けのアプリ中心です)

ハンバーガーメニューがよろしくないことはなんとなく聞いたことがあったのですが、
モバイルのような狭い画面を有効に使う上では仕方のないものだと考えていたので、最近はこんなに少なくなったのかと実感しました。

上記のアプリの大半はボトムナビゲーションを採用していそうでした。
比較的頻繁に使うメニューはボトムへ配置し、それ以外のメニューは一画面に集約しているというパターンが多そうです。

facebook
Facebookアプリの例

特に最近のスマートフォンデバイスはホームボタンなど、デバイスの下部にボタンがある機種が減ってきたというのもあって、このデザインは理に適っているような気がします。
逆に今後もデバイスの変化に伴って使いやすいデザインが変わってくるという可能性はありそうです。

Formの表示をどうするか

アプリケーションの特性にも依りますが、Form 等ユーザーの入力を受け付ける UI をどこに配置するのかというのも Web とモバイルで差がありそうな気がしています。

例えば Twitter の Web 版とモバイル版の UI を見てみましょう。
※ツイートにはモザイクかけてます。

twitter_for_web
Twitter(Web版)

twitter_for_web_form
Twitter 投稿時(Web版)

twitter_for_ios_tl
Twitter タイムライン(iOS版)

twitter_for_ios_form
Twitter 投稿時(iOS版)

Web 版では投稿フォームがタイムラインの上に配置されている & 左下の「ツイートする」ボタンを押すことでフォームが出てくるのに対し、モバイル版では右下のボタンを押下することで投稿用の画面(Modal)が出てきます。

表示内容にもよりますが、Web だと画面が広い分同じ画面にフォームをそのまま配置してしまってもスペースに余裕がありますが、モバイルだとなかなか厳しそうな気がしました。
一覧データと一緒にフォームを配置しているアプリケーションだと他には 5 ちゃんねる(画面下部にフォームが配置されている)もありましたが、こちらもスマホ UI はボタンを押すとフォームが出てくる方式になっていました。

個人的には SPA だと投稿ボタンを押下すると背景が暗くなってダイアログのような形でフォームが出てくるイメージを持っていたので、モバイル UI で一画面のようなモーダルが出てくるのが意外に感じました。(モバイルでモーダルというとこのような一画面に近いものを指しそう)
が、画面が狭い分モバイルの場合はほとんどフォームで隠れてしまうこともあり、背景を見せても仕方がないところがありそう・・・と考えると理に適っている UI のように思いました。

DataTable vs ListView

何かしらの一覧データを表示する場合、モバイルアプリだと縦に長いという特性もあってか、横長になりがちなデータテーブル的な UI を採用しているアプリは少ない印象があります。

もしかすると toB 向けのアプリケーション等だと変わったりするのかもしれないですが、Twitter や Facebook のタイムラインや Youtube のホーム、Gmail 等ほとんどの一覧データは ListView のような UI になっていました。

また、別の観点からの話をすると、UI Framewrok のVuetifyDataTableというコンポーネントを提供しています。
このコンポーネントの仕様が興味深く感じました。
まずは WebUI を見てみましょう。(公式から引用)

VuetifyのDataTable
VuetifyのDataTable

通常のテーブルレイアウトといった形で上部にヘッダーがあり、以降は行ごとに各レコードの値が表示されているのがわかります。Web をやっている方には馴染みのあるレイアウトではないでしょうか。

次にモバイル UI を見てみましょう。

Vuetify の DataTable(モバイルレイアウト)
VuetifyのDataTable(モバイルレイアウト)

大きくレイアウトが変わっているのがわかると思います。
各レコードの表示項目が横に並ぶのではなく縦に並んでおり、かつヘッダーにあった項目名がレコードにくっついているような形です。
こちらもスマホデバイスの縦長の特性を意識しているように見えます。

表示する項目にも依りますが、Web 上でテーブル表示しているデータはこのようなリスト形式に置き換えることができそうです。

Pagination vs Infinite Scroll

上記に付随して、Vuetify の例では Web もモバイルもページネーション UI が付属しているのですが、実際のモバイルアプリを見ていると大抵は無限スクロールを採用していそうです。

Web アプリをモバイルに移行する場合などにこの辺の仕組みを変えようと思うと、慣れていないと少し苦労しそうな気がしました。

さいごに

たぶん他にも山ほどモバイル UI のお約束のようなことがあるとは思うものの、ちゃんとした学び方がいまいちわからず、気になったことを書き連ねてみました。

作るアプリケーションの内容やユーザー等で考慮することが増えそうな気がしますが、まずは既存のアプリを真似て色々と掴んでいければと思っています。

GitHubで編集を提案

Discussion