AwesomRUs' first report of the CHI course at KULeuven

1. Gebruikersinterfaces: verslag 1
Groep 4: AwesomeЯUs
Blog http://awesomerus.wordpress.com/
Maarten Tielemans, Master Informatica
Jonas Hauquier, Master Informatica
Pieter-Jan Speelmans, Master Computerwetenschappen
Nick Meuws, Master Informatica
Abstract—Dit is het eerste verslag voor gebruikersinterfaces, van groep 4. Wij hebben een ontwerp
uitgewerkt voor het grafisch voorstellen van referenties tussen papers. De belangrijkste uitdagingen waren:
de gebruiker meteen laten begrijpen wat de grafische voorstelling uitdrukt, het zoeken naar een niet te
complexe manier om veel papers overzichtelijk voor te stellen en een goed mechanisme uitdenken voor het
verfijnen van de zoekopdracht. Uit deze eerste iteratie van het project leren we vooral dat input van
gebruikers uiterst nuttig kan zijn tijdens het bouwen van een applicatie. Ook de applicatie meer vanuit een
gebruikersstandpunt bekijken heeft zijn nut al bewezen.
Ingediend op: 11 maart 2010
——————————  ——————————
1 IDEE
Onderzoekers hebben vaak het probleem dat er gigantisch veel informatie en papers beschikbaar zijn in
hun onderzoeksgebied. Al deze informatie doorlopen en verwerken is zeer tijdrovend. Sterker nog, het
tempo waaraan nieuwe papers verschijnen is hoger dan het tempo waaraan papers gelezen kunnen
worden. Het merendeel van deze papers is ook niet interessant of relevant voor het werk dat de
onderzoeker verricht. Er is nood aan een manier om deze papers op een structurele manier te bekijken,
zodat enkel relevante papers gelezen kunnen of moeten worden.
Dit is het probleem dat de Awesome Paper Advisor probeert aan te pakken, doormiddel van een goede
zoekfunctie en een grafische weergave (welke de referenties tussen de papers weergeeft), het
makkelijker maken voor onderzoekers om relevante en interessante papers te vinden en oninteressante
papers weg te filteren.
Initieel wilden wij een extensie maken van Mendeley, onderzoekers gebruiken meer dan enkel papers
in hun dagelijks leven en wij dachten dat het mogelijk interessant was om meer dan enkel papers te
delen. Zo zouden zij ook video, labresultaten, … kunnen delen. Deze toepassing leek ons echter minder
nuttig dan het maken van de Awesome Paper Advisor. Meer soorten gegevens betekent namelijk niet
direct meer informatie en er zou alsnog een goede zoekfunctie beschikbaar moeten zijn. Door te kiezen
voor het uitwerken van de Awesome Paper Advisor konden wij ons meer focussen op 1 specifiek
probleem.
Het idee achter de Awesome Paper Advisor en het idee van de grafische weergave zijn goed – veel
onderzoekers waren enthousiast hierover. De grafische weergaven overzichtelijk maken blijkt echter
moeilijker te zijn, het is bijvoorbeeld vaak niet duidelijk wat de pijlen tussen verschillende papers
betekenen. Verder blijkt ook ―zoom‖ of ―detail‖ een verwarrende benaming te zijn op de grafische
weergave.

2. 2 STORYBOARD
Een researcher heeft recent een interessante paper gelezen van Erik Duval, hij weet echter niet goed
welke papers hij hier op volgend moet lezen. Hij beslist om de Awesome Paper Advisor om advies te
vragen.
Aangezien de zoekbox zowel titel als auteur accepteert lijkt hem een goed idee om op Erik Duval te
zoeken.
In de lijst van resultaten ziet hij het recent gelezen paper staan.
Hij beslist echter om goede alternatieven van één van Eriks meer populaire papers te bekijken.

3. De grafische weergave toont een aantal goede artikels om te lezen. De researcher heeft de meeste van deze
artikels echter al gelezen en beslist om meer detail te tonen in de hoop om andere interessante papers te
ontdekken.
De grafische weergave toont nu TE veel reeds ongelezen papers. De researcher is niet geïnteresseerd in
papers over metadata en beslist om deze uit het resultaat te filteren.

