Omdat het voor steeds meer bedrijven belangrijk wordt dat hun website goed werkt op smartphones, tablets en desktop, neemt de vraag naar responsive design toe. Zo ook bij UNITiD. We zijn betrokken bij een groot aantal trajecten. Een aantal persoonlijke praktijklessen wil ik met je delen.
1. Een responsive design traject duurt langer..
Wanneer we responsive ontwerpen, ontwerpen we voor meerdere schermformaten. In veel gevallen gaan we uit van vier formaten: large (desktop), medium (tablet), small (small tablet) en extra small (mobiele telefoons).
Dit betekent dat eenmaal een pagina ontworpen is, dit ontwerp aangepast wordt naar andere schermformaten. Per viewport wordt de layout geoptimaliseerd, waarbij we in principe de pagina voor elk formaat opnieuw ontwerpen.
Ongeacht dat we ontwerpen met reeds ontworpen content, neemt het optimaliseren meer tijd in beslag dan het ontwerpen van een niet responsive website. Daarbij hebben we het testen en de technische realisatie nog buiten beschouwing gelaten.
2. Gebruikers verwachten dezelfde informatie op verschillende devices
Uit gebruikerstesten en webstatistieken blijkt dat gebruikers ongeacht het device waarop zij kijken dezelfde informatie verwachten. Informatie tonen op desktop maar weglaten op mobiel is not done. Maar hoe maak je content voor ieder device toegankelijk?
Bij UNITiD delen we een ontworpen pagina op in componenten. Daarna hebben we vier opties om per schermformaat te bepalen hoe een component zich gedraagt:
- Show: We laten het component zien zoals het oorspronkelijk is ontworpen.
- Change: Het component wordt aan het schermformaat aangepast. Het component kan ook samengevoegd worden met een ander component.
- Hide: Het component wordt ondergebracht in een dropdown, uitklapmenu, carousel, etc.
- Delete: Het component leent zich niet voor het schermformaat. Laat het weg, maar alleen als er geen andere oplossing mogelijk is.
3. Ontwerp eerst de templates, daarna de componenten
Om het ontwikkeltraject voor een technische partij te vergemakkelijken, is het handig om per component te ontwerpen. Maar om zeker te zijn dat deze componenten binnen een pagina de juiste visuele hiërarchie hebben, is het raadzaam om eerst op templateniveau te ontwerpen.
Je kunt denken dat op componentniveau ontwerpen tijd bespaart, zodat ontwikkelaars alvast dat éne componentje kunnen maken. Later in de ontwikkelfase wordt duidelijk dat dit niet het ideale proces is, en dat het vervolgens aan visuele hiërarchie ontbreekt. Een redesign is dan noodzakelijk, wat aanzienlijk meer tijd kost dan het ontwerpen van een template.
Ontwerp daardoor eerst templates en knip deze op in componenten. Omdat gebruikers pagina’s beoordelen is het raadzaam ook te testen op templateniveau. Het liefst op verschillende browsers en devices om zoveel mogelijk schermformaten af te vangen.
4. Stel per device regels op voor content waar je geen controle over hebt
Doordat content steeds vaker wordt gegenereerd door gebruikers, hebben we er niet altijd controle over. Om content enigszins in goede banen te lijden, raad ik aan per schermformaat regels op te stellen voor worst-case scenario’s.
Worst-case scenario voorbeelden: Over hoeveel regels mag een titel lopen? Wanneer mag deze worden afgebroken? Wat als de tekst niet in een contentblok past? Breken we af met puntjes of vewijzen we verder met een hyperlink? Wat is de maximale tekstlengte in een button? Etc.
5. Begin met het vastleggen van veelvoorkomende elementen in een online styleguide
Binnen een responsive project werken vaak meerdere designers. Om uniform te ontwerpen, raad ik aan om in het begin van het ontwerptraject een styleguide op te zetten. Naarmate het project loopt kan deze worden uitgebreid.
Een styleguide is een handleiding voor designers, wat de identiteit van de klant waarborgt. Hierin worden veelvoorkomende elementen (zoals atomics) vastgelegd; denk aan buttons, linkjes, carousels, pijltjes, scrollbars, promotion stickers, ribbons, ratings, social icons, tooltips, etc. Maar ook layouts, icons, marges, typografie en kleurcodes worden gespecificeerd.
Een styleguide kan het best live coded worden opgezet op een testserver. Zo kunnen stijlelementen online afzonderlijk van elkaar ontwikkeld en getoond worden. Op deze manier maak je voor iedereen alle stijlelementen inzichtelijk. Daarnaast kan inconsequent en foutief gebruik van reeds ontworpen elementen voorkomen worden.
