RDM Ondersteuning: de website

Bron: RDM-brochure University of Leicester

Na het trainen van mijn collega's is het inrichten, vullen en online brengen van een website over research data management de tweede grote klus binnen mijn project. Voor het maken van een aparte UvA-website over onderzoeksdata-management heb ik een aantal redenen:

• omdat in workshops of trainingen niet (altijd) alle aspecten van research data management de revue kunnen passeren, is het prettig om naar een online bron te kunnen verwijzen;
• een helpdesk zal niet 24/7 bemenst kunnen zijn, terwijl onderzoekers een website wel 24/7 kunnen raadplegen;
• de informatie op bestaande websites over onderzoeksdata en datamanagement is niet (altijd) afgestemd op een Nederlandse context of UvA-omstandigheden;
• op de website van de Bibliotheek stond wel een pagina over dataopslagvoorzieningen, maar onderzoeksdatamanagement omvat meer dan opslaan alleen en die ene pagina zou binnen de structuur van de Bibliotheekwebsite lastig uit te breiden zijn;
• informatie over onderzoeksdatamanagement op de Bibliotheekwebsite onderbrengen zou, ten onrechte, de indruk kunnen wekken dat het ondersteunen van onderzoeksdatamanagement aan de UvA alleen het werk van de Bibliotheek is.

Een aparte RDM-website dus... maar welke informatie moet daar te vinden zijn en welke indeling zorgt ervoor dat onderzoekers snel de pagina vinden die ze nodig hebben?

Net als bij het voorbereiden van de RDM-training van mijn collega's begin ik met een uitgebreid vergelijkend warenonderzoek, dit keer van bestaande universitaire webpagina's over research data management. Met het Nederlandstalige aanbod ben ik vrij snel klaar: eigenlijk bieden alleen de Universiteitsbibliotheken van Leiden en Utrecht meer dan een online equivalent van een (half) A4'tje. Mijn inspiratie komt - opnieuw - vooral uit Groot-Brittannië, van de universiteiten van Leicester en Bath en de London School of Hygiene and Tropical Medicine (LSHTM).

De kern van de RDM-website van de University of Leicester bestaat uit vier rubrieken: Create, Organise, Keep, en Find and Share. Die thema's vormen voor onderzoekers een heldere ingang, vanuit wat hij of zij met data wil gaan doen. Dat spoort met de adviezen over web task management van Gerry McGovern wiens nieuwsbrief ik al een tijdje met instemming lees: vul je website niet met wat jij allemaal te melden hebt, maar vraag je af wat een bezoeker op jouw website komt doen en richt je website(navigatie) zo in dat hij of zij dat snel en eenvoudig kán doen.

De RDM-pagina's van de University of Bath hebben een soortgelijke indeling als die van Leicester, maar daarnaast is op de openingspagina alle informatie ook nog eens gerangschikt naar stadium van het onderzoek: onder de vraag "What to do when..." staan in drie blokken links naar pagina's die relevant zijn tijdens het plannen, tijdens het uitvoeren en tijdens het afronden van een onderzoeksproject. Dat biedt onderzoekers een tweede ingang, vanuit het stadium waarin zijn of haar onderzoek zich bevindt. De RDM-website van de LSHTM blinkt vooral uit door volledigheid: deze website bevat informatie over onderwerpen die ik op andere RDM-websites niet of niet zo uitgebreid ben tegengekomen.

