Beperkte content voor mobiel? Nee, contentstrategie!

Iedereen wil (of heeft al) een web presence op mobiel. Maar velen weten niet goed hoe ze dit moeten aanpakken. Wat stoppen we wel en niet in de mobiele site? Moeten we geen app? Een losse site of een responsive site? Karen McGrane, gerespecteerd contentstrateeg, gaf op de IA Summit een hele dag haar recept voor een contentstrategie voor mobiel. Of liever, zo bleek, de plaats van mobiel in een goede contentstrategie.

Stop met het doen van aannames

Het idee dat mobiel internetten vooral in ‘onderweg’-situaties gebeurt, is achterhaald. Een grote groep mensen benadert het web primair via mobiel – onderweg, thuis en op werk. Voor een deel van de bevolking biedt hun mobiel zelfs de enige toegang tot het web.

“If you stuff isn’t on mobile, it doesn’t exist for all these people.” – Karen McGrane

De ‘mobiele context’ bestaat niet. Schermgrootte is geen context. Mobiel, tablet en desktop lopen door elkaar heen. 90% van de mensen start een taak op het ene apparaat en voltooit de taak op een ander apparaat. Dus.

Zorg voor contentpariteit

Voordat je allerlei wilde mobiele producten en concepten bedenkt, zorg eerst dat al je content beschikbaar is op alle omgevingen (=contentpariteit).

Jakob Nielsen, de grootvader van usability, adviseerde compleet het tegenovergestelde afgelopen jaar:

Vergeet dit advies

Thanks Jakob! Vergeet dit advies. Maak geen mobiele site als ‘lite’ versie van de desktop-site. Beperk niet de toegang tot content via mobile devices en creëer geen content voor een specifieke schermresolutie of platform. In de realiteit zal dit niet altijd haalbaar zijn – bijvoorbeeld met grote tabellen of infographics – maar het moet wel het uitgangspunt zijn.

“A link to the full desktop website is a terrible user experience.”- Karen McGrane

Afgezien van het achterhaalde idee van ‘mobiele context’ kleven er nog meer nadelen aan een losse ‘lite’ mobiele site:

• Redirects lopen vaak in de soep. Stel iemand deelt via Twitter een link. Je klikt erop, maar de webserver herkent je mobiele browser en stuurt je naar de mobiele homepage in plaats van naar het artikel. Of iemand deelt via zijn mobiel een link. Je klikt erop en voor je het weet kijk je op je desktop naar de mobiele weergave van het artikel.
  

  “If a user can get to a page on the desktop, they should be able to access the same URL on their mobile.” – Brad Frost

• Hoeveel sites moet je maken om alle soorten en maten van ‘viewports’ te ondersteunen? Je komt niet meer weg met een desktop-, een tablet- en een mobiele versie. De werkelijkheid is veel complexer. Ga je ook een aparte versie maken voor smarttelevisies, game consoles, et cetera?
• Losse sites met niet-identieke content betekent extra contentbeheer-inspanning en risico op uit de pas lopende content. A governance disaster waiting to happen.

“It’s not a strategy if you can’t maintain it.” – Karen McGrane

Mobiele content ≠ lokale content

Stel je loopt naar het treinstation, dan wil je heel snel de vertrektijden, storingen en reisplanner kunnen benaderen. Als je in een pretpark loopt, dan wil je het snelst de plattegrond en voorzieningen zien. Dit zijn reële use cases. En terecht dat je deze content dan prioriteit wilt geven. (Let op: prioriteren ≠ weglaten)

Maar nogmaals, dit heeft niets te maken met mobiele content. Het is een strategie voor lokale content. Iemand met een tablet midden in het pretpark wil je dezelfde content bieden als iemand met een mobiel in datzelfde pretpark.

Mag ik dan nog wel een app maken?

Helaas zijn native apps voor veel managers nog steeds de heilige graal en investeren ze liever in een app dan in een goede mobiele presentatie van de website. En dat terwijl 80% van alle branded apps nog niet eens 1000 downloads halen.

Hebben gebruikers echt overal een app voor nodig? Veel websites dringen hun apps nogal agressief aan mobiele gebruikers op. Zodra je een site bezoekt of via een link een artikel wilt lezen, wordt eerst de app in je gezicht gedrukt: “Download onze app!” Maar waarom zou je? Er is slechts een handvol diensten die je dagelijks of zelfs wekelijks gebruikt, wat een app rechtvaardigt. Veel organisaties overschatten sterk hoe frequent hun site gemiddeld gebruikt wordt.

Nadelen aan het gebruik van apps

Los daarvan zitten er ook een paar nadelen aan het gebruik van apps, bijvoorbeeld:

• De kracht van social media zit voor een groot deel in het kunnen delen van ervaringen, van foto’s en van hyperlinks. Maar hyperlinks openen geen apps.
• Apps worden gemaakt voor specifieke devices en platforms. Maar nogmaals: de realiteit is dat de diversiteit blijft toenemen. Voor native apps is dit problematisch, voor het web is dit een kans.

