Nerd.

A while ago Maaike asked the question if we knew any art projects on the web. There were still a few, but not many. This raises the question why there are just a few web art projects. A simple answer would be that it’s hard to make money off a website, and many artists are money focused, obsessed even (not all, relax, I’m exaggerating). Whatever the reason, I believe it’s a shame. The web needs artists to explore its many possible shapes. I’m not talking about cool shit we can do with JavaScript per se, I’m talking about truly understanding the web.

what does that mean?

Yesterday I published all the columns I’ve written so far for the Dutch edition of Web Designer Magazine. One of the reactions I heard was that my thinking is too rational, too black and white: yes, content is important, but experience is important too. And I never talk about experience.

Explain

(This column was published in the Dutch, paper version of Web Designer Magazine. It’s in Dutch). Als je de toekomst wilt voorspellen is het een goed idee om eerst eens naar het verleden te kijken. Hoe zag het web er vijf jaar geleden uit en hadden we toen kunnen voorzien hoe het web er nu uit ziet? Even het geheugen opfrissen: begin 2008 was IE7 de nieuwste versie van Internet Explorer. Firefox zat op versie 2. De iPhone was nog niet te koop in Nederland. Google Chrome bestond nog niet. Ronde hoekjes en schaduwen maakten we nog met behulp van plaatjes en heel veel extra HTML. Elke website was 1024 pixels breed. Flash bestond nog. Apple was een marginale computerfabrikant en Facebook had 60 miljoen gebruikers (tegenwoordig zijn dat er meer dan een miljard!)

Er zijn in 2008 vast mensen geweest die hebben voorspeld dat we tegenwoordig allemaal veelvuldig gebruik zouden maken van onze mobiele telefoon, dat we non-stop aan het twitteren en facebooken zouden zijn. En mensen die voorspelden dat IE niet meer de belangrijkste browser zou zijn. Er was vast ook wel iemand die heeft voorspeld dat er nieuwe browsers bij zouden komen. Heel misschien was er ook wel iemand die het gigantische succes van app-stores zag aankomen. Er zijn zeker mensen geweest die zeiden dat Apple groter zou worden dan Microsoft. Maar niemand geloofde deze mensen. En al helemaal niemand geloofde al deze voorspellingen bij elkaar. Het is allemaal zo verschrikkelijk anders! Het is dus onmogelijk om een duidelijk beeld van de toekomst te krijgen. We weten gewoon te veel dingen nog niet.

Zekere toekomst

Maar er zijn toch wel dingen die we zeker kunnen weten, en dat zijn de dingen die hetzelfde blijven. Vijf jaar geleden had je bijvoorbeeld kunnen voorspellen dat designers nog altijd gebruik zouden maken van Photoshop om websites te ontwerpen. (Ik zou je overigens niet hebben geloofd, ik voorspelde namelijk dat alle designers nu gewoon code zouden typen). Je had ook kunnen voorspellen dat HTML, CSS en JavaScript nog altijd de bouwstenen van het web zouden zijn.

Makkelijke voorspellingen

Hieronder een paar voorspellingen. Erg spannend zijn ze niet.

1. Er komen alleen maar meer verschillende schermgroottes bij. Het idee dat een website een vast formaat heeft vinden we over vijf jaar allemaal bizar, we zullen grinnikend terugdenken aan die koppige designers uit 2013. Over vijf jaar weten we wellicht ook beter hoe al die verschillende apparaatjes het lekkerst werken. Nu zitten we nog te klooien met oude interactiemodellen, tegen die tijd hebben we vast wat mooie, goeie nieuwe dingen bedacht.
2. Klassieke typografie en klassieke theorie over vormgeving worden belangrijker. Een goed beeldend inzicht alleen is niet meer genoeg. Designers zullen naar andere zekerheden moeten zoeken nu we er achter zijn dat het web niet 1024 pixels breed is. Nu we hebben geaccepteerd dat we niet weten hoe de gebruiker onze site ziet. Lees dus vooral de boeken van Josef Müller-Brockmann en Robert Bringhurst een paar keer de komende jaren. Neem de theorie die hierin staat niet te letterlijk, vertaal ze naar de onbetrouwbare eigenschappen van het web. Degene die het boek schrijft wat deze vertaling voor ons maakt is binnen.
3. Alle browsers zijn tof in 2018, tenminste, als we het hebben over ondersteuning van de web-standaarden. Ze zijn nu al bijna allemaal tof, tegen die tijd zijn ze het echt allemaal. Dit betekent dat we eindelijk echt kunnen gaan browser-spitten: code typen volgens de standaarden en er gewoon vanuit gaan dat het overal zal werken.
4. We zullen op nog meer manieren interacteren met websites, niet meer alleen met de muis of met je vingers. Je kan nu al opdrachten roepen tegen Google, over vijf jaar zal dit overal kunnen. (Ik stel me altijd een kantoor voor waar iedereen de hele dag tegen z’n computer praat en denk dan dat het wel mee zal vallen met die spraak-interactie). Nieuwe manieren van interactie zullen de oude niet vervangen, ze komen er gewoon bij. Hier kan je nu al rekening mee houden tijdens het ontwerpen. Bijvoorbeeld door er voor te zorgen dat je ontwerp niet afhankelijk is van een muis.
5. Een groot deel van de front-end-code die we vandaag de dag met de hand typen wordt over vijf jaar door fantastische web-design-tools gegenereerd. Er bestaan nu al plug-ins die prima CSS genereren uit Photoshop-layers. Tegen die tijd genereren we nog veel meer.
6. Het web heeft in 2018 een eigen smoel. Je zult direct kunnen zien of iets een website, en geen native applicatie. Designers begrijpen het web tegen die tijd door en door, precies zoals ze papier al eeuwen begrijpen.

