Wat staat er minimaal in de offerte van de webdeveloper?

[Verwijderd]

Ben bezig met een project waarbij ik het design verzorg waarna een webdeveloper het design sliced en coded. Het code-werk houdt in dat er o.a. een inlog-/ en intranetomgeving gebouwt gaat worden.

Ik heb zojuist de offerte hiervoor ontvangen maar deze komt op mij nogal eenzijdig over. Zo wordt er bijvoorbeeld niet gesproken over browserfunctionaliteit, manier van coderen en het calculeren van meerwerk.
De offerte bestaat slechts uit een korte samenvatting van de functies, prijs en betaalwijze.

Kortom: wat moet er minimaal in de offerte staan en waar moet ik op letten?

[LauPro]

Het ligt een beetje aan de klus. Als het om een paar 100 euro gaat zou ik het niet te ingewikkeld maken. Wanneer het eerder richting de 1000 of meer gaat dan is het zeker wel noodzakelijk.

Er is geen generiek model denk ik. Bij kleine projectjes zie je toch vaak dat er maar weinig mensen aan werken en de noodzaak om goede standaarden te hebben vaak verwatert (of men werkt niet zo). Zelf wil ik altijd dat soort dingen wel op orde hebben omdat het aan het einde van rit gewoon een hele hoop ellende scheelt. Ik heb wel eens in een bestaand project wat quick&dirty aanpassingen gemaakt, als zo'n opdrachtgever dan een paar maanden later weer bij je terug komt is dat een _ramp_.

Als je eerst 8 uur bezig bent met een offerte, en dat is daarna 16 uur werk. Dan ben je niet goed bezig imo. Tenzij je dat allemaal vergoed krijgt ook, maar sowieso lijkt het me dat je eigenlijk meer tijd bezig moet zijn (in verhouding) met de daadwerkelijke producten dan de beschrijving van (al hoewel in sommige gevallen het beschrijven wel enkele weken kan duren natuurlijk).

[crisp]

Als jij de opdracht geeft dan ben jij toch ook degene die zal moeten aangeven waaraan het resultaat moet voldoen? Dat zal dan uiteindelijk ook in de offerte bevestigd moeten worden.

Zo zou je bijvoorbeeld kunnen opstellen dat de frontend-code moet valideren, volledig functioneel moet zijn in grade A browsers en toegankelijk in grade C browsers, en voldoen aan bepaalde webrichtlijnen.
Ook verwachtingen mbt SEO e.d. zal je zelf vantevoren moeten aangeven.

Voor backend code zullen vast ook wel richtlijnen te vinden zijn omtrent veiligheid en documentatie.

Als jij uiteindelijk denkt met een beunhaas te maken te hebben dan zal je op zoek moeten gaan naar een beter webdevelopment bedrijf. Bedenk dat goedkoop meestal duurkoop is.

[Verwijderd]

Vergeten te vermelden dat het project bestaat uit 52 codeeruren en de kosten >€2000.

[LauPro]

Mja, je kan het nog zo leuk specificeren maar uiteindelijk wil de klant een werkend product. En dan kan in je offerte nog wel zo keihard staan dat de klant laatste softwareversies moet gebruiken van browsers en geen fancy contentfiltering. Maar aan het einde van de rit wil de klant dat het gewoon werkt. En als je dan toch probeert voet bij te te houden, of veel meer extra uren in rekening gaat brengen omdat het onderdeel alsnog werkend te krijgen dan krijg je waarschijnlijk geen vervolgklussen meer. Om je in te dekken kan je een aantal extra uren reserveren (voor zover je dat al niet doet).

Als webdeveloper krijg je bij elke software-update die *ergens* in de keten gebeurt min of meer een trap na. Je kan nog zo netjes standaarden en aanbevelingen volgen. Maar zodra er een bedrijf of een head developer van een project besluit dat iets moet worden aangepast dat je applicatie vervolgens breekt dan hangt je.

Serverside heb je dan vaak nog veel dingen in de hand. Maar clientside is het meestal botte ellende. Zeker omdat het als webdeveloper niet te evenaren is wat de verbinding is bij de persoon in kwestie en welke instellingen die gebruikt. Ik heb sommige webapplicaties van bepaalde leveranciers al in een terminal server omgeving opgeleverd zien worden omdat dat de enige methode was om de werking te garanderen.

Dus ondanks dat je dergelijke punten op neemt in je contract, kan het zijn dat je er op moet terugvallen. Daarnaast zijn de standaarden niet absoluut. Het is leuk dat iets semantisch valideert, maar dat zegt totaal niet of het ook contextueel klopt en zo kan ik nog wel even door gaan. Bottomline is gewoon gezond verstand gebruiken en alleen dingen beloven die je ook echt waar kan maken.

[crisp]

