Így tervezz mobil alkalmazást 5 lépésben – 5. rész
Élesre állítás

Elérkeztünk a befejező részéhez az 5 részes “Így tervezz mobil alkalmazást 5 lépésben” cikksorozatomnak. Az előző részben az MVP kialakításáról volt szó. Ha lemaradtál róla, olvasd el, megéri! Tovább haladunk a végtermék legyártásában, és nem maradt más hátra, mint a kiadás.

Éles alkalmazás publikálása

Végre! Oly’ sokat vártál rá … számtalan álmatlan éjszaka … lemondás a hétvégi ágyban szundikálásról … de elkészült a nagy mű! Anyukád büszke lehet rád!

Persze álmodban sem gondoltad volna, hogy innentől kezdve pár hetente meg fogod ismételni roham tempóban az alkalmazás különböző verzióinak kiadását.

De térjünk vissza az első, felemelő pillanathoz! Kell egy ütős egysoros (one-liner) a Store leírásába. Ha ezen túljut a kedves felhasználó (nomeg a világ legszuperebb app címén), akkor egy kisebb esszében sorolod fel, hogy miért a te appod a legjobb a világon. Van már egy pár ezer hasonló a piactéren (de csak hasonló, mert a tiéd legalább az ikonban különbözik), de mégiscsak ezt éri meg a legjobban letölteni.

Kelleni fognak még képernyőképek, bár manapság már a 2 percnél nem hosszabb videók mennek. Rövid, tömör, lényegre törő.

Ja, hogy ingyenes az app? Miből lesz itt bevétel? Még jó, hogy beintegráltál reklám bannereket és videókat, amivel a felhasználóidat ki fogod kergetni a világból.

Sajnos statisztikai alapon a következő user interakciókat kell túlélnie egy appnak:

  1. a Storeban a keresési találatban elől kell végezni, hogy észrevegyék
  2. kellően jól rate-eltnek kell lennie (legalább 4)
  3. érdekes a címe (ASO-zott)
  4. ha a te appod a nyertes idáig, akkor remélhetőleg nem lett túl nagy méretű a telepítője, és lesz ideje kivárni, amíg letöltődik és települ
  5. nos, ha nem, akkor lehet, hogy a telepítés már a háttérfolyamatokban éri a kedves felhasználót
  6. pár nap múlva észreveszi, hogy ő bizony tényleg telepítette az kicsikédet
  7. vagy törli azonnal, mert kiderült, hogy ez foglalta el a tárhelyet a telóján, és emiatt nem ment ez az utolsó macskás fotó a chatben
  8. vagy megnyitja, és nem omlik össze azonnal. Ez mindenképpen jó ómennek bizonyul
  9. lehet, hogy összesen 2x fogja megnyitni: először és utoljára. Az alkalmazások sorsa ez. Kell gyorsan valami, letöltjük és már dobjuk is el. Hacsak!

Hacsak, az elejétől kezdve nem egy szolgáltatást céloztál, amihez mellesleg van egy app is. Enélkül nem tudja igénybe venni az szolgáltatásodat. Lehet, hogy egy honlap is elegendő rá, de egy mobil app az mégiscsak egy “Mobil App”. Egy honlappal összehasonlítva más az érzet, amikor nyomogatod. Ez kétségtelen.

A végére értem az egyes szempontoknak. Van számos buktató benne, de ha ezekben segítségre van szükséged, beszélgessünk a te ötletedről.

Végszónak pedig álljon itt az ismert képlet:

Ötlet Megvalósítás = Termék

Köszönöm, hogy kitartottál, és követted egy termék útját az ötlettől a késztermékig.

Szeretnéd megpróbálni, de nem tudod, hogy hogyan fogj neki? Szükséged van friss ötletekre, nézőpontokra? Jó lenne egy szakmabelivel átbeszélni a részleteket? Keress meg bátran, és beszélgessünk a dédelgetett álmodról, hogy mielőbb megvalósult termék lehessen belőle.

Ha most nem érdekes számodra egy beszélgetés, de követnéd az írásaimat, akkor iratkozz fel a hírlevelemre, hogy értesülj az új részekről. Kíváncsi vagyok a véleményedre, írd meg nekem!

Így tervezz mobil alkalmazást 5 lépésben – 4. rész
MVP létrehozása

Ez az 5 részes “Így tervezz mobil alkalmazást 5 lépésben” cikksorozatom 4. része. Az előző részben az UI tervezésről volt szó. Ebben a részben a legkorábban bemutatható termék-kezdemény létrehozásáról fogunk beszélgetni.

