ABONAMENTE VIDEO REDACȚIA
RO
EN
×
▼ LISTĂ EDIȚII ▼
Numărul 23
Abonament PDF

Livrarea aplicațiilor mobile de succes

Larisa Gota
QA Engineer
@Small Footprint
PROGRAMARE


M-am gândit în ultima vreme la ceea ce înseamnă să creezi/livrezi o aplicație pentru dispozitive mobile de succes. Competiția pe piața din ziua de azi e atât de acerbă, încât trebuie să creezi nu mai puțin decât cea mai bună aplicație posibilă pentru a rămâne "în joc". Sunt inginer SQA în lumea mobile de patru ani, deci pentru mine a livra o aplicație bună e cu adevarat foarte important.

Nu cred că mai există aplicații de succes pe web care să nu fi fost portate pe mobil. Din 2011, când platforma mobilă a ajuns într-un punct critic, e într-o continuă creștere. Doar pentru a vă da un exemplu, anul trecut numărul de utilizatori ai aplicației Facebook pe dispozitive mobile a crescut peste numărul de utilizatori activi de web. Nu cred că mai e nevoie să detaliez această știre; cu siguranță toată lumea a aflat asta până acum.

Ce este o aplicaţie de succes?

Pentru mine, ca utilizator, o aplicaţie de succes trebuie să fie utilă, să încânte, să fie uşor de folosit şi, bineînţeles, să fie în topul celor mai bine clasate aplicaţii de pe piaţă. În calitatea mea de QA, aplicaţiile de succes sunt cele care încântă printr-un design plăcut, care au o performanţă bună (rapidă, fluentă) şi nu au bug-uri (pe cât posibil).

Crearea de aplicații utile, inovatoare nu e tocmai o știință exactă și e chiar imposibil de anticipat ce idee v-ar putea aduce faimă, succes și mulți bani. Atât aplicațiile foarte utile, cât și cele create din hobby, sau create pentru cineva care dorește să-şi "piardă" timpul, pot ajunge să fie de mare succes și să fie descărcate de mii de utilizatori. Există o mulțime de exemple de persoane care au căutat succesul și l-au găsit, însă există și persoane care au creat prima aplicație din viața lor, din pasiune sau doar pentru a-și dovedi lor înșiși că sunt în stare s-o creeze. Un exemplu foarte popular este "Angry Birds", care a devenit un fenomen. Astăzi găsim aplicaţia pe toate platformele (fie mobile, fie web), filme, jocuri etc. .

Foarte populare în zilele noastre sunt jocurile care ajută utilizatorul "să piardă" vremea într-un mod plăcut, aşa cum este "Candy Crush Saga", un joc de care lumea e încă obsedată. Există poveşti cu un sfârşit fericit, pentru dezvolatori precum cei care au creat "Threes", "Luckiest Wheel" sau popularul "2048", oameni care nu au anticipat succesul aplicaţiilor lor; există însă şi oameni ce nu au putut face faţă presiunii. Probabil cel mai elocvent exemplu este "Flappy Bird". Dacă nu aţi reuşit până acum să vă jucaţi acest joc (originalul), acum e cam târziu. Dezvoltatorul lui (Dong Nguyen) l-a retras atât din App Store cât şi din Google Play, motivând că viaţa i s-a complicat mult prea tare. El a susţinut că a ajuns să câştige până la 50.000$/zi numai din reclame de tip "in-app". Intenţionat sau nu, anunţul său (cu privire la retragerea jocului ) a devenit ceva ce poate fi considerat cel mai ingenios act de marketing din istoria magazinelor virtuale de aplicaţii mobile, întrucât numărul lui de descărcări a explodat după postarea anunţului pe site-urile de socializare. Se găsesc însă acum o grămadă de cópii ale acestei aplicaţii pe toate platformele, fiecare încercând să egaleze succesul originalului.

De unde începem?

