1. 1 / 11
Gebruikersinterfaces: verslag 2
Groep 4
Blog http://awesomerus.wordpress.com/
Meuws Nick, Master Informatica
Jonas Hauquier, Master Informatica
Maarten Tielemans, Master Informatica
Pieter-Jan Speelmans, Master Computerwetenschappen
Abstract—In deze iteratie gingen we op zoek naar een interface waar het voor onze
gebruikers meteen duidelijk is welke papers belangrijk zijn in het zoekgebied van hun
keuze. Uit testen met drie visualisaties hebben we een goede visualisatie kunnen bepalen,
hoewel deze afweek van het beeld dat we origineel hadden.
Ingediend op: 17/05/2010
——————————  ——————————
1 BELANGRIJKSTE LESSEN UIT VORIGE PROTOTYPE
De belangrijkste opmerking over het papieren prototype is dat onze interface moeilijk te evalueren
was. Veel van de functionaliteit van ons concept hing af van details in de muisbediening. Zo
verscheen er een popup over een paper wanneer de gebruiker zijn muis over de paper zweefde en
moest een grafische voorstelling ingrijpend aangepast worden wanneer een gebruiker zoomde of
één van de filter aan de rechterkant van het scherm aan- of afvinkte. We losten dit op door onze
testpersonen uit te leggen wat er zou gebeuren bij het gebruik van deze tools. Dit had als nadeel dat
we geen volledig beeld konden hebben van wat onze testpersonen precies zouden doen met onze
applicatie. Door hen uitleg te geven, stuurden we hen namelijk in een bepaalde richting. Hierdoor
werden meetresultaten mogelijk vertekend.
We konden besluiten dat de Google-like interface voor het zoeken naar papers goed werkt. Al de
testpersonen waren hier zeer snel mee weg. Dit is waarschijnlijk ook te wijten aan het feit dat zeer
veel personen Google gebruiken en gewoon zijn met een dergelijke interface te werken. Dit zou
echter kunnen veranderen in de toekomst aangezien Google recent een wijziging in visualisatie
uitvoerde. Deze aanpassing is echter niet zo groot dat gebruikers de huidige visualisatie niet meer
zullen begrijpen. Het zou eventueel wel interessant kunnen zijn om net als de nieuwe interface van
Google categorieën en categoriespecifieke opties weer te geven om de zoekresultaten te verfijnen.
We leerden ook dat de proefpersonen over het algemeen wel geïnteresseerd waren in ons concept,
maar het waarschijnlijk niet zouden gebruiken op de manier die wij aanvankelijk in gedachten
hadden. Het scenario dat wij in gedachten hadden was:
“Een researcher die zich wil inwerken in een onderwerp waar hij nog niet veel van kent.”
Dit scenario is niet zo realistisch en de kans is klein dat het echt relevant is. Een beter doelpubliek
voor onze applicatie is:
“Studenten die meer over een onderwerp willen leren, bijvoorbeeld om een thesis over te
schrijven.”

