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.
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.
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:
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.
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:
Există însă și situații în care Android pare a fi o opțiune mai bună:
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:
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.
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ă.
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.
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ă:
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:
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.
Î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.
de Alpar Torok
