見出し画像

デザイナーが App に Web View を導入するときの覚え書き

ロコガイド デザイナーの木村です。最近読んだ「時間術大全」のおかげで生産性が爆上がりして毎日がたのしいです。

画像6

先日、トクバイで毎日のお買い物が楽しくなるニュースやレシピが見られる「よみもの」という機能をリリースしました🎉 

このプロジェクトでは開発リソースを圧縮するため、早いタイミングで Web View で実装することを決めたのですが、アプリエンジニアから「Web View 大変だよ…」と言われてやったら本当に大変だったので、備忘録も兼ねてデザイナーが Web View を検討する際に考慮しておかないといけないポイントをまとめました。

Web View とは

Web View とは、HTMLやWebコンテンツをアプリ内に直接ロードして表示する仕組みを指します。

ですが、Webコンテンツをアプリ内に表示する方法は Web View 以外にもあります。それぞれメリット・デメリットがあるので、達成したい目的に応じて最適なものを選ぶとよいでしょう。

Web View(WKWebView) ・ WebView

HTMLやWebコンテンツをアプリ内に直接ロードして表示する仕組みです。

画像5

🙆‍♀️  メリット

ナビゲーションを自由にカスタマイズできる
ただし、ウェブブラウザとしての機能はないため、Navigation Bars・App bars にどんなアクションが必要か検討する必要があります。

同じ UIViewController・Activity 内に表示することが可能
ex. タブでネイティブとWeb Viewの表示切り替えを行いたい場合など

🙅‍♂️  デメリット

ブラウザとCookieの共有はできない
SNSシェアボタンをタップすると、場合によってはログインページに遷移してしまう…などの問題が発生します

ページの描画が遅い
Safari・Chrome で表示するよりロード時間が長くかかります。

実装コストが高い

👉   Web View を検討するシーン

更新頻度の高いコンテンツを表示する場合
アプリのアップデートを待たずにコンテンツを更新したい。
ex. ニュース、利用規約、プライバシーポリシー、問い合わせフォーム

・アプリの実装コストをそれほどかけられず、すでにWeb側にコンテンツが用意されている場合
ex. 人的リソース、開発スケジュールの都合など

Web View は最後の手段
Web View でのみできることがある反面、Cookie が保持できなかったり、描画スピードが遅いなどのデメリットもあります。

ヒューマンインタフェースガイドラインでは「iOSでWebを閲覧するおもな方法はSafari」と明記されており、App Store Reviewガイドラインでも「Appを作成する際は、Webサイトを単に再パッケージしたようなものではなく、優れた機能、コンテンツ、UIを作成するようにしてください」とも言及されているように、必要に応じて後述する SFSafariViewController・Chrome Custom Tabs や、Safari・Chrome で Webページを閲覧することを検討しましょう。

トクバイの「よみもの」では、ナビゲーションのカスタマイズが必要だったのと、他のタブのコンテンツと同じ UIViewController・Activity に画面を表示する必要があったため Web View を採用しました。

SFSafariViewControllerChrome Custom Tabs

WebViewの代わりに Safari・Chromeの機能をアプリ内で利用できる仕組みです。 混同されがちですが、Web View ではありません!

画像4

🙆‍♀️  メリット

・ブラウザとCookieの共有が可能
・実装コストが低い

🙅‍♂️  デメリット

・ナビゲーションのカスタマイズは限定的
Navigation Bars・App bars の配色は変えられるが、ナビゲーションの右上にアイコンを置くことができない…などの制限があります。

・同じUIViewControllerActivity 内に表示できない
Webコンテンツを表示するには、新たに UIViewController・Activity を立ち上げる必要があります。

Safari・Chrome

OSデフォルトブラウザアプリ。通常、App内でURLをタップするとこれらのブラウザが起動します。App外に遷移することでユーザー体験が損なわれなければ、ブラウザに飛ばしてしまうのが最も低コストでしょう。

画像6

仕様・UIで検討が必要なこと

ナビゲーション

Navigation Bars・App bars にどんなアクションが必要か検討しましょう。
よく使うものを以下にまとめました。

<進む、 戻る> のナビゲーション
x 閉じるボタン
シェアボタン

画面遷移

Web View を 同じ UIViewController・Activity で表示するか、新しい UIViewController・Activity を開くのか。iOSの場合はさらに push と modal どちらで UIViewController を開くのかも合わせて検討しましょう。

Figmaなどのプロトタイピングツールを利用して画面遷移が違和感ないか確認した上で仕様を策定しましょう。

また、表示するWeb Viewが複数ページに渡るメディアコンテンツの場合はトップと第2階層(ディレクトリトップ)、さらには詳細ページの画面遷移もきちんとフォローしましょう。

トクバイの「よみもの」コンテンツでは、トップと第2階層は同じ Activity で表示しないと違和感があったため、開発途中で仕様を追加しました🙈

ログ

タブ、各コンテンツ、ボタンなどのログを、AppとWebのどちらで取るかを事前に決めておきましょう。二重でUUをカウントしないよう注意しましょう。

動作確認

📣  SafariChrome での挙動と Web View の挙動は違います。
動作確認は必ず Web View で行いましょう。

見落としがちなポイント

・Web View 内でサービス外まで回遊できてしまう
ドメイン外のサイトにアクセスする場合はブラウザで開くよう設定しておきましょう。また、Web View から参照する場合、ドメイン外に遷移する導線を削除してしまうのもよいでしょう。

・JavaScriptが意図通り動かない
smooth scroll が動かない、横スワイプがカクつくなど。なお、Android の Web Viewで JasvaScript を動作させるためには設定を有効にする必要があります。

一緒にロコガイドで働く仲間を募集しています!

ロコガイドでは小さな改善から大きな価値創造まで、一緒にサービスをデザインしていく仲間を募集しています!

まだまだ組織は拡大期、一緒につよつよデザインチームを作っていきましょう💪💪💪 「いきなり応募はちょっと…」というあなた、まずはわたしたちの取り組みについて気軽にお話ししませんか?

参考資料

🍎  iOS

🤖  Android


この記事が気に入ったらサポートをしてみませんか?