Mark Zuckerberg pernah berkata, “Kesalahan terbesar yang kami buat, sebagai sebuah perusahaan, adalah bertaruh terlalu banyak pada HTML5 dibandingkan dengan yang asli… karena itu tidak ada. Dan bukan karena HTML5 itu buruk. Saya sebenarnya, dalam jangka panjang, sangat bersemangat tentang hal itu.” Dan siapa yang tidak senang dengan prospek basis kode tunggal yang bekerja di berbagai platform ?

Bacaan Lebih Lanjut tentang SmashingMag:

• Panduan Pemula Untuk Aplikasi Web Progresif
• Blok Bangunan Aplikasi Web Progresif
• Membuat Aplikasi Web Lengkap Sebagai Dasar Untuk Aplikasi

Sayangnya, Facebook merasa bahwa HTML5 tidak menawarkan pengalaman yang ingin dibangunnya, dan itulah yang sebenarnya terjadi: pengalaman. Saya percaya apa yang sebenarnya ingin dikatakan Mark adalah bahwa kesalahan terbesar mereka adalah membuat keputusan yang didorong oleh teknologi, bukan keputusan yang didorong oleh pengalaman pengguna. Pada akhirnya, kita harus membuat keputusan yang memberikan nilai kepada pelanggan kita , dan berpegang teguh pada teknologi tertentu umumnya bukan cara terbaik untuk mencapainya.

Untuk klien kami Beyond the Rack, pengecer e-niaga khusus online, tujuan utama kami adalah membangun aplikasi dengan pengalaman pengguna yang luar biasa. Seperti Zuckerberg, kami juga ingin mengambil rute HTML5 — pendekatan “tulis sekali, jalankan di mana saja” untuk aplikasi yang ditulis dalam antarmuka web HTML5 sangat menarik. Namun di dunia sekarang ini, di mana aplikasi menjadi cara utama pengguna berinteraksi dengan produk Anda, kinerja tidak hanya bagus untuk dimiliki — ini adalah keunggulan kompetitif.

Namun, hampir tidak pernah terjadi bahwa semua fitur aplikasi Anda perlu dibangun dengan antarmuka yang sepenuhnya asli. Misalnya, meskipun mungkin sulit untuk membuat animasi navigasi terasa asli di web, halaman web yang berisi sedikit atau tanpa animasi kompleks dapat dengan mudah digunakan di aplikasi sambil tetap terasa asli. Ini semua yang benar-benar penting bagi pengguna. Apa yang diperlukan kemudian adalah "mungkin menulis sekali, mungkin berjalan di mana-mana — itu benar-benar tergantung pada fitur ..." strategi.

Singkatnya, jangan memilih antara antarmuka asli dan web . Gunakan keduanya.

Dalam bagian ini, saya akan memandu Anda melalui pengalaman kami dalam membangun aplikasi untuk Beyond the Rack di mana kami menggabungkan konten asli dan web untuk membuat aplikasi yang "terasa" asli.

Studi Kasus: Membangun Aplikasi Untuk Beyond The Rack

Jelas penting untuk menentukan masalah apa yang ingin dipecahkan Beyond the Rack untuk dirinya sendiri dan pelanggannya dengan aplikasinya. Pilihan apakah akan menjadi asli atau web untuk setiap fitur akan datang secara alami dari itu.

Kami menyadari bahwa untuk membangun aplikasi yang hebat, kami perlu melakukan pekerjaan yang hebat dengan ketiga hal berikut:

• Antarmuka belanja
  Beyond the Rack adalah pengecer online saja; jadi, memiliki antarmuka yang bagus untuk menelusuri penjualan dan melakukan pembelian sangat penting. Karena kami sedang membangun aplikasi asli, kami memiliki kesempatan untuk melampaui apa yang dapat ditawarkan oleh pengalaman web.
• Dapat dibagikan
  Karena pendorong pendapatan besar untuk Beyond the Rack adalah pelanggan yang berbagi berbagai item penjualan dengan teman, kami perlu memastikan bahwa berbagi antara iOS, Android, dan browser semulus mungkin.
• Dapat ditemukan
  Beyond the Rack memberikan penjualan waktu terbatas kepada penggunanya; jadi, dapat menjangkau pengguna dengan cepat sangat penting. Pesan push menawarkan cara terbaik untuk melibatkan pelanggan setia tersebut, dan pada akhirnya menjadi pendorong terbesar dalam keputusan untuk membangun aplikasi.

Mari selami cara kami membangun beberapa fitur terpenting dari aplikasi Beyond the Rack iOS dan Android kami: fitur aplikasi mana yang dibuat menggunakan teknologi web, fitur mana yang sepenuhnya asli, dan bagaimana semuanya bekerja bersama.

