1. Zijn veelgestelde vragen nodig?
2. Waar zet ik de veelgestelde vragen?
3. Hoe schrijf je vragen en antwoorden?
4. Hoe zoekt en vindt de gebruiker vragen en antwoorden?

Dit artikel gaat in op deze vragen. En, voor we beginnen: veelgestelde vragen zijn vragen die veel worden gesteld; veel gestelde vragen zijn veel vragen die zijn gesteld (bron: Nederlandse Taalunie).

Een klant wilde op zijn site veelgestelde vragen. Geen ongewone vraag, maar waarom wilde hij dat eigenlijk? Op die vraag kwam geen duidelijk antwoord: “Omdat andere sites dat ook hebben”, “Dat hoort toch zo?”, “Omdat onze oude site dat ook heeft.” Dat zijn redenen waarvan mijn nekharen overeind gaan staan… die veelgestelde vragen komen er niet zomaar!

Het was niet makkelijk om artikelen te zoeken over het wel of niet inzetten van veelgestelde vragen op een website. Ten eerste omdat de zoektermen veel links opleveren náár veelgestelde vragen; ten tweede omdat er blijkbaar niet zo heel veel over geschreven is. Uiteindelijk vond ik twee artikelen, door Caroline Jarrett en David Hamill, waaruit zeker geldige redenen uit te herleiden zijn voor het wel of niet opnemen van veelgestelde vragen in een site.

Zijn veelgestelde vragen nodig?

De eerste vraag die beantwoord moet worden, is of je de veelgestelde vragen echt wel nodig hebt. Veelgestelde vragen moeten de content van de site ondersteunen en niet herhalen of aanvullen – dan kan je je geld beter investeren in een goede schrijver.
Veelgestelde vragen werken prima voor het ondersteunen van een helpdesk: een goed opgezet systeem van veelgestelde vragen kan het aantal telefoontjes naar de helpdesk met wel 10% verminderen (Caroline Jarrett).

Waar zet ik de veelgestelde vragen?

Als je veelgestelde vragen in je site plaatst, moet de gebruiker ze wel kunnen vinden. Gebruikers gaan zelden op zoek naar veelgestelde vragen (David Hamill) – laat staan dat zij op zoek gaan naar de Engelse term ‘FAQ’ (Frequently Asked Questions). En omdat zij deze content niet actief opzoeken, moet je de veelgestelde vragen zeker niet verstoppen. Een voorbeeld van hoe het niet zou moeten, is daarom de KNVB-site, waar de optie ‘FAQ’ onderaan de pagina in de footer verstopt is.

Het is beter om een aantal vragen (de meest gestelde) te tonen en daarbij te linken naar alle veelgestelde vragen. Telfort maakt hier bijvoorbeeld gebruik van, waardoor je direct vanaf de homepage naar bepaalde rubrieken binnen de vragen kan. Nu is niet altijd de homepage de beste plaats om je veelgestelde vragen te introduceren. Een contactpagina is ook een goede plaats, omdat gebruikers op dat moment kunnen besluiten om een vraag op te zoeken in plaats van die aan je helpdesk te stellen.

Hoe schrijf je vragen en antwoorden?

Over de formulering van de vragen én de antwoorden moet ook nagedacht worden. Je kunt erachter komen wat jouw gebruikers zich afvragen door te luisteren naar gesprekken met de servicedesk; door te analyseren waar zij in jouw website naar zoeken; en door hun e-mails te lezen. Echt vaak gestelde vragen komen ook echt regelmatig voor; die zie je op die manier binnen een dag minstens twee keer! Trap niet in de val van ‘de meest aangeklikte vraag is de meest gestelde vraag’, want gebruikers klikken soms vragen aan die zij niet wilden stellen, om toch maar ‘een’ antwoord te vinden, of om te controleren of het antwoord wel correct is. En pas zeker op voor vragen waarvan jij wilt dat de gebruiker ze stelt!

