A folyamatok sorrendiségére, folyamatábrára nem ügyelek, csak azt nézem, hogy miken kell átesni. Úgy ismertetem őket, ahogyan én látom. Praktikusan. Az elvi, akadémikus és egyetemi blabla nem érdekel. Nem hiszem, hogy teljes körű lesz a leírás, de majd a kommentekben felhívjátok a figyelmem és frissítek.

Tanácsadás, feladatmeghatározás

Mielőtt bárminek is nekiesnénk meg kell nézni, hogy az ötletünk hogyan állja meg a helyét. Az ötletet már itt el kell valahogy helyezni az internets rengetegében, piackutatni kell, célcsoportot meghatározni, műszaki megvalósíthatóságot elemezni, pénzügyeket tisztázni, üzleti tervhez méretezni, versenytársakra figyelni.

Tapasztalt webes szakemberek véleményére is szükség lesz. Nem kell feltétlenül nagy dolgokra, sok papírra és izzadt öltönyös majmokra gondolni. Még az is tanácsadás, ha csak megkérdezzük a havert a Twitteren. Tanácsadásra és specifikációra még a legkisebb webes dolgunk esetében is szükség lesz, maximum az egész el lesz intézve három mondattal, e-mailben.

Lesz egy pongyola feladatmeghatározásod, hogy mit és kábé hogyan szeretnél. Az ötletek nagy része már ebben a fázisban elbukik, ami egyáltalán nem baj. Gyakorlatilag itt érik az ötlet projektté.

Már most meg kell becsülni vagy becsültetni a fejlesztés időigényét. Ez borzasztóan durva lesz, mert kevés még az infó, de ha azt mondják, hogy 6 hónapnál tovább fog tartani az első, felhasználók által is használható bétaszintű megjelenés, akkor máris elbuktál, vissza az ötleteléshez! Ugyanis az ötleteid, piackutatásod szavatossági ideje a weben nagyon rövid.

Interface-tervezés

Ebben a lépésben találod ki a weboldalt. Általában tapasztalt és jól megfizetett szakember kell hozzá, hiszen a weboldal gyakorlatilag egy nagy interface. Alapvető fontosságú folyamat, az oldal sikere nagyon nagy részt ezen múlik: nem túl szép, de jól használható weboldalakat gyakran használunk, szép, de rosszul használhatókat kevésbé.

Itt nem a designt, nem a grafikát kell kitalálni! Éppen ezért nagyobb projekteknél ne a grafikus végezze ezt, egy "csak grafikus, designer" ember nem is ért hozzá!

Át kell tekinteni a felhasználói folyamatokat, meg kell tervezni a lehető legkényelmesebb, legegyszerűbb lebonyolítást. Meg kell tervezni drótváz szinten az oldalakat, meg kell határozni a fő oldalelemeket, a navigációtól a legutolsó checkbox-ig.

Ha megvan a terv, végig kell menni rajta egyszerű végfelhasználóként. El tudom-e végezni könnyen, mindenféle különösebb tanulás nélkül a szükséges folyamatot? Megtalálom-e az infót? Ehhez külsős tesztelő bevonása szükséges, nem olyan, aki részt vett a tervezésben.

Itt se gondolj nagy dolgokra: az interface-terv simán lehet egy csomó A4-es lapra ceruzával vázolt rajz, a tesztelő pedig egy rokon.

Hazánkban méltatlanul elhanyagolt területről van szó, gyakran a grafikussal végeztetik az interface-tervezést. Neki nem kell értenie hozzá, nem a feladata. Főleg ezért lesznek rosszul használható oldalaink.

Design

Na ez a grafikus feladata. Megkapja a specifikációt és főként az interface-tervek mentén megrajzolja az oldalt. Ami eddig szimpla vázolt téglalap volt, az most lesz szép, lekerekített sarkú doboz és itt lesz logód is.

Fontos, hogy a grafikusnak is legyen webes tapasztalata. Ne rajzoljon olyan dolgokat, ami túlságosan megdrágítja, szélsőséges esetben lehetetlenné teszi a fejlesztést. Például ne legyen benne olyan inputbox, amit csak plusz órák ráfordításával lehet leprogramozni, próbáljon ésszerű keretek között maradni.

Kilépés a tervezésből

Most jutottunk el odáig, hogy vannak terveink de még nem működik semmi. Minden, ami eddig volt a tervezésről szólt, még a lerajzolt design is csak terv, egy rajz.

Az interface-tervezés és a tanácsadás-feladatmeghatározás eredménye egy pontos weboldal specifikáció, amihez ha hozzácsapod a rajzot (design), a fejlesztő(k) pontos árajánlatot tudnak adni neked. Ha ennél korábban kérsz ajánlatot, akkor nem tudják pontosan tervezni a fejlesztőidő szükségletet, látni fogják, hogy nem csináltad meg a házi feladatot (nekik kell tervezni a fentiek egy részét), ezért drágák lesznek, bekalkulálják.

Kisebb projekteknél persze anyagilag nem lehetséges, hogy az interface-tervezést és a designt más-más ember csinálja. Ilyenkor koncentrálni kell az egészséges skizofréniára.

Természetesen olyan is van, hogy ugyanattól a fejlesztő(cég)től kéred az egészet inkluzíve tanácsadás. Most már legalább tisztában leszel azzal, hogy az árban messze nem csak a fejlesztés és a design van.

