Weblabor

A Fixaidea munkái nekem is tetszenek, de a "Hogyan válassz webfejlesztő céget?" c. kis írásukkal kapcsolatban súlyos fenntartásaim vannak.

1. Validátor
Jellemzően CMS rendszerek esetén fordul elő, hogy átadás után a megrendelő használatba veszi a rendszert, elkezd tartalmakat feltölteni, és egy csomó nem valid oldal lesz a végeredmény. Kattintgat össze-vissza, összezavarodik a TinyMCE, betesz hibás kódolású URL-eket, MS fájlokból átemelt tartalmakat a szövegeibe, stb. Vagy pl. a Drupalnak volt korábban szokása, hogy a hidden mezők köré nem tett p címkéket, erre a validátor mindig sikít, de az vesse a fejlesztőre az első követ, aki ezért nekiáll meghekkelni a rendszert.

Azt csak egy szakember tudja eldönteni, hogy a "This page is not Valid XHTML 1.0 Strict!" valójában mit takar. Arra biztatni a megrendelőket (aki azt se tudja, mi az, hogy XHTML, meg Strict), hogy validálják a referenciamunkákat, és ami nem megy át, az pancser munka - ez szvsz kimeríti a közveszélyesség definícióját...

Ezzel nem a validátor ellen emelek szót, az természetesen kötelező munkaeszköz. De nem való a megrendelő kezébe, mint ahogy az én kezembe se való Geiger-számláló de még fáziskereső se, mert nem értek hozzá.

2. Részekre bontott árajánlat
Hétfőn küldtem át egy árajánlatot egy érdeklődőnek, egyösszegűt. Benne volt a cég telephelyén történő fotózás is. Gondolkodtam, hogy kiveszem a csomagból és külön tételként szerepeltetem. Végül becsomagoltam a végösszegbe. Az ok nagyon egyszerű: ha kiveszem a csomagból, a megrendelő valószínűleg nem kéri, hanem átküldi a saját amatőr fotóit. Aztán 3 napot eltölthetek azzal, hogy fotósoppolom a képeket, hogy valami elfogadható színvonalú anyagot kapjak. Ezt a 3 napot viszont nem fizetnék meg nekem. Ha részekre bontottam volna az árajánlatot, akkor így kellett volna kinéznie:

Honlapkészítés helyszíni fotózással: x Ft.
Honlapkészítés a megrendelő fotóival: x Ft + 30% felár.

De ragozhatnám tovább. A csomagnak szinte minden eleme további elemektől függ. Ha sok funkció kell, felteszem valamilyen tartalomkezelőre. Ha kevés, lehet, hogy inkább kézzel összerakom. Milyen a tárhely, ahol futni fog a szkript? Ki készíti a látványt? Ha én, akkor már a tervezéskor gondolok arra, hogy ezt majd rá kell tennem a CMS által kidobott HTML-re - vajon gondol-e majd erre a megrendelő által hozott grafikus? Satöbbi satöbbi. Ha minden eshetőséget le akarnék írni, egy egyszerű árajánlat is 30 oldalnyi táblázat meg függvény lenne.

Alapvetően az a gond, hogy nem mindig jó funkciókra bontani a feladatot. Honnan tudja a megrendelő, hogy milyen funkciókra van szüksége? Van amikor tudja, van amikor nem. Azt kellene megkérdezni tőle, hogy mi a célja a honlappal, és ennek ismeretében összeállítani a funkció-csomagot. Lehet, hogy nem is hírlevél kell neki, hanem céges blog. Nem vendégkönyv, hanem fórum. Nem fórum, hanem zártkörű munkacsoportok. Ha van blog, nem kell vendégkönyv. Ha nincs blog, kell. Vagy nem. Nagyságrendileg mennyi pénz van rá? Határidő?

A webfejlesztés nem pusztán iparos munka, bár kétségtelen, hogy ez is nagyon fontos része. A honlap adott célok megvalósítását szolgáló eszköz. Az autógyár sem úgy dolgozik, hogy kell négy kerék meg egy kormány. Hanem úgy, hogy kell egy haszongépjármű, amivel kis üzletek árut tudnak fuvarozni, két éven belül sorozatgyártásra alkalmasnak kell lennie, meg kell felelnie bizonyos szabványoknak, és egy ilyen járművet legfeljebb x forintért lehet majd eladni. Ezek után elkezdhetünk gondolkodni, hogy ezt a feladatot milyen műszaki megoldásokkal tudjuk megvalósítani. Kell-e bele blokkolásgátló, légzsák, mindkét oldalon tolóajtó, kabinelválasztás, hátsó ablaktörlő? A válasz: attól függ.

Persze most egy kicsit sarkítottam, nem minden munka így néz ki, és nem minden megrendelő vevő az ilyen együtt-gondolkodásra. De ennek így kellene kinéznie, és szvsz nem szerencsés, ha a honlapunkon kimondottan a négy kerék + kormány = how much? mentalitást népszerűsítjük.

