Software-ontwikkelen kan op vele manieren (watervalmethode, cowboy-coding, iteratief) maar de Agile-software-ontwikkelingsmethoden zijn de laatste jaren in populariteit gestegen. In dit blog beschrijf ik wat Agile-software-ontwikkeling nu eigenlijk is, wat de verhouding met SCRUM is en hoe we het gebruiken binnen het project “Voorbereiding nieuwe repository infrastructuur”. Het projectteam heeft ook een tweedaagse cursus gedaan om te leren wat Agile nu inhoudt en hoe het te gebruiken is.

Agile-software-ontwikkeling is een conceptueel raamwerk voor het uitvoeren van software-ontwikkelingsprojecten als alternatief voor traditionele starre praktijken.

Agile werkt met iteraties, waarbij elke iteraties eigenlijk een miniatuurproject op zichzelf is die in een korte periode uitgevoerd wordt. Dit miniatuurproject omvat planning, analyse, ontwerp, bouw, testen en documentatie. Dit miniatuurproject levert altijd iets bruikbaars op; dat kan in de vorm van een webpagina, een procedure, een prototype, een mockup, een functie of een deel van een werkend programma zijn.

Bij Agile-software-ontwikkeling ligt de nadruk op directe communicatie, bij voorkeur persoonlijk contact. Een Agile team moet op 1 locatie werken, liefst zelfs binnen een ruimte, waarbij het team in elk geval bestaat uit mensen die het product definiëren en mensen die de ontwikkeling doen. Tijdens de cursus hebben we geleerd hoe belangrijk communicatie is en hoeveel makkelijker directe communicatie gaat. Of eigenlijk hebben we zelf meegemaakt met oefeningen hoe lastig communiceren is als je niet direct contact hebt. Een van de oefeningen was om een tekening na te tekenen, waarbij de tekenaar de originele tekening niet zag. Communicatie met degene die de tekening wel voor zich had, ging door middel van briefjes. Hiermee leerden we hoe specifiek je moet zijn met communicatie, dat woorden altijd anders geïnterpreteerd worden en dat directe feedback cruciaal is.

Natuurlijk gaat het bij Agile-software-ontwikkeling niet alleen om de directe communicatie, maar heeft het meerdere aspecten. Om het hoe en waarom van deze aspecten beter te kunnen uitleggen, een korte geschiedenis van de Agile-software-ontwikkeling.

De geschiedenis van Agile-software-ontwikkeling begon midden jaren 90 als onderdeel van een reactie op “zwaargewicht”-methoden. Deze methoden zijn zwaar gereguleerd, detail-gestuurd en maken gebruik van waterval-ontwikkelmodellen. Deze modellen werden als bureaucratisch, traag en bekrompen ervaren en belemmeren de creativiteit en effectiviteit van ontwikkelaars. Hierdoor ontstaat er een aantal nieuwe methoden van software-ontwikkeling, zoals DSDM, SCRUM, Crystal Clear, Extreme Programming, ASD en FDD. Al deze nieuwe methoden hebben een aantal waarden gemeen. Deze waarden werden in 2001 in het Agile Manifesto vastgelegd en ondertekend door een groot aantal software ontwikkelaars.

Manifest voor Agile Software Ontwikkeling (vertaalde versie)

Wij laten zien dat er betere manieren zijn om software te ontwikkelen door in de praktijk aan te tonen dat dit werkt en door anderen ermee te helpen. Daarom verkiezen we:

• Mensen en hun onderlinge interactie boven processen en hulpmiddelen
• Werkende software boven allesomvattende documentatie
• Samenwerking met de klant boven contractonderhandelingen
• Inspelen op verandering boven het volgen van een plan

Hoewel wij waardering hebben voor al hetgeen aan de rechterkant staat vermeld, hechten wij méér waarde aan wat aan de linkerzijde wordt genoemd.

Het Agile Manifesto is gebaseerd op de onderstaande 12 principes:

• Klanttevredenheid door frequente, snelle levering van bruikbare software
• Regelmatig aanbod van nieuwe werkende software
• Voortgang wordt afgemeten a.d.h.v. werkende software
• Wijziging van doelstellingen zijn welkom, zelfs laat in het proces
• Nauwe samenwerking op een dagelijkse basis tussen ontwikkelaars en hun belanghebbenden
• Direct persoonlijk contact als beste vorm van communicatie
• Projecten worden opgezet rondom gemotiveerde individuen, en die moeten dan vertrouwd worden
• Voortdurende aandacht aan technische hoogstandjes en goed ontwerp
• Eenvoud is essentieel
• Zelf-organiserende teams
• Voortdurende aanpassing aan veranderende omstandigheden

In 2005 werd er nog een addendum geschreven aan het Agile Manifesto.

Declaration of Interdependence

“We …

• increase return on investment by — making continuous flow of value our focus.
• deliver reliable results by — engaging customers in frequent interactions and shared ownership.
• expect uncertainty and manage for it through — iterations, anticipation and adaptation.
• unleash creativity and innovation by — recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
• boost performance through — group accountability for results and shared responsibility for team effectiveness.
• improve effectiveness and reliability through — situationally specific strategies, processes and practices.

Dus wat is Agile nu eigenlijk:

• Adaptief
  gericht op snel aanpassen aan de veranderende werkelijkheid, dus wanneer het moeilijk is om de toekomst exact te omschrijven en te plannen (heeft veel gemeen met RAD methoden)
• Timeboxed
  Agile neemt de timebox letterlijk (kort, hooguit enkele weken)
• Klant centraal
  De klant is onderdeel van het team. Na elke iteratie wordt voorgang besproken en de prioriteiten heroverwogen
• Product als doel
  Voortgang wordt gemeten aan de hand van werkende producten
• Communicatie
  Communicatie is heel belangrijk en gebeurt op persoonlijk nivo. Rapporten zijn geen communicatiemiddel.

Maar binnen de UBL maken we toch gebruik van de PRINCE2 methodiek? Betekent dit dat Agile werken en werken met PRINCE2 niet samengaan? Dat deze twee methodes elkaar bijten?
Nee, ze bijten elkaar niet, maar ze hebben wel verschillende doelstellingen. PRINCE2 is een projectmanagement methode, Agile is een software-ontwikkelingsmethode. Binnen het project “Voorbereiding nieuwe repository infrastructuur” worden beide methodes gebruikt naast elkaar. SCRUM (een Agile methode, hierover later meer) als de software-ontwikkeling en PRINCE2 als project management methode. Veel kernwaarden komen overeen bij deze twee methoden, alleen worden ze anders uitgewerkt. Het is echter goed mogelijk (en dat doen we dan ook) om binnen een PRINCE2 project de software ontwikkeling op een Agile manier uit te voeren.

We gebruiken SCRUM als Agile-software-ontwikkelingsmethodiek binnen het project “Voorbereiding nieuwe repository infrastructuur”. SCRUM werkt met een multidisciplinair team dat in korte sprints producten oplevert. Deze producten zijn meestal een aantal gerelateerde functionaliteiten binnen de repository infrastructuur. De sprint duurt bij ons 2 weken, niet langer maar ook niet korter.

De requirements die nog geïmplementeerd moeten worden, zijn beschreven in het product backlog. Deze requirements zijn geschreven in de vorm van een user story, zodat deze begrepen kunnen worden door alle teamleden en niet te technisch zijn. Aan de start van een nieuwe sprint wordt uit de items in de product back log de sprint backlog gemaakt. Dit gebeurt in een overleg tussen het team en de product owner. Er wordt een aantal items gekozen die de hoogste prioriteit hebben en binnen 2 weken te implementeren zijn.

Na elke sprint is er een potentially shippable product increment, oftewel een product dat echt aan de klant getoond kan worden.

Elke werkdag wordt er ook een scrum-meeting van 15 minuten gehouden. Hierin beantwoordt elk teamlid de volgende vragen:

• Wat heb je gedaan?
• Wat ga je doen?
• Wat zijn je problemen?

Natuurlijk is er nog veel meer te vertellen over Agile-software-ontwikkeling en in het bijzonder de SCRUM methodiek. Maar voor deze blog laat ik het hier bij, maar vragen mag je natuurlijk altijd stellen (bij voorkeur via directe communicatie!).

