Front-end development: onderschat, maar van onschatbare waarde

Dank voor dit artikel, Raymond. Ik moet bij klanten vaak uitleggen wat front-end is en dit artikel helpt daar erg bij als ondersteuning. Wat ik nog mis is vermelding van de vakvereniging Fronteers (http://www.fronteers.nl) en het belang van een goed front-end als je wilt voldoen aan standaarden als Drempelvrij of Webrichtlijnen.

“is in staat een goed grafisch ontwerp neer te zetten. Er is heel veel voor te zeggen om het grafisch ontwerp en de (x)HTML door één persoon te laten maken.”

 
Tja, dat zou nog eens mooi zijn zeg. En als die het dan ook nog even programmeert en oplevert, dan ben je helemaal klaar ;) Zonder gekheid, het zou zeker zo moeten zijn dat de grafisch ontwerper de beperkingen van HTML kent en de gevolgen van z’n design voor cross-browser compatibiliteit en andere front-end issues. Het dan ook nog gaan maken, vind ik zelf een stap te ver.
In de praktijk komt het (behalve bij ZZP’ers natuurlijk) volgens mij ook vaker voor dat de grafisch ontwerper een andere persoon is dan de, oneerbiedig gezegd, html’er. Ik krijg helaas vaak genoeg PDF bestanden van 4000×2500 pixels van gerenommeerde Amsterdamse reclame bureaus wat dan ‘webdesign’ genoemd wordt.
 

Want of je nu Internet Explorer, Firefox of Safari gebruikt, een website moet er in alle gevallen hetzelfde uitzien, toch?

http://dowebsitesneedtolookexactlythesameineverybrowser.com/
Even rechtzetten hoor, deze stelling. Ik doe heel erg m’n best om collega’s/klanten te overtuigen dat het niet moet.
 
 
 

@Raymond leuk artikel op zich :) Toch vind ik absoluut dat een visual designer goed moet zijn in heel andere zaken dan een interactie designer en al helemaal een front-end developer. Dat zijn duidelijk verschillende vakgebieden. Een goede front-end developer (ken er weinig overigens en pretendeer net zo min dat ik dat ben of ambieer) weet van alle technische middelen om de interactie designer (haast een filosoof / psycholoog) en visutal designer (houdt van kleuren en zal met de interactie designer tot een helder ontwerp voor de doelgroep moeten komen) te kunnen adviseren om gezamenlijk tot een goede front-end te komen.
Een front-end developer is overigens ook verantwoordelijk voor de implemenatie van Drempelvrij of liever gezegd, het houden aan standaarden op zich, of het hier nu gaat om de accessability, opmaak of anders. Zelf ben ik destijds betrokken geweest bij de beoordeling van Drempelvrij in 2007. Toen was het nog gebaseerd op de Web Content Accessability Guildelines 1.0 (uit 1999). Deze WCAG 1.0 voldeed al snel niet meer, dus is in 2001 het traject voor WCAG 2.0 gestart. Destijds jammer te zien dat een overheidsbesluit (wat de commitment aan drempelvrij was) zich aan 1.0 committeerde, want dat was eigenlijk voor die tijd een wassen neus, maar het is goed te zien dat ze een volgende stap aan het maken zijn.

“@ellen: absoluut, in alle browsers dient de website er hetzelfde uit te zien. Althans natuurlijk niet altijd op de pixel maar het kan niet zo zijn dat bepaalde informatie of functionaliteiten op een compleet andere manier getoond worden.”
Maar je kunt van een mobiele browser toch niet in alle gevallen hetzelfde verwachten als van een desktop browser. En van IE6 toch niet hetzelfde als van Safari of Opera. Je geeft zelf aan dat je de content makkelijk op verschillende kanalen wilt kunnen benaderen, dan is het toch logisch dat dat dit gevolgen heeft voor de weergave ervan. Je magnetron-schermpje zal waarschijnlijk niet veel beter kunnen renderen dan Lynx en dan heb ik het nog niet eens over een braille regel.
D.m.v. progressive enhancement kun je de gebruiker de beste weergave/experience geven die zijn/haar user agent aankan. En zelfs wanneer ze hetzelfde kunnen kan de weergave toch nog anders zijn. Denk maar aan de native weergave van formulier velden. Je kunt proberen die er in iedere browser hetzelfde uit te laten zien, maar dien je daar de gebruiker mee? Die is ongetwijfeld bekend met de native look. En hoe vaak switched die gebruiker tussen user agents?
Ik sluit me dan ook graag aan bij Ellen en de site waarnaar ze linkt.
En zoals Peter-Paul Koch (Quirksmode.org) ook al aangaf in zijn recente presentaties op Fronteers 2009 en Full Frontal: met de opkomst van het mobiele web en de grote verschillen tussen mobiele browsers is het idee dat websites er in iedere browser hetzelfde uit moeten zien absoluut niet meer houdbaar.

