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...

Geslachtsziekte

@mvanselm Wow, dat is snel gegaan! Zoals een bevriende archivaris zou zeggen: je hebt de geslachtsziekte flink te pakken :-)

— Yvette Hoitink (@yhoitink) May 1, 2012

Drie maanden geleden blogde ik voor het eerst over mijn stamboomwebsite. Inmiddels is de 500ste pagina uit mijn toetsenbord gerold en staat van zo'n 160 mensen met de achternaam Van Selm een levensloop online. Ik heb er nog geen archiefinstelling voor van binnen gezien, want aan een internetverbinding heb ik genoeg om geboorten, dienstplicht, huwelijken en overlijden in de 19de en eerste decennia van de 20ste eeuw in beeld te krijgen: via Genlias kan ik op naam te zoeken in grote delen van de Nederlandse Burgerlijke Stand, op FamilySearch zijn scans van de bijbehorende akten te vinden en op Militieregisters.nl komen langzaam maar zeker de gescande inschrijvingsregisters van de Nationale Militie online.

Maar ik zou geen echte historicus zijn als ik niet méér wilde. Daarom begint het zo langzamerhand tijd te worden om mijn onderzoek van internet naar archiefinstellingen te verplaatsen. Ik wil verder terug in de tijd, om aan de hand van kerkelijke doop-, trouw- en begraafregisters — dé bronnen over personen vóór de invoering van de Burgerlijke Stand in 1811 — te achterhalen of de verschillende 'plukken' Van Selmen in Nederland afstammen van een gezamenlijke voorvader. En komt die ene voorvader uit Duitsland? Of uit de Achterhoek?

Voor de 19de eeuw wil ik de Burgerlijke Stand en Militieregisters voorbij: er staat een flinke duik in de archieven van successiekantoren, het kadaster, notarissen en rechtbanken op het programma. Aan de hand van overlijdensdata kan ik nagaan of er een memorie van successie is opgemaakt, een overzicht van bezittingen en schulden van een overledene dat door een belastingambtenaar werd opgesteld om te bepalen hoeveel successierechten er betaald moesten worden. Om de rekensommen gaat 't me niet, wel om de namen van de erfgenamen en hun relatie tot de overledene, en om het eventueel vermelde onroerend goed.

Dat onroerend goed kan ik nazoeken in het kadaster. Sowieso heb ik voor onderzoek in het kadaster al een 'verlanglijstje': de adressen die ik tegenkwam in geboorte- en overlijdensakten. De resultaten van al dat zoekwerk gaan ongetwijfeld aanknopingspunten bieden voor leuke knutselwerkjes met Google Maps, maar zo ver ben ik nog lang niet: eerst maar eens de weg zien te vinden in aanwijzende tafels, leggers, registers, naamlijsten en kaarten. Huizen vol historie, een gids voor huizenonderzoek in de provincie Utrecht, ligt inmiddels op mijn virtuele nachtkastje.

Het erven, kopen en verkopen van (on)roerend goed laat nog een paper trail achter, in notariële archieven: testamenten, akten van boedelscheiding, akten van verkoop en hypotheekakten. Over overlijden gesproken: als iemand bij zijn of haar overlijden minderjarige kinderen naliet, moest een toeziend voogd worden aangesteld. Als ook de tweede ouder overleed, diende bovendien een voogd te worden benoemd. Deze benoemingen werden in de periode 1811-1838 gedaan door vrederechters, daarna door kantonrechters — enter de rechtbankarchieven en mijn lijstje van (half)wezen dat ik op basis van Burgerlijke Standgegevens al heb opgesteld.

De lastigste klus wordt waarschijnlijk het opsporen van notariële akten van plaatsvervanging. Als een jongeman werd ingeloot voor de Nationale Militie maar de dienstplicht wilde laten vervullen door een plaatsvervanger, moest daarvoor een contract in de vorm van een notariële akte worden opgesteld. Hoe ik deze akten op het spoor moet komen zonder te weten welke notaris de akte opstelde, is me nog niet helemaal duidelijk. Ik weet vaak niet méér dan de woonplaats van de loteling in kwestie en dat hoeft niet de standplaats van de betrokken notaris te zijn.

Eén ding is wel duidelijk: ik ga nog heel wat uren doorbrengen in het Regionaal Historisch Centrum Vecht en Venen in Breukelen, het Regionaal Historisch Centrum Zuidoost Utrecht in Wijk bij Duurstede en Het Utrechts Archief in Utrecht. En volgend jaar op familiebezoek in Zuid-Afrika?

Googelen met een website

In de kerstvakantie ben ik aan een nieuwe website begonnen. Nee, ik maak me geen illusies: in het beginstadium zal-ie niet blijven, maar af komt-ie ook niet - een website is nooit 'klaar'. Bovendien is het een website met resultaten van mijn stamboomonderzoek, en 'n stamboom kun je - als je niet al te kieskeurig bent in hoofd- en zijtakken - aardig oneindig uitpluizen.

Bij gebrek aan een eigen webserver en omdat ik in vakantietijd weinig puf had mijn HTML-kennis grondig af te stoffen, besloot ik 't eenvoudig te houden en de gelegenheid aan te grijpen om eens met Google Sites te experimenteren. En ik moet zeggen: daar word ik niet eens ál te ongelukkig van. Het maken van een nieuwe site kan niet eenvoudiger: je logt in op Google Sites met je Google Account, drukt op de 'Create site'-knop, volgt de aanwijzingen op je scherm, en je site is klaar om gevuld te worden. Ook bij het maken en wijzigen van pagina's kan een kind de was doen.

