Chris Smissaert (Min BZK) licht toe: “Het doel van de Webrichtlijnen bij het opstellen was om alle overheidsinformatie goed toegankelijk te maken. Niet alleen voor kwetsbare groepen, maar ook voor alle verschillende computers, telefoons en dergelijke, én voor hergebruik. De gebruiker van overheidsinformatie kan eisen stellen aan het gemak, de snelheid, de flexibiliteit en de gemeenschappelijkheid ervan.” En door Web 2.0 te omarmen, wil BZK innovatie (e-participatie en open data) stimuleren.

De eerste resultaten hiervan zijn een vijftal widgets, die Tam Tam met Alper Çugun (Aardverschuiving) voor BZK ontwikkeld heeft, en de prijsvraag “Dat zou handig zijn”. Deze prijsvraag luidt: “Welke slimme toepassingen van de overheid zouden handig zijn voor de samenleving?” Goed om anderen deze vraag te stellen, want – zo stelt Alper: “Het is voor overheidsorganisaties onmogelijk om alle gebruik van data te voorzien en in te voorzien.” Door open data en API’s beschikbaar te stellen, stel je iedereen in de gelegenheid ermee aan de slag te gaan.

Widgets

De vijf gemaakte widgets waren onder meer bedoeld om (onder meer de overheid zelf) te laten zien dat open overheidsinformatie op nieuwe manieren gebruikt en hergebruikt kan worden. Dit zijn ze:

• Zoekdienst Bekendmakingen
  Kijk snel en eenvoudig wat er in de buurt aan vergunningen en andere bekendmakingen zijn gepubliceerd.
• Rijksoverheidvideo’s
  Video’s zoals gepubliceerd door de Rijksoverheid op Regering.nl
• Waarschuwingen van de VWA
  De meest recente waarschuwingen van de Voedsel en Warenauthoriteit
• Agenda van Werken bij de Overheid
  Agenda widget met daarin de aankomende evenementen van Werken bij de Overheid
• Vacatures van Werken bij de Overheid
  De vacatures van Werken bij de Overheid

Moeten widgets voldoen aan de Webrichtlijnen? Op dit moment voldoen ze in ieder geval nog niet, omdat ze op websites in een iframe geladen worden. De nieuwe versie van de Webrichtlijnen zou hiervoor dus iframes moeten toestaan. Verder wordt er gediscussieerd over de toegankelijkheid van de widget. Moet de informatie in de widget zelf per se toegankelijk zijn? De data komt immers van een website, waar de informatie als het goed is al goed toegankelijk is. Is het niet voldoende om gebruikers voor wie de widget-presentatie (door bv. JavaScript of visuele weergave) niet optimaal werkt, door te verwijzen naar een website waar de broninformatie staat? Is een widget niet ‘extra’? De meningen zijn hierover verdeeld.

De geest van de Webrichtlijnen

Alper Çugun geeft een prikkelende presentatie, getiteld De geest van de Webrichtlijnen.

Voor het bouwen van de 5 widgets heeft hij gekozen voor het OpenSocial platform, omdat:

• OpenSocial het grootste open platform is (iGoogle),
• Het de beste syndicatiemogelijkheden biedt,
• Er nu ook een hele goede mobiele versie van iGoogle is.

Er zitten echter ook wat nadelen aan:

• De eerder genoemde iframes,
• Geen page loads: alles wordt dynamisch opgebouwd met scripts. “Progressive enhancement heeft dus eigenlijk geen zin.”
• Geen DOCTYPE’s mogelijk in widgets, waarschijnlijk vanwege het inline gebruik van widgets. Gevolg: in Internet Explorer 6 zijn de widgets ‘stuk’.

Ondanks de nadelen vindt Alper OpenSocial beter dan de andere platformen, zoals Netvibes.

Over de Webrichtlijnen heeft Alper een prikkelende mening. Alper vindt dat veel mensen te rigide met de Webrichtlijnen omgaan. Hij is zelf een voorstander van pragmatiek en gezond verstand. “De Webrichtlijnen zijn goed om naar een beter Web te komen, maar er zijn betere dingen te doen dan je op alle micro-optimalisaties te richten, zoals goed ontwerp en heldere teksten. Maar is dat minder nauwkeurig toetsbaar”. Hij pleit voor een minder rigide naleving van alle 125 Webrichtlijnen en citeert Douglas Bader (RAF-piloot tijdens WOII): “Rules are for the guidance of wise men and the obedience of fools”. 

Ikzelf onderschrijf Alpers boodschap van harte. Ik denk dat bijvoorbeeld begrijpelijke taal en goede (natuurlijk wel geteste ;-)) usability meer invloed heeft op de kwaliteit van een website dan het netjes coderen van alle afkortingen en korte taalwisselingen in de content of het ombouwen van een zoekfunctie om daar ook vriendelijke url’s te krijgen.

Belangrijkste issues

Bart Hilhorst (Tappan) inventariseert onder het publiek de belangrijkste issues van Web 2.0 in relatie tot de Webrichtlijnen en kijkt samen met de aanwezigen of er snelle antwoorden voor zijn.

N.B. Ik ben geen echte techneut, dus het kan zijn dat ik sommige punten niet helemaal juist weergeef. Ik hoor het graag als dit het geval is.

Routebeschrijving uitbreiden met Google Maps (zodat gebruiker eigen vertrekpunt kan opgeven).
Helaas is de Google Maps code niet Webrichtlijnen-compliant.Google Maps embedden gebeurt (bijna?) altijd met een iframe, dat is dus nu nog een probleem. Misschien dat je hier omheen kunt werken als je de API gebruikt. Roel van Houten (Viziris): “De ‘basis routebeschrijving’ vanaf bepaalde nabije punten naar de organisatie is de verantwoordelijkheid van de organisatie. Het aanbieden van een routebeschrijving van je eigen adres is extra, dus hoeft in principe niet toegankelijk te zijn. Je kunt als organisatie hiervoor ook linken naar een online reisplanner.” Als dit zo werkt, kan de Google Maps toevoeging dan genegeerd worden bij toetsing of blijft de suboptimale code een punt waarop afgekeurd kan worden?

Kunst in een met Flash gecreëerde sfeer op een site presenteren
Het standaard uitgangspunt is: “In principe moet een gehandicapte kunnen doen wat anderen ook kunnen” (Roel van Houten). Maar hoe beschrijf je bijvoorbeeld muziek aan een dove? Of een abstract schilderij aan een blinde? Ik kan me goed voorstellen dat voor bepaalde belevingen geen gelijkwaardig tekstequivalent te maken valt. Moet je het dan toch proberen, omdat het nu eenmaal een toetsingcriterium is? Goede vraag…

Sommige nieuwe technologieën (HTML5, ARIA) en bepaalde API’s  niet bruikbaar volgens Webrichtlijnen
Bepaalde technieken als Canvas en SVG embedded conflicteren met de Webrichtlijnen. De volgende versie van de Webrichtlijnen, waarin WCAG 2 wordt verwerkt, biedt wel ruimte aan nieuwe technologieën.

User generated content (bv. video)
Voor een organisatie kan het een enorme klus worden om door bezoekers geuploade videoclips te ondertitelen en te voorzien van een audiobeschrijving. De verantwoordelijk neerleggen bij de bezoeker zelf is ook geen optie: de drempel wordt dan voor veel mensen te hoog om video’s in te zenden. Is het uit de scope te halen (conform Caesura richtlijnen) als zijnde geen ‘key scenario’? Of kun je je erop beroepen dat je geen verantwoordelijkheid kunt nemen voor content door anderen gecreëerd? Volgens Koen Willems zou dit laatste niet opgaan.

Webstats tellers in de broncode
De meeste webstatistiekpakketten maken geen gebruik van ECMA-script voor de code snippets die je in de broncode van je pagina’s moet plaatsen om gedetailleerdere webstatistieken te krijgen. En dat levert een conflict op met de Webrichtlijnen. Scripts van Google Analytics kun je overigens wel zelf herschrijven.

Webrichtlijnen-conforme chatfuncties
Bestaat er chatsoftware voor op websites die voldoen aan de Webrichtlijnen? In de zaal is er niemand met een concrete oplossing.

Dynamisch wisselende content (bv. live nieuwste Twitter-berichten)
Je kunt proberen ARIA hiervoor te gebruiken. Je kunt een verversknop aanbieden bij geen JavaScript. In bepaalde gevallen kan het misschien zelfs gewoon buiten de scope getrokken worden.

Inlezen externe content
Met XML / RSS moet dit geen probleem opleveren.

Plugins met inline styles/script
Veel populaire open source platformen zoals WordPress ondersteunen plugins, die in principe iedereen kan schrijven en gebruiken. Veel plugins bevatten inline styles/scripts omdat ze rijke functionaliteiten bieden en moeten kunnen functioneren zonder dat de gebruiker dingen hoeft aan te passen aan het platform. Misschien kun je “zelf een betere maken”, zoals sommigen tijdens de barcamp suggereren, maar of dat een werkbare oplossing is?

Rich interfaces: drag/drop, rechtermuistoets
In bepaalde rich internet applications (RIA) wordt gebruik gemaakt van bijzondere handelingen zoals drag & drop en contextmenu’s (keuzemenu’s die met de rechtermuistoets worden opgeroepen). Door gelaagd te bouwen zouden deze functies ook toegankelijk en conform Webrichtlijnen aangeboden moeten kunnen worden.

Conclusies?

Op zich lijkt een aantal zorgen met betrekking tot Web 2.0 en Webrichtlijnen inderdaad ongegrond. Met goed gelaagd bouwen kom je vaak al een heel eind, maar er zijn toch een aantal mogelijke hindernissen met de huidige Webrichtlijnen. Concrete technische hindernissen zijn bv. iframes voor widgets, maar wat minder concreet zijn ‘Web 2.0 features’ op websites waarvan het misschien lastig te bepalen is of die deel uitmaken van de key scenario’s van de website (en dus moeten voldoen) of ‘extra’ zijn, waardoor ze mogelijk uitgescoped mogen worden en dus geen belemmering meer vormen. Ook bij user generated content blijft het lastig om te garanderen dat je blijvend kunt voldoen aan de Webrichtlijnen. Gebruikers zullen niet de moeite nemen hun content zorgvuldig toegankelijk te maken en voor de meeste organisaties zal het onbegonnen werk zijn om dit achteraf te doen voor alle gebruikerscontent. Kennis over Web 2.0 en Webrichtlijnen, en mogelijk uitgebreidere antwoorden op de vragen tijdens Bart Hilhorsts sessie kunnen bijgedragen worden op www.overheid20.nl/werkruimte/45/LabWeb2.0.

“…En daarom hebben we besloten om je een 10 te geven!”

De timing van mijn afstudeeronderzoek was perfect: de Webrichtlijnen waren de afgelopen maanden een hot topic waar uitgebreid over werd geblogd, getwitterd en geschreven in kranten en bladen. Een ideaal moment dus om de Webrichtlijnen te bestuderen en mensen die met de Webrichtlijnen bezig zijn (of juist niet) bij de overheid en in het bedrijfsleven te vragen naar hun meningen en ervaringen. Vandaag het slotstuk: mijn aanbevelingen, mijn ontwerp voor Webrichtlijnen.nl en voor de echte liefhebben mijn complete scriptie.

Onderzoek