Begin december 2014 werd SWIB14 gehouden in Bonn, Duitsland. Dit is een conferentie over het Semantisch Web in bibliotheken, die dit jaar over Linked Open Data ging.
Linked Open Data is een manier om gestructureerde data te publiceren op zo’n manier dat de data met elkaar verbonden is, vrij toegankelijk is (open) en op een betekenisvolle manier bevraagd kan worden. Linked Open Data maakt gebruik van technieken als HTTP, URI en RDF.
Wat bovenstaande precies inhoudt en ook hoe het toe te passen is, daar ging de conferentie over.
De conferentie zelf was 2 dagen, maar de dag ervoor werden er workshops gegeven. Ik ben naar de workshop “Introduction to Linked Open Data” geweest:
Het internet draaide eerst helemaal om computers (computers met elkaar verbonden), later om documenten (websites), maar binnen het semantische web draait eigenlijk alles om dingen. Tja, dingen, en wat zijn dat dan die dingen, vraag je je misschien af. Nou, dat kan van alles zijn; boeken, documenten (dus ook weer websites), personen, maar ook concepten of ideeën.
Over die dingen kan je dingen beweren, zoals die auto is rood of dat boek is geschreven door “Douglas Adams”. De dingen zijn dan “die auto” en “dat boek”, maar ook “rood” en “Douglas Adams”. Een bewering wordt gedaan in de vorm subject-predicate-object, ook wel triple genaamd. Bijvoorbeeld bij de bewering “die auto is rood” is “die auto” het subject, “is” is het predicaat en “rood” is het subject.
Als je uitspraken over dingen wilt doen en die met anderen wilt delen, moet je die dingen wel uniek kunnen identificeren. Dit doe je met behulp van URI’s. Maar ook de predicaten worden met URI’s aangeduid. Maar dat is niet voldoende; je moet ook afspraken maken wat wat betekent en dat een en hetzelfde ding of predicaat dezelfde URI heeft. Hiervoor is het nodig om een vocabulary (woordenschat) te gebruiken.
Er zijn verschillende vocabularies beschikbaar, zoals FOAF, DBpedia, DC terms. En voor bijna elk ding is wel een vocabulary te vinden, bijvoorbeeld via Linked Open Vocabularies.

Wat is nu het grote voordeel van linked open data?

• verbonden: het is linked open data. Als de dingen met een URI benoemd worden, kan de data makkelijk met elkaar verbonden worden omdat duidelijk is dat over hetzelfde ding gesproken wordt;
• open: de data is vrij toegankelijk. Niet alleen omdat het niks (of in elk geval weinig) kost, maar ook omdat er geen restricties op het gebruik zitten;
• eenduidig: doordat er gebruik wordt gemaakt van URI’s, kunnen de dingen eenduidig benoemd worden, ook als ze in praktijk dezelfde naam hebben. Bijvoorbeeld bij het woord “venus” kan de planeet, de godin, de plaats (in Florida, Roemenie of Texas), de film, het lied, de popgroep, het scheermes, het schip of de tennister bedoeld worden. Echter, elk van deze dingen heeft een eigen URI;
• betekenisvol: door linked open data krijgt data betekenis, zelfs meer dan op het eerste gezicht lijkt. Linked open data maakt gebruik van vocabularies (een dataset die betekenis geeft aan bepaalde begrippen). Door deze vocabularies te gebruiken krijgt de data zelf al meer betekenis, niet alleen voor mensen maar ook voor computers die de data interpretteren. Bijv. als het Schema vocabulary gebruikt wordt om aan te geven dat Henk werkt bij de Universiteit Leiden, dan is niet alleen daarmee bekend dat Henk werkt bij de Universiteit Leiden, maar ook dat Henk blijkbaar een Persoon (een bepaalde klasse binnen Schema) is en dat “Universiteit Leiden” een Organisatie (een andere Klasse binnen Schema) is. Door dus dat vocabulary te gebruiken is er meer betekenis gegeven aan de data;
• meerwaarde: doordat de data open, verbonden, eenduidig en betekenisvol is, krijgt de data meerwaarde. Niet alleen voor de producent van de data, maar ook voor de consument van de data. En daarbij kan de producent optreden als consument van andere Linked Open Data;
• taalonafhankelijk: linked open data werkt met dingen in plaats van met woorden. Elk ding, of eigenlijk concept, kan in meerdere talen beschreven zijn. Zoeken op “Den Haag” levert dan ook resultaten voor “The Hague” en “’s Gravenhage” op omdat deze alle zijn gekoppeld aan dezelfde URI.