MVP létrehozása

A Minimal Valuable Product (mostanában az MLP = Minimal Lovable Product is felütötte a fejét) egy olyan kis termék kezdemény, ami már megáll a saját lábán. Egy-két dolgot tud még csak, de azt biztosan. Azt nyújtja, amit ígér. Fontos szem előtt tartani a “funkció a forma fölött” elvet. Nem baj, ha kicsit rusnya, de működjön. Természetesen vannak a használhatóságra negatívan ható tervezési gyengeségek, de ezeket most nem érintem.

Gondolj arra, hogy a szabó sem a végén adja oda a kész öltönyt, amikor már nem lehet rajta módosítani. Elhív egy próbára, amikor már össze van fércelve nagyjából az anyag, de még lehet módosítani rajta. Eleve neked is mások lesznek az elvárásaid egy ilyen félkész ruhadarabbal kapcsolatban. Még a kréta nyoma látható, ami a szabásból visszamaradt. Kilógnak cérnaszálak, de ezektől fejben el tudsz vonatkoztatni. Kényelmes lesz? Az a szín, amire gondoltam? A kivágás akkora lesz az elején, ahogyan megálmodtam?

Jó, a lényeg érthető. Kis lépésekből építjük fel az induló termékünket. Pár hetes ciklusokban (iterációkban) finomítjuk, teszteltetjük különféle csoportokkal. Milyen hosszú legyen egy iteráció? Nos, itt eltérnek a vélemények, de érdemes heti bontásban gondolkozni. Adódik ebből a legrövidebb az 1 hét legyen, de ne haladja meg az 4 hetet. Ez még belátható funkciómennyiség, amit lehet követni. Ez nagyban függ a saját, vagy a csapat ritmusától. Én a 2 heti verziózást követem, ami eddig bevált. Így kellően pörgős, de azért van idő szusszanásra. Ebbe még az is belefér, ha közben egy patch-et (hirtelen foltozást) kell kiadni.

Tesztelés, visszajelzés

Az MVP-t oda lehet adni ismerősöknek, barátoknak, családnak, hogy vegyék kézbe. Lehet szervezni bemutató eseményeket, interjúkat, ahol fontos visszajelzéseket gyűjthetsz be. Ha meg tudod oldani, vedd fel videóra a felhasználó első találkozását a termékeddel. Sokat tanulhatsz belőle. Írd fel a kérdéseket. Meg fogod látni, hogy ebből ki fog rajzolódni egy mintázat.

Hány fővel kell ezt elvégeztetni? A szakmában az átlag a 3-7 db interjú már elégségesnek szokott mutatkozni. Ekkor kiderülnek a fő hibák, ami számodra nem volt egyértelmű a fejlesztés során. Ha tudod, válassz a célközönségedből minél változatosabb személyiségeket, így átfogóan lefeded a leendő piacodat. Összegezve a találatokat, ezek egyben meghatározzák a következő időszak fejlesztési tervét is. Ez már egy, a valós felhasználói közösségtől jövő visszajelzés, ami innentől nem találgatásokra épülít (empírikus módszer).

A következő, egyben befejező részben az alkalmazás publikálása lesz terítéken. Ha tetszett ez a rész, iratkozz fel a hírlevélre, hogy értesülj az új részekről. Kíváncsi vagyok a véleményedre, írd meg nekem!

Vajon nyugdíjba küldi a Flutter a WordPress-t?

A WordPress oldalak itt vannak velünk régóta. Sikere töretlen, hiszen nagyon egyszerű elindulni vele. Több ezer kiegészítőt írt hozzá a közösség, akik életben tartják a jóhírét. Bármilyen feladatra biztosan hogy van már tucatnyi plugin. Szinte bármelyik rendszerrel összekapcsolható, de a legnépszerűbbekkel biztosan. A Flutter képest ezt megtörni?

Mi az előnye? Programozói tudás nélkül, pár óra alatt, akár kezdőként is létrehozhatjuk az saját alap honlapunkat. Ha választunk hozzá egy template sablont, akkor a kinézettel sem lesz gondunk. Van, aki gyűlöli, van, aki imádja. Igen megosztó platform.

Hogyan jutott eszembe ezek után az érvek után összehasonlítani a Flutter-rel? A Flutter egy UI kit a Google-től, ami több platformot is támad egyszerre: mobil, web és lassacskán az asztali alkalmazásokat. A Google nem titkolt célja, hogy legyen szó bármilyen képernyőről, ott elérhető lesz a Flutter. Vagyis a közös Dart nyelven megírt kód bármelyik eszközön működni fog. Ez jó hír, mert a fordítással nem nekünk kell bajlódni.

