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