Mark Zuckerberg a spus odată: „Cea mai mare greșeală pe care am făcut-o, ca companie, este să pariem prea mult pe HTML5, spre deosebire de nativ... pentru că pur și simplu nu era acolo. Și nu este că HTML5 este rău. De fapt, pe termen lung, sunt foarte încântat de asta.” Și cine nu ar fi entuziasmat de perspectiva unei singure baze de cod care să funcționeze pe mai multe platforme ?

Citiți suplimentare despre SmashingMag:

• Un ghid pentru începători pentru aplicații web progresive
• Elementele de bază ale aplicațiilor web progresive
• Crearea unei aplicații web complete în Foundation For Apps

Din păcate, Facebook a simțit că HTML5 nu a oferit experiența pe care dorea să o construiască și despre asta este vorba cu adevărat: experiența. Cred că ceea ce Mark încerca cu adevărat să spună a fost că cea mai mare greșeală a lor a fost să ia o decizie bazată pe tehnologie în loc de o decizie bazată pe experiența utilizatorului. La sfârșitul zilei, ar trebui să luăm decizii care să ofere valoare clienților noștri , iar aderarea la o anumită tehnologie nu este, în general, cea mai bună modalitate de a realiza acest lucru.

Pentru clientul nostru Beyond the Rack, un retailer de comerț electronic doar online, obiectivul nostru principal a fost să construim o aplicație cu o experiență excelentă pentru utilizator. La fel ca și Zuckerberg, am vrut să luăm și calea HTML5 - abordarea „scrie o dată, rulează peste tot” pentru aplicațiile care sunt scrise în interfețele web HTML5 este extrem de atractivă. Dar în lumea de astăzi, în care aplicațiile devin modalitatea principală prin care utilizatorii interacționează cu produsul dvs., performanța nu este doar un lucru plăcut, ci este un avantaj competitiv.

Cu toate acestea, aproape niciodată nu se întâmplă ca toate caracteristicile aplicației dvs. să fie construite cu interfețe complet native. De exemplu, deși ar putea fi greu să faceți animațiile de navigare să pară native pe web, o pagină web care conține puțină sau deloc animație complexă ar putea fi utilizată cu ușurință în aplicație, în timp ce încă se simte nativă. Acesta este tot ceea ce contează cu adevărat pentru utilizator. Ceea ce este necesar atunci este o strategie „poate scrie o dată, poate rulează peste tot — depinde cu adevărat de caracteristică...”.

Pe scurt, nu alegeți între interfețele native și web . Folosiți ambele.

În această piesă, vă voi ghida prin experiența noastră în construirea unei aplicații pentru Beyond the Rack în care amestecăm conținut nativ și web pentru a crea o aplicație care „se simte” nativă.

Studiu de caz: Construirea unei aplicații pentru Beyond The Rack

Evident, era important să se determine ce probleme căuta Beyond the Rack să rezolve pentru sine și clienții săi cu aplicația sa. Alegerea de a merge nativ sau web pentru fiecare caracteristică ar veni firesc din asta.

Ne-am dat seama că pentru a construi o aplicație grozavă, trebuie să facem o treabă grozavă cu toate cele trei lucruri următoare:

• Interfață de cumpărături
  Beyond the Rack este un comerciant cu amănuntul exclusiv online; deci, a avea o interfață excelentă pentru a naviga în vânzări și pentru a face achiziții este crucială. Deoarece construiam o aplicație nativă, am avut ocazia să depășim ceea ce poate oferi experiența web.
• Partajare
  Deoarece un factor mare de venituri pentru Beyond the Rack este că clienții distribuie diverse articole de vânzare cu prietenii, trebuia să ne asigurăm că partajarea între iOS, Android și browser este cât mai simplă posibil.
• Descoperibilitate
  Beyond the Rack oferă utilizatorilor săi vânzări pe timp limitat; deci, a putea ajunge rapid la utilizatori este foarte important. Mesageria Push oferă cea mai bună modalitate de a angaja acești clienți loiali și, în cele din urmă, a fost cel mai mare factor în decizia de a construi aplicația.

Să vedem cum am construit unele dintre cele mai importante caracteristici ale aplicațiilor noastre Beyond the Rack pentru iOS și Android: care caracteristici ale aplicației au fost create folosind tehnologia web, care funcții sunt complet native și cum funcționează toate împreună.