A korai tapasztalatok

Azt persze nem lehet megjósolni, hogy mikorra lesz széles körben is népszerű ez a technológia. Az látszik, hogy mégha új nyelvet is kell megtanulni (az alkalmazásokat Dart nyelven kell megírnunk), a sikere elvitathatatlan. Egyszer kell megírnunk az alkalmazásunkat, és cserébe Androidra, iOS-re, bármely böngészőre optimalizálva elkészítettük. Ez biztosan a jövőben nagyon erős szempont lesz egy, a projekt pénzügyeiért (is) felelős Projek Managernek. Vagy egy CEO-nak, aki most indítja a startup-ját.

Több, mint fél év tapasztalat után állíthatom, hogy a Google beváltotta az ígéreteit. Valóban egy megfelelően gyorsan fejleszthető alkalmazás keretrendszert hozott létre. A hozzá kapcsolódó fejlesztő eszközökkel kiegészítve. Ezeket belegyúrták az Android Studióba, és szintén erős támogatást kapott a VS Code. Rájöttek, hogy nem csinálhatják meg újra ugyan azt, mint az elején, hogy gyenge eszközöket adnak a lelkes fejlesztők kezébe. Mindehhez létrehozták az ingyenes package-ket hosztoló pub.dev fejlesztői oldalt, ahol több ezernyi, kész, és minősített csomagot tudunk egy mozdulattal felhasználni a saját alkalmazásunkban. A közösség pedig kapva kapott rajta, és fantasztikus dolgokat hoznak létre az open-source égisze alatt.

Nos, hogy valaha lesz-e helycsere a két platform között, az még várat magára. A Flutter web nem az out-of-the-box megoldás egyelőre. Kívácsian várom a template rendszereket, konfigurátorokat, amikkel pár perc alatt mindenki létrehozhatja a saját mobil alkalmazását. Ehhez egyre több, ismert márka csatlakozik: Adobe XD, Supernova Studio (Mac-re egyelőre). Ezek a szerkesztők már támogatják, hogy Flutter alkalmazás készüljön a megtervezett designból.

Következtetés

Ez persze még kicsit odébb van. A designereknek kedvezett a Google/Flutter és más team-ek együttműködése. Minden esetre elindult egy jó folyamat: azáltal, hogy a Google definiálta a Material Design-t, a Cupertioni srácok HIG-t (Human Interface Guideline) és a Flutter ezeket implementálja, ezáltal bármelyik fejlesztő egy alap szintű UI-t faraghat az alkalmazásához. Egy kellően jó kinézet már akkor is kijöhet a kezünk alól, ha éppen nem bűvöl el minket a pixelek tologatása. Ez pedig közelíti egy fejlesztő és egy designer közötti távolságot.

Így tervezz mobil alkalmazást 5 lépésben – 3. rész
Felületek tervezése

Ez az 5 részes “Így tervezz mobil alkalmazást 5 lépésben” cikksorozatom 3. része. Az előző részben az ötlet validálásáról volt szó. Következzék a felhasználói felületek (UI) tervezése.

Mostanra eljutottál oda, hogy pontosan tudod, hogy kinek, és mit szeretnél előállítani. Az öteltedet bemutattad másoknak is. Ha nem csak a családi-baráti körben, akkor hivatalosan is validáltad! Ez az! Most már nincs más hátra, mint egy szerethető digitális terméket formálj belőle.

Ez egyszerűnek hangzik, hiszen annyi eszköz érhető el ehhez, hogy pillanatok alatt ki lehet dobni a vázlatot, ha nem tetszik és újat csinálni helyette. Ez mondjuk a nehézsége is egyben, mert honnan fogod tudni, hogy mikor kellően jó?

A játékosítás

Ez most hogyan jön ide, kérdezhetnéd? Nem játékot akarok készíteni, csupán egy használható terméket. Nos, nem is erről van szó. A játékosítás, vagy más néven gamification nem túl régi fogalom. Ez Pusztai Ádám, hazai játékosítási szakértő szavai után szabadon kb. így hangzik: “Játékos elemek alkalmazása, alapvetően nem játék környezetben.” Na, ezzel nem léptünk előrébb. Akkor mi is ez? Nagyjából arról van szó, hogy a tervezés során odafigyelünk a felhasználóra, hogy benne tartsuk egy folyamatban, mégha nem is kellően izgalmas, pl. egy villany-számla befizetése.

