Miért kell natív mobil app egy webes szolgáltatásnak?
Egymás után kapitulálnak a mobilos HTML5 projektek, nem jött be az univerzális stratégia, egyszerűbb egyesével natív klienseket készíteni. Felvetődik azonban a kérdés: miért van szükség arra, hogy a böngészőben született webes szolgáltatások is natív alkalmazásokat készítsenek? Kéménczy Kálmánt, a Prezi szakértőjét (product monkey) kérdeztük meg a témában.
Kéménczy Kálmán szerint az alapvető probléma a HTML5 használatával, hogy a mobilos platformoknál képtelenség annyira erős integrációt létrehozni a webes alkalmazásokon keresztül, amilyenre szükség lenne, amit a felhasználók elvárnának. A Facebook is elkezdte járni a HTML5 utat, majd miután visszakozott, a natív SDK-k kiaknázásával sokkal előrébb jutott néhány hónap alatt felhasználói élmény tekintetében. Tény, hogy az SDK-k teljesen rágyógyulnak az operációs rendszerre, a kihagyásukkal nem lehet annyi élményt adni a felhasználóknak, elég például a nemrég megjelent chat heads funkcióra gondolni Androidon, ami más alkalmazások elé képes layert tenni. Egy webes alkalmazás ezt sosem tudná megcsinálni, de még a névjegyzék-szinkronizáció is egy összetett feladat HTML5-ben.
Jó ötlet volt, csak nem jött be
A HTML5 egy olyan univerzális nyelvnek és platformnak tűnik, amiben elég egyszer megcsinálni a fejlesztést és az mindenhol működik. Ez azonban ebben a formában nem igaz. Az elsődleges probléma már a megjelenítésnél előjön: a felhasználók megszokták a platformspecifikus kontrollokat, azonnal kiszúrják, ha valami nem úgy néz ki, esetleg nem is úgy működik, mint az operációs rendszerben máshol. A specifikus megoldásokhoz való ragaszkodás nem a gyártók berögződése, az emberek tényleg számítanak rá, hogy ha megnyomnak egy felületet, akkor az történik, ami “szokott”. Egy új alkalmazásnál is jogos elvárás a kezelés kiszámíthatósága, az egységesség.
Az iOS, az Android és az többi platform rengeteg ilyen beépített kontrollt, felületi elemet és interakciós megoldást kínál, amik a fejlesztők számára egyszerűen elérhetőek és bonyodalmak nélkül implementálhatóak. Ha iOS-en valaki a gyári widgeteket használja, akkor még szándékosan is nehéz olyan appot készíteni, ami kifagy. Ellenben a HTML5-tel minden ilyen beépített megoldást egyedileg kell elkészíteni, ha pedig a fejlesztő szeretne adni az adott platform felhasználóinak a fent említett kiszámíthatóságból, akkor azzal szembesül, hogy mégis párhuzamosan kell több verziót készítenie.
Kéménczy szerint szét kell tudni választani, hogy milyen szerepet játszik egy adott felület a teljes szolgáltatás életében: nem lehet egyenrangú szereplőként tekinteni a webes, a mobilos, tabletes kliensre, ha más-más élethelyzetben használjuk azokat. A LinkedIn esetében a mobilos felületen többnyire tartalmat fogyasztanak az emberek vagy rákeresnek másokra. Ugyan mindkét funkció erősen támaszkodik a webes keretekre és adatbázisokra, tehát feltételezhető lett volna, hogy a cég kitart a mobilon a HTML5-alapú kliens mellett, de a fent említett dizájn- és UX-igények miatt ott is az lett a verdikt, hogy natív alkalmazásra van szükség.
A Twitter esetében már végképp nem lehet azt mondani, hogy bonyolult funkciókat valósít meg, hiszen mindössze 140 karakteres üzeneteket kell tudnia sorban megjeleníteni. A fejlesztők mégis a natív megoldást választották, mert olyan elemekkel kell integrálódni, mint az eszköz névjegyzéke. A HTML5 app ezt megtehetné Androidon akár a Gmail felhőbe szinkronizált adatbázisán keresztül, de teljesen felesleges saját megoldásokat barkácsolni hosszadalmas, izzadságos munkával, ha van rá kész, sokkal egyszerűbb út is.
A Firefox OS újragondolja
A Firefox OS esetében viszont újraértelmeződik a natív és a web app viszonya, hiszen az operációs rendszer felülete önmaga is HTML5-alapú. Mivel az operációs rendszer ott egy nagyon vékony réteg, illetve a Mozilla lekódolta webes alapokon az összes vezérlőt és API-t a hardverekhez, és az appok is HTML5-ben készülnek, ezért ilyen formán nem lesz különbség. Igaz ettől függetlenül egy szolgáltató fejlesztőinek ugyanúgy “natív” filozófiával kell majd hozzáállni, mert a Firefox OS specifikus funkciók, felületi elemek miatt nem lesz elég egy reszponzív weboldalt becsomagolni appként, ugyanolyan fejlesztési folyamatról lesz szó, csak könnyebb lesz a webes megoldásokat átültetni.
Machine recruiting: nem biztos, hogy szeretni fogod Az AI visszafordíthatatlanul beépült a toborzás folyamatába.
A jelenlegi webes és hibrid alkalmazások esetében a felület kinézetén és a technikai akadályokon túl egy nagyon fontos hátrány még a sebesség is. Mivel a webes appok többnyire a rendszerbe épített JavaScript-motorokkal és nem feltétlenül a legjobb böngészőmotorral futtatják a kódokat, ezért lassúak és korlátozottak lesznek még ahhoz képest is, amit az adott készülékből ki lehet hozni. Kéménczy szerint azonban teljesen mindegy a felhasználóknak, hogy miért lassú egy alkalmazás, nem érdekli őket, hogy ez kinek a hibája és hogyan lehetne megoldani, egyszerűen csak csalódottak lesznek.
Nem platformok vannak, hanem élethelyzetek
A Prezi a különböző verziók fejlesztése közben arra jutott, hogy nem egyes platformokra kell rendelkezésre állni, hanem a meglévő és potenciális felhasználók élethelyzeteire kell reagálni. Ha bizonyos élethelyzetekben a Prezi-felhasználók mobilt használnak, akkor szükséges elkészíteni az igényeknek megfelelő alkalmazásokat. A prezentáció nézegetése esetében teljesen tiszta, hogy ha kapunk e-mailben egy prezit, akkor azt ma már jó eséllyel mobilon is megnyitnánk. Másrészt előadáskor is adja magát a mobil, hiszen mennyivel egyszerűbb egy okostelefonról vagy tabletről a projektorra küldeni a képet, mint egy noteszgéppel bíbelődni. Ráadásul a mobil eszköz kiváltja egyben a prezentert is, mert közvetlenül arról lehet az előadást léptetni.
Ez nagyon egyszerűen hangzik, neki is futott a Prezi csapata is és elkezdődött egy iOS-alkalmazás fejlesztése, ami eredetileg szerkesztő akart lenni, de végül csak nézegető lett belőle. Kéménczy elmondta, hogy amíg a böngészőben Flash-t használ a Prezi, addig a mobilon ez a lehetőség nincs meg vagy bonyolult. Az első kihívás az volt, hogy fejleszteni kellett egy renderelőmotort, ami önmagában véve is bonyolult, de később minden egyes új funkció, mint például a 3D háttér, új animációk vagy a hangok beillesztése után az újdonságokat a főverzió mellett a mobilos renderelőmotorokkba is bele kellett fejleszteni. Jelenleg 3 motor van a Prezi alatt: a böngészős mellett egy egészen jól működő iOS-es OpenGL 1.1-gyel, de shaderek nélkül, illetve egy frissebb androidos, ami már OpenGL 2.x alapokon nyugszik. Ha ez utóbbi jól működik, akkor implementálni fogják az iOS-es helyére is, így már csak két motorra kell dolgozni párhuzamosan.
Kis ajtók a nagy háttérszolgáltatáshoz
Szerencsére a mobilos fejlesztőcsapat nem rabja egyik programnyelvnek vagy technológiának sem, így könnyen képes alkalmazkodni és nem csak a Preziben, de a fejlesztési folyamatokban is "kizoomolni". Így a szolgáltatás egy kerek egész entitásként él majd a felhasználó fejében, aki tudni fogja, hogy egy adott élethelyzetnek megfelelő eszközön, az adott élethelyzetnek megfelelő funkciókat el tudja érni. A felhasználó megoldásokat keres a problémáira, nem fog a villamoson előkapni egy laptopot, ha meg akar nézni egy prezentációt, de az irodában sem fogja a mobilja kis képernyőjén szerkeszteni az előadását. Jó példa erre a fajta átjárhatóságra az Evernote és a Netflix: teljesen mindegy, hogy milyen élethelyzetben talál meg, mindenhová követ a tartalom és a funkció is.
Az Evernote is a natív alkalmazások híve, annyira, hogy asztali környezetben is egyedi alkalmazást készített Windows és OS X alá, de még Windows 8-ra is. A Netflix pedig minden létező platformra kiadott egy natív klienst, amin filmet lehet nézni. Érdekes példa a Spotify, ami pedig mindvégig natív alkalmazásokkal jött, s éppen most készített webes lejátszót. Ott sem arról van szó, hogy megtértek volna a HTML5-be, hanem rájöttek, hogy a telepítendő app már egy komolyabb elkötelezettség a felhasználók részéről, amitől magasabb lesz a kerítés. A webes app nem más, mint egy könnyű belépési pont, a Spotify ezzel egy régi lemaradást pótolt. A webes és a natív alkalmazás azonban annyira össze van drótozva, hogy akinek ez utóbbi fel van telepítve és egy beágyazott weboldali widgeten megnyomja a play gombot, akkor a dedikált appban indul el a lejátszás.
Nincs pardon
Összességében úgy tűnik, hogy a natív alkalmazások készítése nem egy lehetőség a webes szolgáltatók számára, hanem egy kötelező kör. Kéménczy azt meséli, hogy minden nagy webes cég, amivel a Prezi kapcsolatban áll (pl. Dropbox, Evernote, Spotify, Netflix, Facebook), egymástól függetlenül, különböző logikák mentén döntött a HTML5-alapú mobilos appok hanyagolása mellett. A HTML5 egyelőre nem váltotta be az ígéreteket, nem jött el az átjárhatóság, sem a tökéletes függetlenség. Mivel a platformspecifikus gesztusokat és dizájnelemeket egyébként is illik implementálni, ezért szinte mindegy, hogy párhuzamos webes fejlesztések vagy párhuzamos natív fejlesztések mennek. Sőt, a platform SDK-k által adott automatizáció, támogatás, fejlesztői eszközök miatt az utóbbi végeredményben még egyszerűbb is.
A non plus ultra pedig az, hogy maga a HTML5 sem egy egységes platform. Kéménczy szerint hiába ülnek le a legnagyobb szereplők időnként egy asztalhoz, a web továbbra is töredezett. A JavaScript-kódok és a HTML5-eszközök egészen másképp működnek Gecko, WebKit vagy az Internet Explorer motorja alatt. Több ezer különbség van, minden webes szolgáltatásnál lehet mondani egy példát, ami csak Firefox alatt működik, vagy éppen csak ott nem.