4. De resulterende suggesties bevatten goede papers met nuttige informatie voor de researcher. Hij kiest één
van de papers en download deze paper van Mendeley of een andere website.
3 SCHERM-TRANSITIE-DIAGRAM
Wanneer we het scherm-transitie-diagram van onze applicatie bekijken, merken we op dat de applicatie
bestaat uit drie belangrijke nodes:
de home pagina van waar de gebruiker een zoekopdracht kan starten;
de lijst met zoekresultaten waar de gebruiker kan kiezen over welke paper hij meer informatie wenst;
de grafische display waar de gebruiker de informatie over references tussen papers kan bekijken en kan
kiezen hoeveel detail en welke relaties hij wil zien.
Bij het opstellen van het diagram kwamen we tot het besluit dat er initieel in onze applicatie geen
mogelijkheid was om van de zoekresultaten of de grafische display terug te keren naar de home pagina of
een nieuwe query uit te voeren. Om dit probleem op te lossen, voegden we aan de lijst met zoekresultaten
en de grafische display een zoekveld toe.
Door het toevoegen van een zoekveld op deze pagina‘s, kan de gebruiker onmiddellijk zijn query verfijnen.
Ook wordt op deze manier de mogelijkheid tot terugkeren naar de home pagina overbodig. De home
pagina bestaat namelijk enkel uit een zoekveld.
Het alternatief bestond er uit de gebruiker eerst te laten terugkeren naar het beginscherm en vervolgens zijn
query opnieuw te laten uitvoeren. We kozen niet voor deze optie gezien deze zorgt voor een extra
indirectie.
Er werd overwogen om van het beginscherm op basis van de query onmiddellijk naar de grafische display
te springen. Dit zou betekenen dat we de meest relevante paper zouden tonen. We kozen niet voor deze
optie aangezien de gebruiker dan de gewenste paper zeer specifiek zou moeten specifiëren. Indien de
gebruiker goede zoektermen kiest, zal de gezochte paper zoiezo hoog in de resultatenlijst staan.

5. 4 PAPIEREN PROTOTYPE
Ons concept is niet het meest eenvoudige om in een papieren vorm presenteren en evalueren. We hebben
gekozen voor een zeer weinig dynamische gebruikersinterface, die we konden voorleggen met behulp van
een vijftal paginas. 4 van die pagina‘s zijn hieronder afgebeeld.
We begonnen de evaluatie met een kort interview van de testpersoon, om na te gaan of ons project wel
degelijk nuttig zou kunnen gebruikt worden door researchers, en dat er vraag naar zou zijn.
De bedoeling was om eerst het interview af te leggen alvorens het subject onze applicatie te tonen, om zo
veel mogelijk voorbedachtheid te vermijden. De vragen die we stelden waren:
―Bij het schrijven van een nieuwe paper, veelal in een domein waar je relatief nieuw in bent, hoe vind je de
juiste publicaties om te gebruiken als referentie? ‖
De reacties die we hier in het algemeen op kregen, was dat researchers eerst op gerichte keywords gaan
zoeken bijvoorbeeld op Google of Google Scholar. Referenties bleken voor vele researchers zeer belangrijk
te zijn bij het verder zoeken naar meer papers. Enkelen hadden de gerichte methode van het uitprinten van
alle papers die hen interessant leken om die daarna door te nemen. Initieel gebeurt het zoeken vaak wat
willekeurig, en vormen researchers na wat leeswerk een beeld van waar wat thuishoort, en wat voor hen
interessant is. Belangrijk voor een eerste selectie bleek het lezen van de abstract te zijn. Nog een methode is
dat, wanneer een researcher een paper interessant vindt, hij op zoek zal gaan naar meerdere papers van
dezelfde auteur.
―Aan welke papers hecht je meer belang, hoe bepaal je wat je eerst zal lezen en welke papers zullen je meer
voorkeur genieten? ‖