Ennek egész tudománya van, ezt most nem fogom részletezni, de olyanokra gondoljuk, hogy:

  • a felhasználó tudja, hogy melyik képernyőn van, és innen hogyan tud továbblépni
  • mindig kap visszajelzést egy action után: gomb színe változik; felugró ablakban infó, stb.
  • tudja, hogy hol tart a folyamatban (haladás jelző: 3. oldalon áll az 5-ből, tehát még 2-t kell kitöltenie, pl. egy formon)
  • valamilyen szükségletét elégíti ki; problémáját oldja meg; veszteségét minimalizálja; birtokolhat valamit; bátorítást kap, stb.

Erről majd bővebben írok egy másik bejegyzésemben. Ennyi szakmai felkészítés után jöjjön a lényeg, a csillogó-villogó felületünk, amivel elkápráztatjuk a felhasználónkat.

Felületek tervezése

A tervezés miatt nem kell feltétlenül megtanulni egy új eszközt. Ha ez sok időbe, energiádba kerülne, vesd el ezt az irányt! Sokkal többre mész azzal, ha rövid idő alatt láthatóvá teszed a fő képernyőket. Emelj ki egyes részleteket, amiket fontosnak tartasz. Játszadozz a logóval, az elrendezésekkel!

Léteznek erre kiváló eszközök. Nem is gondolnád, hogy a jól bevált kockás (vagy sima) füzet bőven megteszi az elején. Egy marék színes filccel/tollal csodákra vagy képes. Ez a legtermészetesebb, ami kéznél van. Bátorítalak rá, hogy az első pár tervet kézzel rajzold meg. Utána jó emlék lesz visszanézni ezeket, amikor már működik a termék.

Kezdésként fogod a telefonodat, ráteszed a papírra, körberajzolod, és már meg is van az 1:1 méretarányos sablonod. Már csak a képernyőt kell belerajzolni. Ebben az a jó, hogy ezzel a módszerrel könnyedén le tudsz gyártani 10-20-100 képernyőt rövid idő alatt. Egyszerű, igaz!?

Az a jó eszköz, amit könnyedén és szívesen használsz.

Na jó, te mégis tech srác vagy, akkor ide valami nagyágyú kell. Ott van a Figma, vagy az InVision ingyenesen is kiválóan használható online szerkesztők. Csoportos együttműködésre nagyszerűen használatóak. A tervek megoszthatóak egymással, csakúgy mint egy OneDrive-os doksi. Egy linken keresztül akár telefonon is kipróbálhatóak. Meglepően gazdag élményt nyújtva.

Ha Mac-es vagy, akkor a Sketch havi $9-ért már a tiéd lehet. Az Apple híres a designereknek készült eszközeiről, és ez is egy kiváló eszköz.

Az Axure egy másik fizetős program, ami megéri az árát. Kifejezetten prototypeing-ra van, drótvázak tervezésére.

A klasszikus Adobe XD toolja biztosan jóval több funkcióval érkezik, mint amire valaha is szükséged lesz. Szép áttűnések, responzív felületek, animációk, interakciók hozhatók létre vele. Érdemes kipróbálni.

Szándékosan hagytam a végére az Android Studio-ba (AS) jól integrálódó Flutter UI kitet. Ha van affinitásod a kódoláshoz (remélhetőleg ez így van), akkor ajánlom ezt a kombinációt is. A Flutter nem csak AS-ban, hanem a Visual Studio Code (VS Code) programban is kiváló támogatást kap néhány kiegészítő telepítésével. Amennyiben ebben az irányban indulsz el, akkor lényegében az alkalmazásod fele már megvan. Legalábbis a felületek, és néhány kezdetleges interakció az indulásnak. Ez aztán tovább fejleszthető, és a teljes alkalmazás lefejlesztésére jó. Ráadásként egyből Android-ra és iOS-re. Az optimális működésről pedig a keretrendszer gondolkodik. Neked csak a fantáziádra kell hagyatkozni.

A következő részben az MVP-vel folytatjuk. Ha tetszett ez a rész, iratkozz fel a hírlevélre, hogy értesülj az új részekről. Kíváncsi vagyok a véleményedre, írd meg nekem!

Így tervezz mobil alkalmazást 5 lépésben – 2. rész
Validálás

Ez az 5 részes “Így tervezz mobil alkalmazást 5 lépésben” cikksorozatom 2. része. Az első részben az ötlet kitalálásáról volt szó. Következzék az ötletünk validálása.

Validálás

