Voor wie maak je eigenlijk een website?

Er liggen een aantal erg interessante design principes ten grondslag aan HTML, de taal waarmee websites gebouwd worden. Een van de mooiste vind ik de zogenaamde Priority of Constituencies, de volgorde van kiesdistricten. De vertaling is wellicht een beetje onduidelijk, maar in dit principe wordt er bepaald wiens mening zwaarder weegt als er een conflict optreedt tussen verschillende belanghebbenden. In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. De gebruiker heeft altijd gelijk. Als de gebruiker er niet toe doet, dan heeft de author gelijk. Dat zijn wij. De designers, de developers, de content editors, en iedereen die verder meewerkt aan onze websites. Als de mening van ons er niet toe doet dan hebben de implementors gelijk, de browser-bouwers. Je kan hier uit afleiden dat het de taak is van browser-bouwers om het zo eenvoudig en prettig mogelijk te maken voor mensen om onze creaties te gebruiken. Na de implementors zijn pas de specifiers aan de beurt. Dit zijn de mensen die de HTML specificatie schrijven. En pas als allerlaatste doet de theorie er toe. Soms worden er dus beslissingen genomen die voor sommige groepen nergens op slaan. Maar tóch zijn het de juiste beslissingen omdat ze nuttig zijn voor een groep die belangrijker is.

Blingbling? Of gebruiksvriendelijkheid?

Dit is een prachtig principe. Volgens mij is het ook prima toe te passen op de dingen die we maken voor het web. Als er bijvoorbeeld een feature is die wellicht supertof is voor designers — hoei, het glimt en het beweegt! — maar die tegelijkertijd superirritant is voor iedereen die het moet gebruiken — whoah, waarom kan ik niet meer scrollen! — dan moet je het gewoon niet doen. Simpel. Parallax scrollen is irritant op de meeste apparaten. Niet doen. Geen labels op een button? Ziet er wellicht prachtig minimaal uit, maar niemand die het begrijpt. Niet doen dus. Horizontaal scrollen in plaats van normaal? Erg origineel, maar ook onbegrijpelijk. Geen mens die er iets aan heeft. Ook niet doen dus. Ik zeg niet dat je niet moet zoeken naar innovatieve oplossingen. In tegendeel. Natuurlijk moet je vernieuwen. En natuurlijk moet je site er fantastisch uitzien. Maar alleen als het de boel beter maakt voor de gebruiker. Niet als het alleen maar bewonderende tweets oplevert van mede-designers. We maken geen websites om indruk te maken, we maken websites om het leven van onze bezoekers prettiger te maken.

Abstracte development theorieën

Maar niet alleen aan de design-kant is dit principe goed toe te passen. Ook developers zouden het moeten gebruiken. In plaats van nadenken over de beste, meest efficiënte manier van code schrijven zou je moeten nadenken over het beste resultaat voor je gebruikers. Er zouden geen horror-producten als Sharepoint bestaan als iedereen zo dacht.

De laatste jaren hoor ik steeds meer developers praten over MVC frameworks op de client. Websites die helemaal gegenereerd worden vanuit JavaScript. Ik heb nooit goed begrepen waarom dat zo tof zou zijn, maar het heeft iets te maken met theoretische puurheid. Het is een perfecte manier van ontwikkelen. Ofzo. Jammer alleen dat bijna elke site die op die manier gemaakt wordt ook frustrerend traag is. Vooral op apparaten die niet zo snel zijn als de supercomputer waarop de developer zelf werkt. Tim Kadlec publiceerde laatst een blogpost met daarin de resultaten van een eenvoudig onderzoek naar JavaScript-performance in allerlei browsers op allerlei apparaten. Het maakt duidelijk hoe lang het duurt om jQuery te parsen en te verwerken op verschillende apparaten. Op high end apparaten, van die dingen die wij meestal gebruiken, is dat te verwaarlozen. Op goedkopere apparaatjes, die normale mensen gebruiken, is het absoluut niet te verwaarlozen. Het is merkbaar traag. En dit is slechts jQuery. Veel MVC frameworks zijn veel groter en complexer. En jazeker, dit zijn hele populaire apparaten. Misschien niet de apparaten die wij gebruiken, maar wél de apparaten die onze bezoekers gebruiken. En onthoud dat we daar onze websites voor maken.

Wat is de goede volgorde?

Die Priority of Constituencies is natuurlijk een uitgewerkte versie van het gezegde de klant is koning. De klant is volgens mij niet onze opdrachtgever, maar onze bezoeker. Dat is de koning. Daar moeten we het leven voor vergemakkelijken. We bouwen geen sites om onze opdrachtgever te pleasen, we maken dingen om het leven van de klanten van onze opdrachtgevers prettiger te maken.