Een Open Source Huisarts Informatie Systeem?

Dit artikel is gericht aan zowel artsen als ontwikkelaars. Voor beide doelgroepen zullen er zaken in dit artikel staan die als voor de hand liggend zullen worden beschouwd. Reacties kunnen geplaatst worden bij een korte versie van het artikel op LinkedIn.

Huisartsen proberen steeds meer informatie over hun patiënten gestructureerd vast te leggen. Denk hierbij aan persoonsgegevens en afspraken, maar ook de voorgeschiedenis van de patiënt en medicatie gegevens. In Nederland zijn er ongeveer twintig zogenaamde Huisarts Informatie Systemen (HIS) in gebruik om dit soort gegevens vast te leggen. In zijn column “Mijn HIS is het best!”[1] roept Rob Dijkstra, bestuursvoorzitter van het Nederlands Huisartsen Genootschap (NHG), de leden van het NHG op samen te werken om de ontwikkeling van die verschillende HIS-en zoveel mogelijk gelijk te trekken. Het doel van Dijkstra’s oproep is om alle HIS-en te verbeteren en informatie beter uitwisselbaar te maken.

Na het lezen van de column vroeg ik me het volgende af: wat zou er gebeuren als de lessen die geleerd zijn bij het ontwikkelen van open source successen als WordPress[2] en Drupal[3], toegepast zouden worden op de ontwikkeling van een open source huisarts informatie systeem?

Traditioneel gezien krijgt een gebruiker van software niet de code van de programmeur te zien, alleen het resultaat ervan. Open source software (OSS) is software waarbij naast het programma ook de broncode beschikbaar wordt gesteld. Hierdoor kan deze code door derden gecontroleerd worden. Er kunnen zelfs verbeteringen of uitbreidingen worden voorgesteld.

Waarom dat nu weer?

Het ontwikkelen van een nieuw, open source HIS biedt de gelegenheid om de sterkste kanten van de verschillende bestaande HIS-en te bundelen. Organisaties als het NHG, de Landelijke Huisartsen Vereniging (LHV) en NedHIS, een belangenorganisatie voor HIS-gebruikers in Nederland, zouden een sterke adviserende rol kunnen spelen, op basis van de ervaringen die zij van hun achterban gemeld krijgen.

Voor we verder gaan is het nodig duidelijk onderscheid te maken tussen een HIS, een elektronisch patiënten dossier en het elektronisch patiënten dossier. Dit voorstel heeft betrekking op de administratie van een huisarts. Hierbij wordt, in de eerste plaats, niet gekeken naar enige koppeling met andere huisartsen of andere collega’s. Het draait om een uniformiteit in de manier waarop huisartsen (ieder voor zich) met hun data omgaan, die de kwaliteit van de zorg ten goede moet komen.

Een HIS is een verschijningsvorm van een elektronisch patiënten dossier. Er wordt tenslotte gebundelde informatie over een patiënt op elektronische wijze vastgelegd. Het heeft echter slechts indirect te maken met het elektronisch patiënten dossier, zoals dat inmiddels de afgelopen jaren in de publiciteit is geweest. Hierover later meer.

In dit artikel verken ik de verschillende aspecten van software ontwikkeling. Daarbij geef ik aan welke eisen een HIS hieraan stelt en welke mogelijkheden het ontwikkelen van een open source HIS zou kunnen bieden. Het voornaamste doel van dit artikel is om het idee voor te leggen aan zowel huisartsen als software ontwikkelaars. Ik probeer daarbij aan te tonen dat de ontwikkeling van een open source HIS wenselijk en, onder de juiste omstandigheden, haalbaar is.

Wie ontwikkelt zoiets?

Kenmerkend voor open source projecten is dat het overgrote deel van de ontwikkelaars geen of slechts een indirect commercieel belang heeft bij de software. De meeste contributers (ontwikkelaars die bijdragen aan het project) hebben vooral een persoonlijke interesse in een goed functionerend product, veelal omdat ze het product zelf willen gebruiken.

In het geval van een HIS is het natuurlijk zo dat de mensen die het product willen gebruiken zelf geen software ontwikkelaars zijn. Van hen kan dus nooit verwacht worden dat ze zelf een HIS ontwikkelen. Maar we kunnen het idee van “persoonlijke interesse” ook breder zien. Vrijwel iedereen in Nederland is ingeschreven bij een huisarts. Alle software ontwikkelaars in Nederland hebben dus een persoonlijk belang bij een goed functionerend, betrouwbaar en flexibel HIS.

