AppsWorld

Voor de AppsWorld conferentie was ik van 19 tot en met 23 oktober in London. Eerst een paar dagen met vrouw en kinderen Londen bekeken: Tower of London (de zes raven leven nog), Big Ben, London Eye, Trafalgar square, National Gallery, de wisseling van de wacht en veel tubes.

Dinsdagochtend vlogen mijn vrouw en kinderen weer naar Nederland en ik ging naar de AppsWorld conferentie die gehouden werd in Earls Court Exhibition Centre. AppsWorld is een tweedaagse conferentie en expositie die al 4 jaar wordt gehouden in Europa en Noord-Amerika. Het gaat over apps en app eco-systemen op elke manier: apps voor mobiel (Android, iOS), apps voor televisie, apps voor in de auto, games, HTML5, marketing, betalingen en nog veel meer.

Naast veel bedrijven die hun apps en spullen laten zien, zijn er ook workshops en presentaties. Ik heb er een paar gevolgd waarover ik hieronder meer zal vertellen. Maar nog eerst wat cijfers: ruim 8000 bezoekers, 250 bedrijven en meer dan 200 sprekers (waaronder Steve Wozniak). Deze sprekers werden per track ingedeeld, zoals API strategies, HTML5, Developer World, Tech World, Droid World. Sommige tracks daarvan waren alleen toegankelijk met premium passes.

Dinsdagmorgen begon met verschillende openingstoespraken. Van verschillende sprekers die dag en woensdag ben ik de volgende interessante/opmerkelijke feiten of meningen te weten gekomen:

Meerdere sprekers dachten dat HTML5 steeds meer binnen een mobiele app gebruikt zou gaan worden. Deels komt dit door het feit dat er 2 grote en verschillende mobiele platformen zijn (iOS en Android) en het ontwikkelen voor 1 platform (HTML5) is goedkoper dan ontwikkelen voor 2 platformen.  Verder is ontwikkelen voor Android duurder dan voor iOS of ontwikkelen in HTML5. Dit komt voor een deel door de fragmentatie binnen Android. Maar, de klant verwacht wel een “echte” app die uit een App Store komt. Aan die wens is dus tegemoet te komen door een “echte” app als schil te gebruiken voor de HTML5 app (net zoals wij doen binnen de “Leiden Univ” app).

Naast HTML5 waren er nog andere oplossingen om voor meerdere platformen tegelijkertijd te ontwikkelen. Microsoft had een praatje over crossplatformdevelopment met hun Azure platform. Hiermee is een crossplatform app ontwikkeld voor een rugby team wat er indrukwekkend uitzag (zowel de app als het team). AppMachine heeft een andere oplossing, waarmee je met “building blocks” een crossplatform app in elkaar zet. Dit Nederlandse bedrijf (in de “Fryslân Valley”) was goed vertegenwoordigd en had een mooi product, waarmee je op basis van een website een app kon laten genereren.

De betaalmodellen van apps veranderen ook: het freemium model wordt steeds populairder. 25% van de Android apps en 45% van de iOS apps is nog betaald, de rest is gratis of freemium. Android ontwikkelaars verdienen vooral aan contract werk, niet aan de verkoop van apps. Ook is er nu een mogelijkheid om via Amazon reseller te worden en daarmee geld te verdienen. Paypal had ook een API om binnen een app geld over te maken.

Er wordt steeds meer gezocht naar technologie die niet in de weg zit. Hiervan is Google Glass een duidelijk voorbeeld. Dit is echt bedoeld om de hele dag te gebruiken. Tijdens het praatje over Google Glass bleek het vrij simpel of juist heel moeilijk te zijn om een app te maken voor Google Glass. Dit kwam omdat er 3 manieren zijn om dit te doen, die ook nog ’s door elkaar lopen. Het makkelijkst is om de mirror API te gebruiken, waarbij je eigenlijk op je eigen server bepaalde data klaar zet die via een REST service opgehaald wordt. De mogelijkheden zijn beperkt. Je kan ook de Android Foundation gebruiken, wat je ook gebruikt bij programmeren voor Android. En dan heb je nog de GDK, maar die is nog niet klaar.

De marketing van apps kwam ook aan bod; er was een presentatie van de (vervelende) CEO van ooVoo over SoLoMo. ooVoo heeft 80 miljoen geregistreerde gebruikers, dus ondanks die CEO doen ze toch iets goed.

Over de gebruikservaring van mobiele apps was een heel interessante presentatie van de BBC. Daarin werd duidelijk dat ze eerst veel UX aanpassingen deden en dat ze daar nu op terugkomen omdat het veel extra werk oplevert. Wel vonden ze het belangrijk om een duidelijk thema of terugkerend element te hebben binnen hun mobile apps. Dat deden ze nu door (subtiel) kleurgebruik en 1 custom element. Verder gebruiken ze veel web content binnen hun apps, zoals al eerder aangegeven werd. Het voordeel is dat de content dan altijd up-to-date is. Verder hadden ze als motto: de gebruiker wil de app gebruiken, dus zit hem/haar niet in de weg.
In een paneldiscussie werd daarna duidelijk dat men dacht dat de interactie steeds meer zou gaan naar praten tegen de computer/mobiel. De huidige generatie heeft daar nog wel problemen mee (bang voor reactie van anderen), maar het bleek dat dat niet meer speelde bij de jongere generatie. Ook dacht men dat bij scherminteractie gestures steeds belangrijker worden.