De vragen moeten daarnaast geschreven zijn in de taal van de gebruiker. Het is erg verleidelijk om jargon te gebruiken, of om de vragen zo te formuleren als het bedrijf ze gesteld zou hebben. Maar de gebruikers zijn degenen die de vraag ‘stellen’, dus het moet voor hen begrijpelijk zijn. En dat geldt natuurlijk ook voor de antwoorden: kort en krachtig is hier de sleutel. Geef eerst het antwoord, voordat je begint aan uitzonderingen, voorwaarden en uitleg.

Hoe zoekt en vindt de gebruiker vragen en antwoorden?

In het algemeen zullen gebruikers met één vraag bij de veelgestelde vragen uitkomen. Het is dus belangrijk dat ze hun antwoord snel kunnen vinden, en niet in een wirwar van teksten verzeild raken. Daarom is het beter om een lijst vragen te presenteren, waarbij het antwoord verschijnt als de gebruiker op een bepaalde vraag klikt, in plaats van een lijst met vragen waar het antwoord al onder staat. Is de lijst vragen erg lang? Dan heeft het zin om de lijst op te breken in betekenisvolle groepen (rubrieken).

Tenslotte kan het voorkomen dat een gebruiker een vraag heeft die jij nog niet tegengekomen bent. Bied daarom altijd de gelegenheid om contact op te nemen, zodat ook onbeantwoorde vragen beantwoord kunnen worden.

Veelgestelde vragen zet je niet altijd ‘zomaar’ in een site. Het belangrijkste advies: controleer eerst of de antwoorden ook in je content opgenomen kan worden. Zo niet – ook achter deze functionaliteit zit een weloverwogen reden voor het gebruik ervan. En hoewel sommige zaken uit dit artikel inkoppers zijn, is het wel belangrijk om dat eens op een rij te zetten.

Er is een grote variatie in de positie van deze elementen en niet alle oplossingen ondersteunen de taak van de gebruiker even goed. Naast de vraag waarom de gebruiker een bepaald veld in moet vullen, is zijn belangrijkst vragen: “Wat is het volgende veld dat ik in moet vullen?”, of “Wat is de volgende stap in de interactie?”. Dat zijn de vragen waarop het formulier al antwoord moet geven vóórdat de gebruiker zich er bewust van is.

Om het antwoord op de eerste vraag te vergemakkelijken, zetten we alle in te vullen vakken van een formulier onder elkaar, ook links uitgelijnd. Daardoor vinden de ogen van de gebruiker recht onder het ingevulde vak het volgende, lege, vak. Dit is een efficiënte manier voor het invullen van formulieren (Jarrett).

In lijn daarmee is het antwoord op de tweede vraag ook makkelijk te geven: de knop die de meest logische actie uitvoert, moet uitgelijnd staan onder deze invulvakken – als volgt:

De veldnamen staan het beste links van de vakken. Door ze links uit te lijnen wordt de lijst makkelijker te scannen, mits de lengte van de veldnamen niet erg groot is (Wroblewski).

Maar waar laat je dan de andere knop? Vaak is er immers nog een tweede actie, waarmee de gebruiker terug kan naar de situatie vóór de klik naar het formulier. Hoewel de ‘back button’ daar nog heel vaak voor gebruikt wordt, is het wel duidelijk om een dergelijke actie ook in het formulier zelf aan te bieden, vooral bij formulieren die uit meerdere pagina’s bestaan.

In het algemeen ging ik er vanuit dat er op basis van onze leesrichting een logische reden is om de knop voor de stap vooruit aan de rechterkant te zetten, en de knop voor de stap achteruit aan de linkerkant. Maar twee artikelen van Luke Wroblewski (bron en bron) brachten mij aan het twijfelen. Hij noemt namelijk het feit dat er in een formulier zelden een ‘heen-en-weer’ navigatie nodig is – vaker is er onderaan het formulier een ‘primary action’ en een ‘secondary action’. Die ‘primary action’ is dan actie die voor de gebruiker het meest voor de hand ligt. En om die reden kan de weergave van die actie anders zijn dan de andere actie. De knop ‘annuleren’ is in dit geval niet zozeer een actie als wel een link naar de vorige pagina, en kan dus als zodanig worden getoond. Daarbij blijft de knop voor de ‘primary action’ wel uitgelijnd aan de invulvakken, zodat het ‘in the line of fire’ voor de gebruiker blijft:

Wanneer er wel een echte ‘heen-en-weer’ navigatie nodig is (bijvoorbeeld in een wizard), moeten de knoppen wel als gelijke waarden getoond worden:

Zoals vaker is het dus afhankelijk van de context welke oplossing de beste is. En gelukkig maar: wanneer er één de beste was, zou het ontwerpen van een user interface maar een saaie baan zijn!

Zoals Jurgen eerder al aankondigde,  was er gisteren weer een Adobe User Group-meeting. De inspirerende titel-du-jour: Mobile Madness.
En alhoewel we dachten er met een G1 en een iPhone te zijn, waren we er uiteindelijk met twee G1′s. We voelden ons wat eenzaam (echt!).
De conclusie na de verschillende presentaties van onder andere Serge Jespers (Adobe), Thomas Joos (Boulevart), Ralph Cohen (IceMobile), Michel van Velde (Oneshoe) en Ubi de Feo (TwoDotOne) is dat er wel degelijk sprake is van een “mobile madness”, maar dat Adobe er (vooralsnog) mager voor staat op mobiel gebied!

Wordt 2009 het jaar van mobiel internet?
Via Twitter de tweeps op de hoogte houdend, met Yammer HQ een vinger aan de pols gevend en  met AK Notepad op de G1 in de aanslag legden wij ons oortje te luisteren!

Een korte introductie van de Adobe User Group werd gegeven door plaatsvervangend dagvoorzitter Niels de Keizer. Voorzitter Bert Hagendoorn was op een “secret mission” voor Adobe, what ever that may be! De Keizer begon zijn praatje met een stukje geschiedenis: de uitvinder van de eerste, voor het eerst zo genoemde, mobiele telefoon – Martin Cooper van Motorola. Hoewel wellicht niet veel mensen weten dat het eerste patent voor een draadloze telefoon al in 1908 werd ingediend.  Die doet het niet zo goed in de kroeg, overigens.

De Keizer eindigde zijn inleiding met een beetje inzicht in zijn eigen geschiedenis met mobiele telefoons. Die eindigde met een iPhone. Het zou niet de laatste keer zijn dat we die zouden zien, overigens. Vervolgens bleef ook voor hem de hamvraag aan de sprekers: Wordt 2009 het jaar van mobiel internet? Een overzicht van de meest interessante sprekers!

Serge Jespers
Het woord werd overgedragen aan Serge Jespers, “platform evangelist” van Adobe. Jespers had voor zijn presentatie niet één maar maar liefst drie mobieltjes op zak. Twee Nokia’s en ja, ook “die andere telefoon” (en zo werd de iPhone de rest van de dag dan ook genoemd). Hij vertelde kort wat over de ontwikkelingen op het gebied van Flashplayers voor mobiel (de recente berichtgeving uit Barcelona nog in het geheugen) en deelde mee dat er verwacht wordt Q4 2009 of Q1 2010 een mobiele Flashplayer voor Windows Mobile, Symbian en Android te lanceren met de mogelijkheden van Flashplayer 10. Vooralsnog moeten we het nog doen met de Flashlite player dus! Een andere verwachting die Adobe had, is intussen ruimschoots bereikt. Na eerdere onderzoeken had Adobe de verwachting uitgesproken dat er in 2010 zo’n 1 miljard (!) mobieltjes wereldwijd zouden zijn die Flash-content kunnen afspelen. Die aantallen zijn echter begin 2009 al bereikt.

Jespers liet ook nog even wat demo’s zien van Flashlite 3.1. De nieuwe “packager” zorgt ervoor dat applicaties niet meer via de Flashplayer op de mobiel hoeven te worden geopend, maar direct (alsware het een *.exe) te starten zijn. Jespers toonde dit op een Nokia N95 en een Nokia 5800. Helaas voor hem bleek de internetverbinding van Pakhuis De Zwijger op zijn zachtst gezegd “eigenwijs” en trad er regelmatig een fout op tijdens zijn demonstraties.
De hardste lach had hij overigens zichzelf op de hals gehaald, toen bleek dat hij de Flashplayer op een demo-toestel had gedowngrade en vervolgens zijn “live” geschreven applicatie na deployment de “This version of Flash is not supported” melding gaf. Hij accepteerde hem overigens waardig!