Zoals ik al schreef, erg spannend zijn mijn voorspellingen niet. Maar wellicht helpen ze je om de juiste professionele keuzes te maken.

(This column was published in the Dutch, paper version of Web Designer Magazine. It’s in Dutch). Veel designers vinden mij een vervelende zeikerd. Altijd maar aan het zeuren dat het niveau van webdesign niet hoog genoeg is. Ik ga eens proberen om uit te leggen wat ik bedoel, op een iets constructievere manier dan “je snapt er geen fuck van!”.

Hoe wordt je site bekeken?

Er zijn ontelbaar veel mogelijke manieren waarop jouw site bekeken wordt. Je site is onderdeel van een groter, samenhangend geheel, het web. Dat is een aaneenschakeling van documenten en applicaties die bereikbaar zijn via URL’s. Deze URL’s kunnen geopend worden met een browser vanaf verschillende apparaten. Dit laatste is een wezenlijk onderdeel van het web. Het idee is dat het web toegankelijk moet zijn voor iedereen, ongeacht het apparaat waarmee er gekeken wordt. Dit betekent dat jouw website bekeken wordt met de allernieuwste browsers op de allernieuwste gadgets, maar ook met een oude rotbrowser op een antieke computer (met bovendien een gare monitor). Jouw site wordt beluisterd door mensen die niet kunnen kijken. Je zo zorgvuldig gecomponeerde stylesheet wordt overruled door de custom stylesheets van slechtzienden die alles in zwarte 40 px letters op een witte achtergrond willen zien.

Onzekerheid

Het enige wat je dus zeker weet is dat dat niemand jouw site zo te zien krijgt zoals jij hem ziet. In het verleden hebben we altijd geprobeerd om deze onzekerheid te omzeilen, of te negeren, door een vast formaat te kiezen. Eerst waren websites 640 pixels breed, later 800, en weer later werd dat ineens 1024. We wisten wel dat sommige mensen een smaller scherm hadden, of dat veel mensen hun vensters nooit full-screen openen, maar het kwam ons wel goed uit om dat te negeren. Ik heb me hier altijd over verbaasd. Waarom ontwierpen we niet gewoon websites die gebruik maken van procenten, van verhoudingen, in plaats van vaste formaten. Dat is zo veel logischer voor het web. En bovendien kan dat heel eenvoudig met CSS.

Verkeerde tools

Ik denk dat de tools die we gebruiken om websites te ontwerpen ons uitstekend in staat stellen om prachtige plaatjes te maken. Maar het probleem met deze tools is dat ze wezenlijk anders in elkaar zitten dan het web. Ze hebben helemaal niks te maken met de zogenaamde web design stack, ze volgen een andere logica. Ik zal eens proberen om deze web design stack uit te leggen, zonder al te technisch te worden.

De basis van elke site is de content. Stel dat je deze pagina leest op een website (mijn columns worden gelukkig ook online gepubliceerd). Het enige waar ik in dat geval zeker van kan zijn is dat iedereen deze woorden kan lezen (of horen). Als je de content aanbiedt in goede, semantische HTML, zonder styling, dan kan iedereen het lezen.

Verreweg de meeste browsers (maar niet allemaal) kunnen tekst vormgeven met CSS. Je kan de font-grootte aanpassen, het lettertype, de line-height, de grootte van de verschillende kopjes, etcetera. Dit is de typografie. Het is logisch om eerst de typografie op orde te hebben voordat er gekeken wordt naar de volgende stap, de layout. Layout is namelijk niet altijd nodig: sommige apparaten zijn zo smal dat de website gerust in één kolom getoond kan worden.

