Niet zo lang geleden mocht ik een presentatie geven over het belang van een goed front-end voor de PHP-gebruikersgroep. Natuurlijk had ik de meest obscure HTML-elementen en/of de nieuwste CSS trucs kunnen behandelen. Reuze interessant. Daar heb ik echter niet voor gekozen.

Als backender mag je best weten wat er mogelijk is/wordt met CSS3, maar het is niet erg als alleen de frontender dat weet. Binnen een project heb je namelijk veel meer voordeel van het maken van goede afspraken en van een optimale samenwerking tussen back- en front-ender.

Vroeger lagen de werelden van de ontwerpers en de front-enders mijlenver uit elkaar. Nu lijkt dat gat grotendeels gedicht. Doordat er steeds meer ontwerpers zijn die verstand hebben van internet, maar ook doordat de communicatie tussen de ontwerpers en front-enders is verbeterd. Natuurlijk komen we nog wel ontwerpers tegen die hun ego belangrijker vinden dan de belangen van de klant en vooral de belangen van de bezoekers van de site. Maar de goede ontwerpers weten inmiddels dat niet zij alleen het succes van een site bepalen.

En als het mogelijk is om ontwerpers goed te laten samenwerken met frontenders, dan kan het gat ook gedicht worden tussen het front- en backend. In een ideale wereld zouden ook de front- en backenders elkaars grootste vrienden zijn.

Waar staan we?

Zelfs de meest hardcore backend-ontwikkelaar is waarschijnlijk ooit begonnen met het schrijven van HTML. Een tijdje later ben je als backender gaan uitzoeken of er wat meer dynamische pagina’s te maken waren (en vooral hoe). Hoe diep je ook zit in .NET, PHP, Java of een andere ontwikkeltaal, je blijft te maken houden met het front-end. Alle reden dus om goed door één deur te kunnen met je front-ender, want met een goed aangeleverd front-end kun je als backender veel makkelijker werken.

Inmiddels zijn we zo ver dat de verschillende disciplines hun eigen plaats hebben gevonden in het land van de webwerkers. Door deze keurige scheiding van de verschillende rollen is het voor iedereen die betrokken is bij een project duidelijk wie voor wat verantwoordelijk is. En ook het onderhoud aan de site of applicatie is een stuk makkelijker als iedereen weet waar -ie aan toe is.

Maar de scheiding tussen de disciplines lijkt in een aantal gevallen net iets te ver door te slaan. Het is verstandig om de rollen helder te hebben, maar als dat betekent dat er dingen “over de schutting” gegooid worden lijkt me dat niet iets waar iemand voordeel bij heeft. Jij niet, de opdrachtgever niet en uiteindelijk de bezoeker van je website — of gebruiker van de applicatie — al helemaal niet. Zodra er iets over de schutting wordt gegooid is er immers sprake van desinteresse en daar wordt een project niet beter van. Dat kan anders.

Waar gaan we heen?

Ik weet uit ervaring dat alle front-enders echt hele aardige mensen zijn. Tijdens mijn bezoek aan twee PHP-conferenties heb ik gemerkt dat backenders ook bijzonder vriendelijk zijn. Tijdens mijn laatste presentatie zag ik echter voldoende hoofden instemmend knikken om te concluderen dat er nog steeds te weinig overleg is tussen de front- en backenders in een project. Dat kunnen we verbeteren met een — kleine — gedragsverandering.

Het lijkt mij stukken beter als voortaan ook de backender zo snel mogelijk aanschuift bij het project. Op dit moment spreken de ontwerpers met de opdrachtgevers, en in veel gevallen zullen ook de front-enders hierbij betrokken worden. Maar ook jij als backender zou vanaf de start bij de gesprekken uitgenodigd moeten zijn. Niet om vanalles tegen te houden, maar wel om goed in te kunnen schatten wat er van je verwacht wordt.

Je rol hierbij is duidelijk. Je luistert en je schat in wat mogelijk is: het wordt namelijk jouw taak om mogelijk te maken wat er wordt bedacht. Je geeft dus vroegtijdig aan wat de te verwachten investering zal worden. Deze actieve rol zal ervoor zorgen dat je straks niet met het idee zit dat je een sluitpost bent. Bij het maken van plannen binnen onze projecten komen bij ons in ieder geval ook hele heldere en nuttige ideeën van de backenders. Een bijzonder waardevolle aanvulling.

