Front-end developerek Nyíregyházán: Vélemények és kedvező árak

Front-end developer Nyíregyházán

A Front-end developer akkor hasznos, ha egy webes felületnek nem csak szépnek, hanem gyorsnak, átláthatónak és jól használhatónak is kell lennie. Nyíregyházán sok magánügyfél akkor keres ilyen szakembert, amikor a régi oldal telefonon szétesik, lassan tölt be, vagy az érdeklődő nem találja meg rajta azt, amiért érkezett. A front-end fejlesztő munkája főleg a látható részhez kötődik. Ide tartozik az elrendezés, a gombok viselkedése, az űrlapok, a mobilnézet és az is, hogy minden mennyire érthető első pillantásra. A magyar találatokban újra és újra előjött a reszponzív kialakítás, a gyors betöltés és a tiszta szerkezet. Az angol oldalak pedig azt emelték ki, hogy a költséget leginkább a feladat mélysége, a funkciók száma és a későbbi módosítások növelik. Ezt én is reálisnak tartom.

Sokan keverik a teljes webfejlesztést a felületi munkával. Pedig nem ugyanaz. Egy front-end fejlesztés lehet önálló feladat is, például egy meglévő oldal javítása, egy új landing oldal felépítése vagy egy foglalási űrlap rendbetétele. És van, amikor a háttérrendszer már kész, csak a megjelenés és a használhatóság hiányzik. Ilyenkor nem feltétlenül nagy csapat kell. Gyakran elég egy jól dolgozó egyéni fejlesztő is, aki végigviszi a látható részt. A Qjob.hu oldalon is ezért érdemes pontosan leírni, hogy új felület kell-e, vagy egy meglévő oldal javítása.

Mikor kell frontend fejlesztő

Frontend fejlesztőre akkor van szükség, ha a felhasználó látja a hibát, de nem tudja megmondani, mitől rossz az élmény. Tipikus jel a rossz mobilnézet, a túl sűrű kezdőlap, az apró gomb, a nehezen kitölthető űrlap vagy az a helyzet, amikor a látogató megérkezik, körbenéz, majd kilép. Ilyenkor sokan azt mondják, csak egy kis igazítás kell. A gyakorlatban ez néha több, mint kis igazítás. Egy rosszul összerakott felületnél minden módosítás egymásra hat.

Én személy szerint jobban szeretem, amikor a megrendelő egyszerűen fogalmaz. Például azt mondja, telefonon nem lehet elküldeni az űrlapot, vagy a szolgáltatások nem férnek ki rendesen. Ez sokkal használhatóbb, mint az, hogy valami nem elég modern. A felületfejlesztő ebből látja, hol kell hozzányúlni a szerkezethez. Volt olyan ügyfél, aki csak egy új nyitóképet szeretett volna. A beszélgetésből végül az derült ki, hogy a fő baj nem a kép, hanem az volt, hogy három fontos gomb ugyanabba a vizuális zajba fulladt bele. Amikor ezt rendeztük, megváltozott az egész oldal ritmusa, és nem kellett teljes újratervezés.

És van egy gyakori félreértés. Sokan azt gondolják, hogy ha valami jól néz ki asztali gépen, akkor rendben van. De a magyar és külföldi minták alapján is a mobilbarát felület ma alapelvárás, nem külön extra. Ha ezt valaki kihagyja a kérésből, később szinte biztosan többet fizet.

Front-end fejlesztés előtt a legfontosabb kérdések

A front-end fejlesztés akkor halad normálisan, ha az elején tiszta a cél. Új oldal készül. Meglévő oldal javul. Egyetlen kampányoldal kell. Vagy csak néhány kulcsfontosságú elem rendbetétele a feladat. Sok ügyfél ott hibázik, hogy túl általános briefet ad. Azt mondja, legyen letisztult és gyors. Ez irány, de nem elég. Tudni kell, hány blokk lesz, milyen tartalom áll rendelkezésre, kell-e kapcsolatfelvételi űrlap, térkép, galéria vagy árlista.

Saját tapasztalatom szerint a legjobb indulás egy rövid lista. Mi a cél. Melyik oldalakat érinti a munka. Melyik eszközön a legsürgetőbb a javítás. Van-e kész szöveg és kép. Ki fogja később frissíteni a tartalmat. Sok megrendelő ezt túlrészletezésnek érzi. Szerintem inkább ez az a pont, ahol pénzt lehet spórolni. Minél világosabb a feladat, annál kisebb az esély arra, hogy a fejlesztő menet közben újraépítsen valamit.

Olvastam több angol oldalon is, hogy a felesleges funkciók gyakran viszik el a keretet. Ezzel teljesen egyetértek. Sokszor nem az a jó döntés, hogy minden kívánság egyszerre kerüljön be, hanem az, hogy először az készüljön el, amit a látogató tényleg használ. Olcsóbb megoldás első körben ritkán marad jó, ha rossz a sorrend. De ha a lényeg kerül előre, a kisebb keretből is lehet értelmes eredményt kihozni.