2. 2 / 11
We ondervonden vooral problemen bij de visualisatie van de relaties tussen papers:
• Het was voor proefpersonen (en onszelf) niet steeds duidelijk wat de betekenis van een pijl
tussen twee papers is. Zo kan het betekenen “paper1 verwijst naar paper2”, maar ook “er
wordt naar paper1 verwezen door paper2”.
• Het was onduidelijk wat de filter in onze visualisatie juist deed. De proefpersonen konden
niet inschatten wat het effect zou zijn indien er iets aangepast werd in de filterlijst.
• Het was onduidelijk wat de “zoom-tool” in onze visualisatie juist deed. Zoomen kan op twee
manieren geïnterpreteerd worden. Aan de ene kant kan de grafe groter getekend worden en
aan de andere kant kunnen (zoals de bedoeling was) meer of minder papers getoond
worden.
Het belangrijkste probleem is de onduidelijkheid wat de pijlen betekenen aangezien het hele doel
van de applicatie was om de referenties tussen de papers te tonen. Het probleem met de filter en de
zoom-tool waren voor ons minder belangrijk aangezien de focus van het programma hier niet op lag.
Dit zijn namelijk eerder features dan echte kernfunctionaliteit.
Zoals eerder aangeduid hebben we bij de evaluatie onze proefpersonen wat moeten sturen,
waardoor we mogelijk de resultaten wat beïnvloed hebben. Een aandachtspunt voor de volgende
iteratie zal dan ook zijn om een manier te zoeken om ons concept beter te testen. Dit beter testen zal
bestaan uit een prototype in een vorm waarin interactie met gebruiker beter te testen valt en het
bedenken van testen met meetbare proeven zoals de tijd die een gebruiker nodig heeft om de
visualisatie te analyseren.
2 NIEUWE ITERATIE
2.1 AANPAK
Aangezien de voorgestelde manier van visualiseren moeilijk te testen was met het papieren
prototype, kozen we er voor om een tweede iteratie te doen met mock-ups. Dit laat ons toe om de
gebruikers op een directere manier onze applicatie te laten gebruiken.
Om het probleem met de onduidelijke grafe op te lossen, besloten we testen te doen met
verschillende visualisaties in plaats van met één visualisatie. Dit laat ons toe om vergelijkende testen
te doen tussen deze visualisaties. De visualisaties willen we kunnen evalueren aan de hand van
gebruikerstests met mock-ups. Verder besloten we ook de filters en zoom-functionaliteit te
verwijderen uit de applicatie.
In de presentatie van Namahn tijdens de laatste les haalde Jonannes deze techniek ook kort aan. Hij
gebruikte de term A/B Testing (soms ook A/B/N Testing, indien men meer dan twee varianten
gebruikt om te testen). Hierbij worden twee (of meer) varianten van hetzelfde product parallel
losgelaten op een testpubliek om zo te weten te komen welke variant de beste is. Hij zei dat het een
veelgebruikte techniek is in de wereld van gebruikersinterfaces die ook gebruikt wordt door grote
bedrijven als Apple.
Voor de keuze van visualisaties waren er twee alternatieven:

3. 3 / 11
• Zelf enkele visualisaties ontwerpen: dit laat ons toe om visualisaties specifiek voor ons doel
te ontwikkelen. Het nadeel hieraan is dat er veel tijd in het ontwerp kruipt en dat de meeste
aanpassingen daarna elke keer weer veel tijd in beslag zullen nemen.
• Enkele visualisaties opzoeken en toepassen op ons probleem: hiermee kunnen we (hopelijk)
de visualisaties snel toepassen op onze dataset. Dit laat ons toe om een groot aantal
visualisaties te testen. Het nadeel is dat de visualisaties waarschijnlijk niet zal overeenkomen
met wat we in gedachte hebben.
Uiteindelijk kozen we er voor om enkele visualisaties op te zoeken aangezien we op deze manier een
bredere waaier aan visualisaties kunnen uitproberen. Het nadeel dat deze visualisaties waarschijnlijk
niet zijn wat we initieel in gedachte hadden, wordt grotendeels afgezwakt aangezien we met deze
testmethode meer feedback van de gebruiker krijgen.
Het scherm-transitie-diagram voor onze applicatie is hetzelfde gebleven. Uit de eerste iteratie blijkt
dat de command-line zoek interface zeer duidelijk is en dit willen we behouden in onze applicatie. De
schermen met visualisaties zullen vervangen worden door de nieuwe visualisaties.
2.2 IMPLEMENTATIE
De implementatie van de mock-ups nam relatief veel tijd in beslag. Dit is vooral te wijten aan het feit
dat passende visualisaties voor onze applicatie moeilijk te vinden waren. In eerste instantie werd er
vooral gezocht naar toolkits om grafes weer te geven. Toen we hier onvoldoende bruikbaar materiaal
vonden, schakelden we over op zoeken naar algemene visualisatiepakketten. Dit leverde ons echter
een overvloed aan onbruikbare visualisaties op.
Gezien ons gemeld werd dat Bram Vandeputte werkt aan een project dat hard op onze applicatie
lijkt, gingen we bij hem om raad vragen. Hij zei ons dat we best niet te veeleisend waren, want dat
we de perfecte visualisatie toch nooit zouden vinden. Elke visualisatie die je niet zelf ontwikkelt,
heeft voor- en nadelen. Hij zei ons ook dat we er misschien best gewoon enkele konden uittesten.
Uiteindelijk vonden we dan toch enkele visualisaties die min of meer voldoen aan onze criteria:
• http://labs.unwieldy.net/moowheel/
• http://www.graphviz.org/
• http://jung.sourceforge.net/
• http://thejit.org/
• http://prefuse.org/
Uit deze lijst, kozen we er voor om MooWheel, Java Universal Network/Graph Framework (JUNG) en
JavaScript InfoVis Toolkit (JIT) in te bouwen in onze mock-ups. Deze visualisaties leken ons het meest
capabel om grote hoeveelheid papers te tonen. Bovendien leunen deze visualisaties aan bij het ons
originele concept over hoe we de relaties tussen papers willen weergeven.
Eenmaal de visualisaties gevonden waren, gingen we op zoek naar data voor de mock-up. Om de
mock-ups zo realistisch mogelijk te maken, wouden we deze vullen met data zoals deze in de
uiteindelijke applicatie te zien zou zijn.
Al snel vonden we enkele websites waar we datasets konden vinden zoals:

