Wie bepaalt er wat voor grid er gebruikt moet worden in een nieuw te bouwen site? Wie beslist er welk CMS er gebruikt moet worden? Wie bepaalt er hoe de HTML er uit ziet? Dit zijn allemaal redelijk eenvoudige vragen, maar de antwoorden zijn niet zo eenvoudig. Zeker niet in een groot design-team. Het hangt er vaak maar vanaf.
Grids
Laatst sprak ik met een design-team van een groot Nederlands webbureau. We hadden het over hoe multidisciplinaire design-teams samen zouden moeten werken. Iedereen is het er op zich wel over eens dat er meer samengewerkt moet worden, maar hoe? En wie beslist wat precies? Ze kwamen met een voorbeeld. De grafische ontwerper had een ontwerp gemaakt wat gebruik maakt van een mooi asymmetrisch grid. Volgens de ontwerper kwam de content hierdoor veel beter tot z'n recht. De front-end developer daarentegen vond het veel te complex: "wij gebruiken bootstrap" zei hij en paste de hele layout aan zodat alles in een saai 12-koloms grid past. Natuurlijk vindt de ontwerper dit niet tof. Maar wie heeft er in dit geval gelijk? Wie moet deze keuze maken? Je zou zeggen dat dit de verantwoordelijkheid van de grafisch ontwerper is. Maar er is ook wel iets voor te zeggen dat de developer er iets over te zeggen heeft. Als het twee dagen duurt om een complex asymmetrisch grid te bouwen, en het kost een uurtje om een bootstrap-grid in te zetten dan is er discussie mogelijk. Twee dagen werken aan een grid betekent twee dagen niet werken aan iets anders. Dit geldt overigens voor alle features. Blingbling staat vaak tegenover budget. Daar moet over gediscussieerd worden. Beslissingen moeten weloverwogen genomen worden en door het hele team gedragen worden.
Overigens is er geen enkele reden om saaie bootstrap-grids te gebruiken. Ik raad alle ontwerpers die ooit in deze discussie verzeild raken aan om ervaring op te doen met Gridset, een tool waarmee je responsive grids kunt ontwerpen. Er komt zelfs kant en klare code uit. Hiermee neem je het budget-argument direct weg en kan je wél spannende layouts maken. Wat mij betreft heeft iedereen die bootstrap zegt per definitie altijd ongelijk.
HTML
Front-end developers bepalen hoe de HTML gestructureerd moet worden, vaak aan de hand van wireframes en photoshop mockups. Dit doen ze meestal alleen. Terwijl dit toch een nogal fundamenteel werkje is: tijdens het schrijven van de HTML wordt er bepaald wat er belangrijker is. De hiërarchie van de pagina. Vaak is die wel een beetje af te leiden uit de mockups, maar vaak ook niet helemaal. En bovendien kan je je afvragen: het ontwerpen en bouwen van het fundament van elke pagina, moet je dat wel overlaten aan één enkel persoon? Ik zelf denk van niet. Er zijn bepaalde keuzes in het ontwerpproces die je niet door één enkele specialistische discipline moet laten nemen. En de structuur van de HTML is er daar een van. Daar hebben alle leden van het design-team mee te maken. En bovendien is de structuur van de HTML ook nog eens van invloed op andere design-keuzes. Maar ik denk dat in dit geval er iets anders aan de hand is: de structuur van de HTML wordt niet alleen door te weinig mensen bepaald, hij wordt vooral te laat bepaald. Ik denk dat de HTML structuur tegelijk ontworpen moet worden met onderdelen van het grafisch ontwerp. Die twee dingen zijn namelijk van invloed op elkaar.
CMS
Dit zijn geen onoverkomelijke design-problemen. Een paar keer goed met elkaar praten lost dit wel op. Er worden veel dommere beslissingen gemaakt door de verkeerde mensen, vooral in hele grote organisaties. De keuze voor een CMS bijvoorbeeld. Die keuze wordt bijna altijd gemaakt door de business en door back-end developers. Bizar genoeg wordt hier bijna nooit een content-editor en al helemaal nooit iemand uit het design-team bij gevraagd. Ik denk dat dat een van de redenen is dat alle enterprise CMS'en zo krankzinnig slecht zijn. De keuze voor zo'n CMS wordt door de verkeerde mensen gemaakt, op verkeerde gronden. Bovendien wordt die keuze vaak ook veel te vroeg gemaakt. Hoe kan je nou beslissen wat voor systeem je nodig hebt als je nog helemaal niet weet wat voor oplossing er moet komen?
I will be teaching about colour in the coming weeks. One of the things I definitely want to discuss is the idea that you cannot be certain of how people will view your colours. Of course there are environmental differences: is the viewer standing in the sunshine, is it dark, are there reflections, is the room lit by light-bulbs, halogen or candles? Is the user colour blind? These factors are not unique to the web though, they also apply to paint, printed material and all other coloured things.
So what about the web?
Dit weekend, tijdens het procrastineren, heb ik een webpagina gemaakt die elke keer een van de principes uit de collectie van Adactio toont. Ik hou van deze principes. Je kan je werk er aan toetsen, en bovendien zijn ze veelal bedacht door mensen die slimmer zijn dan ik. Het zijn ook prima punten om eens goed over na te denken. Zo heb ik altijd moeite met het eerste punt van de ten principles for good design van Dieter Rams. In dat punt staat dat goed design innovatief is. Hier ben ik het helemaal mee eens, of absoluut mee oneens, afhankelijk van de gebruikte definitie van innovatie.
Innovatie, mooi woord
Ik zat laatste te lunchen met een vriend. Hij was gevallen met de fiets en had zijn hand gebroken. Zijn hele arm zat in het gips. Eten ging op zich prima maar het draaien van spaghetti was wat lastig. En het bedienen van zijn computer ook. En dat is natuurlijk vervelend voor iemand die met computers werkt. Maar het is ook niet onmogelijk. Veel programma's en websites zijn zo gemaakt dat ze ook met een handicap prima te bedienen zijn.
Best fijn, eigenlijk
Every now and then I hear designers say that black should not be black. That instead of using
color: black; you should use something like
color: #666;. I heard people defending this argument by saying that in real life black is never really black. The ink in a book? Not really black. A black t-shirt? Not really black. The colour of my phone? Not really black. So, we argue, since black things are not really black in real life, they shouldn't be black on our screens.
Makes sense, right?
Een product design team, bijvoorbeeld een team dat nieuwe TV's ontwerpt, bestaat van oudsher uit drie disciplines. Een interaction designer die nadenkt over wat de gebruiker met het ding moet kunnen doen. Een visual designer die nadenkt over hoe het ding er uit moet zien. En een developer die nadenkt over wat er allemaal mee mogelijk is, die onderzoekt waar de grenzen van de huidige techniek liggen. Een tijd geleden sprak ik eens met iemand uit het TV-design-team van Philips. Voor hem was het vanzelfsprekend dat deze drie disciplines samen aan een TV werkten. In de jaren tachtig wilden designers natuurlijk ook heel graag hele platte TV's maken. En het zou ook heel eenvoudig zijn om prachtige prototypes te maken, van piepschuim ofzo. Maar hoe hard ze ook zouden willen, het was toendertijd gewoon technisch onmogelijk. Een TV had een beeldbuis en een beeldbuis was dik.
Maar websites zijn toch niet dik?
According to Bringhurst there are a few ratios that look fantastic. These ratios have been used for ages for things like sheets of paper and books, but you can also find them in architecture, paintings, sculptures and in nature. And even in music. These ratios look pleasant, they sound good, and they make sense in a mathematical way, so we should probably use them. So I wondered, can we create and use them on the web?
Can we?
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.
Dat is wat anders dan consensus, toch?
A while ago I created a tool to help you define the ideal length of line for text on the web. You can adjust a few variables, like
font-family and language. When you slide the slider it shows you how many words there are on a line, or how many characters. You can now choose an ideal measure depending on the theory you like most (10 words or something between 45 and 75 characters). It turns out there's a much easier way to define an ideal measure, according to Bringhurst.
Exciting, what is it?
There are a few ways to determine the breakpoints for layout in a responsive design. The first one is based on the size of common screen sizes. The second one adds breakpoints when the content breaks. The third one is based on things like font-size. And there's another one which uses a system of predefined columns.
A, nice, columns
You can't use the em as a unit in most pixel-editors. If we use these types of editors in our design process, this means that we have to calculate em-sizes from pixel-sizes. And if we do that, an
em seems like a terribly complex unit. Pixels use the simple metric system, which is easy to use. We all know how to count from 1 to 10. If we calculate em-sizes from pixel-sizes we're suddenly working with multiples of 16, instead of 10. Which is much harder.
But pixels are hard as well