Om een antwoord te vinden op mijn onderzoeksvraag heb ik naast een grondige bestudering van de Webrichtlijnen zelf een groot doelgroeponderzoek gehouden. Ik heb 27 mensen gesproken die werken bij overheidsorganisaties, commerciële bedrijven en internetbureaus in de functie van opdrachtgever, manager, ontwerper, ontwikkelaar of redacteur. In dit onderzoek wilde ik achterhalen of mensen bekend zijn met de Webrichtlijnen en wat ze ervan vinden, maar ook wat zij nou precies belangrijk vinden voor een website, en voor welke argumenten zij in hun specifieke rol gevoelig zijn.  De interviews leverden een gevarieerd beeld op: bij de overheid was het kwaliteitsmodel bekender dan in het bedrijfsleven, waar veel mensen er zelfs nog nooit van hadden gehoord. Ook verwarren veel mensen de Webrichtlijnen met Stichting Waarmerk Drempelvrij.nl. Ontwikkelaars waren over het algemeen erg positief over de richtlijnen, terwijl ontwerpers niet enthousiast werden over richtlijnen van de ’saaie’ en ‘trage’ overheid.

Aanbevelingen

Er is meer nodig dan een flitsend logootje of een rake slogan om de Webrichtlijnen beter verkoopbaar en meer bruikbaar te maken. Uit mijn onderzoek blijkt dat het probleem dieper zit. Mijn aanbevelingen hebben dan ook niet alleen betrekking op de communicatie van de richtlijnen, maar ook op organisatorische aspecten. Ze vereisen een andere instelling aan de kant van de initiatiefnemers van de Webrichtlijnen.

Focus op de doelen

Één van de grootste problemen van de Webrichtlijnen is het feit dat mensen ze zien als saaie, strenge regels. Waaróm je die regels zou toepassen wordt daarbij soms bijna vergeten.

Mijn eerste aanbeveling is daarom: focus op de doelen, de voordelen. Laat niet die lange lap met richtlijnen zien en vertel niet direct dat je aan alle 125 richtlijnen moet voldoen om door de keuring  te komen, maar vertel dat je site er sneller door wordt, dat je meer mensen bereikt en beter vindbaar bent in zoekmachines.

Stichting Webrichtlijnen: niet alleen de overheid, maar iedereen

Uit mijn doelgroeponderzoek blijkt dat veel mensen de overheid niet ‘vertrouwen’ als afzender van de Webrichtlijnen. Op het terrein van technologie en internet, dat zich razendsnel ontwikkelt en waar innovaties aan de orde van de dag zijn, is de overheid voor veel mensen geen logische keus. Veelgehoord zijn uitspraken als: ‘de overheid loopt niet bepaald voorop op dit gebied, kijk maar naar de blunders met DigID, de ov-chipkaart…’. Om dit wantrouwen tegen te gaan, raad ik aan een Stichting Webrichtlijnen op te richten. Dit moet een stichting worden waarin allerlei organisaties plaatsnemen: De overheid, belangenorganisaties als drempelvrij.nl, maar ook toonaangevende internetbureaus en andere partijen uit het bedrijfsleven. Zo worden de Webrichtlijnen echt ván en vóór iedereen.

Andere indeling Webrichtlijnen

Een volgende aanbeveling is het anders indelen van de Webrichtlijnen. Het doel hiervan is om een kortere, meer overzichtelijke lijst te creëren. Dat kan door de richtlijnen bijvoorbeeld in te delen in meer algemene hoofdprincipes. Een lijst van een stuk of 30 hoofdprincipes is gemakkelijk te scannen, en door de minder technische omschrijvingen van de hoofdprincipes zal het ook voor opdrachtgevers en managers duidelijker worden waar de Webrichtlijnen over gaan.

Andere toetsingsregeling

Op dit moment ben je alleen ‘geslaagd’ voor de Webrichtlijnen als je aan alle 125 richtlijnen voldoet. Voor veel organisaties is dat (op dit moment) onhaalbaar, of onwenselijk. Met name in het bedrijfsleven moeten keuzes gemaakt worden wat betreft budget. Mijn advies is dan ook om de toetsing anders te regelen, bijvoorbeeld door middel van een rapportcijfer. Dus niet meer ‘alles of niets’, maar meerdere niveaus. Met een basisset aan richtlijnen kun je al een 7 scoren. Overheidsorganisaties zullen uiteindelijk voor de 10 willen gaan. Maar als ze dit niet direct halen, dan is het toch veel bemoedigender als ze wel een 8 kunnen halen, in plaats van volledig afgekeurd te worden? Een bezwaar dat sommige mensen tegen dit advies hebben is dat het kan leiden tot een lakse houding bij organisaties: de 7 is dan opeens wel ‘goed genoeg’. Naar mijn idee weegt dit echter niet op tegen de verbetering van de kwaliteit van websites die op zal treden als meer organisaties in ieder geval een deel van de Webrichtlijnen gaan gebruiken. Want al gaan ze dan niet direct voor de 10, nu laten veel organisaties het hele kwaliteitsmodel maar links liggen als blijkt dat ze niet aan alle 125 kunnen voldoen.

Campagne

Bovenstaande aanbevelingen zijn vooral gericht op mensen die vanuit hun functie bezig zijn met de bouw of het beheer van een website. Om het besef dat de Webrichtlijnen waarde hebben echter  door te laten dringen in alle lagen van de maatschappij is het naar mijn idee een goed plan om een landelijke campagne te organiseren die gericht is op ‘het grote publiek’, de eindgebruikers van websites. Deze campagne moet alleen over de voordelen van de richtlijnen gaan voor die eindgebruikers, en dus geen technische taal bevatten. In een ideale situatie worden de Webrichtlijnen net zo bekend als de BOB-campagne of de Thuiswinkelorganisatie. Dan wordt het voor opdrachtgevers en managers bijna vanzelfsprekend om de Webrichtlijnen mee te nemen bij een beslissing, en zullen ook internetbureaus zorgen dat ze aan deze nieuwe klantvraag kunnen voldoen.

Community

Ook in de digitale wereld kan gewerkt worden aan de verkoopbaarheid van de Webrichtlijnen. Een levendige community is hierbij van groot belang. Er zijn zoveel mensen bezig met de Webrichtlijnen. Al die mensen kunnen vanuit hun eigen perspectief vertellen over het kwaliteitsmodel, hoe zij ermee omgaan en wat ze ervan vinden. Op de nieuwe website van de Webrichtlijnen zou ik dan ook een weblog starten waar mensen uit allerlei hoeken over de Webrichtlijnen kunnen schrijven. Denk aan opdrachtgevers die vertellen hoe zij een Webrichtlijnenproject hebben aangepakt, aan ontwikkelaars die tutorials schrijven en redacteuren die tips en tricks met hun collega’s delen. Naast een weblog is een forum ook een goed idee. In mijn doelgroeponderzoek gaven veel mensen aan dat ze behoefte hebben aan meer samenwerking. Ze willen niet telkens het wiel opnieuw uitvinden, of één op één met de Webrichtlijnenhelpdesk bellen. Op een forum kunnen soortgelijke organisaties elkaar vinden, en kunnen zowel de mensen van de helpdesk als andere professionals elkaar helpen met vragen en problemen. Tegelijk kan een weblog of forum een discussieplatform worden: met name ontwikkelaars geven aan dat zij mee zouden willen denken over de verdere ontwikkeling van de Webrichtlijnen.

Nieuwe website Webrichtlijnen

Het laatste deel van mijn onderzoek had specifiek betrekking op de aansluitende afstudeeropdracht: het creëren van (een ontwerp voor) een nieuwe website voor de Webrichtlijnen. Ik onderzocht hiervoor  aan de hand van de User Experience Honeycomb van Peter Morville hoe de gebruikservaring van elk van de doelgroepen geoptimaliseerd kan worden. Aansluitend op dit onderzoek heb ik een ontwerp gemaakt voor de nieuwe website van de Webrichtlijnen.  In dit ontwerp zijn ook mijn aanbevelingen verwerkt. Ook heb ik gekeken naar een verbetering van de online communicatie op het gebied van schrijfstijl en tone of voice.

Conclusie

Kan de verkoopbaarheid en de bruikbaarheid van de Webrichtlijnen vergroot worden? Jazeker! Ik ben ervan overtuigd dat een betere communicatie en een andere benadering van het kwaliteitsmodel ervoor kunnen zorgen dat de Webrichtlijnen bij een groter publiek bekend en geliefd worden.  Dankzij mijn unieke stageplek had ik de mogelijkheid de Webrichtlijnen van alle kanten te bekijken. Ik zag bij Tam Tam dat het zeker mogelijk is om websites af te leveren die aan alle Webrichtlijnen voldoen, maar ook dat veel opdrachtgevers er nog niet klaar voor zijn. Ze weten er niet genoeg van af, of hebben er simpelweg geen interesse in. Bij de overheid zag ik de strijd die veel organisaties leveren om hun website aan alle standaarden te laten voldoen, en de frustratie als dat dan door een paar richtlijnen net niet lukt.

Wat is nu de heilige graal van de Webrichtlijnen? Ik denk dat het ‘samenwerken‘ is. Samenwerken in een Stichting Webrichtlijnen, samenwerking tussen organisaties onderling om verder te komen met de Webrichtlijnen en als initiatiefnemers, webprofessionals en Webrichtlijnenexperts samen nadenken over de toekomst van het kwaliteitsmodel.  Geen eenrichtingsverkeer meer, maar een levendige discussie en een ’samen komen we er wel uit’-mentaliteit.

Tijdens mijn onderzoek kwam ik erachter dat de Webrichtlijnen gevoelig liggen: iedereen heeft er wel een mening over. Maar wat mij het meest opviel was dat al die mensen die met de richtlijnen bezig zijn dat doen vanuit een eerlijk enthousiasme en een betrokkenheid bij het daadwerkelijk beter maken van de gebruikservaring van internetgebruikers. In die 4 maanden afstuderen heb ik veel interessante mensen ontmoet, nuttige feedback ontvangen en veel hulp gekregen. Aan alle mensen die mij hebben geholpen bij mijn onderzoek: dank jullie wel! Het was een inspirerende en een leerzame ervaring.

Eindpresentatie en downloads

Wie meer wil weten over mijn onderzoek kan hier mijn scriptie en eindpresentatie downloaden en mijn prototype bekijken.

• Eindpresentatie “Webrichtlijnen voor iedereen” (PDF, 4MB)
• Scriptie “Webrichtlijnen voor iedereen” (PDF, 17MB)
• Demo nieuw ontwerp Webrichtlijnen.nl
  N.B. Dit is een functionele demo. De code is gegenereerd door Axure en is dus niet W3C-compliant.

Volgens Jakob Nielsen en Hoa Loranger worden gemiddeld de meeste ernstige usability issues veroorzaakt door slechte vindbaarheid, oftewel informatiearchitectuur en navigatie (zie figuur 1). En dit is nog exclusief ‘zoeken’.

Figuur 1: Gewogen (op ernstigheid) usabilityproblemen per categorie (bron: Nielsen & Loranger, 2006)

Als we inzoomen op het aspect ‘navigatie’, blijkt dat gebrek aan intuïtiviteit (inderdaad geen goed Nederlands), zichtbaarheid, context en consistentie van het navigatiesysteem de voornaamste oorzaken zijn dat mensen informatie op een website niet kunnen vinden (zie figuur 2).

Figuur 2: Grootste navigatie-gerelateerde oorzaken voor het niet slagen van gebruikerstaken (bron: Goldfield, 2009)

Zoals gezegd zijn dit de voornaamste oorzaken. Volgens Goldfield voldoet een effectieve navigatie minimaal aan deze 10 eigenschappen:

• zichtbaar
• intuïtief
• contextgevend
• consistent
• permanent
• passend
• uitbreidbaar
• niet hinderlijk
• gecoördineerd
• toegankelijk

Zichtbaar

Maak van navigeren geen paaseieren zoeken: Zorg ervoor dat de belangrijkste elementen van de navigatie standaard zichtbaar zijn. Mensen scannen websites op hyperlinks met trefwoorden die aansluiten bij het doel dat ze voor ogen hebben. Veel interactie-elementen worden hierbij intuïtief genegeerd. Ook subtiele, maar essentiële hyperlinks als “menu” in onderstaand voorbeeld lopen een groot risico over het hoofd gezien te worden.