LauPro: je leest het verkeerd, Thooijs is in deze 'de klant' en ik stel dat als hij bepaalde eisen heeft hij die vooraf ook duidelijk zal moeten communiceren zodat de offerte aansluit bij zijn verwachtingen. Helaas is het niet zo dat je van webdevelopers standaard nette crossbrowser code kan verwachten...

[sanderb]

Zorg dat er een duidelijk change request procedure op papier staat. Daarin bepaal je hoe veranderingen in de toekomst in functionaliteit of werkzaamheden aangepakt gaan worden. Je beschermd hiermee jezelf en de webdeveloper, maar je voorkomt vooral een hoop gedonder over een offerte die op meerdere manieren te interpreteren valt.

Eigenlijk dus wat Crisp al aangeeft: In een offerte horen duidelijke(!) eisen en oplevermomenten van beide partijen te staan, en ook de consequenties bij het niet halen daarvan.
Feitelijk is die offerte je contract. Als opdrachtgever wil je niet het risico lopen dat je webdeveloper het bijltje er bij neergooit omdat hij vind te hebben voldaan aan de eisen van de offerte. Aan de andere kant wil een webdeveloper geen opdrachtgever die het zoveelste redesign en de zoveelste verandering in functionaliteit voor de prijs van de eerste offerte verwacht, simpelweg omdat nooit echt vastgelegd is wat er onder "onderhoud" wordt verstaan.

[LauPro]

Mijn verhaal gaat nog steeds op. Het is denk ik juist in het voordeel van de TS. Als er in een offerte zou staan dat het opgeleverde werk per se moet valideren, en dit staat een bepaalde functie in de weg dan zou dat dus betekenen dat er op het gebruikersgemak moet worden ingeleverd. En als klant (of opdrachtgever) gaat het er om dat het uiteindelijk werkt.

Het is een beetje hetzelfde als eisen van een installateur dat er 230V uit een stopcontact moet komen, maar dat er vervolgens maar 0,1A kan worden opgenomen is er niet bij vermeld waardoor het stopcontact praktisch niet bruikbaar is.

Daarnaast hoe hogere eisen je stelt, hoe hoger het tarief. In dit geval lijkt het me wel verstandig om de portfolio eens door te kijken en misschien wat code reviews te doen.

[ Voor 18% gewijzigd door LauPro op 07-09-2007 01:02 ]

[crisp]

LauPro schreef op vrijdag 07 september 2007 @ 00:59:
Mijn verhaal gaat nog steeds op. Het is denk ik juist in het voordeel van de TS. Als er in een offerte zou staan dat het opgeleverde werk per se moet valideren, en dit staat een bepaalde functie in de weg dan zou dat dus betekenen dat er op het gebruikersgemak moet worden ingeleverd. En als klant (of opdrachtgever) gaat het er om dat het uiteindelijk werkt.

Geef eens een voorbeeld van iets dat volgens jou onmogelijk is met validerende code?
Overigens diende het slechts als voorbeeld van een eis die je als opdrachtgever zou kunnen stellen

Daarnaast hoe hogere eisen je stelt, hoe hoger het tarief. In dit geval lijkt het me wel verstandig om de portfolio eens door te kijken en misschien wat code reviews te doen.

Onzin; een zichzelf respecterende front-end devver levert standaard al gewoon goede code op zonder meerkosten. Als wat jij stelt het geval zou zijn dan heb je zeker met een prutser te maken...

[crisp]

Begrijp ik hier overigens dat het om 1 persoon gaat die zowel backend als frontend coding moet gaan doen? Dat zijn namelijk 2 heel verschillende expertices en de ervaring leert dat er maar heel erg weinig mensen zijn die beide goed beheersen...

Overigens denk ik dat je zelf ook te makkelijk denkt over het frontend werk als je al begint over 'slicen' - dat is namelijk geen methode die nette semantisch correcte markup oplevert

[LauPro]

crisp schreef op vrijdag 07 september 2007 @ 01:06:
Geef eens een voorbeeld van iets dat volgens jou onmogelijk is met validerende code?
Overigens diende het slechts als voorbeeld van een eis die je als opdrachtgever zou kunnen stellen

Eensgelijks in principe. Voorbeeld van niet validerende code: Ik heb wel eens gezien dat er in een opdracht stond globaal dat er geen frames en Javascript mocht worden gebruikt, maar het wel XHTML 1.1 moest zijn. Dat was allemaal geen probleem totdat de programmeur in kwestie tegen een flash-banner aan kwam die erin moest komen, en ook nog compatible voor FF/IE etc. Zijn enige optie zou dan zijn om uit te wijken naar een ranzige wrapper. Maarja, ook dat gaf weer complicaties voordat hij er eenmaal uit was. Toen ik dat project later heb overgenomen heb ik gewoon gesteld dat het voor een moderne website bijna onontkomelijk is om Javascript te gebruiken, al is het maar voor een mooie wrapper loader lib voor flashanimaties.