@Timothy Eens dat alles te nuanceren valt. Mensen die alles van voor tot achter écht kunnen, zullen er zijn, maar die zijn zeldzaam. Daarnaast is een en ander ook afhankelijk van projectgrootte en dus vaak budget. Je gaat niet functioneel ontwerpers, interactie designer, visual designer en front- en back-end developers optrommelen als je 1500,- te besteden hebt.
Interactie design gaat overigens niet over interactie “zien”, maar interactie definiëren. Schroom daarbij niet om aan de hand van de laatste (vaak psychologische) onderzoeken en inzichten iets nieuws te proberen. Intuïtieviteit is key, voor de rest veelal afhankelijk van de doelgroep.
Meeste van je stellingen ben ik het mee eens. Ik ken echter maar een heeeel beperkt aantal die-hard programmeurs die het echt in zich hebben. Ik heb op zoveel grote projecten programmeurs gezien die maar wat aanklooien. Het abstractieniveau dat je daarvoor moet hebben (gaat dan niet alleen over websitejes bouwen, maar ook aansluiten op service bus, enz), is simpelweg niet aan te leren en moet in je zitten, net als creatieve eigenschappen in andere functies.

Waarom zou er wel een duidelijke lijn te trekken zijn tussen interaction design en front-end development, maar minder tussen visual design en front-end. Ik zie dat niet.Persoonlijk voel ik me als front-end developer dichter bij een interaction designer staan, dan bij bij een visual designer. Ben ik dan de norm? Nee, natuurlijk niet, al denk ik dat natuurlijk wel graag ;)
De front-end developer implementeert zowel het interaction design als het visual design, waarbij het interaction design ook reeds verwerkt is in het visual design.

@Raymond moet de lay-out op twee verschillende mobieltjes wel hetzelfde zijn?
Dezelfde lay-out in verschillende situaties (bijvoorbeeld IE6/Windows, Safari/Mac) is iets wat nu voor een aantal jaren technisch (bijna) mogelijk is geweest, maar ik denk dat we er steeds meer afstand van moeten nemen. Er zijn nu al veel situaties waarin web content wordt gebruikt, waaronder mobiel internet en brailleregels, en het worden er steeds meer (zie Yahoo brengt content van het internet naar tv-schermen met hun widget engine). Het gaat om de content. Hoe die precies wordt weergegeven hangt maar net af van de mogelijkheden die het weergevende apparaat heeft. Natuurlijk is het mooier als een website er hetzelfde uitziet in verschillende browsers, maar ik denk dat we voor die ene fancy slideshow best Internet Explorer 6 een eenvoudigere versie kunnen aanbieden. Net zoals we dat doen voor gebruikers die geen javascript hebben. Laten we ons ‘slim’ bezighouden met browsermogelijkheden en richten op wat het belangrijkst is: inhoud en betekenis. 

@Raymond HTML is handig voor publicaties die tientallen jaren onveranderd bruikbaar moeten blijven, maar de code van de gemiddelde website gaat door andere oorzaken dan technische houdbaarheid maar zo kort mee dat veel van de genoemde voordelen van een goede front-ender zelden tot zijn recht komen.

Leuke post, Raymond.
Ik ben respectvol maar sterk oneens met de stelling dat websites in alle browsers hetzelfde er uit moeten zien, en daarmee ook met de implicatie dat een goede front-ender iemand is die achterhaalde technieken hanteert om achterhaalde browsers te accommoderen (rounded corners, anyone?). Een website overal hetzelfde er uit laten zien mag wel een eis zijn van bepaalde opdrachtgevers, maar het hoort niet thuis in een lijst criteria voor goede front-enders. Hooguit kun je zeggen dat een goede front-ender het wel moet kunnen, of “weet hoe het moet”. Maar overal hetzelfde ontwerp is zelden noodzakelijk en evenmin wenselijk: zie bijv. de vele comments over mobiel. Overigens, welke browser support profile hanteerde jij bij het maken van die stelling, en hoe weet een opdrachtgever wanneer dat bijgesteld moet worden?
Dit idee, deze overloper van het print-ontwerp terrein, mag wat mij betreft uit de wereld worden geholpen. Dit zal ook liggen aan, naast de keuze voor een goede front-ender, de keuze voor een goede webdesigner die alles weet over de eigenschappen van ons medium. En opdrachtgevers mogen ook weten dat de dingen die wij moeten doen om bijv. al die leuke transparante effectjes in IE6 werkende te krijgen, ten koste gaan van onder andere die performance waar jij het over hebt.
Exacte weergave is alleen belangrijk als de opdrachtgever het belangrijk vindt, maar dan nog zou ik adviseren om eerder te kijken naar user experience; wie gebruikt tenslotte een website in meer dan één browser tegelijk?
Drie dingen werden altijd geadviseerd consistent te houden over alle browsers: user experience (niet design perse), informatie en functionaliteit. Het Web gaat pas echt loskomen op het moment dat wij beginnen deze drie factoren aan te passen aan de context van de gebruiker. En die is overal anders.

