A napokban kerül élesítésre az fpredony.hu domain-en egy újabb munkám, ami a korábbi parafamiskolc.hu weboldal alapjait használja, de van benne pár trükkös megoldás mind a felhasználók számára, mind programozói szemszögből nézve.
A projekt során úgy érzem, hogy sokat fejlődtem, kezdem érezni a jelenlegi fejlesztési módszerek hátrányát, amit a következő projektnél mindenképp befogok építeni. Ebben a bejegyzésben összegyűjtöttem pár gondolatot a projekttel kapcsolatban.
Árkalkulátor
Az volt a kérés, hogy a vásárló tudjon egy árkalkulátorral ajánlatot kérni a cégtől. Ezért beépítésre került egy árkalkulátor, amiben meg lehet adni a termék szélességét, magasságát (már ha tudja a vevő), és az alapján számol egy árat. A műanyag redőny és pár terméknél ez nem különösebben jelentett gondot, hiszen ott sima m2 ár van. A trükkös dolgok a rolettáknál és a napellenzőknél jelentkeztek.
A legtöbb hasonló oldalnál általában valamilyen táblázatban mutatják meg a vevők számára, hogy mennyi az annyi; ha X szélességtől Y szélességig és Z magasságig W az ár. Itt viszont megoldottam, hogy a kalkulátorral ez működjön, tehát ha valaki beír adott értékek közötti szélességet/magasságot, akkor a hozzátartozó árral fog számolni a rendszer. Az egyértelműség jegyében persze bekerült egy mérettáblázat gomb az ilyen termékek alá, így bárki leellenőrizheti, hogy tényleg annyiba fog-e kerülni.
A táblázat nincs beégetve a rendszerbe, azt az adminisztrációs felületről a kezelő bármikor elérheti és módosíthatja.
Azt lehet mondani, hogy gyakorlatilag az egész oldal legnagyobb mutatványa az árkalkulátor, ami bár eltérően működik a hasonló tematikájú oldalakon találhatóktól, mégis úgy gondolom, hogy a felhasználó számára egyértelműbb a használata.
Technológia és projekt szinten
Talán kevésbé érdekes lehet egy átlag felhasználónak, a szakmabelieknek meg már-már egyértelműnek tűnhet néhány pont ezek közül, de összeírom, hogy ebben a projektben miket használtam segédként, és mi az amiben egyértelműen fejlődtem ezalatt az idő alatt.
Github
Talán a legtöbbeknek elég egyértelmű, hogy van Github fiókjuk, és az is, hogy rendszeresen használják azt. Sajnos én nem az a fajta programozó vagyok, akinek a születési anyakönyvi kivonatában már szerepel a Github fiók url-je, így én mindenképp büszke vagyok arra, hogy először használtam a projekt teljes ideje alatt a Github-ot rendszeresen.
Persze korábban is használtam már időszakosan, de olyan még csak most volt, hogy egészen a legelejétől kezdve használtam.
Nagyon megkönnyítette a munkát, hiszen ha másik gépnél voltam kénytelen folytatni a weboldalt, akkor csak lepulloztam a repot, végrehajtottam az adatbázis módosításokat és mehetett minden annak rendje és módja szerint.
Trello
Ezt is biztos sokan ismerik IT körökben, kisebb projekteknél szokták használni. Gyakorlatilag egy minimalista Kanban táblázat, ahol létrehozhatsz listákat, kártyákat, feladatokat, határidőket és címkéket. Trello-t is használok jó ideje, de most léptem egy szintet projektmenedzselés szempontjából is. Létrehoztam pár alap listát, mint pl TODO, Kérdéses, Kész, Tervezés.
A TODO-ba bekerültek azok a feladatok, amiket meg kell csinálni, ezek kaptak egy-egy kártyát. Ezután jött a priorizálás (a priorosabb feladat került legfelülre), majd kaptak címkéket (itt most sprint címkéket kaptak pl 0801-0816 jelölte az augusztus 1 és 16 közötti sprintet), majd állítottam nekik határidőt is.
Amivel készen voltam kipipáltam a határidő melletti kis checkboxot és áthúztam a készbe. Ami esetleg felmerült kérdés fejlesztés közben azt összegyűjtöttem és 1-2 napon belül írtam egy emailt a megrendelőnek, vagy felhívtam.
Tudom, ez még mindig a projektmenedzselés kapudrogja, de nagyban megkönnyítette a dolgomat, hogy láttam, mivel haladok, mit kell még megtennem, mi az ami nincs kész, hol léptek fel függőségek.
Itt ami tanulságként szolgált számomra: a tervezést időben el kell kezdeni, és alaposabban kell végrehajtani. Sok kérdés felmerülhet már ilyenkor, amit jó tisztázni, és nem fejlesztés közben kell azokhoz improvizálni.
Babel + Webpack
Na ez egy izgalmas dolog volt, mivel az egész projekt úgy kezdődött, hogy full “alap” módon írtam meg a JS fájlokat, és csak később kezdtem el átírni mindent. Mit jelent az “alap” mód? Semmi ES6 szintaxis, semmi class, se const se let, se arrow function, semmi.
Kérdezhetnétek, hogy miért? Nos, elég csak ránézni a kompatibilitás táblázatokra és rájövünk, hogy bizony csak a nagyon új böngészők támogatják ezt a JS kód szintaktikát. Nyilván a legtöbb átlag felhasználónak nem a legújabb Chrome/Firefox van feltelepítve a gépére. A legtöbben még lehet csak Windows XP-t jobb esetben Windows 7-et használnak valami alap Internet Explorer szörnyszülöttel. Így elég egyértelmű volt, hogy ha azt akarom, hogy sokak számára elérhető és használható legyen az oldal, de közben szeretnék szép kódot írni, akkor valamit tennem kell.
Mi lehet hát a megoldás?
Az egyik megoldás, hogy a fejlesztő nem használja ezeket az újdonságokat, megragad a régi bevált módszereknél, és szintaktikáknál. Ennek egyik előnye, hogy lényegében bárhol és bármikor fog tudni JS kódot írni, a hátránya, hogy nem fogja ismerni a modern megközelítéseket, és még az is elképzelhető, hogy több időbe és erőforrásba fog neki kerülni a régi kódot legyártani, mint az újban megírni. Ilyen kisebb projekteknél EDDIG én is ezt az utat választottam, aztán jött az isteni sugallat: mi lenne, ha valahogy meg tudnám oldani az ES6 kód ES5-re átalakítását?
Ekkor kezdtem utánanézni a megoldásoknak és rögtön szembe jött velem a BabelJS projekt egy jó kis Webpack-kel karöltve. A kettő együtt ugyanis elvégzi helyettünk a kód ES5-re alakítását (BabelJS), illetve az importok okozta függőségek feloldását is (Webpack). Csak néhány parancs kell, pár config beállítás módosítása és már működik is.
Egyetlen hátránya van csak a Webpack-nek még pedig az, hogy korábban tfh betöltöttem egy default.js-t minden oldalhoz, meg mondjuk az egyik oldalhoz van egy egyedi custom.js.
- A látogató elérkezik a főoldalra, ott nincs custom.js, a böngésző begyorsítótárazza a default.js-t.
- A látogató átmegy arra az oldalra, ahol a custom.js van, akkor a böngésző a default.js-t már nem fogja letölteni, hanem gyorsítótárból előhúzza, és csak a custom.js-t kell letöltenie.
Webpack esetén a custom.js-be bele van forgatva a teljes default.js, így gyakorlatilag minden oldal megtekintésénél a teljes default.js tartalmat is le kell töltenie.
Szerencsére a minifikációval együtt nem túl nagyméretűek az állományok: 20-22kb, aminél azért valljuk be még ez a bejegyzés is többet nyomna szövegfájlként.
Biztos vagyok benne, hogy ezt is lehet jobban csinálni, és a fenti probléma is megszüntethető. Mindenestre nagyon örülök annak, hogy sikerült ezt is beépítenem a projektbe. Én örülök, hogy végre szép JS kódot írhatok, a látogatók meg örülnek, hogy még IE11-en is látogatható az oldal.
Lighthouse pontszámok
Most különösen odafigyeltem a Lighthouse pontszámokra, aminek az alábbi képen látható eredmény lett a vége.
Mint látható, egyedül a performance nem lett 100%-os. Accessibility-nél most odafigyeltem a megfelelő kontraszt arányokra. Ehhez ezt az oldalt hívtam segítségül: https://contrast-ratio.com/ Szerencsére nem kellett sokat módosítanom az árnyalatokon, így szinte észrevehetetlen volt a különbség.
Mobilra is sikerült jól optimalizálni az oldalt, ahogy az az alábbi pontszámokon is jól látszik:
Itt két lépéssel tudtam rengeteget hozni a pontszámokon:
- a jquery behúzása a header-ből átkerült a footer-be
- a fontawesome könyvtárat lecseréltem egy korábbi bejegyzésben már bemutatott Icomoon app megoldásra. Ezzel lényegében csökkentettem a feleslegesen behúzott fájlok mennyiségét, amit a mobilmérés meg is hálált.
Egy jó tanács webfejlesztőknek
Időközben megfogalmazódott egy amolyan jó tanács is bennem, amit másoknak jó szívvel tudnék javasolni: teszteld le az általad fejlesztett oldal használhatóságát a hétköznapokban is! Tedd fel egy csak általad ismert tárhelyre, nézegesd mobilról miközben épp tömegközlekedel, forgasd el a készüléket, nyomogasd végig az egészet, hogy minden működik-e, milyen szerinted a felhasználói élmény. Mutasd meg bátran másoknak is, barátoknak, párodnak, családtagoknak: számukra mennyire használható az oldal? Mennyire átlátható? Ezekből a visszajelzésekből aztán egy nagyon kellemes oldalt tudsz felépíteni.
Sokan elkövetik azt a hibát, hogy csak a munkaasztal kényelméből, gépen esetleg a Chrome mobilnézetében tesztelik le az oldalt. Ne legyünk lusták!