Onzin; een zichzelf respecterende front-end devver levert standaard al gewoon goede code op zonder meerkosten. Als wat jij stelt het geval zou zijn dan heb je zeker met een prutser te maken...

Vergis je niet hor, het werk dat ik al op mijn scherm langs zien komen is veelal te triest voor woorden. En dan zijn het vaak al mensen die een site al enkele jaren beheren en best grote klanten (bladen bijv.) hebben. De laatste tijd probeer ik me wat meer te richten op software architecture zodat ik een beetje gevrijwaard blijf van al die rommel. Maar mocht ik weer actief dat soort projecten gaan doen dan hou ik mijn hart alvast vast.

edit: En daarnaast, pak een willekeurig project als PHPMyAdmin, als je daar de source van ziet dan springen toch spontaan de tranen in je ogen?

[ Voor 4% gewijzigd door LauPro op 07-09-2007 01:44 ]

[disjfa]

LauPro schreef op vrijdag 07 september 2007 @ 01:39:
[...]
Vergis je niet hor, het werk dat ik al op mijn scherm langs zien komen is veelal te triest voor

Klanten boeien zich nou eenmaal niet om wat er gebeurt, maar alleen dat het gebeurt. Dan is het aan ons om er redelijke code van te maken. Dat wij dat dan niet maken is niet de schuld van ons, maar van de klanten.

Maar dat zet de client side proggers niet op een gouden stoel om het maar zo door te laten gaan

LauPro schreef op vrijdag 07 september 2007 @ 01:39:
[...]
edit: En daarnaast, pak een willekeurig project als PHPMyAdmin, als je daar de source van ziet dan springen toch spontaan de tranen in je ogen?

Jep,

[ Voor 20% gewijzigd door disjfa op 07-09-2007 01:46 ]

[crisp]

LauPro schreef op vrijdag 07 september 2007 @ 01:39:
[...]
Eensgelijks in principe. Voorbeeld van niet validerende code: [...]

Dat heeft in beginsel niets met validerende code te maken maar met kortzichtige en nergens op gebaseerde eisen van de opdrachtgever. Als specialist is het dan inderdaad jouw taak om hem daarop te wijzen

Vergis je niet hor, het werk dat ik al op mijn scherm langs zien komen is veelal te triest voor woorden. En dan zijn het vaak al mensen die een site al enkele jaren beheren en best grote klanten (bladen bijv.) hebben. De laatste tijd probeer ik me wat meer te richten op software architecture zodat ik een beetje gevrijwaard blijf van al die rommel. Maar mocht ik weer actief dat soort projecten gaan doen dan hou ik mijn hart alvast vast.

Dat noem ik ook geen voorbeeld van 'zichzelf respecterende front-end devvers'. Dat zijn gewoon de 9 tot 5 mensen met een 'het werkt' mentaliteit maar verder niet echt een grote affiniteit met het vak dat ze uitoefenen. Veelal zijn het ook back-end programmeurs die het front-end werk 'erbij' doen...

edit: En daarnaast, pak een willekeurig project als PHPMyAdmin, als je daar de source van ziet dan springen toch spontaan de tranen in je ogen?

Absoluut, ik zeg ook niet dat gebrek aan kwaliteit zich enkel op het front-end gebied afspeelt

[gvanh]

Als voorbeeld van wanneer ik mij niet aan validerende code gebonden voel: in XHMTL is de "target" attribuut in een <a> niet toegestaan. Wanneer je een externe link in een nieuw venster zou willen openen, zou je dus met JavaScript events moeten gaan hangen aan alle <a> elementen die niet naar een intern adres verwijzen.

Voor dat soort gevallen zeg: "Dan maar niet volgens boekje" ... er is geen enkele browser die het 'target' attribuut niet ondersteunt en dat lijkt me ook in de toekomst geen probleem.

Maar gut ... daar moest ik even aan denken toen wat berichten voorbij zag komen over validerende code.

[crisp]

gvanh: gewoon een transitional DTD gebruiken en je bent ook klaar

Overigens zal in HTML5 het target-attribuut gewoon weer conforming zijn, er zijn gewoonweg teveel usecases waarbij er geldige rationale is om dit attribuut te gebruiken

[Blue-eagle]

@TS: Jij stelt de voorwaarden, maar je kan er alvast rekening mee houden dat de developer zijn uren inschatting hierop moet/kan aanpassen. Geef hem gewoon aan dat je geen spaghetti-code wilt, een netjes genormaliseerde database, object-geörienteerde code, een online bugtracker, svn repo's, semantisch correcte HTML, aan welke standaarden de frontend (en backend?) moet voldoen, et cetera.

Ik bedoel, als jij het logisch acht dat alle URL's "nette URL's" zijn (nieuws/artikel_naam.html in plaats van /index.ext?id=12345) en de ontwikkelaar niet, dan krijg je uiteindelijk problemen.