Dus ja, maak gerust een app mits voldoende mensen dagelijks of wekelijks met je interacteren. En zo’n app mag bewust gelimiteerd zijn qua content of functionaliteit, omdat de app zich als het goed is focust op het faciliteren van toptaken die gebruikers dagelijks dan wel wekelijks uitvoeren. Maar sta gebruikers nooit in de weg om de volledige website te gebruiken. Dwing ze niet naar de app of naar een gelimiteerde mobiele site.

Om alle hierboven genoemde redenen wint responsive design snel aan terrein: geen app, geen losse sites, alle content en functionaliteiten altijd toegankelijk en een flexibele presentatie van de content.

Gebruik mobile als katalysator

Gebruik mobile als katalysator om content die geen waarde toevoegt te verwijderen. Dit verbetert de user experience voor alle gebruikers – desktop en mobiel.

Als je denkt dat bepaalde content niet waardevol is voor de mobiele gebruikers, waarom zou die content dan wel waardevol zijn voor desktop gebruikers? Schrappen dus!

Kijk eens hoe de daadwerkelijke content op dictionary.com zich verhoudt tot de rommel op de pagina (zie afbeelding). In een mobiele interface zou je dit ongetwijfeld opschonen. Doe dit dan ook voor desktop.

“There is no good writing for mobile. There is only good writing.”- Karen McGrane

Creëer adaptieve content

Probeer zoveel mogelijk van je content herbruikbaar te maken met zo min mogelijk inspanning. Ok, we maken dus geen aparte content for verschillende devices c.q. schermafmetingen. En we schrappen zoveel mogelijk niet-relevante content. Dan nog moeten we ervoor zorgen dat de content mooi op ieder scherm getoond wordt.

Met responsive design kun je zorgen voor progressive disclosure, het aanbieden van meer content pas als de gebruiker erom vraagt of als de schermgrootte het toelaat. Met behulp van responsive design kun je bepaalde content standaard inklappen of weglaten (natuurlijk alleen als het gaat om redundante content). Maar de applicatie moet wel weten hoe de exacte choreografie in elkaar steekt. Een nadeel van het ‘responsive’ inklappen of verbergen van content is, dat het client-side plaatsvindt, dus pas na het downloaden van de data. Een beetje zonde dus.

Botte-bijl-aanpak ten koste van de contentkwaliteit

Ook zie je vaak dat content en zelfs headings na een x-aantal karakters afgekapt worden om de lay-out overzichtelijk te houden. Maar deze botte-bijl-aanpak gaat ten koste van de contentkwaliteit. Het afgekapte deel kan nog relevante content bevatten. Of er staan nog maar vier woorden achter, die je nog makkelijk had kunnen tonen.

Truncation is not a strate… – Karen McGrane

Hoe kun je contentchoreografie over de verschillende omgevingen beter ondersteunen, met zo min mogelijk inspanning? De oplossing: adaptive content. Het credo is “Publish once and distribute everywhere”. Het idee is dat je de content structureert in flexibele pakketjes en die als bouwstenen gebruikt om de user interface op te bouwen.

Contentpakketjes

In het voorbeeld van Netflix zie je onder andere deze contentpakketjes, die op desktop, mobiel of beide getoond worden:

• Filmtitel
• Plot teaser (korte beschrijving)
• Plot beschrijving
• Starring
• (Rest van de) cast
• Regisseur
• Genres

Je creëert dus een goed georganiseerd contentsysteem dat zorgt voor herbruikbare, gestructureerde, presentatie-onafhankelijke, betekenisvolle content. Het verschil tussen responsive design en adaptive design is dat responsive client-slide plaatsvindt en adaptive server-side. Aan de serverkant wordt op basis van de ‘viewport’-eigenschappen bepaald welke set van velden getoond wordt. Dit scheelt ook bandbreedte omdat je de overige velden niet meestuurt. Adaptive content hoeft overigens niet alleen gebaseerd te zijn op schermgrootte, maar bv. op locatie (zie het pretpark-voorbeeld), tijdstip, of een ander soort context.

Content gestructureerd invoeren in het CMS

Zorg dat je CMS het redacteuren makkelijk maakt content gestructureerd in te voeren (wat nodig is voor adaptive content). Om een mooi gestructureerd flexibel contentsysteem te krijgen, moet je de content natuurlijk mooi gestructureerd kunnen invoeren. En hier ligt het volgende obstakel: veel content management systemen zijn standaard niet zo gestructureerd ingericht. Vaak krijgt de redacteur een titelveld, een groot contentveld met een editor en met een beetje geluk nog wat velden voor tags, auteur en publicatiedatum.

Afgezien daarvan wordt er bijna nooit serieus aandacht besteed aan de inrichting van het CMS. Zelden buigt een user experience designer of informatiearchitect hier zich over; meestal wordt dit ‘taakje’ overgelaten aan een developer. Dat moet dus veranderen als je serieus met een contentstrategie voor mobiel alle devices en omgevingen aan de slag wilt.

Dit is een verslag vanuit de ‘Content Strategy for Mobile’-workshop van Karen McGrane op de IA Summit 2013 in Baltimore.