Thomas Joos
Onze zuiderburen hadden Thomas Joos van bureau Boulevart gestuurd om zijn verhaal te doen. Thomas is “mobile consultant” bij dit multimediale bedrijf.
Zijn verhaal, from concept to development, omschreef de stappen van idee tot creatie. Een erg leuk en onderhoudend verhaal, te meer omdat veel dingen die Joos omschreef gelijkwaardig of in een iets andere vorm terugkomen in het ontwikkeltraject voor “desktop internet applicaties”. Ook bij mobiele concepten draait het om een goed idee.Vervolgens is het slim je idee te toetsen bij bekenden of collega’s en te bekijken of het enthousiasme wat jij hebt bij het idee ook bij hen aanwezig is. Daaropvolgend is het altijd aan te raden om te kijken of je idee een probleem verhelpt of dat het een behoefte vervult. Definieer vervolgens je gebruiker en doe dit met precisie! Een goed gebruikersprofiel kan namelijk een echte “decision maker” zijn in je project. Vervolgens doorliep Joos nog een aantal stappen alvorens over te gaan tot ontwikkelen.

Een interessant aspect wat Joos naar voren bracht was een soort “storyboard” waar Boulevart gebruik van maakt tijdens het ontwikkelen van hun applicaties. Deze schetsen bevatten designs voor de schermen, aangevuld met omschrijvingen wat de gebruiker “ervaart” tijdens het gebruiken van de applicatie. Uiterst zinvolle informatie voor met name front-end developers, waarbij ik me af vraag welke mate dit een aanvulling of misschien zelfs vervanger kan zijn van de klassieke UID/IA-combinatie?

Michel van Velde
Via onze zuiderburen naar technisch-echt-bijna-buren: Michel van Velde van het Utrechtse OneShoe. Van Velde is de oprichter en directeur van OneShoe en momenteel verantwoordelijk voor de mobiele tak van dit full-service bureau. OneShoe wist recentelijk nog het nieuws te halen met hun QR-campagnes voor Go-Tan en makelaar Peek. Hij gaf al snel antwoord op de vraag die in het begin gesteld werd: 2009 wordt volgens hem wel degelijk het jaar van het mobiel internet.
Zijn argumenten zijn duidelijk. De huidige en toekomstige toestellen zijn er klaar voor, de iPhone heeft een bepaalde standaard gezet wat dat betreft. Providers bieden tegenwoordig betaalbare flat-fee abonnementen aan en er is een sterke “technical drive” bij de huidige consument. Belangrijker nog:  het nut van internet op de mobiel wordt steeds duidelijker. Intussen maken wekelijks bijna 850.000 mensen in Nederland gebruik van mobiel internet.

Van Velde benadrukte wel dat er nog genoeg te winnen valt. Van de top 200 websites uit 2008 heeft slechts 25% een mobiel-vriendelijke variant, bijvoorbeeld. Daarnaast moeten ontwikkelaars anders kijken naar mobiel internet. Het is een andere techniek en de consument heeft andere gebruiksmomenten. Vooral die gebruiksmomenten kwamen gedurende de daarop volgende presentaties terug, mobiel internet wordt nog het meest gebruikt tijdens het “wachten”.
Een andere tip die Van Velde meegaf, heeft betrekking tot het gebruik van bluetooth marketing. Consumenten hebben vaak niet door dat bij het inschakelen van bluetooth, zij zich ook openstellen voor derden. Een bericht pushen op bijvoorbeeld Utrecht CS zal daarom door de consument worden ervaren als spam. En dat op een apparaat wat vaak veel heiliger is dan de desktop thuis: hun mobieltje. Dit kan dus een averechts effect hebben. Positieve resultaten werden wel bereikt bij evenementen, waarbij via bijvoorbeeld printmedia duidelijk werd gecommuniceerd wat er te verwachten was wanneer aanwezigen hun bluetooth openstelden.