Maar zodra je de site ook geschikt wilt maken voor bredere schermen zul je iets aan layout moeten doen. In de begintijd van responsive design gingen we uit van vaste formaten voor het bepalen van zogenaamde breakpoints. Deze formaten waren gebaseerd op veelvoorkomende schermgroottes. Inmiddels zijn er zo veel verschillende gadgets met zo bizar veel verschillende resoluties dat we iets anders moeten bedenken. Liefst iets wat je kunt beredeneren. Een logisch uitgangspunt voor het bepalen van breakpoints is typografie. Er zijn eenvoudige, redelijk universele wetten die voorschrijven wat de ideale regelbreedte is: tussen de 40 en de 75 karakters, ongeveer. Een logisch breakpoint is dus het moment dat de tekstkolom breder wordt dan 75 karakters. Pas op dat moment moet je iets veranderen aan de layout.

De ideale tool

Simpel gezegd is de web design stack: content -> typografie -> layout -> verf. Het invoeren van (echte) content, het bepalen van de typografie en het opzetten van de verschillende layouts en grids, dit zijn allemaal zaken waarbij een slimme tool enorm handig zou zijn. Voor print bestaan deze tools al lang, het zijn DTP programma’s als InDesign en Quark. Voor het web bestaan dit soort tools vreemd genoeg niet.

Alle tools die we nu gebruiken stimuleren je juist om andersom te denken. Bij Photoshop ligt de nadruk op effecten en kleur, in een canvas van een vast formaat. Het is zelfs helemaal niet geschikt voor typografie. Natuurlijk is het belangrijk dat een site er prachtig uitziet. Maar ik weet zeker dat alle sites er nóg mooier uit gaan zien als de content goed is, als de typografie netjes is en de grids logisch zijn. Als iedereen op die manier sites gaat ontwerpen dan stop ik met zeiken, dat beloof ik.

(This column was published in the Dutch, paper version of Web Designer Magazine. It’s in Dutch). In de creatieve sector zijn we geneigd om zelf naar originele oplossingen te zoeken. Het liefst maken we iets unieks, iets wat we nog nooit gezien hebben; we worden graag origineel gevonden. Grote onzin vind ik dat. De reden dat je iets nog nooit hebt gezien is meestal dat iemand anders er al achter is gekomen dat het niet lekker werkt. Als je als designer een creatieve manier van navigeren bedenkt dan is de kans groot dat een collega je direct kan vertellen dat dat niet lekker werkt. Op het web en in magazines verschijnen allemaal fantastische verhalen, over prachtige originele projecten die een enorm succes waren. Het zou misschien handiger zijn als we eens lazen over de fiasco’s. Als er eens openhartig gepubliceerd werd over alle mislukte, maar o zo originele websites. Waarschijnlijk is daar een veelvoud aan magazines mee te vullen.

Die publicaties zijn er niet. We zijn dus afhankelijk van ervaring om de onzinnige ideeën te scheiden van de nuttige. Op onze eigen ervaring kunnen we niet vertrouwen. Het is dus aan te raden om ideeën snel en vaak te toetsen bij collega’s of andere experts. Je kan daarvoor natuurlijk gebruik maken van diensten als Dribbble, maar volgens mij is het interessanter om te rade te gaan bij collega’s van buiten je vakgebied. De interessantste inzichten krijg je daar.

Een vriend van mij kreeg ooit de opdracht om een ziekenhuis telefonisch bereikbaar te maken. Mensen konden het ziekenhuis wel bellen maar zodra ze werden doorverbonden werd er vaak niet opgenomen. De toestand was dramatisch. Mijn vriend moest er voor zorgen dat iedereen die belde binnen korte tijd goed te woord gestaan zou worden. Het is hem uiteindelijk gelukt. Niet door zelf te gaan bedenken hoe zo iets moet werken maar door met bepaalde specialisten te gaan praten. Met netwerkspecialisten uit het ziekenhuis zelf maar ook met mensen met hele andere specialiteiten. De uiteindelijke oplossing heeft hij voor een groot deel afgekeken van de werkwijze binnen de Toyotafabrieken. Niet precies de plek waar je zo’n oplossing zou verwachten.

Dat is een voorbeeld van ver buiten het web, maar ook dichterbij zijn er verhalen genoeg te vertellen. Frontenders die voor het eerst de code voor een grote, complexe site moeten opzetten zitten vaak met de handen in het haar. Klassieke developers grinniken om zo’n klusje. Dat is wat ze de hele dag doen. In plaats van de oplossing binnen frontend te zoeken heeft het zin om in zo’n geval contact te zoeken met een échte nerd. Voor je het weet zet je je codes op volgens patronen en systemen die al decennia lang blijken te werken. Dat is veel handiger dan via veel vallen en opstaan en heel veel slechte code uiteindelijk zelf een oplossing te bedenken.