Het interview met Steve Wozniak was erg druk bezocht maar wel interessant. Hij is een echte geek en dat laat ie ook duidelijk merken. Zo heeft ie 2 horloges om, een iPod nano en een Nixie watch. Hij denkt dat smart watches de toekomst zijn, waarbij ze aan de binnenkant open kunnen klappen zodat gebeld kan worden. Ook zou het horloge continu mee kijken en je (als een goede vriend) opmerkzaam moeten maken op dingen; als het een taartenwinkel ziet je laten weten dat je nog een taart moet kopen, maar als er een mooi meisje voorbij komt dit ook laten weten. Techniek moet alles zo makkelijk mogelijk maken en wordt steeds persoonlijker; “who do you ask life’s questions? It starts with G-O and it is not God”

Het was een leuke tijd waarin ik veel gezien en geleerd heb. De nadruk lag vooral op Android en iOS, maar Windows Phone en Blackberry waren ook aanwezig. Wat betreft marktaandeel stellen die (nog) niet / niet meer zoveel voor binnen mobiele apparaten.

Het web is niet meer

Het web is niet meer. Althans, niet meer zoals het vroeger was.

Vroeger, toen moesten er allemaal trucs uit gehaald worden om ervoor te zorgen dat een website op verschillende (versies van) browsers het goed deed en er goed uitzag. Vroeger, eind jaren 90 en begin 2000, toen de browser wars in volle gang waren en je als sitebouwer moest weten welke feature op welke versie van welke browser bestond. Vroeger, toen je meer tijd kwijt was om een website er op elke browser goed uit te laten zien dan met het hele design en ontwerp van de site zelf. Vroeger, toen iedereen alleen nog maar een browser had op zijn PC. Of hooguit een WAP browser op je mobiele telefoon die je niet gebruikte omdat het zo traag was en de sites zo slecht.

Vroeger was alles beter….

De tijden zijn veranderd. Het web verandert mee. Het web zoals het was, is niet meer(!)

Het bouwen voor een versie van een browser behoort tot het verleden. Geen browser sniffing meer nodig, dat zou iedereen wel moeten beseffen. Tegenwoordig is het voldoende om te checken op features.

Nu zijn er heel andere problemen, die gelukkig gepaard gaan met goede oplossingen. En als alle sitebouwers weten en gebruik maken van deze oplossingen, dan ziet de toekomst van het web er heel zonnig uit.

Welke problemen zijn er dan? De meeste browsers houden zich goed aan de W3C standaarden. Er zijn er wel die voorop lopen en features ingebouwd hebben die nog niet tot een (officiële) W3C standaard behoren, maar dat zijn kleine problemen die met wat extra typen op te lossen zijn (bijvoorbeeld het stylesheet element ‘column-count‘ heet in FireFox ‘–moz-column-count’ en in WebKit browsers zoals Chrome en Safari ‘–webkit-column-count’. Die moeten dus in een stylesheet alle drie vermeld worden, wil het op de meeste browsers goed werken).

Het grote probleem van vandaag (en morgen) is dat je website niet alleen meer bekeken wordt op een PC met een scherm van 1024×768 of 1366×768 (meest populair een paar jaar terug en in 2013 nog goed voor 33% van de PC’s) of nog groter (nu ruim 40% van de PC’s), maar ook steeds meer op mobiele apparaten. Deze hebben vaak schermen niet breder dan 320 points (nee, geen pixels!). En, wat vaak vergeten wordt, ze werken niet met een muis! Dat betekent dus dat de links en knoppen die gebruikt worden eigenlijk minstens 40 points breed en hoog moeten worden om goed aantapbaar te zijn.

Gelukkig zijn er technieken beschikbaar om met deze problemen om te gaan: HTML5, CSS3 en JavaScript. Samen bieden ze diverse mogelijkheden om op basis van afmetingen en resolutie van het scherm het design van de site aan te passen, zodat dezelfde site op een PC met groot scherm of op een mobiel met een (relatief) klein scherm goed leesbaar is en goed werkt. Een webdesign benadering die gebruik maakt van deze mogelijkheden is Responsive webdesign. Deze term is bedacht door Ethan Marcotte in 2010. Het houdt in dat de website zich aanpast aan de omgeving waarin deze getoond wordt met behulp van flexibele grids, flexibele afbeeldingen en CSS3 media queries.

Responsive webdesign werkt met relatieve eenheden (percentages en ems) in plaats van absolute eenheden als pixels. Hierdoor wordt de breedte en hoogte van de elementen aangepast aan de breedte (en eventueel hoogte) van het scherm. Zo kunnen bepaalde elementen bij een breed scherm naast elkaar staan en bij een smaller scherm onder elkaar door gebruik te maken van float in het stylesheet.

Ook werkt Responsive webdesign zoals gezegd met CSS3 media queries. Hiermee kunnen stijlen afhankelijk gemaakt worden van het medium dat gebruikt wordt. Dus voor een scherm kleiner dan 400 points breed kunnen stijlen gedefinieerd worden die bepaalde plaatjes verkleinen of bepaalde elementen onzichtbaar maken.

De ideeën en de technieken zijn er dus, maar het vraagt wel een hele andere manier van denken over een website. Mijn mening is dat er niet begonnen moet worden met hoe een site er uit moet zien, maar welke content getoond moet worden. Dus ga uit van de content. Hier biedt HTML5 ook hele goede ingangen omdat hier niet meer de presentatie voorop staat, maar de betekenis. Oftewel je kan in HTML5 aangeven dat iets belangrijk is, of dat het een header, footer, navigatie of een figuur is, maar je doet geen uitspraak over de presentatie in de HTML (dus geen <B> om iets belangrijk en dikgedrukt te krijgen). De presentatie wordt geheel geregeld door stylesheets en eventueel JavaScript.