Vanwege mijn stamboomthema hoef ik niet bepaald diep na te denken over wat er op een pagina moet komen te staan: het is eenvoudigweg de bedoeling dat in principe elke persoon uit mijn stamboom een eigen pagina krijgt. Biografisch woordenboek, wiki, zoiets. De gegevens die ik voor het vullen van zo'n pagina nodig heb, heb ik het afgelopen jaar al opgeslagen in Aldfaer: namen, plaatsen, jaartallen, familierelaties.

In Aldfaer blijven het echter vaak 'droge gegevens'. Ok, als twee kinderen van één ouderpaar op dezelfde dag geboren worden, schiet me nog wel "tweeling" door mijn hoofd. En 't valt me ook nog wel op als de overlijdensdatum van een moeder kort op de geboortedatum van haar jongste kind volgt ("complicaties bij de bevalling"). Maar het blijven toch vooral in feitjes uitgedrukte levens, het worden geen levensverhalen. Die verhalen kan ik, aan de hand van de feiten, wel schrijven op een website.

Onderaan elke persoonspagina staan de bronnen waarin ik de bouwstenen voor mijn verhalen gevonden heb. Genlias komt daarin regelmatig voorbij, maar vaker nog FamilySearch. Genlias biedt feiten: datum, plaats en de namen van kinderen, huwelijkspartners of overledenen en hun ouders. In de scans van de akten op FamilySearch ontdek ik wie de aangevers en getuigen waren, wie niet en wie wel kon schrijven (en dus de akte ondertekenen), op welk adres iemand geboren werd of overleed, wanneer en hoe een aanstaande echtgenoot zijn dienstplicht heeft vervuld, en andere bijzonderheden.

Niet alle (scans van) akten zijn even goed leesbaar. Om niet elke keer dat ik een akte raadpleeg het wiel en het buskruit opnieuw te hoeven uitvinden, maak ik van elke akte een transcript. Die transcripten zet ik ook op mijn site. Dat kan op verschillende manieren. De meest voor de hand liggende is om ze als websitepagina's op te nemen, maar als het aantal pagina's gaat groeien, loop ik vroeg of laat tegen de maximum omvang van een Google Site (100 MB) aan. Een tweede mogelijkheid is ze als bijlagen bij 'n pagina uploaden naar Google Sites, maar daarvoor geldt hetzelfde bezwaar. Een derde optie is ze online zetten in Dropbox of Box en ernaar linken vanaf mijn Google Site, maar dat is weer een aanslag op mijn gratis opslagruimte bij Dropbox of Box.

Daarom kies ik voor een vierde manier: ik maak mijn transcript in Google Docs en embed het Google Doc in mijn site. Documenten die je in Google Docs maakt, tellen namelijk niet mee voor de 1 Gigabyte gratis opslagruimte die je bij Google Docs hebt. En embedded documenten, zoals Google Docs, tellen niet mee voor de maximum omvang die 'n Google Site mag hebben. Bijkomend voordeel: als ik in een transcript een typefout ontdek, hoef ik die alleen in het Google Doc te corrigeren, want op mijn site verschijnt automatisch de nieuwste versie van het Google Doc.

Een ander probleem heb ik nog niet echt opgelost: hoe houd ik het personengedeelte van mijn site overzichtelijk? Een platte navigatie, zoals bij een wiki, levert op termijn een wel erg lange lijst pagina's op. Een rangschikking in familieverband gaat zorgen voor een navigatie van zeven of meer niveaus diep, ook niet het toppunt van overzichtelijkheid. En bovendien: hang ik de pagina's van kinderen dan onder die van hun vader of onder die van hun moeder? En waar laat ik echtgenotes? Noem me eigenwijs, maar ik weiger om vrouwen onder hun man te hangen... iemand 'n beter idee?

Ding 8: Delicious

In mijn eenpersoons huishouden waren wat dingen blijven liggen in de aanloop naar de lancering van Indischekamparchieven.nl, maar tussen het schoonmaken van keuken en badkamer, stofzuigen, dweilen, bed verschonen en planten verpotten door heb ik zowaar ook nog wat tijd weten te vinden om Delicious uit te proberen. En ik moet zeggen: 'k vind het gebruiksgemak groot.

't Is sowieso handig om m'n favorietenlijstje vanaf meerdere computers te kunnen raadplegen, want het gebeurt me regelmatig dat ik op m'n werk in mijn geheugen zit te graven naar een webadres waarvan ik weet dat het thuis in mijn bookmarks staat (of andersom). Het toevoegen van websites aan Delicious is een koud kunstje, zeker met de knop 'Save to Delicious' in mijn browser.

Voor interessante websites kan ik bovendien eenvoudig winkelen binnen Delicious: in mijn netwerk - tot nu toe alleen mijn werkkamergenote, maar dat gaat al de nodige mails met links schelen - en bij mijn subscriptions - 'k heb om te beginnen maar 'ns een abonnement genomen op de tag 'Nederlands-Indië'. Via de rss feeds die ik op mijn Netvibes-pagina geplakt heb, zie ik of er updates in mijn netwerk of bij mijn subscriptions zijn.

Webadressen uit beide overzichten kan ik eenvoudig toevoegen aan mijn eigen favorietenlijst door op 'save' te klikken. 'k Vind het wel prettig dat ik daarbij mijn eigen trefwoorden aan 'n webadres kan toevoegen, en niet vast zit aan de tags die iemand anders eraan toegevoegd heeft. Mijn vertrouwen in het tag-vermogen van de rest van de wereld wil namelijk nog niet echt groeien... maar daarin ben ik niet de enige ;-)