Organisatie

De meest succesvolle open source projecten worden geleidt vanuit een centrale organisatie. Het bekendste voorbeeld van zo’n organisatie is de Apache Software Foundation, genoemd naar de open source webserver software waar op het moment van dit schrijven meer dan de helft van alle websites op draaien[4]. Ook projecten als WordPress en Drupal hebben een duidelijke organisatorische structuur, waarin bijvoorbeeld duidelijk is vastgelegd welke ontwikkelaars bepalen of een bijdrage opgenomen wordt in het project.

Ook hebben deze projecten duidelijke doelen en voorwaarden vastgesteld. Een mooi voorbeeld hiervan is de ontwikkelfilosofie uit het Core Contributer Handbook van WordPress[5], waarvan een aantal elementen ook prima van toepassing zouden kunnen zijn op de ontwikkeling van een open source HIS:

  • Out of the Box: er moet weinig configuratie nodig zijn om de software in gebruik te kunnen nemen. De installatie van een basis WordPress duurt bijvoorbeeld niet langer dan vijf minuten[6].
  • Design for the Majority: het overgrote deel van de eindgebruikers heeft weinig technische kennis, dus dat mag niet nodig zijn om de applicatie te gebruiken.
  • Decisions not Options: probeer tijdens de ontwikkeling weloverwogen beslissingen te nemen, in plaats van onnodig veel opties te bieden aan eindgebruikers. In het kader van een HIS komen hier al dan niet vastgelegde standaarden ook bij aan bod.
  • Striving for Simplicity: iedere nieuwe versie zou makkelijker moeten zijn om te gebruiken, niet moeilijker.

Critical Mass

Het is lastig om absolute cijfers te vinden, maar voor ieder succesvol project zijn er zeker honderden projecten die een stille dood sterven. Een open source project heeft momentum nodig. Dit betekent dat er een vaste groep ontwikkelaars ontstaat die gezamenlijk regelmatig werken aan het verbeteren en uitbreiden van de code. Een goede organisatie kan, zoals eerder omschreven, dat momentum in stand houden. Een actief en goed lopend project trekt vervolgens steeds nieuwe developers aan.

Maar waar komt dat momentum in de eerste plaats vandaan? In sommige gevallen kan de betrokkenheid van een commerciële partij het project juist op gang helpen. Dit is bijvoorbeeld gebeurd in het geval van Hadoop, een platform om complexe berekeningen op grote hoeveelheden data te verdelen over een cluster van relatief goedkope computers. Het project werd aanvankelijk ontwikkeld als onderdeel van een open source zoekmachine voor Internet Archive. Doug Cutting, de oorspronkelijke ontwikkelaar, werd door Yahoo! in dienst genomen. Men was onder de indruk van het project en besloot Cutting een team te geven om Hadoop verder te ontwikkelen[7]. Inmiddels is Hadoop ondergebracht bij de eerder genoemde Apache Software Foundation. Het wordt gebruikt en verder ontwikkeld door grote namen als Facebook[8], LinkedIn[9] en Twitter[10]. Dit is natuurlijk een extreem voorbeeld, maar illustreert goed dat een commerciële partij weldegelijk betrokken kan zijn bij de ontwikkeling van een open source project en zelfs van groot belang kan zijn. Een belangrijk gegeven hierbij is dat het commerciële belang niet moet liggen in de verkoop van de ontwikkeling, maar in de implementatie of het gebruik ervan. Daarnaast komt het bijdragen aan open source projecten het publieke imago van bedrijven alleen maar ten goede.

“Open source code betaalt zo lastig in de supermarkt…”

Dat de ontwikkelaars van een applicatie geen commerciële belangen hebben bij het project, wil niet zeggen dat er geen handel zit in open source projecten. Zo verhuurt de organisatie van WordPress ruimte om een WordPress website te plaatsen en worden er verschillende betaalde upgrades aangeboden[11]. Red Hat heeft versies van haar besturingssysteem specifiek gericht op het bedrijfsleven[12].

Maar er zijn ook business modellen voor derden. Een open source content management systeem (CMS) als WordPress maakt het makkelijker en sneller om een website te ontwikkelen, maar er is nog steeds technische kennis voor nodig. Bedrijven als Hoppinger en Triquanta ontwikkelen websites die als basis een open source CMS hebben, maar die zowel qua functionaliteit als uiterlijk volledig toegespitst worden op de opdrachtgever.