Edit

sziasztok!

a fixaidea egyik fele volnék, a programozó fele. a honlapunkon a szövegeket a másik fele írta.

csak azt szeretném mondani, hogy nagyon örülök annak, hogy a munkánknak azt a részét is értékeli valaki, amit a megrendelők és a felhasználók többsége észre sem vesz. köszönöm.

azt egyébként vissza is utasítanám, hogy "vérprofik" lennénk. tudom nagyon jól, hogy sokat lehetne még javítani az oldalainkon, sőt, valójában legtöbbször úgy érzem, hogy a kliens oldali megoldásainkban csak a minimum szintet hozzuk. de a dologhoz hozzátartozik, hogy én inkább a szerver oldali dolgokban szeretek elmélyedni és így sajnos a kliens oldalra egy kicsit kevesebb idő jut, mint amennyit megérdemelne. ez nem mentség, de ez az oka.

viszont itt meg is ragadnám az alkalmat: ha valaki úgy gondolja, hogy ügyesen bánik a css-sel, html-lel, ismeri a böngészők lelkivilágát, esetleg a js-hez is ért, valamint össze tud hozni jól használható felhasználói felületeket, és szeretné ezt a tudását "éles helyzetekben" kamatoztatni, esetleg egy kis mellékesért, ösztöndíjkiegészítésért, akkor vegye fel velünk a kapcsolatot, lehet hogy meg tudunk egyezni. én legalábbis szívesen átadom a munkámnak ezt a részét valaki olyannak, aki jobban ért hozzá és több ideje van rá. vagy ha csak egy-két ötletetek van, hogy hogyan lehetne javítani a jelenlegi oldalainkon, azt se tartsátok magatokban!

w3net:
nem azt tartjuk a legfontosabbnak, hogy az oldalaink strict doctype-pal is átmenjenek a validátoron, hanem azt, hogy az oldalak legyenek a lehető legtöbb ember számára jól használhatóak. ehhez a strict doctype erőltetése kevesebbet ad hozzá, mint az, hogy egyszerűen csak igyekszünk szemantikailag helyes kódot írni, amiből aztán elérhető és könnyebben kezelhető oldal kerekedik minden böngészőben.
de ezzel nem a strict doctype létjogosultságát vitatom. sőt! ha nem használnánk tinymce-t, akkor az oldalaink strict xhtml-ként is átmennének a validátorokon, vagyis az általam írott kóddal nem nagyon lennének problémák. na jó, esetleg itt-ott ki kéne szedni a form element-ből a name attribútumot, néhány linkből a target-et, meg ilyen apróságok. (ezekért a kis hülyeségekért most elnézést is kérek, szégyellem magam. :) ) szóval okos dolgok a strict doctype-ok, de amíg olyan világban élünk, ahol pl. az IE az xhtml-t csak hibás html-ként kezeli, szerintem van ennél fontosabb is.

Edit:
a geiger-számlálós hasonlat nagyon tetszett :), mert tényleg van abban igazság, hogy validátort az használjon, aki tudja is értelmezni az eredményt. és talán tényleg túlzás leírni azt a céget, amelyiknek a munkájában egy-két kisebb hibát találunk vele. de ahogy te is tudod, hogy létezik valami geiger-müller számláló nevű eszköz, amivel a radioaktív sugárzást lehet valahogy mérni, talán nem baj, ha a megrendelők is tudják, hogy van egy validátor nevű eszköz, amivel lehet mérni, hogy egy honlap mennyi hibát rejt. na de majd vitatkozik ezzel a kollégám, ha akar.
a részekre bontott ajánlatról írtakkal kapcsolatban viszont árnyalnám egy kicsit a képet azzal, hogy ezt mi már csak azután adjuk az ügyfélnek, hogy előtte egy személyes találkozón alaposan átbeszéltük vele, hogy mit is szeretne. (aki ilyen találkozóra nem hajlandó, azzal nem is foglalkozunk, mert nem veszi elég komolyan a munkát.) ha az ügyfél pl. szeretne hírleveleket kiküldeni, és mondjuk szeretné, hogy a hírlevelekhez a site-jának adatbázisából származó adatokat tudjon csatolni, akkor mi elmondjuk neki, hogy ez hogyan lehetséges, mit tud ebből megcsinálni a cms-ünk kész hírlevélküldő komponensével és mit kell pluszban hozzáprogramoznunk. aztán az ajánlatban ezek külön tételként szerepelnek, ha akar, lemondhat a plusz kiegészítésről, mert kézzel is hozzá tudja írkálni a hírlevelekhez azt a pár sort, vagy lemondhat az egész hírlevélküldésről, ha meg akarja spórolni az árát.

krisztián