6. De auteur van de paper blijkt een belangrijk cirterium te zijn voor het bepalen van de waarde van een
paper. Sommige researchers die nauwkeurig te werk gaan bij het zoeken stellen veel belang aan de
referenties.
Wanneer ze met deze vragen klaar waren, probeerden we of ze zich probeerden een beeld te vormen van
hoe die papers, op basis van chronologie en van hoe ze elkaars denkproces beïnvloed hebben, met elkaar
verbonden waren. Ook daar bleek dat sommigen heel vaag wel zo'n beeld hadden, en sommigen dan weer
niet.
De resultaten die we konden afleiden uit dit onderzoek varieerden. Sommige onderzoekers zullen
waarschijnlijk niet zo geneigd zijn echt gebruik te maken van onze applicatie. Maar een significant deel
(zo'n 50%) zou wel een potentiële gebruiker zijn.
Na de test van ons concept gingen we verder met de applicatie zelf, we legden hen ons papieren prototype
voor en vroegen hen om te proberen informatie rond een specifieke paper op te zoeken. Het eerste scherm
toonde een simpele zoekbalk. Er was soms verwarring bij de testkandidaten over wat ze moesten invullen,
auteur of titel (waarop het antwoord: beide is mogelijk) was, maar dat kan ook verklaard worden door het
weinige aantal verschillende schermen dat we hen konden aanbieden. Het tweede scherm bevatte steeds
dezelfde lijst zoekresultaten, die soms wat vragen deden oprijzen omdat ze misschien niet gedetailleerd
genoeg waren. Het belangrijkste deel van onze papieren evaluatie was echter het volgende scherm, dat de
kandidaten verkregen wanneer ze een paper uit de lijst kozen.
De kandidaten zagen een scherm met een centrale paper, met daarrond connecties naar andere papers. We
stelden hen de vraag wat ze dachten dat ze zagen, en wat de betekenis van de papers en de pijlen was.
Iedereen is er van overtuigd dat de pijlen verwantschap uitdrukken tussen papers, maar hoe concreet, of
dat op basis van keywords, relevantie of referenties is, is onduidelijk. Ook bleek dat er geen richting voor
de pijlen kan gevonden worden die iedereen meteen juist begrijpt. De ene zal denken dat een pijl
logischerwijs "referentie naar" betekent, terwijl anderen dan weer "referentie van" zullen zeggen.
Dit zien wij nog steeds als één van de grootste hekelpunten aan onze interface, die nog aandacht verdient.
We moeten dus zoeken naar een manier om de betekenis van de pijlen meteen duidelijk te maken.
Ons papieren prototype bevatte ook pijlen van verschillende dikte. Dit kon niemand echt goed begrijpen,
en leek ons ook niet zo makkelijk toepasbaar. Deze feature is dan ook in de vuilbak beland. Het papieren
prototype liet toe om informatie popups te tonen boven de papers, en liet toe om verschoven te worden met
de muis, hoewel dit moeilijk spontaan te testen is op papier omdat je de gebruiker niet echt met een muis
kan laten experimenteren. Hiervoor was altijd wat extra uitleg nodig.
We namen ook de gelegenheid om onze testpersonen te vragen wat ze dachten van de keywords filter, of
die nuttig leeg, en of ze een beter alternatief wisten. Een keywords filter leek goed bevonden, maar iemand
vond de titel "filter" niet duidelijk, waarna we dat in ons papieren prototype veranderden naar "keywords",
maar de volgende kandidaten vonden dat dan weer verwarrend, waardoor het eindresultaat "filter by
keyword" is geworden. Hierna bleek iedereen meteen te snappen waarover het ging. We zochten samen
met hen naar manieren waarop de directe inpakt van het aan- of afvinken op de grafische voorstelling
duidelijk zou zijn. Een goed idee dat uit de bus kwam was het aantal papers dat relevant was voor een
keyword er tussen haakjes bij te zetten. Dat is nu verwerkt in ons volgende prototype.
Andere interessante mogelijkheden die we onderzochten was, of dat onze testpersonen beter hun
zoekresultaat zouden kunnen verfijnen door papers te verwijderen uit de graaf, bijvoorbeeld door op een
kruisje te klikken, of een tak van de graaf af te snijden. Een interessante opmerking die we wel kregen was
dat, als we papers volledig verwijderen in het begin, zouden we later mogelijk links met die papers missen
die toch van belang blijken te zijn. De weggewerkte papers eerder half uit-faden in plaats van ze volledig te
doen verdwijnen is misschien geen slecht idee. Als we effectief toelaten om papers weg te doen moeten we
zeker zoeken naar een manier om ze terug te halen, bijvoorbeeld met een soort van prullemand
functionaliteit.

7. De zoomfunctie zaaide ook wat verwarring onder onze testpersonen. Omdat het bij de titel ―zoom‖ niet
volledig duidelijk is of het detail verandert, dan wel dat de papers gewoon groter of kleiner worden,
hebben we gekozen om met de benaming ―detail‖ verder te gaan. Dit hebben we ook aangepast in ons
papieren prototype en gebruikt bij de laatste kandidaat.
Veel zekerheid omtrent onze resultaten hebben we nog niet. We moeten rekening houden met het feit dat
we te maken hadden met researchers in het CHI vakgebied, die misschien al meer interesse vertonen in
―extraatjes‖ rond het presenteren van gegevens. We kunnen dus nog niet sluitend antwoorden of onze
applicatie een gebruikerspubliek zal vinden. Nieuwe gebruikerstest s kunnen we best uitvoeren met een
prototype op computer, zodat we de functionaliteit als slepen en detail wat duidelijker kunnen maken, en
zodat we kunnen zien wat de gebruiker precies met de muis doet. We zullen moeten focusen op het
duidelijk maken van de items zoals de keyword filter, de detail slider en belangrijkst van al, de betekenis
van de pijlen. Een volgende test, met een nog niet beïnvloed publiek, zou bijvoorbeeld geslaagd zijn als
zeker 50% van de mensen binnen 30 seconden doorheeft waar hij naar kijkt, en familiair is met het
veranderen van detail. Een test met dergelijke gedetailleerde slaagcriteria hebben we nu echter nog niet
kunnen uitvoeren.
5 AANPAK VOLGENDE ITERATIE
Één van de pijnpunten in ons paper prototype was het zoomen. De bedoeling hiervan was dat de graaf
meer gedetailleerd werd indien men inzoomde en minder gedetailleerd naarmate men uitzoomde. Zoals
hoger vermeld was dit voor alle testpersonen verwarrend. Om dit te verhelpen hebben we een andere titel
boven de slider geplaatst, nl.: ‗DETAIL‘. Deze titel dekt meer de functionaliteit die we willen aanbieden.
Indien de gebruiker nu op het minteken naast de slider klikt , wordt de graaf op het scherm minder
gedetailleerd getekend. Er worden dan een aantal papers in de graaf weggelaten. We zullen dus een
criterium moeten hanteren om te bepalen welke papers we zullen weglaten. Alle proefpersonen hechtten
veel belang aan de reputatie van de auteur van de paper, dus waarschijnlijk zullen we dat gebruiken.
Ook hadden we in het paper prototype sommige verbindingen tussen papers vetter getekend dan andere.
Hiermee wilden we aantonen dat bepaalde papers meer gerelateerd waren dan andere. Voor de
testpersonen was het niet meteen duidelijk wat die vettere verbindingen betekenden. Één van de
proefpersonen gaf ook aan dat het aantal referenties naar een paper geen goede maatstaf was voor de
gerelateerdheid van 2 papers: het kan bijvoorbeeld zijn dat er in het begin verwezen wordt naar een heel
belangrijke paper en in de rest van het document niet meer. Hoewel ze zeer gerelateerd zijn is er dan maar
1 referentie. Daarom hebben we ervoor gekozen om dit niet langer te doen. In de komende iteraties zullen
alle verbindingen tussen papers dus even dik zijn.
Voor sommige testpersonen was het ook niet meteen duidelijk wat de pijlen juist betekenden. Iedereen
begreep wel dat we een soort relatie tussen papers wilden duidelijk maken, maar het was niet duidelijk
welke. Hiervoor hebben we nog niet echt een oplossing. We hebben overwogen om een soort legende toe te
voegen, maar dat zouden we liever willen vermijden. Dit is zeker iets waar we aandacht aan moeten
besteden in de volgende tests met proefpersonen, want het is zowat de kern van onze applicatie, en het zou
dus fataal zijn als die verkeerd geïnterpreteerd wordt.
Ook de keywords kwamen voor sommigen wat verwarrend over. Het was niet duidelijk wat er zou
gebeuren indien men één van de keywords aanvinkte. Hierover hebben we ook al nagedacht. We hebben
voorlopig 2 alternatieven; ofwel vinken we initieel alle keywords aan, om aan te geven dat alle gerelateerde
papers op dat niveau van detail weergegeven worden. Indien de gebruiker dan één van de keywords
uitvinkt, worden de papers waarin dat keyword belangrijk is weggelaten/kleiner+fade out (ook hier zijn er
weer verschillende alternatieven).
De andere manier is om initieel geen van de keywords aan te vinken. Indien de gebruiker dan een van de
keywords aanvinkt, worden enkel de papers weergegeven waarin dat keyword belangrijk is. Dit kan
misschien verwarrend overkomen, omdat in het begin geen enkel keyword aangevinkt is en toch alle
papers op dat niveau van detail worden weergegeven. Wat hier de beste oplossing is, zullen we moeten
bepalen aan de hand van bijkomende gebruikerstests.
Voor de volgende iteratie gaan we verder met een meer realistisch prototype. Aan de hand van enkele
statische html pagina‘s en een beperkte hoeveelheid javascript gaan we proberen de gebruikerservaring zo

8. goed mogelijk na te bootsen (met vast ingestelde search terms en results). Hierboven werden reeds een
aantal openstaande problemen aangehaald. In de volgende evaluatie(s) zullen we proberen hiervoor een
oplossing te vinden met behulp van ons meer realistisch prototype.
De overschakeling naar een meer realistische versie was volgens ons noodzakelijk. Met een papieren
prototype kan je wel nagaan of het idee van de applicatie goed is, en of er bepaalde functionaliteit
ontbreekt of teveel is. Dit kan echter maar tot op een zekere hoogte. Bijvoorbeeld het draggen van de graaf,
meer en minder detail, pop-ups bij mouseover, … zijn nu eenmaal dingen die moeilijk na te bootsen zijn
met een paper prototype. We hopen deze zaken met ons meer realistisch prototype ook te kunnen testen.
Het meest geschikte evaluatiecriterium voor onze applicatie is waarschijnlijk het aantal fouten dat een
gebruiker maakt. Om dit echt te testen kunnen we elke testgebruiker een bepaald scenario voorleggen en
telkens bijhouden hoeveel en welke fouten iedere gebruiker maakt. Op die manier kunnen we te weten
komen aan welke aspecten we extra aandacht moeten besteden. Eventueel kunnen we ook meten hoeveel
tijd en muisclicks de gebruiker nodig heeft voor dat scenario. Deze waarden kunnen we dan vergelijken
met de minimale tijd en het minimale aantal clicks dat we verwachten dat de gebruiker nodig zal hebben.
6 RESULTAAT
Algemeen gezien kunnen we uit de testen besluiten dat er voor de applicatie wel degelijk een afzetmarkt
bestaat. De testpersonen waren uiterst enthousiast over het idee. Eveneens konden we afleiden dat ons
beeld over de werkwijze van wetenschappers voor het opstellen van papers strookt met de werkelijkheid.
Wat de interface betreft, kunnen we zien dat er een possitieve evolutie geweest is. De proefpersonen
hebben enkele hekelpunten kunnen identificeren. Deze hebben we dan ook proberen oplossen.
Toekomstige tests zullen moeten aantonen of onze oplossingen een possitieve invloed gehad hebben.
Het belangrijkste probleem dat gevonden werd, is de betekenis van de pijlen in de grafische weergave.
Deze kunnen namelijk geïnterpreteerd worden als ―refereert naar‖ of ―wordt naar gerefereerd door‖. Hoe
we dit probleem gaan oplossen, is nog niet duidelijk.
Globaal kunnen we tevreden zijn met de gemaakte vooruitgang. In vergelijking met de eerste versie van de
applicatie, houdt de huidige vorm al veel meer rekening met de noden van de gebruiker.
7 BESLUIT
Uit deze eerste opdracht kunnen we heel wat lessen trekken voor het vervolg van de opdracht en voor de
ontwikkeling van gebruikersinterfaces in de toekomst.
De eerste en belangrijkste is misschien wel de verandering van perspectief: de meeste mensen met onze
achtergrond nemen meteen het standpunt van de maker in bij het ontwikkelen van applicaties. Bij het
ontwerpen van het storyboard was het de bedoeling dat we ons echt in de plaats van de gebruiker stelden.
In eerste instantie lukte dit (net als voor de andere groepen trouwens) niet zo goed. Een tweede poging
bracht ons al iets verder. Meer en meer bekeken we onze applicatie vanuit het perspectief van de gebruiker.
Met de tests met het paper prototype op de proefpersonen kregen we voor het eerst de kans ons idee op
echte researchers los te laten. Ook konden we testen of de functionaliteit die we in gedachten hadden
voldoende, overbodig, onvoldoende, onduidelijk,… was. Omdat we heel wat nuttige informatie uit deze
tests hebben gehaald, hebben we het nut van testen met een paper prototype echt wel ingezien. Je zal
sneller bereid zijn iets aan te passen aan een papieren prototype dan aan iets dat al helemaal of gedeeltelijk
geïmplementeerd is. De applicatie moet toch worden afgestemd op de gebruiker, dus is het beter en
makkelijker de aanpassingen al in een zo vroeg mogelijke fase door te voeren.
We vinden het ook een goed idee om voor de komende tests over te schakelen op een meer realistisch
prototype, omdat de zaken die we nog willen testen moeilijk te testen zijn op een papieren prototype.

9. APPENDIXi
Maarten Tielemans Jonas Hauquier Pieter-Jan Speelmans Nick Meuws Totaal
Evaluatie mendeley 4 6 7 4 21
Storyboard 6 8 2 10 26
Scherm-transitie-diagram 4 0 2 1 7
Implementatie papieren prototype 2 5 5 5 17
Evaluatie papieren prototype 5 8 5 5 23
Aanpak volgende iteratie 10 8 10 5 33
Totaal 31 35 31 30 127
i tijd in uren