Natuurlijk werkt Linked Open Data alleen goed als gebruik gemaakt wordt van dezelfde vocabularies. Dit gebeurt voor een deel, maar er zijn ook wel weer een groot aantal vocabularies beschikbaar (zie LOV). Deels worden termen uit de verschillende vocabularies (impliciet of expliciet) weer met elkaar verbonden.

Er waren op SWIB14 diverse presentaties over het gebruik van Linked Open Data. Hieronder een verslag van de naar mijn mening interessantste:

Tom Grahame van de BBC sprak over hoe de BBC Linked Open Data gebruikt. Ze begonnen hiermee met het WK van 2010 en daarna de Olympische Spelen van 2012. Elke atleet was een entiteit (ding) en had een eigen pagina die geheel werd opgebouwd uit Linked Data. Hierdoor had ook een minder bekende atleet een eigen pagina, die qua opbouw gelijk was aan die van een zeer bekende atleet, gevuld met informatie. Hiervoor hoefde een redacteur niet de pagina te maken, maar werd alleen data toegevoegd (ook uit andere bronnen). Voor het nieuws zijn ze nu bezig, maar dat is een stuk lastiger omdat het veel diverser is. Voor de ontologies (een formeel gebruikt woord voor vocabularies) hebben ze een eigen website, evenals een website om alle dingen te beschrijven.
Ze gebruiken hun eigen ontologie omdat het lastig is (maar wel het beste!) om een bestaande ontologie te gebruiken.
Alle linked data wordt in een triplestore opgeslagen en daar liggen diverse lagen overheen zodat de data beschikbaar wordt gesteld aan hun eigen apps maar ook aan derde partijen.

De Pina Bausch Foundation heeft een digitaal archief gemaakt van de danseres/choreografe Pina Bausch. Deze danseres had tijdens haar leven al zelf een digitaal archief bijgehouden. De data is als Linked Data beschikbaar gemaakt en gebruikt verschillende vocabularies zoals purl.org, DC terms, FOAF en SKOS. Op basis hiervan is ook een iPad app gemaakt.

Wikidata had ook een interessante presentatie. Wikidata valt onder Wikimedia, waar ook weer Wikipedia onder valt. Wikipedia bevat heel veel data, maar heeft ook een aantal uitdagingen: ze zijn afhankelijk van vrijwilligers en daardoor zijn er veel verschillen tussen talen. Je zou zeggen dat de meeste informatie beschikbaar is in het Engels. Maar dat is niet zo: slechts 50% van de data op Wikipedia is in het Engels beschikbaar. Helaas zijn andere talen slechter vertegenwoordigd. Wikipedia heeft wel heel veel data, maar is niet altijd toegankelijk. Sommige vragen zijn niet te beantwoorden, terwijl de data wel beschikbaar is op Wikipedia. Wikidata probeert dit probleem op te lossen door de data uit Wikipedia op een soort Linked Open Data manier te beschrijven. Deze data wordt weer binnen Wikipedia gebruikt in bijvoorbeeld de informatieboxen aan de rechterkant van een Wikipedia pagina (zie bijvoorbeeld hier). De data in WikiData is veel gestructureerder, meertalig en met vaste verwijzigingen (URI’s) naar andere bronnen. Ook probeert men voor alle data die toegevoegd wordt een bronvermelding te doen.

Europeana had een presentatie over problemen bij meertaligheid. Ze probeerden een deel van de problemen op te lossen met een nieuwe datamodel gebaseerd op SKOS. Ze hadden voor verschillende termen de vertalingen in verschillende talen en die onderling gerelateerd.

BIBFRAME is de MARC21 opvolger, of althans dat zou het moeten zijn volgens Eric Miller van het bedrijf Zepheira. Bibliotheken hebben veel goede data en zijn op veel punten ver vooruit (“libraries are credibility engines”), maar de data die ze hebben is niet zichtbaar op het internet. De data moet meer naar buiten gebracht worden, bijvoorbeeld via Libhub. We spreken nu niet op een manier die het web begrijpt, maar dat zouden we wel moeten doen. Schema.org is een nieuwe manier om op het web te komen, maar niet dé manier. Links zijn dat. We moeten de search engines gebruiken om gevonden te worden. Niet door te vragen aan de search engines of ze ons en onze data willen opnemen, maar door ze zelf te gebruiken. Met BIBFRAME zou dit mogelijk moeten worden, het is een sociaal data model. Helaas is BIBFRAME nog in de draft/test fase en wordt nog niet echt door bibliotheken gebruikt.