Content en semantiek kunnen dus geheel gescheiden worden van de presentatielaag. Dit heeft grote voordelen bij het aanpakken van het grote probleem van vandaag (en morgen): veel verschillende schermgroottes en resoluties. Met JavaScript kan de interactielaag aangepast worden aan de mobiele apparaten. Deze werken immers niet met een muis! Je kan dus niet gebruik maken van het feit dat de gebruiker zijn muis over een element op je website beweegt, maar je kan wel weer gebruik maken van allerlei andere interacties die niet met een muis kunnen, zoals vegen of tappen met 2 vingers.

De scheiding tussen content/semantiek, presentatie en interactie heeft nog meer voordelen:

  • Zoekmachines kunnen beter indexeren, omdat ze verschil zien tussen de echt belangrijke teksten, en teksten voor navigatie en minder belangrijke teksten (zogenaamde aside)
  • De inhoud (content) is makkelijk aan te passen door iemand zonder veel verstand van HTML
  • Een andere presentatie vorm is makkelijker te verwezenlijken
  • De interactie is aan te passen aan nieuwe mogelijkheden, zoals bijvoorbeeld voorlezen of stembesturing

Responsive webdesign gaat uit van de website in zijn geheel, waarbij elementen verkleind of uitgezet worden als het scherm te klein is voor alles. Dit heeft als nadeel dat alle HTML, plaatjes en javascript geladen moeten worden, ook op een mobiel met slechte netwerk verbinding. Een andere benadering is mobile first: ontwerp/bouw voor het kleinste scherm (een mobiel) en voeg elementen toe naarmate het scherm groter wordt. Dit heeft als nadeel dat de wat minder capabele browsers (oude versies of bij mensen die bijvoorbeeld javascript uit hebben staan) alleen de mobiele versie zien.

Ik denk dat een derde manier de beste oplossing is: ga niet uit van de hele site en verklein of laat weg (responsive webdesign) en ga ook niet uit van het kleinste scherm (mobile first), maar ga uit van de inhoud: content first. Hoe zou dat kunnen werken:

  • Bij ontwerp en bouw wordt uitgegaan van de content
  • De content die belangrijk is, wordt eerst in betekenisvolle blokken opgebouwd. Hier kan prima HTML5 voor worden gebruikt. Content die niet altijd (dus niet op elk apparaat) getoond wordt, wordt nog buiten beschouwing gelaten. Denk hierbij aan aside blokken of sommige navigatie blokken. De volgorde van de blokken moet logisch zijn, maar de correcte plaatsing op het scherm gebeurt later.
  • Plaatjes of video kunnen ook geplaatst worden, maar niet op hele hoge resolutie.
  • Om de content nog toegankelijker te maken zou gebruik kunnen worden gemaakt van microdata en ARIA attributen
  • Met stylesheets en media queries wordt de presentatie van de blokken gemaakt voor verschillende schermgroottes. Hier kunnen de technieken van responsive webdesign goed gebruikt worden. Er wordt bij deze stap al rekening gehouden met extra content, zoals asides.
  • Met javascript kan nu de extra inhoud en/of betere versies van plaatjes of video ingeladen worden. Bijvoorbeeld, er kan op een groot scherm een aside geladen worden. Ook kunnen de hoge resolutie versies van plaatjes ingeladen worden, als het doelsysteem dit toelaat (denk aan of het scherm het aan kan en of de netwerkverbinding goed genoeg is)
  • Met javascript kan een extra interactie laag aangebracht worden, bijvoorbeeld voor ondersteuning van swipen of tappen met meerdere vingers voor mobiel, maar ook voor mouseovers voor de desktop.

Alle extra content kan met technieken als media queries en javascript geladen worden, zodat webbrowsers die daar geen capaciteit voor hebben, er ook niet mee belast worden.

Content first vereist een andere manier van websites ontwerpen en bouwen. Maar de technieken zijn voor een groot deel bij de meeste webbrowsers al beschikbaar. Oudere webbrowsers worden ook goed getoond, maar hebben wellicht minder functionaliteit. Het belangrijkste, namelijk de content, wordt goed afgebeeld.

Op naar een zonnige toekomst!

PS: na het schrijven van deze blog kwam ik erachter dat de term “content first” al eerder werd gebruikt. Zeker de moeite waard om ook deze artikelen te lezen, waarbij de invalshoek net anders is:
https://www.frankwatching.com/archive/2012/10/09/van-mobile-first-naar-content-first/
https://www.frankwatching.com/archive/2013/08/16/content-first-van-responsive-design-naar-dynamische-website/
https://www.marketingfacts.nl/berichten/content-first-bij-de-nieuwe-responsive-website-van-ing-commercial-bank
https://www.lukew.com/ff/entry.asp?1430

Werken aan je competenties met IPMA

PM

Toen ik enkele jaren geleden werd overgeplaatst van de sector Bijzondere Collecties naar Digitale Diensten en er officieel Projectmanager in mijn functieomschrijving kwam te staan, werd ik ook in de gelegenheid gesteld om een cursus projectmanagement te volgen. Ik had bij mijn vorige werkgever al Prince2 examen gedaan en hoewel ik hier zeker wel wat aan heb gehad, vond ik de bijbehorende cursus zo saai dat ik niet direct stond te springen. Het ging er daarin toch vooral om heel veel termen uit je hoofd te leren. Mijn collega projectmanagers hadden echter alle drie al eens een cursus gevolgd die gericht was op het verbeteren van competenties van projectmanagers en zij verzekerden mij dat dit wel erg nuttig was geweest. Aan de slag dus. Na een vergelijking van de twee bekendste methodes, IPMA en projectmatig creëren, viel de keus op de eerste. Ik mocht me inschrijven voor het examen IPMA D en ter voorbereiding hierop bezocht ik 4 cursusdagen in Utrecht.