4. 4 / 11
• http://www.scientificcommons.org/
• http://citeseerx.ist.psu.edu/
We importeerden vervolgens de citeseer gegevens in onze database en genereerden enkele basis
datasets voor de mock-ups. Vervolgens implementeerden we de visualisaties. Dit verliep relatief vlot.
Het grootste probleem dat we tegenkwamen, was het verschil in datasets gebruikt door de
verschillende visualisaties. Enkele kleinere problemen waren vooral te wijten aan de onduidelijke
API’s van de frameworks.
Toen eenmaal de implementaties gebruiksklaar waren, kwamen we tot de conclusie dat indien we
het gebruik van de applicatie goed wouden nabootsen, we een relatief groot aantal datasets nodig
zouden hebben. Aangezien we reeds beschikten over database servers en code om datasets te
genereren, besloten we deze database en de code te optimaliseren zodat we “on the fly” nieuwe
datasets zouden kunnen genereren. Hoewel het genereren van deze datasets in sommige gevallen
nog relatief lang duurt, resulteerde dit eigenlijk in de implementatie van de volledige applicatie. Het
resultaat zijn dus drie werkende visualisaties voor onze applicatie.
De mock-ups beginnen allemaal met een algemeen beginscherm (Figuur 1) waar de gebruiker een
zoekterm invoert en op search klikt. Vervolgens krijgt de gebruiker een lijstweergave (Figuur 2) met
alle papers die voldoen aan de opgegeven zoektermen.
Figuur 1: Algemeen zoekscherm
Wanneer de gebruiker dan één van de papers uit die lijst selecteert, verschijnt afhankelijk van de
mock-up een scherm met de visualisatie van de relaties tussen de papers. In de MooWheel
visualisatie (Figuur 3) komen de titels van de papers te staan in een cirkel. De relaties tussen de
papers worden dan uitgedrukt door lijnen tussen de papers. Onder deze cirkel staat een kader met
de informatie van de gekozen paper.
De gebruiker kan door met de muis over de titel van een paper te zweven, de relaties van die paper
met de andere papers tonen. Indien een gebruiker op een titel klikt, verandert de weergave en
worden de papers gerelateerd aan de gekozen paper getoond. Ook de informatie onderaan de
visualisatie wordt geüpdatet.

5. 5 / 11
Figuur 2: Algemeen zoekresultaten
Figuur 3: MooWheel visualisatie
Figuur 4: JUNG visualisatie
De JUNG visualisatie (Figuur 4) toont net als de MooWheel visualisatie de papers in een cirkel en de
informatie van de gekozen paper in een kader. Deze visualisatie heeft echter pijlen die aanduiden