Ralph Cohen
Cohen sloot de dag af met enkele inspirerende cases van Icemobile. Die naam doet wellicht een belletje rinkelen, ze waren recent nog in het nieuws met de Centraal Beheer-app die afgekeurd werd voor de Apple App-store. Hij toonde enkele cases voor Red Bull en Samsung.

Maar wacht, er is meer…
Ja, er was meer. Zo was Ubi de Feo er om te vertellen welke dingen TwoDotOne er heeft gedaan voor Nokia, vertelde Wimer Hazenberg van Booreiland over Okimok, waren er mensen van Raak Mobile Concepts en deelde Ruben Salomon (HotSMS) in rap tempo zijn huidige en toekomstvisie op mobiel internet.

Aan het eind van de dag hadden collega Bertram en ik een behoorlijk tevreden gevoel. Nee, de informatie die genoemd werd was niet iets wat we nog niet eerder hadden gehoord. En ja, we werden wel een beetje suf van het feit dat er in elke presentatie wel een iPhone voorbij vloog (daarmee niets af willen doen aan de status van het apparaat). En wellicht had er toch iets breder kunnen worden gekeken naar ontwikkelingen op het gebied van Android of Symbian en wat dit voor de markt zou kunnen betekenen. Bovenal was het duidelijk dat Adobe nog niet veel  in te brengen heeft in alle “mobile madness”.

Waarom we dan toch met een tevreden gevoel op huis aan gingen? De focus van de presentaties lag niet op de producten van Adobe, maar daadwerkelijk op de ontwikkelingen die er plaatsvinden. Nu was het voor mij de tweede keer dat ik een AUG-event bijwoonde, dus ik weet niet of dit bij andere events wel zo is of was (en ja, ik zal proberen er vaker bij te zijn om dat te toetsen ;-)). Daarnaast waren er na afloop genoeg verse ideëen, haakjes en inspiratie om een goed gevoel over te houden.

Vanochtend zag ik onderstaande presentatie van Pattie Maes van MIT Media Lab en ik viel zowat van mijn stoel.

Pattie onderzoekt namelijk tools waarmee mensen kunnen interacteren met hun omgeving. In deze presentatie presenteert ze de ‘Sixth Sense’ van Pranav Minstry, die met bestaande technologieen ter waarde van 350 dollar een tool in elkaar heeft geknutseld, waarbij de echte wereld naadloos gemixt wordt met de data op het internet.

Het filmpje duurt zo’n 8 minuten. Zit het even uit, verbaas jezelf en houd je kaak vast!

Gisterenavond vond de tweede editie van This happened plaats in Theater Kikker in Utrecht. This happened gaat in op de verhalen achter interaction design met als achterliggende gedachte: ideeën hebben is makkelijker dan ze realiseren. Aan de hand van hedendaagse projecten wordt getoond hoe de conceptontwikkeling, het ontwerpproces en de realisatie van deze projecten tot stand kwam. Vier sprekers hebben elk tien minuten om over hun project uit te weiden en vervolgens heeft het publiek een kwartier om vragen te stellen en met de spreker in discussie te gaan.

Piece of Family

De eerste spreker van de avond was Sanne Kistemaker. Sanne is werkzaam als user centered designer en heeft ons wegwijs gemaakt met Piece of Family, een communicatiemiddel waarmee ouderen contact kunnen houden met hun familie zonder computer, maar met simpele hulpmiddelen als pen en papier, die weer via een scanner en weblog verbonden worden aan de wereld van de jongere generatie. Bij het ontwerpen is gebruik gemaakt van nieuwe ontwerptechnieken, zoals generative tools en contextmapping om de gebruikers in een vroeg stadium te betrekken in het ontwerpproces. Met het ontwerp van Piece of Family won Sanne in 2007 de Design for All Award bij de Nederlandse Designprijzen.

Ik vond dit een helder en goed verhaal. Wat het wat mij betreft erg interessant maakte is de doelgroep voor wie het product ontwikkeld is: ouderen van boven de 75 jaar. Ik ben niet eerder zo’n geslaagd eigentijds product tegengekomen voor een doelgroep voor wie het zeer moeilijk aan te leren is hoe ze om kan gaan met onze huidige digitale communicatiemiddelen.

Softbody