Antarmuka Belanja

Bit Asli

Kami telah membangun situs web responsif untuk Beyond the Rack di tablet dan seluler — situs yang kami banggakan. Tapi itu tidak cukup untuk hanya melemparkan situs web ke tampilan web dan menyebutnya sehari; situs web itu sendiri tidak terasa seperti aplikasi asli. Alasan besar untuk itu adalah navigasi. Di browser, Anda memiliki tombol mundur dan maju serta bilah URL. Di aplikasi iOS dan Android, pengguna memiliki ekspektasi yang sangat berbeda tentang cara bernavigasi, dan kami ingin mencocokkan ekspektasi tersebut sehingga aplikasi kami terasa konsisten dengan setiap platform.

Kami membuat prototipe yang memuat konten secara dinamis melalui AJAX dan mengelola navigasi dan transisi dalam bahasa web, tetapi kami tidak dapat membuatnya terasa sehalus sutra seperti transisi yang Anda lihat di aplikasi asli. Animasi navigasi di iOS dan Android cukup sulit untuk dicocokkan menggunakan teknologi web, dan setiap jank dalam navigasi akan membuat aplikasi kita terasa kurang asli. Jika aplikasi Anda tidak berjalan pada 60 frame per detik, pengguna akan menyadarinya.

Kami datang dengan pendekatan yang kami rasa menggabungkan yang terbaik dari kedua dunia: memuat konten utama dari web, tetapi menggunakan elemen navigasi asli:

Di iOS, menerapkan ini sangat sederhana. Kami memanfaatkan pengontrol navigasi, yang mengelola tumpukan tampilan, serta bilah navigasi untuk mengontrol navigasi di antara setiap tampilan. Dalam kasus kami, tumpukan tampilan benar-benar hanya tumpukan tampilan web — setiap kali navigasi terjadi, daripada menavigasi ke tampilan web itu sendiri, kami membuat instance tampilan web baru, mendorongnya ke UINavigationController kami dan menavigasi ke tujuan baru. Menggunakan tumpukan tampilan web juga berarti bahwa setiap kali pengguna kembali, mereka tidak perlu menunggu halaman dimuat ulang, yang sangat bagus untuk pengalaman mereka. Jika di masa mendatang kami memutuskan untuk mengganti fitur dengan tampilan asli, kami hanya akan mendorong tampilan asli ke tumpukan, daripada versi tampilan web dari fitur itu.

Di Android, yang setara dengan pengontrol navigasi adalah menggunakan tumpukan aktivitas. Kami memutuskan untuk tidak menggunakan banyak aktivitas dan fragmen, karena keduanya memerlukan manajemen siklus hidup yang sangat kompleks. Kami akhirnya mengelola tumpukan tampilan web kami sendiri untuk aplikasi dan menulis animasi asli khusus untuk transisi di antara setiap tampilan.

Sejumlah aplikasi lain memanfaatkan elemen navigasi asli agar sesuai dengan pola desain OS. Lihat gambar aplikasi Android Basecamp ini, yang memanfaatkan bilah navigasi asli:

Juga, bandingkan aplikasi Amazon dengan situs web selulernya:

Dengan pendekatan ini, kami menemukan sweet spot kami memiliki pengalaman yang terasa akrab dengan platform , sambil tetap memanfaatkan pengalaman belanja inti yang hebat dari web.

Ini mungkin mengejutkan bagi banyak orang, tetapi pengembang aplikasi Facebook juga terus-menerus menemukan sweet spot, memanfaatkan asli atau web ketika masuk akal untuk setiap fitur. Menurut sebuah artikel yang ditulis oleh seorang insinyur Facebook: “Untuk area dalam aplikasi di mana kami mengantisipasi membuat perubahan lebih sering, kami akan terus menggunakan kode HTML5, karena kami dapat mendorong pembaruan sisi server tanpa mengharuskan orang untuk mengunduh versi baru aplikasi. .” Sepertinya Facebook mengambil pendekatan yang sama seperti yang dianjurkan di sini: Pilih teknologi untuk setiap fitur berdasarkan kinerja, upaya pengembangan yang diperlukan, dan seberapa cepat Anda perlu mengeluarkannya dari pintu.

Untuk aplikasi Anda, pertimbangkan kasus per kasus apakah membangun fitur secara native atau memanfaatkan konten web lebih masuk akal. Mengingat sulitnya membangun navigasi yang terasa asli, mungkin masuk akal untuk setidaknya membangunnya menggunakan komponen asli.

Bit Web