Figuur 3: Op Novell.com is de navigatie onzichtbaar

Figuur 4: Hoe hoger de beeldschermresolutie, hoe meer het navigatieknopje van Coca Cola voor het oog verdwijnt

Intuïtief

De gebruiker moet direct snappen hoe het navigatiesysteem werkt. In de regel betekent dit interface-elementen gebruiken waarmee de gebruiker al vertrouwd is. Dit gaat over zowel presentatie, groepering en taalgebruik. Over alledrie bestaan conventies. Gebruikers verwachten bijvoorbeeld:

• direct zichtbare en herkenbare menu’s, bovenaan en/of links;
• een “home” knop (maar niet op de homepage) helemaal links in de globale navigatie (het hoofdmenu) of in de buurt van het menu;
• een logo in de linker bovenhoek;
• een open zoekveld in de rechter bovenhoek;
• log in/uit en winkelwagen-icoon (indien van toepassing) in de rechter bovenhoek;
• subtiel vormgegeven metanavigatie helemaal bovenaan en/of helemaal onderaan;
• dat bepaalde navigatielabels op iedere site gehanteerd worden: Home, Contact, Sitemap, maar ook “Over ons”. Hoewel je dit laatste nog mag vervangen door “Over [organisatienaam]“.

Maar ook een creatieve navigatie-interactie (dus zonder vertrouwde interface-elementen) kan intuïtief werken, als de werking al bij de eerste aanraking direct duidelijk wordt.

Niet intuïtief zijn bijvoorbeeld menu’s die drukke / bannerstijl plaatjes gebruiken in plaats van tekstlabels. De hoofdnavigatie van Coca Cola was in eerste instantie al onzichtbaar, maar als je het vervolgens openklikt, zie je navigatie-items vermomd als banners.

Figuur 5: Coca Cola’s hoofdnavigatie ziet eruit als een rij banners

Contextgevend

Het navigatiesysteem moet communiceren waar in de website de gebruiker zich bevindt. Dit kan op verschillende manieren, zoals:

• huidige locatie visueel aanduiden (bv. door contrasterende kleur) in de lokale navigatie;
• hoofdonderdeel waar de huidige pagina onder valt, visueel aanduiden in de globale navigatie;
• broodkruimelpad opnemen in de pagina.

Daarnaast is het voor de oriëntatie van de gebruiker erg belangrijk dat de navigatie permanent en consistent is.

Permanent en consistent

Het navigatiesysteem is op iedere pagina van de website aanwezig. Het wordt op iedere pagina op dezelfde plaats en op dezelfde manier gepresenteerd. Het gedraagt zich consistent van pagina naar pagina en ook de links erin gedragen zich consistent.

Figuur 6: Wehkamp heeft een permanente, consistente navigatie

Bovenstaande lijkt allemaal vanzelfsprekend, maar gaat nog vaak genoeg mis. Bij grote, complexer websites met een diepe informatiestructuur (bv. 7 lagen) is het vaak zoeken naar navigatiesysteem dat alle lagen bereikbaar maakt en nog goed te hanteren is voor de gebruiker. Dit wil dan nog weleens ten koste gaan van bijvoorbeeld het permanent tonen van de bovenste lagen.

Passend

Navigatiecomponenten en -stijl passen bij de functie van de website en de organisatie erachter. Bijvoorbeeld: een carrousel is wellicht niet erg geschikt voor een bank, maar past prima bij een merk als Disney.

Figuur 7: Carrouselnavigatie op Disney.com

Laat ook meewegen welk navigatiecomponent je gebruikt voor welk type navigatie. In het voorbeeld van Disney wordt de carrousel gebruikt als extra navigatiemethode, maar het is erg riskant om het te gebruiken als hoofdnavigatie. Zie weer het voorbeeld van Coca Cola: doordat het linker navigatiemenu onzichtbaar is, is het meest opvallende navigatiecomponent de carrousel in het midden. Maar die brengt de gebruiker alleen maar naar een zomeractie, een reclamespot en naar Hyves (weg van de site dus).

Uitbreidbaar

Het navigatiesysteem is berekend op geplande groei. Sommige organisaties weten zeker dat hun website nooit meer dan 3 hoofdonderdelen gaat bevatten. Maar in de meeste gevallen is de tijdens het project ontworpen navigatie slechts de uitgangssituatie. In de levenscyclus van een site kan de navigatie verbreden, verdiepen en veranderen. Wees hierop voorbereid. Vooral een horizontale navigatiebalk kan snel volraken. Amazon had in maart 2000 bijvoorbeeld nog 9 hoofd-tabs. Vier maanden later waren dat er al 15, verdeeld over 2 regels. Later is de hoofdnavigatie verplaatst naar de linkerkant.

Niet hinderlijk

Soms wijst de navigatie niet de weg, maar staat hij zelfs in de weg bij het uitvoeren van andere gebruikerstaken. Goldfield liet in London een videofragment uit een usability test zien waarin een gebruiker de zoekfunctie van de Amerikaanse BMW-site wil gebruiken, maar daarbij wordt gehinderd door het uitklapmenu.

Figuur 8: Het uitklapmenu van BMW (USA) hindert de zoekfunctie

Gecoördineerd

Veel sites bevatten meerdere navigatiecomponenten: globale en lokale navigatie, metanavigatie, broodkruimelpad, gerelateerde links, navigatie in de content, enzovoorts. Zorg ervoor dat de verschillende componenten elkaar aanvullen en niet tegenwerken.

Toegankelijk

Last but not least: Het navigatiesysteem moet ook gebruikt kunnen worden door mensen met een mobiele telefoon (klein scherm, misschien plaatjes uitgeschakeld) en mensen met een functiebeperking (bv. blind, lichamelijke handicap). Zorg dus dat het ook werkt zonder plaatjes, zonder javascript, dat toetsenbordbediening ondersteund wordt, dat blinde mensen het navigatiemenu ook kunnen overslaan, enzovoorts.

Figuur 9: De website van het Ministerie van VWS heeft niet alleen een toegankelijke navigatie, maar biedt ook snel-links naar de verschillende navigatiecomponenten

Tot zover de top 10 voorwaarden voor een effectieve website-navigatie. Hiermee kun je veel belangrijke usability-problemen voorkomen die betrekking hebben op informatie vinden binnen de website.

Agile (Engels voor snel, levendig) staat voor iteratief (kortcyclisch) werken, onderdeel voor onderdeel. Handig voor het programmeren, daar zijn velen het wel over eens. Maar op het eerste gezicht lijkt agile een bedreiging voor de user experience (UX) omdat het developers controle geeft over het proces en het niet genoeg tijd gunt voor user research, interactieontwerp en gebruikstesten. Toch horen we ook positieve ervaringen van UX-professionals. Hoe waarborg je user experience in een agile omgeving?

Wat is agile?

De meestgebruikte projectmethodieken volgen het watervalmodel. Hierbij doorloopt het project achtereenvolgens een vast aantal stappen, meestal analyse, ontwerp, bouw, test, acceptatie, implementatie en ten slotte overdracht naar beheer. Iedere stap wordt zo volledig mogelijk uitgevoerd, gedocumenteerd en geaccordeerd, zodat het voor iedereen na iedere stap duidelijk is wat het resultaat is/wordt. Bijkomend voordeel is dat projectscope, -planning en -kosten vroeg in het proces ingeschat kunnen worden en ‘fixed’ afgesproken kunnen worden.

“Waterfall method is best when you can’t afford to learn from your mistakes. You don’t design software for the Space Shuttle in an Agile manner.”

Alon Salant, engineer

De Agile filosofie gaat er juist vanuit dat projecten altijd last hebben van ‘voortschrijdend inzicht’. Dat de klant pas echt weet wat hij wil nadat hij een eerste werkende versie van zijn product heeft gezien. Dat bepaalde denkfouten of gaten in het ontwerp pas worden ontdekt tijdens het bouwen of - erger nog - daarna. Met als gevolg dat er een dure, vertragende iteratie nodig is om dat op te lossen, waar van beide kanten geen rekening is mee gehouden. Agile softwareontwikkeling omarmt juist iteraties en verandering van inzicht. In het Manifesto for Agile Software Development staan de volgende waarden:

• Individuals and interactions over ‘processes and tools’
• Working software over ‘comprehensive documentation’
• Customer collaboration over ‘contract negotiation’
• Responding to change over ‘following a plan’

Agile werken vertaalt zich o.a. in:

• Het tegelijk inzetten van alle rollen bij een sprint, in één team. Bij de watervalmethode heeft iedere fase experts., die hun taak uitvoeren en het resultaat overdragen naar de experts voor de volgende fase,
• Het werken aan één onderdeel tegelijkertijd in korte sprints (liever enkele weken dan enkele maanden),
• Zeer frequente tussenopleveringen, dus vaak feedback van de klant, dus regelmatig wijzigingsverzoeken,
• Zo snel mogelijk vertalen van ideeën naar werkende software. Dit is de belangrijkste voortgangsgraadmeter,
• Zoveel mogelijk persoonlijk contact, zo min mogelijk documenteren,
• Geen vroege zekerheid over hoe het eindresultaat wordt, hoeveel iteraties er nodig zijn en/of hoe hoog de projectkosten zullen zijn,
• Nauwe samenwerking op dagelijkse basis tussen ontwikkelaars en belanghebbenden.

Waarom de vraag?

Een agile projectaanpak zou de nadelen van het watervalmodel moeten oplossen. Er zijn inmiddels voldoende voorbeelden van bedrijven die agile succesvol toepassen. Een van de bekendste is 37Signals (bekend van tools als Basecamp en Backpack), die er zelfs een boek getiteld “Getting Real” over hebben geschreven. Door de succesverhalen krijgt de agile filosofie steeds meer aanhangers. Waarom dan de vraag of agile en usability wel samen gaan?

“Agile methoden proberen usability barriëres in traditionele softwareontwikkeling weg te nemen, maar introduceren nieuwe bedreigingen voor de kwaliteit van de user experience. … Agile’s grootste bedreiging voor de kwaliteit van een systeem komt voort uit het feit dat het een door programmeurs voorgestelde aanpak is die vooral de implementatiekant van systeemontwikkeling adresseert. Dit heeft tot gevolg dat interaction design en usability vaak over het hoofd gezien wordt en dus meer als bijeffect van het programmeren ontstaan.”

Jakob Nielsen (Usability-coryfee)

De meeste user experience designers hanteren een watervalaanpak. Het bekendste voorbeeld hiervan is wellicht Jesse James Garrett’s “Elements of User Experience” model. Het proces begint vaak met het inventariseren van o.a. functionele eisen en wensen, gebruikersdoelen en huidig gebruik. Vervolgens bedenken we dan een concept, creëren - al dan niet met input van gebruikers - een informatiearchitectuur en interactieontwerp, testen op usability, en documenteren het geheel. Ten slotte zorgt het grafisch ontwerp voor het glazuur van de user experience.

Wat gebeurt er met dit proces als we user experience design agile gaan benaderen? Een korte SWOT-analyse:

Sterkten (Strengths)

In welke situaties komt agile goed tot zijn recht? (bron)

• Bij projecten:
  • waarin doorontwikkeld wordt (bv. nieuwe features) aan een product (waarvan het concept dus al staat),
  • van start-ups met een duidelijke visie op hun product, features en doelen,
  • waarbij de ‘time to market’ kritiek is voor succes.
• Bij teams:
  • die het volledige vertrouwen krijgen dat ze de doelen behalen, en die daarin optimaal gefaciliteerd worden,
  • die ervaren zijn, intensief kunnen samenwerken en actief kunnen participeren,
  • met UX-ontwerpers die zich comfortabel voelen bij constante iteratie,
  • met engineers/ontwikkelaars die ook gericht op de gebruiker (’user-centered’) zijn en veel communiceren met ontwerpers.