De eindpresentatie werd gedaan door Richard Wallis van OCLC. Hij herhaalde nogmaals dat de bibliotheek niet gelinkt was aan het web: “Why catalog? So we can find things. Why are we on the web? So todays users can find our resources”. Wat bibliotheken moeten doen volgens hem is gebruik gaan maken van linked data met Schema.org als vocabulair. Met Hadoop kan makkelijk data geconverteerd worden. We moeten niet meer denken in records, maar focussen op entiteiten. WorldCat loopt daar volgens hem in voorop.

Natuurlijk waren er nog veel andere interessante presentaties, zoals over alles annoteren, SKOS, KOS, Microtask Crowdsourcing, d:swarm (demo.dswarm.org), ElasticSearch en nog veel meer.

Voor de AppsWorld conferentie was ik van 19 tot en met 23 oktober in London. Eerst een paar dagen met vrouw en kinderen Londen bekeken: Tower of London (de zes raven leven nog), Big Ben, London Eye, Trafalgar square, National Gallery, de wisseling van de wacht en veel tubes.

Dinsdagochtend vlogen mijn vrouw en kinderen weer naar Nederland en ik ging naar de AppsWorld conferentie die gehouden werd in Earls Court Exhibition Centre. AppsWorld is een tweedaagse conferentie en expositie die al 4 jaar wordt gehouden in Europa en Noord-Amerika. Het gaat over apps en app eco-systemen op elke manier: apps voor mobiel (Android, iOS), apps voor televisie, apps voor in de auto, games, HTML5, marketing, betalingen en nog veel meer.

Naast veel bedrijven die hun apps en spullen laten zien, zijn er ook workshops en presentaties. Ik heb er een paar gevolgd waarover ik hieronder meer zal vertellen. Maar nog eerst wat cijfers: ruim 8000 bezoekers, 250 bedrijven en meer dan 200 sprekers (waaronder Steve Wozniak). Deze sprekers werden per track ingedeeld, zoals API strategies, HTML5, Developer World, Tech World, Droid World. Sommige tracks daarvan waren alleen toegankelijk met premium passes.

Dinsdagmorgen begon met verschillende openingstoespraken. Van verschillende sprekers die dag en woensdag ben ik de volgende interessante/opmerkelijke feiten of meningen te weten gekomen:

Meerdere sprekers dachten dat HTML5 steeds meer binnen een mobiele app gebruikt zou gaan worden. Deels komt dit door het feit dat er 2 grote en verschillende mobiele platformen zijn (iOS en Android) en het ontwikkelen voor 1 platform (HTML5) is goedkoper dan ontwikkelen voor 2 platformen.  Verder is ontwikkelen voor Android duurder dan voor iOS of ontwikkelen in HTML5. Dit komt voor een deel door de fragmentatie binnen Android. Maar, de klant verwacht wel een “echte” app die uit een App Store komt. Aan die wens is dus tegemoet te komen door een “echte” app als schil te gebruiken voor de HTML5 app (net zoals wij doen binnen de “Leiden Univ” app).

Naast HTML5 waren er nog andere oplossingen om voor meerdere platformen tegelijkertijd te ontwikkelen. Microsoft had een praatje over crossplatformdevelopment met hun Azure platform. Hiermee is een crossplatform app ontwikkeld voor een rugby team wat er indrukwekkend uitzag (zowel de app als het team). AppMachine heeft een andere oplossing, waarmee je met “building blocks” een crossplatform app in elkaar zet. Dit Nederlandse bedrijf (in de “Fryslân Valley”) was goed vertegenwoordigd en had een mooi product, waarmee je op basis van een website een app kon laten genereren.

De betaalmodellen van apps veranderen ook: het freemium model wordt steeds populairder. 25% van de Android apps en 45% van de iOS apps is nog betaald, de rest is gratis of freemium. Android ontwikkelaars verdienen vooral aan contract werk, niet aan de verkoop van apps. Ook is er nu een mogelijkheid om via Amazon reseller te worden en daarmee geld te verdienen. Paypal had ook een API om binnen een app geld over te maken.