Niels Keetels stond ons vervolgens te woord. Niels is game design researcher aan de HKU en vertelde over Softbody; een afstudeerproject waaraan hij samen met vier anderen werkte. Softbody is een game waarin vrij en doelgericht spelen worden gecombineerd. De spelmechanismen werden geïnspireerd door observaties van spelende kinderen tijdens veldonderzoek op basisscholen.

Wat interessant is aan dit project is dat de uitkomsten van het veldonderzoek behoorlijk verrassend bleken en dit ook zeer grote implicaties voor het ontwerpproces betekende. De spelende kinderen toonden aan dat spelen niet in de regel een doel hoeft te hebben: het gaat om het spelen zelf. De manier waarop dit is doorvertaald naar de game zelf vind ik erg goed gedaan. Er is bijvoorbeeld geen einddoel in het spel en de surrealistische vormgeving is meer dan alleen decoratief: veranderingen in het uiterlijk van de omgeving geven de speler een indruk van de voortgang. De (verder onbewoonde) spelwereld is daarmee het belangrijkste personage in het spel.

Mahlangu Hand-washer

De derde spreker, productontwerper Irene van Peer, nam ons mee naar Afrika. Met een aantal collega’s bezocht zij de townships van Zuid-Afrika om als ontwerpers mee te werken aan een waterproject. Gebaseerd op gesprekken met de bevolking wilde ze een oplossing vinden die niet van boven opgelegd werd, maar een die men zelf kan maken en onderhouden. Uiteindelijk kwam zij op een simpel, maar ingenieuze oplossing om een lege fles om te bouwen tot een kraan, waarmee je je handen kan wassen met een beperkte hoeveelheid water. Naast de Mahlangu Hand-washer, genoemd naar de meest fanatieke gebruiker, maakte ze ook de instructies die door de bevolking aan elkaar doorgegeven kan worden.

Behalve dat dit natuurlijk een erg mooi project is voor de mensheid (er sterven namelijk wereldwijd zo’n 2,5 miljoen mensen per dag (!) aan slechte sanitaire voorzieningen), is dit project in mijn ogen bijzonder omdat de bevolking zelf zo intensief bij het project betrokken is geweest. De ontwerpers hebben zeer veel met de bevolking gesproken en maakten veel tussentijdse schetsen om duidelijk te maken of ze wel op een lijn met de Afrikanen zaten.

Mimoa

Tenslotte kwamen Naomi Schiphorst en Mieke Vullings iets vertellen over MIMOA –een gratis en open gids voor moderne architectuur, die zij in 2006 zijn gestart. MIMOA biedt precies de informatie die je nodig hebt voor het vinden en bezoeken van gebouwen, parken, bruggen, openbaar interieur en kunst in de publieke ruimte. De visie van de oprichters was om niet alleen architecten, maar ook een breder publiek te bedienen. Ze wilden een duurzame dienst opbouwen met een toegewijde community. MIMOA telt nu meer dan 4500 geregistreerde gebruikers en bevat meer dan 2500 projecten.

Dit project van deze twee jonge vrouwen vond ik erg inspirerend. Mieke en Naomi zijn beide architect en kwamen erachter dat ze iets misten: online bronnen op het gebied van architectuur. Omdat niet aan hun behoefte voldaan kon worden, besloten ze het zelf maar op te starten. En dit terwijl ze totaal geen internetervaring hadden. Erg stoer: iets missen en het dan maar gewoon zelf maken!

Volgende keer weer?

Ik vond het een toffe en inspirerende sessie. Een mix van mensen uit het veld, gevestigde ontwerpers, commerciële bedrijven en studenten spreken openlijk over hun methodes en ideeën en zetten je aan het denken. Dus: volgende keer weer? Jazeker! Als er plek is tenminste, want alle 70 kaarten waren binnen 20 minuten al weg!

De volgende edities van This happened worden gehouden op maandag 29 juni en maandag 26 oktober. Wil je ook komen? Schrijf je dan in voor de nieuwsbrief van Thishappened.nl en je wordt op de hoogte gehouden van het volgende evenement.