• Bij klanten:
  • die de wensen en behoeften van hun gebruikers kennen/begrijpen,
  • die dagelijks en face-to-face betrokken kunnen zijn en snel beslissingen kunnen nemen (maar ook van gedachten kunnen veranderen),
  • met heldere, vaste business doelen en visie.

Zwakten (Weaknesses)

Wanneer werkt het watervalmodel beter? (bron)

• Bij projecten:
  • waarin intense, non-modulaire, branded user experiences gecreëerd worden,
  • met grote risico’s en/of complexiteit, die heel goed doordracht moeten worden,
  • waarbij het succes van het ontwerp afhankelijk is van de uitkomsten (en beslissingen) van research.
• Bij teams:
  • op afstand, bv. outsourcing, of gewoon op verschillende locaties,
  • waarvan de leden niet allemaal tegelijkertijd aan hetzelfde kunnen werken.
• Bij klanten:
  • die de wensen en behoeften van hun gebruikers niet kennen/begrijpen,
  • die niet dagelijks en face-to-face betrokken kunnen zijn en snel beslissingen kunnen nemen,
  • met veel belanghebbenden die documentatie nodig hebben als context voor besluitvorming,
  • die fixed price, fixed time èn fixed features willen.

Kansen (Opportunities)

• Het werken in iteraties biedt de mogelijkheid om veel regelmatiger feedback van gebruikers te krijgen. Je kunt het zien als continu verbeterproces.
• Testen met werkende software is meestal te prefereren boven testen met beperkte prototypes.
• De user experience designer blijft continu betrokken en kan de usability dus blijven bewaken. Bij watervalprojecten raakt hij vaak na de ontwerpfase op de achtergrond, omdat hij niet meer op het project is ingepland en inmiddels aan zijn volgende project werkt.
• Door veel persoonlijk contact binnen het team wordt usability geen papieren tijger, maar onderwerp van gesprek. Bovendien bespaart het niet uitgebreid documenteren van alle functionaliteiten tijd.

Bedreigingen (Threats)

• Websites zijn niet hetzelfde als webapplicaties. Agile is in principe gebaseerd op het ontwikkelen van applicaties, met grotendeels afgekaderde, op zichzelf staande functies. Bij veel gebruikersscenario’s voor websites speelt het vinden en verwerken van content een grote rol. Daarom zijn website-taken niet makkelijk te isoleren in specifieke functies.
• Het opdelen van het product in kleinere, losse delen, die één voor één ontworpen en ontwikkeld worden, heeft verder als risico dat de gezamenlijke features geen coherente totaalbeleving opleveren.
• Door het werken in korte iteraties van slechts enkele weken en dus heel strakke deadlines, is het risico groot dat als eerste beknibbeld wordt op usability (research en/of testing), uit angst dat daar geen tijd voor is.
• Als de doelgroep moeilijk bereikbaar en/of beschikbaar is voor het projectteam voor gebruikstesten, maar je wilt wel in iedere iteratie toetsen op usability, dan kan dit een tijdrovende en kostbare activiteit worden.
• Een nauwe samenwerking tussen ontwerper en ontwikkelaar is noodzakelijk. Bij waterval hebben ontwikkelaars nog een Functioneel Ontwerp als houvast voor het uitwerken van de user interface. Wat niet beschreven staat, wordt - met name door ontwikkelaars die zich niet ten volste betrokken voelen bij het succes - niet gemaakt of zo makkelijk mogelijk opgelost zonder overleg met de ontwerper. Hieruit volgt ook: Agile en outsourcing gaan niet samen.

Succesvol zijn in een agile omgeving

Jeff Patton (onafhankelijk consultant en agile coach) heeft de volgende aanbevelingen voor user experience designers om succesvol te zijn in een agile omgeving:

• Neem de rol aan van business owner.
• Onderzoek, modelleer en ontwerp vooraf, maar niet teveel.
• Hak je ontwerpwerk in brokken. Voorkom hierbij dat ontwerptijd in het gedrang komt door ontwerpintensieve iteraties af te wisselen met ontwikkelintensieve iteraties.
• Werk parallel aan de huidige development iteratie vooruit aan de volgende iteratie en evalueer/test de vorige iteratie.
• Creëer een pool van gebruikers waar je continu gebruikersonderzoek mee kunt doen.
• Organiseer continu gebruikersonderzoek in een eigen spoor, los van development.
• Combineer meerdere doelen als je met gebruikers zit.
• Test en optimaliseer de user interface iteratief.
• Maak prototypes simpeler (’low fidelity’) naarmate de samenwerking met ontwikkelaars intensiveert.
• Gebruik prototypes / wireframes voor discussie in plaats van specificatie.
• Word een ontwerpfacilitator.

In een volgend artikel ga ik uitgebreider op deze aanbevelingen in.

Zelf ervaring?

Zelf heb ik nog geen hands-on ervaring met agile UX design. Wie heeft er al wel ervaring mee? Klopt de SWOT-analyse? Nog tips?

De introductie van Google Chrome afgelopen augustus markeert een nieuwe mijlpaal in de browsergeschiedenis. Niet omdat het een nieuwe speler op de markt is, niet omdat Google de geestelijk vader is, maar omdat Chrome de eerste browser is die gepositioneerd wordt als ‘shell’ voor webapplicaties. En wat komt er na Chrome? In dit artikel blik ik terug en vooruit naar de evolutie van de browser. Een evolutie die nauw samenhangt met die van personal computing en natuurlijk het World Wide Web.

Dit artikel is in februari 2009 geschreven voor en verschenen in ‘Informatiebeveiliging‘, het tijdschrift van het Platform voor InformatieBeveiliging (PvIB). De laatste sectie van het artikel (over de toekomst) is gebaseerd op mijn eerdere artikel “De browser, de desktop en de toekomst” (sep 2008). De inhoud van dit artikel valt onder een Creative Commons Licentie. Het is ook te downloaden als PDF-document.

De eerste browsers

De allereerste web browser werd in 1990 geschreven door Tim Berners-Lee en heette WorldWideWeb (later hernoemd naar Nexus). Het was op dat moment de enige manier om het World Wide Web te bekijken. In 1993 kwam MOSAIC uit, de eerste browser met een volledig grafische interface en features als plaatjes tussen de tekst, icons en favorieten. MOSAIC ontketende het web. Een jaar later volgde Netscape Navigator (later hernoemd naar Netscape Communicator), die in de beginjaren van het web de browsermarkt zou domineren. De populariteit was te danken aan de gebruikersvriendelijke interface, het feit dat de browser gratis te downloaden was en de snelle ondersteuning van innovaties als cookies, frames en JavaScript.

Met nog maar 18.000 webpagina’s was het Internet in 1995 nog een overzichtelijk informatienetwerk met weinig poespas. HTML-mogelijkheden waren redelijk beperkt. Niet zo vreemd, want de Graphical User Interface (GUI) stond ook nog in de kinderschoenen. Windows 95 luidde het definitieve einde in van het Command Line Interface (CLI) tijdperk. Het web was primair gericht op informatie en navigatie, en in toenemende mate op commercie, met pioniers als Amazon en eBay (1995).

De browseroorlog

Microsoft begon in te zien dat zijn eigen Microsoft Network het aflegde tegen het World Wide Web en zag in Netscape een bedreiging voor het monopolie van besturingssysteem Windows. Het bouwde MOSAIC om tot Internet Explorer (IE) 1.0, die kort daarna al werd vervangen door versie 2.0. Netscape Communicator lag met een marktaandeel van 90 procent echter mijlenver voor op IE. Microsoft besloot grover geschut in te zetten en ging Internet Explorer 4.0 (vanaf deze versie met de Trident browser engine onder de motorkap) meeleveren met het nieuwe besturingssysteem Windows 98. Deze zet was zeer omstreden en resulteerde in een grote mededingingsrechtszaak, maar zorgde wel voor een snel groeiend marktaandeel.

Vanaf IE 5.0 nam Microsoft de dominante marktpositie over van Netscape. Naast de Windows-integratie speelde in het voordeel van Microsoft dat veel meer resources had, sneller was en trouwer de W3C-specificaties opvolgde dan Netscape. Eind 1998 was de browseroorlog beslecht. Netscape gaf de broncode van zijn browser vrij.

De toegankelijke browser

Even kwamen oude browsers (zonder grafische interface) zoals Lynx weer terug op het toneel. Het World Wide Web Consortium (W3C) kwam in 1999 met (WCAG) richtlijnen om het Internet toegankelijk te maken voor mensen met een functiebeperking, zoals blinden en motorisch gehandicapten. In Nederland staan deze richtlijnen nu bekend als het Waarmerk Drempelvrij.nl. Met oude browsers als Lynx en specialistische browsers zoals IBM Home Page Reader konden websites gepresenteerd worden zonder alle grafische en JavaScript poespas. Blinden konden op die manier websites raadplegen met behulp van brailleregels of voorleessoftware. Later werden de oude browsers als Lynx overbodig, omdat er ook toegankelijkheidshulpmiddelen ontwikkeld werden voor de populaire browsers.

De open source browser

In 2002 was het marktaandeel van Internet Explorer met 96% op zijn top. De Mozilla open source community stond echter op het punt met Mozilla Firefox de browseroorlog weer aan te wakkeren. Snel na het uitkomen van Firefox 0.8 werd de nieuwe browser (met Gecko engine) door de internationale pers geprezen om zijn snelheid, veiligheid (IE werd voortdurend geplaagd door beveiligingslekken) en gebruiksgemak. Mozilla slaagde erin features te ontwikkelen die goed aansloten op de ontwikkelingen van het Internet, waaronder:

• Navigeren met tabbladen
  Van 2001 tot 2005 bleef het World Wide Web exponentieel groeien. En niet alleen met pagina’s, maar ook steeds meer applicaties werden omgebouwd tot webapplicaties, bijvoorbeeld routeplanners, telefoongidsen, e-mail clients en tekstverwerkers. Mensen hadden dus naast verschillende programma’s ook vaak meerdere browservensters tegelijk open. Tabbladen binnen de browser vormde dus een zeer welkome oplossing voor de steeds voller rakende taakbalk. Overigens was niet Firefox, maar Opera (met Presto engine) de eerste grotere browser met ‘tabbed browsing’. Microsoft introduceerde tabs in Internet Explorer 7 met enkele verbeteringen (verschuifbaar en sluitknop op de tabs zelf). Google Chrome is de eerste browser die de tabs helemaal bovenaan plaatst, omdat dit volgens Google het meest primaire onderdeel is van de gebruikersinterface.
• Pop-up blokkering
  Ongewenste pop-up vensters waren al jaren een doorn in het oog van menig internetter. Soms kwamen er per seconde meer bij dan je er weg kon klikken. Ook hier was Opera de eerste die tools voor het blokkeren van pop-ups in de browser opnam. Mozilla verbeterde deze functie door alleen automatisch pop-ups te blokkeren bij het laden van de pagina. Microsoft voegde in 2004 pop-up blokkering toe aan IE 6 en twee jaar later een phishing filter aan IE 7.
• Directe zoekmachine-invoer (standaard Google)
  Kort na de lancering van de Google zoekmachine, stapten talloze Altavista- en Yahoo!-gebruikers over naar deze nieuwe, simpele, maar krachtige zoekdienst. Google was direct een hit en tot op de dag van vandaag is er nog geen andere zoekmachine geweest die beter presteert. Google werkte zo goed, dat het voor veel mensen het startpunt werd van zo’n beetje iedere online sessie. Vindbaarheid en dus indexeerbaarheid wordt belangrijk. Semantisch opmaken en schone code levert nu wat op. Google heeft niet alleen invloed op betere naleving van W3C-standaarden, maar ook op de interface van de browser. Eerst is er de Google toolbar (naast de Yahoo! toolbar). Firefox was de eerste browser die een permanent zoekveld opneemt in zijn interface, met Google als standaard zoekdienst. IE7 volgde later dat voorbeeld, maar gebruikte natuurlijk Microsoft Live Search als standaard.
