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 / 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 / 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 / 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 / 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 / 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 / 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 / 11

2.5 EVALUATIE: RESULTATEN METINGEN Visualisatie MooWheel JIT JUNG Opdracht 1

#clicks 2

sec. 3

#clicks 1

#clicks 2

sec. 3

#clicks 1

#clicks 2

sec. 3

#clicks voorkeur

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

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).

0

2

4

6

8

10

12

14

16

18

Vraag 1 (#clicks) Vraag 2 (sec.) Vraag 3 (#clicks)

MooWheel

JIT

JUNG

Doel

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 / 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

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 prototype

Werkende mock-up

Keywords: Titel: “Keywords” boven de te selecteren keywords.

Titel hernoemd naar “Filter by keyword” om geen verwarring te creëren

Filter by keyword functionaliteit is weggelaten.

De enige indicatie dat keywords geselecteerd zijn is een ingekleurde checkbox

Getallen tussen haakjes achter elk keyword moeten 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 met “+” en “-”

Om wat verwarring te voorkomen veranderd door “zoom in” en “zoom out”

Zoom functionaliteit is verdwenen bij alle visualisaties behalve bij de JIT interface. Hier heten de mogelijkheden nog steeds “zoom in” en “zoom out”.

Pijlen: Pijlen duiden op “refereert naar” relatie.

Pijlen duiden op “refereert naar” relatie.

Pijlen zijn weggelaten omdat ze voor verwarring zorgen. Enkel de Jung visualisatie bevat nog pijlen.

Popups Popups verdwijnen als muis van paper verdwijnt, tekst is niet selecteerbaar.

De gebruiker kan met zijn muis over een popup om er tekst uit te selecteren en kopiëren.

Popup is vervangen door vast tekstvak met info over de paper. Enkel de info over de 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.