Saat ini, hampir semua orang setuju bahwa adalah ide yang baik untuk meningkatkan situs web secara progresif : Gunakan satu basis markup untuk penyebut umum peramban terendah, dan lapisi dengan fungsionalitas dan penyempurnaan menggunakan JavaScript dan CSS, tergantung pada konteksnya — tidak ada basis kode atau template yang terpisah untuk perangkat yang berbeda diperlukan. Sama seperti tidak masuk akal untuk membuat template terpisah untuk web seluler dan desktop, kami ingin menggunakan template situs web langsung di dalam aplikasi itu sendiri. Aplikasi ini hanyalah konteks lain.

Saya menyebut bangunan ini sebagai situs web responsif "sadar aplikasi" . Dengan membangun situs web kami dengan mempertimbangkan konteks dan kinerja aplikasi, kami akan siap mengirim ke semua pengguna kami di berbagai platform lebih cepat daripada nanti.

Situs web harus dapat mendeteksi konteks aplikasi di tiga tempat: CSS, JavaScript, dan server. Kami membuat kelas app untuk menulis CSS bersyarat dan metode isRunningInApp untuk menulis JavaScript bersyarat, dan kami menambahkan App ke agen pengguna untuk logika sisi server bersyarat.

Contoh di mana kami menggunakan peningkatan progresif dalam aplikasi ada di halaman tampilan produk kami. Kami mengoptimalkannya dengan menambahkan tombol "Tambahkan ke troli" dengan posisi tetap hanya untuk aplikasi:

Kami juga dapat menambahkan tombol "Tambahkan ke tas" dengan posisi tetap di browser, tetapi kami tidak melakukannya karena, di Safari, mengklik di dekat bagian bawah akan benar-benar membuka bilah navigasi Safari. Membiarkan bilah ini terbuka secara tidak sengaja saat pengguna mencoba menambahkan produk ke troli mereka akan menjadi kelemahan kegunaan yang tidak dapat diterima, meskipun ada keuntungan memiliki tombol “Tambahkan ke troli” yang terus-menerus di bagian bawah halaman:

Area lain tempat kami membuat penyesuaian khusus aplikasi ke situs web ada di keranjang belanja. Logika keranjang biasanya merupakan salah satu aspek tersulit dari situs web e-niaga mana pun, dan karena kami cukup senang dengan pengalaman keranjang belanja di seluler, kami memutuskan untuk menggunakannya kembali di aplikasi, meskipun dengan tampilan dan nuansa yang sedikit dimodifikasi:

Dapat dibagikan

Kemampuan untuk membagikan tautan dan membuka tautan bersama adalah fitur penting yang harus berfungsi dengan baik untuk Beyond the Rack. Kami ingin berbagi menjadi mulus. Jika seseorang membagikan tautan dari desktop mereka, dan teman mereka membukanya di aplikasi, tautan tersebut harus dibuka dengan benar; demikian juga, jika seseorang membagikan produk dari aplikasi, produk tersebut harus dibuka dengan benar di desktop; dan jika teman menggunakan ponsel tetapi tidak menginstal aplikasi, itu harus terbuka di browser. Kami bertekad untuk menjadikan ini pengalaman yang luar biasa karena ini biasanya merupakan kelemahan aplikasi.

Membuat konten yang dapat dibagikan antara web dan aplikasi bisa jadi sulit . Agar berhasil melakukannya, Anda harus memetakan tautan aplikasi dan tautan web Anda. Ini menyakitkan di hari-hari pra-responsif, ketika membuka URL desktop akan membawa Anda ke halaman beranda URL seluler, karena pengalihan dan semacamnya. Kami melihat masalah yang sama persis hari ini dengan aplikasi — spanduk di Safari dan Chrome meminta Anda untuk membuka tautan di aplikasi, hanya agar aplikasi tidak menampilkan apa yang Anda cari, membuat Anda harus mencarinya lagi. Untungnya, menangani tautan web di aplikasi Beyond the Rack sangat mudah, karena yang perlu kita lakukan hanyalah memuat URL itu dalam tampilan web. Kami hanya perlu memastikan bahwa tautan web membawa pengguna ke aplikasi, bukan browser.

Di Android, membuka URL di aplikasi itu sederhana. Anda hanya perlu menyiapkan filter maksud untuk memuat aplikasi setiap kali pengguna mencoba memuat URL yang ditentukan (dalam kasus kami, www.beyondtherack.com ). Setelah aplikasi diinstal, pengguna akan diberikan opsi untuk membuka URL di aplikasi atau di browser:

iOS memiliki jalan yang sedikit lebih sulit untuk memungkinkan URL web dibuka langsung di aplikasi. Sebelumnya, iOS hanya mengizinkan Anda mendaftarkan skema aplikasi untuk setiap aplikasi (misalnya, beyondtherack:// ). Karena tidak mungkin mengetahui aplikasi mana yang diinstal, satu-satunya pilihan adalah membuka tautan yang diberikan di Safari dan, dari sana, mencoba membuka tautan itu di aplikasi. Ini datang dengan sedikit gangguan: Jika aplikasi tidak diinstal, pengguna akan mendapatkan pesan kesalahan yang mengganggu, "Safari tidak dapat membuka halaman karena alamatnya tidak valid." Untungnya, peretasan memungkinkan Anda untuk menekan kesalahan itu menggunakan iframe. Jika Anda ingin mendukung tautan dalam di iOS 8, ini adalah opsi terbaik.

Untungnya, iOS 9 memperkenalkan tautan universal, yang memungkinkan aplikasi mencegat tautan web sebelum tautan melalui Safari. ## Dapat Ditemukan Ketepatan waktu sangat penting bagi perusahaan seperti Beyond the Rack. Secara tradisional, cara utama perusahaan untuk menginformasikan kepada pelanggan tentang penjualan adalah melalui kampanye email. Namun dengan aplikasi, ia dapat **berkomunikasi langsung dengan pelanggannya tentang penjualan**, yang sangat hebat. (Tentu saja, pemberitahuan push perlahan-lahan tiba di browser, dengan [Chrome memimpin biaya](https://gautface.com/blog/2014/12/15/push-notifications-service-worker). Tetapi untuk perangkat Android yang lebih lama dan untuk iOS, pilihan apakah akan menggunakan teknologi asli atau web sudah dibuat untuk kami.) Sama seperti berbagi, keputusan kami untuk memanfaatkan konten web secara langsung di aplikasi membuatnya mudah untuk menyiapkan **pemberitahuan push**. Karena setiap produk dan penjualan dapat diidentifikasi dengan URL yang sama baik di situs web maupun di aplikasi, mendidik pemasar tentang cara mengirimkan pemberitahuan kepada pelanggan mereka sangatlah mudah — yang perlu mereka lakukan hanyalah membagikan URL yang sama yang biasa mereka bagikan dalam kampanye email. Satu perbedaan menarik antara iOS dan Android adalah **sistem izin** untuk notifikasi push. Di iOS, izin untuk notifikasi dikendalikan oleh sistem operasi, sedangkan izin tidak diperlukan di Android. Namun, kami merasa bahwa meminta izin adalah hal yang benar untuk dilakukan dari perspektif layanan pelanggan. Jadi, saat pengguna masuk ke aplikasi untuk pertama kalinya, kami menanyakan apakah mereka menginginkan notifikasi:

Kami juga memutuskan untuk membuat **kotak dialog notifikasi** tersebut dengan antarmuka web. Tidak ada yang membutuhkan kinerja tingkat lanjut, jadi membangunnya dengan UI web dan menggunakannya kembali di seluruh platform masuk akal. Ini adalah contoh lain untuk membuat situs web sadar aplikasi: Kotak dialog ini adalah bagian dari situs web tetapi ditampilkan secara kondisional di aplikasi.

Hasil

Setelah rilis aplikasi, kami ingin membandingkan kinerjanya dengan pengalaman browser. Membandingkan analitik mereka secara langsung tidak cukup, karena menurut pengalaman kami, siapa pun yang telah menginstal aplikasi kemungkinan besar adalah pelanggan yang lebih setia dan, dengan demikian, kemungkinan besar akan berkonversi lebih baik. Untuk menghindari bias pemilihan, kami menyiapkan pengujian A/B; setengah dari pengguna disimpan di aplikasi dan setengahnya ditendang ke browser, yang memastikan bahwa satu-satunya peserta dalam eksperimen adalah pengguna yang menginstal aplikasi (pengguna yang lebih setia).

• Transaksi per pengunjung unik 76% lebih tinggi dengan pengalaman aplikasi dibandingkan dengan web.
• Pengguna aplikasi harian yang unik 20% lebih mungkin untuk berkonversi .
• Pengguna aplikasi menghabiskan 63% lebih banyak waktu untuk menjelajah daripada pengguna web .

Performa Cepat Menang

Membuat aplikasi yang memuat konten web dan terasa asli tidak keluar dari kotak di iOS atau Android. Berikut adalah beberapa tantangan kinerja yang kami hadapi yang layak dibagikan:

• Di iOS, momentum pengguliran dalam tampilan web tidak cocok dengan momentum pengguliran dalam tampilan gulir asli. Ini terungkap dalam pengujian pengguna. Berikut adalah satu liner untuk menyelesaikannya: webview.scrollView.decelerationRate = UIScrollViewDecelerationRateNormal;
• Berhati-hatilah saat mengubah ukuran tampilan web . Kami mengalami masalah ketika mengubah ukurannya menyebabkan seluruh pengecatan ulang, yang mematikan kinerja gulir pada perangkat yang lebih lama.
• Berurusan dengan ratusan implementasi tampilan web yang berbeda di Android bisa jadi menyakitkan. Masalah paling menyakitkan yang kami alami adalah bug tampilan web yang diketahui di Android 4.4.2, yang menimbulkan pengecualian fatal di Chromium yang menyebabkan aplikasi mogok. Menghapus transform: translate3d dalam versi Android itu tampaknya berhasil. Atau, Anda dapat menggunakan Crosswalk untuk mengirimkan runtime web terkompilasi Anda sendiri dengan aplikasi Anda (kami tidak melakukan ini, tetapi kami berencana untuk proyek mendatang).
• Gunakan FastClick, bukan hanya karena menghilangkan penundaan klik 300 milidetik, tetapi juga karena memperbaiki bug klik tampilan web yang diperkenalkan di iOS 8.4.1. Bagi kami, bug memanifestasikan dirinya dengan tidak membiarkan halaman berubah jika kliknya terlalu lambat.
• Lakukan semua yang Anda bisa untuk membuat pengguliran terasa luar biasa. Anda dapat mendebounce acara gulir, menghindari pengecatan ulang yang tidak perlu, dan banyak lagi. Jika pengguliran tidak berjalan pada 60 frame per detik, pengguna akan melihat, terlebih lagi di aplikasi daripada di web.
• Lakukan semua yang Anda bisa untuk membuat halaman dimuat dalam waktu kurang dari 1000 milidetik.

Alat Untuk Membangun Aplikasi yang Memanfaatkan Situs Web Anda

Anda memiliki sejumlah opsi untuk membangun aplikasi yang memanfaatkan situs web Anda yang ada. Pendekatan yang kami ambil adalah membangun aplikasi khusus untuk setiap platform (menggunakan Xcode dan Android Studio), memanfaatkan tampilan web atau tampilan asli bila diperlukan.

Saat memuat tampilan web untuk fitur tertentu, sebaiknya integrasikan tampilan web Cordova, daripada langsung menggunakan pustaka tampilan web yang disediakan oleh iOS dan Android. Ini akan memberikan tampilan web Anda sejumlah fitur yang seharusnya Anda buat sendiri, seperti jembatan web-ke-asli untuk berkomunikasi dari JavaScript ke kode asli dan sebaliknya, kemampuan untuk mengakses peristiwa siklus hidup, serta akses untuk banyak plugin Cordova. Atau, beberapa jembatan web-ke-asli lainnya tersedia untuk berbagai platform jika Anda ingin menghindari ketergantungan pada Cordova.

Beberapa kerangka kerja tersedia untuk membantu Anda membuat aplikasi dengan cara ini, seperti Supersonic dan Astro, kerangka kerja aplikasi asli yang kami buat untuk mempermudah mengelola kerumitan pembuatan aplikasi menggunakan antarmuka asli dan web.

Kesimpulan

Dengan Beyond the Rack, kami mulai membangun aplikasi di mana kami dapat dengan mudah mengirimkan nilai kepada pengguna tanpa mengorbankan pengalaman. Dengan mengikuti pendekatan yang menempatkan teknologi di kursi belakang , memungkinkan kami menggunakan teknologi yang tepat untuk tugas tersebut, kami yakin kami telah mencapai hal itu. Dengan perubahan atau pengenalan fitur apa pun, kami akan selalu bertanya pada diri sendiri, “Pengalaman apa yang ingin kami rancang di sini yang akan menyelesaikan masalah pengguna dengan paling baik? Apakah pengalaman itu memerlukan penggunaan kinerja atau animasi tingkat lanjut?”

Jawaban atas pertanyaan itu akan menentukan apakah kami membangun fitur dengan teknologi web dan menggunakannya kembali di browser dan di Android dan iOS atau membuatnya khusus untuk setiap platform.

Pada akhirnya, saya percaya bahwa ini adalah bagaimana aplikasi harus dibangun. Tapi itu akan mengubah pola pikir. Alih-alih mencoba menentukan apakah web akan menang atas asli atau menjadi peninggalan masa lalu, kita harus merangkul yang terbaik dari keduanya. Kita harus mengenali kelebihan dan kekurangan masing-masing dan menggunakan teknologi yang paling masuk akal untuk fitur yang diberikan.