• Extensies
  Extensies zijn kleine programmaatjes of plug-ins waarmee je de browser kunt personaliseren door er extra functionaliteiten aan toe te voegen, bijvoorbeeld:
  • Automatisch voorbeeldplaatjes van websites tonen bij Google zoekresultaten (Google Preview);
  • Een schermvullend driedimensionale afbeeldingenmuur presenteren om afbeeldingen binnen een website of zoekresultaat te verkennen (Cooliris, zie afbeelding X);
  • Kunnen opslaan van een complete webpagina – dus ook wat niet op het scherm past – als JPG-afbeelding (FireShot);
  • Direct een Gmail-account kunnen beheren vanaf de statusbalk (Gmail Manager).

Momenteel bestaan er zo’n 6500 Firefox extensies, voor het grootste deel geschreven door handige Firefox-liefhebbers.

De sociale browser

Social media en social network zijn termen die horen bij het Web 2.0. Maar de eerste sociale informatiesystemen – Bulletin Board Systems (BBS) – bestonden al in 1978, ver voor het World Wide Web. Ze werden gebruikt voor het delen van software, nieuws en korte berichten (forum / chat rooms) en het spelen van online games. De eerste sociale internetapplicaties waren Instant Messengers, zoals ICQ (1996), Yahoo! Pager (1998) en MSN Messenger (1999). Deze software draaide niet in een webbrowser, maar op de desktop.

Het Web 2.0 en de daaraan toegeschreven sociale successen als blogs, Flickr, YouTube, Delicious (sociale bladwijzers), Facebook en Wikipedia zijn ook doorgedrongen tot de browser. In de eerste plaats zijn er voor veel populaire Web 2.0 platformen Firefox-extensies ontwikkeld (zie afbeelding). Hiermee kun je direct in je browser deze services gebruiken zonder dat je eerst naar de website moet navigeren.

In november 2007 aanschouwt de eerste ‘sociale browser’ – Flock – het eerste daglicht. Flock is een onafhankelijke browser, gebaseerd op Firefox, met meegebakken extensies. Onlangs kwam versie 2.0 uit, met de nodige verbeteringen. Uniek in Flock zijn:

• ‘People sidebar’ die de online activiteiten (Twitter, Facebook, YouTube) van vrienden aggregeert.
• Blogpost editor, natuurlijk ook geïntegreerd, die onder andere Blogger, WordPress of TypePad blogs ondersteunt.
• ‘Media bar’ die foto’s en video’s van Flickr, YouTube, Photobucket enzovoorts compact aggregeert. En deze media kun je slepen naar de blogpost editor.
• Volledig geïntegreerde online bladwijzeropslag (Delicious, Magnolia)
• ‘Web clipboard’: snel een tekst, foto, blogpost of iets anders bewaren zonder een bladwijzer te hoeven maken.
• ‘My World’, waar al je RSS, bladwijzer-, foto-, video- en ‘vriend’-updates samenkomen.

Ondanks de mooie integratie en aggregatie van social media, is Flock (nog?) niet doorgebroken als populaire browser.

De mobiele browser

Twitter brak wel door in 2007. Eerst in de Verenigde Staten, een paar maanden later waaide het ook over naar Nederland. Twitter is een platform waarop mensen ‘microblogs’ of ‘tweets’ (korte berichten) kunnen delen met anderen, via SMS, instant messenger, e-mail, de Twitter website en/of via ‘Twitterific’ (een desktop applicatie). Bekende ‘twitteraars’ zijn Barack Obama en Maxime Verhagen. Het mooie aan Twitter is dat het geen primaire interface heeft; de beleving is nagenoeg hetzelfde via pc of mobiel. Twitteren met mobieltjes heeft in 2008 een vogelvlucht genomen en zal in 2009 alleen nog maar toenemen. Twitter is een van de eerste webservices die op grote schaal gebruikt worden met mobiele telefoons. Ondanks dat dit gewoon met SMS kan en niet via de browser hoeft, betekent dit wel iets voor de evolutie van het Internet. Het gebruik verplaatst zich naar andere devices en niet per se binnen een browservenster.

Een andere onbetwiste katalysator van mobiel internet is de iPhone 3G. Voor mobiel internet met dat andere netwerk - GPRS - moest je voorheen vooral veel geduld hebben. Dankzij de nieuwe iPhone met zeer geschikte GUI, een relatief groot scherm en mobiel breedbandinternet wordt er eindelijk intensief mobiel gesurft. Het gebruik van mobiel internet was afgelopen december zeven keer zo hoog als het jaar ervoor.

De browser op de iPhone is Safari, Apple’s browser (met de open source WebKit engine). De populairste mobiele browser op niet-iPhones is onbetwist van Opera. Hun software staat op meer dan 50 miljoen mobiele apparaten. Microsofts Internet Explorer Mobile loopt nog achter op deze concurrenten. Ongetwijfeld gaat er op mobiel gebied nog het nodige gebeuren, zeker als bijna iedereen straks de beschikking heeft over breedband mobiel internet.

De applicatiebrowser

Veel van wat we vandaag op het web gebruiken, zijn niet zomaar webpagina’s, maar applicaties. Google vindt echter de huidige bestaande browsers hiervoor te instabiel en heeft daarom Google Chrome ontwikkeld, een browser die speciaal ontworpen is met webapplicaties in het achterhoofd. Chrome zou een betrouwbaarder ‘shell’ voor applicaties moeten zijn, omdat iedere tab in een eigen proces draait, waardoor nooit de hele browser crasht, maar slechts de ene veroorzakende tab. Bovendien wordt dankzij het ‘multi-process’ principe efficiënter met geheugen omgegaan. Chrome gebruikt, net als Android en Safari, de WebKit engine, omdat het geheugenefficiënt en uitermate geschikt is voor ‘embedded’ devices. Verder is JavaScript zo belangrijk voor de webapplicaties en -sites van vandaag, dat voor Chrome een nieuwe JavaScript Virtual Machine ontwikkeld is, wat zorgt voor veiligheid en platformonafhankelijkheid.

Ook in de gebruikersinterface introduceert Chrome enkele nieuwe features. Naast de al genoemde tabs die helemaal bovenaan het venster staan, zijn er de ‘omnibox’, de ‘nieuwe tab-pagina’ en een nieuwe pop-up blocker. De omnibox combineert de traditionele adresbalk en het inmiddels ingeburgerde geïntegreerde zoekveld. Maar het biedt ook suggesties voor zoektermen, eerder bezochte websites en (nog niet bezochte) populaire websites en -pagina’s. De ‘nieuwe tab-pagina’ toont de 9 webpagina’s die je het meest bezocht hebt, de sites waar je het meest op zoekt en de meest recent bladwijzers en gesloten tabs. De ingebouwde pop-up blocker plaatst een pop-up geminimaliseerd op de tab vanwaar hij werd geopend.

Chrome is waar we nu aanbeland zijn, vijftien jaar na de introductie van MOSAIC. Wat wordt de volgende stap? Nu Web 2.0 over zijn hoogtepunt is, zullen browsers moeten gaan anticiperen op Web 3.0, het semantische web.

De semantische browser

Volgens Tim Berners-Lee, de grondlegger van het web, liggen de bouwstenen klaar om het semantische web te maken. Het huidige web is gebaseerd op aan elkaar gelinkte pagina’s. Het semantische web is een web van entiteiten (dingen). Documenten gaan immers over mensen, boeken, landen, gebeurtenissen, enzovoorts. Als we computers de samenhang tussen de entiteiten kunnen laten begrijpen, kunnen ze ons beter van dienst zijn. Een belangrijke bouwsteen van het ‘klassieke’ semantische web is het Resource Description Framework (RDF), waarmee je entiteiten en hun relaties beschrijft, zoals “[Peter] {kent} [Michel]”.

Er zijn nog geen mainstream semantische browsers. Wel zijn er al wat academische uitprobeersels zoals de OpenLink RDF Browser en enkele interessante Firefox extensies. Eén daarvan is Glue, die informatie toevoegt aan pagina’s die je bezoekt en handige links aanbiedt op basis van onderwerpen op de pagina. Gaat de pagina over een boek, dan biedt Glue diverse Amazon-links naar boek, auteur enzovoorts. Daarnaast is de (nog in bèta zijnde) APML plug-in (Attention Profile Markup Language) interessant, die webcontent voor je zoekt op basis van je surfgedrag.

De webtop en cloud agent

De ontwikkelingen volgen elkaar snel op. De komst van het Internet heeft een onmiskenbare invloed gehad op maatschappij en economie. En met de huidige ontwikkelingen - sociale media, webapplicaties, mobiel breedband, altijd online, semantisch web - wordt die impact alleen nog maar groter. Internetstrateeg Nova Spivack spreekt al van een “Web Wide World”.

Kijkend naar recente concepten en innovaties rijst de vraag of het concept ‘browser’ niet zijn langste tijd gehad heeft. De browser is nog steeds een programma op onze desktop, dat in de basis nog hetzelfde doet als tien jaar geleden: webpagina’s presenteren. Maar als de meeste software van desktop naar online gaat, gaat de browser steeds meer de rol van de desktop overnemen. Vermoedelijk zullen desktop en browser samensmelten tot een zogenaamde ‘webtop‘. Volgens Spivack wordt de desktop van de toekomst een ‘hosted webservice’: “Alle apparaten zullen synchroniseren met de ‘cloud’, waar je applicaties, data en desktop werkomgeving leven als een gebundelde, hosted service. Je desktop verschijnt op ieder apparaat waarop je inlogt, precies zoals je het de afgelopen keer had achtergelaten.” Pikant detail is overigens dat Microsoft al in 1998 browserfuncties (IE 4) in Windows 98 had geïntegreerd, en daarmee in zekere zin al een beginnende webtop was.

Het is interessant zowel de ontwikkelingen van besturingssystemen, als die van browsers in de gaten te houden. Bij de besturingssystemen denk ik dan in de eerste plaats aan de mobiele varianten zoals Windows Mobile en Google Android, omdat het web meer en meer ingebed zal raken in allerhande apparaten. Veel mag verwacht worden van Microsoft en Google, omdat zij zowel de producten als de resources hebben om browser en besturingssysteem te verenigen. Er gaan al geruchten dat Google hiermee bezig is. Maar ook partijen als Apple, Mozilla en Symbian (marktleider in mobiele besturingssystemen) zullen niet stilzitten.

Daarnaast zullen er ook web-based platforms worden ontwikkeld, die nu nog binnen een browser draaien, maar op termijn embedded kunnen werken. Een eerste voorbeeld hiervan is Cloud, een besturingssysteem dat in de browser draait. Bij het opstarten van de computer wordt direct Chrome opgestart met daarop de Cloud webtop (zie afbeelding).

Wat volgens Nova Spivack en Thomas Vanderwal (Amerikaanse informatiearchitect) ook zal veranderen, is de verschuiving van informatie naar attendering. De meest schaarse resource is niet meer bandbreedte of opslagcapaciteit, maar aandacht. Als gevolg van de ‘information overload’ moet je meer overlaten aan je persoonlijke webservice of ‘cloud agent’, die informatie voor je filtert zodat jij er beter op kunnen handelen. Deze agent attenteert je locatie-, tijd-, device- en contextonafhankelijk op relevante data. Dit is mogelijk omdat al je data (webgeschiedenis, vrienden, websites, bladwijzers, voorkeuren, enz.) online staan opgeslagen, bijvoorbeeld in een APML-bestand. Het semantische web moet er vervolgens voor zorgen dat de agent zinvolle relaties kan leggen tussen jouw voorkeuren en entiteiten enerzijds en nieuwe informatie anderzijds.