Op het Zesde Vlak kwam eerder vandaag dit filmpje tegen, dat daar aardig op aansluit. Ja, het is een gezonde portie sci-fi, maar dat maakt het niet minder entertaining! Daaronder vindt je de Slideshare van Michael Tchong’s presentatie zoals hij die op Picnic08 gaf.

Computer Arts Magazine (CAM) smijt er een mooie analogie tegenaan: “the designer creates a perfect egg and they hand it over to developers, who break it then stick it back together.” Resultaat; aan het einde van de rit is een designer zelden of nooit tevreden over het opgeleverde online product.

De tijd dat de designer zelf met Actionscript of HTML/CSS aan de slag ging lijkt steeds verder weg. Er komen steeds meer specialisaties, waarbij het aantal toepasbare technieken ook hand-over-hand toeneemt. De “hybride werknemer” is dood, leve de hybride werknemer!

De analogie van CAM is het startpunt van een discussie in het blad tussen verschillende partijen, waaronder Jeremy Baines, van Howard/Baines – leverancier van diverse webapplicaties aan bijvoorbeeld Reuters. Die Baines geeft zijn designers als eerste regel mee: “praat niet met de developers voordat je je concept volledig hebt uitgewerkt”. Vaak limiteert het de designer in zijn visie; “We make a point of not letting designers speak to developers and start going: ‘is this possible?’. As soon as you do that, you start limiting your creativity”.

De stelling van Baines is op zich goed. Het creatief proces moet zo vrij mogelijk zijn. Maar ik kan zo al een situatie bedenken waarbij developer X uiteindelijk aan het buro van projectmanager Y staat om hem/haar te vertellen dat het development-team 2 weken extra nodig heeft omdat het voorgestelde design te gecompliceerd was en er dus extra lang over gedaan is.

Persoonlijk denk ik dat het belangrijk is om kennis te koppelen. Laat een designer vrij in zijn creatief proces, maar ben als designer slim genoeg om op vaste tijden te overleggen met een developer. Denk als developer mee in het gedachtegoed van een designer. “Kan niet” is dan vaak geen optie, maar werk samen naar een oplossing. Vaak is die oplossing krachtiger omdat hij niet alleen goed ontworpen is, maar ook goed ontwikkeld kan worden. Communicatie is key.  Volgens mij zorgt de juiste communicatie er niet voor dat een creatief wordt gelimiteerd, sterker nog – het maakt hem/haar beter. Moet een designer kunnen coden? Nee, naar mijn mening niet. Zoals een developer niet hoeft te kunnen designen.

Wat deze discussie voor mij uniek maakt is het feit dat hij enigzins parallel loopt met de ontwikkeling van het web. Van alles vanuit een individu naar kennisdeling. Waar het web zich nu klaar maakt voor de volgende stap; alle informatie op de juiste manier aan elkaar knopen – moeten wij dat ook….

…. of denk jij, Frank-ly lezer, daar anders over? :-)

(Computer Arts Magazine 151 is nu te koop in de winkel)

 Is dit een manier om de resultaten van je site te benchmarken en te achterhalen wat de bezoekresultaten zijn van websites van concurrenten? Lees verder voor een  review en het antwoord op deze vraag!

Nog enigszins met het voetbaldrama van het weekend in mijn hoofd, heb ik de sites van de drie grootste voetbalclubs in Nederland als voorbeeld genomen:

 
(klik even op het plaatje of de voorbeeldlink ter verduidelijking)

Wat zijn de mogelijkheden?

• Het is mogelijk om op regio en op tijd te filteren.
• Er is een schatting van het absolute aantal unieke bezoekers te aanschouwen, zien we de onderlinge verhoudingen tussen de clubs en zijn voor een deel de seizoensinvloeden te zien.
• Bij de subregio’s kunnen we de logische conclusie aflezen dat de meeste bezoekers van psv.nl uit Noord-Brabant komen. En dat de statistieken ook uit wijzen dat de fans van Ajax.nl meer uit Noord-Holland en van Feyenoord.nl uit Zuid-Holland afkomstig zijn.
• Tevens is per site te achterhalen waar bezoekers nog meer heen surfen en naar gezocht hebben. Leuk om te zien is dat bezoekers van PSV.nl ook geïnteresseerd in de site van de Brabantse zanger Guus Meeuwis.