Frontend fejlesztő árak

A frontend fejlesztő díja főleg attól függ, hogy javításról, részleges átalakításról vagy teljes felületépítésről van szó. A magyar árak között nagy a szórás, de visszatérő minta, hogy az óradíj és a projektár is a bonyolultságtól, a teszteléstől, az egyedi elemek számától és az átadás részletességétől függ. A külföldi cikkek ugyanezt írják más nagyságrendben. Nem a kód mennyisége számít egyedül, hanem az, hogy mennyit kell tervezni, finomítani és több eszközön ellenőrizni.

Az én véleményem az, hogy túl olcsó felületi munka ritkán lesz tartósan jó. 20.000 alatt egy komolyabb javítás már gyanúsan kevés. Lehet kivétel, de ritka. És aki nagyon alacsony árat mond az elején, az néha minden további módosításért külön kér pénzt. A végén így drágább lesz az olcsónak tűnő ajánlat. Nyíregyházán is inkább a tiszta, részletes vállalást keresném, nem a legalacsonyabb számot.

Ez a táblázat irányadó. A valós díjat befolyásolja a sürgősség, a meglévő oldal minősége és az is, hogy mennyi egyeztetésre lesz szükség. Szerintem 12.000 - 22.000 körül még reális lehet egy rövid utómunka. De ennél olcsóbban sokszor már a kommunikáció is kapkodó lesz, és az ritkán vezet jó végeredményhez.

Front-end developer választása

Front-end developer választásánál nem a látványos referencia az első szűrő. Az is számít, de önmagában kevés. A fontosabb kérdés az, hogy a fejlesztő hogyan kérdez. Rákérdez-e a célra. Meg tudja-e mondani, mi az, ami belefér, és mi az, ami már külön kör. Világosan fogalmaz-e. Én személy szerint jobban bízom abban a szakemberben, aki egyszerű szavakkal írja le a folyamatot, mint abban, aki hosszú technikai listával próbál hatni.

Sok megrendelő hibázik, amikor csak az ár alapján választ. Pedig a rossz kommunikáció legalább akkora gond, mint a gyenge kivitelezés. Volt eset, amikor egy ügyfél gyorsan igent mondott a legolcsóbb ajánlatra, mert a képernyőképek szépek voltak. Később derült ki, hogy a módosítások száma nincs tisztázva, a mobilteszt nincs benne, és az átadás után egy hét múlva már nem érte el a fejlesztőt. A munka végül elkészült, de feszültséggel és plusz költséggel.

Nyíregyházán előny lehet a személyes egyeztetés, de nem ez dönt. A jó fejlesztő távolról is jól együtt tud működni, ha pontos. Én a választás előtt mindig kérnék rövid ütemezést, módosítási szabályt és azt, hogy mi számít kész állapotnak. Ez unalmasnak hangzik, de később ebből lesz kevesebb vita.

Front-end fejlesztővel való munka menete

Egy front-end fejlesztővel a közös munka általában felméréssel indul, utána jön egy első változat, majd a javítások és az átadás. Ez egyszerűnek hangzik, de sok félreértés abból ered, hogy nincs leírva, mikor lehet módosítani, és mennyi kör fér bele. A hazai találatoknál is látszott, hogy a tervezés, a demo vagy első változat, a tesztelés és az élesítés visszatérő elemek. Az angol minták pedig külön hangsúlyozták, hogy a fenntartási költség és a későbbi változtatások ugyanúgy részei a teljes képnek.

Én azt tartom jónak, amikor a megrendelő nem csak a kész képet látja, hanem kap egy rövid magyarázatot is arról, mi miért úgy működik. Nem kell hosszú oktatás. De tudni kell, hol lehet majd szöveget cserélni, hogyan néz ki a mobilnézet, és mit kell jelezni, ha valami új kérés felmerül. Sok ember ott csúszik meg, hogy azt hiszi, az átadás után már minden változtatás azonnal és plusz költség nélkül megoldható.

És itt jön egy kényes pont. A túl sok apró menet közbeni kérés szét tudja húzni a munkát. Sokkal jobb, ha az első kör előtt egyben össze vannak gyűjtve az észrevételek. Így a front-end fejlesztés gyorsabban zárható le, és kisebb az esély arra, hogy ugyanazt a részt háromszor kell újranyitni. Ebben a fajta fegyelemben nincs semmi merevség. Inkább arról szól, hogy a felület végül használható legyen, ne csak félig kész.

Ha valaki Nyíregyházán keres segítséget magáncélú webes felülethez, szerintem az a legjobb út, ha először a problémát írja le, nem a technológiát. Egy jó felületfejlesztő ebből is látni fogja, mire van valóban szükség, és mire nem.