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.