Az előbbi lépés, amikor még csak ötletelünk, sokszor elegendő lehet, hogy kiderüljön, működne-e? A leírt terveket, rajzokat meg tudjuk mutatni egy pár ismerősünknek, és fontos visszajelzéseket kaphatunk tőlük. Persze nem árt odafigyelni, hogy kitől kapjuk a visszajelzést.

A 3F (Friends-Family-Fools) véleménye könnyen téves útra vihet téged. Ezt hosszasan elemzi Rob Fitzpatrick: Anyu teszt (Mom test) című könyvében. A lényeg, hogy a közeli hozzátartozóidtól, barátaidtól biztosan nem fogod megkapni a valós véleményeket, hiszen nem akarnak majd letörni és elvenni a kedvedet. (Ki merne ilyet felvállalni manapság?) A könyv alapján a lényeg, amit mond, hogy ne jövőbeli ígéretekre, hanem a múltban megtörtént eseményekre alapozzunk. Mit jelent ez pontosan?

Párbeszéd Anyukád és közted (tévút):

Te: Szia Anya!
Anyu: Helló Kicsim!
Te: Képzeld, festettem egy nagyon szép képet. Mit szólsz hozzá, te megvennéd tőlem?
Anya: Húú, de gyönyörű! Persze, hogy fizetnék érte. Ezzel még sokra viheted. – és el…
Te: Köszi, tudtam, hogy tetszeni fog.

Nos, ígérni bárki tud. Nyilvánvaló, hogy nem akart téged megbántani, hiszen bátorítani szeretne. Így nem megy bele abba a játékba, hogy letörjön az elején. Érezhető, hogy ebből nem lesznek milliós darabszámú eladásaid.

Párbeszéd Anyukád és közted (anyu-teszt):

Te: Szia Anya!
Anyu: Helló Kicsim!
Te: Képzeld, festettem egy nagyon szép képet. Mit szólsz hozzá?
Anya: Húú, de gyönyörű! Kinek festetted?
Te: Igazából magamnak. Te szoktál hasonló képeket vásárolni? Bár igaz, nem látok hasonlót sem a házunkban.
Anya: Nem igazán. Újszerű ez a stílus tőled, de ilyet biztosan nem tennék ki a lakásba.
Te: Mi az, ami nem tetszik benne?
Anya: Az például, hogy …
Te: Köszi, tudtam, számíthatok a véleményedre.

Itt látható, hogy egészen másképpen alakult a beszélgetés. Az anya sem érezte, hogy feltétlenül áradoznia kellene a festményről. Egy objektívebb síkra terelődött a beszélgetés, amiben kiderült az igazság a munkával kapcsolatban. Siker!

Ha elfogytak a 3F klub tagjai, akkor hogyan lehet még további infókhoz jutni? Olvass fórumokat, blogokat az adott témában. Regisztrálj be egy oldalra, csatlakozz egy csoporthoz, és ott kérdezz. Aztán csak figyelj, hogy milyen válaszok érkeznek. Ez már jó kiinduló lehet, és tovább finomíthatod az ötletedet. Ez lehetőséget ad arra is, hogy egy részpiacra (niche, ejtsd: nís) szükítsd a te megoldásodat, mert te nem akarod MINDENKI problémáját megoldani. Te a “24-26 éves, pályájukat most kezdő egyetemet végzett, férfi, városban élő, programozóknak akarsz mobil fejlesztési kurzust adni.”. Ez csak egy példa, de látható, hogy mennyire specifikusan fogalmaztam meg.

Ezek persze csak néhány példája annak, ahogyan tudod validálni. Az interjúztatás (f-2-f, O3), a kérdőív kitöltetése, a mobil app marketeken a review-k átolvasása tovább színesítik a képet.

A begyűjtött válaszok alapján körvonalazhatod magadnak azokat a személy-csoportokat (perszóna), akikre tudsz vizualizálni, miközben kidolgozod az apró részleteket, vagy amikor a post-okat írod, vagy a hirdetéseket szövegezed.

A következő részben a felületekkel folytatjuk. Ha tetszett ez a rész, iratkozz fel a hírlevélre, hogy értesülj az új részekről. Kíváncsi vagyok a véleményedre, írd meg nekem.

Így tervezz mobil alkalmazást 5 lépésben – 1. rész
Az ötlet

Ebben az 5 részes sorozatban összeszedem azokat a gondolatokat, mérföldköveket, amikkel én találkoztam egy-egy projektem kapcsán.

Kezdetben úgy voltam vele, hogy bármire jól jönne egy app. Ez a gondolat elmékeim szerint Steve Jobstól ragadt meg a fejemben: “… a jövőben mostantól mindenre kelleni fog egy app…” – mondta az iPhone 1-es bemutatóján. Legalábbi valami nagyon hasonlóan hangzott.