Op basis van met name deze drie websites zet ik een structuur voor de RDM-website van de UvA in elkaar. Basisinformatie die toepasbaar is in alle vakgebieden wil ik onderbrengen in vier secties: Plannen, Organiseren, Opslaan en Delen. Voor elk van deze secties maak ik een lijstje met onderwerpen (pagina's) die erin moeten komen. Informatie over ondersteuning en training komt, net als op de websites van Leicester en Bath, in een aparte sectie Ondersteuning. Naar voorbeeld van het centrale UvAweb en de website van de Bibliotheek komt er ook een sectie Disciplines. Daarvoor schrijven mijn informatiespecialistcollega's, als eindopdracht van hun training, elk een pagina over research data management in hun eigen vakgebied.

De basisteksten schrijf ik zelf. Dat doe ik in eerste instantie in een Worddocument, één pagina voor elke webpagina die er moet gaan komen. Om de haverklap raak ik in dat bestand de weg kwijt: ik scroll me een ongeluk om 'even' te kijken wat ik op een vorige of latere pagina ook alweer geschreven heb, en daardoor schiet het schrijven niet op. Nadat ik op het idee kom de teksten in een Google Site te zetten, verlies ik het overzicht niet meer en gaat het schrijven een stuk sneller. Ook kan ik, als ik bijna klaar ben, mijn collega's beter laten meekijken: voor hen is de Google Site een stuk prettiger om te bekijken dan een Worddocument waaraan maar geen einde lijkt te komen.

Aanvankelijk heb ik tijdens het schrijven steeds ten minste bovenstaande drie, en vaak nog meer RDM-websites open staan. Dat lijkt handig, maar te veel inspiratie blijkt verlammend te werken. Als ik mezelf erop betrap dat ik meer zit te vertalen dan dat ik eigen teksten schrijf, gooi ik mijn browser dicht en zoek ik de presentaties op die ik voor de training van mijn collega's gemaakt heb. Ik gebruik ze als handvat en schrijf slides uit tot lopende tekst, en controleer aan de hand van de slides of ik in de webtekst niets vergeten ben.

Tijdens het schrijven besluit ik de rubrieken Organiseren en Opslaan in elkaar te schuiven tot één rubriek Bewaren. Over het organiseren van bestanden heb ik niet genoeg schrijfstof om een aparte rubriek te rechtvaardigen; bovendien zijn organiseren en opslaan nauw met elkaar verbonden: opslaan zonder te organiseren is 'n slecht plan, en organiseren zonder opslaan wordt lastig. In een rubriek Introductie breng ik een pagina over het waarom van onderzoeksdatamanagement onder; in deze rubriek staan - naar voorbeeld van Bath - ook de pagina's Voor onderzoek, Tijdens onderzoek en Na onderzoek: pagina's met een selectie van links naar informatie die in elk van deze onderzoeksstadia van belang kan zijn. Naar deze introductiepagina's verwijs ik op de homepagina van de website.

http://rdm.uva.nl/

Na een paar dagen knippen en plakken van Google Sites naar content management systeem Hippo kan ik mijn collega's half juli melden dat de Nederlandstalige RDM-website online is. Beeldredacteur Monique Kooijmans zorgt ervoor dat de data-foto's van collega Janneke Staaks een mooie omlijsting van de website gaan vormen.

Daarmee zit fase één van de RDM-website erop. In fase twee komen de vakspecifieke pagina's erbij en krijgt de site een Engelstalige evenknie, in fase drie gaan we ons wagen aan online training...

Mobiel: app of site?

Als het antwoord op de vraag Moeten we mobiel? bevestigend is, dient de volgende vraag zich aan: op welke manier? Waarmee? Er zijn vier mogelijkheden: een app, een web app, een mobiele website en responsive web design.

Op een aantal terreinen lijkt de app de mobiele website de baas:

1. Een app is eenvoudiger toegankelijk dan een mobiele website: 'n klik op een pictogram is voldoende om de app te starten, terwijl voor een mobiele website een adres in een browser moet worden ingevoerd.
2. Een app kan meer functies van een telefoon gebruiken dan een mobiele website: niet alleen GPS en accelerometer, maar bijvoorbeeld ook de camera (denk aan Instagram) of de contactenlijst (bijvoorbeeld Whatsapp).
3. Een app kan offline werken, een mobiele website heeft een netwerkverbinding nodig.
4. Een app is beter te personaliseren dan een mobiele website.

Er zijn ook punten waarop een mobiele website het van een app wint:

1. (Het adres van) een mobiele website is makkelijker te vinden en eenvoudiger te delen dan een app.
2. Een mobiele website is toegankelijk vanaf elk mobiel apparaat, ongeacht besturingssysteem, terwijl een app speciaal voor een besturingssysteem moet worden gemaakt.
3. Een mobiele website is direct toegankelijk en voor gebruikers onderhoudsvrij, terwijl een app gedownload, geïnstalleerd en onderhouden moet worden.
4. Voor (naar verwachting) eenmalige interactie met een organisatie en voor het zoeken naar informatie nemen gebruikers hun toevlucht tot het web, niet tot apps; een app moet de schijfruimte en de moeite van het installeren waard zijn, mensen installeren een app (pas) als ze verwachten er regelmatig gebruik van te gaan maken en dat gebruik hen iets oplevert.

Is de stand hiermee 4-4 gelijk? Niet helemaal. Het eerste 'winpunt' van apps vind ik bijvoorbeeld niet erg overtuigend. Mensen installeren soms zoveel apps dat ze niet meer weten of ze een bepaalde app al geïnstalleerd hebben, laat staan waar ze die gelaten hebben. Bovendien is het niet overdreven ingewikkeld om een snelkoppeling naar een mobiele website op een tabblad van een mobiele telefoon of tablet te zetten. Een tussenweg is de mobiele web app, simpel gezegd: een als app vermomde mobiele website. Een web app nestelt zich na download en installatie als pictogram op een tabblad van telefoon of tablet, maar haalt z'n inhoud bij het opstarten van de app vanaf een webserver binnen (bijvoorbeeld de apps van Nu.nl).

Ook op het eerste 'winpunt' van mobiele websites valt af te dingen. Zoekmachines zijn (nog) niet ingesteld op mobiele websites. De rangschikking van zoekresultaten vindt plaats op basis van het aantal links naar een site, en dat zal voor een mobiele website lager zijn dan voor een desktop website. Een zoekopdracht via een browser op een mobiele telefoon of tablet zal dus primair desktop websites als resultaat opleveren. Wie vervolgens zo'n desktop website aanklikt, zal niet altijd automatisch naar de mobiele evenknie worden doorgeleid, want aan het maken van automatische redirects van volledige naar mobiele websites kleven ook nogal wat haken en ogen.

De gebruik(er)svriendelijkheidtesters van de Nielsen Norman group (NN/g) adviseren een app als gebruikers één specifieke taak moeten kunnen uitvoeren (bijv. het bestellen van een pizza), zo'n taak herhaald en frequent wordt uitgevoerd (bijv. elke week bestellen bij dezelfde pizzeria), meer telefoonfuncties dan GPS nodig zijn (bijv. de camera om een barcode te scannen), offline gebruik nodig is en/of informatie wordt verschaft die niet vaak verandert en (dus) lokaal opgeslagen kan worden.

Verandert je informatie vaak, wordt de informatie via een webserver geleverd en/of moeten meerdere samenhangende taken ondersteund worden? Dan is volgens NN/g een mobiele website de aangewezen weg. Als je 'm tenminste, vanwege de moeilijkheden met zoekmachines en automatische doorverwijzingen, ook letterlijk aanwijst door op een opvallende plaats op je desktop website een link naar je mobiele site op te nemen.

Als de informatie die je wilt bieden en de taken die je klanten moeten kunnen uitvoeren op je desktop website weinig verschillen van je wensen voor een mobiel platform adviseert NN/g responsive web design, een manier van websitebouw waarbij de rangschikking van paginaelementen automatisch wordt afgestemd op de grootte van het scherm waarop de webpagina bekeken wordt.

Verwante posts:
(Mobile) user experience
Moeten we mobiel?

Moeten we mobiel?

Op de eerste dag van de Amsterdamse editie van de Usability Week van de Nielsen Norman Group (NN/g), maandag 23 april, is Usability of Websites and Apps on Mobile Devices het thema. 's Ochtends draait het vooral om de vraag 'Moeten we mobiel, en zo ja, waarmee dan?'

Uit onderzoek van Pew Internet Research - die organisatie kwam al eens eerder voorbij op dit weblog - blijkt dat mensen mobiele apparaten grofweg op twee manieren gebruiken: browsing en searching. Onder browsing valt het 'ongerichte' en 'ongecompliceerde' gebruik van een smartphone of tablet, bijvoorbeeld het lezen van nieuws of het gebruik van sociale netwerken om de tijd te doden in 'n wachtkamer of op 'n perron. Searching is het voorzien in een specifieke informatiebehoefte die vaak wordt ingegeven door locatie of context: zijn er leuke boekwinkels in de buurt? Staat er nog genoeg geld op mijn rekening om dit boek te kopen? Leeft deze auteur nog?

Als mensen op een mobiele telefoon een bepaalde taak uitvoeren, bijvoorbeeld het plaatsen van een bestelling of het opzoeken van bepaalde informatie, slagen ze daarin beter als ze dat met een app of via een mobiele website doen dan wanneer ze een website gebruiken die bedoeld is voor een desktop computer. Voorwaarden daarvoor zijn wel dat de gezochte informatie niet uitsluitend op de niet-mobiele ('volledige') website beschikbaar is, dat de app of mobiele website goed is vormgegeven, en dat iemand niet de volledige website als zijn broekzak kent en daarom toch daaraan, ook op het kleine scherm van 'n telefoon, de voorkeur geeft.

Om te bepalen of het zinvol is om 'mobiel te gaan', zijn vier overwegingen van belang: budget, verkeer, gebruik en content. Als er geld is voor het (laten) maken en onderhouden van een app of mobiele website, 7 tot 10% van de bezoekers van een volledige website daar via een mobiel apparaat komt, die website gebruikt wordt om de tijd te doden of om kleine transacties te verrichten, en de inhoud van de website regelmatig verandert of informatie is die mensen nodig hebben als ze niet in de buurt van een desktop computer zijn, is een mobiel platform volgens NN/g een goed idee.

Maar welk platform? Een app of een mobiele site? Wordt vervolgd...

Verwante post:
(Mobile) user experience

(Mobile) user experience

"Good mobile user experience requires a different design than what's needed to satisfy desktop users. Two designs, two sites, and cross-linking to make it all work." Aldus usability-expert Jakob Nielsen over de verhouding tussen mobiele en 'volledige' websites, op 10 april van dit jaar in zijn tweewekelijkse column.

Een storm van kritiek — op Twitter komt de term Jakobrage voorbij — volgt. "Stripping out content from a mobile website is like a book author stripping out chapters from a paperback just because it's smaller. We use our phones for everything now; there's no such thing as 'this is mobile content, and this is not'", schrijft ontwerper en ontwikkelaar Josh Clark.

Web ontwikkelaar Bruce Lawson doet ook een duit in het zakje: "[I]s the mobile device so fundamentally different that you should make different websites for it, or is there only one Web that we access using a variety of different devices? (...) I disagree (mostly) with the idea that people need different content because they’re using different types of devices."

"The reason many 'full websites' are unusable on mobile phones is because many full websites are unusable on any device", legt Lawson de vinger op de zere plek. "[W]ebsite owners have long proved incontinent in keeping desktop websites focussed, simply because they have so much room. (...) If your normal site isn't minimal, functional, with everything designed to help the user complete a task, it's time to rethink your whole site. And once you've done that, serve it to everyone, whatever the device."

Het lezen van deze en andere stukken van mensen die het op punten hartgrondig en beargumenteerd met Nielsen oneens zijn, is mijn voorbereiding op twee dagen ondergedompeld worden in Nielsens usability-evangelie door een User Experience Specialist van de Nielsen Norman Group. Ik ga proberen te bloggen wat ik op 23 en 24 april heb opgestoken. Alleen nog een fatsoenlijke vertaling van mobile user experience zien te vinden — 'mobiele gebruikerservaring' klinkt toch een beetje alsof ik het ga hebben over de belevenissen van rondwandelende heroïnespuiters...