Jij moet dus als opdrachtgever duidelijk zijn in je opdracht. Als je alles variabel laat zal de ontwikkelaar gewoon werken zoals het hem het beste uitkomt. En mijn ervaring is dat freelancers en eenpitters vaak slecht werk leveren, tenzij je ze juist aanstuurt.

[FragFrog]

Blue-eagle schreef op vrijdag 07 september 2007 @ 11:39:
Ik bedoel, als jij het logisch acht dat alle URL's "nette URL's" zijn (nieuws/artikel_naam.html in plaats van /index.ext?id=12345) en de ontwikkelaar niet, dan krijg je uiteindelijk problemen.

Dat soort dingen kun je vaak al uitstekend aan zien komen door naar oude sites te kijken, wat ookal eerder opgemerkt is in dit topic: bekijk een rits andere sites die je developper geschreven heeft, in een breed scala browsers en je krijgt direct een idee hoe deze persoon werkt en wat voor code je kan verwachten. Zijn er enkele zaken niet naar je zin leg je deze vast in je contract of ga je toch voor een ander.

Zeker zoals Crisp al zei, je hebt frontend- en backenddevelopment en er zijn maar weinig personen die beide goed kunnen. 52 uur is naar huidige tarieven toch een behoorlijke smak geld, als hij al aangaf dingen te gaan splicen ed zou ik persoonlijk gaan twijfelen aan zijn capaciteiten als developper. Als zijn andere werk dan ook niet bepaald netjes is zou ik ook bepaalde harde eisen gaan stellen zoals mijn bovenbuurman al opmerkt.

[Verwijderd]

Blue-eagle schreef op vrijdag 07 september 2007 @ 11:39:
Ik bedoel, als jij het logisch acht dat alle URL's "nette URL's" zijn (nieuws/artikel_naam.html in plaats van /index.ext?id=12345) en de ontwikkelaar niet, dan krijg je uiteindelijk problemen.

Jij moet dus als opdrachtgever duidelijk zijn in je opdracht. Als je alles variabel laat zal de ontwikkelaar gewoon werken zoals het hem het beste uitkomt. En mijn ervaring is dat freelancers en eenpitters vaak slecht werk leveren, tenzij je ze juist aanstuurt.

Precies. Alles waar je zekerheid over wil leg je vast, en dat hoort dus in de offerte. Ik heb klanten gehad die het geen bal interesseerden hoe hun site in elkaar zat, als 't maar werkte. De specificatie was iets als 'een site met functionaliteit x y en z'.

Voor een andere klant moest ik aangeven dat ik voor stijlinformatie zo veel mogelijk externe css bestanden moest gebruiken, behalve als het niet anders kon (en dan moest ik het onderbouwd aangeven).

Moraal van het verhaal: als opdrachtgever specificeer je wat je belangrijk acht. Als opdrachtnemer stuur je een verhaal terug (offerte) waarin je benoemd wat je denkt dat je opdrachtgever belangrijk vind. Als er de match goed genoeg is heb je een overeenkomst.

[alienfruit]

Je leert dan misschien niet veel over het gebruik stylesheets en semantiek icm html, maar je leert wel goede project plannen en/of voorstellen te schrijven op multimedia opleidingen.

[ Voor 18% gewijzigd door alienfruit op 09-09-2007 17:37 ]

[Verwijderd]

alienfruit schreef op zondag 09 september 2007 @ 17:36:
Je leert dan misschien niet veel over het gebruik stylesheets en semantiek icm html, maar je leert wel goede project plannen en/of voorstellen te schrijven op multimedia opleidingen.

Wat dat betreft heb je meer aan een heao-CE opleiding, op de multimedia opleiding waar ik zat werd alleen geleerd om een projectvoorstel te schrijven. Das niet perse gelijk aan een goed projectvoorstel

[Verwijderd]

Thanks voor de tips!

Vinden jullie dat een webdevver met een marktconform tarief dit soort technieken standaard moet leveren of is dit meerwerk?

[Verwijderd]

Verwijderd schreef op woensdag 12 september 2007 @ 20:15:
Thanks voor de tips!

Vinden jullie dat een webdevver met een marktconform tarief dit soort technieken standaard moet leveren of is dit meerwerk?

Wat je niet in je offerte aanbiedt is meerwerk. Dus ik heb geen flauw idee of je zelf wel begrijpt wat je precies bedoelt.

[Verwijderd]

Verwijderd schreef op woensdag 12 september 2007 @ 21:49:
[...]

Wat je niet in je offerte aanbiedt is meerwerk. Dus ik heb geen flauw idee of je zelf wel begrijpt wat je precies bedoelt.

Sorry, ik zal het even verduidelijken.