Dacă sunteți programatori/ QA implicați într-un proiect, atunci presupun că detaliile aplicației, schițele, cerințele și specificațiile vă sunt deja cunoscute și astfel aveți deja un avantaj. În caz contrar, citiți în continuare câteva principii simple, menite a vă ajuta să începeți:

  • O aplicație pentru dispozitive mobile inteligente trebuie să rezolve o problemă, fie că e o aplicație foarte utilă sau e doar un joc.
  • Concentrați-vă pe un singur lucru, dar faceți-l bine. Fiți clari cu privire la ceea ce face aplicația; ar trebui să fie capabilă a se rezuma ca "one-liner".
  • Măsurați-vă propriile abilități și interese pentru a rezolva o problemă de zi cu zi și a o face mai bine, sau cu o mică diferență. Există o mulțime de aplicații create până acum. Nu pierdeți efort și timp clonând ceva ce există deja. Aceasta nu înseamnă desigur că nu puteți îmbunătăți o aplicație deja creată, dar urmăriți să găsiți o nouă soluție pentru aplicație, ceva mai bun, mai distractiv sau care adaugă o nouă dimensiune. Cu alte cuvinte, să aducă de fiecare dată ceva nou.

Mergeți pe aplicații native.

Facebook, LinkedIn și-au schimbat aplicațiile și s-au orientat pe nativ, iar aceasta nu este o întâmplare, căci decizia a venit în urma unui studiu de piață. Sunt conștientă că dezvoltarea unei astfel de aplicații poate părea o sarcină descurajantă, dar trebuie să știți că atunci când se face comparația și se trage linie, beneficiile dezvoltării unei aplicații hibride de web sunt cu mult depășite de adevăratele beneficii ale experienței unei aplicații native. Cei mai importanți factori, monetizarea, performanța, experiența de utilizator, securitatea, toate sunt puternic înclinate în favoarea aplicațiilor native. Nu ne permitem să ignorăm acest trend cu ușurință. O parte din ceea ce alimentează această ascensiune a experienței mobile unice: aplicațiile native și experiența de utilizator atât de bogată asociată cu acestea. Pentru că există o sumă uimitoare în joc, atât Apple cât și Google se asigură ca sistemele lor de operare sunt actualizate permanent și că sunt compatibile cu cele mai noi, cele mai bune feature-uri de pe piață. Aici aplicațiile native câștigă din nou, pentru că ele beneficiază de toate actualizările de sistem și inovațiile rapid lansate, într-un mod care pare pur și simplu imposibil aplicațiilor web.

Pentru ce plaformă să dezvoltăm prima oară? Alegeți-vă prima platformă cu grijă.

Când vine vorba de crearea aplicațiilor native, dezvoltarea pentru toate platformele deodată nu e o idee prea bună. De fapt, cel mai bine e să se înceapă cu una. Credeți sau nu, alegerea primei platforme pe care să se facă dezvoltarea ține mai mult de comportamentul utilizatorului final și are mai puțin de-a face cu capacitățile fiecărei platforme în parte. Până acum iOS și Android au reușit să atingă niveluri remarcabile și fiecare să-și țină aproape nișa proprie de utilizatori. Dacă ați ajuns într-un punct în care nu vă puteți hotărî pe care din ele s-o alegeți prima, atunci dați-mi voie să vă ajut.

De cele mai multe ori iOS se prezintă mai bine ca primă opțiune:

  • pentru că Android e un sistem fragmentat, iar dezvoltarea pentru iOS implică mai puțină muncă;
  • utilizatorii iOS tind să fie mult mai captivaţi, mai interesați de aplicațiile noi;
  • utilizatorii iOS sunt mult mai dispuși să plătească pentru aplicații.

Există însă și situații în care Android pare a fi o opțiune mai bună:

  • atunci când ați identificat acea nișă de utilizatori Android dispuși să plătească pentru aplicații sau dacă urmăriți distribuirea în cadrul unei companii;
  • atunci când nu sunteți siguri că aplicația poate trece de exigențele impuse de Apple;
  • atunci când nu vă permiteți costurile inițiale necesare pentru dezvoltarea unei aplicații pe iOS (un Mac, cont de programator - necesare doar pentru a începe).