In plaats van kennis ophalen als je het nodig hebt kan je natuurlijk ook actief kennis gaan brengen als je ziet dat anderen het nodig hebben. Dat kan wat lastig zijn, niemand zit te wachten op een wijsneus, maar soms moet het. We zien allemaal dat visual designers worstelen met het feit dat het web geen vast formaat heeft. We kunnen aan de zijlijn toekijken hoe ze al vallend en opstaand op zoek gaan naar oplossingen. We kunnen ook gewoon de helpende hand aanbieden. Door te tonen wat er allemaal mogelijk is met fluid, responsive layouts, bijvoorbeeld. Of door pattern libraries aan te leggen. Het zorgt er niet alleen voor dat onze kennis bij de juiste mensen uitkomt, het zorgt ook voor een dialoog: de kennis van de designers komt ook weer terug bij de nerds. Bovendien kunnen we dan eindelijk eens écht goede websites gaan maken.

Een mooi voorbeeld van een kruisbestuiving tussen grafische ontwerpers en frontend developers zijn grids. Grids zijn belangrijke basiselementen van een goed grafisch ontwerp. Er zijn hele boeken met theorieën en wetmatigheden over grids geschreven. Dit is een onderwerp waar dus al heel veel over bekend is. Frontenders hebben veel aan deze kennis, maar dit is echt iets waarover we te rade moeten gaan bij goede grafische ontwerpers. Het probleem met kennis over grids is alleen dat die kennis is gebaseerd op papier, op drukwerk. En dat vertaalt zich, zoals we weten, niet vanzelf naar het web. Dat is waar goede CSS-kennis weer van pas komt. Frontenders kunnen vaste grids vertalen naar fluid, of zelfs responsive grids en daar kunnen designers weer van leren. Ik ben hier laatst met een collega mee aan de slag geweest. Niet alleen is onze kennis over elkaars vakgebied enorm toegenomen, we hebben ook nog eens iets moois gemaakt.

Test je ideeën dus vaak en snel. Vraag aan collega’s wat zij er van vinden. Maar stap vooral ook eens buiten je vakgebied en zoek je oplossing ergens anders. Grote kans dat eenzelfde soort probleem al eens is opgelost. En mocht je tóch eens een unieke oplossing verzinnen, en blijkt die niet te werken, schrijf er dan over zodat wij niet ook dezelfde fout hoeven te maken.

(This column was published in the Dutch, paper version of Web Designer Magazine. It’s in Dutch. There’s an English translation available). De eeuwige discussie: welke browsers moeten we ondersteunen? Moet de site er exact hetzelfde uitzien in IE7 als in de laatste versie van Chrome? Klanten én ontwerpers hebben nog altijd moeite met deze vragen. Websites moeten er, net als drukwerk, overal hetzelfde uitzien en zich altijd hetzelfde gedragen. Adobe, een bedrijf dat pas sinds kort het web een beetje begint te begrijpen, heeft ooit zelfs een tool ontwikkeld waarbij je de website in verschillende browsers over elkaar heen kon leggen om zo pixelverschillen op te sporen. Zo ontzettend zonde van de tijd.

Langzaamaan begint men in te zien dat pixelperfectie altijd een mythe is geweest. Alleen al de manier waarop besturingssystemen en browsers letters weergeven zorgt voor duidelijke verschillen. De discussie over ondersteuning wordt steeds makkelijker te voeren maar ik merk tot mijn verbazing en ergernis dat zowel klanten als ontwerpers er soms nog moeite mee hebben. Hoe vaak heb ik wel niet een ontevreden klant aan de telefoon gehad omdat de letters er in zijn browser niet zo mooi uitzagen als in het gelikte Photoshop-ontwerp dat hij aan de muur had hangen.

Ondersteuning suggereert uniformiteit

Waarom het ondersteunen van oude browsers oplichterij is? In principe vind ik dat alle content en alle basisfunctionaliteit van een website voor iedereen toegankelijk moet zijn. Dat is nu juist precies datgene waarom ik het web zo fantastisch vind.

Maar de manier waarop die content wordt getoond, of de manier waarop een bepaalde functie wordt uitgevoerd, dat mag wat mij betreft verschillen per browser. Mag zelfs heel erg verschillen. Sterker nog, dat moet zelfs verschillen. Wat die verschillen precies zijn hangt van een aantal dingen af. Het hangt bijvoorbeeld van specifieke eigenschappen van browsers en apparaten. Het hangt ook van individuele instellingen van onze bezoekers af. Je kan er gerust vanuit gaan dat geen enkele bezoeker jouw ontwerp precies zo ziet zoals jij hem ziet op je state-of-the-art, dagelijks gekalibreerde monitor.

