Responsive design: tips voor het ontwerpproces

De nieuwe hype, maar volgens menigeen een blijvertje: responsive design. De toepassing ervan kent echter nog veel valkuilen, waar wij als professionals angstvallig zand in proberen te gooien. In dit artikel wil ik een aantal van die kuilen vullen met cement, zodat we een goede basis hebben om responsive op te bouwen. 

Workflow

Er klopt een klant bij je aan. Of jij misschien zo’n responsive website voor ze zou kunnen bouwen. Natuurlijk kun je dat, maar de beste manier lijkt nog steeds niet uitgevonden te zijn. Designers zitten met hun handen in het haar, want moeten ze voor iedere schermresolutie nou wel of niet een design maken? Front-end developers weten niet welke resoluties ze nou moeten hanteren en interactiedesigners zien door alle mogelijkheden het grote geheel niet meer voor zich.

Natuurlijk is dit allemaal een beetje overdreven en kunnen de professionals zich in de praktijk allemaal wel redden, maar de heilige graal in de perfecte workflow is nog niet gevonden. Nu kan ik alvast verklappen dat ik die in dit artikel ook niet ga geven, maar ik heb wel wat ideeën over hoe het beter zou kunnen.

Context

Alle artikelen die je leest over responsive design hebben een verwijzing naar context. Vaak komt het er op neer dat de schrijver bang is dat we de context van de gebruiker vergeten. Wat wel jammer is, is dat er bij context al jaren aannames gedaan worden. Gebruik je een desktop computer, dan heb je veel tijd en heb je een goede internetverbinding. In de praktijk zijn er genoeg mensen die met een dongel in een shabby wegrestaurant snel hun mail moeten checken, voordat ze bij een klant arriveren.

Hetzelfde geldt voor telefoongebruikers. De aanname is dat deze gebruikers altijd onderweg zijn en haast hebben en dat ze daarom alleen telefoonnummers of een plattegrond nodig hebben. In de praktijk zit ik zelfs als ik een desktop voor mijn neus heb met mijn telefoon in mijn hand om even mijn mail te checken of een Facebookberichtje te sturen. Ik heb alles behalve haast en heb geen plattegrond of telefoonnummers nodig op dat moment. Daarbij komt nog dat ik gebruik maak van mijn stabiele thuisnetwerk en dus een prima internetverbinding heb. Uit een onderzoek uit 2010 bleek al dat het mobiele gebruik heel anders is dan altijd aangenomen wordt.

Content

Context lijkt dus nogal variabel. Om die reden zou een contentstrateeg onderzoek moeten doen naar de doelgroep. De vraag die het belangrijkste is; wat verwacht de gebruiker wat wil de gebruiker zien op mobiel, tablet, desktop en digitale televisie? Een contentstrateeg gaat ook in gesprek met de klant om te kijken of de wensen van de gebruiker en die van de klant overeen komen. Vinden beide groepen dezelfde dingen het belangrijkste en hoe kan hier een eventuele middenweg in gevonden worden?

Contentchoreografie

Wanneer de content vast staat en er een graad van belangrijkheid aan gegeven is, kan er gespeeld worden met content. In een artikel van Trent Walton vond ik de term contentchoreografie.