Er wordt steeds meer gezocht naar technologie die niet in de weg zit. Hiervan is Google Glass een duidelijk voorbeeld. Dit is echt bedoeld om de hele dag te gebruiken. Tijdens het praatje over Google Glass bleek het vrij simpel of juist heel moeilijk te zijn om een app te maken voor Google Glass. Dit kwam omdat er 3 manieren zijn om dit te doen, die ook nog ’s door elkaar lopen. Het makkelijkst is om de mirror API te gebruiken, waarbij je eigenlijk op je eigen server bepaalde data klaar zet die via een REST service opgehaald wordt. De mogelijkheden zijn beperkt. Je kan ook de Android Foundation gebruiken, wat je ook gebruikt bij programmeren voor Android. En dan heb je nog de GDK, maar die is nog niet klaar.

De marketing van apps kwam ook aan bod; er was een presentatie van de (vervelende) CEO van ooVoo over SoLoMo. ooVoo heeft 80 miljoen geregistreerde gebruikers, dus ondanks die CEO doen ze toch iets goed.

Over de gebruikservaring van mobiele apps was een heel interessante presentatie van de BBC. Daarin werd duidelijk dat ze eerst veel UX aanpassingen deden en dat ze daar nu op terugkomen omdat het veel extra werk oplevert. Wel vonden ze het belangrijk om een duidelijk thema of terugkerend element te hebben binnen hun mobile apps. Dat deden ze nu door (subtiel) kleurgebruik en 1 custom element. Verder gebruiken ze veel web content binnen hun apps, zoals al eerder aangegeven werd. Het voordeel is dat de content dan altijd up-to-date is. Verder hadden ze als motto: de gebruiker wil de app gebruiken, dus zit hem/haar niet in de weg.
In een paneldiscussie werd daarna duidelijk dat men dacht dat de interactie steeds meer zou gaan naar praten tegen de computer/mobiel. De huidige generatie heeft daar nog wel problemen mee (bang voor reactie van anderen), maar het bleek dat dat niet meer speelde bij de jongere generatie. Ook dacht men dat bij scherminteractie gestures steeds belangrijker worden.

Het interview met Steve Wozniak was erg druk bezocht maar wel interessant. Hij is een echte geek en dat laat ie ook duidelijk merken. Zo heeft ie 2 horloges om, een iPod nano en een Nixie watch. Hij denkt dat smart watches de toekomst zijn, waarbij ze aan de binnenkant open kunnen klappen zodat gebeld kan worden. Ook zou het horloge continu mee kijken en je (als een goede vriend) opmerkzaam moeten maken op dingen; als het een taartenwinkel ziet je laten weten dat je nog een taart moet kopen, maar als er een mooi meisje voorbij komt dit ook laten weten. Techniek moet alles zo makkelijk mogelijk maken en wordt steeds persoonlijker; “who do you ask life’s questions? It starts with G-O and it is not God”

Het was een leuke tijd waarin ik veel gezien en geleerd heb. De nadruk lag vooral op Android en iOS, maar Windows Phone en Blackberry waren ook aanwezig. Wat betreft marktaandeel stellen die (nog) niet / niet meer zoveel voor binnen mobiele apparaten.

Het web is niet meer. Althans, niet meer zoals het vroeger was.

Vroeger, toen moesten er allemaal trucs uit gehaald worden om ervoor te zorgen dat een website op verschillende (versies van) browsers het goed deed en er goed uitzag. Vroeger, eind jaren 90 en begin 2000, toen de browser wars in volle gang waren en je als sitebouwer moest weten welke feature op welke versie van welke browser bestond. Vroeger, toen je meer tijd kwijt was om een website er op elke browser goed uit te laten zien dan met het hele design en ontwerp van de site zelf. Vroeger, toen iedereen alleen nog maar een browser had op zijn PC. Of hooguit een WAP browser op je mobiele telefoon die je niet gebruikte omdat het zo traag was en de sites zo slecht.

Vroeger was alles beter….

De tijden zijn veranderd. Het web verandert mee. Het web zoals het was, is niet meer(!)