Was dat nuttig? Ja, wel zeker! De IPMA certificering bestaat uit een mix van harde en zachte competenties. Tot de harde vaardigheden behoort onder meer het maken van een planning, begroting en eindbalans. De zachte vaardigheden gaan over zaken als teambuilding, onderhandelen en het luisteren naar klanten. Sommige onderwerpen waren nieuw voor me, andere al in meer of mindere mate bekend, dankzij Prince2, of omdat we er zelf al mee werken in onze projecten. Maar het is goed om een keer het complete verhaal te horen en – belangrijker nog – er over te discussiëren en er mee aan de slag te gaan in huiswerkopdrachten. Op die manier blijft de stof echt goed hangen.

Tijdens de cursus was er ook voldoende tijd ingeruimd om ervaringen uit te wisselen over succes- en faalfactoren in projecten. En dat was leuk én zinvol. Mijn mede-cursisten kwamen uit de meest uiteenlopende sectoren, van energiecentrale en riolering tot Topdesk en Heineken. Zij vonden het wel amusant, een bibliotheekmedewerkster die ‘in de oude boeken zit’. Nu hebben allemaal wel eens de neiging om op te kijken naar commerciële bedrijven, onder het mom van ‘met zulke grote budgetten zullen ze wel veel professioneler werken’. Maar ik kwam er al snel achter dat dit een misverstand is. Uiteraard zijn onze budgetten in de meeste gevallen veel kleiner, maar ik ben er wel achter gekomen dat onze projecten zeker niet slechter lopen.

Zo bleek iedereen problemen te ondervinden met het maken van een realistische planning. We zijn blijkbaar allemaal geneigd te onderschatten hoe lang iets duurt, ook al hebben we het vaker gedaan. Dit staat bekend als de ‘planning fallacy’. We hebben een hele sessie besteed aan het uitwisselen van tips en ideeën om deze valkuil te voorkomen. Een heel goed idee vond ik het organiseren van een planningsworkshop. Het hele team maakt tijdens een sessie van een halve of hele dag gezamenlijk een planning. Dit wordt gedaan met behulp van drie soorten post-its die op een wandvullend vel papier worden geplakt:

  • Groene voor beslissingen (en wie neemt deze?)
  • Roze voor de benodigde input (en wie is hiervoor nodig?)
  • Gele voor activiteiten (Wie? Minimale duur? Maximale duur)

Samen definieer je op deze manier alle mijlpalen in het project. Vervolgens schrijf je op een flipover wat de op te leveren producten en diensten zijn voor de verschillende mijlpalen. Alle input wordt ten slotte door de projectleider verwerkt tot een planningsdocument. Uiteraard dient een dergelijke sessie voorzien te worden van voldoende koffie, thee, koeken en een borrel achteraf. Op deze manier is de workshop namelijk ook bevorderlijk voor de teambuilding.

Mij lijkt een dergelijke sessie in elk geval heel nuttig. Nu alleen nog afwachten wat mijn eerstvolgende project gaat worden, zodat ik het geleerde in de praktijk kan brengen!

Het meten van wetenschap

Het onderwerp “kwaliteit en impact van wetenschappelijke publicaties” staat de laatste tijd veel in de aandacht. De discussie richt zich vaak op de vraag of het uberhaupt wel mogelijk is om een abstract gegeven als wetenschappelijke kwaliteit in cijfers uit te drukken. Het CWTS in Leiden heeft in 2012 een interessant rapport over dit onderwerp geschreven. Ook tijdens het OAI8 congres, dat ik in juni heb bijgewoond, was er veel aandacht voor dit onderwerp.

In zijn presentatie “Scholarly Impact Measures: An Overview” benadrukte Johan Bollen van de Universiteit van Indiana (voorheen ook de Los Alamos National Library) dat wetenschappelijke impact in feite een heel ongrijpbaar fenomeen is. Wetenschappers produceren bepaalde ideeën en bepaalde nieuwe informatie. Niet alle ideeën zijn natuurlijk even waardevol. Is het op een of andere manier mogelijk om aan te geven wat de waarde of de relevantie is van een idee? Volgens Bollen komt de relevantie van een bepaald idee vooral tot uitdrukking via de status die een wetenschapper verwerft dankzij de publicatie van deze ideeën. De kwaliteit van meetinstrumenten hangt dus samen met hoe goed of hoe slecht deze reputatie onder vakgenoten in beeld wordt gebracht.

Traditioneel worden de wetenschappelijke kwaliteit en impact afgelezen aan de hand van citatiedata (met indicatoren zoals de Journal Impact Factor en de H-Index). Deze citatiegegevens hebben verschillende praktische nadelen. Als een publicatie verschijnt duurt het uiteraard enige tijd voordat er andere publicaties kunnen verschijnen die dit artikel weer citeren. De citaties worden meestal ontleend aan Web of Science of aan Scopus, maar het is bekend dat publicaties op het gebied van de geesteswetenschappen en de sociale wetenschappen, en teksten die niet in het Engels zijn geschreven, niet goed zijn vertegenwoordigd in deze databases. Het belangrijkste probleem is volgens Bollen echter dat de lijst met high impact journals vaak helemaal niet overeenkomt met wat wetenschappers zelf als belangrijke tijdschriften ervaren.