Deze webtops en agents zijn nog niet gerealiseerd, maar beeldvorming is er al volop. Zo heeft Microsoft afgelopen jaar een filmpje uitgebracht, getiteld “Future Vision: Healthcare”. En ontwerpbureau Adaptive Path presenteerde zijn webtop-concept Aurora (video).

De grote vraag is hoe snel de infrastructuur (semantisch web, alom aanwezig breedband internet, e.d.) rijp genoeg is om de webtop en de cloud agent concepten te verwezenlijken. Zoals gezegd: de bouwstenen liggen al klaar.

Informatiearchitectuur / navigatie

De vindbaarheid van informatie op een website wordt sterk bepaald door de informatiestructuur, die de basis vormt van de website navigatie. Staat de content op een voor bezoekers logische plaats en begrijpt men de naamgeving ervan? Zeker bij informatierijke sites is het bedenken van een goede navigatie een serieuze klus.

Wat is cardsorting?

Cardsorting is een gebruiksonderzoekmethode waarbij de gebruiker zelf onderwerpen (geschreven op kaartjes) rangschikt in voor hem logische groepen. Het wordt toegepast om te komen tot een informatiestructuur die voldoet aan de verwachting van de gebruiker. Het kan zowel gebruikt worden om een compleet nieuwe structuur te ontwerpen als om een al bestaande structuur te testen en verbeteren.

Cardsorting is een geliefde techniek omdat het niet alleen effectief is, maar ook snel en goedkoop. Helemaal als je de cardsorting online afneemt. Maar daarover straks meer.

Cardsorting kent 2 hoofdvarianten:

• Gesloten cardsorting: De gebruiker moet beschreven kaartjes indelen bij voorgedefinieerde (en dus al gelabelde) groepen. Hiermee kan worden getest hoe goed een reeds bestaande (of een nog slechts bedachte) structuur ‘presteert’, met als doel zwakke punten in die structuur aan te kunnen pakken.
• Open cardsorting: De gebruiker mag zelf met behulp van beschreven kaartjes groepen vormen en benoemen. Onderzocht wordt hoe gebruikers de gegeven informatieverzameling voor zichzelf zouden organiseren, met als doel te komen tot een informatiestructuur die daar zo goed mogelijk op aansluit.

Vandaag ga ik vooral in op open cardsorting, omdat ik die persoonlijk het meest toepas en omdat ik eerder al een uitgebreide case study over gesloten cardsorting heb geschreven.

In onderstaand filmpje leg ik aan een schoolklas uit hoe de cardsorting in zijn werk gaat. Dit was in het kader van het redesign van de TU Delft website.

Wat levert het op?

Na afloop van een cardsorting ronde heb je geen definitieve informatiestructuur. Wel heb je inzicht gekregen in bv.:

• Hoe jouw gebruikers jouw informatie intuïtief groeperen; ontstaan er groepen rondom thema’s, doelgroepen, locaties of iets anders?
• Hoe breed en hoe diep de structuur ongeveer wordt. Hoeveel mogelijke hoofdcategorieën zie je voorbijkomen?
• Welke labels je gebruikers aan iedere hoofdcategorie c.q. groep plakken.
• In hoeverre verschillende doelgroepen op dezelfde indeling en/of labels uitkomen.
• Wat de rationale is achter hun indeling.

Op basis van de indelingen door gebruikers en de verkregen inzichten, kun je zelf aan de slag om de uiteindelijke informatiestructuur vast te stellen en die in de navigatie te gebruiken van het interactieontwerp. De bedachte structuur kun je vervolgens samen met de interactie testen in een usability test, of apart in bijvoorbeeld een gesloten cardsorting.

Niet alleen de uitkomst van een cardsorting sessie is belangrijk, ook het denkproces is interessant. Tijdens een sessie kun je af en toe vragen waarom de deelnemer een bepaalde keuze maakt; op dat moment weet hij nog het best waarmee hij het kaartje in zijn handen het meest associeert. Zelf werk ik ook graag met twee- of drietallen, zodat ze vanzelf hardop met elkaar overleggen over de rationale. Het indelen gebeurt misschien wat minder intuïtief, maar vaak vind ik het proces net zo leerzaam als het resultaat. Vorige week heb ik zowel solo- als duosessies gehouden; je kunt ze prima door elkaar gebruiken.

Online vs offline

Tegenwoordig hoef je niet meer fysiek bij elkaar te komen voor een cardsorting sessie. Je kunt gebruikers ook online mee laten doen. De voordelen van online cardsorting zijn:

• Het biedt de kans in korte tijd veel sessies af te nemen zonder daar zelf veel tijd aan kwijt te zijn. Respondenten gaan alleen aan de slag, op het moment dat het hen uitkomt;
• Het werven en inplannen van respondenten  kost veel minder tijd. Je kunt een groot bestand mensen aanschrijven en ziet vanzelf hoeveel er meedoen. En inplannen hoeft dus niet (zie vorige punt);
• Ieders resultaten worden automatisch opgeslagen en sommige online cardsorting tools, bv. OptimalSort, bieden verschillende analysemogelijkheden.

Enkele nadelen in mijn ogen zijn:

• Je bent er zelf niet bij, dus je mist het denkproces en het kunnen stellen van vragen;
• De user interface (vooral bij open cardsorting) kan een drempel zijn voor gebruikers die digitaal minder vaardig zijn.
• Online tools lijken me minder flexibel (zie volgende paragraaf).

Flexibiliteit

Net als bij paper prototyping biedt het werken met papier veel vrijheid, voor mij als facilitator en voor de gebruikers. En de laatste tijd benut ik die vrijheid ten volste. Enkele suggesties:

• Nadat je hebt uitgelegd voor welke website de cardsorting georganiseerd is, maar voordat de gebruikers aan de slag gaan met de kaartjes, geef de gebruikers 10 lege kaartjes. Vraag ze om zoveel mogelijk onderwerpen en/of vragen op te schrijven die ze zelf hopen of denken te vinden op de website. Voeg deze kaartjes aan de stapel toe. Hiermee krijg je inzicht in welke onderwerpen c.q. vragen de gebruikers bezighouden en kun je eventuele gaten in je eigen contentselectie opvullen.
• Geef de gebruikers een stapeltje lege kaartjes en een stapel post-its als ze gaan beginnen. De lege kaartjes kunnen ze gebruiken als ze een bepaald kaartje willen dupliceren (om het in meerdere groepen te kunnen plaatsen) of als ze al doende nog nieuwe onderwerpen bedenken. Met de post-its kunnen ze op ieder moment een groepje labelen of tijdelijk met meerdere woorden omschrijven.
• Verplicht niet dat gebruikers ieder kaartje indelen. Ik zet altijd 2 bakjes klaar: (A) “Snap ik niet” en (B) “Snap ik wel, maar ik weet hem nergens bij in te delen”. Ik heb liever dat gebruikers meteen een kaartje zo wegleggen, dan dat ze het na lang piekeren ergens zonder overtuiging bij indelen.\
• Sta toe dat gebruikers iets aan een kaartje veranderen als het daarmee meer betekenis voor ze krijgt.
• Sta toe dat gebruikers één of meer kaartjes tussen 2 groepen in leggen, als ze bv. vinden dat de kaartjes wel dicht tegen het groepje aanliggen, maar er net niet onder vallen.

De keerzijde van flexibiliteit is dat de resultaten moeilijker onderling te vergelijken en te turven zijn. Flexibiliteit werkt denk ik vooral bij een kwalitatieve benadering (versus een kwantitatieve benadering).

Verwerking en analyse

Het meest tijdrovende van een cardsorting onderzoek is het verwerken van de resultaten. Bij een usability test is soms een enkele waarneming al genoeg om een aanbeveling te kunnen schrijven. Maar bij cardsorting moet je meestal de grote gemene deler vinden omdat je nu eenmaal geen 5 structuren voor dezelfde website kunt aanbieden.

Er zijn verschillende manieren om cardsorting resultaten te analyseren. Als je veel tijd hebt voor analyseren, kun je grote matrices (voorbeeld in Excel, uit TU Delft project) maken van kaartjes (verticaal) versus groepen (horizontaal). Turven hoe vaak een kaartje in welke groep is ingedeeld. Zoeken naar kaartjes die vergelijkbare turfpatronen hebben en die clusteren. Kijken welke clusters en daarmee welke groepen ontstaan, enzovoorts.

Heb je niet zoveel tijd, dan kun je ook eerst focussen op de gemaakte groepen. Zoek naar de indeling die de meeste resultaten dekt. Dan heb je in principe al een mooie basisstructuur om verder mee te gaan. Vervolgens zou je nog kunnen kijken welke kaartjes over de verschillende sessies duidelijk binnen zo’n groep vallen en welke niet. Vervolgens kun je gaan bedenken wat je gaat doen met de nog zwevende kaartjes.

Eén tip met betrekking tot het verwerken van resultaten wil ik nog wel meegeven: nummer de kaartjes! Dat scheelt je heel veel tijd bij het opschrijven en verwerken van de resultaten.

Tips?

Nog andere cardsorting tips? Ik hoor ze graag!

Inmiddels ben ik bij een stuk of tien organisaties langsgeweest, zoals de Belastingdienst, Hogeschool Rotterdam, TNT Post, internetbureau Info.nl en communicatie-adviesbureau Via Forma, de Bibliotheek Rotterdam, adviesbureau WEBMANAGEMENT.nl en trendblog Frankwatching. Elke organisatie gaf mij een kijkje in haar website-keuken. En wat blijkt? De Webrichtlijnen liggen bij de één al in stukjes op het aanrecht om in de soep gegooid te worden, terwijl ze bij de ander nog op de bovenste plank van het kleinste keukenkastje zijn weggestopt.

In mijn gesprekken met managers, redacteuren, developers en vormgevers, in reacties op het internet, in berichtgeving in de media en in de antwoorden die op vragen in mijn enquête voor organisaties gegeven worden zie ik een aantal punten telkens terugkeren. In dit artikel een eerste overzicht van mijn bevindingen.

Onbekend bij het grote publiek

Het eerste probleem van de Webrichtlijnen is simpelweg hun onbekendheid bij het grote publiek. Een korte inventarisatie onder mijn medestudenten levert antwoorden op die zich bevinden tussen ‘regels over hoe de overheid wil dat je website eruit ziet’, tot ‘dat is toch iets voor blinden?’. Veel mensen hebben nog nooit van de term ‘Webrichtlijnen’ gehoord, en wie dat wel heeft, weet vaak niet waar ze precies over gaan.

Verwarring met Drempelvrij

Vaak denken mensen dat ik, als ik over de Webrichtlijnen begin, doel op Drempelvrij. Gevolg van deze verwarring: ze zien het belang van de Webrichtlijnen niet, omdat ze denken dat het alleen over gehandicapten (en dan vooral: blinden) gaat. En veel organisaties willen hun site, heel begrijpelijk, eerst maar eens op orde hebben voor ‘de grote massa’ voordat ze over kleinere doelgroepen gaan nadenken.

Overheidsorganisaties en Webrichtlijnen

Binnen de overheid heeft haast iedereen inmiddels wel iets over de Webrichtlijnen gehoord.  Dat betekent niet dat iedereen ook precies weet waar ze over gaan. Mensen van communicatie-afdelingen denken dat zij niets te maken hebben met de ‘veel te technische’ richtlijnen. Bovendien zijn de Webrichtlijnen maar één van de vele sets richtlijnen waar overheidsorganisaties rekening mee moeten houden. Zo zien ze al snel door de bomen het bos niet meer. Volgens Renata Verloop van WEBMANAGEMENT.nl is ook de verplichte status van de Webrichtlijnen niet altijd bekend. ‘De Webrichtlijnen worden vaak niet serieus genomen. […] Mensen hebben geen flauw idee wat de status is, waar het vandaan komt, en waarom ze het zouden moeten doen.’