Het bouwen voor een versie van een browser behoort tot het verleden. Geen browser sniffing meer nodig, dat zou iedereen wel moeten beseffen. Tegenwoordig is het voldoende om te checken op features.

Nu zijn er heel andere problemen, die gelukkig gepaard gaan met goede oplossingen. En als alle sitebouwers weten en gebruik maken van deze oplossingen, dan ziet de toekomst van het web er heel zonnig uit.

Welke problemen zijn er dan? De meeste browsers houden zich goed aan de W3C standaarden. Er zijn er wel die voorop lopen en features ingebouwd hebben die nog niet tot een (officiële) W3C standaard behoren, maar dat zijn kleine problemen die met wat extra typen op te lossen zijn (bijvoorbeeld het stylesheet element ‘column-count‘ heet in FireFox ‘–moz-column-count’ en in WebKit browsers zoals Chrome en Safari ‘–webkit-column-count’. Die moeten dus in een stylesheet alle drie vermeld worden, wil het op de meeste browsers goed werken).

Het grote probleem van vandaag (en morgen) is dat je website niet alleen meer bekeken wordt op een PC met een scherm van 1024×768 of 1366×768 (meest populair een paar jaar terug en in 2013 nog goed voor 33% van de PC’s) of nog groter (nu ruim 40% van de PC’s), maar ook steeds meer op mobiele apparaten. Deze hebben vaak schermen niet breder dan 320 points (nee, geen pixels!). En, wat vaak vergeten wordt, ze werken niet met een muis! Dat betekent dus dat de links en knoppen die gebruikt worden eigenlijk minstens 40 points breed en hoog moeten worden om goed aantapbaar te zijn.

Gelukkig zijn er technieken beschikbaar om met deze problemen om te gaan: HTML5, CSS3 en JavaScript. Samen bieden ze diverse mogelijkheden om op basis van afmetingen en resolutie van het scherm het design van de site aan te passen, zodat dezelfde site op een PC met groot scherm of op een mobiel met een (relatief) klein scherm goed leesbaar is en goed werkt. Een webdesign benadering die gebruik maakt van deze mogelijkheden is Responsive webdesign. Deze term is bedacht door Ethan Marcotte in 2010. Het houdt in dat de website zich aanpast aan de omgeving waarin deze getoond wordt met behulp van flexibele grids, flexibele afbeeldingen en CSS3 media queries.

Responsive webdesign werkt met relatieve eenheden (percentages en ems) in plaats van absolute eenheden als pixels. Hierdoor wordt de breedte en hoogte van de elementen aangepast aan de breedte (en eventueel hoogte) van het scherm. Zo kunnen bepaalde elementen bij een breed scherm naast elkaar staan en bij een smaller scherm onder elkaar door gebruik te maken van float in het stylesheet.

Ook werkt Responsive webdesign zoals gezegd met CSS3 media queries. Hiermee kunnen stijlen afhankelijk gemaakt worden van het medium dat gebruikt wordt. Dus voor een scherm kleiner dan 400 points breed kunnen stijlen gedefinieerd worden die bepaalde plaatjes verkleinen of bepaalde elementen onzichtbaar maken.

De ideeën en de technieken zijn er dus, maar het vraagt wel een hele andere manier van denken over een website. Mijn mening is dat er niet begonnen moet worden met hoe een site er uit moet zien, maar welke content getoond moet worden. Dus ga uit van de content. Hier biedt HTML5 ook hele goede ingangen omdat hier niet meer de presentatie voorop staat, maar de betekenis. Oftewel je kan in HTML5 aangeven dat iets belangrijk is, of dat het een header, footer, navigatie of een figuur is, maar je doet geen uitspraak over de presentatie in de HTML (dus geen <B> om iets belangrijk en dikgedrukt te krijgen). De presentatie wordt geheel geregeld door stylesheets en eventueel JavaScript.

Content en semantiek kunnen dus geheel gescheiden worden van de presentatielaag. Dit heeft grote voordelen bij het aanpakken van het grote probleem van vandaag (en morgen): veel verschillende schermgroottes en resoluties. Met JavaScript kan de interactielaag aangepast worden aan de mobiele apparaten. Deze werken immers niet met een muis! Je kan dus niet gebruik maken van het feit dat de gebruiker zijn muis over een element op je website beweegt, maar je kan wel weer gebruik maken van allerlei andere interacties die niet met een muis kunnen, zoals vegen of tappen met 2 vingers.