Weg met uniformiteit

Als ik zeg dat oude browsers ondersteunen oplichting is, bedoel ik dat het veel te veel geld kost en veel te weinig oplevert. Een website er exact hetzelfde uit laten zien in IE6 kost al gauw 100% extra frontend-ontwikkeltijd. IE7? 50%. IE8? Nog eens 50%. Dat is echt heel erg veel geld; je moet hele goede argumenten hebben om dat te kunnen verantwoorden. En die argumenten zijn er niet meer. IE6 is nauwelijks meer waar te nemen in Nederlandse statistieken en IE7 en IE8 zijn in zeer hoog tempo aan het verdwijnen. Zelfs Google stopt nu met het ondersteunen van IE8! Het is onze taak om onze klanten hier goed over in te lichten. Als we dat niet doen dan lichten we ze op. En als ze tóch dat geld over hebben voor die antieke browsers leg ze dan gewoon uit dat je dat geld veel beter kunt besteden om de site nóg beter te optimaliseren voor de toekomst. Door hem bijvoorbeeld te optimaliseren voor dikke vingers. Of game consoles. Of apparaten met GPS.

Nadeel

De consequentie van het streven naar uniformiteit op het web is dat de slechtste browser bepaalt wat de nieuwste browser te zien krijgt. Fantastische nieuwe technieken zoals GeoLocation, Canvas en SVG kunnen we in een uniforme situatie niet gebruiken omdat het niet overal kan werken. Streven naar uniformiteit op het web zorgt er dus voor dat mensen met geavanceerde apparaten niet de ultieme ervaring krijgen. Het houdt innovatie en verbetering tegen.

Maar wat dan wel?

Ik ben er een voorstander van om een minimale basis-styling aan te bieden aan mensen met IE6, IE7 en IE8. Goed leesbare tekst, eenvoudig opgemaakt in één enkele kolom, eventueel met een informatieve waarschuwing over de verouderde browser. Zo’n layout is ook uitermate geschikt voor minder krachtige mobieltjes. Layout en wat rijkere vormgeving – zoals kleurverlopen, schaduwen, skewing en ronde hoekjes – worden alleen aangeboden aan browsers die CSS3 ondersteunen. Het is voor niemand echt nuttig om grafische elementen na te gaan bouwen met plaatjes. De site wordt er echt trager van, het is lastiger te onderhouden en duurder om te maken.

De paradox van ondersteuning

Een van de belangrijkste redenen dat we oude browsers nog steeds moeten ondersteunen is het feit dat we oude browsers ondersteunen. Mensen met een oude browser hebben niet door dat het web veranderd is, dat het allemaal veel beter kan doordat wij er voor zorgen dat het niet kapot is. Laten we daar mee ophouden.

(This column was published in the Dutch, paper version of Web Designer Magazine. It’s in Dutch). Het web is van pak hem beet 2003 tot 2010 niet wezenlijk veranderd. Als we een website gingen bouwen in die periode dan hadden we altijd een paar vaststaande uitgangspunten: de website moest er in elke browser precies hetzelfde uitzien, hij moest 1024 pixels breed zijn, hij moest perfect werken in IE6. Bovenaan de pagina stond de header met een logo en een navigatie, links stond eventueel nog een navigatie, rechts hadden we ruimte voor wat widgets, onderaan de pagina stond er een footer, en, oh ja, daartussen stopten we de inhoud. Het web is veranderd. De uitgangspunten die hierboven staan zijn stuk voor stuk verouderd. De meeste browsers kunnen tegenwoordig fantastische dingen en we hebben allemaal een kek minicomputertje in onze broekzak of handtas. Dit ecosysteem van nieuwe apparaten en browsers vraagt om een hele andere aanpak. Hier onder beschrijf ik een paar New Defaults, nieuwe uitgangspunten voor het huidige web.

Touch First

We gingen er altijd van uit dat iedereen die onze website bezocht een muis gebruikte. Veel van onze interacties waren hier dan ook afhankelijk van: mouseovers werden geregeld gebruikt om content te tonen, zoals bijvoorbeeld een subnavigatie of hulpbalonnetjes. Meer en meer mensen gebruiken echter een touch device en mouseovers werken niet op touch devices. Voor interacties is het dus beter en handiger om uit te gaan van touch in plaats van de muis. Als het werkt met een dikke vinger dan werkt het ook met een cursor, andersom geldt dat niet altijd.

Content First

