Fejlesszünk Fintech appot!
Mobil appot fejlesztenél, vagy csak érdekel, hogy más hogyan csinálja, mik a lépések, buktatók, sajátosságok és érdekességek? Mi belevágtunk majd egy éve, itt az ideje, hogy megosszam a tapasztalatot, hátha másnak is hasznos lesz.
Akinek nem mondana semmit az INLOCK és hogy miként kapcsolódik a fintechhez, azoknak egy rövid gyorstalpaló: Az INLOCK egy stablecoin és kriptopénz alapú megtakarítási platform, ahol az ügyfelek kölcsönbe tudják adni fedezet és intézményi biztosítással védett eszközeiket, amikért akár évi 10%-os kamatot tudnak zsebre tenni. Ezen a ponton most ne mélyedjünk el az olyan kérdésekben, hogy mégis miért éri meg kölcsönadni Bitcoint vagy éppen USDC stablecoint. Fogadjuk el, hogy ennek is van piaca és ügyfelei is. Nos… szóval ez egy Fintech termék.
Az INLOCK projekt definiálásánál talán az egyik leginkább távlati cél a mobil alkalmazás elkészítése volt. Ennek korai fázisban nagyon sok oka volt, de ha őszinte akarok lenni… akkor nagyjából azt mondhatnám, hogy a mobil appot azért hagytuk a feladatok sokaságának a végére, mert pontosan tudtuk, hogy mire oda elérnénk, már amúgy is túl leszünk nagyon sok projekt pivoton, amiket nyilván sokkal költséghatékonyabb webes alkalmazáson kifinanszírozni, mint minden egyes iterációra külön mobil alkalmazást fejleszteni a nulláról.
From scratch…
Az idei (2020) projekt célok összerakásánál két nagyon fontos célt fogalmaztunk meg: A meglévő peer-to-peer elv felszámolását és ezzel együtt a mobilapp elkészítését. Eredeti terveink szerint úgy voltunk vele, hogy az első félévben (május végéig) kihozzuk a mobil app-ot csak a Managed Lending funkcióra, majd nyár végére szépen kijövünk a többi funkcióval is (Borrow és Stake). Időközben a nyarat sikerült újra egy teljes projekt pivotálással kezdenünk, aminek ugyan a részleteit most még nem írnám le, de így utólagosan nagyon jó döntés volt, hogy a mobil appnál sem a “gyere cipó hamm bekaplak” elvet alkalmaztuk, akárcsak a többi fejlesztésnél.
Alapvetően többször beigazolódott mára és mindenféleképpen itt hagynám takeawaynek:
Egy startupnak az esetek döntő többségében fogalma sincs arról, hogy mit akar csinálni. Amije van az egy ködös elképzelés és a végtelen önbizalom, hogy oda el fog jutni…
Most, hogy az appunk ott van már az AppStoreban és a Google Playben, időszerű lehet visszaemlékezni, hogy miként is jutottunk el idáig.
A projekt első lépése egyfajta dev roadmap elkészítése volt, ami tartalmazta, hogy minek is kell benne lennie az MVP-ben (minimum viable product). Ezt mi így definiáltuk: Ügyfél regisztráció, teljes KYC process, wallet/dashboard nézet, ki/be utalások teljes ügymenete és további egy darab konkrét pénzügyi szolgáltatás, ami esetünkben a Managed Lending termék lett. Ez hivatott arra, hogy az ügyfelek kölcsön tudjanak adni USDC stablecoint és be tudjanak zsebelni érte éves szinten akár 10% kamatot, heti kifizetéssel.
Esetünkben az alkalmazás backendje már adott, hiszen 2 éve működik a szolgáltatás és bár több mobil app specifikus fejlesztést is kellett végezni, de legalább volt mire építenünk.
Az MVP definíció után jöhet is a csapat összerakása. Külső szemmel nézve az embereknek kétféle elképzelésük van egy mobil alkalmazás fejlesztésről:
- vagy azt hiszik, hogy odaadnak néhány ködösen felskiccelt fecnit egy “ÁJTÍSNEK”, aki kotlik rajta 2 hónapot és utána… hopp kész is a mobil alkalmazás.
- vagy azt hiszik, hogy felütik a sárgaoldalakat és a “mobil alkalmzás fejlesztő kisiparos” rovatból kiválasztják azt, akinek a telefonszáma a legalacsonyabb számmal kezdődik (gondolva, hogy akkor ő már nagyon keni a szakmát) és majd ő kotlik 2 hónapot és hopp… kész is a mobilapp.
Nos… a helyes megfejetés az “egyik sem”. Helyette viszont fontos megérteni, hogy mit is akarunk: amit akarunk, az egy mobil alkalmazás. Egy olyan mobil alkalmazás, amit mi magunk is szeretnénk használni. A feladat első lépése tehát definiálni a projekt célt, erőforrásokat hozzárendelni és belevetni magunakt az ismeretlenbe!
Kikre van mindehhez szükség: Érdemes már az első lépésekhez is bevonni a projektbe egy UI/UX szakértőt, aki az OKJ-s UI/UX képzésnél (ha egyáltalán van ilyen) egy picit több futott kilométerrel rendelkezik. Az INLOCK esetében ez a neve elhallgatását kérő Géza volt, akit valójában Bélának hívnak; de a továbbiakban az egyszerűség kedvéért nevezzük *uxchick*-nek. Szóval kell egy *uxchick* és nem árt, ha ebben a fázisban már megvan a product owner, aki lényegében a koordinátora lesz a munkálatoknak, plusz ugye kell egy project sponsor, akinek illik tudnia megfogalmazni, hogy mi a francot is akar lefejlesztetni. Ez az INLOCK esetén jómagam voltam/vagyok és még tervezek is lenni. Nézzük hát miként fogalmaztam meg 2019. december 17-én, hogy mit is akarunk csinálni:
A termék egy peer-to-peer kölcsön platformot valósított meg, ahol az ügyfelek fedezetként kriptopénzeket használnak és a kölcsönök stablecoinban vannak folyósítva. A platform idén május óta működik mely jelenleg kizárólagosan webes felületen érhető el. A cél az lenne, hogy elkészüljön a termék mobilos alkalmazása is, viszont szeretnénk ezt úgy meglépni, hogy ez minél kevésbé vegye el a fókuszt a meglévő webes termék fejlesztésétől, illetve az üzletfejlesztéstől, ezért az a döntés született, hogy a mobilos platform fejlesztésre egy külön csoportot akarunk összerakni minél kevesebb átfedéssel a meglévő gárda kapcsán.
Kizárólagos feladata a teamnek a mobil alkalmazás összerakása. A háttérfolyamatok készen vannak, minden funkció jelenleg is ügyfelek által használtak szerint.
A mobil alkalamzás kapcsán mind funkcionalitásban, mind ügyfélélményben egy lényegesen egyszerűbb megoldást akarunk létrehozni mint a jelenlegi webes megoldásunk. A megközelítés: “mobil for beginners, web for pros, api for partners”.
Van egy alap koncepciónk (lényegében előzetes piackutatás által megalkotott megoldások alapján), illetve *uxchick* személyében adott a UI/UX szakértőnk is, aki ezzel fog foglalkozni. Az összes többi szerep viszont jelenleg még nyitott, illetve a koncepció kapcsán is törekszem arra, hogy a csapat szabad kezet kapjon.
A jelenlegi INLOCK staffból két stakeholder lesz csak érintett a mobil fejlesztésben. Egyrészt jómagam mint sponsor, illetve kollégám, aki a teljes backend/API integráció kapcsán tud segédkezni, és egy személyben viszi a product owner státuszt.
Timing: Az elvárás, hogy május elejére/közepére elkészüljön egy mvp product, ami minimálisan egy fő funkciót már élesben is tud működtetni (ez célszerűen a lending rész lesz, mivel az az egyszerűbb), illetve minden más funkció kapcsán is már megmutatja a készülő koncepciót demó jelleggel. Ennek már olyan állapotban kell lennie, hogy az ügyfelek is használhassák/kipróbálhassák. A végső productnak legkésőbb 2020 augusztus 15-ig kell elkészülnie. Aminek tartalmaznia kell a következő INLOCK funkciók mobilra szabott (leegyszerűsített) teljes folyamatát: onboarding, autodrive lending, borrow, shield, push notifications, in-app promotions.
Cél platformok: Android és iOS. Mindkét esetben csak a mobilos portrait orientation. Tablet-ready viewra nincs szükség, (ez utóbbi mégis kipottyant)
A munka teljesen remote-work alapon tud működni. Van irodánk, ahol meg lehet tartani a projekt, illetve sponsor egyeztetéseket, de egyetlen team tag részéről sem elvárás az onsite munkavégzés.
Bármilyen meglepő is, de ez egy projekt definíció. Nem éppen prince2 szerinti és valószínűleg a főiskolai projekt menedzsment órámról is kivágtak volna ezzel, de komolyan… aki egy sponsortól ennél többet vár, az szerintem csak tankönyvekben hallott még a projekt sponsorokról.
Ha megvan a rajzolgató emberünk, aki már látott UX-et, megvan a product ownerünk és a projekt sponsor kiimádkozta magából a projekt definíciót, akkor jöhet is az első izgalmas lépés: A wireframe. A projektek cirka 90%-a vagy eleve ezen a ponton vérzik el, vagy ennek hanyag megvalósítása miatt vérezteti el a saját projektjét… esetleg (és ez a legrosszabb eset), elkészült és kihozzák a mobilappot, majd megkapják az ügyfelektől, hogy: “mi ez a használhatatlan förmedvény”. Tehát ha szeretnél olyan mobil appot készíteni, amit az ügyfeleid örömmel fognak használni és szeretnél is erről pozitív visszajelzéseket kapni… nos akkor NE AKARD MEGSPÓROLNI A WIREFRAME MELÓT!!!!!!!
Első lépés: wireframe
Hogy mi a wireframe? Gyakorlatilag az alkalmazás drótváza. Tehát a nézetek, amik a felhasználók előtt meg fognak jelenni. In medias res… valami ilyesmit képzelj el:
Mint látható a képen a wireframe az egyes nézeteket tartalmazza design nélkül, de már a véglegeshez közelálló layouttal. Egy wireframe akkor jó, ha lényegében az elkészült mobilapp nélkül végig tudod “klikkelni” a teljes szoftvert. Amíg a tervezőasztalon nem “működik” a mobilpapod, addig felesleges akár csak egy sort is lekódolni. A wireframe tipikusan nem az lépés, amit érdemes feldarabolni és bizonyos részeit későbbre hagyni. Fontos, hogy minden egyes nézeten (framen) csak annyi adat legyen amennyi feltétlenül szükséges. Ha nagyon sok adatot raksz rá, vagy akár csak egy sort is el kell olvasni egy egyébként logikus felépítésű frame-n, akkor esélyes, hogy az ügyfél el fog rajta vérezni. Mutatok egy tipikus rossz példát, amit mi még a béta tesztek után is bent hagytunk az appban és perpillanat a KYC csapat ennek issza is a levét:
Két frame. Az elsőn az ügyfél tud készíteni egy selfiet a nagy fehér gombbal és közben látja is magát a kamerában, a másodikon eddig ellenőrizni lehet, hogy tényleg jó lett-e a kép. A selfie készítő képre ráírtuk, hogy nem elég egy sima fotó saját magadról, hanem kell a kezedbe egy papír, rajta az INLOCK feliratal és a dátummal, illetve legyen a kezedben az ID-d is a képen… sőt még raktunk rá egy menő linket is (Show me an example), ami a fotóra rárakja a középső kis minta képet.
Na mit tippel az olvasó mennyien véreznek el ennél a lépésnél és töltenek fel simán egy képet magukról? Természetesen az app használók kb 60%-a. Ezeket a képeket nyilván a KYC csapatnak el kell utasítania, ami egyből az ügyfélnél negatív élmény amiből logikusan következik is az ügyfélvesztés és a“mint szívóztok” komment. A probléma persze simán elkerülhető lett volna, ha az ellenőrző képen (jobb frame) rárakjuk a fényképezett kép mellé/alá/pip-ben a selfie example-t is ezzel jelezve még időben az ügyfélnek, hogy egyébként egy sima fotó nem lesz elég. Ezzel drasztikusan lehetett volna csökkenteni az ilyen kellemetlenségeket. A jó pap is holtig tanul…
A wireframe kapcsán néhány takeaway:
Minden frame a minimális elemekből álljon csak és lehetőleg egy frame = egy interakció. Amit lehet vizualizálj és a layouttal próbáld vezetni az ügyfelet, különben el fog veszni. Az egyes mobil framekre csak olyan szöveget írj rá, amin nem fontos, hogy el is olvasson az ügyfél, ellenkező esetben tuti nem fogja elolvasni és utána jöhet a negatív tapasztalat.
Ha megvan a wireframe, már szénné van tesztelve a teljes folyamat, akkor érdemes azt egy olyan csoporttal teszteltetni, akik nem vettek részt a kidolgozásában, tehát — még — nem szerelmesek a wireframebe. A kapott visszajelzések kapcsán (alapvetően a teljes mobilappra igaz, nem csak a wireframre) egy nagyon fontos takeaway:
Ha egy tesztelő nem ért valamit a felületen, de elmagyarázva megérti és a homlokára csapva magyarázkodik, hogy “hú de hülye vagyok, pedig milyen logikus”… Na akkor valójában nem ő a hülye, hanem a mobilapp/nézet/design/frame a rossz. Nem leszel ott minden ügyfél mellett, hogy elmagyarázd neki ugyanezt. Ilyenkor azonnal vissza kell húzni a tervezőasztalig!
Mi wireframehez egyébként a figma-t használtuk és fogjuk is használni. Nagyon bevált a csapatnak. A szolgáltatás javarészt ingyenes, de 3 fő felett már megkérik rendesen az árát… és tuti nem fogtok beleférni a 3 fő limitbe… Ezzel érdemes előre számolni, vagy valami egyéb toolt használni. A figma azért hatékony eszköz, mert konkrétan erre és csak erre jó, de erre annyira, hogy egy teljes prototípust össze tudsz benne klikkelni, amit végig is lehet nyomkodni az összes interakcióval együtt. Így nagyon hatékony eszköze tud lenni pl. annak amikor A/B tesztelni akarsz egy konkrét folyamatot.
Ha megvan a wireframe és a fókuszcsoportos teszten is jól vizsgázott, akkor mehetünk a második lépésre, mely két (célszerűen párhuzamos) al-lépésre oszlik: design és fejlesztési keretrendszer + fejlesztő kiválasztása
2/A lépés: Design
A design kapcsán nagyon kevés igazán jó gondolatot lehet megosztani. Mára egyáltalán nem menő a csicsás, sok képből álló design, kivéve persze ha Candy Crush Saga-t fejlesztesz, mert oda kell. A design letisztult legyen. Egységes elemeket használj. A formok, gombok, mezők, szövegek azonosak legyenek, nem is beszélve a színekről és font méretekről. Színekből használj keveset. Érdemes eleve valamilyen egységes design frameworköt használni, pl. Material design, ami gondoskodni fog arról, hogy tényleg minden ugyanúgy nézzen ki és csak annyi perszonalizálj rajta amennyi feltétlenül szükséges. Az ikonok egységesek legyenek. Ha az ikonjaid pl. monochromok, akkor mindenhol legyen is az, ha színesek, akkor egységes színeket használj. A színek ne azt segítsék, hogy az appod úgy nézzen ki mint egy unikornis, hanem azt, hogy kiemeljék a fontos és releváns dolgokat, kvázi a megérthetőséget segítség. És úr isten, a szürke és a kicsit szürkébb az nem két szín! Ne rakjál szürkére szürkét, mert ugyan a tervezésnél a képernyődön baromi jól fog kinézni, de tudod ezt emberek fogják használni egy nagyobb gyufásdoboz méretű kijelzőn, úgy hogy éppen az utcán sétálnak verőfényes napsütésben, miközben a kijelző fényereje nullára van húzva, hiszen azzal biztos sok aksit megspórol. A színek kapcsán nagyon fontos a megfelelő kontraszt elérése. Agyam eldobom attól, amikor nagybankok kihozzák az egyébként tényleg nagyon jó mobilappjaikat, amikben szürkére írnak szürkével, minden szöveg 6 pixel magas és a gombok keretei csak 1–2 árnyalattal ütnek el a háttértől, ami miatt sok esetben abban se biztos az ügyfél, hogy az egyébként egy gomb.
A design egységes legyen. Kövesd a későbbi verzióknál is korábban lefektetett alapokat. Ha mégis változtatni akarsz egy már kiadott app kinézetén, akkor azt tedd meg visszamenőlegesen az összes érintett formon.
A design kapcsán létfontosságú az A/B tesztelés. Mindenből készíttess 2–3 alternatívát és simán kérdezz meg minél több embert, hogy kinek melyik tetszik és miért. A feedbackek segíthetnek abban, hogy a design ne NEKED készüljön és tetsszen, hanem az ügyfeleidnek.
Két példa arra, hogy miként lesz a kiszinezett wireframből design.
Persze a design nem feltétlenül csak arról szól, hogy hol mi milyen színű legyen. Ugyanilyen fontosságú feladat, hogy az egyes UI elemek honnan kapnak adatokat, mit jelenítsenek meg, mivel és hogyan interaktáljanak. Esetünkben ugye egy API gateway mögé rakott backenddel kommunikáló alkalmazásról beszélünk, így a design ezen része arról szólt, hogy mit és hogyan kap meg az alkalmazás, mihez milyen backend hívások kellenek.
2/B lépés: Fejlesztési keretrendszer
Kétféle út létezik: Natív app fejlesztése androidra és iOS-re (külön skillset kell hozzá, akár külön csapat is a két platformhoz, külön kódbázis, külön bugok, satöbbi). Másik alternatíva, hogy valamilyen cross platformos környezetben indul el a fejlesztés. Ilyen például a xamarin vagy a react native.
Relatív új irány az amikor az ember az egyiket sem választja, hanem rátalál a Flutterre, ami a google saját quasimodoja erre a témára. A flutter a dart nevű programozási nyelvre épül és lényegében az a célja, hogy a dartban elkészített alkalmazásból készítsen egy natív android és egy natív ios alkalmazást. Ezeket ezt követően már a natív fejlesztő toolokban lehet buildelni, deployolni, satöbbi…
Jelenleg a flutter ugyan még bétában van, de ez senkit sem tarthat vissza attól, hogy pont ezt válassza, hiszen bármilyen képernyőméreten és készüléken pixelhelyesen megjelenített design nem kicsit csábító, nem is beszélve a dinamikusan fejlődő toolokról. Jelenleg már több mint 100.000 flutterben fejlesztett éles alkalmazás található az AppStoreban.
Talán, csak egy dolog jelenthet komolyabb visszatartó erőt: annyira új a flutter és a dart is, hogy egyelőre nagyon kevesen értenek hozzá. Kb. olyan kihívás flutter fejlesztőt találni ma, mint amilyen kihívás volt 2000-ben php fejlesztőt.
Ennek ellenére mi a Flutter mellett döntöttünk és a megfelelő fejlesztő(k) beszerzése érdekében egy nyílt pályázatot írtam ki a variance blogon:
Érdekes módon kifejezetten sok jelentkezést kaptunk. Volt sok fulltime freelancer és több kisvállalkozás is, aki szívesen bedolgozott volna nekünk.
Előzetes rövid interjúkon leszűkítettük a shortlistet négy jelentkezőre (2 cég, 1 fulltime freelancer és 1 parttime), akiknek egységesen ugyanazt a dealt ajánlottuk fel: Készítsék el a mobilapp egyik képernyőjét (dashboard) teljes funkcionalitással, automatizmusokkal, backend hívások kezelésével, stb. Kapott mindenki erre 2 napot, amire fix költséget tudtak elszámolni (érdekes módon ezzel az elszámolással a végén senki nem akart élni).
A négy pályázó közül három küldött határidőre pályamunkát. A kiválasztási szempontok voltak: pixelhelyes megvalósítás, overflow-k kezelése, használt külső libek, kód olvashatósága, illetve a fejlesztési idő alatti kommunikáció jellege a fejlesztő és az *uxchick* és a product owner között. Az utóbbi kifejezetten fontos, hiszen ha az első framenél már nagyon sok az iteráció és sok a félreértés, akkor ez később sem lesz másképp.
Ekkorra megvolt a design, ki volt választva a dev framework és a fejlesztővel is leszerződtünk. Nem volt más hátra mint előre lépni, indulhatott a DEV!
3. lépés: DEV!!!
Ezzel a fázissal kapcsolatban túlságosan sok okosságot nem tudok és nem is akarok leírni. Ami tény: Ha az első két lépésnél nem spóroltuk ki a megfelelő tervezést, akkor az app fejlesztés javarészt csak erőforrás menedzsmentről fog szólni, ami végtelenül kényelmes tud lenni. Nyilvánvaló, hogy attól, hogy egy fejlesztő kap egy csomó wireframet és designt, illetve megkapja esetleg az api hívásokat… szóval ettől még biztosan nem fog egy kész terméket fejleszteni. Érdemes a feladatot nagyon sok elemi kis feladatra darabolni és valamilyen task management eszközben trackelni. Mi már lassan 3 éve a Trello-ra esküszünk, de használtunk előtte asana-t is, ami egyébként ugyanúgy jó és biztos vagyok benne, hogy erre bármi más is jó… kivéve azt az egy toolt, amivel már halálba nyomaszt a YouTube, mert minden videó előtt annak a reklámját kell, hogy megnézzem és nem vagyok hajlandó a nevét se leírni.
Szóval, a fejlesztés legnagyobb részét (a kódoláson kívül) a task management teszi ki. Ez igaz akkor is, ha magát a mobil appot csak egy fejlesztő csinálja, de különösen igaz, ha egy kódbázison több fejlesztő dolgozik.
A trello és hasonló appok a fejlesztés elején abban segítenek, hogy mérhető és ütemezhető legyen a fejlesztés. Később pedig abban, hogy az egyes hibajegyek és esetleges változtatási igények a fejlesztőnek ne emailekből és telegram üzenetekből kelljen összehalásznia, hanem strukturáltan tudjon ezekkel haladni. A trello lényegében egy kanban táblát ad… nem is érdemes ennél több dolgot belelátni.
Mivel egy mobilappot nem lehet csak úgy 2–3 percenként kireleaselni, ezért fontos, hogy az első éles verzió minél inkább bugmentes legyen és pontosan azt tudja amit szeretnénk. Éppen ezért létfontosságú a megfelelő mennyiségű belső teszt, majd zárt beta teszt és a végén akár nyílt beta tesztek lebonyolítása is. Ezekhez egyébként mint az Apple (ios), mind a Google (android) megfelelő eszközöket ad, melyekkel akár komolyabb mennyiségű beta tesztelő esetén is lehet folyamatosan kiadni az újabb tesztelhető verziókat. De ezekről később.
A fejlesztéssel párhuzamosan (amikor még a fejlesztés a végefelé tart), célszerű elkezdeni felkészülni az app kiadásra.
4. lépés: App kiadások előkészülete
Egységesen igaz, mind a google, mind az apple platformokra, hogy éles áruházba csak akkor jelenhet meg alkalmazásod, ha előtte csatlakozol a fejlesztői programjukhoz és aláveted magad review folyamatnak.
A fejlesztői program tagság az apple esetén évi 90 dollárba kerül, a google esetén pedig egyszeri 25 dollárt kell fizetni érte. Ezért cserébe lehet hozzáférni az Apple Developer és Connect felületekhez, illetve a Google esetén a Play Consolehoz. Ezeken az eszközökön fogod majd az alkalmazás verziókat menedzselni, illetve — és ezen a ponton ez nagyon fontos — itt fogod beállítani azt is, hogy az ügyfeleid előtt hogyan fog megjelenni az alkalmazásod letöltési adatlapja.
A kiadás kapcsán a munka oroszlánrésze a megfelelő adatlap összerakása, megfelelő screenshotok, szövegek kellenek. Érdemes videókat készíteni, amikhez persze már nem ártana, ha az alkalmazás véglegesen kész is lenne. Nem kifejezetten jól időzíthető ez a feladat. Mi az INLOCK kapcsán úgy döntöttünk, hogy egyelőre elindulunk egy minimal adatlappal és menet közben “pimpeljük” fel. Maga a feladat komplexitását jól bemutatja az alábbi ASO (App Store Optimization) cheat sheet:
Igen, ez egy olyan link, aminek érdemes a tartalmát lementeni és jól elrakni, ha valaki mobil app fejlesztésen töri a fejét, mert az ASO ugyanolyan biznisz lesz néhány éven belül, mint amelyik eddig a SEO volt.
A cheat sheetből jól látszik, hogy temérdek mennyiségű egyedi méretű képet, ikont és különböző méretű promóciós szövegeket kell elkészíteni.
Mindezt tovább tetézi a Google Play áruház, ami pl. az alkalmazás rövid leírását, automatikusan azon a nyelven jeleníti meg, amin az ügyfél használja a Google Play Storet/telefonját. Ha az appból nincs pl. magyar, olasz vagy mondjuk kínai leírás, az sem gond. A Google gondolkodás nélkül megjeleníti magyarul, olaszul vagy éppen kínaiul a google translatelt átiratot… és nem… ezt nem lehet kikapcsolni. Egyetlen megoldás, hogy ténylegesen létrehozod az adatlapot annyi nyelven, amennyin csak tudod és rendes szakfordítókkal lefordíttatod a szövegeket… Vagy persze választhatod ehhez a Google fizetős fordító szolgáltatását is, ahol természetesen már élő és lélegző emberek fogják elvégezni a fordítást.
5. lépés: Tesztelés, béta tesztelés
Ha elkészült az első kiadásra váró release és a belső teszteken már nagyon jól szerepel az alkalmazás… Akkor lehet elkezdeni béta tesztelőket toborozni. Egy teljesen zöldmezős alkalmazáson ez persze nem egyszerű kérdés, de esetünkben meg tudtuk szólítani az INLOCK aktív felhasználóit, akik közül szerencsére igen sokan jelentkeztek is a beta tesztelő programra. Ez azért is volt szerencsés, mert valójában az éles kiadás után ők fogják először használni a terméket, tehát igen fontos, hogy az első benyomásukat már a beta teszt időszakban megosszák a fejlesztő csapattal.
Az Apple/iOS estén a béta tesztekben a “Test Flight” nevű app segít, ami az Apple hivatalos alpha/beta tesztelő eszköze, ugyanúgy lehet benne telepíteni az alkalmazásokat, mintha AppStoreból jönnének. A Google esetén ezzel rendesen megszenvedtünk. Ott a Play Console, App Releases nézetében lehet a különböző tesztelési fázisokra meghívni az ügyfeleket. Igazából az “addig nyomkodtam amíg egyszer nem sikerült” állapot vezetett megoldásra és ennél professzionálisabb leírást senki ne is várjon tőlem. Igaz mi eleve eléggé a végére hagytuk az Androidos beta teszteket.
Mindkét esetben (Test Flight és Google Internal test/beta) igaz, hogy csak app review után lehet kiadni a tesztelőknek az új verziót. Ezeket a reviewkat általában 24 óra alatt hajtják végre a Google/Apple mérnökök, de pl a Google esetén az első review-ra több mind három napot kellett várnunk.
Egyébként a reviewn szintén komoly előnyt jelent, ha az elején jól választod meg mind a fejlesztőt, mind a fejlesztő eszközt. Esetünkben pl a tény, hogy a Flutter minden kijelzőn és készüléken ugyanúgy jeleníti meg a design-t, gondoskodik az olvashatóságról és az olyan dolgokról mint pl. a látás/hallássérült felhasználók által használt kisegítő funkciókkal való kompatibilitás… nos ez igen komoly fegyvertény mellette, ami nyilván csak itt a review fázisban fog kijönni pozitívumként.
6. lépés: Launch
Ide már nem nagyon tartom célszerűnek kisesszét írni. Aki ideáig eljut, annak lesz egy applikációja ami elérhető lesz AppStoreból és Google Playből. De nyilvánvaló, hogy a munka oroszlánrésze csak itt indul…
Remélem hasznos gondolatokat találtál a leírásomban. Ha bármivel kiegészítenéd, akár saját tapasztalatod alapján, akkor kérlek tedd meg alább!
Ha érdekel, hogy mégis milyen mobil app készült nálunk, akkor kérlek látogass el a https://inlock.io/ oldalra és töltsd le! Köszönöm.