6. 6 / 11
“paper1 verwijst naar paper2”. Wanneer een gebruiker op een paper klikt, verandert de focus en
worden de papers sterk gerelateerd met de gekozen paper getoond.
De JIT visualisatie tenslotte (Figuur 5) toont een grafe van alle papers gerelateerd aan een gekozen
paper. De informatie over de gekozen paper staat aan de rechterzijde. Hier staan ook knoppen om de
grafe groter of kleiner weer te geven. Indien een gebruiker op een paper klikt, wordt de
informatiekader geüpdatet en verschuift deze paper naar het midden van de grafe. De andere papers
schikken zich dan rond de gekozen paper. Er wordt in tegenstelling tot in de andere twee weergaves,
geen nieuwe grafe getekend. De huidige grafe wordt dus enkel op een andere manier weergegeven.
Figuur 5: JIT visualisatie
2.3 EVALUATIE: AANPAK EN DOEL
Om de goede en slechte kwaliteiten van elk van de drie visualisaties te weten te komen, maken we
gebruik van gebruikerstests. Op deze manier kunnen we dan de beste visualisatie voor de relaties
tussen papers kiezen. Het is uiteraard ook mogelijk dat uit de tests geconcludeerd moet worden dat
geen van de gekozen visualisaties een goede is voor ons probleem.
Om de beste visualisatie te kiezen, gebruiken we volgende criteria:
1. het aantal nodige clicks om van een gekende paper de relevante papers op te kunnen
zoeken;
2. het aantal seconden dat een gebruiker nodig heeft om de belangrijke papers gerelateerd aan
de gezochte paper te kunnen herkennen;
3. het aantal clicks dat een gebruiker nodig heeft om informatie van een paper gerelateerd aan
de gezochte paper te kunnen opzoeken.
Op basis van deze criteria kunnen we dan volgende eigenschappen afleiden:
• hoe vlot in de gekozen visualisatie een paper gevonden kan worden;
• hoe overzichtelijk de visualisatie is;
• hoe duidelijk de uitgedrukte relaties zijn voor de gebruiker.
Verder zijn we ook benieuwd welke visualisatie de voorkeur van de gebruiker heeft.

7. 7 / 11
Voor de gevonden criteria stellen we volgende doelen op:
1. Als maximum 2 clicks om een paper te vinden.
• Dit is eveneens het minimum. We willen dus dat gebruikers het optimale pad kiezen
voor het vinden van een paper.
2. Als gemiddelde tijd om informatie terug te vinden 10 seconden.
• Afhankelijk van het aantal getoonde papers kan dit getal sterk omhoog gaan. We
willen dus met eenvoudige en duidelijke grafen werken zodat er niet te veel gescrold
moet worden. Hiervoor moet 10 seconden voldoende zijn. We laten de laadtijd
buiten beschouwing.
3. Als maximaal 1 click om informatie te vinden over een andere interessante paper.
• Ideaal komt dit neer op één click op de grafe. Het zou ook mogelijk zijn om opnieuw
te gaan zoeken. In dit geval komt het neer op twee clicks. We willen dus testen of de
gebruiker begrijpt dat hij kan klikken op een paper om de informatie van deze paper
te vinden.
2.4 EVALUATIE: VERLOOP
Omdat we nog niet klaar waren om te testen met proefpersonen op de voorziene momenten tijdens
de les, hebben we zelf voor proefpersonen moeten zorgen. Omdat we ons met onze applicatie
richten tot studenten was dit echter geen probleem. Als testpersonen konden we dus mensen uit
onze onmiddellijke omgeving gebruiken. Alle proefpersonen waren studenten aan de hogeschool of
universiteit. De leeftijd lag tussen 19 en 23 jaar.
Voor elk van de drie visualisaties vroegen we de proefpersonen de volgende opdrachten uit te
voeren:
1. Zoek naar papers gerelateerd met de paper ‘Genetic Programming for Articulated Figure
Motion’
2. Welke paper is sterk gerelateerd met het domein van de huidige paper? Welke zeer zwak?
3. Één van de papers gerelateerd met deze paper is ‘Een willekeurige titel uit de graaf’. Geef de
auteur van deze paper.
Na het afnemen van de test met deze drie visualisaties, vroegen we nog welke visualisatie hun
voorkeur kreeg.
De problemen die we tegenkwamen tijdens het evalueren waren:
• Papers waar zeer vaak naar gerefereerd wordt en die zelf veel refereren naar andere papers,
gaven aanleiding tot grafen die te groot waren voor het scherm of onduidelijk werden.
• Aangezien de prototypes gebruikt bij de evaluatie steunden op een trage database server,
duurde het laden van een nieuwe grafe soms net iets te lang. Hierdoor moesten we de
proefpersoon gerust stellen dat het systeem zijn click had geregistreerd en de aanpassing ten
gevolge van deze click uitgevoerd zou worden.

