Mobiele bezoekers: mobiele of reguliere site tonen?

Steeds meer bedrijven bieden naast een reguliere website ook een mobiele website of een app aan. Maar hoe en wanneer bedien je de bezoekers met deze verschillende opties? Begin je direct met de geoptimaliseerde mobiele website, de volledige reguliere website of wellicht geen van beide? Hieronder een aantal tips & voorbeelden hoe je de bezoeker met deze verschillende startpunten kunt bedienen.

1. Direct een keuze maken

Een veel voorkomende manier om een mobiele site of app te communiceren is middels een introductiepagina of wel een ‘splash’ pagina genoemd. De bekende ‘splash’pagina geeft de bezoeker de mogelijkheid om de website bijvoorbeeld in HTML of Flash te bekijken. Inmiddels zien we dit steeds meer op mobiele devices verschijnen, waarbij de bezoeker een keuze moet maken tussen de mobiele site, volledige (reguliere) site en/of app. Een bekend nadeel van een ‘splash’ pagina is dat er een grotere kans bestaat dat bezoekers voortijdig afhaken, omdat men het lastig vindt om direct een keuze te maken. Daarnaast kan het zijn dat de pagina niet voldoet aan de verwachtingen van de bezoeker, doordat dieperliggende pagina’s (deeplinks) niet meteen bereikbaar zijn. Aan de andere kant is het een voordeel dat het een lichte pagina is om te laden, waarbij je alle opties kunt aanbieden.

2. Standaard de mobiele website tonen

Sommige websites kiezen ervoor om standaard de mobiele site te laten verschijnen, wanneer bezoekers via een mobiel device binnenkomen. Dit kan een voordeel zijn omdat je de keuze uit handen van de bezoeker neemt. Doorgaans zijn mobiele sites functioneler ingericht en geoptimaliseerd voor mobiel gebruik. Vandaar dat een meerderheid van deze websites vaak een beknoptere versie van de reguliere site omvat. Het nadeel hiervan, net als bij introductiepagina’s, is dat het bereiken van deeplinks niet altijd meer mogelijk is doordat deze pagina niet bestaat in mobiele sites.

Een voorbeeld is de website van Carglass. Deze start met de mobiele homepagina (ongeacht via welke link de bezoeker binnenkomt). Dit betekent dat de Google link van Carglass: ‘ANWB ledenvoordeel’ via mobiel niet meer bereikbaar is, omdat deze niet bestaat in de mobiele site.

In de praktijk blijkt dat niet alle bezoekers een geforceerde mobiele website aangenaam vinden. Mobiele bezoekers kiezen in 65 % van de gevallen voor de gewone website en slechts 35% kiest voor de mobiele website. Enkele bezoekers stellen zelfs hun mobiel in als dekstop device, zodat de volledige site altijd als eerst wordt getoond.

3. Standaard de volledige website tonen

Een 3e optie is om altijd de volledige website te laten zien. Het voordeel hiervan is dat deeplinks altijd bereikbaar zijn. Het is belangrijk om te communiceren dat er naast de reguliere website, ook een geoptimaliseerde website voor mobiele devices of een app beschikbaar is. Houd er wel rekening mee dat de volledige homepagina te zwaar kan zijn om te laden voor een mobiel device. Booking.com begint altijd met de volledige website, maar biedt wel direct bovenaan de pagina de optie om de mobiele site te bezoeken of de app te downloaden. Dit hanteren zij tevens vanuit Google Adwords. Het is daarom belangrijk om je SEA te optimaliseren voor mobiel.

Crosslinken naar mobiele site, reguliere site of app

Laat de bezoeker in elk geval altijd zien dat er meer is (dan de reguliere website), zodat hij zelf kan kiezen. Het is een gemiste kans als je de bezoeker er niet op attendeert dat er verschillende keuze’s zijn. De ANWB heeft een reguliere site, een mobiele site en een app. Zij laten echter kansen liggen om deze verschillende kanalen onder de aandacht te brengen. Vanuit de volledige website wordt er niet gewezen op de mobiele site of de app. Via Google is de mobiele site ook niet te vinden en de mobiele site wijst ook niet op de app.