Interfața de cumpărături

Biții Native

Am creat un site web receptiv pentru Beyond the Rack pe tabletă și mobil – unul de care suntem mândri. Dar nu a fost suficient să arunci pur și simplu site-ul într-o vizualizare web și să-l numești o zi; site-ul web în sine nu se simte ca o aplicație nativă. Un mare motiv pentru asta este navigarea. Într-un browser, aveți butoane înapoi și înainte și o bară de adrese URL. În aplicațiile iOS și Android, utilizatorii au așteptări foarte diferite cu privire la modul de navigare și am vrut să ne potrivim cu aceste așteptări, astfel încât aplicația noastră să se simtă în concordanță cu fiecare platformă.

Am realizat un prototip care încarcă dinamic conținut prin AJAX și gestionează navigarea și tranzițiile în limbile web, dar nu am reușit să îl facem să se simtă la fel de neted ca tranzițiile pe care le vedeți în aplicațiile native. Animațiile de navigare de pe iOS și Android sunt destul de greu de egalat folosind tehnologia web și orice deplasare în navigare ar face ca aplicația noastră să se simtă mai puțin nativă. Dacă aplicația dvs. nu rulează la 60 de cadre pe secundă, utilizatorii vor observa.

Am venit cu o abordare care credem că combină tot ce este mai bun din ambele lumi: încărcați conținutul principal de pe web, dar folosiți elemente de navigare native:

Pe iOS, implementarea acestui lucru a fost într-adevăr destul de simplă. Am folosit controlerul de navigare, care gestionează un teanc de vizualizări, precum și o bară de navigare pentru a controla navigarea între fiecare vizualizare. În cazul nostru, teancul de vizualizări este de fapt doar un teanc de vizualizări web - de fiecare dată când are loc o navigare, mai degrabă decât să navigăm la ea în vizualizarea web în sine, instanțiem o nouă vizualizare web, o împingem la UINavigationController și navigăm la noua destinatie. Utilizarea stivelor de vizualizări web înseamnă, de asemenea, că ori de câte ori utilizatorul se întoarce, nu trebuie să aștepte reîncărcarea paginii, ceea ce este grozav pentru experiența sa. Dacă în viitor decidem să înlocuim o caracteristică cu o vizualizare nativă, pur și simplu am împinge o vizualizare nativă în stivă, mai degrabă decât versiunea de vizualizare web a acelei caracteristici.

Pe Android, echivalentul controlerului de navigație ar fi utilizarea stivelor de activități. Am decis să nu folosim mai multe activități și fragmente, deoarece ambele necesită un management al ciclului de viață extrem de complex. Am ajuns să ne gestionăm propriul teanc de vizualizări web pentru aplicație și să scriem animații native personalizate pentru a trece între fiecare vizualizare.

O serie de alte aplicații folosesc elementele native de navigare pentru a se conforma modelelor de proiectare a sistemului de operare. Vedeți această imagine a aplicației pentru Android Basecamp, care folosește o bară de navigare nativă:

De asemenea, comparați aplicația Amazon cu site-ul său mobil:

Cu această abordare, am găsit punctul nostru favorabil de a avea o experiență familiară platformei , în timp ce profităm de o experiență de cumpărături de bază excelentă de pe web.

Aceasta ar putea fi o surpriză pentru mulți, dar dezvoltatorii aplicației Facebook găsesc, de asemenea, în mod constant punctul favorabil, valorificând nativ sau web atunci când are sens pentru fiecare caracteristică. Potrivit unui articol scris de un inginer Facebook: „Pentru zonele din cadrul aplicației în care anticipăm să facem modificări mai des, vom continua să folosim codul HTML5, deoarece putem împinge actualizări din partea serverului fără a solicita oamenilor să descarce o nouă versiune a aplicației. .” Se pare că Facebook adoptă aceeași abordare pentru care se susține aici: alegeți tehnologia pentru fiecare caracteristică în funcție de performanță, efortul de dezvoltare necesar și cât de repede trebuie să o scoateți pe ușă.

Pentru aplicația dvs., luați în considerare de la caz la caz dacă construirea unei funcții în mod nativ sau valorificarea conținutului web are mai mult sens. Având în vedere dificultatea de a construi o navigație care pare nativă, probabil că are sens să o construim cel puțin folosind componente native.

Web Bits

