Aplicație web sau aplicație mobilă: alegeți prima platformă

Alegeți între o aplicație web și una mobilă după sarcina pe care utilizatorii trebuie s-o îndeplinească. O aplicație web este adesea un punct de plecare util pentru munca la care se ajunge printr-un link și care se face pe dispozitive diferite. O aplicație mobilă nativă devine un candidat mai puternic atunci când traseul principal depinde de funcții specifice ale dispozitivului sau de folosirea frecventă pe telefon. Testați cerințele înainte să vă angajați la oricare dintre ele.

„Oamenii o vor folosi pe mobil” nu ajunge ca să decideți. O aplicație web poate funcționa într-un browser de telefon. Nici „avem nevoie de acces offline” nu ajunge: comportamentul offline trebuie proiectat, iar unele aplicații web îl pot oferi. Întrebarea utilă este care abordare poate livra fluxul real de lucru, cu limite acceptabile.

Care este diferența?

O aplicație web rulează într-un browser. Utilizatorii o pot deschide, de obicei, printr-o adresă URL, iar interfața se poate adapta la telefon, tabletă sau calculator. Posibilitățile ei depind de browserele și de dispozitivele pe care alegeți să le susțineți.

O aplicație mobilă nativă este construită pentru o anumită platformă, de exemplu iOS. Se instalează pe dispozitiv și folosește convențiile de interfață și API-urile disponibile ale platformei respective. Acoperirea unei alte platforme native adaugă muncă de livrare și de verificare.

O aplicație web progresivă, sau PWA, folosește tehnologii web cu funcții suplimentare, precum instalarea și un comportament offline proiectat. Documentația MDN despre PWA (în engleză) explică aceste posibilități. Disponibilitatea și comportamentul trebuie totuși verificate pe dispozitivele vizate; „PWA” nu este o promisiune că orice funcție nativă merge peste tot.

Folosiți cerințele de mai jos ca să alegeți prima formă a produsului.

Comparați constrângerile înaintea tehnologiei

Pe un ecran îngust, derulați tabelul lateral ca să citiți toate coloanele.

Cerință	Aplicația web: ce verificați	Aplicația nativă: ce verificați
Clienții ajung printr-un link	Pot parcurge traseul în browserele susținute, fără instalare?	Este instalarea unei aplicații un pas acceptabil înainte să primească ceva de valoare?
Munca se desfășoară pe calculator și pe telefon	Aspectul și interacțiunile sunt potrivite pentru ambele?	Vor avea nevoie și utilizatorii de pe calculator de o interfață web?
O funcție a dispozitivului este esențială	API-ul necesar este disponibil și fiabil în exact browserele pe care trebuie să le susțineți?	Oferă platforma această funcție, și ce permisiuni și restricții se aplică?
Conexiunea este nesigură	Ce acțiuni merg offline și cum se sincronizează munca stocată?	Aceleași întrebări; instalarea în sine nu face ca acțiunile care depind de server să meargă offline.
Sunt necesare mai multe platforme	Verificați comportamentul pe combinațiile de browsere și dispozitive susținute.	Definiți ce acoperă fiecare platformă, plus testele, munca de lansare și mentenanța de care are nevoie.
Versiunile trebuie schimbate des	Planificați publicarea, compatibilitatea și refacerea după defecțiuni pentru modificările aduse serviciului în funcțiune.	Luați în calcul și distribuirea, verificarea de către magazin acolo unde se aplică, și utilizatorii cu versiuni mai vechi ale aplicației.

Nu tratați tabelul ca pe un scor în care câștigă cele mai multe bife. O singură funcție esențială poate determina abordarea. Mai multe preferințe nu justifică neapărat încă o formă a produsului.

Două exemple care duc la prime versiuni diferite

Un portal de aprobare pentru clienți: clienții primesc un link, parcurg documente, aprobă lucrări și uneori fac acest lucru de pe telefon. Personalul gestionează înregistrările de la birou. O aplicație web adaptabilă este un prim candidat rezonabil. Înainte să construiți o aplicație, testați dacă instalarea ar îmbunătăți deloc traseul important.

Un instrument de culegere a datelor în teren: personalul introduce informații pe parcursul zilei, în locuri cu conexiune slabă. Produsul are nevoie de comportament specific al dispozitivului, de înregistrări locale și de sincronizare ulterioară. Evaluați o aplicație nativă și o PWA în raport cu exact aceste cerințe. Un mic experiment cu funcția, pe dispozitivele reale, poate lămuri alegerea mai util decât o comparație generică de funcții.

