Background: a short case study
A major telecom was looking for a quick, innovative way to increase POS sales stations in their brick and mortar retail locations. 同社はAppleのiPhoneを取り上げたばかりで、ブラックフライデーが間近に迫っていました。 この企業は、来店客数の増加を予測し、技術チームに解決策を求めました。 9484>
すべての場所に新しい POS ステーションを設置するには、十分な時間がないことが分かっていました。 そのために、私たちは本当のロジスティクスの悪夢を話しているのです。 ハードウェアの調達、新しいネットワークの配線、新しいワークステーションのための机のスペースの確保、そして何千もの小売店の一つ一つの認証が必要だったでしょう。 なるほど。 プラン B」に進みます。
Sales Leadership チームに Samsung タブレットを導入するパイロット プログラムを開始して数か月が経過した頃、同社は機会を見出しました。 タブレット上に配置されたモバイル POS ステーションです。 当時は必ずしも斬新なアプローチではありませんでしたが、いくつかの技術的および概念的なハードルを飛び越える必要があることは確かです。 プレイヤーは誰か？
これらはすべて、モビリティ プログラムについてブレインストーミングを行い、明確に文書化することが重要です。 しかし、最終的に Apple iOS デバイスを配備することを決定した同社の原動力となったいくつかの要因について、私は言及したいと思います。 これらのタブレットは、日常的にリアルタイムの PCI データを処理することになるため、セキュリティが主な懸念事項でした。 また、確立された調達チャネルも重要でした。 Appleは信頼できるいくつかの販売代理店と連携しており、調達、プロビジョニング、配送をスムーズに行うことができます。 そして最後に、エンタープライズ・アプリケーションを管理・展開する技術チームの能力です。 ここでは、ウェブビューとハイブリッドアプリ環境が活躍しました。
彼らはすでに「モバイル ファースト」アプリケーションを開発していなかったため、同社は UI Webview を活用したソリューションを導入し、ネイティブ アプリケーション (Kronos、Workday、およびその他のサード パーティ製アプリケーション) と一緒に Web アプリケーション (ほとんどのエンタープライズ決済および請求アプリケーション) をデプロイすることにしました。 Webviewのアプローチにより、チームはエンドユーザー向けに一元化されたワンストップショップのエクスペリエンスを開発することができました。 モバイルアイアンのようなモバイルデバイス管理（MDM）ソリューションと組み合わせることで、ウェブビューはコンテナ化され、ネイティブアプリとしてユーザーにプッシュされるようになりました。 バックエンドの詳細な設定を除けば、機能的なモバイルPOSソリューションが完成したのです。
Webview: defined
WebView アプリは、主に Javascript、CSS、および HTML ファイルで構成されます。 基本的に、アプリは 1 つまたは複数の Web ページです。 これらの Web ページは、フロントエンド インターフェイスを構成します。 WebView」は、デバイスがこれらの Web ページを表示するウィンドウです。
(Human Element – Webview strategy for iOs and Android より)
従来のブラウザの代わりに WebView を表示します。 iOS の場合、WK WebView は、Safari のユーザー エクスペリエンスを再現するのに十分な働きをしてくれます。 ただし、開発中に個別に対処する必要がある、標準的なブラウザの機能には制限があります。 たとえば、戻るボタン、AirPrint、および iOS 周辺機器へのアクセスなど、これらはすべて WK Webview の上で実行され、より Safari に近いデプロイメントを可能にする必要があります。 Web アプリのスイートを展開し、それらをネイティブ アプリのエクスペリエンスのような形でパッケージ化することができます。 また、ユーザーにすでに配備されている既存のネイティブ アプリに「リンクスルー」したい場合も、それが可能です。
当社の新しい WebView ソリューションと統合するための開発標準は誰が定義しているのでしょうか。 誰が何を所有し、誰に責任があるのかを答えることは、必ずしも明確ではありません…
興味深いのは、アプリのエクスペリエンスが終わり、WebView のエクスペリエンスが始まるところです。 エンタープライズ開発環境では、これは物事が不明瞭になるところです。 誰が何を所有し、誰に責任があるかに答えることは、常に明確ではありません。 多くの「リーンIT」企業では、DEVショップの多くがベンダーに管理されていることは言うまでもありません。 その関係をどのように管理すればよいのでしょうか？ 新しいWebViewソリューションと統合するための開発標準は誰が定義するのでしょうか？
WebView は「モバイル ファースト」への旅の途中である
理想的な世界では、すべての企業アプリにネイティブ アプリケーションを展開することでしょう。 ユーザー エクスペリエンスを簡単に制御し、リリースの影響を管理することができます。 iOS のリリースのベータ テストでさえも簡素化されます。 モバイル ファースト戦略のビジョン ステートメントを持っているかもしれません。 しかし、Vision 2020 や Digital Transformation 戦略のように、最初にロードマップを構築し、後で実装します。
Webview はモバイル ファーストのロードマップの一部を担うべきであり、おそらく担うことになるでしょう。 しかし、完全なモバイル化を行うと、WebView で享受していた優美さと柔軟性が失われることを忘れないでください。 1 つには、モバイル OS を無視できなくなることが挙げられます。 上記の会社のように iPad にデプロイする場合、Apple と iOS 開発に専念する必要があります。 Android デバイスをスコープに入れるという話を聞いたのですが？ Android に行くことは、iOS からまったく新しい世界なので、おそらくそのことに同期すべきです……その計画には多くの質問があります…
それは、人材を獲得し、開発ツールを調達し、自分の考えを iOS 構造と一致させるということです。 ほとんどの場合、これはリソース集約型の計画です。
今投資するか、後で投資するかは別として、ハイブリッド アプリ開発の利点により、チームは新しく興味深いユースケースを提供できるようになるでしょう。 WK Webview とその前身である UI Webview は、ブラックフライデーを節約するソリューションとして説得力のあるケースを提供したと思います。 投資した技術で、本当のリターンはユーザーによる採用から生まれます。 それは、Apple UI Class ではなく、ビジネス次第なのです
。