De wetenschappelijke communicatie verplaatst zich meer en meer naar het web, en wetenschappelijke ideeën worden tegenwoordig ook verspreid via weblogs, via repositories en via social media. Het is dus eigenlijk niet meer van deze tijd om impact alleen maar te beoordelen via traditionele publicaties. Een alternatieve methode is, bijvoorbeeld, om te kijken naar het aantal downloads van een digitale publicatie. Deze gegevens zijn over het algemeen gewoon beschikbaar, zowel bij de institutionele repositories als bij de uitgevers. De mogelijkheden van download-statistieken in deze context zijn onder meer onderzocht in het project MESUR, en ook in PIRUS en COUNTER (waarin de Journal Usage Factor is ontwikkeld, als tegenhanger van de Journal Impact Factor).

Hiernaast geeft ook de vertegenwoordiging in social media (“attention data”) een goed beeld van het gebruik en van de impact. Deze laatste categorie data wordt meestal aangeduid met de term ‘altmetrics’. Het kan dan gaan om twitterberichten over artikelen, of over blogposts met verwijzingen naar publicaties. Het bedrijf altmetrics.com, dat wordt gefinancierd door de Macmillan Group, heeft zich tot doel gesteld om zo veel mogelijk van dit soort gegevens uit social media posts in te zamelen. Het doel van Altmeric.com is in eerste instantie om de data te verzamelen. Het bouwen van applicaties rond deze data laten zij aan andere partijen over. Interessant voor de UBL is dat Ex Libris één van de partijen is die gebruik maakt van de gegevens van altmetrics.com. Er bestaat al een code extension voor Primo waarmee het mogelijk wordt om altmetrics-gegevens weer te geven bij de zoekresultaten in Primo. Zo kan bij ieder artikel worden weergegeven hoe vaak er over die publicatie is getweet, hoeveel mensen die titel in hun Mendeley-bibliotheek hebben opgenomen, en hoe vaak het artikel in een blogpost is genoemd. Dit geeft uiteraard ook een heel goed beeld van de impact van het artikel.

Bollen eindigde zijn lezing bij OAI8 met een interessante gedachte. Aangezien wetenschappers zelf over het algemeen het beste weten welke collega’s het beste werk produceren is het misschien beter om al het onderzoeksgeld dat beschikbaar is in gelijke mate te verdelen over de gehele onderzoekspopulatie en om de gemeenschap vervolgens zelf te laten besluiten waar subsidies naar toe gaan. Dan zijn er ook geen metrics meer nodig …

Open Annotation Collaboration

Dit is een tweede post in de serie over dingen die mij opvielen tijdens OAI8. In deze post ga ik in op Open Annotation Collaboration (OAC). Over deze standaard heb ik tijdens OAI8 een presentatie en een workshop bijgewoond. Beide werden gegeven door Rob Sanderson van de Los Alamos National Library.

OAC is eigenlijk al een aantal jaren oud. Het werk begon rond 2010, en is min of meer onstaan in de periode waarin Herbert Van de Sompel als visiting researcher verbleef bij DANS en bij het Huyghens Instituut. Veel onderzoekers op het gebied van de digital humanities houden zich bezig met het annoteren van bronnen, zoals digitale edities van literaire teksten, of reproducties van kunstwerken. Vaak worden er daarbij specifieke systemen gebruikt en kunnen die annotaties niet gemakkelijk worden hergebruikt. Maar het annoteren van bronnen is uiteraard een breder fenomeen. In systemen zoals Flickr of FaceBook kunnen er uiteraard ook opmerkingen bij bronnen worden geschreven. Ook hier speelt het probleem dat deze opmerkingen vastzitten aan die specifieke omgevingen. Het doel van OAC is om een manier van annoteren te ontwikkelen die generiek is en die los van het systeem waarin deze bronnen worden beheerd.

Open Annotation is gebaseerd op een simpel data model, en maakt ook volledig gebruik van de architectuur van het web. In de visie van W3C bestaat het web uit entiteiten die worden geïdentificeerd door een URI. In het data model van Open Annotation bestaan alle componenten van de annotatie dus uit ‘Web Resources’ met een eigen URI. De basisgedachte is dat een annotatie bestaat uit twee onderdelen. De eerste bron is de annotatie zelf is (de ‘Body’). De tweede bron is datgene is dat wordt geannoteerd (de ‘Target’). Deze eerste twee bronnen worden bij elkaar gebracht door een derde Web Resource, namelijk de ‘Annotation’. Een ‘Target’ kan bijvoorbeeld een scan zijn van een schilderij, en een “Body” is dan een tekst waarin wordt toegelicht wat er op het schilderij te zien is. Een annotatie kan natuurlijk ook gaan over specifieke details van het schilderij. OAC voorziet ook in technieken waarmee specifieke onderdelen van bronnen kunnen worden geaddresseerd (zogenaamde ‘selectors’).

intro_model

Recentelijk zijn er nog een aantal termen aan het data model toegevoegd. Het is nu ook mogelijk om het doel van de annotatie op te geven (gaat het om wetenschappelijk onderzoek? Of is het een soort ‘Bookmark’ of geheugensteun?). Er zijn ook termen toegevoegd waarmee de “provenance” kan worden vastgelegd (de persoon die verantwoordelijk is voor de annotatie). Hiernaast is ook de term “SemanticTag” gedefinieerd, zodat er bij het annoteren ook termen uit bestaande ontologieën kunnen worden gebruikt.