Sunt fluxuri ipotetice, nu afirmații despre rezultate obținute pentru clienți AL+. Primul favorizează accesul ușor de pe dispozitive diferite; al doilea pune în centru comportamentul dispozitivului și al conexiunii. Niciunul nu stabilește arhitectura fiecărui produs din categoria lui.

Lucrul offline are nevoie de un comportament scris, nu de o etichetă

Descrieți ce se întâmplă înainte, în timpul și după întreruperea conexiunii:

Ce informații trebuie să fie deja pe dispozitiv?
Ce acțiuni poate îndeplini utilizatorul fără un răspuns de la server?
Cum arată interfața lucrul salvat, în așteptare, eșuat și sincronizat?
Ce se întâmplă dacă altcineva modifică aceeași înregistrare?
Ce se întâmplă când utilizatorul se deconectează, pierde dispozitivul sau revine după o întrerupere lungă?

Un ecran păstrat în memoria cache și o tranzacție de afaceri offline sunt cerințe diferite. De exemplu, afișarea unei programări încărcate anterior nu stabilește că o rezervare nouă poate fi confirmată fără a ajunge la sistemul care deține disponibilitatea.

Atât implementările native, cât și cele web cer decizii privind datele, conflictele și refacerea. Consultați documentația platformei relevante și verificați comportamentul critic, în loc să-l promiteți pornind de la numele unei tehnologii.

Partea de server este o componentă separată a deciziei

O aplicație instalată poate depinde în continuare de conturi, de înregistrări comune, de plăți, de notificări și de instrumente administrative care rulează în altă parte. O aplicație web poate avea nevoie de aceleași servicii.

Pentru oricare abordare, stabiliți ce parte de server există deja, cine o controlează, ce interfețe sunt disponibile și ce trebuie construit. Mutarea interfeței pe telefon nu rezolvă o integrare nesigură sau o proprietate neclară asupra datelor.

Includeți fluxul administrativ. Dacă cineva trebuie să corecteze o înregistrare sau să ajute un client, decideți cum o va face. O experiență mobilă pentru client și o interfață web de administrare pot fi forme diferite ale aceluiași produs, dar ambele intră în proiect.

Comparați estimări pentru versiuni complete

Cereți fiecărei propuneri să separe munca de produs comună de munca pentru fiecare platformă:

Comportament comun: regulile de afaceri, datele, accesul, integrările și operarea serverului.
Interfața: traseele utilizatorilor și aspectul pentru fiecare formă susținută.
Verificarea: dispozitivele, browserele, permisiunile și cazurile de eșec care vor fi verificate.
Lansarea: publicarea sau trimiterea către magazin, accesul la conturi, informațiile de suport și refacerea după defecțiuni.
Mentenanța: modificări de compatibilitate, corecții, versiuni noi și costurile continue ale furnizorilor.

Nu există un procent universal fiabil cu care o abordare să fie mai ieftină decât cealaltă. O parte de server existentă, o funcție necesară a dispozitivului sau o a doua interfață pot schimba comparația. Comparați aceeași versiune utilă, nu două numere de ecrane sau tarife orare.

Ghidul nostru despre costul unei aplicații mobile (în engleză) explică munca dintr-o estimare pentru o aplicație iOS nativă. Este o listă de verificare pentru funcționalități, nu o promisiune de preț standard pentru proiect.

Un brief pentru decizia privind platforma

Scrieți aceste șase rânduri înainte să cereți unui dezvoltator să aleagă tehnologia:

Traseul principal: ce trebuie să parcurgă un utilizator de la început până la rezultat.
Utilizatori și dispozitive: cine îl folosește, unde, cât de des și pe ce dispozitive.
Funcții esențiale: comportamentul exact al dispozitivului sau integrările de care depinde traseul.
Comportamentul conexiunii: ce trebuie să se întâmple când rețeaua nu este disponibilă.
Sisteme existente: partea de server, datele, conturile și interfețele deja disponibile.
Limitele primei versiuni: platformele susținute, excluderile, limitele de buget și motivul oricărei date fixe.

Dacă o funcție ar putea schimba decizia, cereți o verificare tehnică țintită înainte de construirea completă. Dacă incertitudinea ține de modul în care oamenii folosesc interfața, un prototip poate fi primul pas potrivit.

Discutați fluxul de lucru înainte de a alege platforma

AL+ construiește aplicații web la comandă și aplicații native pentru iPhone și iPad, cu responsabilitate pentru serviciile conectate și pentru mentenanță după lansare. Putem discuta prima platformă pornind de la sarcină, de la dispozitivele vizate și de la sistemul existent.

Scrieți-ne despre proiectul dumneavoastră web sau iOS. Trimiteți brieful de șase rânduri, ca discuția să înceapă de la cerințele care determină munca.