De content, de inhoud van de site, het spul wat onze bezoekers willen zien, dat stopten we altijd ergens tussen de widgets, de headers en de footers, nadat we die al hadden vormgegeven. Onze sites werden eerst ontworpen, eerst de layout, de kleuren en de tierlantijntjes, en daarna werd er pas gekeken wat er nu eigenlijk in kwam te staan. Tegenwoordig pakken we het iets slimmer aan en kijken we eerst naar de content. We beginnen met het vormgeven van de inhoud, in plaats van de inhoud in een fantastische vormgeving te proppen. Design is het vormgeven van content met de restricties en mogelijkheden die er zijn. Als je de inhoud in een vormgeving stopt, dan ben je een plaatjesmaker, geen designer.

CLI First

Niet alle websites bestaan alleen maar uit content om te consumeren, op veel websites kun je ook iets doen. Een tijd geleden beschreef Luke Wroblewski hoe hij BagChek had opgezet. Hij had er eerst voor gezorgd dat de API goed werkte, dat alle basisfunctionaliteit het deed vanaf de commandline. Daarna begonnen ze pas, laag voor laag, de verschillende grafische interfaces toe te voegen, altijd bovenop deze API. Als er een nieuw apparaat op de markt komt wat een wezenlijk andere interface nodig heeft (TV bijvoorbeeld) dan is dit redelijk eenvoudig te realiseren.

Mobile First

Toen we de eerste responsive sites gingen bouwen, een paar jaar geleden, toen begonnen we met een al dan niet bestaande desktop-site en vormden die om naar iets wat ook lekker werkt op kleinere schermen. We zijn er achter gekomen dat dit wat onhandig is. Het is makkelijker om een site te bedenken en te ontwerpen voor een klein scherm en dit vervolgens op te rekken en aan te passen voor hogere resoluties. Als het op een klein scherm past dan past het ook op een groot scherm. Bovendien dwingt het je om nóg beter na te denken over wat er echt belangrijk is: als het niet op dat kleine schermpje past, is het dan echt wel noodzakelijk? Je ziet inmiddels allemaal websites verschijnen zonder nutteloze, afleidende widgets en met lekker grote, leesbare letters. Een hele fijne ontwikkeling wat mij betreft.

Everything First

De New Defaults die ik hierboven beschrijf zijn nadrukkelijk uitgangspunten, er staat niet Mobile Only, er staat Mobile First. Natuurlijk moet je rekening houden met mensen die een muis gebruiken, of een toetsenbord. En natuurlijk moet een site er prachtig uit zien, het gaat wellicht om meer dan alleen de content, vormgeving is enorm belangrijk. En jazeker, soms zijn widgets een beter idee dan witruimte, en een site moet het absoluut ook doen op de klassieke desktop-computer. Aan al deze dingen moet je óók denken tijdens het ontwerpen en bouwen. Maar niet als eerst.

(This column was published in the Dutch, paper version of Web Designer Magazine. It’s in Dutch). Een van de manieren om beter te worden in wat je ambieert is door veel te lezen. Maar lezen is veranderd. Vroeger lazen we van papier, tegenwoordig hebben we veel betere alternatieven.

In de jaren negentig kocht ik boeken over kunst, ik had de ambitie om kunstenaar te zijn. Ik las over kunstenaars die ik bewonderde, over kunstenaars die ik verafschuwde, ik las over kunststromingen en leerde op die manier het een en ander. Ik noteerde opmerkingen in de kantlijn van deze boeken; voor later, dacht ik er altijd bij. Dit is dezelfde manier waarop mensen 400 jaar lang kennis hebben opgedaan. De meeste mensen zullen, net als ik, nooit meer teruggekeken hebben naar de notities in hun boeken.

In de jaren nul werd ik een serieus webdeveloper. Ik heb geen enkel boek opengeslagen om de kennis te vergaren die ik nu heb; ik heb alles wat ik weet geleerd van websites, van mensen die de moeite namen om de fantastische dingen die ze hadden ontdekt te delen, en van mensen die daar weer op reageerden. In de jaren dat ik me verdiepte in webdesign en webdevelopment heb ik veel meer geleerd dan in de jaren dat ik boeken verslond over kunst. Kennis vergaren gaat zo veel makkelijker en sneller als je er eenvoudig naar kunt *wijzen*. Dit is de kracht van het web, dit is wat het web uniek maakt en dit is de reden dat ik ons vak het mooiste vak vind dat er is.