Alapinfrastruktúra

Innentől már fejlesztünk, de még mielőtt elkezdjük a kódsorokat püfölni, a specifikációban szereplő számok alapján (pl. mennyi látogatóra lövünk) megtervezzük az alapinfrastruktúrát. Mekkora és milyen szerverek kellenek? Min fogunk tesztelni? A legtöbbi (főleg hazai) projektben ez egyszerű kérdés.

Ha viszont nagyra lövünk, akkor alapvetően más skill szükséges minden oldalról, a fejlesztés jellege megváltozik, egy csomó mindent másképp kell majd csinálni. Sajnos a magyar felsőoktatás semmilyen szinten nem készít fel erre a helyzetre, ezért a megfelelő fejlesztőcsapat összeállításával még nagyobb gondban leszel.

Mert az nem úgy van, hogy a kicsi weboldal csak úgy szimplán megnő. Máshogy fejlesztünk kicsiben, máshogy nagyobban, máshogy mégnagyobban.

Külföldön is nem egyszer láttunk már olyat, hogy alultervezték mondjuk a látogatószámot. Ilyenkor indul a kapkodás, röpködnek a nagy nehezen összekalapolt kockázatitőke-pénzek és fű alatt újrafejlesztik az oldal nagy részét.

Fejlesztés

Fejlesztünk, pont. Ez a szakasz marhára unalmas, mert általában csak a tesztelési fázisban kapsz nagyobb feladatot, addig nincs mit birizgálni. Használd ki ezt az időszakot az oldalad marketingjére, promótálására. Gyűjtheted a korai tesztelőket/adoptereket, építheted a hype-ot.

Tesztelés

Ha kész van valami szénné kell tesztelni. Én még olyat nem láttam, hogy a fejlesztő kapásból hibátlan rendszert hozott volna létre. A szoftverfejlesztésben olyan sok dologra kellene ügyelni, hogy ez amúgy is lehetetlen. A teszteléskor valami probléma mindig kijön. Sőt, nem csak a fejlesztőnél lehet labda, lehet, hogy az interface-tervezéskor hibáztatok.

És végül noch einmail: nem hiszem, hogy teljes körű lesz a leírás, de majd a kommentekben felhívjátok a figyelmem és frissítek.

2 hozzászólás

1. idézem 2008.05.31. 13:36
   • Hodicska Gergely
   Na még egyszer megpróbálom. :)
   
   Egy olyan pont volt a postban amivel nem is vitatkoznék, inkább egy másik aspektust is behoznék.
   
   A látogatószám belövése sajnos nem annyira egyszerű ügy. Kábé minden startup egyrészről azt szeretné, hogy majd az ő cucca legyen a következő nagy dobás, de erre nincs garancia, valamint eleinte szinte biztosan van valamilyen erőforrás szűke (anyagi, emberi).
   
   Nem tudsz mindig mindent úgy megoldani, hogy az tuti működjön mondjuk 100-szor annyi nézővel is, mert egyrészt nem is biztosan ismered a telejes probléma teret (néha banális, soha nem gondolt szűk keresztmetszetek tudnak létrejönni), másrészt még ha tisztában is vagy a problémákkal, nem biztos, hogy az adott fejletségi szinten megéri a tökéletes megoldást megszűlni. Vagy éppen túl sok idő lenne a prototípus tesztelése (vagy éppen nem is olyan egyszerű mondjuk a videók esetén), és fontosabb, hogy elő tudj jönni a "feature"-rel, mintsem az tökéletes legyen.
   
   Egy másik érdekes attitűd lehet, amikor azt látod, hogy nem pontosan úgy kezdik el használni a szolgáltatásod, mint amire te az kitaláltad (pont a twitter is jó példa erre), és emiatt vagy kénytelen változtatnod.
   
   Kb. egyfajta RAD megközelítés lehet nyerő, igyekszel a lehető legjobb megoldást kitalálni, de nem érdemes túltervezni is, mert gyakran csak annál több kódot kell majd kidobnod. Persze fontos, hogy alapvetően skálázható megoldásokat igyekezzen összehozni az ember, illetve lehetőleg minél függetlenebb komponenseid legyenek, hogy megnövekedett terhelés esetén tud a darabkákat jobbra cserélni.
   
   Üdv,
   Felhő
2. idézem 2008.06.01. 12:41
   • Gábor
   Kicsit pontosítok: sokszor látjuk, hogy kezdéskor nagyon alálőnek, pedig egy amerikai startupnak gyakran lenne pénze kapásból "feljebb fejleszteni", például egyből valami komolyabb caching-et beépíteni.

Legutolsó hozzászólások

DJ PLAYER Blue Edition: Gábor: Ja, és természetesen megy iPad-en is, hiszen _minden_ iOS app megy iPad-en.

DJ PLAYER Blue Edition: Gábor: Bug report-okat itt fogadunk: http://djplayer.net/page/bug_report_fixes

DJ PLAYER Blue Edition: hohand: Hello!A dj player mukodik iPad-on is?Tegnap feltettem, wifi-n athuztam ra zeneket,de amikor ranyomtam egy zeneszamra,error-t dobott es valami is!...

Uzsidoboz LED!: zo via Google Reader: vicces dolog, csak nem értem mire való

Uzsidoboz LED!: Gábor: @Benjamin Minek forogjanak? Egy falszínezőnek olyat nem kell tudnia, így is épp elég hatásosak.