De scheiding tussen content/semantiek, presentatie en interactie heeft nog meer voordelen:

• Zoekmachines kunnen beter indexeren, omdat ze verschil zien tussen de echt belangrijke teksten, en teksten voor navigatie en minder belangrijke teksten (zogenaamde aside)
• De inhoud (content) is makkelijk aan te passen door iemand zonder veel verstand van HTML
• Een andere presentatie vorm is makkelijker te verwezenlijken
• De interactie is aan te passen aan nieuwe mogelijkheden, zoals bijvoorbeeld voorlezen of stembesturing

Responsive webdesign gaat uit van de website in zijn geheel, waarbij elementen verkleind of uitgezet worden als het scherm te klein is voor alles. Dit heeft als nadeel dat alle HTML, plaatjes en javascript geladen moeten worden, ook op een mobiel met slechte netwerk verbinding. Een andere benadering is mobile first: ontwerp/bouw voor het kleinste scherm (een mobiel) en voeg elementen toe naarmate het scherm groter wordt. Dit heeft als nadeel dat de wat minder capabele browsers (oude versies of bij mensen die bijvoorbeeld javascript uit hebben staan) alleen de mobiele versie zien.

Ik denk dat een derde manier de beste oplossing is: ga niet uit van de hele site en verklein of laat weg (responsive webdesign) en ga ook niet uit van het kleinste scherm (mobile first), maar ga uit van de inhoud: content first. Hoe zou dat kunnen werken:

• Bij ontwerp en bouw wordt uitgegaan van de content
• De content die belangrijk is, wordt eerst in betekenisvolle blokken opgebouwd. Hier kan prima HTML5 voor worden gebruikt. Content die niet altijd (dus niet op elk apparaat) getoond wordt, wordt nog buiten beschouwing gelaten. Denk hierbij aan aside blokken of sommige navigatie blokken. De volgorde van de blokken moet logisch zijn, maar de correcte plaatsing op het scherm gebeurt later.
• Plaatjes of video kunnen ook geplaatst worden, maar niet op hele hoge resolutie.
• Om de content nog toegankelijker te maken zou gebruik kunnen worden gemaakt van microdata en ARIA attributen
• Met stylesheets en media queries wordt de presentatie van de blokken gemaakt voor verschillende schermgroottes. Hier kunnen de technieken van responsive webdesign goed gebruikt worden. Er wordt bij deze stap al rekening gehouden met extra content, zoals asides.
• Met javascript kan nu de extra inhoud en/of betere versies van plaatjes of video ingeladen worden. Bijvoorbeeld, er kan op een groot scherm een aside geladen worden. Ook kunnen de hoge resolutie versies van plaatjes ingeladen worden, als het doelsysteem dit toelaat (denk aan of het scherm het aan kan en of de netwerkverbinding goed genoeg is)
• Met javascript kan een extra interactie laag aangebracht worden, bijvoorbeeld voor ondersteuning van swipen of tappen met meerdere vingers voor mobiel, maar ook voor mouseovers voor de desktop.

Alle extra content kan met technieken als media queries en javascript geladen worden, zodat webbrowsers die daar geen capaciteit voor hebben, er ook niet mee belast worden.

Content first vereist een andere manier van websites ontwerpen en bouwen. Maar de technieken zijn voor een groot deel bij de meeste webbrowsers al beschikbaar. Oudere webbrowsers worden ook goed getoond, maar hebben wellicht minder functionaliteit. Het belangrijkste, namelijk de content, wordt goed afgebeeld.

Op naar een zonnige toekomst!

PS: na het schrijven van deze blog kwam ik erachter dat de term “content first” al eerder werd gebruikt. Zeker de moeite waard om ook deze artikelen te lezen, waarbij de invalshoek net anders is:
https://www.frankwatching.com/archive/2012/10/09/van-mobile-first-naar-content-first/
https://www.frankwatching.com/archive/2013/08/16/content-first-van-responsive-design-naar-dynamische-website/
https://www.marketingfacts.nl/berichten/content-first-bij-de-nieuwe-responsive-website-van-ing-commercial-bank
https://www.lukew.com/ff/entry.asp?1430