Ontwikkelaars van de huidige HIS-en of een bedrijf als HIS-Support zouden een vergelijkbare rol kunnen spelen in de implementatie van een open source HIS. Hoewel een open source project zou betekenen dat iedere huisarts in de gelegenheid is om het systeem zelf te implementeren en zelfs naar eigen inzicht te wijzigen, zal vrijwel niemand dit kunnen en zelfs willen. Waar nu handel wordt gedreven in het ontwikkelen en implementeren van twintig verschillende HIS-en, zou op termijn gezamenlijk gewerkt kunnen worden aan één HIS die iedere partij voor haar eigen klanten implementeert.

Het slot ligt op straat, niet de sleutel

Als men kijkt naar de algemene kwaliteit van software, wijst in ieder geval één onderzoek[13] erop dat de kwaliteitsontwikkeling van open source software vergelijkbaar is met die van closed source applicaties.

Een HIS bevat veel gevoelige informatie. Veel mensen verwachten dat als de code van een HIS openbaar is, die kennis ook gebruikt kan worden om ongeoorloofd toegang te krijgen tot die persoonlijke informatie. Het tegenovergestelde zal echter het geval zijn.

Beveiligingssystemen bestaan uit twee onderdelen: een algemene methode en een stuk informatie dat de beveiliging uniek maakt. De methode kan vergeleken worden met een slot en de unieke informatie met de sleutel. In het verleden is verschillende malen geprobeerd om een systeem te beveiligen door de werking van het slot geheim te houden. Dat soort systemen worden vrijwel altijd gebroken, zoals het geval bleek bij de OV-chipkaart[14] en bij Blu-ray schijven[15]. Doordat de methode geheim gehouden wordt, hebben relatief weinig mensen over de methode nagedacht en blijven er vaak zwakheden in de methode achter. Die zwakheden kunnen door derden ontdekt en misbruikt worden.

TrueCrypt is een voorbeeld van een open source beveiligingssysteem. Het wordt gebruikt om harde schijven of delen ervan te beveiligen. TrueCrypt is op dit moment alleen te kraken als de indringer langere tijd fysieke toegang tot de computer zelf heeft en beschikt over forensische software.

Methoden die openbaar zijn, worden door veel meer mensen onderzocht. Slechts een klein deel van deze groep heeft kwade bedoelingen. De rest draagt bij aan het veiliger maken van het systeem. Juist door het systeem openbaar te maken, kun je de data veilig opbergen.

Wie krijgt er toegang?

Een nieuw te ontwikkelen HIS biedt direct de gelegenheid om de koppeling met het Landelijk Schakelpunt (LSP; eerder bekend als het EPD) te implementeren. Het LSP is een systeem dat zorginstellingen, zoals dienstdoende huisartsen of een afdeling Spoed Eisende Hulp (SEH), in staat stelt om actuele medische gegevens op te vragen op het moment dat een patiënt zelf niet in staat is deze te verschaffen.

Het LSP is ontwikkeld en wordt beheerd door CSC Computer Sciences[16]. Daarbij heeft CSC zich ertoe verplicht te zorgen dat bij het gebruik van het LSP de Wet Bescherming Persoonsgegevens (WBP) nageleefd wordt[17]. Daarnaast is de Vereniging van Zorgaanbieders voor Zorgcommunicatie van plan een patiënten portaal te ontwikkelen[18] waarbij de patiënt:

  1. Een (email of sms-) bericht ontvangt als zijn gegevens worden opgevraagd.
  2. Elektronische inzage kan krijgen in hoe hij staat geregistreerd en welke gegevens door welke zorgaanbieder(s) zijn opgevraagd.
  3. Een persoonlijk toestemmingsprofiel kan maken om zo gedifferentieerd toestemming te geven voor gegevensuitwisseling via de zorginfrastructuur.

Ondanks de vergelijkingen met open source webservers en content management systemen, is het wel de bedoeling dat een open source HIS een gesloten systeem is dat lokaal op de praktijk draait, of via een versleutelde verbinding op servers bij een toeleverancier toegankelijk wordt gemaakt.

Gezamenlijk verbeteren