Als backender ben je er namelijk bijzonder goed in om snel te analyseren welke impact bepaalde front-endbeslissingen hebben op de planning, het budget, de onderhoudbaarheid en schaalbaarheid van het product. Die input is vanzelfsprekend bijzonder waardevol, je kunt immers niet altijd verwachten dat je opdrachtgever of accountmanager dit precies weet in te schatten.

Wat is er voor nodig?

Verder mag je eisen stellen aan de aanlevering. De professionalisering heeft ook aan front-endzijde niet stilgestaan. Een duidelijke sitemap, flowchart en/of FO is het minste wat je mag verwachten van je front-ender. Je mag echter best om meer vragen. Hieronder een lijst met mogelijkheden die je als startpunt kunt gebruiken. Pas 'm aan met de dingen die voor jou belangrijk zijn.

• Vraag om valide én betekenisvolle HTML

  Qua aangeleverde templates mag je verwachten dat er valide en betekenisvolle HTML geschreven wordt door de front-ender. Als jij met goede templates aan de slag kunt, mag men van jou ook kwaliteit verwachten. Accepteer geen broddelwerk meer (als je je werk leuk wilt houden)!

• Vraag om valide CSS

  Als je hebt gevraagd om valide HTML dan is er niks mis mee om je front-ender ook te vragen om de CSS te valideren. Het is een kleine moeite voor je front-ender om even de CSS te valideren voordat zij wordt aangeleverd. Zie het als een kwaliteitscontrole en ijkpunt voor het aangeleverde materiaal.

• Vraag — indien gewenst — om <!-- commentaar -->

  Stel jezelf de vraag wat de front-ender kan doen om jouw werk makkelijker te maken. Moet je steeds zoeken naar welk div-je wordt afgesloten in de HTML en zou het handig zijn als de markup is voorzien van commentaar — zoals in onderstaand voorbeeld — vraag hier dan om. De front-ender doet het graag voor je (al was het maar omdat het zijn of haar eigen werk ook makkelijker maakt)!

    </div> <!-- #voettekst -->
  
   </div> <!-- #content --> 
  </div> <!-- #kader -->
  

• Vraag goede documentatie

  Vraag om uitleg van het aangeleverde materiaal, zowel in een gesprek als in documentatie. Een opzet voor deze documentatie is al gratis af te halen op Front-end documentatie, aan jou de eer om deze aan te vullen met voor jou relevante eisen.

• Geef – indien nodig – aanwijzingen om de performance te verbeteren

  Stel je op de hoogte van de regels om de performance van de website te optimaliseren. Krijg je templates met 8 gelinkte CSS-bestanden en/of 16 JavaScript-bestanden die aangeroepen worden? Dan is duidelijk dat jouw front-ender geen rekening heeft gehouden met hoe je de performance zo goed mogelijk kunt maken. Help hem of haar dan hiermee. Bel eens op en leg voor wat je verbetervoorstellen zijn. Maar ga nooit, ik zeg nooit, zelf in het front-end aanpassingen maken (tenzij je hierover hele heldere afspraken hebt ;-)). Je kunt deze verschillende rollen het beste zo helder mogelijk houden. Mocht er onverhoopt iets misgaan, dan weet je snel wie het kan oplossen.

En als laatste… informeer je opdrachtgever

Als jij en je front-ender tot goede afspraken zijn gekomen en ook een heldere documentatie en/of afspraken hebben, bespreek deze dan ook met je opdrachtgever. Negen van de tien opdrachtgevers willen best — op lekenniveau — geïnformeerd worden over wat hun site kan en welke beslissingen je hebt genomen.

Jij bent aan het eind van het project degene die precies weet wat er in de toekomst aan uitbreidingen mogelijk is (want dat was je basis). Als je dit met je opdrachtgever bespreekt dan zal het — hopelijk — tot een visie voor de verdere ontwikkeling van de site leiden. Je opdrachtgever krijgt hierdoor nog meer binding met haar product en zal er — in dezelfde negen van de tien gevallen — zorgvuldiger mee omgaan.

Als iedereen zich in dienst kan stellen van de bezoeker van de website, en effectief kan samenwerken, wordt het er echt voor iedereen een stuk leuker op.

• Home
• Artikelen
• Colofon