Open Annotation is voor de UBL een heel interessante techniek. Terwijl de technologie rond nanopublicaties (die ook is gebaseerd op  Semantic Web technologie) toch voornamelijk toepassingen lijkt te hebben binnen de natuurwetenschappen, kunnen onderzoeksgroepen binnen de Geesteswetenschappen via OAC ook een stap zetten naar Linked Data en naar herbruikbare en gestructureerde onderzoeksannotaties. Een goed voorbeeld van humaniora-onderzoek waarin OAC momenteel al wordt toegepast is het Emblemata-project, waar onder meer ook onderzoekers van de Universiteit Utrecht aan deelnemen. Er zijn inmiddels ook al een aantal open source applicaties beschikbaar waarmee vrij gemakkelijk Open Annotations kunnen worden aangemaakt, namelijk SharedCanvas en in Pund.It. Voor bijvoorbeeld kunsthistorici die heel gedetailleerd bepaalde uitsnedes van kunstwerken willen beschrijven, of voor literatuurcritici die commentaar geven op specifieke tekstfragmenten, kunnen dit heel nuttige tools zijn.

Repositories gelijkzetten

In juni bezocht ik het Open Archives Initiative congres in Genève. Dit congres richt op innovatieve technologie op het gebied van wetenschappelijke communicatie, en wordt om de twee jaar georganiseerd. OAI vond dit jaar al weer voor de achtste keer plaats. In verschillende blogposts bespreek ik een aantal interessante nieuwe ontwikkelingen die ik daar heb gehoord.

resourcesync_logo

Voorafgaand aan OAI8 waren er een aantal workshops, en de workshop die ik zelf heb bijgewoond ging over het nieuwe protocol ResourceSync. Het initiatief voor de ontwikkeling van deze techniek is genomen door de mensen van OAI (onder meer Herbert Van de Sompel, Simeon Warner en Carl Lagoze). Zij waren eerder ook verantwoordelijk voor belangrijke standaarden en protocollen zoals OAI-PMH, OAI-ORE en Memento. Aan de ontwikkeling van ResourceSync hebben inmiddels ook partijen als NISO, OCLC, de Library of Congress, Cottage Labs, Ex Libris en JISC bijgedragen.

ResourceSync is, simpel gezegd, een protocol waarmee de inhoud van verschillende repositories kan worden gesynchroniseerd. De site ArXiv.org, waarop veel publicaties in open access worden gepubliceerd, heeft een aantal mirror sites opgericht, onder meer vanuit de LOCKSS-gedachte (“Lots of copies keep stuff safe”). Arxiv ondervindt momenteel veel problemen bij het kopiëren van die bestanden naar de andere servers. Ook vanuit Europeana is interesse getoond voor ResourceSync. Voor de Europeana-portal worden op dit moment alleen nog de metadata van de verschillende aangesloten instellingen geharvest. Europeana wil op termijn ook graag de digitale objecten zelf gaan harvesten. ResourceSync probeert in dit soort situaties een oplossing te bieden.

Zoals bij de meeste standaarden is ResourceSync gebaseerd op een data model. Dit model is in eigenlijk heel simpel. Op de eerste plaats is er een “Destination” server. Deze server wil graag documenten of gegevens overnemen van een “Source”. Er wordt onderscheid gemaakt tussen een “baseline synchronisation” en een “incremental synchronisation”. Het eerste geval is in feite het begin van het synchronisatieproces. Alle aangemerkte bestanden worden daarbij direct overgebracht van de “Source” naar de “Destination”. Na deze initiële synchronsatie ontstaat er een situatie waarin de ontvangende server goed op de hoogte moet blijven van toevoegingen of wijzigingen op de bron-server. Hierbij kan gebruik worden gemaakt van een pull-mechanisme, waarbij de Destination server een verzoek om informatie verstuurt, of van een push-mechanisme, waarbij de Source een bericht naar de Destination stuurt op het moment dat er nieuwe of gewijzigde bestanden zijn. Wanneer een server met ResourceSync wil werken moet deze server er voor zorgen dat er altijd een actuele siteMap is waarop een volledige inventaris te vinden is van de bronnen op de site, samen met de datum van de laatste wijziging.

ResourceSync is op dit moment nog in de ontwikkelfase. Het theoretische model is al heel goed uitgedacht, maar de onderliggende techniek is nog niet volledig uitgewerkt. Er zijn ook nog geen concrete implementaties van ResourceSync. Er is op dit moment nog onduidelijkheid over hoe bestanden concreet moeten worden overgeheveld. Bestanden kunnen individueel worden gedownload, maar door de “Source” server kunnen er eventueel ook zip-mappen met gewijzigde files worden klaargezet.

Wat tijdens de workshop wel duidelijk werd benadrukt is dat met ResourceSync een aantal van de huidige nadelen van OAI-PMH kunnen worden opgelost. OAI-PMH gaat op de eerste plaats alleen over metadata. Er zijn wel pogingen geweest om ook digitale objecten over te dragen via OAI-PMH, maar dat bleek technisch heel complex. Bij OAI-PMH moeten alle metadata worden opgenomen als onderdeel van de response, en zijn er beperkingen aan het aantal records dat per response kan worden verstuurd. Hierdoor onstaan er vaak vertragingen. Belangrijk is ook dat er bij OAI-PMH geen push-mechanisme bestaat. Instellingen die willen harvesten moeten dus periodiek polsen of er nieuwe of aangepaste metadata zijn. OAI-PMH is al meer dan tien jaar oud en de web-technologie is inmiddels natuurlijk verder geëvolueerd. Gezien de huidige problemen rond OAI-PMH is het niet ondenkbaar dat instellingen die nu harvesten via dit protocol (een voorbeeld hiervan is natuurlijk de KNAW, die ons repository harvesten voor de NARCIS-portal) op termijn zullen overstappen naar ResourceSync. Het is daarom zeker een ontwikkeling om goed in de gaten te houden!