Geloof het of niet, ook programmeren is mensenwerk. Ieder systeem, open source of niet, zal problemen bevatten. Dit kan variëren van een typefout tot het verkeerd begrijpen van de behoeften van de eindgebruikers. Er zijn steeds meer middelen en methoden beschikbaar om dergelijke problemen te beperken, maar het risico blijft altijd bestaan. Vergelijk maar met de spellingscontrole van een tekst verwerker: wanneer je “grip” schrijft, weet het programma niet dat je “griep” bedoelde, omdat beide woorden in het woordenboek staan.

Wanneer alle huisartsen hetzelfde systeem gebruiken, betekent dit ook dat er een grotere groep gebruikers is die problemen kunnen tegenkomen en rapporteren. Het rapporteren van dit soort problemen heeft altijd zin, ook bij closed source systemen. De wetenschap dat jouw melding iedere huisarts in Nederland kan helpen, kan er mogelijk toe leiden dat gebruikers ook actiever gaan melden wat er mis gaat en wat er verbeterd kan worden.

De medische wetenschap staat niet stil. Wet- en regelgeving evenmin. Met een verzameling systemen, ieder met een eigen ontwikkel team, is het maar afwachten wanneer wijzigingen op basis van nieuwe inzichten of regels volledig doorgevoerd worden.

In het geval van één open source HIS kunnen wijzigingen op basis van gemelde problemen of wijzigende regelgeving centraal en eenduidig doorgevoerd worden.

Conclusie

Er zijn genoeg mensen die de lof zingen over open source software. Echter, de meest succesvolle open source projecten hebben een brede toepassing. Ik heb getracht aan te duiden dat open source projecten ook waardevol kunnen zijn voor specifiekere toepassingen, zoals een Huisarts Informatie Systeem. Zoals Dijkstra in zijn column al aangaf, is een kleinere groep gebruikers er juist bij gebaat om de krachten te bundelen.

Discussie

Ieder nieuw systeem roept weerstand en wantrouwen op, zeker als de eindgebruikers maar zeer beperkt inzicht hebben in de aard van het systeem. Dit geldt wellicht nog sterker voor een uitdagend concept als open source software. Ik heb getracht in dit artikel een deel van dat wantrouwen weg te nemen. Verdere discussie en heldere informatie zal moeten leiden tot draagvlak voor dit concept.

De grootste praktische uitdaging voor een open source HIS zal naar mijn idee het begin zijn: wie gaat dit maken? In een ideale wereld slaan de ontwikkelaars van de huidige HIS-en de handen ineen om, geadviseerd door het NHG en de LHV, gezamenlijk het ultieme HIS te ontwikkelen. Daarbij verschuift hun commerciële belang van de ontwikkeling naar de implementatie van HIS-en en het ondersteunen van hun gebruikers.

Verder moet onderzocht worden wat de juridische implicaties zijn van het ontwikkelen en gebruiken van open source software. Wie is precies aansprakelijk op het moment dat een fout in de software leidt tot een probleem in de praktijk? Hierop heb ik nog geen concrete antwoorden kunnen vinden.

Over het algemeen hebben open source projecten al snel een internationaal karakter. De verwijzingen naar organisaties als het NHG en de LHV en een systeem als het Landelijk Schakelpunt geven het idee dat het toch vooral om een Nederlands project zou gaan. Toch zou het voordelig zijn om ook contact te zoeken met vergelijkbare organisaties in het buitenland. Hoe meer partijen bij een dergelijk project betrokken zijn, hoe groter ook het draagvlak voor ontwikkeling is. Om te zorgen dat die niet tot verwatering of versplintering leidt, zullen ook deze partijen alleen een adviserende rol moeten hebben. Op deze manier kan de centrale organisatie van de ontwikkeling zelfstandig en slagvaardig blijven.


[8] Thusoo, A., et al. 2010. Data warehousing and analytics infrastructure at Facebook. In Proceedings of ACM SIGMOD 2010, pp. 1013-1020.
[9] Roshan Sumbaly, Jay Kreps, Lei Gao, Alex Feinberg, Chinmay Soman, and Sam Shah. Serving Large-scale Batch Computed Data with Project Voldemort. In Proceedings of the FAST, 2012.
[10] George Lee, Jimmy Lin, Chuang Liu, Andrew Lorek, and Dmitriy Ryaboy. 2012. The unified logging infrastructure for data analytics at Twitter. Proc. VLDB Endow. 5, 12 (August 2012), 1771-1780.
[11] https://store.wordpress.com geraadpleegd op 20-04-13
[13] Ying Zhou and Joseph Davis. 2005. Open source software reliability model: an empirical approach. In Proceedings of the fifth workshop on Open source software engineering (5-WOSSE). ACM, New York, NY, USA, 1-6. DOI=10.1145/1082983.1083273 http://doi.acm.org.ezproxy.hro.nl/10.1145/1082983.1083273