Ik ben dus nu teruggekomen met een aantal wensen (W3C valid, leesbare url's) die niet tijdens het eerste gesprek ter sprake zijn gekomen. De devver beschouwt deze daarom als meerwerk en schroeft zijn prijs voor dit extra werk op.

Ben ik nou de verantwoordelijke die dit soort technische zaken in het voorstadium ter sprake moet brengen? Of mag ik verwachten dat de devver dit standaard implementeert of het zou aandragen in het gesprek?

[krvabo]

W3C-valid is gewoon een wens/eis die je niet écht onder meerwerk kunt vatten. Als je een XHTML Strict doctype wil en dan nog W3C-valid code wil.. mja dan vind ik het vallen onder meerwerk. Als je een HTML 4.01 Transitional site met W3C-valid code wil vind ik dat iedereen dat gewoon moet kunnen.

Leesbare URL's is opzich niet echt moeilijk, maar kost wat tijd. Dit is dus wel meerwerk.
Als je vooraf een functioneel plan hebt overlegd met de developer waarin latere besluiten niet zijn opgenomen dan valt dit onder meerwerk.

Overigens.. 52 uur voor 2000 euro (~40 euro per uur) voor een devver die niet W3C-valid progt.. damn. Dan word je flink afgezet. Dan zal ie toch in andere zaken flink goed moeten zijn.
Een freelancer die dit soort zaken kan ben je veelal niet meer dan 15-20 euro per uur aan kwijt. Misschien is ie iets langzamer, maar dat maakt ie dan weer goed in prijs/uur.

Ik zou nog eens goed overwegen of je wel zo'n devver wil

[Max|Burn]

Een freelancer die dit soort zaken kan ben je veelal niet meer dan 15-20 euro per uur aan kwijt.

Een freelancer voor 15-20 euro? We hebben het hier toch niet over bijbeunende studenten of wel ? . Als je je kosten aftrekt van die15-20 euro verdien je haast niets meer. 40 Euro is een vrij normale rate.

Verder vind ik wel dat hij gewoon conform standaarden moet devven. 40 euro / uur voor een webdeveloper die geeneens validated code schrijft.. Ga dan nog eens na waarom je deze offerte zou moeten accepteren ? Het stikt van de webdevelopers (zeker dit type ).

[Verwijderd]

Verwijderd schreef op donderdag 13 september 2007 @ 03:34:

Ik ben dus nu teruggekomen met een aantal wensen (W3C valid, leesbare url's) die niet tijdens het eerste gesprek ter sprake zijn gekomen. De devver beschouwt deze daarom als meerwerk en schroeft zijn prijs voor dit extra werk op.

Terecht. Als is afgesproken dat de site in IE6, IE7 en FF2 moet werken, is er nog niets gezegd over validerende code, zoekmachineoptimalisatie, friendly URL's, etc. Als je daar niets over zegt vind je het kennelijk ook niet belangrijk.
Later vind je het ineens wel belangrijk, en nu moet hij misschien iets gaan ombouwen, of extra werk gaan doen.

Ben ik nou de verantwoordelijke die dit soort technische zaken in het voorstadium ter sprake moet brengen? Of mag ik verwachten dat de devver dit standaard implementeert of het zou aandragen in het gesprek?

Dat is compleet afhankelijk van jouw kennis van zaken. Als je niet over dit soort dingen begint, zal hij er vanuit gaan dat je er niet zoveel van weet, en je dus niet vermoeien met dit soort verhalen. Of hij het standaard aanbiedt is zijn zaak.

[ Voor 5% gewijzigd door Verwijderd op 13-09-2007 08:09 ]

[Max|Burn]

Later vind je het ineens wel belangrijk, en nu moet hij misschien iets gaan ombouwen, of extra werk gaan doen.

Ze zitten nog in het stadium van offerte dus dat valt wel mee. Dat de TS nu wel over validatie begint moet voor de offerte niet uitmaken. Dat er voor overige zaken wel een meerprijs komt is te begrijpen maar validatie is toch echt niet zo vreemd en zou niet extra moeten kosten.

[ Voor 5% gewijzigd door Max|Burn op 13-09-2007 09:47 ]

[SYQ]

heb zelf vroeger ook veel projectjes gedaan voor bedragen rond de 1000 euro, uiteindelijk mee gestopt vanwege tijdsgebrek (werk nu bij een it bedrijf) maar ook vooral vanwege de klanten. altijd onduidelijk, nooit afgesproken dingen nakomen, tussendoor nieuwe ideetjes erin willen proppen etc etc

* eis iig een voortgangsgesprek, elke maandag ofzo
* neem zijn portfolio eens goed door, zoals eerder aangegeven 40euro per uur voor een devver die extra betaald wilt worden voor w3c valid websites. pfff
* vraag of hij het geheel gaat bouwen middels classes (object georrienteerd), zo niet waarom. dit zegt natuurlijk niks over de kwaliteit van de website, maar wel over zn kennis.
* behandel zowat elk punt uitgebreid en duidelijk in de eventuele contract

ps. slicen met photoshop is hoogstens halfuurtje werk, zo niet max 1 uur. laat je vanwege dit dus niet afzetten

[Blaise]

Ik ken een developer die w3c valid sites bouwt: miljard divs, met aan elke div een class, en een onclick event aan links die in een nieuw venster moeten openen. Dat wil je niet. Daarom zou ik niet speciaal validatie eisen, maar wel checken of je developer genoeg kennis heeft van semantiek, CSS en de verschillen tussen browsers. Als dat tegen meerprijs is heb je de verkeerde.

[Verwijderd]

Blaise schreef op donderdag 13 september 2007 @ 15:38:

Ik ken een developer die w3c valid sites bouwt...

Wat is W3C valid, denk ik dan. HTML code is automatisch te valideren. CSS code is automatisch te valideren. Maar je kunt niet automatisch valideren of de site wel aan WCAG richtlijnen voldoet.

[Blue-eagle]

Verwijderd schreef op donderdag 13 september 2007 @ 03:34:
[...]


Sorry, ik zal het even verduidelijken.

Ik ben dus nu teruggekomen met een aantal wensen (W3C valid, leesbare url's) die niet tijdens het eerste gesprek ter sprake zijn gekomen. De devver beschouwt deze daarom als meerwerk en schroeft zijn prijs voor dit extra werk op.

W3C-valid zou voor een goede developer normaal moeten zijn (ik doel hierbij op goede, semantisch correcte, logische HTML en CSS, geen tagsoup) en zou dus geen meerwerk hoeven zijn. Als je ontwikkelaar van deze technieken echter niet op de hoogte is, is dat ook weer "meer werk".

Mooie URL's is vaak ook meer werk (lees dit gewoon letterlijk: het kost tijd om alle URL's er mooi uit te laten zien) - dus volkomen terecht dat hij je daar uren voor laat betalen. Let wel, sommige (open source) CMS-systemen hebben zelf al toepassingen die zelf mooie URL's maken.

Ben ik nou de verantwoordelijke die dit soort technische zaken in het voorstadium ter sprake moet brengen? Of mag ik verwachten dat de devver dit standaard implementeert of het zou aandragen in het gesprek?

Als je van mijn ervaring wilt uit gaan (een stuk of 10 freelancers in de afgelopen 2 jaar): Ga er vanuit dat hij niet doet wat jij wilt. Ten eerste kan hij geen gedachten lezen (neem ik aan, voor het gemak) en ten tweede kan het zijn dat hij simpelweg niet weet dat bepaalde technieken bestaan en/of belangrijk zijn.

Je kan nooit teveel specificeren. Zeker niet bij iemand wiens werk je nog niet kent. Te weinig specificeren krijg je alleen maar spijt van. Een paar geromantiseerde quotes:

• "Dus de site mocht niet helemaal in Ajax waarbij pagina's niet te bookmarken zijn? Dat stond niet in de specificaties."
• "Ja, .png werkt immers niet in IE6." - had nog nooit gehoord van conditional comments en de bekende trucs om png werkende te krijgen..
• "Ik ben geen grafisch specialist" - plaatjes (backgrounds, borders, headers, etc.) waren veel te groot in bestandsgrootte, site werd er traag van.
• "Resizen? Dat moet de klant zelf doen" - nadat de klant een foto van 10 MB had toegevoegd welke niet automatisch werd terug geschaald.
• "Of ik test in meerdere browsers? Hmm.. hoezo?" - over een site die niet werkte op Safari/Mac
• "Niemand gebruikt Firefox" - tsja.
• "Het valideert toch?" - jawel, maar er staan nog steeds 200 tabellen in 1 pagina.
• "Het valideert toch?" - jawel, maar via Ajax laad je 1 divje vol met 200 tabellen.

De laatste twee trouwens van dezelfde persoon die in de eerste instantie de opdracht had gekregen om een semantisch correcte, validerende website te maken. Semantiek begreep hij niet echt (maar dat liet hij ons niet weten bij het accepteren van de opdracht) en de site valideerde inderdaad prima - toch jammer van de tientallen geneste tabellen.

Na de opdracht "fix dit" (beknopte samenvatting) kwam meneer aanzetten met 1 div-je in de pagina. Via Ajax werd vervolgens dezelfde tag-soup aan tables ingeladen.

Toch jammer dat de meeste problemen met freelancers komt door gebrek aan kennis bij de managers. Die stellen wel eisen maar kunnen dit niet controleren, ze weten zelf niet eens waar het precies over gaat. Tegenwoordig laten ze mij of een van m'n collega's naar het contract kijken voordat hij eruit gaat.

That said..

Ik heb ook erg goede ervaringen met freelancers, ze bestaan dus zeker wel

[krvabo]

Blue-eagle schreef op donderdag 13 september 2007 @ 19:59:
[...]

• "Dus de site mocht niet helemaal in Ajax waarbij pagina's niet te bookmarken zijn? Dat stond niet in de specificaties."
• "Ja, .png werkt immers niet in IE6." - had nog nooit gehoord van conditional comments en de bekende trucs om png werkende te krijgen..
• "Resizen? Dat moet de klant zelf doen" - nadat de klant een foto van 10 MB had toegevoegd welke niet automatisch werd terug geschaald.
• "Of ik test in meerdere browsers? Hmm.. hoezo?" - over een site die niet werkte op Safari/Mac
• "Het valideert toch?" - jawel, maar er staan nog steeds 200 tabellen in 1 pagina.

Afgezien van je valide punten verder.. Bookmarken met AJAX, als dat niet gespecificeerd is maak ik het ook niet zo. Het laten werken van PNG met alpha-channel transparantie in IE6 doe ik ook niet aan (teveel werk). Het resizen: tenzij anders gespecificeerd heb ik die instelling ook. Als de bedoeling is om in een WYSIWYG-editor plaatjes te kunnen toevoegen dan resize ik de afbeeldingen ook niet. Anders is het inderdaad een probleem van de klant. Safari/mac is niet iets waarop getest wordt. Tenzij de site enorm groot is of heel belangrijk dan is zoiets ook niet nuttig. Niet iedereen heeft een Mac.
De tabellen: Tenzij anders gespecificeerd maakt dat ook niet uit imho. Tenzij vooraf gesteld is dat het semantisch correct moet zijn (wat jij dus had gedaan) is zo werken meerwerk.
Als het tabulaire data is dan is het alleen maar goed van die tables uiteraard

[imp4ct]

Verwijderd schreef op vrijdag 07 september 2007 @ 00:33:
Vergeten te vermelden dat het project bestaat uit 52 codeeruren en de kosten >€2000.

't Is vrij moeilijk om de totale omvang van het project te schatten. Maar als er maar 52 werkuren worden aangerekend denk ik niet dat het dus zo heel groot zal zijn. Als de prijs hiervoor al boven de 2000 Euro ligt, mja dan is het een vrij hoog uurloon moet ik zelf wel zeggen. Hoewel.. meer dan 40 euro per uur vragen als een webdeveloper soms zelfs nog "normaal" is.

'k Ken wel wat mensen in die wereld en bv. een uurloon van 60 - 65 euro is soms ook nog heel normaal, maar jah... Ik denk dat het hierbij afweegt van, "hoe snel" moet het klaar zijn en mja natuurlijk de kwaliteit eh, welke eisen moet het voldoen. Als je hoge eisen stelt en het moet snel gemaakt zijn, tjah dan gaat de prijs omhoog wat logisch is denk ik.

Maar ik zou toch als 'klant' zijnde toch vragen om een meer gedetailleerde omschrijving te krijgen. Zelf volg ik een methode die'k van een vriend heb gekregen voor het opstellen van een financiële analyse wanneer ik een offerte opmaak.

vb.
Stappenplan:

• infovergadering
• structurele fase
• ontwerpfase
• ontwikkelingsfase
• afwerkingfase
• ondersteuning

Hierbij maak ik dus een document en per stap geef ik een uitgebreide uitleg wat deze inhoud en wat de kosten hiervan zijn. Zodat de klant weet wat hij kan verwachten en indien nodig ook wijzigingen hierin kan aanbrengen.

Dus bottomline.. als jij het gevoel hebt dat je te weinig info krijgt, gewoon om meer info vragen en niets houd je tegen bij andere bureaus een offerte aan te vragen.

[edit]
na de ander posts nog eens goed doorgelezen te hebben moet ik ook wel toegeven, als "klant", specifieer echt to the bone. Ok, soms zijn het maar details maar daar komt het vaak op neer. Als devver zelf doe ik dit liefst ook, zo krijg je gewoon achteraf geen last, want het document waarin staat wat er juist zal gemaakt worden, wordt door beide partijen ondertekend, 't is dan best nuttig van dingen goed en duidelijk te omschrijven zodat er achteraf geen betwistingen kan zijn.

[ Voor 13% gewijzigd door imp4ct op 14-09-2007 00:06 . Reden: Even alles doorgelezen. ]

[Blue-eagle]

krvabo schreef op donderdag 13 september 2007 @ 20:38:
[...]

Afgezien van je valide punten verder.. Bookmarken met AJAX, als dat niet gespecificeerd is maak ik het ook niet zo.

Niet om te flamen hoor, maar dan maak je dus gewoon geen goede site. In een webbased applicatie kan het wel (al valt er wat voor te zeggen dat je altijd een pagina link moet kunnen doorsturen en/of bookmarken).. maar in een website die voorziet in informatie? Belachelijk..

Het laten werken van PNG met alpha-channel transparantie in IE6 doe ik ook niet aan (teveel werk).

Een simpele conditional comment en een aparte stylesheet is alles wat je nodig hebt om het te laten werken. Een gebrek aan kennis is de enige reden om niet te testen. Oh ja, dan krijg je dingen als: "Ik heb XP/IE7, kan dus geen IE6 testen" - men kan blijkbaar ook niet even zoeken op Google.

Het resizen: tenzij anders gespecificeerd heb ik die instelling ook. Als de bedoeling is om in een WYSIWYG-editor plaatjes te kunnen toevoegen dan resize ik de afbeeldingen ook niet. Anders is het inderdaad een probleem van de klant.

Klanten zijn per definitie geen webdevelopers of grafici. Je moet ze tegen zichzelf beschermen, en iedere serverside language kan plaatjes terug schalen voor zover ik weet. Bij PHP kost het niks, ASP3.0 vereist een component (die je ook zelf kan schrijven) en .Net kan het ook gewoon zelf.

Safari/mac is niet iets waarop getest wordt. Tenzij de site enorm groot is of heel belangrijk dan is zoiets ook niet nuttig. Niet iedereen heeft een Mac.

Stukje kwaliteit.. daarbij, als je site het doet in IE7, Firefox en Opera dan werkt hij 99/100 keer ook prima in Safari/mac.

De tabellen: Tenzij anders gespecificeerd maakt dat ook niet uit imho. Tenzij vooraf gesteld is dat het semantisch correct moet zijn (wat jij dus had gedaan) is zo werken meerwerk.

Het is juist minder werk als de ontwikkelaar bedreven is in wat hij doet. Als hij meer uren gaat maken om semantisch correct te werken is hij geen professional, maar een hopeloos verouderde hobbyist.

Als het tabulaire data is dan is het alleen maar goed van die tables uiteraard

Zoals ik zei: semantisch correct. Dat betekent dus inderdaad dat je tabellen moet gebruiken waar je tabulaire data wilt weergeven.

Maargoed, ik type weer teveel.. laat ik het erbij houden dat een web ontwikkelaar juist aangestuurd moet worden omdat er in dit wereldje veel teveel prutsers rondlopen. Type "zolderkamer-neefje" zegmaar... frustrerend soms.

[Verwijderd]

Blue-eagle schreef op vrijdag 14 september 2007 @ 10:32:

Een simpele conditional comment en een aparte stylesheet is alles wat je nodig hebt om het te laten werken. Een gebrek aan kennis is de enige reden om niet te testen. Oh ja, dan krijg je dingen als: "Ik heb XP/IE7, kan dus geen IE6 testen" - men kan blijkbaar ook niet even zoeken op Google.

Zolang het niet mogelijk is om PNG afbeeldingen exact zo te kunnen gebruiken als bedoeld is, gebruik ik geen PNG. Er zijn diverse bugs, waaronder z-index ongein, en nog veel meer ellende, waardoor ik gewoon weiger PNG's met alpha channel te gebruiken.

[Cartman!]

Verwijderd schreef op vrijdag 14 september 2007 @ 10:42:
[...]

Zolang het niet mogelijk is om PNG afbeeldingen exact zo te kunnen gebruiken als bedoeld is, gebruik ik geen PNG. Er zijn diverse bugs, waaronder z-index ongein, en nog veel meer ellende, waardoor ik gewoon weiger PNG's met alpha channel te gebruiken.

Precies, ik gebruik ook nog steeds geen PNG omdat de ondersteuning brak is. Heb alles tot nu toe kunnen oplossen met GIFs gewoon ook.

[Blue-eagle]

Soms ontkom je niet aan PNG-gebruik, helaas Een scanline achtergrond die middels een transparante gradient naar rechts verloopt over een gekleurde achtergrond bijvoorbeeld, deze achtergrond kleur moest aan te passen zijn door gewoon RGB waarden op te geven. Het z-index probleem was snel opgelost door gewoon de overliggende (relevante) content een "position: relative; z-index: 9999;" stijl te geven. Da's 10 seconden typen in je CSS-template

[Blaise]

Met wat voor sadistische ontwerper werk jij?

[Blue-eagle]

In dat geval was het ook een freelancer

[Cartman!]

Blue-eagle schreef op vrijdag 14 september 2007 @ 13:45:
Soms ontkom je niet aan PNG-gebruik, helaas Een scanline achtergrond die middels een transparante gradient naar rechts verloopt over een gekleurde achtergrond bijvoorbeeld, deze achtergrond kleur moest aan te passen zijn door gewoon RGB waarden op te geven. Het z-index probleem was snel opgelost door gewoon de overliggende (relevante) content een "position: relative; z-index: 9999;" stijl te geven. Da's 10 seconden typen in je CSS-template

Zulke dingen weiger ik dan ook te maken. Als de designers dat hier produceren dan meld ik er gewoon bij dat er niet gehackt gaat worden voor een website. Als je als IE6 gebruiker eerst een grijze background ziet en ie dan verspringt naar t goede is het gewoon lelijk.