Hoe werkt het?

In de FAQ van Google Trends voor websites staat hoe ze aan deze data komen:

Trends for Websites combines information from a variety of sources, such as aggregated Google search data, aggregated opt-in anonymous Google Analytics data, opt-in consumer panel data, and other third-party market research. The data is aggregated over millions of users, powered by computer algorithms, and doesn’t contain personally identifiable information.

Google geeft dus aan dat ze ook het populaire Google Analytics gebruiken voor het aggregeren van gegevens als de beheerder van een Analytics account toestemming geeft om de data te delen. De exacte gegevens binnen Analytics worden echter niet direct gebruikt voor Google Trends, aangezien dit de privacy regels schendt.

Google waarschuwt dat het product nog in de Google Labs-fase zit en dat er nog heel wat geëxperimenteerd moet worden om de kwaliteit van de cijfers te waarborgen. Hierdoor vangen ze gelijk af dat de cijfers nog kunnen verschillen van andere partijen van vergelijksites van bezoekverkeer, zoals Alexa, Compete en Comscore.

Spelen maar!

Ik ga Google Trends voor websites de komende tijd zeker verder testen naast de andere tools die al beschikbaar zijn. Natuurlijk is ook dit product weer volledig gratis te gebruiken. Het is zeker een manier om een beeld te krijgen van wat jouw site doet ten opzichte van die van anderen.

Wel moet je er altijd rekening mee houden waarschijnlijk niet accuraat zijn. Als ik de bezoekcijfers van een bepaalde site vergelijk met de cijfers binnen Google Analytics, dan verschilt dat enorm. Als je echter de periode wat langer maakt, dan zijn er wel overeenkomsten te zien qua trends.

Het kan zo zijn dat wellicht jouw site niet is opgenomen in de resulaten, aangezien Google bepaalde regels hanteert en het volume van bezoekverkeer op je site boven een bepaalde grens dient te liggen.

Wel vind ik het een beetje raar dat je de resultaten van de sites van Google zelf niet kunt achterhalen:

Worden die sites niet zo veel bezocht of zal daar een andere reden voor zijn? ;-)

Webanalisten.nl

Dit artikel is al eerder geplaatst op webanalisten.nl. De site waar ik samen met mijn vakbroeders over web analyse en belangrijker nog de optimalisatie van websites schrijf. Natuurlijk zal ik voor jou, lezer van Frank-ly, schrijven over mijn vakgebied. Maar zoek je verdere verdieping en meningen van anderen op dit gebied, neem dan eens een kijkje op webanalisten.nl!

Bij Rhinofly hebben we een passie voor Internet. Dat zeggen we veel, dat stralen we uit en dus is het waar. Echt.
Op een goede tweede plek en dicht daar achteraan vind je echter bij de meesten van ons een ongekende passie voor muziek.
Muziek als de benzine om de motor op gang te helpen, te laten versnellen of als koelvloeistof om even bij te komen.
Onze muzieksmaak, tja, die ligt wel wat uit elkaar.
Van Gotcha! naar NWA en via Armin van Buuren naar Modern Talking. Het kan je (soms helaas) allemaal overkomen. Het leidt tot neurieën of neuroses. Maar leuk is het wel!

Om het toch een beetje overzichtelijk en inzichtelijk te maken zijn we een tijdje geleden met wat collega’s begonnen met het scrobbelen van onze muziek via LastFM. Het levert een prettig stukje audio-mash op:

En zo leg ik af en toe mijn online oortje te luisteren bij mijn collega’s.
Voor het goede “funk/punk-spul” meldt je je bij Ronald, als mis je er op deze manier wel de extragratis luchtgitaarsolo die er bij hoort! Voor de “snoeihard rawwwwk” en de grunge moet je bij Frank wezen. Bas, Jan en Jurgen staan garant voor het betere aan “bliep-tuut”. En ik? Ik ben als “jongen van de straat” *proestkuch* meer van de hip-hop.

Wat heeft de Frank-ly lezer met muziek? Ik ben benieuwd!
En aan de collega’s zonder LastFM-profiel en scrobble-software: hup!