8. 8 / 11
2.5 EVALUATIE: RESULTATEN
METINGEN
Visualisatie MooWheel JIT JUNG
Opdracht 1 2 3 1 2 3 1 2 3 voorkeur
#clicks sec. #clicks #clicks sec. #clicks #clicks sec. #clicks
Persoon 1 2 6 1 2 18 1 2 12 1 MooWheel
Persoon 2 2 9 1 2 10 1 2 10 2 JIT
Persoon 3 2 18 1 2 30 1 2 27 2 MooWheel
Persoon 4 2 15 1 2 25 1 2 19 1 MooWheel
Persoon 5 2 3 1 2 14 1 2 4 2 MooWheel
Persoon 6 2 3 1 2 4 1 2 3 3 JIT
Tabel 1: Metingen per visualisatie
OBSERVATIES
18
16
14
12 MooWheel
10 JIT
8
JUNG
6
Doel
4
2
0
Vraag 1 (#clicks) Vraag 2 (sec.) Vraag 3 (#clicks)
Figuur 6: Gemiddelde per opdracht per visualisatie
Alle testpersonen slagen erin om van een paper waarvan ze de titel kennen, de gerelateerde papers
te vinden in twee clicks (vraag 1). Voor dit scenario volgt iedereen dus het perfecte pad en wordt het
vooropgestelde doel voor elke visualisatie gehaald (zie figuur 6).
Voor het ontdekken van sterke en zwakke relaties tussen bepaalde papers (vraag 2) zien we in tabel 1
dat met MooWheel vier op zes testpersonen het vooropgestelde doel van 10 seconden halen. Voor
JIT en JUNG is dit respectievelijk twee op zes en drie op zes. Figuur 6 laat zien dat enkel de
gemiddelde waarde van MooWheel onder de vooropgestelde grenswaarde ligt. Voor dit criterium is
MooWheel dus de beste visualisatie.
Het opzoeken van de auteur van een gerelateerde paper (vraag 3) gebeurt in de MooWheel en de JIT
visualisatie steeds volgens het vooropgestelde doel, nl. 1 click. Voor JUNG is dit slechts in twee van de
zes keren het geval. Dit is ook zichtbaar in figuur 6; het gemiddelde voor JUNG ligt boven de
doelwaarde.
Op de vraag welke visualisatie men de beste vindt om gerelateerde papers op te zoeken antwoordde
vier van de zes testpersonen MooWheel. De twee overige kozen voor JIT (zie tabel 1).

9. 9 / 11
2.6 EVALUATIE: BELANGRIJKSTE LESSEN
Uit deze evaluatie kunnen we besluiten dat de MooWheel visualisatie de meest geschikte is om mee
door te werken. Het is de enige visualisatie die voor alle criteria onder het vooropgestelde doel blijft.
Vooral voor het tweede criterium (hoe hard papers gerelateerd zijn) is dit goed. Dit criterium is het
belangrijkste van onze evaluatie: het moet namelijk meteen duidelijk zijn welke papers belangrijk zijn
in het domein van de opgezochte paper en welke minder. Hierbij komt nog dat de meerderheid van
de proefpersonen (vier op zes) aangaf het liefst met MooWheel te werken om gerelateerde papers op
te zoeken. Dit was meteen ook het belangrijkste doel van deze iteratie: het vinden van een goede en
duidelijke visuele representatie.
De belangrijkste problemen die we nu nog hebben zijn:
1. Wanneer iemand een paper met veel referenties opzoekt, explodeert de grafische weergave.
Dit heeft als gevolg dat de grafe te groot wordt om in het scherm te passen. Dit is nadelig
voor de tijd waarin een gebruiker kan zien welke papers nuttig zijn. Indien de belangrijke
papers van het scherm vallen, moet er uiteraard gezoomd of gescrold worden.
2. De traagheid van het prototype gaf soms aanleiding tot frustratie bij de gebruikers aangezien
er nergens een laadbalkje zichtbaar is. Er kan dus onduidelijkheid bestaan of een click reeds
geregistreerd is of niet.
Om deze problemen op te lossen, stellen we volgende mogelijke oplossingen voor:
• Probleem 1: om dit probleem op te lossen, kunnen we het aantal gerelateerde papers in de
grafe gaan beperken. Dit kunnen we realiseren op volgende manieren:
o Het filteren van de teruggegeven resultaten op basis van aantal referenties en het
toevoegen van een knop op de filter strenger (minder papers) of losser (meer papers)
te maken.
o Het toevoegen van een aanmeld mogelijkheid waardoor we kunnen filteren op basis
van voorkeuren en zoekgeschiedenis van een gebruiker. Op deze manier kunnen de
zoekresultaten gepersonaliseerd worden. Ook in dit geval moeten we knoppen
toevoegen voor het aanpassen van de filter.
• Probleem 2: dit probleem is eigen aan het prototype maar het is vanzelfsprekend ook nodig
rekening te houden met gebruikers die een tragere internetverbinding hebben. Hier kan
namelijk een gelijkaardig probleem optreden. Het oplossen van het probleem met een
snellere databaseserver is dus geen goede optie. Het invoegen van een laadbalkje is echter
wel een mogelijke oplossing aangezien op deze manier de gebruiker feedback krijgt.
3. BESLUIT
Indien we de resultaten van het project bekijken, merken we op dat een applicatie bekijken vanuit
het standpunt van de gebruiker tot verrassende nieuwe inzichten kunnen leiden. Deze kunnen
aanleiding geven tot het ontwikkelen van een applicatie die simpelweg beter is. Dit is in de eerste
plaats beter voor de gebruiker ervan maar ook vanuit het oogpunt van de ontwerper. Er zijn namelijk
veel aspecten die je uit het oog verliest als ontwerper. Dit merken we vooral wanneer we naar de
evolutie van onze interface kijken. Zo hadden we eerst een lijst met filters en zoom knoppen
aangezien we dit zelf handige features vonden. Uit testen bleek toen echter dat gebruikers deze

10. 10 / 11
features nutteloos vonden en we ons beter konden focussen op de eigenlijke relaties tussen de
papers.
Ook in die weergave van de relaties tussen papers hebben we grote aanpassingen gemaakt. De
gebruikerstesten toonden aan dat de MooWheel visualisatie de beste is. Deze visualisatie is echter
anders dan de visualisatie die we initieel in gedachte hadden (een grafe met pijlen). Indien we dus
vastgehouden hadden aan dit initiële idee, hadden we dus mogelijk veel tijd verspild aan een
onduidelijke interface. We hebben er dus goed aan gedaan verschillende al beschikbare interfaces te
testen in plaats van onze energie te stoppen in het zelf bouwen van een interface.
Ten slotte kunnen we ook zien dat het goed is dat er vanaf de tweede iteratie een focus was op één
enkel werkingspunt: het zoeken van een goede visualisatie. Indien we meer features zouden hebben
voorzien, was hier veel tijd in gekropen. We hadden dan de visualisatie minder goed kunnen
uitwerken. Het was dus beter geweest indien we de focus al vanaf het eerste prototype vastgelegd
hadden.
REFERENCES
Gross, Joshua. Moowheel: A javascript connections visualisation library. 2008.
http://labs.unwieldy.net/moowheel/ (toegang 16 mei 2010).
O'Madadhain, Joshua et al. JUNG: Java Universal Network/Graph Framework. 2010.
http://jung.sourceforge.net/ (toegang 16 mei 2010).
Garcia Belmonte, Nicolas. Javascript InfoVis Toolkit: Interactive Data Visualizations for the Web.
2010. http://thejit.org/ (toegang 16 mei 2010).
The College of Information Sciences and Technology. CiteSeerX: Scientific Literature Digital Library
and Search Engine. 2010. http://citeseerx.ist.psu.edu/ (toegang 16 mei 2010).
Meuws, Nick, Tielemans, Maarten, Speelmans, Pieter-Jan & Hauquier, Jonas. Gebruikersinterfaces:
verslag 1. 2010.
Meuws, Nick, Tielemans, Maarten, Speelmans, Pieter-Jan & Hauquier, Jonas. AwesomeRUs: Just
Another CHI Weblog. 2010. http://awesomerus.wordpress.com (toegang 16 mei 2010).
APPENDIX
GEPRESTEERDE UREN
Nick Meuws Jonas Hauquier Maarten Tielemans Pieter-Jan Speelmans Totaal
Bespreking aanpak 12 12 12 12 48
Implementatie 6 6 16 20 48
Evaluatie: verloop 1 0 1 1 3
Evaluatie: analyse resultaten 3 0 0 0 3
Schrijven verslag 14 5 11 15 45
Totaal 36 23 40 48 147

11. 11 / 11
OVERZICHT VAN DE MEEST FUNDAMENTELE VERANDERINGEN IN DE EVOLUTIE VAN ONZE
PROTOTYPES
In de eerste twee prototypes werkten we met de visualisatie uit ons initieel concept. In het derde prototype
werd geëxperimenteerd met drie verschillende visualisaties. De aanpassing van het papieren prototype
gebeurde nog tijdens het testen met het papieren prototype. De aangebrachte veranderingen waren
gebaseerd op rechtstreekse commentaar van de proefpersonen (wat zou u aanpassen aan het huidige
prototype).
Papieren prototype Aanpassing papieren Werkende mock-up
prototype
Keywords: Titel: “Keywords” boven de te Titel hernoemd naar “Filter Filter by keyword
selecteren keywords. by keyword” om geen functionaliteit is weggelaten.
verwarring te creëren
De enige indicatie dat Getallen tussen haakjes
keywords geselecteerd zijn is achter elk keyword moeten
een ingekleurde checkbox aanduiden hoeveel papers
gelinkt zijn aan dat keyword.
Om de gebruiker een
indicatie te geven hoe de tags
zich relateren tot het
getoonde resultaat.
Zoom: Zoom in en uit was aangeduid Om wat verwarring te Zoom functionaliteit is
met “+” en “-” voorkomen veranderd door verdwenen bij alle
“zoom in” en “zoom out” visualisaties behalve bij de JIT
interface. Hier heten de
mogelijkheden nog steeds
“zoom in” en “zoom out”.
Pijlen: Pijlen duiden op “refereert Pijlen duiden op “refereert Pijlen zijn weggelaten omdat
naar” relatie. naar” relatie. ze voor verwarring zorgen.
Enkel de Jung visualisatie
bevat nog pijlen.
Popups Popups verdwijnen als muis De gebruiker kan met zijn Popup is vervangen door vast
van paper verdwijnt, tekst is muis over een popup om er tekstvak met info over de
niet selecteerbaar. tekst uit te selecteren en paper. Enkel de info over de
kopiëren. gefocuste (aangeklikte) paper
wordt getoond. Tekst is
gemakkelijker klikbaar, en
bijvoorbeeld een link naar
Google of andere science 2.0
pagina’s is makkelijk
toevoegbaar.