Nos, ezzel nem tévedtem sokat, bár ha meggondoljuk, hogy miért (?) kell app, akkor egészen sokáig kell keresnünk. Mi az, amit egy responsive weboldal nem tud elvégezni? Persze van olyan dolog, de ezt mindig tartsuk észben! (A kalapács és a szög esete ugyebár.)

Az tény, hogy megalkotni egy mobil alkalmazást varázslatos dolog: szélsebesen natívan fut a telefonodon, bárkivel megoszthatod, színes-szagos, offline működik stb. Egyszóval semmihez sem fogható érzés.

Ha benned is hasonló érzelmek munkálkodnak a fentieket olvasva, akkor vágjunk is bele!

A fő lépések

  1. Az ötlet
  2. Validálás
  3. Felületek tervezése
  4. MVP létrehozása
  5. Éles alkalmazás publikálása

Az ötlet

Ötlete mindenkinek van, ez nem szokott problémát okozni. Ha mégsem jön magától, akkor vannak rá professzionális eljárások, hogy hogyan csalogassuk ki azt a bizonyos ötletet az agytekervényeinkből. Kevésbé tudományos, ha bezárkózunk egy szobába, és addig ki nem jövünk, amíg nincsen egy épkézláb ötletünk. Ezzel már el lehet indulni.

Sokszor a legbanálisabb, legelvetemültebb, gyermeteg ötletből jöhet ki valami egészen fantasztikus. Ha végigsöpörsz az alkalmazások listájában a telódon, akkor nagy valószínűséggel egyet értesz velem.

Ha megvagyunk az ötlet megtalálásával, akkor érdemes kicsit kidolgozni, eljátszogatni a lehetőségekkel. Elő a Post-it-eket, lehet ragasztgatni, rajzolni egy füzetbe.

Az ötletünknek lesz egy fő vonala. Egy olyan pontja, amire mindig vissza fogunk térni, akárhogyan is forgatjuk a lehetőségeket. Ez lesz a magja, ami megalapozza a végterméket. Ez egy fontos felismerés: egy alkalmazás csináljon egy dolgot, de azt jól. Érdemes így végiggondolni az ötletünket. Milyen problémát old meg? Kinek a problémáját oldja meg?

A fenti kérdésekre vannak technikák, amivel ezeket ki tudjuk fejteni. Egyik ilyen az “Empathy map” (kb. beleérzés térkép).

Empathy map

Egyedül, vagy csoportban elvégezve végezzük el a feladatot. Töltsd le ezt a kis segítséget, nyomtasd ki egy A3-as vagy A2-es lapra, és Post-it-tel ragaszd rá a válaszokat. A részterületeket végigjátszatjuk, ha egy konkrét célszemélyt (perszóna) kiválasztunk, és hozzá intézzük a kérdéseinket. Beleülünk az ő helyzetébe, és körbenézünk, hogy:

  1. Mit gondol és érez
  2. Mit hall nap mint nap?
  3. Mit lát nap mint nap?
  4. Mit mond és hogyan cselekszik?

Ezután írjuk be az is, hogy mik lehetnek a Veszteségei (problémái), amiket mi meg fogunk neki oldani? Mik lesznek a Nyereségei, ha a mi termékünket használja? Ebből már ki fog jönni egy csomó hipotézis, amiket már tudunk validálni.

A következő részben a validálással folytatjuk. Ha tetszett ez a rész,iratkozz fel a hírlevélre, hogy értesülj az új részekről. Kíváncsi vagyok a véleményedre, írd meg nekem.

Ezért használják már félmillióan a Flutter-t
Ideje újat tanulnod

Újabb bejelentések történtek a Google háza táján. A Flutter Spring 2020 Update nyilvánosságra hozta, hogy több, mint 500 000 fejlesztő használja már az egyre népszerűbb Flutter UI kit-et. Ez nem meglepő, hiszen cross-platformos megoldásokban (Android, iOS, web, desktop, …) egyelőre a legjobb megoldásnak találtatik.

Előnye, hogy egy kódbázissal a fent említett platformokra elkészül a kód, és a fordítást (build) kell elvégezni a megfelelő rendszerre. A közös kódnyelvre a Google a saját Dart nyelvét választotta. Ez azt is jelenti, hogy meg kell tanulni egy új nyelvet. Bár ha van alapvető objektum-orientált előképzettségünk, akkor ez nem jelent gondot. Összehasonlítva pl. a Java teljesen OOP megközelítésével, itt lehetőség van az osztályokon kívüli, modul szintű egységek szervezésére is. Ez nagy előny, és rugalmasságot ad a kezünkbe. Összességében elmondható, hogy egy egyszerű, de mondern nyelvről van szó.