Bineînțeles că toate acestea sunt valabile doar în cazul în care vă creați propria aplicație. În schimb, dacă lucrați pentru un proiect, atunci mai toate vă sunt aranjate, însă chiar și așa există câteva ponturi bune de luat în calcul, care să vă ajute în final atât pe dumeavoastră, cât și pe client:

  • Dacă ține de voi cu ce platformă începeți, sfatul meu ar fi să începeți cu cea care vă e mai comodă, cea cu care sunteți deja obișnuiți.
  • Urmați guideline-urile și principiile lor şi astfel sigur veți obține o aplicație robustă.
  • Chiar dacă aveți schițe foarte bine detaliate, e perfect normal să se devieze puțin de la ele pe parcursul dezvoltării; a crea aplicaţia după cele mai noi designuri e cât se poate de logic.
  • Faceți cercetări prima oară să vă asigurați că sunteți la curent cu toate noutățile, pentru că platformele se întrec în a optimiza și scoate versiuni noi în mod constant. Nu vă fie teamă să folosiți elemente noi, ele pot rezolva probleme cheie pentru soluția voastră. Întotdeauna încercați să găsiți cele mai bune soluții din punctul de vedere al utilizatorilor, pentru că în cele din urmă ei vor fi cei ce vor utiliza aplicația pe scară largă.

QA-ul e implicat din ce în ce mai mult în crearea şi stabilirea documentelor cu specificaţii, în estimări, deci e foarte important să fie la curent cu tot ceea ce e nou. Dacă sunteţi QA, fiţi pregătiţi să vă exprimaţi opiniile, îngrijorările, ideile, dar mai ales să vă puteţi întotdeauna motiva punctele de vedere.

Nu copiați elemente de pe alte platforme.

Chiar dacă nu vă dați seama de pe-acuma, una din cele mai grele probleme e "portarea" aplicației de pe o platformă pe alta. Oricât de tentantă e crearea unei aplicații care să arate și să funcționeze la fel pe toate platformele, trebuie să ținem minte că fiecare platformă în parte are caracteristicile ei, așa că e foarte posibil să nu puteți menține totul așa cum vă doriți. Nu încercați să faceți în așa fel încât aplicațiile să arate identic pe toate platformele și în nici un caz nu copiați elemente specifice de pe o platformă pe alta, doar pentru că arată bine. Nu numai că e o experiență proastă pentru utilizatorul obișnuit cu elementele specifice platformei pe care o folosește, dar e foarte probabil ca în final să fiți nevoit să faceți atât de multe compromisuri încât ultima soluție să fie re-crearea aplicației de la zero, iar acesta implică timp, bani şi resurse. De exemplu un "ActionBar" din Android nu va putea fi înlocuit cu succes de un "ApplicationBar" din Windows Phone sau "NavigationBar" pe iOS. Deci, nu e suficientă identificarea elementelor corespondente dintr-o platformă în alta. Întreaga structură trebuie regândită și refăcut designul.

De asemenea, este foarte puțin probabil ca un utilizator să folosească aplicația pe mai multe platforme deodată; dar chiar și asa, odată obișnuit cu un sistem de operare, el se va aștepta ca aplicația să se comporte într-un anume fel. Fiți flexibili și încercați să creați aplicația cât mai flexibil, astfel încât în momentul în care vă apropiați de o livrare și mai sunt încă modificări de făcut, să puteți adăuga orice element în timp util, iar aplicația să poată fi lansată la timp.