Choreografie volgens het woordenboek: cho – re – o – gra` fie beschrijving of aanduiding van de bewegingen van balletten en dansen; danskunst, balletkunst

Content is dus niet meer je oude buurman, maar een gracieuze ballerina die over je scherm danst. Vanaf nu wordt het pas echt interessant, want hoe kunnen we een goede choreografie schrijven voor content? Volgens mij moet dit een samenwerking zijn tussen een contentstrateeg en een interactieontwerper. Interactieontwerpers zien namelijk altijd beweging en opties die ze aan objecten kunnen toekennen. Denk aan een mooie hover of een accordeonmenu. Zij hoeven nu niet meer te denken aan beweging op een van te voren bedachte plek, maar kunnen helemaal los in het creëren van beweging. De contentstrateeg is in dit proces erg belangrijk, omdat hij of zij de graad van belangrijkheid te allen tijde ter harte neemt en in de gaten houdt.

Een interactieontwerper maakt geen wireframes voor een responsive project, maar style tiles waarmee de beweging van de contentelementen duidelijk worden voor de designer en de front-ender. Style tiles zijn duidelijke overzichten van stijlelementen. Niet te vaag zoals een moodboard, maar ook niet te precies, zodat het hele design al vaststaat. Ze zijn daardoor niet arbeidsintensief, maar zijn toch een goede guide voor een designer of een front-end developer en geven bovendien nog creatieve ruimte.

Voorbeeld van een style tile. Bron: http://styletil.es/

Design en front-end

Nadat de contentstrateeg en de interactieontwerper hun werk hebben gedaan, komen de designer en de front-end developer in beeld. Zij zullen binnen dit project ook een nauwe samenwerking hebben. De front-end developer kan al meteen aan de slag met de style tiles van de interactieontwerper. De website kan eigenlijk al in z’n geheel opgebouwd worden. Alle content-blokken zijn namelijk al bepaald en de choreografie is duidelijk.

De designer neemt ook de style tiles van de interactiedesigner en ontwerpt een flexibele lay-out voor ieder content-blok. Een designer ontwerpt geen complete website meer, maar ontwerpt ieder content-blok individueel. De complete website vormt zich vanzelf als de front-end developer alle styles aan zijn script heeft toegevoegd. Iedere professional moet zichzelf al twee stappen voor zijn in het proces. De uitdaging binnen het proces, is dat iedereen hetzelfde eindresultaat voor ogen heeft en de klant weet wat het uiteindelijk gaat opleveren. Er is geen ontwerp, het ontwerp is pas klaar als de website klaar is.

Werkwijze & communicatie

Een klant overtuig je niet meer met design, maar met kennis. Om die reden is de communicatie tussen het team van professionals en de klant zo belangrijk. Dit proces zie je ook terugkomen in de scrummethode. Bij de scrummethode wordt er gewerkt in een multidisciplinair team. Een project wordt opgedeeld in periodes van een aantal weken, ook wel sprints genoemd. Het voordeel van de scrummethode is dat er als één team intensief gewerkt wordt. Alle problemen, maar ook alle successen, zijn bekend. Hierdoor kan een goede teamspirit ontstaan.

Ook zou er gekozen kunnen worden voor een iteratieve werkwijze. In een iteratief proces worden alle stappen herhaald en uitgevoerd om tot het gewenste resultaat te komen. Hierin is er ruimte om dingen uit te proberen, zo kom je met z’n allen tot een goed eindproduct. Proberen, vallen, leren en doorgaan. Welke methode je ook kiest: GO RESPONSIVE, GO!

Interessant?

Lees dan ook onze andere artikelen over , , , , , , , , , , , .

Reacties

  1. Noraly,

    interessant artikel.

    Er is trouwens nog een andere definitie van “responsive design”. Gebruikt irt mobile marketing en m-business: “What is a ‘responsive design’ for smart consumers?” Klik hier: http://ow.ly/a4Hy6 .

    Succes met je afstuderen!

    Tony de Bree
    Twitter: @tonydebree

  2. @Tony de Bree – Dankjewel voor je reactie. Met dat afstuderen komt het denk ik wel goed!

  3. Zeker geen hype. Ik zou het meer voortschrijdende ontwikkeling willen noemen. Must-read voor iedere web developer: http://www.abookapart.com/products/responsive-web-design

    Zo moeilijk is het niet… ;-)

  4. Wat je hier in feite zegt is dat je naast de vormgeving met ‘responsive design’ ook de context moet ‘besturen’ met ‘responsive content’.

    Interessant!

    Peter

  5. @Chantal – Fijn dat er medestanders te vinden zijn. Zelf denk ik dat Ethan Marcotte inderdaad een goede voorzet geeft, maar dat er nog heel veel en beter over nagedacht kan worden om het juiste fundament te hebben voor grote en complexe projecten.

    @Peter Luit – Ja inderdaad zoals Trent Walton ook al een tijdje aanhangt en Sara Wachter-Boettcher het een en ander over geschreven heeft in haar artikelen Future-Ready-Content en Responsive-ready-content is het belangrijk dat we niet alleen kijken hoe we onze design elementen goed Responsive krijgen, maar ook kijken naar de perfecte content choreografie.

  6. @Peter, klopt. Sommige content is voor mobile devices minder interessant dan voor bezoekers die via desktop komen. Bijv een winkel, iemand die via smartphone op bezoek komt zal eerder openingstijden en of een adres/telefoonnummer willen zien.

  7. @Chantal – Daar ben ik het jammer genoeg niet mee eens. Daar worden te veel aannames in gedaan. Het komt namelijk geregeld voor dat ik op de bank een website check en dan wil ik geen telefoonnummers of plattegrond, maar gewoon snel kijken hoe duur een specifieke jurk is die ik in een reclame heb gezien.

  8. @noraly klopt het echter dat verreweg de meeste ontwikkelingen (op dit moment) zich nog ‘beperken’ tot het ‘design’ op basis van resoluties/schermen en veel minder op ‘responsive content’? Zou je van dat laatste voorbeelden kunnen noemen, die ‘demotechnisch’ te tonen zijn?

  9. @Noraly meestal staan die aanbiedingen niet op een website of met behulp van een folder die Flash player gebruikt. Die zijn sowieso bijna nooit responsive. Afgezien van het feit dat Flash player zowat dood is nu Adobe al heeft aangekondigd te gaan stoppen met een mobiele versie.

  10. @Peter – Zelf prefereer ik het Mobile First programmeren. Dit zou je zelf nog een stap verder kunnen trekken naar content first programmeren. Je begint kadert eerst alle content af, dus je begint niet meer met dummy tekst. Dan kan het spelen met de content beginnen op de verschillende schermen. Op het moment ben ik bezig met het maken en zoeken van tools om dit op een zo natuurlijk mogelijk manier te doen.

  11. @Peter goed voorbeeld is Smashing Magazine. http://www.smashingmagazine.com/ Verklein je browser maar. Kennelijk zijn advertenties tonen (aan rechterkant) niet van belang voor mobile devices.

  12. @chantal: ja, dergelijke voorbeelden zijn echt heel mooi, maar toch is ook dit voorbeeld gericht op het ontwerp. Als ik goed heb gekeken, zie ik de content als zodanig niet veranderen. Klopt dat?

    Overigens gebruik ik binnen WordPress een paar WooThemes, die dit soort zaken ook redelijk netjes afhandelingen, echter nog niet perfect. Daarnaast aalleen gericht op design en niet op responsive content, althans voorzover ik nu heb geleerd en ervaren…. #wieweetmeer

  13. @Chantal en Peter – Als je vanuit Mobile First denkt, is je content teruggebracht na het belangrijkste voor zowel je gebruiker als voor de klant. Vanuit daar ga je dit uitwerken naar desktop. Als je het goed aanpakt hoef je niks bij te voegen. Ik denk dat Smashingmagazine niet het beste voorbeeld is, dat ze de advertenties weghalen naar mobile komt meer door de zwaarte ervan. Het is wel goed dat ze zich dat realiseren.

  14. Responsive content als je daarmee bedoelt: pas de manier waarop content wordt geladen aan aan de bandwidth van je bezoeker : eens !

    Maar niet als het betekent: we gaan andere info serveren op basis hiervan.
    Uiteindelijk is er maar één website, en als je mensen 1. gaat helpen (maar ook verwarren) met een andere interface, zorg er dan 2. tenminste voor dat de content die ze gewend zijn te vinden op je website ook te vinden is.

    Leg idd de focus op kerntaken ipv pakweg op “de historiek van ons bedrijf”, maar verstop het ook niet, want jij kan niet gokken wat je mobiele bezoeker komt doen op je site. En die mobiele bezoeker zit mss ook gewoon over een snelle WiFi verbinding thuis in z’n zetel met smartphone of tablet, en wil gewoon ook die 10MB PDF binnenhalen die hij laatst zag op je site..

    In dat laatste geval, dat heb ik al meegemaakt, dat een link naar een PDF werd weggehaald “want dat heeft iemand met een smartphone niet nodig”… Ja-wél !!

    Denk er goed over na.

    “If you’re gonna hide stuff on your mobile (rwd) website, why was it there in the first place”.

    grtz,
    ToM.

    ps: heb er pas een presentatie over gedaan op WordCampNL, maar is applicable voor alle platformen, vermits front-end technology. Linkie: http://www.slideshare.net/tomhermans/responsive-webdesign-wordcampnl-2012

  15. @Peter op een komende WordPress Meetup in Rotterdam, wil ik hier meer aandacht aan besteden. Teveel WordPress admins wijken te snel onnodig uit naar plugins als WPtouch e.d. Jammer!

  16. @tom: dus jij zegt expliciet dat je geen verschillende ‘inhouden’ (langer – minder kort – kortst) moet aanbieden op basis van devices/resoluties/schermen?

  17. @chantal: ook ik heb op vele sites WPTouch draaien. Maar met de komst van RD Themes, begin ik daar wel anders over te denken……

  18. @Tom – Helemaal mee eens. Ik ben een sterk voorstander van zelfde informatie op alle formaten. Ik denk dat dat juist het sterke punt van Responsive Design is.

    Door goede content choreografie verdwijnen belangrijke punten (die mogelijk normaal in een sidebar staan) niet helemaal onderaan een contentblok zoals je nu vaak zit gebeuren op mobiel.

  19. @noraly: ok, dus mijn eerdere stelling is dus niet juist? Dat je ook content moet aanpassen op basis van scherm eigenschappen?

  20. @Peter – Aanpassen als in een goede content choreografie bieden ja. Andere of kortere content bieden nee.

    Als je mobile first je content bekijkt heb je hapklare blokken tekst. Ik heb toevallig Sara Wachter-Boettcher geïnterviewd hierover. http://youtu.be/bPAamdlwQ94 – misschien interessant om haar standpunten eens te horen. Ze noemt een paar heel goed voorbeelden van hoe het volgens haar niet moet.

  21. We zijn op dit moment bezig een aantal responsive website’s te ontwikkelen en ontwerpen. Er is veel over te vinden maar inderdaad een best case scenario voor het proces is er nog niet echt. Interessant dat hier nu eens aandacht aan besteed wordt.

    Ook wij hebben de eerste projecten volledig in alle resoluties ontworpen. Veel tijd en achteraf onnodig. Hoop hierover meer ervaringen / cases te lezen in de nabije toekomst.

  22. @bart – Interessant! Ik ben op zoek naar professionals die bijzondere bevindingen hebben binnen dit gebied en misschien willen meedenken hierover. Mocht je interesse hebben stuur even een mailtje of contact me via twitter, misschien kunnen we wat voor elkaar betekenen en kan ik vertellen over het project waar ik nu aan werk.

  23. @noraly: ik maak gebruik van RD Themes bij WordPress, ik doe testen met PageLines een WooThemes en beiden doen interessante dingen. Wat ik wel merk is dat met name plugins wel eens een nadelige invloed kunnen hebben op het RD aspect, waardoor niet elke webpagina even vriendelijk reageert. Maar tot nu toe zijn de resultaten veelbelovend en klanten zijn uitermate tevreden. Zoals @chantal al meldde werd en wordt er nog veel gebruik gemaakt van WPTouch binnen WordPress. In feite voegt die plugin een geheel eigen theme toe voor andere devices/resoluties en valt dus niet binnen RD.

    Als je meer wilt weten, ik ben graag bereid je verder te helpen, alhoewel ook ik een beginner ben in dit spannende traject.

    Peter

  24. @noraly: net naar Sara Wachter-Boettcher gekeken. Ik moet het dus echt een tweede keer doen, want ik verloor mijn aandacht na een kwartier. Is dit verhaal niet te algemeen, te zoekende? Of mis ik de boodschap die zij wil verkondigen?

  25. - Een interactieontwerper maakt geen wireframes voor een responsive project, maar style tiles waarmee de beweging van de contentelementen duidelijk worden voor de designer en de front-ender. Style tiles zijn duidelijke overzichten van stijlelementen. –

    Ik ben het helemaal met je eens dat je niet alle formaten kunt ontwerpen, en dat het ontwerp pas klaar is als de website af is.

    Maar het is wel erg onlogisch dat een pure interactie ontwerper, die normaal zwart/witte wireframes maakt, nu style tiles zou moeten maken binnen een responsive design project. Het lijkt mij eerder voor de hand liggend als een visueel ontwerper dit zou maken.

  26. @wendy: ja, dat speelt inderdaad ook nog eens een belangrijke rol: wie doet wat met welke competenties? Zou graag meer willen weten over de splitsing van taken die al dan niet ten gevolge van deze ontwikkeling gaat plaatsvinden.

  27. Het is duidelijk dat regie veel belangrijker is geworden. Dat betekent voor de klant ook een veel grotere taak, veel duidelijker kiezen welke content op welke wijze je presenteert. Voor kalnten zal het veel meer aandacht vragen omdat inhoud/redactie fexibeler toegepast worden.
    Technische mogelijkheden zullen snel toenemen, de complexiteit voor de klant is waar een meer fundamente verschuiving in denken ligt.

    Voor veel klanten wordt de bedrijfs strategie als anker in keuzes alleen maar belangrijker.

  28. Hoi Noraly,
    Je geeft aan dat er geen compleet design zal zijn. (“Er is geen ontwerp, het ontwerp is pas klaar als de website klaar is.)”. Bedoel je dat je geen complete screens gaat maken in het traject? Zo ja, dat lijkt mij niet realistisch. Mijn ervaring is dat het heel belangrijk is in internet projecten om zo snel mogelijk een versie van het eindplaatje voor de gebruikers te maken. Dit als input voor concept testen en om beslissers te kunnen betrekken. Ik zou zeggen minimaal een versie homepage voor de website en voor een generieke smartphone.

    Verder compliment voor het artikel; naast goede inhoud leest het ook erg makkelijk weg!

  29. Een relatie van mij in Rotterdam – Mangrove – gebruikt de SCRUM methode. Zijn er anderen die hiermee ervaring hebben? En zou dat goed passen in de rolverdeling van dit soort ontwikkelingen?

  30. Lennaert, dit is helaas ook mijn ervaring, daarom is het denk ik des te belangrijker om de klant ook te overtuigen van de enorme voordelen, gelukkig is het steeds gebruikelijker om in pitches en concept fases al mockups te presenteren, de tooling op IA gebied word hier ook steeds handiger in.

    En Noraly uistekend artikel van je :)

  31. @Wendy – Ik denk dat een designer dit ook zou kunnen doen. Een interaction designer neemt wel de template van een style tile en bedenkt alle interactie en verschuivingen van alle content elementen.

    @Sibren – Bedankt voor je visie! Ik denk inderdaad dat er een grote verschuiving plaats vindt ook bij de klanten.

    @Lennaert – Ik snap dat het een probleem gaat worden in het overtuigen van een klant. Ik denk persoonlijk dat klanten altijd verwend zijn. Web staat niet gelijk aan print. Wij hebben web altijd wel behandeld als print. Open een canvas met Photoshop, beslis op welke afmeting je gaat vormgeven en gaan. Klanten weten al vroeg in het proces wat er uiteindelijk ‘geprint’ gaat worden online. Ik denk door dat alles flexibel wordt je dat niet meer kan doen. Schetsen met interactie en style tiles zijn het nieuwe startpunt en het nieuwe punt waar klanten op akkoord gaan of niet. Je moet je klant van te voren duidelijk maken dat Responsive ‘messy’ is. Als je de scrum methode gebruikt is een klant zo nauw betrokken binnen je proces, dat dit geen problemen zou moeten opleveren.

    @Peter – Ik weet toevallig dat Tam Tam al een flinke tijd helemaal overgestapt is op Scrum. Bij Mirabeau zijn er een aantal projecten die we via scrum aanpakken.

    @Sjors – Bedankt voor je visie!

  32. “Een interactieontwerper maakt geen wireframes voor een responsive project, maar style tiles waarmee de beweging van de contentelementen duidelijk worden voor de designer en de front-ender. Style tiles zijn duidelijke overzichten van stijlelementen.”

    Waarom zou een interactie ontwerper een style tile moeten maken?

    “Style Tiles are a design deliverable consisting of fonts, colors and interface elements that communicate the essence of a visual brand for the web.”

    Dat is de taak van de vormgever, die gene die verantwoordelijk is voor de beeldtaal van een interface. Een interactie ontwerper is verantwoordelijk voor de interactie tussen de gebruiker & interface. Natuurlijk met de opkomst van UX design worden de grenzen steeds meer vaar, maar je moet niet verwachten dat jouw interactieontwerper met style tiles gaat komen :(


    Check even de Boston Globe redesign, en hoe zij dat hebben aangepakt. Daar zitten veel goeie tips in:
    http://upstatement.com/blog/2012/01/how-to-approach-a-responsive-design/
    http://filamentgroup.com/lab/introducing_the_new_responsive_designed_bostonglobecom/

  33. Leuk artikel. Zag van de week een soortgelijk artikel voorbij komen in de tweets van een bekende designer. Meer goede info voor mensen die hier meer van willen weten:
    Style Tiles as a Web Design Process Tool
    http://badassideas.com/style-tiles-as-a-web-design-process-tool/

  34. Hoi Noraly,

    allereerst wil ik zeggen dat RWD (Responsive Web Design) geen hype is, maar stiekem een voortzetting is van onze fluid tabelletjes uit de jaren ’90!

    RWD is redelijk gedefinieerd door Ethan Marcotte en heeft 3 (technische)eigenschappen:

    1. fluid/elastische grid
    2. media queries in CSS (o.a. max-width)
    3. fluid/elastische content/afbeeldingen

    Het uitzetten (het niet tonen) van content/afbeeldingen middels display:none in de verschillende media-queries is dus nooit de bedoeling geweest bij RWD (briljant uitgelegd door @Tom!).

    RWD staat nog redelijk in de kinderschoenen omdat we nog niet voor alles een oplossing hebben .. oplossingen die overigens gebasseerd zijn op JavaScripts, polyfills of andersoortige zaken zijn NIET responsive, hooguit adaptive of mobile friendly (verwar een masonry jQuery dus nooit met RWD – want de afbeeldingen zijn niet fluid gemaakt en er wordt ook geen gebruik gemaakt van CSS media-queries!)

    Persoonlijk bij het maken van RWD’s vind ik het omschakelen van je workflow (mobile first), het goed invullen van een contentmanagement (inderdaad, briljant artikel van Trent) en het juist triggeren van de media-queries (maw. plaats je de breakpoints in je CSS op basis van devices of op basis van je ontwerp?) de belangrijkste aandachtspunten bij RWD.

    Dat wireframes niet handig zijn bij de development van RWD is een feit, Style Tiles is een leuke tool maar ik heb gemerkt dat pen en papier nog steeds de beste hulpmiddelen zijn (ook als preso naar de klant).

    Maar waar ik absoluut geen voorstander van ben is om content op het ene device wel te tonen en op een andere niet. Als je dat doet heb je waarschijnlijk een slechte benadering van je contentmanagement gekozen en ontgaat je het hele principe van RWD! .. Niet doen dus!

    Zowiezo als je content ‘blocked’ op bijv. mobiel wordt diezelfde content wel geladen (content wordt alleen niet getoond) en heb je dus alsnog een lange loadtime voor je mobiel, .. en met 25kB/sec wordt je dan niet echt blij!

    RWD biedt webcontent altijd en op ieder apparaat met een optimale gebruikservaring, dus zonder verlies aan functionaliteit én content[!].

    En dan heb ik het niet eens gehad over het gemak van RWD aangaande het ‘onderhoud’ (je hebt namelijk maar 1 site, ipv een desktop en een mobiele versie – 2 verschillende sites), een betere SEO vanwege HTML5 microdata etc, omdat het gewoon een UX-orgasme is, etc., etc.!

    De redenen waarom ik mijn bloggie responsive heb gemaakt kun je nalezen op de gonzoblog [in het engels].

    Met responsive groet ..

  35. Sven van de Scheur |

    Interessant artikel, toch heb ik er wel wat opmerkingen over:

    Ten eerste noem je style tiles, hoewel style tiles zeer nuttig kunnen zijn lijkt het mij handig om dan vooral in de richting van een style guide te werken waar de cruciale elementen worden vastgelegd (wellicht met mobiele varianten). Deze kan de front-end developer dan gebruiken om zelf oplossingen te zoeken.

    Daarnaast beweer je dat je een klant niet meer overtuigt met design maar met kennis, dat kan kloppen maar toch denk ik dat een klant van te voren wil zien wat er gemaakt wordt zodat hij of zij er een beeld bij kan vormen. Er kan dan bijvoorbeeld uitgegaan worden van drie versies die de klant te zien krijgt: mobiel, tablet en desktop. Deze versies hoeven natuurlijk niet definitief te zijn maar dienen vooral ter indicatie.

    Momenteel ben ik ook bezig met een afstudeeronderzoek naar responsive design en ben ook op zoek naar goede ontwikkelmethode. Het lijkt mij echter dat hierbij het beste naar meer gekeken kan worden dan responsive design alleen.

    Ik denk dat huidige werkwijzen vaak problemen kunnen geven bij het ontwikkelen van responsive websites, dit heeft verschillende oorzaken.

    Ten eerste is er het workflow aspect, vaak gaat alles eerst via de designer die de touwtjes in handen heeft als het gaat om de look and feel. Vervolgens wordt het bij de front-end developer neergelegd die alles moet uitwerken en elke design afwijking moet voorleggen aan de designer.

    Ik denk dat dit geen handige situatie is voor responsive websites. ik denk dat front-end developers vaak beter een inschatting kunnen maken van hoe webpagina’s reageren en eventueel aan de hand van een style guide (of style tile) misschien beter zelf een oplossing kunnen zoeken, het is natuurlijk wel belangrijk dat usabillty voor de verschillende apparaten gewaarborgd blijft.

    Daarnaast is er het technisch aspect. Het is vaak wenselijk in webdesign om html CSS en JavaScript uit elkaar te houden. Dit gebeurd meestal ook maar vaak wordt er nog te weinig gekeken naar de reden waarom dit gedaan wordt. Een artikel hierover is te vinden op

    http://dev.opera.com/articles/view/4-the-web-standards-model-html-css-a/

    waar ook wordt uitgelegd dat het uit elkaar halen van HTML, CSS en JavaScript ook kan bijdragen aan het beter optimaliseren van webpagina’s voor mobiele apparaten.

    We kunnen veel flexibeler te werk gaan op het moment dat HTML, CSS en JavaScript goed uit elkaar gehaald zijn. Ik denk dat een goed startpunt voor een front-end developer het uitlezen van de (voorbeeld) content van een ontwerp is. Deze kan vervolgens gestructureerd worden in HTML zonder te kijken naar de opmaak. Op deze manier ontstaat er hopelijk een puur structurele HTML zonder overbodige elementen. Vervolgens moet dit afhankelijk van het media gestyled worden.

    Een paar tips hiervoor:

    - Voorkom zoveel mogelijk HTML tags ten gunste CSS (bijvoorbeeld wrapper divs.

    - Gebruik zoveel mogelijk HTML5 tags zoals section en article.

    - Ik denk dat we er van uit moeten gaan dat elke (inhoudelijk niets zeggende) (div) tag er een te veel is.

    - Maak gebruik van media queries in CSS en ga uit van progressive design (mobile first). Breidt de styling uit per platform.

    - Vergeet interactie niet.

    Als je HTML code puur gebruikt voor het structuren (dus niet formatteren) van opmaak en je CSS gebruikt om deze, al dan niet platform afhankelijk op maken kun je al vrij eenvoudig een responsive geheel opzetten. Met behulp van JavaScript kunnen we de responsive ervaring uitbreiden (denk met name aan interactie).

    In de periode die ik al aan mijn onderzoek heb besteed ben ik er achter gekomen dat er erg veel mogelijk is maar dat er ook nog de vraag is hoe ver je moet en wil gaan. Kan responsive design zelfs storend werken op het moment dat je continu van content wisselt?

    Ik ben er nog niet uit maar ik houd de trends in de gaten.

  36. @Sven,

    Het loskoppelen van de content (HTML), de visuele presentatie (CSS files) en Javascript (evt. interactie of functionaliteit) is niet iets wat typisch bij RWD hoort.

    Dit is al de laatste 5 jaar redelijk gebruikelijk om te doen ..! Alleen al vanwege het SEO (o.a. loadtime, betere indexatie, etc) aspect, is dit zwaar aan te raden (ondanks het feit dat er een paar extra http-requests bijkomen om dit voor elkaar te krijgen)!

    Hierdoor is het namelijk ook veel makkelijker om een site te onderhouden en/of aan te passen en kan de CSS nu bijvoorbeeld ook gecached worden (wordt een stuk lastiger met inline CSS!).

    Gelukkig is mijn workflow een stuk makkelijker dan die jij beschrijft ;-P Ik ben namelijk de designer, front-end designer én back-end developer in één!

  37. @gonzo

    Dat weet ik maar toch gaat de uitwerking ervan bij wijze van spreken vaak niet verder dan floats toepassen op div tags die zijn aangebracht puur voor 1 bepaalde opmaak, naar mijn mening niet correct en ik denk dat het responsieve design in de weg kan zitten. Slimmer css kan het proces denk ik zeker wel versnellen…. (los van de rest)

  38. Hoi Noraly

    Leuk artikel, goede insteek ook om te kijken naar wat het met het proces doet.

    Je nuancering van het belang van context is me uit het hart gegrepen. Daarom ben ik juist zo voor responsive design: je weet niet waar iemand op zijn mobiel of tablet wel of geen behoefte aan heeft, dus zorg dat iedereen op alle devices alles kunnen bereiken.

    Over de ‘messy’ projectaanpak die je voorstelt:
    Ik zie style tiles inderdaad goed werken binnen scrum. Of nog beter gezegd binnen 1 sprint. Want bij de demo moet je de stakeholders toch complete pagina’s laten zien om te zorgen dat je door kan.
    Buiten scrum zullen style tiles doorgaans onvoldoende zijn om opdrachtgevers mee te krijgen. En helaas, niet iedere opdracht leent zich voor scrum, o.a. door zeer democratische of juist zeer formele opdrachtgevers (meer hierover in dit artikel van mijn collega Pieter Jongerius: http://www.frankwatching.com/archive/2010/12/27/agile-design-scrum-de-mythes-de-faq/)

    We zijn bij Fabrique bezig met een aantal mooie responsive projecten, zodra die live zijn deel ik de inzichten graag hier.

  39. Interessant artikel over responsive design. Leest lekker weg en geeft een goed inzicht. Alleen de afsluiting van het artikel vind ik jammer. Het lijkt erop alsof SCRUM wordt weggezet als een opgeknipte waterval en dat SCRUM losstaat van iteratief werken. Juist Agile is gebaseerd op iteratief werken. En wat zijn de valkuilen, voordelen van integreren van responsive design in een agile methode?

    Daarnaast is het dan volgens mij juist de praktische uitdaging om ook de klant het (zelfde) eindbeeld voor ogen te laten hebben. Hoe wordt hiermee omgegaan? Je zegt immers “Er is geen ontwerp, het ontwerp is pas klaar als de website klaar is.” Verwachtingsmanagement en Responsive Design, gaat dat op deze manier samen?

  40. Ik denk dat de rolverdeling van de verschillende taken binnen dit soort processen niet heel makkelijk in één fomat is te vangen. Volgens mij zijn de doelstellingen bij de ontwikkeling en bouw van dergelijke projecten zo verschillend, dat per keer de juiste methode zal worden gekozen.

    De afbakening tussen taken als:

    - user interface design
    - grafisch ontwerp
    - database management
    - programmeren
    - content creatie
    - interactie

    is groter of kleiner naarmate de omvang van het project. Ook traditionele methoden in het voortraject, zoals vooronderzoek, functioneel- en technisch ontwerp zie ik tegenwoordig niet meer als vaststaande feiten voorkomen in elk traject.

    Daarnaast is onder invloed van (grotere) opensource CMS omgevingen heel veel te ‘verkrijgen’ als templates/themes, waarbinnen als het ware wordt ontworpen binnen een gegeven ontwerp. Ook dat aspect is een bijzonder gegeven, zeker voor ontwerpers die traditioneel vanaf een ‘wit’ scherm hun begin willen maken. Afhankelijk van het te realiseren project wordt dat wel of niet gekozen.

    Responsive Design is een voorziening om websites op meerdere typen schermen op juiste wijze weer te geven, teneinde het communicatie effect in al die omgevingen te maximaliseren. Die voorziening heeft dus kenmerken van techniek, creativiteit en communicatie.

    Binnen project management methoden (welke je ook kiest) zal ook deze voorzineing een plekje krijgen binnen het gehele proces. Rest mij op te merken dat de eerder genoemde afbakening in mogelijke taken minder wordt naarmate nieuwe vakspecialisten de markt zullen betreden. Het valt mij op dat deze nieuwe generaties steeds vaker en steeds makkelijker meerdere disciplines beheren en beheersen. Het opknippen in vakgebieden is iets wat wij als mensen graag doen om het omspanningsvermogen van mensen in de hand te houden, zeker in bedrijven met complexere en/of grotere organisatie structuren.

    Overigens waardeer ik deze discussie hier zeer zeker. Een blogpost die binnen een dag al enkele tientallen reacties laat zien rondom dit onderwerp is een genot om te lezen en aan mee te doen.

    Toen de term SCRUM werd genoemd werd de discussie breder dan misschien in het artikel bedoeld. Maar ik heb ervan genoten en wederom veel geleerd. Veel dank!

  41. @Gonzo the great – Fijn een medestander. Ben zelf ook van mening dat het geen hype is namelijk.

    Met het plaatsen van alle content op alle apparaten ben ik het absoluut eens! Jammer genoeg wordt dat nu vaak niet gedaan.

    Het schetsen van interactie is zoals ik al in een eerder comment aan gaf een goede methode voor een Interaction designer.

    @Sven van de Scheur – Het probleem bij designer, zelfs als het een draft is, is dat het veel tijd kost. Ik denk dat het juist van belang is dat er eerst wordt bekeken wat er voor content elementen op de website moeten komen. Ik denk niet dat je de klant drafts moeten laten zien, maar eerder voorbeelden van wat je al hebt opgeleverd, zodat ze ongeveer weten wat ze kunnen verwachten.

    Leuk dat je ongeveer dezelfde insteek hebt qua afstuderen als ik. Ik probeer responsive Design ook ruimer te zien dan alleen hoe je het uitvoert, vandaar ook dit artikel over workflow binnen het Responsive proces. Ik hou me nu bezig met content en context.

    @martijn – super interessant. Ik ben juist op zoek naar professionals die geïnteresseerd zijn in dit onderwerp. Momenteel ben ik bezig met een project om Responsive Design in alle opzichten aan te pakken en te verbeteren, mocht je meer willen weten, stuur dan even een mailtje. (noonk at mirabeau dot nl)

    @Bram – Scrum is alles behalve een opgeknipte waterfall. Het is veel intensiever en er komen veel beter en samenhangende projecten uit wat mij betreft. Zelf denk ik eigenlijk juist dat Srum uitstijgt boven waterfall en iteratief werken. Het punt van dat de klant moeilijk te overtuigen is valt in een scrum methode erg mee volgens mij. In de scrum methode zie je geregeld dat de klant een volwaardige plek in het scrum team inneemt en zich echt deel van het proces voelt en het product ziet groeien. Dat is juist de kracht.

  42. Sven van de Scheur |

    @Noraly

    Ik vind dat je gelijk hebt op je punt dat je moet kijken naar individuele elemenenten, ook omdat deze naar mijn mening verschillende soorten interacties moeten ondersteunen (denk bijvoorbeeld aan touch). Maar toch vind ik ook dat je de klant vanaf het begin iets moet kunnen laten zien. Dat hoeft natuurlijk niet een vast design te zijn maar kan wel een streven zijn hoe het er onder gegevens omstandigheden uit kan zien.

    Ik richt mijn afstudeeronderzoek ook op interactie van responsive design, afhankelijk van context.

  43. Interessant artikel Noraly, die ook veel discussie losmaakt. Wij zijn onlangs ook begonnen met het responsive maken van onze eigen website. In tegenstelling tot wat ik in veel van de reacties lees hebben wij niet voor alle resoluties apart ontworpen. Bij ons was het veel meer een proces van gaandeweg doordenken over de mogelijkheden om kleinere schermresoluties.

    Het helpt dan wel als je het project scrum aanpakt, want nog meer dan in een ‘normaal’ project verandert er veel. En een verandering werkt meteen door naar meerdere resoluties, dus dit heeft ook meteen meer impact.

    Ik geloof wel dat responsive de toekomst is en dat we op zoeken moeten naar wen best case scenario om deze projecten aan te pakken. Ik ben benieuwd naar je onderzoek!

  44. Dank voor je artikel, Noraly. We denken erg in dezelfde lijn, merk ik. Leuk! Onlangs hebben mijn collega Niels van Midden en ik een workflow/aanpak voor het responsive web op hoofdlijnen uitgewerkt. We verwachten daarover volgende week een artikel te schrijven voor Frankwatching, dat dan de week erna zou moeten verschijnen.

    Eén major issue waar ik voortdurend tegenaanloop, is dat de meeste ‘experts’ zeggen dat de ‘mobile context’ niet bestaat. Hoewel ik hun redenering volg, ben ik het er ook niet helemaal mee eens. Daarmee pleit ik geenszins over wat Jakob Nielsen onlangs uitte, maar ook zíjn denken snap ik.

    Natuurlijk is er het dilemma ‘on the go’ versus ‘on the couch’, en natuurlijk kun je niet voorspellen wat de context van een mobiele bezoeker is. Maar je kunt wel op z’n minst een educated guess doen, én je kunt toetsen welke taken (en dus welke content) op mobiel, tablet en desktop belangrijker zijn. In veel gevallen zullen de verschillen nihil zijn, maar ik kan ook wel voorbeelden bedenken waar de taken voor verschillende context/devices flink kunnen afwijken.

    Daarover dus binnenkort meer… :-)

  45. @Christaan W Lustig – Bedankt voor je reactie. Context is inderdaad bij veel mensen een dingetje. Ik ben op het moment druk bezig om een landelijk onderzoek te doen naar internet en apparaat gebruik dat veel moet gaan opleveren wat context betreft. Zo kan je (mocht dat volgens de resultaten nodig zijn) gaan spelen met je content strategie en het weergeven van elementen op een bepaald moment.

    Ik denk dat je dit soort dingen alleen kan verdedigen door gedegen onderzoek. Vandaar dit initiatief. Ik ben op dit moment van mening dat je op ieder moment dezelfde content zou moeten laten zien of vinden. Voor zowel u als mijn mening zou dit onderzoek een onderbouwing kunnen vormen. Nu zit ik nog in de testfase van het onderzoek, maar ik hoop dat ik het snel kan starten.

    Ben erg benieuwd naar uw artikel.

Plaats een reactie

Je e-mailadres wordt niet gepubliceerd. Verplichte velden zijn met een * aangegeven.

Verschijnt je reactie niet, dan is deze mogelijk in de spam terechtgekomen. Mail ons dan even!