Astăzi, aproape toată lumea este de acord că este o idee bună să îmbunătățim progresiv site-urile web : utilizați o bază de markup pentru cel mai mic numitor comun al browserelor și puneți-o pe un strat cu funcționalități și îmbunătățiri folosind JavaScript și CSS, în funcție de context - fără baze de cod sau șabloane separate pentru diferite dispozitive necesare. La fel cum nu are sens să creăm șabloane separate pentru web-ul mobil și desktop, am vrut să folosim șabloanele de site live în cadrul aplicației în sine. Aplicația este doar un alt context.

Eu numesc această clădire site-uri web receptive „conștiente de aplicații” . Prin construirea site-ului nostru web ținând cont de contextul și performanța aplicației, vom fi gata să livrăm tuturor utilizatorilor noștri pe diverse platforme mai curând decât mai târziu.

Site-urile web trebuie să poată detecta contextul aplicației în trei locuri: CSS, JavaScript și server. Am creat o clasă de app pentru a scrie CSS condiționat și o metodă isRunningInApp pentru a scrie JavaScript condiționat și am atașat App la agentul utilizator pentru logica condițională pe partea serverului.

Un exemplu în care am folosit îmbunătățirea progresivă în cadrul aplicației este pe pagina noastră de afișare a produsului. L-am optimizat adăugând un buton „Adăugați în coș” cu poziție fixă ​​numai pentru aplicații:

Am fi putut adăuga și un buton „Adăugați în geantă” cu poziție fixă ​​în browser, dar nu am făcut-o pentru că, în Safari, făcând clic în partea de jos va deschide de fapt bara de navigare a Safari. Deschiderea accidentală a acestei bare atunci când utilizatorul încearcă să adauge un produs în coșul său ar fi un defect inacceptabil de utilizare, în ciuda avantajelor de a avea un buton persistent „Adăugați în coș” în partea de jos a paginii:

O altă zonă în care am făcut modificări specifice aplicației site-ului web este în coșul de cumpărături. Logica căruciorului este de obicei unul dintre cele mai complicate aspecte ale oricărui site de comerț electronic și, pentru că am fost destul de mulțumiți de experiența căruciorului de pe mobil, am decis să-l reutilizam în aplicație, deși cu un aspect și un aspect ușor modificat:

Partajare

Abilitatea de a partaja link-uri și de a deschide link-uri partajate este o caracteristică critică care trebuie să funcționeze bine pentru Beyond the Rack. Am vrut ca distribuirea să fie perfectă. Dacă cineva partajează un link de pe desktop, iar prietenul său îl deschide în aplicație, linkul trebuie să se deschidă corect; de asemenea, dacă cineva partajează un produs din aplicație, acesta trebuie să se deschidă corect pe desktop; iar dacă prietenul este pe mobil, dar nu are aplicația instalată, ar trebui să se deschidă în browser. Am fost hotărâți să facem din aceasta o experiență minunată, deoarece acesta este de obicei ceva la care aplicațiile sunt slabe.

A face conținut care poate fi partajat între web și aplicație poate fi dificil . Pentru a face acest lucru cu succes, va trebui să mapați linkurile aplicației și linkurile web. Acest lucru a fost dureros în zilele pre-responsive, când deschiderea unei adrese URL de pe desktop te ducea la pagina de pornire a unei adrese URL mobile, din cauza redirecționărilor și altele. Întâmpinăm exact aceeași problemă astăzi cu aplicațiile - bannerele din Safari și Chrome vă cer să deschideți un link într-o aplicație, doar pentru ca aplicația să nu arate ceea ce căutați, lăsându-vă să o căutați din nou. Din fericire, gestionarea linkurilor web în aplicația Beyond the Rack este ușoară, deoarece tot ce trebuie să facem este să încărcăm acea adresă URL într-o vizualizare web. Trebuie doar să ne asigurăm că linkurile web conduc utilizatorii la aplicație în loc de browser.

Pe Android, deschiderea unei adrese URL într-o aplicație este simplă. Trebuie doar să configurați un filtru de intenție pentru a încărca aplicația ori de câte ori un utilizator încearcă să încarce adresa URL specificată (în cazul nostru, www.beyondtherack.com ). Odată ce aplicația este instalată, utilizatorilor li se va oferi opțiunea de a deschide adresa URL în aplicație sau în browser:

iOS a avut un drum puțin mai dificil pentru a permite adreselor URL web să se deschidă direct în aplicații. Anterior, iOS vă permitea doar să înregistrați o schemă de aplicație pentru fiecare aplicație (de exemplu, beyondtherack:// ). Deoarece era imposibil să știm ce aplicații au fost instalate, singura opțiune a fost să deschideți un anumit link în Safari și, de acolo, să încercați să deschideți acel link în aplicație. Acest lucru a venit cu o supărare minoră: dacă aplicația nu a fost instalată, utilizatorul ar primi un mesaj de eroare enervant, „Safari nu poate deschide pagina deoarece adresa este invalidă”. Din fericire, un hack vă permite să suprimați această eroare folosind iframe. Dacă doriți să acceptați legăturile profunde pe iOS 8, aceasta este cea mai bună opțiune.

Din fericire, iOS 9 a introdus legătura universală, care permite aplicațiilor să intercepteze link-uri web înainte ca acestea să treacă prin Safari. ## Descoperibilitate Punctul în timp este extrem de important pentru o companie precum Beyond the Rack. În mod tradițional, principalul mod al companiei de a informa clienții despre vânzări era prin campanii de e-mail. Dar cu aplicații, este capabil să **comunica direct cu clienții săi despre vânzări**, ceea ce este foarte puternic. (Desigur, notificările push sosesc încet în browsere, cu [Chrome conducând taxa](https://gauntface.com/blog/2014/12/15/push-notifications-service-worker). Dar pentru dispozitivele Android mai vechi iar pentru iOS, alegerea de a folosi tehnologia nativă sau web a fost deja făcută pentru noi.) La fel ca în cazul partajării, decizia noastră de a folosi conținutul web direct în aplicație a făcut să configurați **notificări push** ușor. Deoarece fiecare produs și vânzare pot fi identificate prin aceeași adresă URL atât pe site-ul web, cât și în aplicație, educarea specialiștilor în marketing cu privire la modul de a trimite notificări către clienții lor este simplă - tot ce trebuie să facă este să partajeze aceleași adrese URL pe care sunt obișnuiți să le partajeze. în campaniile de email. O diferență interesantă între iOS și Android este **sistemul de permisiuni** pentru notificările push. Pe iOS, permisiunea pentru notificări este controlată de sistemul de operare, în timp ce permisiunea nu este necesară pe Android. Totuși, am simțit că solicitarea permisiunii este ceea ce trebuie făcut din perspectiva serviciului pentru clienți. Deci, atunci când utilizatorul se conectează pentru prima dată la aplicație, îl întrebăm dacă dorește notificări:

De asemenea, am decis să construim acele **casete de dialog de notificare** cu interfețe web. Nimic despre ele nu necesita performanță avansată, așa că construirea lor cu interfețe de utilizare web și reutilizarea lor pe platforme avea sens. Acesta este un alt exemplu de conștientizare a aplicației site-ului web: aceste casete de dialog fac parte din site, dar sunt afișate condiționat în aplicație.

Rezultate

După lansarea aplicației, am vrut să comparăm performanța acesteia cu experiența browserului. Compararea directă a analizelor lor nu a fost suficientă, deoarece, din experiența noastră, oricine a instalat aplicația era probabil un client mai loial și, prin urmare, ar fi probabil mai bine convertit. Pentru a evita tendința de selecție, am configurat un test A/B; jumătate dintre utilizatori au fost ținuți în aplicație și jumătate au fost transferați în browser, ceea ce a asigurat că singurii participanți la experiment erau utilizatorii care aveau aplicația instalată (utilizatorii mai fideli).

• Tranzacțiile per vizitator unic au fost cu 76% mai mari cu experiența aplicației decât cu web.
• Utilizatorii zilnici unici ai aplicației au avut cu 20% mai multe șanse de a face conversii .
• Utilizatorii aplicației au petrecut cu 63% mai mult timp navigând decât utilizatorii web .

Câștigări rapide de performanță

Crearea unei aplicații care încarcă conținut web și se simte nativă nu iese din cutie pe iOS sau Android. Iată câteva dintre provocările de performanță cu care ne-am confruntat și care merită împărtășite:

• Pe iOS, ritmul de defilare într-o vizualizare web nu se potrivește cu ritmul de defilare într-o vizualizare nativă de defilare. Acest lucru a fost descoperit în testarea utilizatorilor. Iată o linie pentru a rezolva asta: webview.scrollView.decelerationRate = UIScrollViewDecelerationRateNormal;
• Aveți grijă când redimensionați vizualizările web . Am întâmpinat probleme în care redimensionarea lor a cauzat revopsiri întregi, ceea ce a ucis performanța derulării pe dispozitivele mai vechi.
• A face față a sute de implementări diferite de vizualizare web pe Android poate fi dureroasă. Cea mai dureroasă problemă cu care am întâlnit este o eroare de vizualizare web cunoscută în Android 4.4.2, care generează o excepție fatală în Chromium care provoacă blocarea aplicației. Eliminarea transform: translate3d în versiunea respectivă de Android pare să facă treaba. Alternativ, puteți utiliza Crosswalk pentru a vă livra propriul timp de rulare web compilat cu aplicația dvs. (nu am făcut acest lucru, dar intenționăm să facem acest lucru pentru proiecte viitoare).
• Utilizați FastClick, nu numai pentru că elimină întârzierea de clic de 300 de milisecunde, ci și pentru că remediază o eroare a clicurilor de vizualizare web introdusă în iOS 8.4.1. Pentru noi, bug-ul s-a manifestat prin faptul că nu a permis ca pagina să se schimbe dacă clicul a fost prea lent.
• Faceți tot ce puteți pentru ca derularea să se simtă uimitoare. Puteți elimina evenimentele de defilare, puteți evita revopsirile inutile și multe altele. Dacă derularea nu rulează la 60 de cadre pe secundă, utilizatorii vor observa, chiar mai mult într-o aplicație decât pe web.
• Fă tot ce poți pentru ca paginile să se încarce în mai puțin de 1000 de milisecunde.

Instrumente pentru a construi o aplicație folosind site-ul dvs

Aveți o serie de opțiuni pentru a crea o aplicație care să folosească site-ul dvs. web existent. Abordarea pe care am adoptat-o ​​este să construim aplicația specifică fiecărei platforme (folosind Xcode și Android Studio), utilizând vizualizări web sau vizualizări native ori de câte ori este necesar.

Când încărcați o vizualizare web pentru o anumită caracteristică, vă recomandăm să integrați vizualizarea web Cordova, mai degrabă decât să utilizați direct bibliotecile de vizualizare web furnizate de iOS și Android. Acest lucru va oferi vizualizărilor dvs. web o serie de caracteristici pe care altfel ar trebui să le construiți singur, cum ar fi o punte web-nativ pentru a comunica de la JavaScript la codul nativ și invers, abilitatea de a accesa evenimentele ciclului de viață, precum și accesul la o multitudine de pluginuri Cordova. În mod alternativ, alte câteva poduri web-nativ sunt disponibile pentru diferitele platforme dacă doriți să evitați dependența de Cordova.

Există câteva cadre pentru a vă ajuta să creați aplicații în acest fel, cum ar fi Supersonic și Astro, un cadru de aplicații nativ pe care îl construim pentru a facilita gestionarea complexității creării de aplicații folosind atât interfețele native, cât și cele web.

Concluzie

Cu Beyond the Rack, ne-am propus să construim o aplicație în care să putem livra cu ușurință valoare utilizatorilor fără a sacrifica experiența. Urmând o abordare care pune tehnologia pe bancheta din spate , permițându-ne să folosim tehnologia potrivită pentru sarcină, credem că am realizat exact asta. Cu orice modificare sau introducere a unei funcții, ne vom întreba întotdeauna: „Ce experiență dorim să proiectăm aici, care va rezolva cel mai bine problema utilizatorului? Această experiență necesită utilizarea unor performanțe avansate sau animații?”

Răspunsul la această întrebare va determina dacă construim funcția cu tehnologie web și o reutilizam în browser și pe Android și iOS sau o construim personalizat pentru fiecare platformă.

În cele din urmă, cred că așa ar trebui să fie construite aplicațiile. Dar va fi nevoie de o schimbare de mentalitate. În loc să încercăm să stabilim dacă web-ul va triumfa asupra nativului sau va deveni o relicvă a trecutului, ar trebui să îmbrățișăm ce este mai bun dintre ambele. Ar trebui să recunoaștem avantajele și dezavantajele lor și să folosim tehnologia care are cel mai mult sens pentru caracteristica dată.