Zoals jullie misschien wel weten publiceer ik dagelijks soms een lijst met links naar interessante artikelen op het gebied van webdesign en webdevelopment op Smashing Magazine de Daily Nerd, altijd met een kort commentaar erbij om uit te leggen waarom het belangwekkend is. Ik doe dit voor mezelf om op de hoogte te blijven van de ontwikkelingen in ons vakgebied, maar ik doe het ook omdat ik graag wil dat het web nóg beter wordt. Omdat ik zeker weet dat jullie, de meer getalenteerde webmensen, er nog toffere dingen mee kunnen gaan doen dan ik kan. En ja, dat is belangrijk, als mijn concurrenten beter worden moet ik ook beter mijn best doen. Onze gebruikers hebben daar weer profijt van.

De laatste tijd lees ik wel weer eens een boek over webdevelopment en webdesign. Geen papieren boeken maar digitale boeken. Digitale boeken hebben hetzelfde probleem als papieren boeken: je kan er niet direct naar linken en dus kan ik de prachtige kennis die ik opdoe niet direct met jullie delen. Maar er zijn tegenwoordig manieren om dat wél te doen. Met Readmill bijvoorbeeld, een epub-reader op de iPad, kan je stukken tekst highlighten, je kan er een commetaartje bij schrijven en dit kan je vervolgens delen via Tumblr en Twitter en daar kan je weer naar linken. Je kan mensen ook volgen op Readmill, je ziet hun highlights en commentaren als je een boek leest. Laatst kreeg ik een bericht dat “Somebody liked your highlight”! Boeken worden hierdoor ineens weer een stuk interessanter.

Ik heb niet zo veel meer met papier, zoals je inmiddels wel doorhebt. Ik heb dan ook flink gegrinnikt toen ik de mogelijkheid kreeg om te gaan schrijven voor een Webdesigner Magazine, een blad op papier. Dat is het format dat misschien wel het minst linkbaar is van alles. Veel mensen zien het als het summum, gepubliceerd zijn in een papieren magazine. Ik voel me ook enorm vereerd om hier te kunnen schrijven, maar ik vind het ook erg onhandig omdat ik er zo moeilijk naar kan linken. Artikelen in een magazine staan meestal niet in de Google index, en ze staan niet in mijn persoonlijke archief. Ik kan ze dus nooit meer terugvinden. Wat ik er wel erg tof aan vind is dat ik mijn meningen met jullie kan delen en er op die manier misschien aan kan bijdragen dat het web beter wordt. En wie weet, misschien draag ik er ook wel aan bij dat magazines linkbaarder worden!

1. Craig Mod heeft hier een prachtige reeks artikelen over geschreven

Yesterday, Bob asked if there’s any research been done about how people hold their tablets. Always in portrait, or always on landscape mode? The only scientific research I know of is a Twitter poll I did a few years ago. Back then, ten people answered and there was no consensus. I decided to repeat the poll – I have more followers now than I had two years ago. More followers is more science.

I did a similar poll about how people hold their telephones, and the outcome was not shocking at all. Everybody holds their telephone in portrait mode, unless they do something special, like watching a movie, or typing. Landscape mode is a clear exception here.

The results

On tablets the results are very much divided. 22 people replied to my tweet. Four people clearly answered that it depends on what they’re doing, without showing a clear preference. I divided the rest of the answers into four possible results: always portrait, always landscape, preferable portrait, preferably landscape.

I could have stopped with the it depends answer. Five people always use their tablet in portrait mode and four people always use it in landscape mode. Four people prefer portrait, while five people prefer landscape. I think we can conclude that 50% of the tablet users will mostly use their device in portrait mode, while 50% will mostly use it in landscape mode. It looks like it’s a good idea to not make any assumptions about screen orientation when designing an app or a website.

Further thinking

There are many interesting questions that pop to mind after this poll. For instance, might the way people hold their device be coupled to some kind of personality. For instance, do some types of people prefer landscape mode because the have more overview, and do other types prefer portrait because of more focus? I’m no UX person, and I’ve never been interested in psychology, other people might know the answer to this assumption.

It might also be a cultural thing. All the respondents were Dutch or Belgian. People could also be lying unconsciously. Their preference might not be the same as their actual behaviour. It would be interesting to compare these results with actual website statistics.

Further reading

After writing this article, that same Bob pointed me in the direction of this much more interesting article on the same subject (with roughly the same results!). If you like thoughts about tablet orientation, you should definitely read it.

Today I tried to provoke my twitter time line by stating that the discipline of front-end development should cease to exist. Part of it should become part of Visual Web Design, and part of it should become part of the discipline Web Development. Provoking worked, discussing the provocation is harder. I’ll try to explain what I mean.

I am asked to think about the future of the specialty front-end development as it is taught on the University of Applied Science in Amsterdam. One of the ideas I’m playing with is to make front-end development a part of two other courses that are taught there: Visual Design and Web Developer.

Visual Design