Designing the User Experience: building an interactive Funnel Diagram

During the minor Interface and User Experience Design, we were asked to pick a method out of the HCI Toolkit at random, research the method and write a paper on the subject. The method I drew was the Funnel Diagram. A lot has been said about how to interpret funnel diagrams and what can be done to improve the conversion they depict. But during my research I discovered there really isn’t that much to say about why a funnel diagram should be used and how it should be designed. In Communicating the User Experience the authors Richard Caddick and Steve Cable give thorough and well substantiated instructions on how to design a funnel diagram.

Part of the assignment was to give a short workshop on the subject, including the demonstration of a worked example. Because there wasn’t that much to tell about how to make a funnel diagram, I decided to put some extra effort into the worked example by building a tool that would allow anyone to make a funnel diagram in a few minutes instead of the usual several hours. It offered a great opportunity to start exploring d3.js, a JavaScript library for manipulating documents based on data developed by Mike Bostock. The tool is now available at http://funneldiagram.andra.nl for anyone who would like to use it. If I find the time, I’d like to revise the code and make it available through github.

Funnel Diagram

Although this tool gave me something to demo during the workshop, I still really didn’t know what to write about. After showing the tool to my teacher Jasper Schelling, he showed me some of the work and ideas of Victor Bret. In particular, Jasper pointed out Bret’s ideas about what he calls explorable explanations and reactive documents. These offered extra ideas to implement in the tool, but also a direction I could take with the paper I was about to write. We came upon the idea of building more tools for the methods in the HCI Toolkit.

The Funnel Diagram is one of those methods where the finished artifact associated with the method offers insight into the design of a product. However the process of creating the artifact doesn’t add anything at all, even though the process takes up significant amounts of time and attention. Contrast this with the method Mind Mapping, where the process of creating the artifact (i.e. the mind map) provides the insight or ideas. By building tools that make light work of creating artifacts, the cost of implementing the associated methods would become significantly lower. This could lead to methods being applied more often, which should ultimately lead to better designed and developed solutions.

I’ve written the paper about these ideas and posted it on this site. If you’re interested, please read Let’s put the “Tool” into “HCI Toolkit”.

Let’s put the “Tool” into “HCI Toolkit”

Abstract

De Human Centered ICT Toolkit is ontwikkeld om een overzicht te geven van alle methoden die beschikbaar zijn tijdens het ontwerpen en ontwikkelen van een product. Dit artikel stelt voor om de HCI Toolkit uit te breiden met praktische, herbruikbare en waar mogelijk interactieve tools, om het toepassen van de verschillende methoden te bevorderen. Aan de hand van een casestudy wordt besproken hoe dit vorm zou kunnen krijgen en waarmee rekening gehouden moet worden.

English summary

The Human Centered ICT Toolkit (HCI Toolkit) is intended “to enlighten human-computer interaction (HCI) and software engineering (SE) researchers and practitioners (i.e., the representatives of the six bachelor courses) and enable them to develop a shared understanding and a holistic view of the overlapping fields of SE and HCI.” [5] It represents a collection of methods that can be applied while designing or developing a solution or product. Most of these methods include the production of artifacts: documents that either guide the method or represent its outcome. The production of these artifacts can be time-consuming. This could cause designers and developers not to apply certain methods out of time-constraints.

The author proposes to review all methods in the HCI Toolkit to determine if the production of the aforementioned artifacts could be caught in templates. The costs of producing these artifacts could then be greatly reduced, which makes it all the more plausible that the methods to which the articles belong will actually be applied.

The author also proposes to consider whether the artifacts could gain in value if it were made interactive, as propose by Victor Bret in “Explorable Explanations” [3].

While developing the tools to produce the artifacts, the following should be taken into consideration:

The tool should be as universally accessible as possible. No special hardware or software should be necessary to use the tools. This improves the likeliness that the tools will be used.

Providing open-standard documents like PDF [1] is one way of ensuring accessibility. Providing easy to use web-applications is another possibility. The javascript libraries jQuery [6] and D3 [2] allow developers to build very powerful and flexible tools. An example of such a tool can be viewed at http://funneldiagram.andra.nl.

It yet needs to be determined which methods and artifacts would qualify for this approach.