Ennyit a technikai háttérről, nézzük a számokat!

A fejlesztők 60%-a Windows-on, 27%-a macOS-en, 13%-a Linux-on fejleszti a kódját.

A gyors UI fejleszthetőség miatt felkapott a startupok körében (35%), de a vállalati használat is jelentős (26%). Emellett említsük meg, hogy a design studiók is elkezdték használni (7%). Ez főként annak köszönhető, hogy a Flutter-t már a legelejétől fogva a Google a fejlesztőkkel egyeztetve, és kellően felvértezett eszközarzenált adott a kezünkbe. (Nem akarta elkövetni azt a hibát, amit pl. az Android esetében, hogy csak évek múlva sikerült valamelyest jól használható tool-okat adni a fejlesztők kezébe.)

A Flutter öt legelterjedtebb területe India, Kína, az Egyesült Államok, az EU, és Brazília.

Flutter a vállalatoknál

A Flutter növekedése gyors ütemben bővül a vállalati ügyfelek körében, és a Google kutatásai azt mutatják, hogy ennek az a fő oka, hogy gyorsan lehet teljesen saját arculatot kialakítani úgy, hogy a többplatformos megoldást támogatja. Egységesíteni lehet a front-end kialakításánál a fejlesztő csapatot egy közös keretrendszerre, mindamellett, hogy gyorsan készülnek el a funkciók Android-ra és iOS-re egyszerre.

Fontos, hogy rendelkezésre állnak sok és nagyon jó minőségű, professzionális építőkockák, amikből a felületek, vagy a drótvázak létrehozhatóak.

Az új verziók kiadását újragondolták

A keretrendszer egymást követő verzióinak stabilitása és egy új kiadás dátumának megjósolhatósága fontos lépés volt. Ezt szem előtt tartva, nagy hangsúlyt fektetnek rá, hogy még egyértelműbb legyen a különféle verziók stabilitása. Egy gyors fejlesztést követelő megoldásban elengedhetetlen, hogy az új verziók megjelenése ne borítsa fel a fejlesztőcég életét. Ezek a módosítások már az áprilisi kiadásokban is tetten érhetőek lesznek.

Konlúzió

Látható tehát, hogy a Google nagy erőket mozgósít, hogy minél jobban megszerettesse az új rendszerét a nagyközönséggel. Használva a Flutter-t nekem az a tapasztalatom, hogy nem az a kérdés, hogy hogyan, hanem hogy mit szeretnék megcsinálni. Több éves Android fejlesztői tapasztalataim alapján elmondhatom, itt valóban jól ki vannak találva az építőkockák. Könnyedén összerakhatóak az alkalmazások. Az eszközök használata (ami folyamatosan bővül) elgondolkoztat, hogy akár már egy drótvázat is érdemes kód szinten elkészíteni (vagy generáltatni, pl. Adobe XD-ben). Ebben az esetben a kód fele már megvan, a UI.

Az egyszerűségéről te magad is meggyőződhetsz, ha be akarod piszkítani a kezedet. Ebben az írásomban letölthető kód példával bemutatok egy pár alap dolgot.

Külön szimpatikus az a törekvése a Google-nek, hogy a “mezei” fejlesztőkből egycsapásra design-erek válhatnak. Persze mindegyik egy külön szakma, de a közös nyelvezet kialakításában mindenképpen segíthet.

Ha tetszett az írásom, oszd meg velem. Amennyiben javítani valót találsz, ne tartsd magadban. Várom a hozzászólásaidat a témához.

A mobil app fejlesztés új formája
Minden mobilfejlesztő álma

A Google gurított egy nagyot a multiplatformos mobil app-ok fejlesztése teréln. Ennek 2019 adta meg a végső lökést a Flutter UI toolkit erős promóciójával. A Flutter egy olyan multiplatoformos keretrendszer, ami megsokszorozza a produktivitást a fejlesztői csapatban. Nem pusztán arról van szó, hogy Android-ra, iOS-re, Desktop-ra és Web-re (és a sor folytatódik) egy kódbázissal tudunk fejleszteni.