Odată ce aţi început dezvoltarea unei aplicaţii, nu trageţi de timp. O creaţi, o testaţi şi o puneţi pe piaţă, altfel riscaţi ca tot ceea ce aţi creat până atunci să devină "învechit" şi tot efortul depus până atunci să fie în zadar, pentru că e nevoie din nou de "ajustări" menite a se supune ultimelor guideline-uri. Am experimentat şi eu o situație asemănătoare, cu o aplicaţie dezvoltată intern, care a primit câte o linie de cod atunci când un programator avea timp liber. Astfel dezvoltarea a durat mai bine de un an, iar principiile, guideline-urile s-au schimbat mult, plus actualizările sistemului de operare au "schimbat mult jocul", astfel încât munca per total a fost cu mult mai mare decât dacă aplicaţia ar fi fost creată, testată şi pusă pe piaţă cât mai repede. Platformele fac actualizări de sistem în mod constant şi aplicaţia are nevoie de ajustări oricum, fie că e în dezvoltare, fie că e deja pe piaţă (în mentenanţă). În timp ce vă străduiţi să dezvoltaţi aplicaţia pentru următoarea platformă, cea care e deja făcută publică vă poate da informaţii prețioase şi poate îndruma spre ceea ce aveţi de făcut în continuare. Deci vă puteţi baza pe utilizatorii/clienții voştri pentru "feedback" şi pentru a vă face o idee despre cum "stă" aplicaţia voastră.

Nu adăugaţi elemente menite să ajute utilizatorul novice.

E important să se facă o distincţie clară între utilizatorul nou al aplicației și utilizatorul nou al platformei. Trebuie să aveţi în minte utilizatorul final şi să încercaţi să acoperiţi nevoile lui. De exemplu, un gest "Back" e folosit în Android și pe Windows Phone pentru a naviga la un ecran anterior, a închide tastatura virtuală, iar în cazul WP8 navigarea spre aplicația deschisă anterior. Deci adăugarea unor butoane pentru navigare, doar pentru că aplicaţia poate părea mai puţin intuitivă unor utilizatori noi ai platformei, nu e cea mai bună idee. Noi trebuie să credem că aplicaţia va fi folosită de oameni inteligenţi și chiar şi utilizatorii noi ai unei platforme vor ajunge să se obişnuiască cu aplicaţia odată ce se obişnuiesc cu sistemul de operare.

Cum ne facem aplicaţia descoperită?

Această secţiune e dedicată atât programatorilor cât şi inginerilor QA. Aceştia din urmă sunt tot mai mult implicaţi în planificarea proiectului, de la specificaţii până la livrare, deci a şti cum să vă faceți aplicaţia descoperită, vă ajută atât pe voi cât şi pe client. Nu putem însă avea control asupra câtorva aspecte, ca de exemplu găsirea aplicaţiei după o căutare în funcție de recenzii sau recomandări, clasificări, după relaţii şi "cross-sell" sau după aplicaţii în trend, dar există câteva moduri în care am putea modifica aceste cifre într-o oarecare măsură, făcând aplicaţia mai captivantă, pentru că, în cele din urmă, acesta e un cerc vicios: cu cât se depune mai mult efort, cu atât aplicația va avea mai mult succes la public.

Există câteva lucruri discutate la conferinţa Google I/O 2013 ce pot fi aplicate şi altor platforme. În primul rând metadata este foarte importantă:

  • Titlul: trebuie să fie clar, creativ, intuitiv.
  • Descrierea: e indicată precizarea cât mai clar și mai concis posibil a obiectivului propus. E bine să ne asigurăm că toată descrierea încape şi pe ecrane mici.
  • Capturi de ecran: acestea trebuie să reflecte cele mai bune caracteristici ale aplicaţiei.
  • Video: video preview poate fi una din cele mai convingătoare metode (în cazul în care capturile de ecran nu sunt suficiente).

Gândiţi-vă la utilizatorii vizaţi (desigur dacă aveţi). Recenziile lor pot să vă ajute în graficele de clasament. Nu aţi vrea să fiţi traşi în jos de recenziile negative ale utilizatorilor pe care nici nu i-aţi vizat, deci încercaţi să excludeţi această categorie, în cazul în care aplicaţia nu e menită a fi utilizată de toată lumea.

