
Hoe ontwerp en ontwikkel je een website, intranet of extranet voor zowel desktop als mobiel, tablet, TV en andere devices? Een hot topic, ook hier op Frankwatching. De traditionele ‘waterval’-aanpak is wat ons betreft verre van ideaal. In dit artikel stellen wij daarom een nieuwe aanpak voor: het 'sustainable'-model.
Onze ervaring is dat de traditionele ‘waterval’-aanpak te lang duurt, te duur is, niet efficiënt genoeg werkt én te weinig grip geeft op het eindresultaat als je voor responsive webdesign gaat. Maar alternatieve aanpakken passen niet altijd bij ons als professionals en zijn vaak te beperkt, bijvoorbeeld omdat ze strategie achterwege laten. Daar komt bij dat iedereen wel ‘content first’ zégt, maar niemand het daadwerkelijk dóet. Dat kan en moet anders. We introduceren dan ook één agile aanpak voor strategie, responsive design, development én contentproductie: het ‘sustainable’-model.
Ontwerpen en ontwikkelen voor mobiele toepassingen
Eerder deze maand schreef Anne-Roos Hassing ‘Van mobile first naar content first’. Een interessant artikel, waarin ze de vraag stelt: “Wat is de juiste manier om te ontwerpen voor mobiel?” Vervolgens gaat ze in op heel interessante onderzoeksresultaten van Google en benoemt ze technische en functionele aspecten “zoals locatiebepaling of cameratoepassing”.
Anne-Roos benoemt ook enkele stappen voor een aanpak om voor mobiel te ontwerpen:
- Content is het uitgangspunt en alle content is via elk device toegankelijk.
- Prioriteren van content/functie naar devices op basis van gebruikerstaken.
- Optimaliseer voor de verschillende gebruikersmomenten per device.
(Of alle content altijd op alle devices toegankelijk moet zijn, is de vraag; over ‘responsive content’ schreven we al eerder op Frankwatching én op .Net Magazine. Punt 2 zijn we het van harte mee eens: ook over hoe je van toptaken een succesvolle site (of intranet) maakt, publiceerden we al eens.)
Hoewel deze 3 stappen zeker hout snijden, vinden wij ze wat al te high-level. Wij misten bovendien wat eigenlijk het antwoord op die vraag zou moeten zijn: hoe ontwerp en ontwikkel je nu voor mobiele toepassingen? Waarbij onze aandacht in eerste instantie niet uitgaat naar apps, maar juist naar het web.
Traditionele aanpak voor webdesign en development…
De afgelopen 10 à 15 jaar hebben de meeste van onze vakgenoten websites, intranetten en extranetten ontworpen en ontwikkeld volgens grofweg deze stappen:
- Doelgroeponderzoek
- Online strategie/contentstrategie
- Informatiearchitectuur en interactieontwerp
- Grafisch ontwerp/webdesign
- Frontend- en backenddevelopment
Die aanpak bleek prima te voldoen en leverde, binnen een overzichtelijke periode en tegen (meestal) acceptabele kosten, een heel goed werkbaar eindproduct op. Waarbij contentproductie doorgaans in een parallel traject plaatsvond, in ons geval soms alleen door onze opdrachtgever zelf, maar vaak ook in samenwerking met onze collega’s.
… duurt te lang, is te duur en niet effectief als je responsive gaat
Toen we aan de vooravond van ons eerste responsive project stonden, hadden we al snel in de gaten dat die oude watervalmethode niet goed was. Want normaal gesproken ontwikkel je voor een desktopsite een interactieontwerp van bijvoorbeeld 15 templates in Axure of een vergelijkbare tool, en vervolgens maak je voor diezelfde 15 templates grafisch design in Photoshop. Daar ben je dan bijvoorbeeld 4 weken zoet mee, inclusief correctierondes, enzovoort.
Maar nu moet je nu niet alleen voor desktop, maar ook voor mobiel en tablet ontwerpen. Dan maak je dus ineens 3 x 15 = 45 templates in Axure en 3 x 15 = 45 designs in Photoshop. En dan hebben we het nog niet eens over verschillende typen mobiel en tablet, om van TV of gameconsole nog maar te zwijgen.
Bovendien blijf je in Axure en Photoshop aan het knutselen in statische bestanden, waar je vervolgens je ‘normale’ vertaling naar HTML/CSS van moet maken, voor mobiel, tablet én desktop. Op deze manier rijzen doorlooptijd (niet 4 tot 6, maar 6 tot 8 weken) én kosten van de traditionele watervalmethode (denk alleen maar eens aan de meer-uren) natuurlijk de pan uit. Terwijl de efficiëntie van het proces en (dus) de kwaliteit van het eindproduct (effectiviteit) vervolgens te wensen over laten. Je loopt op z’n minst dat risico.
Alternatieve aanpak voor responsive webdesign
Gelukkig zijn er heel veel slimme mensen in de wereld van design en development. Er wordt dan ook veel gezegd en geschreven over hoe je responsive dan zou moeten aanpakken. We lichten 2 voorbeelden waar wij brood in zagen, uit, van de verschillende aanpakken en workflows die we de afgelopen tijd tegenkwamen:
- Ontwerpen in de browser
- Maak het watervalproces responsive
Ontwerpen in de browser
Stephen Hay is spreker, schrijver en eigenaar van Zero Interface. Hij beschrijft zijn flexibele aanpak, ontwerpen in de browser, en spreekt daarover regelmatig op conferenties, bijvoorbeeld op Mobilism 2012.
In een aantal stappen verweeft Stephen het ontwerpen van wireframes en composities met front-end develoment:
- Creëer wireframes in HTML en CSS
- Vul wireframes met echte content
- Maak een breekpuntindicatie
- Schets, brainstorm en verwerk dit naar een conceptcomposities voor elk breekpunt.
- Smeed de composities samen met wireframe naar een prototype in HTML (flexibel).
- Betrek de klant en presenteer screenshots (!) van dit prototype.
- Gebruik het prototype na goedkeuring als testmiddel.
- Als alles naar behoren werkt, hergebruik je de meeste code in de ontwikkeling.
Deze aanpak heeft verschillende voor- en nadelen:
- Voordelen
Er is weinig tijd nodig om composities uit te werken met bijvoorbeeld Photoshop. De meeste tijd gebruik je om code te kloppen, code die tijdens de implementatie voortdurend hergebruikt kan worden. Wijzigingen worden direct doorgevoerd voor alle schermformaten — je werkt immers in de browser. En vorderingen kun je eenvoudig presenteren, waardoor je opdrachtgever én je team betrokken blijven. - Nadelen
Ontwerpen in de browser brengt ook nadelen met zich mee. Niet iedereen kan de vertaalslag maken van code naar visuele composities en andersom.
Sarah Parmenter, spreker, user interface designer en eigenaar van You Know Who wijdde hier een artikelaan. Zij zegt:My creative brain switches at the point when I open my HTML/CSS editor (Espresso), and starts thinking in terms of structure and how to achieve the look of my design using as much native CSS as possible. If I don’t have my design to follow, the whole process breaks down for me.
Maar de aanpak van Stephen Hay mist ook de onderzoeks- en strategische componenten. En is daarmee dus eigenlijk incompleet.
Maak het watervalproces responsive
In mei schreef Travis Sheppard een uitstekend artikel op ReadWriteWeb over hoe je met relatief kleine aanpassingen aan het watervalproces, toch kunt ontwerpen en ontwikkelen voor meerdere schermgrootten. Hij benoemt 5 stappen:
- Plannen (interactie)
- Ontwerpen (design)
- Bouwen
- Testen
- Wassen, spoelen en herhalen
Sheppard gaat dus uit van wat er is — de watervalmethode — en hij scherpt het proces aan op basis van de eisen die responsive webdesign stelt. Bijvoorbeeld: “Wireframes must represent different screen sizes, and therefore layouts must be fluid.” En net als Hay, zegt Sheppard: “Wireframes need to become prototyping tools rather than blueprints, and some development and testing is needed to ensure they’re fully functional across the display spectrum.”
- Voordelen
Sheppards herhaling in het proces is volgens ons heel goed. Want hiermee incorporeert hij feitelijk interactie- en grafisch ontwerp in een agile of scrumaanpak, terwijl die methode traditioneel alleen voor technische development wordt gebruik. - Nadelen
Ook Sheppard slaat doelgroeponderzoek en (online- of content-)strategie over. Een misser. En als we dan toch scrum bezig zijn: we missen in zijn aanpak de planning en productie van tekst, beeld, video en infographics… dus contentcreatie.
Iedereen zégt ‘content first’, maar niemand dóet het
Met het inbedden van contentcreatie in een vernieuwde aanpak voor design en development van responsive sites, intranetten en extranetten, doe je wat talloze designers, developers en contentstrategen wel zeggen, maar eigenlijk niet doen: content namelijk een beslissende factor maken in wat je ontwerpt en ontwikkelt. Jeffrey Zeldman zei het al:
“Design in the absence of content is not design”
De discussie over responsive webdesign wordt gedomineerd door designers en developers. En hoewel we het meeste van wat zij zeggen beamen — van de goeden in elk geval, zoals Brad Frost, Jeremy Keith, en Josh Clark: thumbs up — vinden we hun dominantie niet goed. Waarom? Omdat er lang niet genoeg gezegd en geschreven wordt over waar content écht over gaat — daar schreven we op Frankwatching al verschillende keren over — namelijk niet over dimensies, verhouding tot functionaliteit, enzovoort, over betekenis, boodschap en het bouwen van relaties met echte mensen.
Daarom pleiten we ervoor om contentproductie in dezelfde aanpak mee te nemen, en niet losstaand, parallel te doen.
Eén aanpak voor een ‘sustainable’ website of intranet
Met onze collega’s hebben we een nieuwe aanpak uitgewerkt die we de afgelopen tijd al verschillende keren in de praktijk hebben gebracht. En die we de komende maanden allicht nog finetunen op basis van de ervaring die we ermee opdoen om er vervolgens zeker op terug te komen hier op Frankwatching. We noemen die aanpak voorlopig ‘sustainable’, omdat we verwachten dat hij voldoende weg blijft van schermgrootten, devicetypen, enzovoort, en (zo) future-friendly genoeg is om ‘houdbare’ ofwel sustainable websites, intranetten en extranetten op te leveren.
Vertrekpunt voor onze sustainable aanpak is wat Jesse James Garrett, medeoprichter en president van Adaptive Path, beschrijft in zijn boek ‘The elements of user experience. User-centered design for the web‘, namelijk de 5 ‘planes’:
- Strategie
- Scope
- Structuur
- Skelet
- Surface
We hebben deze ‘planes’ benaderd als fasen, als stappen in onze aanpak. En we lichten deze 5 stappen hierna op hoofdlijnen toe.
- Strategie
Een goede site of intranet staat of valt met een scherp geformuleerde strategie. We onderzoeken de behoeften van de doelgroep, de (beleids)plannen van de organisatie en de trends in de omgeving van de organisatie én de doelgroep (het ecosysteem). De bevindingen leggen we, nadat we die stevig doorzaken met management en stakeholders, vast in een online strategie. Onderdeel van de online strategie, maar soms ook een afzonderlijke deliverable, is een contentstrategie: met welke content beantwoorden we wanneer aan welke behoefte van de doelgroep op welk platform? Hier komen persona’s, customer journeys en user stories om de hoek kijken.
- Scope
In de scopefase bepalen we de reikwijdte van het eindresultaat (dus niet van het project). We leggen dus functionele eisen en wensen vast, en stemmen ook de contentvereisten af met opdrachtgever en doelgroep. Zo bepalen we niet alleen wat er functioneel en technisch moet komen, maar ook welke inhoud — tekst, beeld, video — daarbij hoort.
- Structuur
Vervolgens geven we concreter vorm aan de website of het intranet. We werken een informatiearchitectuur uit (navigatiestructuur en taxonomie) en bepalen wat we noemen ‘content outlines’: welke content moet waar komen, wat is de boodschap, in hoeveel woorden/beelden, enzovoort. Daarna maken we een compositieontwerp. Hierin geven we aan welke content en functies waar moeten komen. En bepalen daarbij meteen hoe die blokken zich tot elkaar moeten verhouden op kleinere en grotere schermen (contentchoreografie). En tot slot gaat art director Flooraan de slag om de grafische stijl te bepalen. Dat doet hij op hoofdlijnen, wat in de praktijk betekent dat hij op basis van de huisstijl schetsen maakt van een homepagina en enkele subpagina’s. Idealiter doen we dit (ook) voor enkele schermformaten.(Overigens deden we onlangs een experiment met een team van 5 — art director, interactive designer, developer, contentspecialist en opdrachtgever — met als doel in een sprint van één dag een homepagina en een ‘gewone’ contentpagina te ontwerpen en ontwikkelen, en er content voor te produceren. De interactive designer richtte zich enkel op wireframes en front end, en de art director concentreerde zich volledig op grafische stijl. En opvallend genoeg bleek na die ene, korte sprint, dat de ontwikkelde CSS al zo’n stevig basis bood dat we de rol van de art director in volgende sprints terug zouden kunnen brengen tot die van adviseur.)
- Skelet
Vervolgens dient de skeletfase in wezen als voorbereiding op de eerste sprint (en is daarmee eigenlijk sprint 0 uit de bekende scrumaanpak). We maken een database-/informatieontwerp, een gedetailleerd interactieontwerp en gedetailleerd design van de verschillende componenten die we in sprint 1 willen ontwikkelen. En — heel belangrijk! — we ontwikkelen de content voor diezelfde sprint 1. Dat betekent tekstschrijven, fotografie en/of fotoredactie, zo nodig scriptschrijven, filmen en monteren, enzovoort. Waarom vóór de sprint? Als je contentproductie namelijk werkelijk tegelijk met interactieontwerp, design en front-end development doet, zitten ergens een keer mensen op elkaar te wachten. En omdat we ‘content first’ écht menen, maken we de content ook echt first.
- Surface/sprints
Hier wijken we vervolgens sterk af van wat Garrett beschrijft in zijn boek. Want Garretts methode was en is natuurlijk ontwikkeld als watervalaanpak. En daar willen we nu net vanaf. Dus wij noemen ‘surface’ liever ‘sprints’. En daarmee bedoelen we dus niet louter developmentsprints, maar sprints waarin we content produceren of finetunen, details van interactieontwerp en grafisch ontwerp (verder) uitwerken, en vervolgens front end en back end programmeren. Waarbij voor front end geldt dat we al gauw voldoende hebben aan de CSS en dus geen designer meer nodig hebben.
En daarna wassen, spoelen en herhalen in de volgende sprints.
Conclusie
Onze aanpak heeft verschillende voordelen ten opzichte van de traditionele watervalmethode waarbij je alleen een desktopvariant van een site of intranet ontwikkelt. De belangrijkste daarvan is natuurlijk dat je een responsive resultaat hebt dat onafhankelijk is van device en schermgrootte.
Maar zo’n een responsive site kun je ook volgens de watervalmethode ontwikkelen, hoor ik je denken. En dat klopt. Maar je zag in de plaatjes hierboven waarschijnlijk dat zo’n traject zo maar liefst 40% langer duurt. Terwijl je in zo’n langdurig proces volgens ons onvoldoende grip hebt op het eindresultaat.
In onze aanpak (zie hiernaast) houden we weliswaar dezelfde doorlooptijd voor onderzoek en strategie, maar dan gaan we juist sneller met compositieontwerp en art direction. En door in één sprint zowel contentproductie als interactieontwerp én bouw op te nemen, kunnen we sneller in de lucht met een responsive resultaat, dan met een traditionele aanpak voor louter desktop. Om natuurlijk aansluitend de overige content en functionaliteit te ontwikkelen, waaraan je opnieuw kunt schaven en bijsturen op basis van je bevindingen uit sprint 1, met een beter eindresultaat tot gevolg.
We zijn benieuwd naar wat je hiervan vindt. Waar schort het in onze aanpak misschien nog aan of zien we dingen over het hoofd? En heb je misschien andere ervaringen op dit vlak die je wilt delen? We zijn heel nieuwsgierig naar je reactie.
Uitgelicht: Training Schrijven voor SEO: hoe maak je content vindbaar?