@Timothy Als een website onderdeel is van een multi-channel uiting hoeft een “normale” gebruiker niet 6 browsers open te hebben om te zien dat de ene uiting wel “rounded corners” heeft en de ander niet. Zolang front-enders om interne technische redenen dit soort dingen als issues willen zien graven ze hun eigen graf omdat er genoeg Flashers klaar staan die niet moeilijk gaan doen over wat voor corners dan ook.

Hoe communiceer je dat dan goed met de klant? “Voor EUR 50 extra zouden we de huisstijl met afgeronde hoeken in alle mainstream browsers kunnen implementeren, maar sinds er daarvoor een voor front-enders politiek correcte manier bestaat die helaas niet ondersteund wordt door browsers waar we toch al een hekel aan hebben zouden we de huisstijl in die browsers liever niet helemaal door willen voeren”?

@Roland Je gaat wel heel kort door de bocht. Wanneer je “rounded corners” als voorbeeld neemt is het heel simpel. Of je werkt bijv. met een javascript oplossing of je werkt bijv. met afbeeldingen, beide zaken zorgen voor een overload. Als je dit communiceert hoeft het geen probleem te zijn.

@Timothy Ja, als je al dit soort details moet communiceren kan ik me voorstellen dat je het prettiger vindt om design en code beide uit te voeren. Dan komt het er op neer dat de communicatie met jezelf gewoon denken in beperkingen is.

@Sander Niet kiezen voor een 9-slice die prima werkte in de tijd van Netscape 4 en dial-up is geen technische reden, maar een politieke. Dat is leuk voor een persoonlijk blog, maar niet iets om klanten mee lastig te vallen.

@Timothy @Renata Ik ben het met jullie eens, en nogmaals, ik vind deze post heel nuttig voor opdrachtgevers. De diepte is niet belangrijk voor de klant, maar ik vond het nodig om een bordje “Let op: water is dieper dan 2m” te plaatsen :) Voor de veiligheid, zullen we zeggen.
Timothy heeft het wat mij betreft mooi opgehelderd.

@Timothy LOL! Ik ben ook maar pas in 2000 onder leiding van ppk als professioneel front-ender begonnen en heb sindsdien ook maar tientallen sites die aan drempels weg richtlijnen voldeden voor verschillende ministeries opgeleverd.

Dus, ik ben bang dat als een klant naar aanleiding van dit verhaal geïnteresseerd raakt in de kwantificering van de issues hij bedrogen uit komt. Mooi dat nette code wat in traffic scheelt, maar de meeste sites hebben niet zo bizar veel bezoekers dat de tijd die zo’n optimalisatie kost ooit terug verdiend wordt. Leuk dat Google misschien rekening houdt met snelle code, maar als de site daardoor op plaats 900 in plaats van 10000 in de zoekresultaten terecht komt heb je daar ook niet veel aan. Technisch gaat nette code misschien niet stuk op een wat exotischer device, maar hoeveel gebruikers zijn daar echt blij mee en switchen niet toch naar een normale browser omdat dat toch lekkerder werkt? Het zijn allemaal voordelen van HTML die als het er echt op aan komt de mogelijkheid bieden met heel veel extra resources er ook echt wat mee te doen, maar zonder die extra resources levert het zelden spontaan iets nuttigs op.

[...] http://www.frankwatching.com/archive/2009/12/02/front-end-development-onderschat-maar-van-onschatbar… [...]

Interessanter is waarom alleen front-enders graag melden dat ze die andere dingen ook kunnen, maar die andere specialismen zelden melden dat ze ook inzetbaar zouden kunnen zijn als front-ender.