Onbemind: door afzender en tone-of-voice

De onbekendheid van het kwaliteitsmodel Webrichtlijnen en de doelen die ermee bereikt kunnen worden is natuurlijk een groot probleem voor de verkoopbaarheid ervan. Maar met alleen meer bekendheid lossen we dit probleem niet op. Met name buiten de overheid reageert men niet altijd even positief op het concept ‘Webrichtlijnen’. Er zijn meerdere factoren die ervoor zorgen dat mensen, al vóór ze serieus naar de inhoud en het doel van de Webrichtlijnen hebben gekeken, afwijzend reageren.

De overheid als afzender

Vooral in het bedrijfsleven en bij internetbureaus wordt de overheid vaak niet gezien als de meest geschikte afzender van een kwaliteitsmodel voor websites. Het internet is een dynamisch werkveld, waarin vernieuwingen aan de orde van de dag zijn. De ‘trage’ overheid past niet in dat plaatje: vindt innovatie niet juist in het bedrijfsleven plaats? Het feit dat de overheid wil vertellen ‘hoe het moet’ werkt meer op de lachspieren dan dat het interesse wekt, en de verwijzing naar problemen met DigiD, de OV-chipkaart en het elektronisch patientendossier wordt snel gemaakt.

Ook op een ander vlak werkt de Nederlandse overheid als afzender boodschapvervuilend: veel opdrachtgevers, developers en designers vertrouwen internationale richtlijnen eerder dan Nederlandse. Misschien is het net zoiets als met Nederlandse films: veel mensen denken toch dat die minder goed zijn dan internationale producties.

Overlap met internationale richtlijnen

Uitleggen dat de Webrichtlijnen grotendeels zijn gebaseerd op internationale regels maakt het niet duidelijker. Met al die overlap tussen de Webrichtlijnen en W3C standaarden, WCAG en internationale best practices is de meerwaarde van de Webrichtlijnen niet voor iedereen evident. Een bezoekje aan Webrichtlijnen.nl biedt geen soelaas: nergens is een kort en duidelijk overzicht te vinden van de precieze relatie met internationale standaarden.

Verplicht voor de overheid. Dus: niet voor ons

Het valt mij op dat degenen die niet verplicht zijn de Webrichtlijnen te volgen, vaak ook niet de intentie hebben dit te doen. Mio van der Lijn, coördinator van de afdeling Frontend Development voor het cluster Media aan de Maas van de Hogeschool Rotterdam verwoordt het als volgt: ‘de Webrichtlijnen voor de overheid, dat lokt meteen de reactie uit: ‘dus niet voor ons!’.

Regels worden doel op zich

Een laatste probleem van de Webrichtlijnen: het zijn regels. En zo worden ze ook gepresenteerd. Organisaties in het bedrijfsleven gebruiken de Webrichtlijnen meestal niet, maar doen wel veel onderzoek naar gebruiksvriendelijkheid en klanttevredenheid. Bij deze organisaties staat de klant echt centraal. Als die naar hun idee tevreden is, dan voldoet de website voor de organisatie. Ze zien niet in waarom ze daarbovenop nog een stel overheidsregels zouden moeten volgen. En daar ligt het probleem misschien ook wel: de regeltjes worden bijna een doel op zich. Terwijl organisaties juist zoeken naar middelen om de doelen van hun organisatie en die van hun klanten te bereiken.

Onbereikbaar ondanks grote inspanning

De Webrichtlijnen zijn dus onbekend en onbemind bij velen. Maar er zijn ook partijen die serieus bezig zijn met het kwaliteitsmodel, zowel binnen als buiten de overheid. De sfeer die ik hier proef is er één van ‘zeker wel willen, maar niet altijd kunnen’. Internetbureaus die toegankelijkheid vanaf het begin in hun websiteprojecten borgen en perfecte code opleveren zien hun toegankelijke front-end verdwijnen zodra de back-endpartij het CMS heeft geïmplementeerd. Gemeenten hebben contracten met ICT-leveranciers en kunnen niet anders dan hun (mogelijk niet duurzame en niet toegankelijke) producten afnemen. Grote organisaties zitten met een site van duizenden pagina’s, en beschikken niet over de capaciteit om elke pdf toegankelijk te maken en alle teksten om te werken naar de duidelijkste en eenvoudigste taal die zich leent voor de content van de site.

Wat ik tot nu toe heb gezien zijn mensen die graag willen werken aan een kwalitatief betere website, die duurzame toegankelijkheid belangrijk vinden, maar die door allerlei externe factoren eenvoudig niet kúnnen voldoen aan de Webrichtlijnen. En daar worden ze zo nu en dan wel een beetje moedeloos van.

Eerste ideeën m.b.t. verkoopbaarheid

Mijn eerste ideeën over het meer verkoopbaar maken van de Webrichtlijnen zijn gericht op het veranderen van die drie problemen: onbekendheid, onbemindheid en onbereikbaarheid. Ik nodig jullie uit dit op te vatten als de start van een brainstorm en mee te denken!

Meer bekendheid door een landelijke campagne

De Webrichtlijnen bestaan al sinds 2004. Toch zijn ze nog steeds enorm onbekend bij het grote publiek, bij webontwikkelaars en -ontwerpers en zelfs bij mensen die voor de overheid werken. Slechts een relatief klein gezelschap enthousiastelingen weet alles over het doel en de inhoud ervan. En bij dat woord enthousiastelingen ligt volgens mij de sleutel: de overheid heeft bij de presentatie van de Webrichtlijnen veel te weinig van dat enthousiasme laten zien, door de nadruk te leggen op het verplichte karakter en de 125 richtlijnen zelf.

Om de Webrichtlijnen verkoopbaar te maken is naar mijn idee eerst een breed draagvlak nodig in de maatschappij. Mensen moeten zich bewust worden van de voordelen van het kwaliteitsmodel van de Webrichtlijnen. Zoals iedereen bekend is met het energielabel en weet wat een BOB is, zo zouden ook (de doelen van) de Webrichtlijnen vanzelfsprekend moeten worden. Is er eenmaal een grotere bekendheid dan zullen internetbureaus, CMS-makers en ICT-leveranciers de Webrichtlijnen omarmen als een manier om hun professionaliteit te tonen, pitches te winnen en klanten tevreden te stellen. Misschien is een landelijke campagne daarom wel een goed idee. In de komende periode wil ik uitzoeken óf een grote campagne zou werken en welke boodschap ik dan precies wil verkondigen. Ik ben ook benieuwd naar jullie ideeën!

Meer aandacht voor de makers

Vanuit de overheid gaat veel aandacht uit naar de opdrachtgevers. Zo is er een stappenplan voor opdrachtgevers en worden er pilots uitgevoerd met gemeentes. Ik ben het ermee eens dat de verantwoordelijkheid voor voldoen aan de Webrichtlijnen uiteindelijk bij de opdrachtgever ligt. Tegelijkertijd merk ik ook dat veel organisaties ervanuit gaan dat hun leverancier op de juiste manier werkt en hun zal adviseren over dit soort richtlijnen. Daarom denk ik dat de Webrichtlijnen juist ook richting bouwers meer gebracht moeten worden als iets dat handig is, als een fijn hulpmiddel bij het bouwen van een site met kwaliteit. Een beetje zoals de Webdeveloper Toolbar in Firefox, of jQuery als framework bij het javascripten.

Differentiëren naar doelgroepen

Naar mijn idee moeten de Webrichtlijnen dus naar verschillende doelgroepen op verschillende manieren gecommuniceerd worden. Naar het grote publiek met een algemene bewustwordingscampagne die draait om de voordelen van de richtlijnen en het uiteindelijke doel: niemand buitensluiten (maar niet beperkt tot mensen met een handicap!). Misschien kunnen we een parallel trekken met milieubewustzijn. ‘Groen zijn’ is iets dat individuen en organisaties de laatste jaren bezig houdt. Zo is ook ‘niemand buitensluiten’ een maatschappelijke verantwoording. Naar de bureaus moeten de Webrichtlijnen gecommuniceerd worden met een meer inhoudelijk verhaal, gericht op de voordelen voor developers en op de voordelen voor het bureau (professionele werkwijze als unique selling point). Naar overheidsinstellingen moeten ze waarschijnlijk op een weer andere manier gebracht worden.

Een andere benadering: focus op de voordelen

Wil zo’n promotiecampagne slagen, dan is een andere benadering nodig. Niet meer de 125 regeltjes, maar de verschillende voordelen die de Webrichtlijnen bieden. Gebruiksvriendelijkheid, toegankelijkheid, zoekmachineoptimalisatie, het zijn woorden die meer aanspreken dan de onaantrekkelijk lange lijst met technisch klinkende regels. Om het bedrijfsleven over te halen moeten de Webrichtlijnen bovendien wat meer gebracht worden als bijvoorbeeld de nieuwste MacBook. Niemand dwingt je om die te kopen, maar hij is zo hip, snel, robuust en strak vormgegeven: die móet je gewoon hebben. Anders loop je binnenkort hopeloos achter. Met andere woorden: focus op de voordelen en maak het interessant.

Wat nu?

Dit artikel is bedoeld als een brainstorm: het zijn mijn eerste ideeën over het verkoopbaar maken van de Webrichtlijnen. De laatste interviews moet ik nog houden, en ik hoop nog meer resultaten te halen uit mijn enquête voor organisaties (werk je bij een organisatie en heb je, in welke functie dan ook, te maken met de website van die organisatie, vul hem dan in en stuur hem door!).

Begin april start ik met het daadwerkelijke concept voor de nieuwe communicatie. En ook dan kom ik natuurlijk weer bij jullie terug voor advies, feedback, tips & tricks!

Graduation project

What are the functional and graphical consequences when designing for different cultures?

I am focusing on applying anthropological research methods in design processes. Just as physical cities and countries differ and reflect the people who live there, so do web sites. When publishing content in other languages than Dutch, there is always the possibility users will find other ways to interpret the visual design than the designer presupposed or there is a potential tension between the practices of design and use. A cultural approach will help us understand and create multilingual usability.

Problem definition

During the upcoming months, till July, I will try to answer my research question: “What are the consequences of language and culture on behavior and experience when launching a website in another country than the Netherlands?”

Feedback

I could use any of the information (opinions, insights, experiences, suggestions, etc) you might have on the relation between anthropology and design and/or designing globally. Also, if you have any experiences with user testing for multicultural groups, I am interested to read about it. I am open to arranging an appointment and having a talk about your knowledge in this area.

Deze case study is ook gepubliceerd op Frankwatching.

De website

De communicatie van de TU Delft is gericht op 9 doelgroepen: eigen studenten, aankomende (bachelor en master) studenten, alumni (oud-studenten), eigen medewerkers, aankomende medewerkers, bedrijven en overheid, media, scholieren (voor de eindfase) en wetenschappers van andere universiteiten. Tot nog toe bediende de website al deze doelgroepen, behalve scholieren. Daarvoor was een speciale scholierensite opgezet.

De universiteit heeft 8 faculteiten, 14 bacheloropleidingen en 45 masterprogramma’s. Daarnaast zijn er postmasters, minors, onderzoeksprojecten, studentenprojecten, dissertaties, leerstoelen en nog veel meer interessants.

Aanleiding project

De bestaande website sloot niet meer goed aan op de communicatiedoelen en het merk van de TU Delft. Ook bleek uit onderzoek dat de site niet gebruiksvriendelijk was, onder andere omdat de informatiestructuur voor de meeste bezoekers onduidelijk was. Verdere doelstellingen voor de website waren:

• Doelgroepgericht aanbieden van gewenste informatie;
• Vindbaarheid door externe zoekmachines vergroten;
• Actieve bijdrage leveren aan het werven van studenten en medewerkers;
• Internationale karakter van de TU Delft versterken;
• Maatschappelijke betrokkenheid van de TU Delft tonen.

Aanpak

De TU Delft selecteerde Tam Tam voor de informatiearchitectuur, het interactieontwerp, het grafisch ontwerp, de productie van html sjablonen en later ook contentadvies. Enig voorbereidend werk was al gedaan, in de vorm van een uitgebreid behoefteonderzoek per doelgroep door Contentkings en een nieuw merkconcept door Studio Dumbar. De technische realisatie nam TU Delft voor haar eigen rekening.

Het project stond onder leiding van TU Delft internetmanager Rob Speekenbrink. Voor het project werden een stuurgroep, werkgroep en klankbordgroep geformeerd, om breed draagvlak binnen de TU Delft en besluitvorming te waarborgen. En voor volledige transparantie startten we een projectsite en -blog, waarmee we vooral in het begin van het project veel van de overwegingen en resultaten met de buitenwereld (voornamelijk stakeholders) deelden, en waar achteraf veel van de overwegingen en documentatie vastgelegd zijn.

Allereerst hebben we een Programma van Eisen (PvE) opgesteld om de ambities voor het project en het verwachte kwaliteitsniveau scherp te krijgen. Input hiervoor is het behoefteonderzoek (pdf), intern (deels via het projectblog) geïnventariseerde eisen en wensen, het nieuwe merkconcept en Tam Tam’s eigen expertopinie.

Omdat doelgroepgerichtheid een van de belangrijkste uitgangspunten was, hebben we gekozen voor een user centered design aanpak. Hier hebben we invulling aan gegeven door:

• doelgroepprofielen op te stellen (kenmerken, aanleiding bezoek, informatiebehoefte e.d.);
• open cardsorting met verschillende doelgroep uit te voeren om tot een informatiestructuur (of navigatiestructuur) te komen die voor iedereen logisch en duidelijk is;
• usability test uit te voeren op het prototype (op basis van het interactieontwerp);
• tekstformats te schrijven vanuit het lezersperspectief;
• veel aandacht te besteden aan de user experience in zowel interactie- als grafisch ontwerp.

Doelgroepen en ingangen

Eén van de eerste dingen die we wilden aanpakken, waren de doelgroepingangen. Bijna iedere universiteit heeft ze, maar vaak zijn ze niet erg gebruikersvriendelijk. Dat lijkt een paradox; doelgroepingangen zijn per definitie erg doelgroepgericht. Het probleem zit hem in het perspectief. Organisaties denken in doelgroepen, bezoekers denken in onderwerpen of taken. Doelgroepingangen dwingen mensen na te denken in welke hoedanigheid zij de site willen bekijken of in welke doelgroep zij denken dat de site-eigenaar hen heeft geplaatst. En zo wordt de lijfspreuk van Steve Krug overtreden: “Don’t make me think!”. Bij de TU Delft hadden de toekomstige studenten het moeilijkste doelgroeplabel: zij moesten zichzelf kunnen associëren met het label “studiekiezers”. We zijn dus aan de gang gegaan met een informatiestructuur zonder doelgroepingangen.

De oude site had een thematische (bovenin) èn een doelgroepnavigatie (linkerkant)

Daarnaast hebben we 3 doelgroepen losgemaakt van de website. De corporate website is primair gericht op externe communicatie. Studenten en medewerkers kunnen voor hun specifieke informatie terecht op hun portal en hoeven daarvoor niet per se een uitgebreide navigatie op de website te hebben. Wel hebben we in de metanavigatie links opgenomen naar de studentenportal en medewerkersportal. Met deze beslissing is de website meteen ruim 50.000 pagina’s kleiner geworden.

En voor scholieren die nog niet bezig zijn met hun studiekeuze, ontwikkelt de TU Delft een speciale scholierensite. Deze scholieren wil TU Delft vooral interesseren in het bèta-vakkenpakket, en nog niet zozeer Delft promoten (wat natuurlijk wel een van de hoofddoelen is van de corporate site).

Alumni (oud-studenten) vormen ook een bijzondere doelgroep. Naar mijn idee heb je drie soorten alumni:

• de actieve alumnus, die zich nog heel nauw betrokken voelt bij de universiteit en zich graag inzet voor alumni-activiteiten en de universiteit,
• de afwachtende alumnus, die wel lid is geworden van een alumnusvereniging om een beetje op de hoogte te blijven en af en toe aan een activiteit deel te nemen,
• de afzijdige alumnus, die zich nauwelijks bewust is met zijn alumnus-status, die meer een band voelt met zijn faculteit, studentenvereniging en studentenhuis dan met de universiteit, die door zijn werk een nieuw netwerk heeft opgebouwd en vooral vakliteratuur en -evenementen in de gaten houdt.

Voor de universiteit zijn alumni een erg interessante groep om een nauwe band mee te onderhouden, dus moest daar aanvankelijk een prominente ingang voor komen, ondanks het advies m.b.t. doelgroepingangen. Maar de meeste alumni komen niet terug bij de TU om ‘alumni-informatie’ te zoeken, maar omdat ze daar een concrete aanleiding voor hebben: ze willen samenwerken, ze hebben gehoord over een interessante lezing of ze hebben bijvoorbeeld in de krant gelezen over een interessant project. Ook voor deze doelgroep zijn we dus zoveel mogelijk uitgegaan van een thema- c.q. taakgerichte benadering.

Informatiearchitectuur principes

Zoals gezegd was de informatiestructuur één van de grootste knelpunten van de website; veel mensen verdwaalden snel in subsites die hun eigen homepage en navigatie hadden. Daarnaast was de informatiestructuur in grote mate opgehangen aan de organisatiestructuur, die externen vanzelfsprekend niet kennen en dus ook niet herkennen.

Als je bijvoorbeeld naar informatie van een bepaalde faculteit keek en je wilde terug naar de homepage, dan kwam je op de homepage van de faculteit in plaats van de echte homepage.

Voor de nieuwe informatiestructuur hebben we een aantal principes opgesteld, waaronder:

• De indeling en labels worden taak- en/of themagericht.
• De website hanteert een centrale, vaste structuur voor alle content. De nieuwe site krijgt één homepage en een navigatiemethode die geschikt is voor grote, diepe structuren.
• Informatie heeft een enkele plaats in de structuur. Waar nodig worden crosslinks aangeboden.
• Informatie moet beschikbaar zijn in alle talen die in de interface van de website worden aangeboden. De inhoud van de verschillende pagina’s nationaal en internationaal kan soms wel verschillen (bijvoorbeeld informatie over benodigde vooropleidingen/diploma’s).

Cardsorting

Vervolgens hebben we per doelgroep een (open) cardsorting sessie gehouden. Iedere groep kreeg een doorsnede van de site-content in de vorm van 100 gelabelde kaartjes en moest die voor zichzelf zo logisch mogelijk organiseren. Onderstaand filmpje laat zien hoe we dit ook met een complete VWO-5 klas hebben gedaan.

De cardsorting sessies leerden ons onder meer dat:

• we waarschijnlijk goed zaten met de thematische indeling. Er werden bijna geen doelgroep-groepjes gemaakt (af en toe voor bedrijven);
• de Bachelor/Master (Ba-Ma) structuur nog niet bekend is bij diverse alumni;
• scholieren een studie tot en met de master als een studie zien (dit is een aanname uit het gegeven dat geen enkel groepje het onderscheid tussen Ba en Ma aanbrengt in de informatiestructuur). Waarschijnlijk is de Ba-Ma onderverdeling pas interessant voor bachelor studenten;
• “Na de opleiding” een belangrijk onderwerp is voor scholieren en studenten;
• alle groepen een onderscheid maakten tussen informatie over opleidingen en ‘studeren aan de TU Delft’;
• opleidingen zo hoog mogelijk in de informatiestructuur moeten staan en dat veel informatie daaronder moet vallen, zoals toelatingseisen, doorstroommogelijkheden, na je studie. In de oude structuur werden deze onderwerpen algemeen behandeld.
• masterkiezers veel minder belang hechten aan informatie over de universiteit en het studentenleven; zij gaan een serieuzere fase van hun studie in en focussen veel meer op de inhoud van een master;
• faculteiten geen plaats hebben in het keuzeproces van een opleiding. Als je op zoek bent naar een opleiding ben je niet op zoek naar een faculteit;
• alumni de namen van de huidige masterprogramma’s niet herkennen en ook niet aansprekend vinden.

We hebben de resultaten van alle cardsorting sessies (xls) samengevoegd, zelf nog eens goed nagedacht en vervolgens een nieuwe informatiestructuur gemaakt, die we verderop in het project hebben getest in een usability test.

Resultaat

De nieuwe informatiestructuur (pdf) laat een aantal essentiële veranderingen zien, waaronder:

1. De hoofdstructuur is thematisch; de doelgroepnavigatie is verdwenen. Vooral dit laatste is een trendbreuk met de meeste andere Nederlandse universiteiten.
2. De labels in de navigatie zijn taalkundig niet consequent. Toch zijn de labels bewust zo gekozen. “Studeren” prikkelt namelijk meer dan “Studie” en omvat meer dan alleen “Opleidingen”. En “Onderzoek” klinkt natuurlijker dan “Onderzoeken”.
3. “Samenwerken” is de container die de meeste oude doelgroepingangen (bedrijven, overheden, alumni, docenten/decanen) vervangt. Dit label sluit ons inziens het beste aan bij de redenen waarom deze doelgroepen de TU Delft website bezoeken. Eerst hebben we het label “Netwerk” geprobeerd, maar die bleef niet overeind in de usability test.
4. Veel meer informatie wordt opleidingsspecifiek aangeboden. Voorheen waren er algemene pagina’s over minors, toelating, kosten en dergelijke. Maar die pagina’s waren zoekplaatjes (bv. de oude toelatingseisen pagina). Bovendien bleek uit de cardsorting dat scholieren en studenten die informatie opleidingsspecifiek verwachten. Voor gedetailleerde opleidingsinformatie (zoals vakgebied, vakken en keuzevakken) linkt de opleidingspagina ook niet meer door naar de faculteitsite. Die informatie staat nu ook gewoon in de centrale, opleidingsspecifieke navigatie.
   
   De plaats en context van de opleidingspagina in de structuur (links oud, rechts nieuw)
5. Alle niet-opleidingspecifieke informatie over studeren is gebundeld in het item “Studeren aan de TU Delft”. In de oude structuur stonden deze onderwerpen onder “Bacheloropleidingen” (bovenstaand plaatje toont een al recentere structuur). Dit leverde in de usability test wel wat waarnemingen op dat mensen echt moesten schakelen tussen deze twee soorten informatie, maar was te prefereren boven de oude situatie.
6. De internationale (Engelstalige) structuur is voor 98% identiek aan de Nederlandse, maar wijkt bewust op enkele plaatsen af. De TU wil zoveel mogelijk dezelfde structuur om het switchen tussen talen gemakkelijk te houden, maar bepaalde onderwerpen als “Prepare your stay” hebben natuurlijk geen echte meerwaarde voor Nederlanders.
7. “Zoek een medewerker” is getransformeerd van menu-item naar zoekmodus. Dit is wel erg wennen voor iedereen die de oude site gewend was.
   
8. De footer willen we zoveel mogelijk inzetten voor ‘service’-links, bv. snel-links naar populaire pagina’s, gerelateerde websites en hulplijnen als “Contact” en “Sitemap”.

N.B. Sommige van bovenstaande punten zijn op dit moment nog niet helemaal doorgevoerd. Het is een flinke klus om alle pagina’s te herschrijven en herstructureren.

Tot zover deel 1 van deze case study. In deel 2 zal ik uitgebreider ingaan op het interactieontwerp, vormgeving en de nieuwe contentformule.