Egy működő webáruház mellé készülő alkalmazásnál nem a felületek elkészítése a legnagyobb feladat. Ebben a projektben az integráció és a hozzá tartozó háttérfejlesztés a teljes fejlesztési idő közel felét igényelte.
Egy működő webáruház mellé készülő mobilapp elsőre egyszerűbbnek tűnik, mint egy nulláról induló termék. A termékek megvannak, az árazás megvan, a rendelésfeldolgozás működik. Csak egy másik felület kell hozzá.
A gyakorlatban máshogy alakult.
Magyarország egyik vezető szerszám-webáruháza mellé készítettünk alkalmazást, egyedi, nem dobozos rendszer mögé. A webshop évek óta működött, több tízezer termékkel.
A projektben az integráció és a hozzá tartozó háttérfejlesztés a teljes fejlesztési idő közel felét igényelte. A felületek elkészítése ehhez képest a kisebb tétel volt.
Röviden: mi készült?
- React Native mobilalkalmazás iOS-re és Androidra: terméklistázás, szűrés, regisztráció, belépés, rendelésleadás
- Node.js háttérszolgáltatások és API, amelyek a mobilos működést kiszolgálják
- Teljes szinkron a webes és a mobilos oldal között: közös fiókok, közös rendelési előzmények
- Több tízezer termék, végtelen görgetéssel
- A fizetés a webshopban maradt, az app a státuszt kapja vissza
- Push értesítések, és folyamatban lévő hűségprogram
A mobilos rendszer nem a weboldal másolata. A webshop keretet és funkciókat adott, de a mobilos felület és működés önálló terméktervezés eredménye.
Hogyan dolgoztunk együtt a webáruház fejlesztőivel?
A webáruházat nem mi építettük, és a működését sem mi ismertük. A meglévő rendszer fejlesztői segítettek megérteni, hogyan épül fel a webshop, ez nélkülözhetetlen volt, mert egy évek alatt összeállt rendszernél sok döntésnek van története, amit kívülről nem lehet kitalálni.
A munkát megosztottuk: néhány feladatot ők oldottak meg a saját rendszerükben, a nagyobb részt mi építettük meg a mobilos működést kiszolgáló háttérszolgáltatásokban.
Ez a felállás gyakori, és általában így működik jól. Aki a meglévő rendszert ismeri, gyorsabban old meg bizonyos feladatokat benne. Ami viszont az alkalmazás logikájából következik, azt érdemesebb az új rétegben kezelni.
Ezért az egyik első kérdés egy hasonló projekt előtt: elérhetők-e még azok, akik a rendszert építették? Nem feltétlenül fejlesztési munkára, sokszor elég, ha tudnak válaszolni. Ennek a projektnek a tempóját érdemben befolyásolta, hogy volt kivel egyeztetni.
Több tízezer termék egy telefonon
A katalógus mérete önmagában is feladat.
A terméklistát végtelen görgetéssel oldottuk meg: az app mindig csak annyit tölt be, amennyi éppen kell, és görgetés közben kéri a következő adagot. Így nem kell egyszerre nagy adatmennyiséget betölteni, sem a készüléken feldolgozni.
A szűrés ehhez kapcsolódik: több tízezer termék között a kereső és a szűrők nem kényelmi funkciók, hanem az elsődleges navigáció. Ilyen katalógusméretnél a kereshetőség és a válaszidő a két meghatározó követelmény.
Az árak és a készletadatok lekérdezéskor frissülnek, amikor a felhasználó betölt egy oldalt, akkor jön az aktuális érték.
Mi történik, ha rendelés közben változik valami?
Ez az e-kereskedelmi integrációk klasszikus élhelyzete, és érdemes végiggondolni, mielőtt előfordul.
Ha változik az ár, a vásárló a kosárban látja az új értéket. Nem az történik, hogy a régi áron rendel, és később derül ki az eltérés.
Ha a termék elfogyott, a kosárból már nem adható le rá rendelés.
Ha pont a rendelés közben fogy el, az app hibaüzenetet ad, hogy a termék elfogyott.
Egyik eset sem elegáns, de mindhárom esetben az derül ki, ami a valóság, és a vásárló nem utólag szembesül vele. Egy készletkezelő rendszernél ez a fontosabb szempont.
A fizetés ott maradt, ahol működött
A fizetést a webshop kezeli, és a státuszt jelzi vissza az appnak.
A fizetési folyamat már működött és tesztelt volt. Nem volt indok arra, hogy az alkalmazás saját úton indítson tranzakciót, amikor a meglévő megoldás ezt megbízhatóan ellátja.
Ez általánosítható tanulság: ha valami már működik és nem az új rendszer problémája, nem érdemes újraépíteni csak azért, mert megoldható lenne benne is.
Közös fiókok, közös rendelések
A vásárló szempontjából egyetlen dolog számít: ugyanaz a fiókja, bárhonnan lép be.
A két rendszer között teljes a szinkron és az átjárás. A weben regisztrált vásárló ugyanazzal a fiókkal lép be az appba, látja a korábbi rendeléseit, és az appban leadott rendelés a webshop adminfelületén jelenik meg.
Az üzemeltető oldaláról ez legalább ennyire fontos: nem kell két helyen kezelni a termékeket, és nem kell két rendelési listát összevezetni.
Tesztelés: meglévő és új felhasználókkal
A tesztelés nem csak az appról szólt, hanem a két rendszer együttműködéséről.
Belső és külső tesztelés is volt, mindkét oldalon, meglévő és új felhasználókkal egyaránt. Ez a megkülönböztetés szándékos: egy meglévő vásárló fiókja évek adatait hordozza, régi rendelések, korábbi állapotok, olyan helyzetek, amik egy frissen létrehozott tesztfiókban nem fordulnak elő.
Mit érdemes tisztázni egy hasonló projekt előtt?
Ha működő webáruházad van, és appot terveznél mellé:
Hogyan érhetők el a rendszeredből az adatok? Ez mozgatja leginkább a költséget. Ahol a meglévő rendszer már kiszolgálja a szükséges műveleteket, ott gyorsabb a munka. Ahol nem, ott háttérszolgáltatást kell építeni hozzá, ez a fejlesztés jelentős részét jelentheti.
Elérhetők-e a rendszer fejlesztői? Nem feltétlenül fejlesztési munkára. Sokszor elég, ha tudnak válaszolni arról, hogyan épül fel a rendszer.
Mekkora a katalógus? Néhány száz és néhány tízezer termék között a kereshetőség és a válaszidő követelményei érdemben eltérnek.
Mit vársz az apptól? A webshop keretet ad, de az app nem a weboldal másolata. Érdemes végiggondolni, mit használnak majd másképp a vásárlók telefonon, de ebben mi is segítünk tapasztalatainkkal.
Webshopod van, és appot terveznél mellé?
Írd meg, milyen rendszeren fut a webáruház, és mit vársz az alkalmazástól. Megnézzük, mit tud kiszolgálni a meglévő rendszer, mihez kell új réteg, és mit érdemes érintetlenül hagyni.