De presentatie die tijdens OAI8 is gegeven door Herbert Van de Sompel, Robert Sanderson en Stuart Lewis is hier te bekijken.

Helemaal Poka Yoke!

Saskia van Bergen

Als medewerker van de afdeling Innovatie & Projecten houd ik mij vooral bezig met projectmanagement. Hierbij werk je binnen een beperkte periode en budget naar een concreet einddoel of eindproduct. De laatste tijd kom ik steeds vaker de term procesmanagement tegen. Hierbij gaat het om het ontwikkelen en verbeteren van doorlopende activiteiten. Denk bijvoorbeeld aan het inrichten van een productielijn in een fabriek of – om het wat dichter bij huis te houden – de gang van het boek in onze bibliotheek. In de praktijk komt het een meestal uit het ander voort. Zo wordt er vaak een project gestart om een onderdeel in een proces in te richten of te verbeteren. 

Het een-na-laatste nummer van Informatie Professional bevat een inspirerend artikel van de hand van Matthijs van Otegem over de toepassing van procesmanagement in de Koninklijke Bibliotheek. Als case-study gebruikt hij de verbetering van het digitaliseringstraject,  wat gezien de projecten met Google en ProQuest een belangrijke activiteit is voor de KB. Toen een oud-collega me vertelde dat de KB een workshop organiseerde over hetzelfde onderwerp, aarzelde ik geen moment en heb direct gevraagd of ik aan mocht sluiten. Gelukkig was ik van harte welkom!

Tijdens de workshop werd uitgebreid ingegaan op één van de bekendere procesmanagementmethodes Lean Six Sigma. Hierin staat het verbeteren van klanttevredenheid en het verhogen van efficiëntie centraal. “Door te focussen op datgene wat voor de klant écht belangrijk is en fouten in de uitvoering terug te dringen, wordt het aantal processtappen gereduceerd (Lean) en de uitkomst van de processen voorspelbaar gemaakt (Six Sigma) “. Doordat de methode van oorsprong Japans is, kwamen er flink wat exotische termen voorbij, zoals Poka Yoke – een proces wordt zodanig ingericht dat mensen geen fouten kunnen maken – en Jidoka – de volgende productiestap mag pas worden genomen wanneer het deelproduct defectvrij is. Ook wordt veel verantwoordelijkheid bij de medewerkers neergelegd; verbetering wordt niet van boven opgelegd, maar doe je samen. De deelnemers aan de workshop werden daarom ook zelf aan het werk gezet. De opdracht was om in groepjes te bedenken hoe de klanttevredenheid bij het aanvragen van boeken uit het Depot Nederlandse Publicaties verbeterd kon worden. Deze boeken mogen het gebouw niet verlaten, wat regelmatig tot misverstanden en ontevredenheid leidt bij klanten.

Na afloop realiseerde ik me dat we op de UB ook al tamelijk Lean werken. Dit is namelijk precies wat wij proberen te bereiken met de nieuwe dienst “Digitalisering op verzoek”. Ook hier vormde de klant het uitgangspunt voor de inrichting van een efficiëntere workflow. Door het proces te vereenvoudigen en te automatiseren kunnen de scans sneller aan de klant worden geleverd, en kost het ons tegelijk minder tijd en inzet. Hiervoor hebben we uiteenlopende deelproducten gerealiseerd, waaronder:
– Buttons in PRIMO waarmee klanten direct vanuit de catalogus scans kunnen bestellen
– Geautomatiseerde levering van scans door middel van FTP
– Een betaalmodule waarmee klanten snel en eenvoudig kunnen betalen

Ook de aanschaf van het softwarepakket GOOBI voor het inrichten en managen van de digitaliseringsworkflow helpt hierbij. Goobi deelt het productieproces op in deeltaken, en koppelt aan elke taak een rol, zoals ‘baliemedewerkers’, en ‘scanmedewerkers’. Taken worden na afronding automatisch naar de volgende in het proces doorgestuurd, of -wanneer een fout wordt geconstateerd- teruggestuurd naar de vorige. Ook is een aantal validaties ingebouwd, waarmee medewerkers gedwongen worden om bepaalde velden in de database in te vullen. Niet alleen helemaal Jidoka, maar ook echt Poka Yoke dus!

Innovatie is een modewoord voor iets dat vaak mislukt

De titel van deze blogpost heb ik niet zelf verzonnen, maar vormt de kop van een artikel in NRC Opinie & Debat van zaterdag 29 juni 2013.  Sinds mijn afdeling volmondig Innovatie & Projecten heet, valt mijn oog vaker dan voorheen op dit soort artikelen en lijkt het woord Innovatie ook vaker voor te komen. (Hoe heet dat effect ook al weer?)

De bibliotheekwereld heeft het de laatste tijd ook veel over innovatie; zonder dat zou de toekomst van de (universitaire) bibliotheek wel eens heel somber kunnen zijn. daarom kijken alle bibliotheken, en dus ook de UBL, goed naar de eigen rol en naar mogelijkheden voor innovatie.