It also needs to be determined who will be responsible for the development and maintenance of the proposed tools. Students could do this. The advantage of this approach is that students get familiar with the methods for which they develop tools. They also gain experience in developing dynamic tools in general. Maintenance could become problematic, however. The students who developed a tool will leave school and may not be available for maintenance. Maintaining another’s can be difficult, especially for students.

Another option is to have companies ‘adopt’ one or more methods that they (could) apply in their own daily practice. They would then be responsible for both development and maintenance of the tools. They would be building tools that can be deployed in their own workflows. They would also be contributing to the education of their future coworkers, raising the level of professionals industry-wide.

1. Introductie

De Human Centered ICT Toolkit [5] (HCI Toolkit) is een verzameling methoden die toegepast kunnen worden tijdens het ontwerpen en ontwikkelen van een oplossing. De HCI Toolkit is ontwikkeld om het toepassen van deze methoden onder studenten te bevorderen, om op die manier de kwaliteit van Human Centered Design in de praktijk te verbeteren.

In de HCI Toolkit staan voor veel verschillende methoden niet alleen omschrijvingen van de methoden zelf, maar ook hoe de artefacten rond de methoden gemaakt zouden moeten worden. Sommige van deze artefacten kunnen redelijk arbeidsintensief zijn om te produceren. Daarnaast is het vaak ook vervelend werk, niet in de laatste plaats omdat je tijdens het maken van zo’n artefact niet bezig kunt zijn met het ontwerpen of ontwikkelen van het product waar de methode betrekking op heeft. De tijd en aandacht die het kost om de artefacten te maken kan zelfs een reden zijn om een methode niet toe te passen.

Verder zijn veel van de artefacten ooit ontworpen als statische documenten, bedoeld om uit te printen in rapporten of als posters. Vandaag de dag is het ondenkbaar dat er teamleden of andere belanghebbenden zijn die niet over een computer beschikken. De vraag rijst of sommige artefacten niet gebaat zijn, dat wil zeggen, meer betekenis krijgen, wanneer ze interactief gemaakt worden.

In dit artikel stel ik voor om voor iedere onderdeel van de HCI Toolkit te onderzoeken wat er gedaan kan worden om het produceren van de benodigde artefacten te vereenvoudigen. Verder stel ik voor om voor ieder artefact te onderzoeken of het baat zou hebben bij een meer interactieve uitwerking.

Beide voorstellen zouden er toe moeten leiden dat de methoden in de HCI Toolkit zowel vaker als effectiever worden toegepast. Hiermee zou het doel de HCI Toolkit dus beter bereikt worden.

Deze ideeën zijn ontstaan tijdens een onderzoek naar het Funnel Diagram als onderdeel van de HCI Toolkit. Ik zal dit onderzoek dan ook als casestudy hanteren..

2. Op zoek naar “snellere” artefacten

2.1 Het doel

Bij het ontwerpen of ontwikkelen van een oplossing is het goed om het probleem en/of het product op verschillende manieren te benaderen. Om studenten een inzicht te geven in welke methoden hiervoor toegepast zouden kunnen worden, is de HCI Toolkit ontwikkeld. De HCI Toolkit moet studenten stimuleren om met die methoden hun eigen werk, en daarmee het vakgebied, verder te professionaliseren.

Bij vrijwel iedere methode zijn één of meerdere artefacten betrokken. Ieder artefact kost tijd en aandacht om te maken. Wanneer het maken van het artefact juist het doel is van de methode, wordt deze tijd en aandacht heel direct gespendeerd aan het ontwerpen van een oplossing. Denk hierbij aan Mindmapping, waarbij het creëren van de mindmap integraal onderdeel is van de methode. In het geval van een funnel diagram daarentegen, draait de methode vooral om het inzicht dat het voltooide artefact kan bieden. Het creëren van het artefact zelf draagt niets bij aan het ontwerpen of ontwikkelen van de oplossing. In dat geval gaan de gespendeerde tijd en aandacht dus verloren.

Omdat tijd en aandacht eindig zijn, zullen er keuzes gemaakt moeten worden over welke methode wel of niet wordt toegepast. Het doel van de HCI Toolkit is echter, dat er zoveel mogelijk methoden worden toegepast. Door te zorgen dat, waar mogelijk, methoden minder tijd en aandacht in beslag nemen, kan gezorgd worden dat er meer methoden toegepast kunnen worden op één product.

2.2 De voorgestelde aanpak

