📱

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

2022/01/24に公開約4,300字

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

ログインするとコメントできます