Leer in een dag hoe je jouw content (tekst, video, social media) kunt optimaliseren voor Google, zodat je meer conversie realiseert. Sandra Hulsenboom, Marketing & Communicatie SNT: “De training Schrijven voor SEO is een echte aanrader! Je leert veel en krijgt tips & tricks om je website direct beter vindbaar te maken voor Google. Je gaat met energie en inspiratie naar huis om zo snel mogelijk je site te optimaliseren."
Meer weten?


Interessant artikel. Wel erg veel informatie. Ik zou het zelf als volgt samenvatten; agile werkt 40% sneller dan waterval. Als je pas begint met contentontwikkeling wanneer de website af is, dan is deze laatste stap altijd volgens de watervalmethode. Kortom de contentontwikkelaars (redacteuren) moeten vanaf het begin in het proces betrokken worden.
Dan is voor mij moeilijk te zien wat dit te maken heeft met responsive design. Behalve dan misschien dan je ook hier kan zeggen, dat eerst de website bouwen (desktop) en dan pas nadenken ook hoe deze responsive te maken, niet echt past binnen een agile benadering. Ergens lijkt het dan weel een beetje of het bouwen van een responsive design in jullie conclusie ook nog eens sneller gaat dan het bouwen van een traditionele website.
Hoe dan ook het eerder starten met contentontwikkeling, direct responsive bouwen en werken volgens agile vind ik ook een goed idee. Bedankt voor het delen.
Bass, dank voor je reactie.
Om je laatste punt — “… of het bouwen van een responsive design in jullie conclusie ook nog eens sneller gaat dan het bouwen van een traditionele website…” — te beantwoorden: dat lijkt inderdaad zo, maar klopt niet.
In het voorbeeld duurt het traditionele traject 14 weken, en gaat een responsive site volgens een agile aanpak na 11 weken, maar daarna volgens nóg 2 sprints, wat het totaal op 17 weken zou brengen.
Begrijp ik het goed dat jullie met deze aanpak deel voor deel ontwikkelen? Dat werkt naar mijn idee wel met een nieuwe website, maar met een restyle lijkt me dit niet handig. Dan staat al een deel van de nieuwe website online en moet de rest wachten op de volgende sprints? Of mis ik dan iets in het plaatje?
Goede vraag Pieter!
Zeker een goede vraag, Pieter. Maar niet één met een pasklaar antwoord, volgens mij.
Als je letterlijk een restyle doet — dus alle content en functionaliteit blijft bestaan, maar je maakt de site alleen responsive — dan kun je dat denk ik ‘gewoon’ in een waterval doen, maar óók in een aantal sprints, waarbij je steeds enkele onderdelen/templates aanpast.
Maar als een restyle ook inhoudt dat je aan content en functies gaat sleutelen — is dat dan nog wel een restyle?
— zou je, hardop denkend, kunnen kiezen voor ‘planting the seed’ (http://bit.ly/Algcjx) of voor wat je zelf al benoemt, dus een deel vernieuwen, live gaan en de oude content/functies verwijderen.
Iemand andere ideeën of ervaringen? ‘k Ben heel nieuwsgierig.
Ik had ook geen pasklaar antwoord verwacht
Webprojecten zijn nu eenmaal aan veel variabelenonderhevig: dat maakt het ook zo leuk!
Bij ons komt het zelden voor dat bij een restyle enkel het ontwerp wordt aangepast, dus in die zin heb je gelijk: dan praat je over een nieuwe website.
Maar dan blijft toch altijd dat er een reeds bestaande website online staat. Het nadeel van gedeeltelijk een site aanpassen in een sprint en dan direct online plaatsen, is dat je met 2 versies van een website werkt. Dit werkt naar mijn idee verwarrend voor zowel beheerders (als het cms ook veranderd) als bezoekers (die geconfronteerd worden met een veranderende navigatie), om dan nog niet te spreken over het doorverwijzen van pagina’s voor behoud van posities in zoekmachines (zoals al genoemd wordt).
‘Planting the seed’ is een mooie gedachte, maar roept bij mij veel van dezelfde vragen op. De gedachte dat hiermee de denkwijze bij contentproductie veranderd staat me wel erg aan en kan ik me ook goed voorstellen.
Naar mijn gevoel kan het goed werken om in teams diverse sprints te maken om gezamenlijk aan projecten te werken: maar dat is nog lastig in de praktijk te brengen. In de afronding / finetuning van een project heb ik wel gezien dat dit soort sprints erg goed werken en leerzaam zijn voor de verschillende disciplines, met name als hier ook de klant bij betrokken wordt.
Restyling is vaak stukken complexer dan beginnen met een schone lei. Responsive is mooi als het aantal layouts weinig veranderen en is trouwens ook afhankelijk van de hoeveelheid en complexiteit van de beschikbare informatie.
Er bestaat naast responsive / adaptive design ook zoiets als gescheiden content. Als de database en dergelijke goed zijn opgezet kun je met een tool zoals Terra cloud uitstekend verschillende devices afvangen en op basis daarvan de juiste css/html voorschotelen in plaats van te werken met media-query’s en schermformaten.
Blijft de vraag voor content creatie. Bij designprocessen is het zeer zeker belangrijk de klant aan de hand te nemen en tijdig te starten met content voorbereiding wil je voorkomen dat je een compleet CMS inclusief desktop, tablet en mobiel oplevert en de klant nog moet gaan nadenken over content.
Wat ik wel knap vind is om een tijdsplan te maken op development waarin vaak nog van alles uitgevonden moeten worden en debuggen mega veel tijd kan innemen. Levensgevaarlijk trouwens om oude content weg te gooien, beter eerst een 301 erop zetten voordat je oude content zomaar wegmikt
Wat ik mij echter afvraag, Google “hyped” responsive design, maar heeft nog geen duidelijke strategie bij fysiek gescheiden content. Iemand meer ervaring hierin?
@Cris, wat is volgens jou dan responsive design? Je kunt dat volgens mij heel breed nemen, als content voor elk devices beschikbaar (zonder verlies aan …) of heel nauw een html5 layout met css3 media queries.
Content staat toch tegenwoordig altijd gescheiden (in een database)?
Het betrekken van de content bij je responsive design helpt iig met het oplossen van vragen als, wat heb je aan een mobiele webshop als de betaalmethoden niet aansluiten bij mobiel gebruik of een melding over de mobiele site aan mobiele gebruikers, filmpje die niet op een mobiele telefoon te bekijken zijn, afbeeldingen die hun functie verliezen als je te klein worden, etc.
Bij grote verschillen van de aangeboden content op basis van het device, lijkt het ook minder logisch dat alleen met een paar mediaqueries op te lossen. In dat geval is content dus inderdaad leidend in de rest van de implementatie.
Wij merken bij het op zetten van een webdesign (voor kleine opdrachtgevers 2 en 100 medewerkers) dat het aanleveren van de content voor de website nogal eens een probleem vormt in het proces. Hoe pakken jullie dit aan? Niet beginnen met het ontwerp van de website layouts voordat je alle content hebt? Deadlines afspreken voor de content aanlevering (wat doe je dan als ze het niet aanleveren?) Laat de mede professionals maar spreken
In onze (Sabel Online) praktijk hebben we vaak te maken met grotere organisaties die óf eigen communicatiemensen hebben die content organiseren of creëren óf budget kunnen/willen vrijmaken om content te laten produceren, bijvoorbeeld door mijn collega’s van Sabel Communicatie. Hoewel planning daarmee nog steeds een issue kan zijn, is daarmee wel een belangrijke drempel (tijd of geld) weg.
Hoe je dit in kleinere organisaties kunt afvangen, weet ik niet direct. Maar ik kan me voorstellen dat je je opdrachtgever werk uit handen neemt, bijvoorbeeld door een tekstschrijver — bureau of freelancer; elk heeft zijn voordelen — fotograaf of anders mee te offreren.
Hoi Christiaan, we werken inderdaad met een fotograaf en/of tekstschrijver de wij inhuren bij het maken van website. In dat geval komt de tekst/foto meestal als geplant en is de opleveringsdatum van de website ook altijd haalbaar. Raar genoeg vinden veel (kleine) bedrijven het te duur en schrijven zelf de content. Misschien is het voor ons belangrijk hier meer naar toe te werken en anders een website niet te maken. Bedankt voor je reactie.
@aquaster0318 als je werkt op de manier zoals hier beschreven. Dan wordt contentontwikkeling onderdeel van het ontwikkelteam. Er wordt dan dus samengewerkt. Samen met de product-owner wordt bepaald welke content nodig is.
Het hele proces zal stil vallen als de content niet aangeleverd is en het zal de contentontwikkelaar ook duidelijk zijn waarom dat zo is.
In dit geval wacht je dus niet op de klant, maar werkt samen met de klant.
Wij zijn geen tekstschrijvers, die moeten we dan inhuren. Wat als de klant zelf teksten wil schrijven, hoe kun je dan samenwerken aan de content zoals je hier aangeeft? Hoe zie jij die samenwerking?
Dan zul je de klant denk ik moeten meenemen in het proces, en ‘m proberen te houden aan afspraken en deadlines, omdat het geheel van het proces zonder zíjn content in de soep loopt.
De tekstschrijver / of medewerker van de klant moet zoveel mogelijk onderdeel van het ontwikkelteam zijn. Indien mogelijk op locatie en meedoen in de daily scrum. Zo wordt voor het hele team inzichtelijk aan welke content gewerkt is / gaat worden.
Wordt aan het eind van de sprint de frontpage opgeleverd, dan wordt tijdens de sprint dus ook content ontwikkelt voor de frontpage. etc.
Ik kan mij voorstellen dat een kleine organisatie, niet iemand vrij kan maken om zo intensief deel te nemen. In dat geval lijkt een ingehuurde tekstschrijver mij een goed alternatief.
Zou toch erg interessant zijn om zo’n spint een keer in de praktijk te zien, wellicht een idee voor een case / timelapse door één van de bedrijven die deze werkwijze al succesvol inzet?
Bedankt heren, ondanks dat wij een kleinere organisatie zijn proberen wij inderdaad samen met de klant te werken aan een mooi eindresultaat. Jullie maken (aan jullie advies te horen (lezen)) geen websites voor een paar honderd euro?!
Mogelijk iets brutaal maar wel interessant, wat zijn jullie vanaf prijzen? Wij beginnen met maatwerk vanaf 1500,-. Ons concept http://www.Sitetogo.nl maakt websites voor starters en de zzp’er voor 325,- maar dit is (natuurlijk) semi maatwerk dmv voor gedefinieerde website templates.
Het belangrijkste nadeel van deze aanpak lijkt mij dat er geen eenvoudig zicht is op wat de eigenlijke kosten voor het de verschillende responsive resultaten zijn, en er dus geen kosten-baten analyse gedaan kan worden. Oftewel je verkoopt een totaal pakket waarvan je beweert dat het een stuk goedkoper is, maar daarmee weet je niet eens of er een onrendabel deel is dat zonder problemen weggelaten kan worden, of hoeveel het goedkoper zou worden wanneer de klant aangeeft dat een deel onrendabel is. Uiteindelijk kost het ondersteunen van ieder extra breakpoint resources waarvan je toch wil weten of dat rendabel is, en of responsive überhaupt rendabel is.
Dat is een goed punt, Roland. Omdat deze aanpak zo nieuw is en we ‘m niet in zó veel projecten hebben toegepast, zijn we er nog niet aan toegekomen om het kostenaspect uit te diepen. Maar misschien heb jij of hebben andere reageerders suggesties hoe dat zou kunnen.
Kun je bij het aanbod dat je de klant doet een bepaald device uitsluiten? Stel de klant zegt ik wil niet dat mijn site op een tablet bekeken kan worden (of van dat hoeft niet nodig ….) hoe ga je daar mee om? Bezoeker krijgt altijd de desktop versie? Of moet er een melding geplaatst worden; “deze site kan niet …” in het eerste geval heb je geen extra kosten, in het tweede geval wel. In beide gevallen kun je een schets / mockup maken om te laten zien hoe het er uit ziet.
Omdat je proces responsive is; zou je m.i. altijd kunnen laten zien hoe het er uit zou moeten gaan zien op desktop, tablet, etc. vanuit die basissituatie kun je misschien kosten in kaart brengen wat het kost om de gewenste situatie te realiseren.
Voor mij is het grote obstakel dat de SLA voor de desktop versie te veel verschilt van een responsive alternatief. De desktop versie wordt namelijk in de gebruikerstesten gebruikt en in de desktop versie worden de A/B tests doorgevoerd. Oftewel het hele maintenance deel dat de performance van de site in de praktijk test en verbetert schaalt niet mee naar meerdere breakpoints. Dan kan je in theorie wel net doen alsof je bij de ontwikkeling geen device uitsluit, maar in de praktijk ga je geen dure test-resources besteden aan iets anders dan dat waar een verbeterde performance door schaalgrootte het meeste oplevert. Het uitsluiten gaat er dan niet om dat we daar niet even de code voor willen maken, maar daar niet ook meteen 2-3k extra tegenaan gooien om het net zo grondig als de desktop versie te laten testen (als dat al überhaupt technisch mogelijk is). Responsive gaat wat dat betreft niet verder dan dat het misschien beter dan niets is en als het niet te duur is waarschijnlijk niet onrendabel is en misschien nog voor andere vage dingen gunstig kan zijn, terwijl we voor de desktop versie weten dat zelfs die 2-3k voor gebruikerstesten zichzelf nog gewoon terug gaat verdienen.
@ipenburg, @nielsvanmidden en alle anderen bedankt voor jullie uitgebreide reacties. Veel geleerd en een hoop nieuwe ideeën opgedaan hier.
@roland Responsive loont zeer zeker. En dan niet alleen qua investering, maar bedenk ook dat responsive erg positief beoordeeld wordt door Google. Daarnaast moet je rekenen dat 60% van internet plaatsvind op mobiel (zie het CBS persbericht van 23 oktober: http://qrcode-news.blogspot.nl/2012/10/cbs-mobiel-internetten-groeit.html) .
Door mobiele gebruikers een desktopversie te serveren op mobiel wordt de laadtijd van de site erg traag en volgens ons ook keihard meegenomen in je SEO. Een trage laadsnelheid betekend dus “strafpunten”. Het is maar een van 2 argumenten die spreken vóór responsive. Je ontkomt er gewoon niet aan, het moet. Wat exact de kosten zijn per onderdeel is een kwestie van ervaring. Bjj responsive webdesign & development is onze ervaring dat je eigenlijk 3 websites ontwikkeld: Mobiel, Tablet en Desktop. Daar komt straks televisie bij. En als iets niks mag kosten betekend het meestal dat het ook niets oplevert.
Het vak van de webbouwer en online marketeer wordt in ieder geval steeds leuker en uitdagender!
Naast dat ik nog nooit bewijzen gezien heb voor allemaal uitspraken over hoe bepaalde best practices aan SEO zouden bijdragen is het ook een suf argument als je met klanten te maken hebt die toch al lang op nummer 1 staan, of je voor hun intranet dan weer een andere smoes moet verzinnen. En ik ontkom er best aan als ik voor de desktop niet veel groter ga dan iPad en voor mobiel en televisie de browsers op die platformen daar een slimme oplossing voor laat renderen op basis van een desktop site, zoals ze dat ook doen voor alle andere sites die niet responsive zijn en dat ook niet gaan worden. Of dat de beste oplossing is is natuurlijk afhankelijk per site, maar als ik hier zie hoe snel “responsive” degradeert naar 3 designs die dan waarschijnlijk ook nog alleen voor desktop, iPad en iPhone bedoeld zijn krijg ik toch het gevoel dat je daarmee net zo ongefundeerd een heleboel ander potentieel laat liggen. Waarom wordt het bij minder dan 320px blijkbaar te lastig en zou dat niet al bij bijvoorbeeld 480px geconcludeerd mogen worden?
Ik denk ook niet dat responsive op zich een positief effect op je ranking heeft en zeker niet vanwege de laadtijd.
In http://bassjobsen.weblogs.fm/het-vak-van-de-webbouwer-en-online-marketeer-wordt-steeds-leuker-en-uitdagender/ schreef ik eerder vandaag al dat responsive maken mbv media queries de laadtijd helemaal niet, of misschien zelfs juist niet, korter maakt.
Wel kan ik mij voorstellen dat zoekmachines gebruikerservaring (bijvoorbeeld te meten met bounce-rate) graag meenemen in de ranking. Vervolgens lijkt mij een logische stap dat mobiele gebruikers een andere ranking te zien krijgen dan desktop gebruikers bij het gebruik van de zoekmachines. Je zet een site die niet werkt op een mobiele telefoon niet bovenaan in de zoekresultaten van iemand die zocht op zijn mobiele telefoon.
Klanten die nummer 1 staan zullen dat willen blijven staan en ook zullen zij over het algemeen ook mobiel verkeer naar hun site willen hebben.
Intranet staat los van seo daar gaat het enkel om de gebruikerservaring, als iedereen op een desktop werkt en dat blijft doen, dan optimaliseer je uiteraard daarop.
De ondergrens van 320px komt voort uit de beschikbare hardware en is niet per definitie een ondergrens voor design of functionaliteit.
En wat betreft wat jij noemt degradatie naar 3 designs, je kun het ook anders benaderen, zie bijvoorbeeld: http://designshack.net/articles/css/responsive-design-why-youre-doing-it-wrong/
Hoi Roland, kijk gerust eens hier:”Details of recommendations” : https://developers.google.com/webmasters/smartphone-sites/details . Verder is met geen woord gerept over iOS, intranet of 320 pixels, dus begrijp ik je reactie niet goed. Je werkt binnen grenzen van devices, die grenzen zijn als het goed is schaalbaar (liquid).
De vertraging in laadtijd is wel degelijk een issue om rekening mee te houden (bouncepercentage) . Met “strafpunten” zou je je ook af kunnen vragen wat een vertraagde laadtijd op mobiel je als bedrijf gaat kosten: http://blog.kissmetrics.com/loading-time/
Zorg dragen voor device geoptimaliseerde informatie voor bezoekers is ook een kwestie van usability, beleving en respect voor je bezoekers, of je het nu responsive noemt of niet.
Consumenten laten trouwens een merk vallen als de info niet mobiel optimaal is: http://www.themarketingblog.co.uk/2012/04/brands-risk-losing-customers-as-result-of-poor-mobile-engagement-foolproof/ De “bounce” waar Bas over spreekt.
Om dat nou “suf” of “ongefundeerd” te noemen mag best hoor, ieder z’n vak.
PS. Er zijn meer dan 3500 mobiele devices in de wereld die gebruik maken van internet las ik recentelijk. Als dat geen uitdaging is! Who’s first?
In de praktijk kunnen devices die op een fatsoenlijke manier met responsive sites om kunnen gaan over het algemeen ook gewoon de desktop site met een slimme pan & zoom werkend krijgen, dus kan een zoekmachine eigenlijk niet bepalen dat een site niet bruikbaar is op zo’n device. Om mobiel verkeer van dienst te zijn is een door middel van responsive design voor mobiel geoptimaliseerde site dus ook niet eens een vereiste en kan een oplossing die niks kost dus toch wat opleveren. De benchmark van responsive is dus niet 0, maar de performance van de desktop site door een mobile browser (bijvoorbeeld een Opera Mobile of Opera Mini) geoptimaliseerd voor dat device. En het dus ook een optie kan zijn om voor die situatie te optimaliseren.
@ipenburg ik denk niet dat een gebruik wil zoomen om een website te kunnen gebruiken.
Ik kan mij verder helemaal vinden in de uitspraak van @qtag_qrcode, ik herhaal deze daarom nog een keer: “Zorg dragen voor device geoptimaliseerde informatie voor bezoekers is ook een kwestie van usability, beleving en respect voor je bezoekers, of je het nu responsive noemt of niet.”
Websites bouw ik tenslotte toch altijd vanuit het oog van de bezoeker.
Who’s first? Ik ben betrokken geweest bij de ontwikkeling van de i-Mode, WAP en Web-TV versies van de destijds één van de meest gebruikte sites van Nederland. Responsive is ook wel interessant, maar waar vroeger de samenwerking met de server-side echt noodzakelijk was om content of functionaliteit goed op verschillende devices te krijgen is daarmee in vergelijking responsive design een front-end gimmick waar de lat een stuk lager ligt.
“Zorg dragen voor device geoptimaliseerde informatie voor bezoekers is ook een kwestie van usability, beleving en respect voor je bezoekers, of je het nu responsive noemt of niet.” Dat is drempelvrij prio 3 ook, of wordt het dan iets te gekwantificeerd?
Cris (@qtag_qrcode) en Bas (@bassjobsen) hebben hier beide een goed punt.
SEO
6 juni jongstleden vond de Search Marketing Expo in Seattle plaats. Google maakte tijdens deze conferentie bekend dat zij websites hoger ranken wanneer deze geoptimaliseerd zijn voor smartphones. Zij ondersteunen dit in drie degradaties:
1. Websites die responsive zijn.
2. Websites met dezelfde URL waarvan aparte HTML en CSS geserveerd wordt aan de hand van de user agent (desktop of mobiel).
3. Websites die voor desktop en mobiel beide unieke URL’s bieden.
Wat heeft dan de voorkeur?
Toevallig stuurde ik gistermiddag nog een tweet over dit onderwerp: “Google prefereert responsive design alleen als de bezoeker dat ook doet.” Bryson Meunier is spreker en ‘Director of SEO Strategy’ bij het bedrijf Resolution Media. Hij schreef gistermiddag het artikel ‘Does Google really prefer responsive sites?’ Hierin vertelt hij dat de oplossing die het best aansluit bij de bezoeker een betere ranking krijgt. Voor meer details: http://www.netmagazine.com/opinions/does-google-really-prefer-responsive-sites
Christiaan schreef ook eerder voor dit magazine. In het artikel ‘The case for responsive content: it’s all about the users’ haakt hij ook aan op dit onderwerp. Je kunt dat artikel vinden in de volgende URL: http://www.netmagazine.com/features/case-responsive-web-content-its-all-about-users
Responsive Design + Server Side Components: RESS
De ingredienten van responsive webdesign zijn media-queries, een flexibel grid en flexibele media. En dat is inderdaad alleen de front-end. Luke Wroblewski is spreker en medeoprichter van de ‘Interaction Design Association’. Hij is ‘Chief Design Architect’ bij YAHOO geweest en schreef onder andere het boek ‘Mobile First’. In zijn artikel beschrijft hij hoe je het beste van twee werelden kunt combineren: Responsive design en responsive componenten aan de serverzijde. In de volgende URL vind je zijn artikel wat hij ruim een jaar geleden schreef: http://bit.ly/nsW1nq
@ipenburg leuk dat je dat aanhaalt. Juist door met responsive bezig te zijn moest ik weer denken aan de cursus die ik ooit volgde bij wat toen nog “Drempels weg” heette.
In beide gevallen gaat het om toegankelijkheid.
Het lijkt mij goed om ‘de drempels’ ook mee te nemen in het responsive design. Wie zijn site optimaliseert voor een mobiele telefoon, heeft misschien ook de neiging om de zoom functie te beperken. Alles is immers al op de juiste grootte / verhouding gebracht. Iemand die visueel beperkt is, zal de zoomfunctie missen.
Media queries werken ook voor de device typen speech (aural) en braille, daar hoor je nooit wat over.
Je kunt er vanuit gaan dat mensen met een visuele beperking een smartphone kopen met extra ondersteuning voor toegankelijkheid. Zo heeft de iPhone bijvoorbeeld spraakondersteuning, de mogelijkheid om braille-apparaten in te schakelen via bluetooth en om vanuit het Operating System te zoomen en lettertypen te vergroten.
Deze kun je dus gewoon blijven gebruiken.
Wat misschien een leuk weetje is, is dat de mobiele website van Facebook per dag met 7000 verschillende mobiele apparaten benaderd wordt. Simon Cross, developer van Facebook, vertelde dat vorige week tijdens “The Future of Web Apps” in Londen.
@ipenburg wat mij betreft, en volgens mij bij iedereen die heeft bijgedragen aan dit artikel en discussie, ligt de lat juist enorm hoog. Voor mijn klanten wil ik alleen het allerbeste.
Ik ben het met je eens dat de serverklant niet vergeten mag / moet worden. Zolang elk element dat je op de client schaalt of verbergt nog wel volledig geladen moet worden, is er qua performance / laadtijd ook aan de serverkant nog veel winst te halen.
Kijk bijvoorbeeld eens naar: http://www.responsinator.com/?url=http://www.volgensisabel.nl/niels-van-midden/978/landing.html (prototype van @nielsvanmidden) of http://www.responsinator.com/?url=www.webvrouw.nl dan zie je toch als gebruiker hele bemoedigende resultaten? Daar wordt je als gebruiker toch blij van? Dat je dit te zien krijgt en niet een site, waarbij je steeds moet zoomen, scrollen, etc. om te kunnen lezen wat er staat. Als ontwikkelaar tussen al dat moois overigens nog wel een hoop verbeterpunten.
Als ontwikkelaar blijf ik ook zoeken, zowel server-side als client-side naar oplossingen en verbeteringen.
Met al je server-side ervaring kun jij zeker ook een bijdrage leveren. Ik ben benieuwd welke server-side verbeteringen jij ziet en hoe die eventueel passen in een content first benadering.
Natuurlijk wil je voor een klant het allerbeste, maar dat begint lijkt mij met een realistische voorstelling van wat er met een bepaald budget wel en niet bereikt kan worden. Het probleem is niet dat er een gebrek aan kennis is met betrekking tot best practices, maar dat er zoveel aspecten zijn dat je bijna altijd een keuze moet maken. Zelfs al mogen we er van uitgaan dat iedere developer hier de skills en goede intentie heeft om een perfect SEO, drempelvrij prio 3, YSlow Grade A, valide, cross-browser, etc. product op te leveren komt dat er in de praktijk zelden van. Dat is in bijna alle gevallen ook geen probleem omdat de best practices van Google, Facebook en Yahoo! niet echt significant zijn voor de gemiddelde site, maar dan moet je wel een aanpak volgen waarin je enigszins kan voorspellen voor welke aspecten je uiteindelijk niet het “beste” gaat leveren. Dan zie ik responsive als tegenhanger van bijvoorbeeld een mobiele site toch als punt waar er voor gekozen wordt niet het “beste” te leveren.
(En dan heb ik vaak toch iets van leuk geprobeerd maar ik merk er weinig van op mijn Xperia X10 mini Pro of mijn Playstation 3 op full HD, dus waar ging het ook alweer over?)
Wat ik zie is dat net zoals bij drempelvrij een meetbaar succesvolle responsive site weinig kans van slagen heeft als in plaats van dat het als serieuze vraag met dito budget vanuit de business geïnitieerd wordt het als technisch antwoord in het proces lekt. Developers hebben er misschien nog wel lol in om een site op exotische hardware aan de praat te krijgen, maar met content first als vertrekpunt zijn er voor een responsive aanpak te veel specialisten bij betrokken die totaal geen connectie hebben met de subculturen die van bepaalde devices gebruik maken, of dat nu brailleregels of Blackberries zijn. Juist de theoretische vrijblijvendheid van responsive wat betreft devices nodigt uit om dan meestal toch maar niet veel verder te kijken dan de iPhone en iPad die binnen handbereik liggen.
(Steeds zoomen scrollen, etc. is overdreven ingewikkeld geformuleerd: de gebruiker double-tapt of drukt op R3 zodat de browser dat deel van de browser in één keer leesbaar laat zien. Zo kan je rechtshandige 4-inch touchscreen gebruikers ook wel proberen wijs te maken dat een Blackberry zonder touch met je linkerhand bijna onmogelijk te gebruiken is, maar voor linkshandige gebruikers van dat soort devices is dat gewoon hoe het werkt)
De efficiëntie tijdens het ontwikkelen valt of staat bij een ‘mobile-first-approach’. Ongeacht de hoeveelheid breekpunten die je hanteert, werk je van klein naar groot. Een nieuw breekpunt betekent nieuwe media-queries met daarin nieuwe CSS-condities. De praktijk wijst uit dat het vaak alleen een herberekening betreft van breedtes, marges, padding en font-size.
Los van deze workflow neemt front-end ontwikkeling gemiddeld (per template) slechts 15-30% in tijd toe. Zo blijkt uit voorgaande urenrapportages. Afhankelijk van het aantal breekpunten, complexiteit van de templates en de hoeveelheid templates.
In de workflow die wij beschrijven maken we die marge ruimschoots goed. Wij verweven design in de sprints uiteindelijk met de front-end ontwikkeling. De rol van de designer verandert daardoor in de loop van de sprints. Deze krijgt meer een controlerende- en adviesrol.
Minimaal werken wij met 5 breekpunten.
1. Mobiel in portret (maximaal 320 pixels)
2. Mobiel in landschap (minimaal 321 pixels en maximaal 480 pixels)
3. Tablet in portret (minimaal 481 pixels en maximaal 768 pixels)
4. Tablet in landschap & desktop (minimaal 769 pixels en maximaal 1024 pixels)
5. Overig (Minimaal 1025 pixels)
Over het algemeen werken wij met 7 breekpunten.
1. Mobiel in portret (maximaal 320 pixels)
2. Mobiel in landschap (minimaal 321 pixels en maximaal 480 pixels)
3. Kleine tablets zoals de iPad mini en de Kindle in portret (minimaal 481 pixels en maximaal 600 pixels)
4. Tablet in portret (minimaal 601 pixels en maximaal 768 pixels)
5. Tablet in landschap & desktop (minimaal 769 pixels en maximaal 1024 pixels)
6. Grotere desktopschermen (1025 pixels en maximaal 1248 pixels)
7. Overig (Minimaal 1249 pixels)
Een mooi voorbeeld is misschien wel dit prototype (niet geoptimaliseerd voor oudere browsers):
http://bit.ly/RH2u0I
@nielsvanmidden bedankt voor het delen van deze breekpuntenstrategie. Handig om het zo duidelijk te zien. Je stelt: “De praktijk wijst uit dat het vaak alleen een herberekening betreft van breedtes, marges, padding en font-size.” Daar lijkt dan weinig aandacht voor content (first) meer te zijn. Per breekpunt zou je misschien content willen toevoegen, weglaten of herpositioneren.