Van ieder artefact in iedere methode uit de HCI Toolkit kan onderzocht worden welke aspecten voor ieder project gelijk zullen zijn. Deze aspecten kunnen dan opgenomen worden in een template waarmee het artefact vlotter geproduceerd kan worden. Het spreekt voor zich dat veel voorkomende varianten binnen een artefact hier ook in meegenomen kunnen worden. Deze templates kunnen vervolgens aan de HCI Toolkit toegevoegd worden zodat ze zowel voor studenten als professionals beschikbaar worden.

In het geval van een Funnel diagram schrijft de literatuur [4] hele duidelijke richtlijnen voor die voor ieder project hetzelfde toegepast kunnen worden. Het maken van het artefact geschied dus voor ieder project op exact dezelfde wijze. Hoewel een Funnel diagram geen moeilijk artefact is om te maken, kost het toch, afgaand op anekdotes, één tot drie uur om een Funnel diagram te produceren. En dat terwijl van project tot project, het enige verschil bestaat uit andere gegevens in een brontabel.

Tijdens het onderzoek naar de Funnel diagram besloot ik uit te zoeken of het mogelijk was om een tool te creëren om dit werk te vereenvoudigen. Het doel was om met slechts het invullen van een tabel, een Funnel diagram te creëren dat direct geschikt zou zijn om op groot formaat uit te printen. Ik besloot hiertoe een combinatie van de javascript libraries jQuery [6] en Data-Driven Documents [2] (D3) aan te wenden. Dit was de eerste keer dat ik D3 gebruikte. Om die reden ging een groot deel van de tijd die ik aan de ontwikkeling van de tool heb besteed, op aan het leren werken met D3. Mijn inschatting is dat een ervaren developer mijn werk binnen acht tot zestien uur kan reproduceren.

Het resultaat is te bekijken op http://funnel diagram.andra.nl. Het voornemen is om de code publiekelijk beschikbaar te maken door het op https://github.com te plaatsen. Ook zou de code desgewenst direct opgenomen kunnen worden in de HCI Toolkit.

2.3 De voorwaarden

Het doel van de voorgestelde tools is om tijd te besparen tijdens het toepassen van de methoden uit de HCI Toolkit. Daarom is het van belang dat voor ieder artefact goed wordt overwogen welke handelingen uit handen genomen kunnen worden van de ontwerper of ontwikkelaar.

Opname van een tool in de HCI Toolkit vereist dat de tool voor een zo groot mogelijk publiek toegankelijk en bruikbaar moet zijn. Een goed voorbeeld is het Business Model Canvas [7]: een vrij verkrijgbaar PDF bestand met daarin een schema waarin alle aspecten van een goed business-model een eigen plaats krijgen. Dit artefact heeft altijd dezelfde layout, waardoor PDF een erg geschikt medium is: het is een open standaard [1] en biedt de mogelijkheid om opmaak nauwkeurig en onafhankelijk van resolutie op te slaan.

In het geval van een Funnel diagram is juist de opmaak voor ieder project anders, maar is de manier waarop die opmaak bereikt wordt voor ieder project dezelfde. Hierdoor is een tool waarmee op dynamische wijze de opmaak berekend kan worden de beste oplossing. Tegenwoordig mag aangenomen worden dat ontwerpers, ontwikkelaars en andere belanghebbenden beschikken over een computer met een browser en een internetverbinding. Daarom zou een tool ook doormiddel van een web-applicatie beschikbaar gesteld kunnen worden. Waar mogelijk moet de web-applicatie de mogelijkheid bieden om de output op enige wijze op te slaan.

Algemeen geldt dat, aangezien de HCI Toolkit zelf vooral een online naslagwerk is, alle tools digitaal toegankelijk gemaakt moeten kunnen worden. Bij voorkeur gebeurt dit in een vorm die in een browser te raadplegen is. Anders volstaat een document dat gedownload kan worden.

3. Discussie

Het ontwikkelen van herbruikbare tools biedt de gelegenheid om de verschillende artefacten opnieuw tegen het licht te houden en te overwegen of ze nog verbeterd kunnen worden. Victor Bret pleit in “Explorable Explanations” [3] ervoor om documenten waar mogelijk interactief te maken. Hiermee kan het document meer betekenis krijgen en kan de lezer een beter begrip krijgen van de inhoud. In het voorbeeld van het Funnel diagram is het mogelijk gemaakt om door met de muis te scrollen of te klik-en-slepen, de verschillende stappen groter of kleiner te maken. Alle achterliggende stappen worden automatisch herberekend. Hiermee is dus snel te bekijken welke gevolgen veranderingen in de ene stap zou hebben voor de opvolgende stappen.