Maga a fejlesztési folyamat nagymértékben felgyorsul azáltal, hogy élő nézetet kapunk a felületről, amint elmentjük a kód módosításunkat. Ennek ugyan az az ára, hogy a kódot a Google által fejlesztett Dart nyelven kell írni. Persze aki ismer már egy objektumorientált nyelvet (Java, JavaScript, TypeScript, C++, Kotlin, stb.) ez nem akadály. Akinek pedig ez az első nyelve, az egy modern nyelvet fog megtanulni. A kódolás szintaxisának megtanulása pár órában, legfeljebb napokban mérhető.

Minden “Widget”

Így van! Bármihez is kezdük a felületen, biztosan szükségünk lesz egy widget-re. De mi is ez valójában? A widget-ek olyan kis építőkockák, amikből független, előre megírt, de nagyban személyes igényeinkre szabható felületek hozhatóak létre. Jó-jó, de mit tud? Gondoljunk egy egyszerű gombra. Ez egy widget, a maga absztrakciójával. Ha van egy gombunk, pár paraméter beállításával módosítható a színe, a betű színe, a betű stílusa, a sarkok kerekítése. Egyszóval bármi. Értsd, tényleg bármi!

Material csomag

A legjobb az egészben, hogy a Google ehhez felépített egy teljes grafikai UI/UX open-source leírást. Ezt mérnökök sok-sok év tapasztalatával gyűjtötte össze, hogy mi mutat jól egy mobil kijelzőjén, és mitől lesz egyértelmű az interakció. Iránymutatást ad a design alapelveire, stílusokra, bevált módszerekre. Az egyes komponensek (widget) és ikonok használatára, tervezéséhez nyújt segítséget. Nem megfeledkezve az Accessibility-ről, vagyis gondolt azokra is, akiknek az alapvető kezeléssel nehézségei adódnak. Pl. látássérült, hallássérült vagy kognitív hiányosságai vannak.

Érdemes ellátogatni az oldalukra https://material.io. A későbbiekben vissza fogunk nyúlni ehhez a remek csomaghoz.

Példák

Ne múljon el ez az írás anélkül, hogy egy pár felületet megnéznénk.

Emlékszünk még az Androidon az Activity-kre és a Fragment-ekre? Nos, itt ezzel nem kell bajlódnunk. A navigációt pár sorral lerendezzük. A tranzíciók szépen meg vannak csinálva alapból, de tudunk finomítani rajtuk.

basic screen navigation with buttons
Alap képernyőképek navigációval

Button

Egy gomb definiálása a legegyszerűbb egy RaisedButton widget-tel. Ez be van még csomagolva egy Transform.rotate widget-be, ami az elforgatást intézi.

Transform.rotate(
                angle: 0.2,
                child: RaisedButton(
                  color: Colors.amber,
                  elevation: 5,
                  shape: RoundedRectangleBorder(borderRadius: BorderRadius.circular(20)),
                  child: Padding(
                    padding: const EdgeInsets.all(10.0),
                    child: Text(
                      "Switch to Page Two",
                      style: TextStyle(fontSize: 20, color: Colors.green),
                    ),
                  ),
                  onPressed: () {
                    Navigator.of(context).push(
                      MaterialPageRoute(builder: (context) => PageTwo()),
                    );
                  },
                ),
              )

ListView

Lista nézet egyszerűen. Nem kell a RecycleViewHolder rémálommal bajlódni, mint korábban. Felsoroljuk a ListView-ban a widget elemeket, és készen is vagyunk.

 @override
  Widget build(BuildContext context) {
    return Scaffold(
      ...
      body: Container(
        padding: EdgeInsets.all(10),
        color: bgColor,
        child: ListView(
          children: [
            ListItem(order: 1),
            ListItem(order: 2, onPress: _navigateToPageTwo(context)),
            ListItem(order: 3, onPress: _navigateToPageTwo(context)),
            ListItem(order: 4),
            ListItem(order: 5),
            ListItem(order: 6),
            ListItem(order: 7),
            ListItem(order: 8),
            ListItem(order: 9),
            ListItem(order: 10),
          ],
        ),
      ),
    );

AppBar

Az oldal teteji navigációra ugyancsak megvan a kész megoldás. Az AppBar-nak elnevezett widget ezután tetszőlegesen paraméterezhető. A szokásos materialos felületeket tudja. Ha nem lenne elegendő, akkor természetesen testre szabhatjuk.

SlivertAppBar

Komplex mozgási effekt az AppBar-t kiegészítve. Ezzel nagyon látványos navigációt tudunk készíteni. Lásd a Page Two-n lévő app bar-t a tetején.

A kódok elérhetőek a GitHub-ról.

Kíváncsi vagyok a véleményedre. Írd meg kommentben, ha tetszett, vagy valami javításra szorul.