Beperkingen met responsive design

Houd er rekening mee dat het lastig is om in een responsive design website de bezoeker te voorzien van een link naar de volledige website. In responsive design past de website zich namelijk automatisch aan de schermgrootte van het betreffende device aan. Een goed responsive design laat geen pagina’s achterwege in de mobiele variant, maar dit betekent niet dat de bezoeker geen behoefte heeft om de volledige website te bekijken.

Slot

Bij het bepalen hoe te beginnen: de mobile site, de reguliere site of een introductiepagina is voor elke doelstelling anders. Elke variant heeft zijn voor- en nadelen. Ik ben erg benieuwd naar de overwegingen die jullie maken bij het bepalen van een mobiel startpunt.

Interessant?

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

Reacties

  1. Ruben Woudsma |

    Is de keuze voor een mobiele website nog valide? De huidige trends richting zich naar mijn idee nog op specifieke mobiele apps of het ontwikkelen van een responsive ontwerp.

    “Houd er rekening mee dat het lastig is om in een responsive design website de bezoeker te voorzien van een link naar de volledige website”

    Hoe bedoel jij dit? Een responsive ontwerp maakt toch geen onderscheid tussen een volledige website. Je hebt per definitie altijd de beschikking over een volledige website.

  2. Ik ben vooralsnog nog niet een groot fan van het gebruik van responsive design, omdat je daarbij vaak in eerste instantie “teveel” informatie binnenhaalt, die je vervolgens “verbergt” voor mobiele apparaten. Zo haal je meestal alle (achtergrond) plaatjes binnen en de gehele CSS file: dit kan al gauw enkele tientallen kilobytes extra zijn die je niet gebruikt, maar die wel de gebruiker extra wachttijd kosten en misschien ook wel extra geld (gezien de huidige trend van datalimieten op mobiel Internet en zo). Je kan hier natuurlijk wel server-side een oplossing voor bedenken, maar dan ontkom je toch niet aan iets van browser-sniffing en heb je eigenlijk geen responsive design meer.

  3. Als je alleen wil informeren of een goede indruk wil achterlaten is de keuze makkelijk: direct naar de mobiele site met die smartphone.

    Het wordt pas ingewikkeld als je meteen iets aan de bezoeker wil verkopen.

  4. Op m’n laptop gebruik ik de mobiel site van de RET aangezien deze beter en overzichtelijker is dan de normale site.
    Verder heb ik m’n telefoon op ‘desktop’ staan vanwege het regelmatig nutteloos ontbreken van content.
    Voorbeelden: iBood. Je kan niet naar ‘bespreek het product’ via de mobiele site.
    Ander voorbeeld: Nu.nl –> geen link naar Nujij.
    Nog een voorbeeld: Nujij.nl, laat slechts 10 berichten per pagina zien waardoor sommige onderwerpen binnen mum van tijd meer dan 30 pagina’s hebben.
    Marktplaats: link uit e-mails werken vaak niet als je je device niet als desktop laat werken.

    Al met al is dit een onderwerp waar veel sites niet gebruiksvriendelijk mee om weten te gaan. Daarnaast worden schermen ook steeds groter, dus weergaves van normale sites op mobiele devices ook steeds beter. Als je op je werk/ school en thuis gewoon op WiFi zit maakt de datalimiet ook een stuk minder uit.

  5. “Een goed responsive design laat geen pagina’s achterwege in de mobiele variant, maar dit betekent niet dat de bezoeker geen behoefte heeft om de volledige website te bekijken.”

    Met deze zin kan ik het toch niet eens zijn. Als je een goede Responsive Website bouwt wordt de volledige website op de goede manier weergeven op welk device dan ook.

    @bert – Bekijk eens of de Mobile First approach je van mening doet veranderen. Hier gaat het om vanuit mobiel beginnen met ontwikkelen, waarna je je media queries voor groter formaat definieert. Hierdoor laat je niks wat overbodig is op mobiel of tablet.

  6. De keuze van reguliere site, mobiele site, app of splash page hangt volgens mij heel erg af van het doel van je website.

    Voor bv. Carglass of ANWB zou ik direct een mobiele site tonen gericht op wat de doelgroep onderweg waarschijnlijk wil doen: bv. hulp voor het maken van een autoruit of hulp bij pech onderweg. Dat lijkt mij het voornaamste doel.

    Wanneer je een mobiele site toont, zorg er dan wel voor dat alle content óf op de mobiele site toegankelijk is óf dat je van de mobiele site kunt schakelen naar de reguliere site. En maak geen onderscheid in wel/niet betaalde informatie tussen desktop en mobiel. Een raar en slecht voorbeeld hiervan vind ik VI.nl. Je kunt niet van de mobiele site naar de reguliere site. Wil je op de mobiele site tussenstanden weten, dan moet je daarvoor betalen, terwijl die service op de reguliere site gratis is. (ik weet niet zeker of dit nog zo is, maar was zeker ruim een jaar het geval)

    De keuze tussen een app en een reguliere site snap ik niet goed. Wie wil er nu direct een app downloaden en installeren? Bovendien, ga je dan dus voor ieder platform een app ontwikkelen? Een mobiele site is veel breder toepasbaar voor meer apparaten. Wanneer SEA campagnes etc. daar allemaal op ingericht worden, biedt een mobiele site goede uitkomst. Bovendien kun je dan ook makkelijk met qr codes mensen vanuit advertenties/billboards/beursstands/etc. doorverwijzen naar specifieke landingspages. Een app is mijn inziens meer geschikt wanneer je een relatie hebt met elkaar, bv. als klant van een bank. In de app kun je je gegevens inzien en beheren. Of denk aan je persoonlijke account bij diverse winkels (kleding, bol.com, greetz, etc.)

    Natuurlijk zijn bovenstaande voorbeelden geen vast staande regels. Op basis van doel, budget of middel bepaal je wat voor jou het meest effectief/haalbaar is.

  7. HarryMonmouth |

    Ik denk een optie is nodig binnen chrome of opera, etc. Soms wil ik altijd surfen de mobile site op smartphone en ook PC als ik ben 3G gebruiken. Maar als ik ben op kabel den wil ik meestal surfen de volle site omdat als ik de mobile site gebruiken ik ben altijd gefrustreerde. Ik wil altijd zelf keuzen op allemaal gadgets.

    Sorry voor de slecht Nederlandse schrijven. Ik ben een Londoner.

  8. Mooi dat iedereen zo zijn eigen voorkeur heeft: mobiel, volledige site of app. Hangt ook erg af van het doel van je site en je doelgroep. Dus: meten is weten! Simpele A/B tests zouden moeten kunnen uitwijzen wat voor een bepaalde site de juiste strategie is.

  9. Een mooie ontwikkeling: de groei van smartphones/tablets gaat zo snel, dat de verwachting is dat er binnen 12 maanden meer ‘mobile’ apparaten in de wereld zijn dan normale (desktop) PC’s.

    De gebruikers gaan dus sneller dan de aanbieders. Al was het alleen maar om klant vriendelijk te zijn, is het advies: begin met mobile. Al is het maar klein’. Groots uitpakken kan altijd nog. En vindt zo uit hoe de gebruikers reageren, welk deel van de bezoekers via mobile komt (Google Analytics), en werk daar beleid voor uit.

    Voor sollicitanten is het al een stuk vriendelijker geworden nu vacatures ‘mobiel’ leesbaar gepresenteerd kunnen worden. Wie volgt?

  10. @Ruben Woudsma
    Wat ik hiermee bedoel is dat een bezoeker via mobiel nooit de ‘grotere weergave’ van de website kan bekijken. Stel voor de gebruiker heeft een banner gezien op de volledige weergave van de website. De volgende morgen wilt hij dezelfde link zoeken op mobiel, maar hij kan deze niet vinden omdat de gehele rechter kolom met crosslinks in de ‘kleinere weergave’ niet op het scherm wordt getoond. Er is dan geen link of welke mogelijkheid dan ook om de ‘grotere weergave’ te tonen op mobiel, omdat dit automatisch wordt gedetecteerd. Dit kan leiden tot frustraties bij bezoekers, zoals @jos, die zijn mobiel als dekstop heeft ingesteld.

    @ Norelay
    Het is inderdaad zo dat een goed ontwikkelde responsive website zich perfect aansluit op de betreffende device. Dit neemt niet weg dat er vaak content zoals crosslinks, banners, uitgelichte content (alles wat in een ‘rechterkolom’ zou kunnen staan) beperkt worden op de kleinere weergave van de website. Hiermee wil ik aangeven dat er vele bezoekers zijn die dit een probleem vinden en dat je er rekening mee moet houden bij het ontwikkelen van de website.

    @ Bram de Winter
    Het meten van je website is een inderdaad een belangrijk actiepunt bij het bepalen van je mobiele startpunt. Bedankt!

  11. Precies dit is wat ik bedoel. Als je als ontwikkelaar rekening houdt met de wensen van de gebruiker. Zal responsive design op welk device dan ook alles bieden wat een gebruiker zich maar wenst!

    Responsive design is niet een kwestie van je sidebar onder je normale content plakken, omdat hij dan responsive is. Het is een overweging van hoe zwaar elk content element weegt qua belangrijkheid en dan ga je kijken naar de juiste plaatsing.

  12. Bert Anvelink |

    Uit alle reacties valt, logischerwijs, op te maken dat het doel bepaald of er een (mobiele) site en/of app ontwikkeld moet worden. Voor mij als relatieve leek is nog wel onduidelijk wat wanneer het beste kan worden ingezet en in welke combinaties. Is het niet mogelijk om een beslissingsboom te maken, die aan de hand van eerste doelstellingen, een advies geeft over de keuzes die gemaakt moeten worden? Lijkt me een mooi vervolg op bovenstaande discussie.

  13. het is heel simpel om je normale site om te zetten naar een mobiele pagina, inclusief alle links en foto’s, ik ben er mee bezig via http://www.dudamobile.com/ moet alleen op de server nog een m. subdomain aanmaken. het maken van een mobile site voor een smartphone is echt 5 minuten werk

  14. @Noraly
    Helemaal mee eens dat het dat je niet de gehele sidebar onder je content moet plakken. Maar gedacht vanuit gebruikersperspectief, zou er een uitweg moet zijn om deze content alsnog te bereiken via mobiel. En dat is erg lastig in responsive design, omdat er een automatische detectie van schermgrootte plaats vindt.

    @Bert
    Er is inderdaad geen één ideale oplossing die je standaard kunt gebruiken. Een beslissingsboom zou een handig idee kunnen zijn.

  15. Het merendeel zal waarschijnlijk uitkomen op een responsive design. In vergelijking tot een mobiele website valt er in de meeste gevallen buiten een aantal of images en flash weinig weg. Een gebruiker die niet afweet van de app zal op een mobiel eerder op zoek gaan naar de website. Bovendien biedt een mobiele website nog geen oplossing voor tablets. Het blijft inderdaad een afweging wat het doel is van de website.

  16. “Maar gedacht vanuit gebruikersperspectief, zou er een uitweg moet zijn om deze content alsnog te bereiken via mobiel.”

    Ik snap niet helemaal wat je hiermee bedoeld, want ik zei juist in mijn vorige comment dat het gaat om een graad van belangrijkheid en een goede content choreografie. Er word dus geen content weggelaten. Dus hoezo moet er een uitweg zijn om content alsnog te bereiken?

  17. @Noraly
    Maar als je de informatie uit je sitebar wel wil tonen, maar niet domweg “onderaan” je content wil plakken, waar moet je het dan wel zetten? In een accordion of een ander inklapbaar paneel? Maar heb je dan niet weer meer Javascript nodig om de boel in en uit te klappen, hetgeen je mobiele site weer “zwaarder” maakt? Of anders op een nieuwe, achterliggende pagina? Maar dan moet je als gebruiker constant weer een nieuwe pagina laden… Lastige maar interessante vraagstukken :)

  18. @Bert
    Het ligt er natuurlijk aan wat je in je sidebar hebt staan. Stel het is de sidebar van een luchtvaartmaatschappij. In een desktopwebsite zou het zomaar kunnen dat daar de tool staat om een vlucht te zoek.
    Het is natuurlijk logisch dat zo’n tool op mobiel niet ineens onder de normale content geplakt moet worden.

    Zelf vind ik dit het interessantste vraagstuk binnen Responsive Design, wat doe je met context en wat doe je met je content? De contentstrateeg moet samen met de klant en de gebruiker de gewenste content bepalen en welke content belangrijk is op welk moment.

    Het gaat om de juiste content choreografie: http://trentwalton.com/2011/07/14/content-choreography/

    Maar ook over is je content er klaar voor:
    http://www.alistapart.com/articles/future-ready-content/

    Misschien goed leesmateriaal er is al door veel mensen over nagedacht. Zelf ga ik ook binnenkort wat publiceren binnen het onderwerp Responsive Design.

  19. @Noraly
    Daarmee bedoel ik de content van de sidebar, oftewel context zoals jij het benoemd. (ik denk dat de verwarring was) In het kader van mijn artikel: Mobiele of reguliere site tonen, wil ik alleen aangeven dat de bezoeker in responsive websites geen optie heeft om de website in ‘grotere weergave’ te bekijken, indien deze wens bij de bezoeker is.

    Hoe je uiteindelijk responsive design het beste kunt ontwikkelen is zeker nog een interessante vraagstuk. En ik kijk uit naar je artikel.

  20. Hi Wendy, ik werk vanuit Maxlead voor Carglass. Graag wil ik je wijzen op het gegeven dat de ANWB voordeel link géén SEA link is, maar een organische listing. Ik ben het met je eens dat deze rich snippet op de mobiele resultatenpagina van Google 1.) niet vertoond zou moeten worden of 2.) naar een correcte pagina zou moeten leiden.

  21. Als aanvulling op m’n vorige reactie: waar ik rich snippet zei, bedoelde ik sitelink.

  22. Bart, Dank voor de correctie. Ik zal het aanpassen!

  23. Luke Wroblewski heeft inmiddels ook een interessant stukje geschreven over responsive design patterns: http://www.lukew.com/ff/entry.asp?1514

  24. @Bert – Als ik naar dat artikel van Luke kijk zie ik toch eerder de fout die altijd wordt gemaakt, dan dat ik hier de toekomstige content grid zie. Dit is als je naar de visuals kijkt een kwestie van content onder elkaar zetten namate het scherm kleiner wordt. Ikzelf denk dat sommige content die bij een mobiele website bovenaan staat op een desktopwebsite genoeg aandacht krijgt als het in de sidebar staat.

    Begrijp je mijn twijfel?

  25. @Noraly Ik begrijp je twijfel wel: er wordt hier simpelweg gekeken naar het heen en weer schuiven van content op de pagina terwijl je er misschien nog abstracter naar moet kijken: hóe presenteer je content? (en niet zozeer “waar” presenteer je content).

    Daarnaast blijf ik bij een dergelijk responsive design vraagtekens zetten wat betreft de grootte van de site en de bijbehorende performance. Alhoewel de bandbreedte van mobiel Internet minder problematisch is geworden, mede door meer Wifi spots, merk ik toch nog wel dat veel mobieltjes struikelen over grotere sites. Het lijkt vaak een geheugenprobleem te zijn. Bij mijn eigen oude E72 kan ik er in ieder geval vanuit gaan dat hij zich stuk loopt op sites van meer dan 1.5 Mb, zelfs als ik alle overige apps sluit. En ik heb zelfs ook al problemen gehoord van een collega met een Galaxy S2 die soms niet meer genoeg geheugen had.

  26. Is het niet mogelijk om, net als google het lijkt te doen met hun tablet versie van google.com, het “responsive” gedeelte uit te zetten als de gebruiker dat wil.

    Ofwel, met JS de detectie zodanig zetten dat hij de desktop variant ziet. Of nog leuker, dat hij kan kiezen wat hij wil. Desktop, tablet, mobile of een device van morgen.

    Ik weet dat responsive aangeeft dat het “over devices heen” gaat maar er zitten altijd knipmomenten in waarbij grafisch keuzes gemaakt worden. Dat is waar ik op doel.

  27. Interessant om te zien dat het artikel gaat over de keuze mobiel versus desktop en de reacties (bijna) allemaal over dat ene alineaatje over ‘responsive design’. Overigens terecht, als je het mij vraagt, wat de keuze ‘mobiel of desktop’ is door responsive web design goeddeels irrelevant geworden.

    De vraag is bij responsive design overigens niet ‘welk type device gebruikt de bezoeker?’, om daar vervolgens met breakpoints en dergelijke op in te spelen, maar ‘welke taak wil de bezoeker uitvoeren?’ en ‘welke content of tools passen daarbij?’. Die taak wordt natuurlijk beïnvloed door context — dus door type device, fysieke omgeving, aanleiding voor het sitebezoek ofwel de situatie waarin de bezoeker zich bevindt — maar de taak blijft het belangrijkste issue. Daartegenover staat vanzelfsprekend het doel van de afzender/uitbater van de site: wat wil die bereiken?

    Zowel de toptaken als je sitedoel bepaalt welke content je waar positioneert op welke schermgrootte. Dus een call-to-action die op je desktopversie rechts bovenin een sidebar staat, verschijnt op mobiel direct onder header, paginatitel en lead, en boven de rest van de content. En niet, zoals veel sites nu doen: onderaan (al) je content. Dat is immers geen responsive lay-out, maar slechts adaptive.

    Ik zou zelfs nog verder willen gaan: wanneer iemand op een mobile device je site bezoekt, heeft hij een andere toptaak dan wanneer hij op zijn laptop of desktop-pc komt. (Welke dat zijn, moet je per geval onderzoeken en verifiëren.) Vervolgens richt je je responsive site op díe toptaken in voor zowel desktop als mobiel (als tablet als tv enzovoort).

    Tot slot: argumenten als ‘wat moet de bezoeker dan die op zijn desktop dit of dat heeft gezien, en vervolgens op zijn mobiel terugkomt en die content mist’ staan bol van drogredenen. Je ontwikkelt een site toch niet voor de uitzonderingen?

    (Overigens een interessante discussie. Complimenten!)

  28. @Janwillem – Grappig dat we elkaar overwachts tegenkomen en kort konden sparren over dit onderwerp. Ik heb nog even nagedacht over wat je gisteren zei. Toch denk ik dat over het punt desktop is de ‘normale’ weergave heen moet stappen. Het is meer een kwestie van je content vormgeven tot hapklare brokken die op alle manieren flexibel zijn en je dus op ieder apparaat op de goede manier kunt positioneren. Gisteren heb ik Sara Wachter-Boettcher geinterviewd, die hier ook wat erg interessante dingen over heeft gezegd.

    @Christiaan W. Lustig – Helemaal eens met je commentaar. Zou het interessant vinden om eens te sparren.

  29. @Christiaan en @Noraly,

    Dank voor jullie inhoudelijke reactie. Ondanks dat ik het graag eens ben is de mens een gewoonte dier. En voor sites die niet veel bezocht worden is herkenning plezierig. Te meer als het sites zijn met aanzienlijke hoeveelheden content of taken waar mensen geconcentreerd moeten zijn. Daar zie ik een tegenstelling in.

    Daarbij, als jullie stelling het geval is waarom kiest bijv. Google hier dan expliciet niet voor? En ook Apple heeft weer een heel andere zienswijze, die doen niets. Het feit dat ook devices slimmer/ krachtiger worden en problemen verhelpen die kleine schermen opwerpen moet je in mijn beleving niet zomaar buiten beschouwing laten.

    Ik ben benieuwt naar jullie reactie.

  30. @janwillem – ‘Te meer als het sites zijn met aanzienlijke hoeveelheden content of taken waar mensen geconcentreerd moeten zijn. Daar zie ik een tegenstelling in.’

    Dit is op dit moment inderdaad een groot struikelblok binnen Responsive Design. Gisteren vroeg ik dat aan Sara, omdat ik zelf ook niet de oplossing hiervoor heb en omdat ik erg benieuwd was hoe zij daarover denkt. Als je een grote, complexe website wil bouwen, met veel content, wat dan?

    Zij zei(in vrije vertaling): Als je een zo’n complex project start, moet je zorgen dat iedereen uit je team hetzelfde doel voor ogen heeft en je moet weten dat het een bloederige en ‘messy’ boel wordt. Laat dat je klant van tevoren weten.

    Het laatste stukje voelt een beetje als Apple en Google op de brug blijven staan, dan wij ook. Moeten wij als innovatieve professionals niet gewoon in het diepe springen en kijken of we blijven drijven?

  31. @ janwillem
    Dank voor je reactie. Leuke discussie, zo. :-)

    “… voor sites die niet veel bezocht worden is herkenning plezierig.”
    Wat bedoel je hiermee precies? Als je een site niet veel bezoekt, wil je toch gewoon je ding doen en wegwezen? Daarmee draait het dus júist om de toptaken.

    “… taken waar mensen geconcentreerd moeten zijn.”
    Door je nadrukkelijk op de toptaken te richten, maak je ze makkelijker voor je klant, relatie of burger. En is er minder concentratie nodig.

    “… waarom kiest bijv. Google hier dan expliciet niet voor?”
    Google is in elk geval wat zoeken betreft optimaal ingericht op toptaken… namelijk zoeken.

    Daarnaast, wat Noraly zegt, snijdt ook hout: “Het laatste stukje voelt een beetje als Apple en Google op de brug blijven staan, dan wij ook. Moeten wij als innovatieve professionals niet gewoon in het diepe springen en kijken of we blijven drijven?”

    @ Noraly
    “Als je een grote, complexe website wil bouwen, met veel content, wat dan?”
    Ook dán is het zaak te blijven richten op het belangrijkste: welke content, welke tools en welke functies vraagt het grootste deel van je bezoekers?

  32. @Christiaan W. Lustig –
    “Ook dán is het zaak te blijven richten op het belangrijkste: welke content, welke tools en welke functies vraagt het grootste deel van je bezoekers?”

    Hier ben ik het helemaal mee eens. Ik denk inderdaad dat je moet kijken naar de focus van je bezoeker.Hoe je belangrijke onderdelen door middel van een goede content choreografie zou kunnen weergeven. Het proces zal hierdoor zoals Sara zegt wel een warboel en messy worden, aangezien het een complex project is en je als team hetzelfde doel moet nastreven, al is dat doel nog helemaal niet afgekaderd.

    Er moet volgens mij nagedacht worden over alle handvatten die je de verschillende disciplines kunt geven, zodat dit proces net even minder messy wordt en je als team weet dat het een goed en doordacht project wordt.

  33. @ Noraly

    Leuk dat je Sara Wachter-Boettcher hebt gesproken. Ik had onlangs uitvoerig Twitter-contact met haar, en met Karen McGrane, overigens. Beide dames doen erg inspirerende dingen.

    Waar ze echter een slag missen, is als het gaat om doelgroepgerichte content, dus echt op de klant, relatie of burger afgestemende taken en inhoud. Dat gaat immers verder dan louter je content in hapklare en herbruikbare brokken opknippen, zoals ik in mijn recente artikel — plug: http://bit.ly/GRilYc — ook al beargumenteerde. Zulke content gaat immers om context en betekenis.

    Wat project en proces betreft: ik werk met mijn collega Niels van Midden aan een projectaanpak en workflow voor responsive design en development. Waarschijnlijk publiceren we hierover binnenkort een keer op Frankwatching, waarna er mogelijk een e-bookje of white paper volgt.

  34. @Christiaan W. Lustig – Zelf ben ik juist gefocust op context en daar ga ik binnenkort een landelijk onderzoek over uitzetten. Verder is mijn artikel over workflow afgekeurd door Frankwatching, omdat het te technisch zou zijn voor het lezerspubliek. Binnen onbepaalde tijd zal mijn artikel te lezen zijn op Fronteers.

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!