Het ontwikkelen en interactief maken van herbruikbare tools brengt ook een aantal uitdagingen met zich mee. Allereerst is het nog niet duidelijk hoeveel artefacten uit de HCI Toolkit daadwerkelijk in aanmerking komen voor deze aanpak. Op het moment van dit schrijven wordt de HCI Toolkit door andere studenten geüpdate. Wanneer dit proces voltooid is, kan er geïnventariseerd worden wat de behoeften en mogelijkheden zijn.

Verder rijst de vraag wie er verantwoordelijk zou moeten zijn voor het ontwikkelen en onderhouden van de tools. Hierin zijn in ieder geval twee scenario’s denkbaar:

  • Studenten van het instituut Communicatie, Media en Informatietechnologie zouden de tools kunnen ontwikkelen. Het voordeel is dat de studenten kennis maken met de methoden waartoe de artefacten behoren. Tegelijkertijd doen ze extra ervaring op met het ontwikkelen van dynamische documenten. Een nadeel is dat de studenten in het algemeen onervaren zijn en dus mogelijk minder kwalitatieve producten kunnen opleveren dan ervaren professionals. Een ander nadeel is dat onderhoud van dergelijke tools lastig is in een omgeving waarin de personen die de tools hebben gemaakt binnen een paar jaar op z’n minst slecht bereikbaar zijn om hun producten toe te lichten.
  • Bedrijven zouden tools die ze in de dagelijkse praktijk (kunnen) gebruiken kunnen “adopteren”. Zij nemen dan de verantwoordelijkheid voor het ontwikkelen èn onderhouden van de gekozen tools. Niet alleen ontwikkelen ze daarmee tools die ze zelf ook kunnen gebruiken; ze dragen daarmee ook direct bij aan de kennis en ontwikkeling van hun toekomstige collega’s.

4. Conclusie

Er ligt een kans om de HCI Toolkit effectiever te maken. Dit kan bereikt worden door het toepassen van de verschillende methoden minder tijdrovend te maken. Door het ontwikkelen van herbruikbare en interactieve tools voor het produceren van de verschillende artefacten, kunnen de tijd en aandacht van een ontwerper of ontwikkelaar meer gericht blijven op de het ontwerpen en ontwikkelen van een oplossing. Het streven hierbij is dat de tools, net als de HCI Toolkit zelf, universeel toegankelijk zijn.

Er moet nog geïnventariseerd worden voor welke artefacten het haalbaar en nuttig is om templates te ontwikkelen. Verder moet besloten worden wie er verantwoordelijk wordt voor het ontwikkelen en onderhouden van de verschillende tools.

5. Referenties

[1]    Adobe Systems Incorporated, 2008, Public Patent License ISO 32000-1: 2008. Retrieved November 8, 2012, from http://www.adobe.com/pdf/pdfs/ISO32000-1PublicPatentLicense.pdf

[2]    Bostock, M., Ogievetsky, V. & Heer, J., 2011 D3: Data-Driven Documents, IEEE Trans. Visualization & Comp. Graphics (Proc. InfoVis). Retrieved November 8, 2012, from http://vis.stanford.edu/papers/d3

[3]    Bret, V. 2011 Explorable Explanations. Retrieved November 8, 2012, from http://worrydream.com/ExplorableExplanations/

[4]    Caddick, R. & Cable, S. 2011 Communicating the User Experience, 291-322

[5]    Leurs, B. & Mulder, I. 2009. UCD education beyond the textbook: practicing a human-centered attitude. Verbeek, F.J., Lenior, D. & Steen, M. (eds). Proceedings of CHI Nederland conference ‘Change!’, 11 June 2009, Leiden, 47-50. Should be available from http://www.chi-conferentie.nl/2009/06/website/wp-content/uploads/2009/07/proceedings_chi_nederland_2009.pdf, but the link appears to be broken on November 8, 2012.

[6]    McCormick, E. & De Volder, K. 2004. JQuery: finding your way through tangled code. In Proceeding OOPSLA ’04 Companion to the 19th annual ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications, 9-10. DOI= http://dx.doi.org.ezproxy.hro.nl/10.1145/1028664.1028670

[7]    Osterwalder, A. & Pigneur, Y. 2010 Business Model Generation