AwesomRUs: CHI report 1
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

AwesomRUs: CHI report 1

  • 530 views
Uploaded on

AwesomRUs' first report of the CHI course at KULeuven

AwesomRUs' first report of the CHI course at KULeuven

More in: Education , Travel , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
530
On Slideshare
471
From Embeds
59
Number of Embeds
2

Actions

Shares
Downloads
5
Comments
0
Likes
0

Embeds 59

http://awesomerus.wordpress.com 57
http://static.slidesharecdn.com 2

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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