Există cinci lucruri care pot îmbunătăţi procesul descoperirii aplicaţiei:

  • Asiguraţi-vă că aveţi ancore web folositoare.
  • Încercaţi să creaţi un pachet pentru aplicaţie cât mai mic (nu v-ați dori ca aplicaţia voastră să fie în topul celor care urmează să fie dezinstalate pentru că spaţiul necesar nu permite instalarea unei alte aplicaţii).
  • Evitaţi greşelile intenţionate: de genul celor în titlu - Google Play va auto-corecta un cuvânt greşit în motorul său de căutare altfel că aveţi toate şansele ca aplicaţia să nu fie gasită din prima încercare tocmai din acest motiv.
  • Creați o buclă virală pentru aplicaţie - de exemplu un clasament pe rețele de socializare; aplicaţia poate deveni populară cel puţin în cercul vostru de prieteni.

"O reţetă" a succesului unei aplicaţii mobile

Din punctul meu de vedere, cel al unui QA, a crea o aplicaţie de succes înseamnă a crea o aplicaţie robustă, cu o performanţă bună, care încântă, care are un timp de instalare la utilizator cât mai lung, recenzii bune şi succes la public. Intenţionat sau nu, aplicaţiile menționate la începutul articolului au ceva în comun: toate urmaresc modelul Kano.

Fig. 1 Modelul Kano

În figura de mai sus puteţi observa curba de jos ce arată caracteristicile aplicaţiei la care un utilizator se aşteaptă, dar nu sunt neaparat elemente definitorii. Ideea aplicaţiei poate fi bună, dar ne limităm utilizatorii la folosirea unor elemente de bază. În acest fel nu ne vom face remarcați. Furnizând doar necesarul vom rămâne în pătrăţelul din colţul dreapta jos, lăsându-ne utilizatorii indiferenţi.

Curba din mijloc - Performance/Linear - reprezintă caracteristicile care au o relaţie liniară cu satisfacţia clienţilor. Altfel spus, cu cât oferim mai mult, cu atât mai fericiţi vor fi clienţii. "Flappy Bird" (originalul) a devenit atât de popular pentru că avea ceva ce cópiilor sale le lipseşte: o performanţă bună şi nivele potrivit de dificile. Nici măcar aplicaţia din care se presupune că programatorul s-a inspirat nu era atât de bună ("Piou Piou vs. Cactus").

Curba de sus arată caracteristicile care nu sunt aşteptate de client. Prezenţa lor poate să îmbunătăţească satisfacţia clienţilor foarte mult (de exemplu "Angry Birds" - care are foarte multe detalii încântătoare), dar lipsa lor nu ar fi un lucru foarte rău pentru utilizator (de exemplu "2048" -care nu se remarcă prin detalii grafice).

A şti ce caracteristici acoperă necesităţile utilizatorilor, ce i-ar încânta şi care ar fi cele ce îi lasă indiferenţi vă poate ajuta să vă decideţi asupra căror lucruri să vă canalizați eforturile. Atâta timp cât veţi tinde spre colţul din dreapta sus, veţi avea mari şanse de reușită. Desigur, aşa cum am văzut, norocul are mult de-a face cu succesul unei aplicaţii, însă ceea ce e esenţial să reţinem este că, dacă nu ne cumpărăm bilet de loterie, nu vom şti niciodată cum e să câştigăm premiul cel mare; aşa că nu mai staţi pe gânduri şi începeţi acum.

LANSAREA NUMĂRULUI 83, Târgu-Mureș

Prezentări articole și
Panel: Connected Products

Joi, 30 Mai, ora 17:00
Hotel Plaza, Târgu-Mureș

Înregistrează-te

Facebook Meetup

Conferință

Sponsori

  • ntt data
  • 3PillarGlobal
  • Betfair
  • Telenav
  • Accenture
  • Siemens
  • Bosch
  • FlowTraders
  • MHP
  • Connatix
  • UIPatj
  • MetroSystems
  • Globant
  • MicroFocus
  • Colors in projects