ウェブサイトを活用するファーストクラスのアプリの構築：ケーススタディ
公開: 2022-03-10Mark Zuckerbergはかつて、次のように述べています。「企業として私たちが犯した最大の過ちは、ネイティブではなくHTML5に賭けすぎたことです。 そして、HTML5が悪いわけではありません。 私は実際、長期的に、それについて本当に興奮しています。」 そして、複数のプラットフォームで機能する単一のコードベースの見通しに誰が興奮しないでしょうか？
SmashingMagの詳細：
- プログレッシブウェブアプリの初心者向けガイド
- プログレッシブウェブアプリの構成要素
- Foundation ForAppsで完全なWebアプリを作成する
残念ながら、Facebookは、HTML5が構築しようとしているエクスペリエンスを提供していないと感じていました。それが、実際のエクスペリエンスです。 マークが本当に言おうとしていたのは、彼らの最大の過ちは、ユーザーエクスペリエンスに基づく決定ではなく、テクノロジーに基づく決定を行うことだったと思います。 結局のところ、私たちはお客様に価値を提供する決定を下す必要があり、特定のテクノロジーに固執することは、一般的にそれを達成するための最良の方法ではありません。
オンラインのみのeコマース小売業者であるBeyondthe Rackのクライアントにとって、私たちの主な目標は、優れたユーザーエクスペリエンスを備えたアプリを構築することでした。 Zuckerbergと同様に、HTML5ルートを採用したかったのです。HTML5Webインターフェイスで作成されたアプリへの「一度書けばどこでも実行できる」アプローチは非常に魅力的です。 しかし、ユーザーが製品を操作する主な方法がアプリになりつつある今日の世界では、パフォーマンスは優れているだけでなく、競争上の優位性もあります。
ただし、アプリのすべての機能を完全にネイティブなインターフェースで構築する必要があることはほとんどありません。 たとえば、ナビゲーションアニメーションをウェブ上でネイティブに感じさせるのは難しいかもしれませんが、複雑なアニメーションをほとんどまたはまったく含まないウェブページは、ネイティブでありながらアプリで簡単に使用できます。 これがユーザーにとって本当に重要なことです。 その場合に必要なのは、「多分一度書けば、どこでも実行できるかもしれません。それは本当に機能に依存します…」戦略です。
つまり、ネイティブインターフェイスとWebインターフェイスのどちらかを選択しないでください。 両方を使う。
この記事では、Beyond the Rack用のアプリを作成した経験を紹介します。このアプリでは、ネイティブコンテンツとWebコンテンツを組み合わせて、ネイティブを「感じる」アプリを作成します。
ケーススタディ：ラックを超えたアプリの構築
明らかに、Beyond theRackがアプリで自分自身とその顧客のために解決しようとしている問題を特定することが重要でした。 機能ごとにネイティブにするかWebにするかの選択は、当然のことながらそこから行われます。
優れたアプリを作成するには、次の3つすべてで優れた仕事をする必要があることに気づきました。
- ショッピングインターフェース
Beyond theRackはオンラインのみの小売業者です。 したがって、販売を閲覧したり購入したりするための優れたインターフェースを持つことが重要です。 ネイティブアプリを構築していたため、Webエクスペリエンスが提供できる以上のことを行う機会がありました。 - 共有可能性
Beyond the Rackの大きな収益源は、顧客がさまざまな販売アイテムを友人と共有することであるため、iOS、Android、およびブラウザー間の共有が可能な限りシームレスであることを確認する必要がありました。 - 発見可能性
Beyond the Rackは、ユーザーに期間限定の販売を提供します。 そのため、ユーザーにすばやく連絡できることが非常に重要です。 プッシュメッセージングは、これらの忠実な顧客を引き付けるための最良の方法を提供し、最終的にはアプリを構築する決定の最大の推進力となりました。
Beyond the Rack iOSおよびAndroidアプリの最も重要な機能のいくつかをどのように構築したか、つまり、アプリのどの機能がWebテクノロジーを使用して構築されたか、どの機能が完全にネイティブであり、それらがすべてどのように連携するかについて詳しく見ていきましょう。
ショッピングインターフェース
ネイティブビット
タブレットとモバイルでBeyondtheRackのレスポンシブウェブサイトを構築しました。これは私たちが誇りに思っていることです。 しかし、単にWebサイトをWebビューに入れて、それを1日と呼ぶだけでは十分ではありませんでした。 Webサイト自体は、ネイティブアプリのようには感じられません。 その大きな理由はナビゲーションです。 ブラウザには、戻るボタンと進むボタン、およびURLバーがあります。 iOSアプリとAndroidアプリでは、ユーザーはナビゲートする方法について非常に異なる期待を持っており、アプリが各プラットフォームと一貫していると感じるように、それらの期待に一致させたいと考えました。
AJAXを介してコンテンツを動的にロードし、Web言語でナビゲーションとトランジションを管理するプロトタイプを作成しましたが、ネイティブアプリで見られるトランジションほどスムーズに感じることはできませんでした。 iOSとAndroidのナビゲーションアニメーションをWebテクノロジーを使用して一致させることは非常に困難であり、ナビゲーションにジャンクがあると、アプリのネイティブ感が低下します。 アプリが毎秒60フレームで実行されていない場合、ユーザーは気付くでしょう。
私たちは、両方の長所を組み合わせたと感じたアプローチを思いつきました。Webからメインコンテンツをロードしますが、ネイティブナビゲーション要素を使用します。
iOSでは、これを実装するのは非常に簡単でした。 ビューのスタックを管理するナビゲーションコントローラーと、各ビュー間のナビゲーションを制御するためのナビゲーションバーを活用しました。 この場合、ビューのスタックは実際には単なるWebビューのスタックです。ナビゲーションが発生するたびに、Webビュー自体でナビゲートするのではなく、新しいWebビューをインスタンス化し、 UINavigationControllerにプッシュして、にナビゲートします。新しい目的地。 Webビューのスタックを使用することは、ユーザーが戻るたびに、ページがリロードされるのを待つ必要がないことも意味します。これは、ユーザーエクスペリエンスに最適です。 将来、機能をネイティブビューに置き換えることにした場合は、その機能のWebビューバージョンではなく、ネイティブビューをスタックにプッシュするだけです。
Androidでは、ナビゲーションコントローラーに相当するのは、アクティビティのスタックを使用することです。 複数のアクティビティとフラグメントはどちらも非常に複雑なライフサイクル管理を必要とするため、使用しないことにしました。 最終的に、アプリのWebビューの独自のスタックを管理し、各ビュー間を移行するためのカスタムネイティブアニメーションを作成しました。
他の多くのアプリは、ネイティブナビゲーション要素を活用してOSデザインパターンに準拠しています。 ネイティブナビゲーションバーを活用したBasecampのAndroidアプリの画像をご覧ください。
また、AmazonのアプリをモバイルWebサイトと比較してください。
このアプローチにより、Webからの優れたコアショッピング体験を活用しながら、プラットフォームに馴染みのある体験をすることができるというスイートスポットを見つけました。
これは多くの人にとって驚きかもしれませんが、Facebookアプリの開発者は、各機能に意味がある場合にネイティブまたはWebを活用して、常にスイートスポットを見つけています。 Facebookのエンジニアが書いた記事によると、「アプリ内で変更が頻繁に行われると予想される領域では、新しいバージョンのアプリをダウンロードしなくてもサーバー側で更新をプッシュできるため、引き続きHTML5コードを利用します。 。」 Facebookは、ここで提唱されているのと同じアプローチを採用しているようです。パフォーマンス、必要な開発作業、およびドアから出すために必要な速度に基づいて、各機能のテクノロジーを選択します。
アプリの場合、機能をネイティブに構築するか、Webコンテンツを活用する方が理にかなっているかどうかをケースバイケースで検討してください。 ネイティブに感じられるナビゲーションを構築することの難しさを考えると、少なくともネイティブコンポーネントを使用してナビゲーションを構築することはおそらく理にかなっています。
Webビット
今日、ほとんどの人がWebサイトを段階的に拡張することをお勧めします。ブラウザの最小公分母に1つのマークアップベースを使用し、コンテキストに応じて、JavaScriptとCSSを使用して機能と拡張機能を重ねます。個別のコードベースやテンプレートはありません。必要なさまざまなデバイス用。 モバイルウェブとデスクトップウェブ用に別々のテンプレートを作成することが意味をなさないのと同じように、アプリ自体の中でライブウェブサイトテンプレートを使用したかったのです。 アプリは単なる別のコンテキストです。
私はこの建物を「アプリ対応」のレスポンシブウェブサイトと呼んでいます。 アプリのコンテキストとパフォーマンスを念頭に置いてウェブサイトを構築することで、さまざまなプラットフォームのすべてのユーザーに遅かれ早かれ出荷できるようになります。
appクラス—ウェブサイトをアプリ対応に段階的に強化するためのパズルのピース。 ウェブサイトは、CSS、JavaScript、サーバーの3か所でアプリのコンテキストを検出できる必要があります。 条件付きCSSを作成するためのappクラスと条件付きJavaScriptを作成するためのisRunningInAppメソッドを作成し、条件付きサーバー側ロジックのユーザーエージェントにAppを追加しました。
アプリ内でプログレッシブエンハンスメントを使用した例は、製品の表示ページにあります。 アプリ専用の固定位置の[カートに追加]ボタンを追加して、最適化しました。
ブラウザに固定位置の「バッグに追加」ボタンを追加することもできますが、Safariでは、下部の近くをクリックすると実際にSafariのナビゲーションバーが開くため、追加しませんでした。 ユーザーがカートに商品を追加しようとしたときにこのバーを誤って開いてしまうと、ページの下部に[カートに追加]ボタンが表示され続けるという利点があるにもかかわらず、許容できないユーザビリティの欠陥になります。
ウェブサイトにアプリ固有の調整を加えたもう1つの領域は、ショッピングカートです。 カートロジックは通常、eコマースウェブサイトの最も難しい側面の1つであり、モバイルでのカートエクスペリエンスに非常に満足しているため、ルックアンドフィールを少し変更して、アプリで再利用することにしました。
共有可能性
リンクを共有し、共有リンクを開く機能は、Beyond theRackでうまく機能する必要がある重要な機能です。 共有をシームレスにしたかったのです。 誰かがデスクトップからリンクを共有し、その友人がアプリでそれを開いた場合、リンクは正しく開く必要があります。 同様に、誰かがアプリの製品を共有する場合、デスクトップで正しく開く必要があります。 友達がモバイルを使用しているがアプリがインストールされていない場合は、ブラウザで開く必要があります。 これは通常、アプリが苦手なものであるため、これを素晴らしいエクスペリエンスにすることを決意しました。
Webとアプリの間でコンテンツを共有可能にするのは難しい場合があります。 これを正常に行うには、アプリのリンクとWebリンクをマッピングする必要があります。 デスクトップURLを開くと、リダイレクトなどが原因でモバイルURLのホームページに移動するため、これは応答前の時代には苦痛でした。 今日、アプリでもまったく同じ問題が発生しています。SafariとChromeのバナーでは、アプリでリンクを開くように求められますが、アプリでは探しているものが表示されず、もう一度検索する必要があります。 幸い、Beyond the RackのアプリでWebリンクを処理するのは簡単です。必要なのは、そのURLをWebビューにロードすることだけだからです。 Webリンクがユーザーをブラウザーではなくアプリに誘導することを確認する必要があります。
Androidでは、アプリでURLを開くのは簡単です。 ユーザーが指定されたURL（この場合はwww.beyondtherack.com ）を読み込もうとするたびに、アプリを読み込むためのインテントフィルターを設定する必要があります。 アプリがインストールされると、ユーザーはアプリまたはブラウザでURLを開くオプションが表示されます。
www.beyondtherack.com ）でアプリを開くためのAndroidインテント。 （拡大版を表示） iOSは、WebURLをアプリで直接開くことができるようにするためのやや困難な道を歩んでいます。 以前は、iOSでは各アプリのアプリスキーマのみを登録できました（たとえば、 beyondtherack:// ）。 インストールされているアプリを知ることは不可能だったため、Safariで特定のリンクを開き、そこからアプリでそのリンクを開こうとするしかありませんでした。 これにはちょっとした煩わしさがありました。アプリがインストールされていない場合、ユーザーは「アドレスが無効なため、Safariはページを開くことができません」という迷惑なエラーメッセージを受け取ります。 ありがたいことに、ハックを使用すると、iframeを使用してそのエラーを抑制できます。 iOS 8でディープリンクをサポートする場合は、これが最適なオプションです。
ありがたいことに、iOS 9ではユニバーサルリンクが導入されました。これにより、アプリはリンクがSafariを通過する前にWebリンクをインターセプトできます。 ##発見可能性適時性は、Beyond theRackのような企業にとって非常に重要です。 従来、売上について顧客に通知する同社の主な方法は、電子メールキャンペーンによるものでした。 しかし、アプリを使用すると、**販売について顧客と直接通信**することができます。これは非常に強力です。 （もちろん、プッシュ通知はブラウザにゆっくりと届き、[Chromeが主導権を握っています]（https://gauntface.com/blog/2014/12/15/push-notifications-service-worker）。ただし、古いAndroidデバイスの場合iOSの場合、ネイティブテクノロジーとウェブテクノロジーのどちらを使用するかはすでに選択されています。）共有と同様に、アプリでウェブコンテンツを直接活用するという決定により、**プッシュ通知**を簡単に設定できました。 すべての商品と販売はウェブサイトとアプリの両方で同じURLで識別できるため、マーケターに通知を顧客にプッシュする方法を教えるのは簡単です。必要なのは、共有に慣れているのと同じURLを共有することだけです。メールキャンペーンで。 iOSとAndroidの興味深い違いの1つは、プッシュ通知の**許可システム**です。 iOSでは、通知の許可はオペレーティングシステムによって制御されますが、Androidでは許可は必要ありません。 それでも、顧客サービスの観点からは、許可を求めることは正しいことだと感じました。 そのため、ユーザーが初めてアプリにログインするときに、通知が必要かどうかを尋ねます。 
結果
アプリのリリース後、そのパフォーマンスをブラウザーのエクスペリエンスと比較したいと思いました。 私たちの経験では、アプリをインストールした人は誰でもより忠実な顧客であり、したがってより良いコンバージョンを達成する可能性が高いため、分析を直接比較するだけでは不十分でした。 選択バイアスを回避するために、A / Bテストを設定しました。 ユーザーの半分はアプリにとどまり、残りの半分はブラウザーにキックオーバーされました。これにより、実験の参加者はアプリをインストールしたユーザー（より忠実なユーザー）のみであることが保証されました。
- ユニークビジターあたりのトランザクション数は、ウェブよりもアプリエクスペリエンスの方が76％高かった。
- アプリのユニークな毎日のユーザーは、コンバージョンする可能性が20％高くなりました。
- アプリユーザーは、ウェブユーザーよりも63％多くの時間を閲覧に費やしました。
クイックパフォーマンスが勝ちます
Webコンテンツをロードし、ネイティブであると感じるアプリを作成することは、iOSまたはAndroidではすぐに使用できません。 共有する価値のある、私たちが直面したパフォーマンスの課題をいくつか示します。
- iOSでは、Webビューのスクロールの勢いは、ネイティブのスクロールビューのスクロールの勢いと一致しません。 これは、ユーザーテストで明らかになりました。 これを解決するための1つのライナーを次に示します
webview.scrollView.decelerationRate = UIScrollViewDecelerationRateNormal; - Webビューのサイズを変更するときは注意してください。 サイズを変更すると全体が再描画され、古いデバイスでのスクロールパフォーマンスが低下するという問題が発生しました。
- Androidで何百もの異なるWebビューの実装を処理するのは、苦痛を伴う可能性があります。 私たちが遭遇した最も厄介な問題は、Android 4.4.2の既知のWebビューのバグです。これは、Chromiumで致命的な例外をスローし、アプリをクラッシュさせます。
transform: translate3dはうまくいくようです。 または、Crosswalkを使用して、コンパイル済みの独自のWebランタイムをアプリと一緒に出荷することもできます（これは行いませんでしたが、将来のプロジェクトに向けて計画しています）。 - FastClickを使用すると、300ミリ秒のクリック遅延がなくなるだけでなく、iOS8.4.1で導入されたWebビューのクリックバグが修正されます。 私たちにとって、クリックが遅すぎる場合にページを変更できないようにすることで、バグが明らかになりました。
- スクロールを素晴らしいものにするために、できる限りのことをしてください。 スクロールイベントをデバウンスしたり、不要な再描画などを回避したりできます。 スクロールが毎秒60フレームで実行されていない場合、ユーザーはWebよりもアプリの方が気付くでしょう。
- 1000ミリ秒未満でページをロードするためにできる限りのことをしてください。
あなたのウェブサイトを活用するアプリを構築するためのツール
既存のウェブサイトを活用するアプリを構築するためのいくつかのオプションがあります。 私たちが採用したアプローチは、（XcodeとAndroid Studioを使用して）各プラットフォームに固有のアプリを構築し、必要に応じてWebビューまたはネイティブビューを活用することです。
特定の機能のWebビューをロードするときは、iOSおよびAndroidが提供するWebビューライブラリを直接使用するのではなく、CordovaWebビューを統合することをお勧めします。 これにより、JavaScriptからネイティブコードへ、またはその逆に通信するためのWebからネイティブへのブリッジ、ライフサイクルイベントへのアクセス、アクセスなど、他の方法では自分で構築する必要のある多くの機能がWebビューに提供されます。豊富なCordovaプラグインに。 または、Cordovaに依存することを避けたい場合は、さまざまなプラットフォームで他のいくつかのWebからネイティブへのブリッジを利用できます。
この方法でアプリを構築するのに役立つフレームワークがいくつかあります。たとえば、SupersonicやAstroは、ネイティブインターフェースとWebインターフェースの両方を使用してアプリを構築する複雑さを管理しやすくするために構築しているネイティブアプリフレームワークです。
結論
Beyond the Rackを使用して、エクスペリエンスを犠牲にすることなくユーザーに簡単に価値を提供できるアプリの構築に着手しました。 テクノロジーを後部座席に配置し、タスクに適切なテクノロジーを使用できるようにするアプローチに従うことで、まさにそれを達成したと確信しています。 機能の変更や導入に伴い、私たちは常に自分自身に問いかけます。「ユーザーの問題を最もよく解決するために、ここでどのようなエクスペリエンスを設計したいですか？ その経験には、高度なパフォーマンスやアニメーションの使用が必要ですか？」
その質問への答えは、Webテクノロジーを使用して機能を構築し、ブラウザーやAndroidおよびiOSで再利用するか、プラットフォームごとにカスタムで構築するかを決定します。
最終的には、これがアプリの構築方法であると私は信じています。 しかし、それは考え方を変えるでしょう。 Webがネイティブに勝つか、過去の遺物になるかを判断するのではなく、両方の長所を取り入れるべきです。 それぞれの長所と短所を認識し、特定の機能に最も適したテクノロジーを使用する必要があります。