The reason behind this thinking is as follows: Visual web designers don’t really understand the web technically, they don’t understand that everything will look different everywhere. This must be part of their understanding. When they understand this, their designs will be better. I strongly believe this is the basic idea behind web design. This makes web design different from all other design specialties. Of course you could force designers to learn how to write HTML and CSS, but I don’t think that will work, designers want to see what they’re making. Instead we should make tools that force/help them in working with the web (instead of ignoring it). And until these tools exist we should teach them how the web works.

But it works both ways: many front-end developers right now don’t understand anything about design. They should.

Web Development

There used to be a strict division between people who write code for the server and people who write code for the browser. But this division is not so clear anymore. Which is a very good thing. But this does have some consequences: I see so called back-end developers bringing their best practices to the browser. The problem here is comparable with the problem we have with designers: the browser is completely different from the server and many developers find it very hard to accept that. Not all best practices apply to the browser. I firmly believe that all web developers must understand how browsers work, that developing for the browser is fundamentally different from developing for a server.

But it works both ways: many front-end developers right now can and should learn a lot from classic developers.

Conclusion

So I’m not saying that Front-end development should cease to exist as a trade. It is a separate profession in many ways. It needs its own specialists for sure. But I do believe that in applied universities front-end development, or browser behaviour, should be taught as a part of other, broader disciplines.

Now, I’m really looking forward to reading your opinions on this matter.

The web has changed the last few years but the way we design for it hasn’t. It needs to though. In this small talk I did for the Fronteers 2012 Jam Session I show some new defaults we should use when designing for the web. This is a small try out for a longer talk I will be giving at UX Cambridge. There’s definitely a lot of work to be done, there’s plenty of room for improvement here.

I would appreciate any feedback.

All these different resolutions for all these different devices. It can be pretty confusing and intimidating when you try to understand how they work. Is a pixel a pixel or isn’t it? This can be mindblowingly complex. But here’s what you should basically know:

If you set the meta viewport to width=device-width,initial-scale=1 all devices translate the units you use in your CSS to usable formats on the screen.

That is, if your CSS units are sensible in the first place. This means that a square of 40×40 pixels can be handled with fat fingers on every device. And this means that a 16px (or 1em) font-size is perfectly readable.

The most important part you need to know about the viewport though, is that you should only use it if you optimize your site for all resolutions. In other words: you should only use it if the responsive result is better than the static one.

A tool to design websites should be based on the web stack, which actually closely resembles the classic Graphic Design stack. Instead of the arbitrary layers we see in tools like Photoshop, we would need (at least four) base layers that need to be touched by the designer. The content layer, the typography layer, the layout layer and finally the paint layer.

The Content Layer

The content layer could be filled with real content. Or the tool could provide some common content types to work with. Articles with common patterns, forms, widgets, things like that.

The Typography layer

Typography is the base of a design. Typography defines the rhythm and it can help you in finding clever breakpoints. So force the designers to first define the typography before they move on. Typography is also something almost all your users will see: even on small screens, with a one column layout, the typography is just there. It should be really good.

The Layout

Layout on the web is different. It’s fluid. One grid is probably not enough for a website. This tool should make it easy to work with different grids. It should show the content while working on your layouts and grids. Grids can be defined by the typography: things like measure and white-space can be based on the base font size. It should be possible to link the grid layer to the typography layer. When you decide to change a font, the grids should adapt.

The Paint

Right now the web design tools we have stimulate you to start painting as soon as possible. Paint should really be the last thing you add to your website. I’m not sure how to enforce this, but maybe the decorative tools only work when the content, the typography and the layout layers are done.

Of course a web design tool would need much, much more. But I think these basic principles of the web, the web stack, should be the core of all web designers tools. Yes, this does look a bit like InDesign. Just replace the paper sized fixed document size with the fluid nature of web and you’re done. You are more than welcome to build this tool, I’d love to beta test it and help you out with ideas. I would appreciate it if someone else than Adobe built it, they need some serious competition.

I think we could use a new HTTP Status Header which explains that the content you are looking for will be published but is not there yet. You could use 404 for this, but you could use 404 for just about everything. It’s vague.

Use cases: Marco Arment created a magazine which is immediately accessible for people with an iOs device. These articles will probably be published on the web in a few weeks so we can actually link to them. A special header would be good in this case. Right now every article does have a URL, but there’s just some placeholder text there. A special header would be useful for tools like Pinpoard.

Another example: I create a bi-weekly video podcast with Peet Sneekes, a colleague of mine. The URL structure is pretty easy: domain/nnn, where nnn stands for episode number. Now I wouldn’t want to send a Will Be Published header if someone is looking for episode number 999, I’m pretty sure it will not be published. But I am sure that episode number 020 will be published in the next coming days. We actually link to it already. Right now you will get a 404, but I think another header would be more appropriate here.