Een paar zinnen in het NRC artikel vielen mij extra op.

“Innoveren is vernieuwen, een stap verder gaan dat de status quo. … Innovatie is iets anders dan inventie, uitvinden.”  Dit stelt mij gerust, we zijn niet zo goed in uitvinden, maar doen wel redelijk mee  als het gaat om vernieuwen.

“Innoveren wordt ook wel gedefinieerd als het ontwikkelen van nieuwe combinaties.” Een goed voorbeeld hiervan zijn de lockers die de UBL in gebruik heeft voor uitlenen van materialen zonder dat daar direct bibliotheekpersoneel voor nodig is. Een combinatie van lockers (zoals ook in gebruik bij zwembaden) en een uitleenautomaat (zoals veel bibliotheken die gebruiken, met als protocol SIP2) heeft gezorgd voor een mooie innovatie. Recent hebben we onze locatie in Den Haag ook van lockers voorzien: materialen kunnen uit de UBL collectie worden opgevraagd en worden via de lockers op de Campus Den Haag uitgeleend. Wellicht komt er binnenkort nog zo’n vestiging bij.

“Innoveren heeft twee fundamentele kenmerken die elke manager tot wanhoop kunnen drijven: een onzekere uitkomst en een onzeker proces.” Ik prijs me dan ook gelukkig dat ik geen manager ben. Bij het management van de UBL valt die wanhoop overigens ook niet te merken. Juist onze directeur Kurt De Belder, loopt graag voorop als het gaat om innovatie en heeft een duidelijke visie voor de toekomst van de UBL en ook de overige MT leden zijn bepaald niet vies van vernieuwing.

“In een innovatietraject kun je vier type activiteiten onderscheiden … bedenken op welk gebied je wilt innoveren … iets bedenken dat hiervoor een oplossing biedt … concept goed uitwerken … innovatie op de juiste manier implementeren in je organisatie.”  Persoonlijk vind ik het eerste en het laatste punt het lastigste. Met de kennis die we bij de UBL in huis hebben kunnen we vrij goed oplossingen bedenken en uitwerken, binnen de beperkte mogelijkheden.  De typen activiteiten lopen ook vaak door elkaar heen, bij het bedenken van een mogelijkheid moet je al rekening houden met haalbaarheid (beperkte middelen!) en mogelijkheden voor implementatie, waarbij ook acceptatie een belangrijke rol speelt.

“We vinden innoveren leuk.” Dat geldt zeker voor de medewerkers van de afdeling Innovatie & Projecten van de UBL. We zijn dan ook volop bezig om (al dan niet in projecten) te werken aan vernieuwing van diensten, processen en systemen. Een aantal van de belangrijkere innovatieve projecten:

  • Samenwerkingsomgevingen voor onderzoekers en ook voor het betrekken van studenten bij onderzoek
  • Catalogiseren van onze bijzondere collecties (handschriften, prenten, fotografie, brieven, etc.) met gebruik van standaard infrastructuur als GGC en WorldCat
  • Metadata van leveranciers gebruiken in plaats van deze zelf in te voeren

De komende jaren staat de UBL nog veel innovatie te wachten, waaronder waarschijnlijk een hele nieuwe generatie bibliotheeksystemen die moeten leiden tot een aanzienlijk lagere “Total Cost of Ownership”.

Gelukkig dus ruim voldoende werk….

P.S.  Volgens INSEAD staat Nederland op plek 4 van “The World’s Most Innovative Countries: The Global Innovation Index 2013”. Zo slecht doen we het dus ook weer niet

Toch maar wel weer bloggen

Tegen de stroom in hebben wij bedacht dat we (weer) willen gaan bloggen. Maar dan wel op een nieuwe plek en onder een nieuwe naam : UBL innovatie . Het moet een blog worden door de medewerkers van de afdeling Innovatie & Projecten van de Universitaire Bibliotheken leiden (UBL), geïnspireerd door ons dagelijks werk, maar op persoonlijke titel.

Google Reader is er net mee gestopt (1 juli!). Er is op diverse bekende bibliobblogs over geschreven met als titels “Is it the end of an era for librarian blogging?” , “Niet bloggen maar joggen?”, “Biblioblog(gers) in vrije val”  en “De bloggende bibliothecaris anno 2013” : bloggen is uit!

Ook op een recente interne UBL bijeenkomst werd geconstateerd dat Twitter wellicht veel belangrijker zou zijn dan bloggen. En dat RSS readers hun langste tijd wel gehad zouden hebben.

Vervolgens werd er heel veel getweet (en geblogd) over de beste vervanger voor Google Reader, met Feedly als winnaar. En komen er toch ook weer nieuwe blogs bij, zoals Skills for InformatieProfessionals van onze eigen divisiemanager Josje Calff.  Onze collega’s van de UB Utrecht zijn in staat om inspirerend gezamenlijk te bloggen met hun I&M / I&O 2.0 blog.

Als je dat samenvoegt met alle discussies over het bestaansrecht van universitaire bibliotheken en recente organisatorische veranderingen bij de UBL, met als resultaat een zelfstandige afdeling Innovatie & Projecten,  ontstaat toch het gevoel van “dat zouden wij toch ook moeten kunnen?” Dus: we gaan weer bloggen. Nu nog voldoende inspiratie.En lezers natuurlijk, met liefst inhoudelijke reacties. Wij denken dat we genoeg te vertellen hebben, voor ons geldt: bloggen is in!