CHI 2009-2010 1/17

Gebruikersinterfaces: finale verslag Groep 3

Blog http://guijoe.wordpress.com/

Peter De Roovere, 1e Ma Ing. Wet.: Computerwet. optie Gedist. Syst. Laurens De Vocht, 1e Ma Ing. Wet.: Computerwet. optie Mens-Machine Comm.

Jan Grauwels, 1e Ma Ing. Wet.: Computerwet. optie Mens-Machine Comm. Joris Van den Broeck, 1e Ma Ing. Wet.: Computerwet. optie Veilige Software

Abstract—Dit is het finale verslag voor gebruikersinterfaces, van groep 3. Wij hebben een nieuwe iteratie-cyclus uitgewerkt voor onze markeertoepassing. Dit verslag geeft een overzicht van de eerder doorlopen ontwikklingsiteraties en beschrijft een extra, derde evaluatieronde. De belangrijkste uitdagingen bij deze iteratie waren het correct onderzoeken van de beste manier om belangrijjke informatie in papers voor te stellen aan gebruikers. Hieruit leerden wij vooral dat het niet evident is een groot aantal testpersonen te bereiken en dat het voor sommige zaken niet evident is correcte tests op te stellen. Dit verslag dient verder als een overzicht van alle ontwikkelingsstappen die bij dit gebruikersinterfaces-project doorlopen zijn.

Ingediend op: 14 mei 2010

—————————— ——————————

1 INLEIDING EN OVERZICHT Belangrijke papers efficiënt lezen, onbekende papers onmiddellijk vatten. Dat is het doel dat we met deze applica-

tie nastreven. Bepaalde bronnen [1] tonen aan dat het maken van markeringen van belangrijke stukken bij het lezen van teksten de concentratie bevorderen. Bovendien worden gemarkeerde woorden/zinnen onmiddellijk opgemerkt. Met deze informatie in het achterhoofd ontwikkelden we het idee van onze toepassing, te beschouwen als een soort sociaal highlighting-systeem.

Gebruikers markeren belangrijke zaken bij het lezen van papers. Op basis van wat gemarkeerd is kan aan gebruik-ers die een paper niet kennen een overlay getoond worden waarbij de belangrijkste (meest gemarkeerde) onderdelen aangeduidt worden. Opdat de manier waarop papers gelezen kunnen worden en markeringen gemaakt kunnen wor-den werd beslist de applicatie uit te werken voor een iPad of gelijkaardig touch-toestel.

In dit hoofdstuk wordt een beknopt overzicht gegeven van de manier waarop we de ontwikkeling van de applicatie hebben aangepakt. Daarna wordt elke iteratie in meer detail besproken. Vervolgens wordt gekeken naar gelijkaardige applicaties. Daarna bespreken we bondig verkregen feedback. Als afsluiter volgt een algemeen besluit.

1.1 ITERATIE I We gingen van start met een onderzoek van de kans op slagen van het idee (is de applicatie nuttig?). Het uitwerken

van een applicatie waarvan achteraf blijkt dat het concept fout zit zou uiteraard dom zijn. We schotelden testpersonen uit het doelpubliek vragenlijsten voor. We wilden te weten komen hoe zij papers lezen, of ze gebruik maken van markeringen, hoe ze deze papers lezen (computer, papier, …). Daarnaast vroegen we ze rechtuit of ze de applicatie zouden gebruiken. Tot slot lieten we ze effectief een paper markeren om te onderzoeken of bepaalde onderdelen meermaals als belangrijk geïdentificeerd werden. We leerden dat er interesse is in de applicatie. Dat bepaalde onder-delen bijna steeds terugkeerden als zijnde belangrijk in papers. Verdere ontwikkeling van de applicatie is dus gerecht-vaardigd. Ook belangrijk was de opmerking dat gebruikers het belangrijk vonden dat de toepassing geen vertraging introduceerde ten opzichte van de applicaties die ze gebruikten. Daarnaast lazen de meeste gebruikers papers op de computer en drukte ze deze af voor markeringen toe te voegen of opmerkingen bij te schrijven.

In parallel met dit proces werd in dit stadium ook al nagedacht over de structuur van de applicatie. Een storyboard en scherm-transitie diagram werden gecreëerd. Feedback over deze structuur werd gekregen door testen met een pa-pieren prototype (is de gebruikersinterface goed ontworpen?). Het ‘think-aloud’ protocol werd hiervoor aangewend. We leerden dat gebruikers vlot met de applicatie konden werken. Een puntje dat voor verbetering vatbaar was was de manier waarop gebruikers konden terugkeren naar eerder bekeken papers (MyPapers).

Een gedetailleerde beschrijving van deze iteratie volgt in hoofdstuk 2. Afbeelding vat samen.

CHI 2009-2010 2/17

1.2 ITERATIE II Voortgaande op de lessen geleerd uit de eerste iteratie volgde de tweede iteratie. Om na te gaan hoe onze applicatie zich verhoudt tot bestaande veelgebruikte toepassingen (vergelijken workflow)

voor het lezen van papers creëerden we een digitaal storyboard. De tijd nodig voor het uitvoeren van taken zou dan gemeten kunnen worden. We vroegen gebruikers taken uit te voeren (maken van markeringen, papers zoeken en openen) enerzijds met onze toepassing, anderzijds met Voorvertoning en Adobe Acrobat Reader, twee veelgebruikte pdf-readers. We leerden dat onze toepassing steeds beter presteerde.

Daarnaast wilden we de onduidelijkheid (zie iteratie I) met betrekking tot de MyPapers functionaliteit ophelderen. We veranderden de manier waarop deze zichtbaar was (groter symbool, andere benaming) en evalueerden weer met testgebruikers, ditmaal met het digitale storyboard. We leerden dat gebruikers de functie nu makkelijk terugvonden.

Tot slot wilden we nagaan hoe makkelijk (of moeilijk) gebruikers markeringen kunnen maken op touch-toestellen. Het markeren van teksten is immers erg belangrijk voor de toepassing. Hiervoor vergeleken we het maken van markeringen met een computer (muis, touchpad) met touch-principes op een iPhone (er was immers geen iPad beschikbaar) en met de klassieke manier op papier. Dit deden we door proefpersonen specifieke zinnen te laten mark-eren met elk van deze. We ontdekten dat het standaard markeerprincipe van de iPhone (en iPad) sterk scoort en dat zullen we dus aanwenden.

Hoofdstuk 3 geeft een uitgebreid verslag van deze iteratie. Afbeelding 2 vat samen.

1.3 ITERATIE III Het concept, de structuur, de verhouding tot andere toepassingen en het principe van het maken van markeringen

zijn reeds onderzocht. Een laatste belangrijk (wat betreft de tijdsspanne beschikbaar gesteld voor het project) aspect dat we nu nog wilden onderzoeken was de manier waarop de ‘community highlights’ weergegeven worden. We gingen op zoek naar een aantal principes en bedachten een test om te onderzoeken welk principe het meest efficiënt belangri-jke informatie duidelijk maakt. Ondanks een ditmaal minder geslaagde test concludeerden we dat het gebruiken van een overlay met verschillende lagen, overeenkomstig met de belangrijkheid, de beste oplossing vormt.

Hoofdstuk 4 gaat hier verder op in. Afbeelding 3 vat samen.

Afbeelding 1

Afbeelding 2

CHI 2009-2010 3/17

Afbeelding 3

CHI 2009-2010 4/17

2 ITERATIE I

2.1 AANPAK Deze iteratie vormt het begin van het ontwikkelingsproces van onze applicatie. We gingen van start met een brain-

storm-sessie rond het thema science 2.0. Na het overlopen van de resultaten die deze opleverde kwamen we tot het concept van 'gelinkte papers'. Een video die het storyboard op basis van dit idee beschrijft is terug te vinden op onze blog [2].

Een herevaluatie van dit idee (door gesprekken binnen de groep, met de begeleider en met medestudenten) leidde er echter toe dat ons geloof in het idee verzwakte. We zagen in dat enerzijds het linken van papers reeds bevat zit in de referenties die papers hebben en dat anderzijds gebruikers, volgens ons, niet makkelijk te motiveren zijn om gelijkaar-dige papers te linken.

We besloten het roer om te gooien en een nieuw concept te bedenken. Een punt dat tijdens de brainstorm-sessie naar voren kwam is dat we gebruikers efficiënt en snel papers willen laten doorgronden. Na het lezen van een artikel [1] dat het nut van markeren bij het lezen aanstipt bedachten we het idee van onze markeer-toepassing.

Een beschrijving van dit idee en de link ervan met het artikel zijn terug te vinden in de paragraaf 1. Idee van verslag 1. Ook wordt hier een vergelijking gemaakt met Mendeley en de ideeën van andere groepen en wordt het eerste alter-natieve concept (gelinkte papers) en de tegenargumenten hiervan besproken.

De aanpak in deze iteratie bestond uit drie luiken, die beschreven worden in de volgende drie paragrafen:

A- STORYBOARD EN SCHERM-TRANSITIE DIAGRAM Ten eerste creëerden we een storyboard van hoe wij de applicatie voor ogen hadden. Een grote uitdaging hierbij

was het kijken naar de applicatie vanuit het standpunt van de gebruiker. Het storyboard moest een verhaal vertellen over hoe een gebruiker de applicatie zou gebruiken. Daarnaast werden we verplicht concreet na te denken over de vorm van de applicatie. Het resultaat kan bekeken worden op onze blog [2] en wordt grondig besproken in de para-graaf 2. Storyboard van verslag 1.

We hebben vooral getracht de structuur van de applicatie zo beperkt mogelijk te houden. We hebben niet nagedacht over elk aspect. Het is zo dat de lijst met zoekresultaten, zichtbaar in figuur 1 uit paragraaf 2. Storyboard van verslag 1 wellicht geen goede manier is om de resultaten weer te geven. We wilden hier echter aangeven dat een lijst getoond wordt. De manier waarop dit best gebeurde werd niet onderzocht.

Ook wordt in de concrete toelichting (subparagraaf Concreet uit paragraaf 2. Storyboard) niet duidelijk gemaakt hoe een gebruiker aangeeft dat hij een paper later wil terug lezen. Hier was op dit punt geen optie voor voorzien. We ve-ronderstelden dat de gebruiker de applicatie laat open staan en namen dit op zodat zowel het lezen van gemarkeerde papers als het zelf maken van markeringen in het storyboard betrokken konden worden, terwijl één verhaal verteld kon worden over hoe één gebruiker de toepassing gebruikt.

Naast het storyboard hebben we ook een scherm-transitie diagram gemaakt. We werden gedwongen na te denken over de structuur van de toepassing. Paragraaf 3. Scherm-transitie-diagram uit verslag 1 beschrijft dit diagram. De op-merking dat we de 'My Highlighted Papers'-pagina als de startpagina voor ingelogde gebruikers kunnen beschouwen is zeker terecht. Anderzijds wilden we gebruikers toelaten op elke pagina in te loggen en wilden we de consistentie behouden dat een gebruiker na inloggen de pagina blijft zien waar hij zich bevond.

B- KANS OP SLAGEN VAN HET CONCEPTi Ten tweede was het voor ons belangrijk zo snel mogelijk na te gaan wat de kans was dat het idee achter onze

toepassing zou slagen. We beseften dat het concept nogal gewaagd is, zoals ook aangegeven in alinea 3 van Paragraaf 1. Idee. We realiseerden ons dat alle verdere ontwikkelingen die nog zouden gebeuren nutteloos zouden zijn indien het idee van de applicatie geen potentieel zou hebben.

Het gebruik van een vragenlijst (meer informatie in paragraaf 2.4 van dit verslag) leek ons de gepaste methode om na te gaan in hoeverre het doelpubliek het doel van de toepassing zou appreciëren.

Daarnaast wilden we ook te weten komen of mensen die papers lezen effectief gelijkaardige (belangrijke) stukken markeren. Het effectief laten markeren van papers en een vergelijking van de gemarkeerde delen leek ons hiervoor gepast.

C- WERKEN MET DE APPLICATIE Ten derde wilden we nagaan in hoeverre de gebruikers de structuur van de toepassing (zoals uitgedacht en

beschreven m.b.v. storyboard en scherm-transitie diagram) begrepen en deze konden gebruiken om de diensten die onze toepassing aanbiedt te benutten. Een papieren prototype was hiervoor geschikt.

i Opmerking: het zou uiteraard logisch zijn de kans op slagen van het idee te onderzoeken voor het creëren van een

storyboard en scherm-transitie diagram. Deze waren echter een verplicht onderdeel van de opdracht op het moment dat we ons idee uitwerkten. De verschillende onderzoeken worden hier dan ook chronologisch toegelicht.

CHI 2009-2010 5/17

2.2 IMPLEMENTATIE A- STORYBOARD EN SCHERM-TRANSITIE DIAGRAM

Beide werden op papier uitgetekend en gedigitaliseerd met Adobe Photoshop. Van een echte implementatie kunnen we hier niet spreken. Er werd reeds verwezen naar de desbetreffende figuren.

B- KANS OP SLAGEN VAN HET CONCEPT Doordat gebruik gemaakt werd van een vragenlijst en papers op papier kan ook hier niet van implementatie

gesproken worden.

C- WERKEN MET DE APPLICATIE Een papieren prototype werd geknutseld. Foto's van dit papieren prototype kunnen teruggevonden worden in de

Bijlage (Figuur 3 - 8) van verslag 1.

2.3 EVALUATIE: AANPAK EN DOEL A- STORYBOARD EN SCHERM-TRANSITIE DIAGRAM

Het storyboard en scherm-transitie diagram werden niet gebruikt voor een evaluatie. Deze zullen dan ook niet verder besproken worden.

B- KANS OP SLAGEN VAN HET CONCEPT Zoals reeds vermeld werd voor dit onderdeel een vragenlijst opgesteld. We wilden te weten komen hoe onderzoek-

ers papers lezen en of ze reeds aantekeningen of markeringen gebruiken. Daarnaast wilden we ook hun mening over onze applicatie te weten komen na uitleg uitleg van het concept. Concreet resulteerde dit in de volgende vragen:

Reeks A • Hoeveel papers leest u per week? • Leest u papers op papier, via de computer, beide, ...? • Duidt u zaken aan in de papers die u leest? • Zo ja: doet u dit door aantekeningen te plaatsen, belangrijke zaken aan te duiden, beide, ...? • Maakt u samenvattingen van gelezen papers? Reeks B • Lijkt het u nuttig om papers te lezen die anderen gemarkeerd hebben? • Zou u dan het liefst markeringen zien van uw collega's of alle mensen die de paper reeds lazen? • Zou u de applicatie zelf gebruiken? Waarom wel/niet ? • Zou u het nuttig vinden om commentaar bij papers te zetten? • Zou u het nuttig vinden symbolen bij stukken uit papers te kunnen zetten? • Zou u het nuttig vinden stukken tekst uit papers te linken aan andere papers? Naast deze vragenlijst werd ook, zoals reeds aangegeven, gebruikers gevraagd een paper te lezen en de belan-

grijkste stukken te markeren. Dit om achteraf te kunnen kijken of bepaalde stukken meermaals als 'belangrijk' beschouwd werden.

Opdracht A • Lees een paper en markeer de belangrijkste onderdelen.

Uiteraard verwachtten we dat gebruikers interesse tonen in de applicatie en dat ze deze zelf zouden willen ge-bruiken. We verwachtten langs de andere kant dat gebruikers verkiezen papers te lezen op papier.

C- WERKEN MET DE APPLICATIE Met het papieren prototype willen we onderzoeken of gebruikers taken, die uitgevoerd dienen te worden met de

toepassing, vlot konden uitvoeren. We geven hiervoor gebruikers bepaalde opdrachten en vragen ze, tijdens de uitvo-ering hiervan, luidop te zeggen wat ze denken.

Concreet waren de opdrachten: Opdrachten B • Zoek een paper van E. Duval en markeer hier willekeurig enkele zinnen in. • (Vanaf het eindpunt van 1.) Zoek een andere paper van E. Duval. • (Vanaf het eindpunt van 1.) Open de paper die gemarkeerd werd in 1.

Uiteraard verwachtten we dat het voor gebruikers duidelijk is hoe de opdrachten uit te voeren. In deze iteratie werden geen specifieke metingen (aantal clicks, tijd nodig, ...) gemeten.

CHI 2009-2010 6/17

2.4 EVALUATIE: VERLOOP B- KANS OP SLAGEN VAN HET CONCEPT & C- WERKEN MET DE APPLICATIE

Deze twee onderdelen werden gelijk geëvalueerd. Paragraaf 4. Papieren prototype uit verslag 1 beschrijft het verloop. De proefpersonen waren onderzoekers van het departement Computerwetenschappen.

Concreet werd gestart met de vragen uit reeks A (zie hierboven 2.3). Vervolgens werd gevraagd opdrachten A uit te voeren, daarna werden de vragen uit reeks B gesteld en tot slot moest opdracht B uitgevoerd worden. Deze volgorde wordt ook hieronder gehanteerd bij de bespreking van de resultaten.

2.5 EVALUATIE: RESULTATEN (1 BLZ) RESULTATEN

Vier proefpersonen werden getest. Omdat de antwoorden geen strikte vorm bevatten wordt direct een conclusie gegeven:

Reeks A • Hoeveel papers leest u per week? • Leest u papers op papier, via de computer, beide, ...? • Duidt u zaken aan in de papers die u leest? • Zo ja: doet u dit door aantekeningen te plaatsen, belangrijke zaken aan te duiden, beide, ...? • Maakt u samenvattingen van gelezen papers?

• Gemiddeld 1-4 papers per week. • De meeste proefpersonen lazen papers op de computer en drukte deze af om markeringen of notities toe te

voegen. • Sommigen deden dit, anderen niet • Diegenen die dit deden deden dit allen voor te markeren. Sommigen hiervan voegden ook aantekeningen toe • Niemand deed dit

Opdrachten A Zie hiervoor de tweede alinea van de subparagraaf Conclusies uit de evaluatie van paragraaf 4. Papieren prototype uit ver-

slag 1. Reeks B • Lijkt het u nuttig om papers te lezen die anderen gemarkeerd hebben? • Zou u dan het liefst markeringen zien van uw collega's of alle mensen die de paper reeds lazen? • Zou u de applicatie zelf gebruiken? Waarom wel/niet ? • Zou u het nuttig vinden om commentaar bij papers te zetten? • Zou u het nuttig vinden symbolen bij stukken uit papers te kunnen zetten? • Zou u het nuttig vinden stukken tekst uit papers te linken aan andere papers?

• Hierop werd positief gereageerd. • Onderzoekers zouden iets meer belang hechten aan de markeringen van mensen uit hun onderzoeksgroep. • Zeker, maar de applicatie mag geen vertraging opleveren t.o.v. applicaties die nu gebruikt worden (Acrobat

Reader, Voorvertoning). • Het merendeel zou dit willen. • Slechts enkelen zouden dit nuttig vinden. • Dit zag bijna niemand echt als nuttig.

Opdracht B Zie hiervoor de voorlaatste alinea van subparagraaf Conclusies uit de evaluatie van paragraaf 4. Papieren proto-

type uit verslag 1.

CONCLUSIES Conclusies worden besproken in de subparagraaf Conclusies uit de evaluatie van paragraaf 4. Papieren proto-

type uit verslag 1. Het verloop van het onderzoek werd in de vorige alinea van dit verslag nog eens besproken voor een duidelijk verband tussen de testen en de resultaten. In de subparagraaf Conclusies uit de evaluatie van paragraaf 4. Pa-pieren prototype uit verslag 1 worden de conclusies gegeven volgens eenzelfde structuur:

conclusies reeks A

CHI 2009-2010 7/17

conclusies opdrachten A conclusies reeks B conclusies opdracht B

Samengevat concluderen we dat de applicatie zeker een bestaansreden heeft, dat er geen behoefte is om samenvattin-gen te schrijven over papers. Ook is het belangrijk dat papers die gelezen zijn bijgehouden moeten worden. Verder zien we dat de knop ‘My Papers’ niet duidelijk genoeg weergeeft dat het over de reeds gelezen papers gaat en dat de methode om te markeren duidelijker aangegeven dient te worden. Ook concluderen we da het pad naar het lezen van een bepaalde paper zo kort mogelijk moet zijn en dat gebruikers geen vertraging willen ondervinden ten opzichte van hun huidige toepassing. We zagen ook dat een groot aantal kernwoorden door alle onderzoekers werd aangeduid.

CHI 2009-2010 8/17

3. ITERATIE II

3.1 AANPAK In deze iteratie hebben we enerzijds ons papieren prototype omgezet in een Flash prototype met behulp van Flair-

builder Fout!Verwijzingsbron niet gevonden. en hiermee een aantal testen gedaan. Anderzijds hebben we een aantal testen gedaan om verschillende alternatieven te vergelijken om markeringen te maken in teksten.

A- FLASH PROTOTYPE Zoals al te lezen was in paragraaf 2.1 van ons tweede verslag zijn we van ons papieren prototype overgegaan op een

Flash prototype omdat we ons op meer kwantificeerbare tijden wilden baseren. Dit was belangrijk omdat we wilden nagaan of een aantal concrete doelen in de applicatie konden bereikt worden binnen opgelegde tijdslimieten. We von-den het belangrijk om binnen deze tijdslimieten te blijven omdat we tijdens onze eerste iteratie van een aantal onder-zoekers te horen hadden gekregen dat ze de applicatie zouden gebruiken als deze zou passen in hun dagelijkse workflow. Waarmee ze bedoelden dat het belangrijk was dat onze toepassing niet meer tijd zou vragen om bvb. markeringen te doen dan de methode (bvb. markeren in Acrobat Reader, of met papier en markeerstift) die ze op dat moment gebruikten. De testen zelf en de concrete tijdslimieten worden beschreven in paragraaf 3.3. Een demo-video van ons Flash prototype vanuit het standpunt van een virtuele researcher is ook beschikbaar op onze blog [2].

B- ALTERNATIEVEN OM MARKERINGEN TE MAKEN Omdat markeringen maken één van de hoofddoelen is van onze applicatie is het belangrijk dat deze functionaliteit

gemakkelijk te gebruiken is. Daarom hebben we een aantal mechanismen vergeleken die markeren mogelijk maken. De concrete testen en details hiervan zijn te lezen in ons tweede verslag en in paragraaf 3.4 van dit verslag.

3.2 IMPLEMENTATIE Om de implementatie van ons Flash prototype te doen hebben we gekozen om met Flairbuilder te werken. Het

voordeel van deze tool ten opzichte van powerpoint, HTML/CSS en anderen is dat er bij deze tool standaard compo-nenten aanwezig zijn zoals buttons, tabellen, menu's, enz.. Er was ook een bibliotheek van iPhone componenten aan-wezig. Dit bood ons de mogelijkheid om deze look and feel ook in ons prototype aan te brengen, niet onbelangrijk aangezien we onze (eventuele) uiteindelijke applicatie voor een iPad wilden ontwikkelen. Met deze tool hoeft er ook geen letter code geschreven te worden, de implementatie gebeurt puur visueel. Dit leverde ons snel een handig en bruikbaar prototype op.

Het schermtransitiediagram (zie ook paragraaf 2.1 van ons tweede verslag) is in deze iteratie hetzelfde gebleven als bij het papieren prototype. Hierdoor is het Flash prototype dus een identieke maar virtuele versie van het papieren proto-type. Enkel hebben we hierin de naam van de knop "My Papers" aangepast naar "My History" zoals ook te lezen was in ons tweede verslag.

De functionaliteit om zelf markeringen aan te brengen was niet in dit prototype aanwezig omdat we hier nog een aantal testen voor wouden doen (zoals beschreven in paragraaf 3.1 van dit verslag was dit het tweede luik van deze iteratie). De verdere details van de implementatie (en screenshots) zijn te vinden in het tweede verslag.

3.3 EVALUATIE: AANPAK EN DOEL Zoals beschreven in paragraaf 3.1 van dit verslag zijn we hier tweeledig te werk gegaan:

A- FLASH PROTOTYPE Met het Flash prototype hebben we testen uitgevoerd om te weten te komen hoe onze applicatie zich verhoudt tot

andere applicaties die een gelijkaardige functionaliteit (markeringen in teksten maken) aanbieden. We wilden nagaan hoeveel tijd het vroeg van de gebruikers om deze functionaliteit te gebruiken. Concreet hebben we ons prototype ver-geleken met Adobe Acrobat Reader (PC) en Voorvertoning (Mac).

We ontwikkelden hiervoor volgende test: we vroegen de gebruikers om de functionaliteit om te kunnen markeren te activeren in Acrobat Reader, Voorvertoning en ons Flash prototype. We namen dan de tijd op vanaf het moment dat de gebruikers de paper geopend zagen in elk van de applicaties.

Onze hoop was dat onze applicatie hierbij beter of minstens even goed scoorde als de andere applicaties. Concreet schatten we dat deze taak in 5 seconden kon uitgevoerd worden in onze applicatie en dat dit bij de andere applicaties minstens 30 seconden zou duren.

B- ALTERNATIEVEN OM MARKERINGEN TE MAKEN Met deze testen wilden we te weten komen welk het beste mechanisme was om markeringen in een tekst aan te

CHI 2009-2010 9/17

brengen. Om dit na te gaan vergeleken we 5 mechanismen: selecteren met een muis op een PC, selecteren op een touchpad op een MacBook, markeren met papier en markeerstift, selecteren op een iPhone en markeren met de Aji Annotate applicatie [4]. Deze laatste is een applicatie die we gevonden hebben voor op de iPhone die ook toelaat om markeringen te maken in teksten (het markeringsprincipe is hierbij anders dan het standaard selecteren op een iPhone zoals beschreven in paragraaf 2.3 van het tweede verslag).

Concreet ontwikkelden we volgende test: we vroegen de testpersoon om in dezelfde paper eenzelfde stukje tekst te selecteren volgens de 5 verschillende methodes. We maten hierbij telkens de tijd op en vroegen de gebruiker ook welke techniek het meest praktisch in gebruik vonden. Omdat niet iedereen gewoon is om met een iPhone te werken vroegen we de gebruiker om de test hier vijf keer op uit te voeren. Om zo de invloed van het leerproces op de resultaten te verkleinen. (Verdere details over de test zijn te vinden in paragraaf 2.3 van ons tweede verslag.)

We hoopten bij deze test dat de methodes op een touch-device beter zouden scoren dan de andere. Concreet ver-wacthtten we dat de tijd nodig voor het selecteren maximaal 2 seconden zou bedragen bij elk van de technieken. We verwachtten ook dat de touch-technieken geen merkbare vertraging zouden opleveren tenzij misschien bij het eerste gebruik ervan.

3.4 EVALUATIE: VERLOOP Bij de testen in deze tweede iteratie waren de testpersonen 3 van onze medestudenten uit een ander CHI-team. Het

leek ons bij deze fase van de evaluatie niet cruciaal belangrijk dat de testpersonen onderzoekers waren. Achteraf gez-ien was dit misschien een foute inschatting, want zoals Joannes Vandermeulen van Namahn in de laatste sessie op-merkte kunnen de testen beter op de specifieke doelgroep gedaan worden om juiste resultaten te bekomen.

Wat we de testpersonen vroegen om te doen staat beschreven in paragraaf 3.3 hierboven en verder in detail in para-graaf 2.4 van het tweede verslag.

Er zijn bij deze testen ook geen noemenswaardige problemen opgetreden.

3.5 EVALUATIE: RESULTATEN We konden hieruit besluiten dat de markeer standaard functionaliteit van de iPhone goed genoeg is om markerin-

gen mee te doen en om een markeer applicatie mee te maken. De resultaten van hiervan worden hieronder weer-gegeven.

Tijd tot aan de markeer functie Onze Applicatie Voorvertoning Acrobat Gebruiker 1 10.5 35 60+ Gebruiker 2 11 32 60+ Gebruiker 3 15 34 60+ Gemiddelde 12.13 33.7 60+

Bij standaard pdf applicaties werd de markeer functionaliteit heel moeilijk gevonden (als ze al werd gevonden).

Tijd om tekst te selec-teren Muis TouchPad Papier (mark-

eren) Iphone standaard selec-tie tool

Iphone Aji Annotate applicatie

Gebruiker 1 3 4 11 4.3 30 Gebruiker 2 2 3.4 9 6 26.1 Gebruiker 3 2.3 3.5 12.2 5.5 29 Gemiddelde 2.4 3.63 10.73 5.267 28.3

CHI 2009-2010 10/17

4. ITERATIE III

4.1 AANPAK Als derde iteratie hebben we nagegaan hoe we de markeringen van de community het best zouden weer-

geven. Als criterium voor "beste manier van weergeven" veronderstelde we dat de weergave waarbij de testper-sonen het meest van een paper onthielden (na hem vluchtig overlopen te hebben), de beste was. Het oorspronke-lijke doel van de applicatie is immers onderzoekers sneller de informatie in een paper laten vatten. Hiervoor hebben we twee manieren van visualisatie geëvalueerd. Met een korte vragenlijst over de inhoud van de paper trachtten we dan na te gaan hoeveel de testpersoon van de paper opgestoken had. Hoe we dit concreet hebben aangepakt beschrijven we in de volgende paragrafen (paragrafen 4.2 t.e.m. 4.5).

4.2 IMPLEMENTATIE Deze test werd gebouwd met php, html, css en javascript. Een eerste pagina geeft een korte uitleg over de test

en bevat een grote start-knop. Afbeelding 4 toont dit scherm. Bij klikken op de startknop wordt de gebruiker doorverbonden met een pagina die een gemarkeerde paper geeft.

Op een willekeurige manier wordt de gebruiker doorverbonden met ofwel een paper gemarkeerd met gele

markeringen, ofwel met een gradient van verschillende tinten (hoe donkerder hoe meer belangrijk).

Afbeelding 5 geeft een vergelijking van deze twee soorten markering. Daarnaast wordt ook een timer weergegeven

die aanduidt hoelang de gebruiker nog heeft om deze tekst te lezen. Deze werd gemaakt met behulp van de jQuery javascript library. De keuze van welke markering zichtbaar is wordt onthouden en de gebruiker wordt bij aflopen van de timer doorverbonden met een formulier. Deze werden gecreëerd met behulp van Google Docs.

Verder willen we vermelden dat er, buiten de gebruikte soorten markering, ook nog andere types onderzocht zijn.

Afbeelding 4

Afbeelding 5

CHI 2009-2010 11/17

Deze hebben we uiteindelijk verworpen: • Afbeelding 6: links

o Niet makkelijk om woorden/zinnen te laten opvallen. Nogal druk om efficiënt te kunnen lezen. • Afbeelding 6: rechts

o Omdat bij dit principe volledige regels gekleurd zijn is de granulariteit te groot. Ook kunnen belang-rijke zinnen over meerdere regels verspreid zijn en moet de gebruiker dan zelf gaan zoeken.

4.3 EVALUATIE: AANPAK EN DOEL Om de beste visualisatie techniek te vinden, hebben we eerst zitten experimenteren met verschillende visualisatie

technieken. Dit deden we door de "markeer data" van verschillende personen als layers boven elkaar te zetten in Adobe Photoshop en daar verschillende effecten op toe te passen (andere kleuren, transparantie, …).

Na een aantal dingen te hebben geprobeerd, vonden we de volgende markeringen het interessantste om te testen. • Geel gradiënt: hoe donkerder geel de zin is, hoe vaker hij is aangeduid. (zie onderaan afbeelding 5) • Gewone markeringen: enkele laag van markeringen (zie bovenaan afbeelding 5)

We wilden dan 2 zaken over de markeringen te weten komen, nl.: • Is het visueel duidelijk, aantrekkelijk? • Helpen de markeringen ook bij het onthouden van de kernzaken van de tekst, is de gebruiker iets met de

markeringen? Na een brainstorm sessie, hebben we dan besloten dat de beste manier om veel bruikbare informatie te krijgen, via

een webtest is. Hierbij krijgt de gebruiker de markeringen 25 seconden te zien en moet daarna een vragenlijst invullen (zie ook 4.2 implementatie). We hebben de vragen ontworpen om de vorige twee vragen te kunnen beantwoorden en om een idee te krijgen van onze test groep, nl.:

• Wat is uw leeftijd? • Wat is uw beroep? • Vond u de markeringen duidelijk? • Was het systeem dat achter de markeringen zat meteen duidelijk? • Wat was het beroep van Bas Bogaert en Eva Schampaert? • Hoe heet het luisterboek dat Bas en Eva hebben uitgebracht? • Waarnaar gingen Bas en Eva op zoek na hun lange reis? • Wat is de link die Bas en Eva uiteindelijk gevonden hebben? • Wat betekent het Latijnse woord "ninare" in het Nederlands? • Vonden Bas en Eva ook muzikale overeenkomsten? • Wie heeft Sarah Bettens een Spaans slaapliedje laten inzingen?

Achteraf gezien hadden we deze vragen toch nog beter kunnen ontwerpen. Bij de eerste twee vragen moeten we ons afvragen of we op deze manier voldoende weten van onze testpersonen. Zoals Joannes Vandermeulen van Namahn terecht opmerkte in de laatste sessie, mag je nooit zomaar testen doen op "een" testpubliek. Men moet steeds een specifieke testgroep gebruiken waarbij men goed op de hoogte is van de eigenschappen van de testpersonen. Vraag 3 en 4 zijn ook geen goede manier om te weten te komen of de markeringen goed zijn.

De verspreiding van de website hebben gedaan via sociale media zoals facebook en twitter als op meer traditionele

manieren zoals email of msn aan vrienden vragen. Onze verwachting was dat de 2de soort markeringen het hoogste zouden scoren (deze met de oranje highlights)

Afbeelding 6

CHI 2009-2010 12/17

omdat daarbij de belangrijkste informatie nog eens extra duidelijk is aangeduid.

4.4 EVALUATIE: VERLOOP Zoals vermeld in vorige paragraaf hebben we een link naar onze test gepost op twitter en andere fora (o.a. ook ti-

jdens onze presentatie in de les) en een willekeurige groep testpersonen deze laten invullen. Zoals reeds aangehaald kregen deze gebruikers een tekst verrijkt aan de hand van twee verschillende visuele voorstellingen van markeringen die door een reeks andere gebruikers , ze kregen een vragenlijst (zie §4.3) omtrent een artikel. De vragen trachtten te polsen naar hoe goed ze zich enkele belangrijke elementen uit de tekst konden herinneren.

Om de gemengde groep testpersonen toch ietwat te kunnen identificeren hebben we in enquête (zie vragenlijst

hierboven) enkele vragen over de achtergrond van de persoon gesteld. Op zich hadden we niet echt problemen tijdens het testen. Wel deden er veel minder testpersonen mee dan verwacht. Dit maakt het moeilijk om conclusies te trekken uit de resultaten. Bovendien in de resultaten van de bevraging die we dan wel hebben, zijn de verschillen tussen beide visualisaties nauwelijks merkbaar. We sluiten niet uit dat de tijd om de tekst met highlights te bekijken simpelweg te kort gekozen was. Echter gezien de beperkte tijd die ons nog restte en de weinige opkomst voor de vorige test (ong. X testen op meer dan een week tijd) hebben we dit niet meer overgedaan. We hadden nooit de veronderstelling mogen maken dat we gemakkelijk proefpersonen konden vinden die snel even 5 minuten tijd willen maken om een enquête in te vullen.

4.5 EVALUATIE: RESULTATEN In onderstaande tabel worden de resultaten weergeven van de gebruikers voor beide bevragingen.

Afbeelding 7 geeft de resultaten voor gewone aanduidingen. Afbeelding 8 deze voor de aanduidingen met gradiënt. Toevallig (gebruiken werden willekeurig doorverbonden) blijken er meer resultaten te zijn voor de gewone aandui-

dingen dan voor deze met gradient.

Afbeelding 7

CHI 2009-2010 13/17

Wat direct opvalt is dat er niet echt een duidelijk lijn te trekken is uit deze resultaten. Zowel voor het geval van het

weergeven van een gradiënt als het geval van enkel de belangrijkste markeringen tonen. De waarnemingen wijken heel sterk af van de gestelde doelen, we kunnen dus niet echt een conclusie trekken louter op basis van deze vragenli-jsten.

Bovendien geven enkele gebruikers aan dat hun niet meteen duidelijk is wat het systeem achter de markeringen is (lees: waarom iets gemarkeerd is of niet, laat staan waarom iets in een donkerdere tint gemarkeerd is). We zullen de visualisaties op een andere manier moeten evalueren, zoals merkbaar uit de resultaten is het niet evident om te achter-halen of een bepaalde soort markering het onthouden beïnvloedt. Het lijkt daarentegen dan interessanter om te proberen nagaan welke soort markeringen, puur op uitzicht, een hiërarchie van belangrijkheid beter zichtbaar maken. Uiteraard zonder dat gebruiker in de war raakt en de tekst een soort kleurmap wordt zonder betekenis.

Een goede oplossing hiervoor is, en dit is meteen een belangrijke conclusie, bij de markeringen een legende voorzien worden die aangeeft wanneer en dus ook waarom iets gemarkeerd wordt of niet. Zo wordt voor de gebruiker het sys-teem achter de getinte zones meteen duidelijk.

Bijvoorbeeld: Naar gelang het percentage van de gebruikers dat een stuk tekst heeft gemarkeerd. 'Van de gebruik-ers' zijn dan alle gebruikers die het artikel gelezen hebben en ergens in de tekst iets voor hen interessant gemarkeerd hebben.

gemarkeerd >50% geen <50% rood >75% oranje 75 - 50% geel 50 - 25% geen <25%

Deze onderverdeling kan dan worden weergegeven als een soort graadmeter bij elk document eventueel waarbij

aangegeven wordt hoeveel gebruikers nu die 100% uitmaakt: "Zijn dat er 10 of 10000?". Om duidelijk te maken aan de lezer hoe relevant of betrouwbaar markeringen effectief zijn. Dit hebben we echter nog niet nagegaan. Het is dus zeker nodig om te verifiëren bij wetenschappers of dit enig verschil maakt. Dit is een aspect dat we dus niet testen kunnen met een enquête die voor iedereen toegankelijk is.

Onderstaande tekst met markeringen is daarvan een goede illustratie. Hierbij valt rechts de graadmeter op met een legende getiteld: "insight", die aangeeft in hoeveel exemplaren (copies) een bepaald stuk tekst gemarkeerd is.

Dit is een afbeelding afkomstig uit een andere context. Voor onze applicatie zouden i.p.v "insight" beter "high-lighted (by)" en i.p.v. copies "users" als termen worden gekozen.

Afbeelding 8

Afbeelding 9

CHI 2009-2010 14/17

5. VERGELIJKING MET ANDERE APPLICATIES

5.1 MENDELEY Om te beginnen merken we op dat Mendeley een volledig uitgebouwd systeem is met verschillende function-

aliteiten die kunnen verschillen naargelang het profiel van de gebruiker. Dit is meteen een belangrijk verschil met onze applicatie. Bij RichPapers is het doel heel rechtlijnig: het lezen van papers beter integreren in de workflow van de wetenschapper en de paper verrijken door belangrijke punten die de community heeft aangeduid te visualiseren. Wij houden dus niet echt een profiel bij van gebruikers, enkel een history met geopende, gemarkeerde en favoriete papers zodat ze hun weg makkelijk kunnen terugvinden.

Mendeley wil papers aanbevelen en op die manier ook eventueel wetenschappers met elkaar in contact brengen. Dit is bij RichPapers helemaal niet de bedoeling. De meerwaarde voor de gebruikers om te markeren is simpelweg het ei-gen voordeel: sneller de belangrijkste zaken terugvinden en onthouden. Dit veroorzaakt tevens dat ze de markeringen van andere zullen zien. In onze applicatie is het dus ook niet nodig om papers te uploaden, er wordt gewerkt met een extra visualisatielaag bovenop de bestaande papers die uit een of andere databank komen. Welke informatiebron is niet relevant voor het concept van RichPapers. Terwijl dit voor Mendeley net een rol speelt: "Wie heeft die paper ge-upload?"

5.2 AJI ANNOTATE VOOR IPHONE Toen we research gingen doen naar bestaande applicaties waarbij we markeringen konden maken op touch devices,

kwamen we Aji Annotate [4] tegen. Deze zorgt voor annotatie functionaliteit voor pdf-documenten op de iPhone. We hebben echter ondervonden dat er weinig is nagedacht over de gebruikersinterface van deze applicatie. Om iets te kunnen markeren moet men eerst de "highlight"-functionaliteit uit een onhandig menu selecteren:

Daarna kan men iets markeren, het markeren gebeurt echter meteen als men de tekst aanraakt zonder enige vorm

van bevestiging. Het resultaat is dat je met je vinger teveel of te weinig selecteerd en telkens opnieuw moet beginnen.

Afbeelding 00

CHI 2009-2010 15/17

6. BEDENKINGEN EN FEEDBACK UIT DE LAATSTE SESSIE In de laatste sessie hebben we slechts enkele opmerkingen gekregen op de toenmalige stand van zaken van ons pro-

ject. Deze kwamen er op neer dat we niet expliciet vermeld hadden dat het community aspect door die meerdere mogelijk markeringen een rol speelden. Maar dit volgt eigenlijk impliciet uit het concept en dient niet expliciet ver-meld te worden. Op zich is dat ook niet het hoofddoel, zoals we reeds vaak hebben aangehaald gaat het om de papers verrijken om ze dus sneller en beter te kunnen lezen.

Verder hebben we uit de laatste sessie nog een aantal zaken opgestoken van de mensen van Namahn. Zo leek ons

de techniek om met personna's te werken (een fictieve typische gebruiker van de applicatie met goed gedefinieerde eigenschappen) een goede techniek om jezelf als ontwerper beter in te kunnen leven in de gebruikersgroep waar je voor ontwikkelt. Deze techniek kan er ook voor zorgen dat alle ontwerpers in één team dezelfde gebruiker voor ogen hebben, zodanig dat de communicatie tussen de teamleden vlotter kan verlopen. Een bruikbare methode dus, die we zeker nog gaan toepassen wanneer we gebruikersinterfaces moeten ontwikkelen.

Verder leerden we ook nog dat de testen op gebruikers gerust wat creatiever mogen aangepakt worden dan puur vragen stellen en de gebruiker observeren terwijl hij met een mockup werkt. Zo leek ons bvb. het werken met puzzelstukken om een gebruiker zijn typisch gebruiksscenario te laten samenleggen een leuk idee.

CHI 2009-2010 16/17

7. BESLUIT Zoals benadrukt werd bij aanvang van de cursus, lag de focus tijdens deze opdracht op het 'zich in de plaats van de

gebruiker stellen'. Dit was voor ons nieuw. Met elke nieuwe iteratie van de opdracht kreeg dit begrip steeds meer een concretere invulling. We hebben gemerkt dat zelfs een eenvoudig en sterk afgelijnd concept voor een toepassing aan-leiding geeft tot heel wat moeilijke keuzes. Zelfs nu na een derde iteratie hebben we nog enkele belangrijke vragen om-trent de precieze visualisatie van de verschillende markeringen. Dit neemt niet weg dat we dankzij de input van de testgebruikers, voornamelijk wetenschappers en toekomstige wetenschappers (studenten), toch heel wat vragen en bedenkingen bij ons initieel concept hebben kunnen oplossen.

De verschillende storyboards die we hebben gemaakt vooral in iteratie 1 en 2 hebben heel goed geholpen om aan

ons eerder abstract idee van "het lezen van papers te verbeteren door markeringen van andere gebruikers te laten zien" te realiseren. Het dwong ons om heel concreet na te denken hoe onze applicatie in de workflow van wetenschappers kan passen. Dit belette ons ook dat de concrete invulling van onze applicatie een reeks features zou worden.

Na de storyboards hebben we dan een praktische implementatie gemaakt aan de hand van een papieren prototype

en een flash prototype. Hier konden wij onze keuze voor het tablet platform (o.a.) het formaat echt laten 'voelen' aan de testgebruikers. We hebben echter de verschillende aspecten van onze applicatie moeten testen op een niet geïnte-greerde manier. Dit kwam wegens het feit dat de iPad nog niet beschikbaar was toen en we bovendien nog in een te vroege fase waren om echt al een volledige applicatie te ontwikkelen.

In plaats daarvan hebben we het workflow aspect laten testen via een webapplicatie gebouwd in Flash. Het mark-

eren hebben we getest op een iPhone en vergeleken met de gewone markeerstift en met de muis op een gewone pc. Ons papieren prototype diende om het tablet concept en formaat te kunnen nagaan bij de gebruikers. De betere visu-alisatiemethode voor de highlights zelf hebben we geprobeerd via een bevraging aan een grote groep gebruikers te achterhalen.

We blijven bij ons besluit dat het maken van markeringen met behulp van een touch-toestel zeker een meerwaarde

brengt voor de wetenschapper. Uit de testen die we hebben uitgevoerd gedurende de hele opdracht bleek dat het ge-bruik van deze techniek geen noemenswaardige vertraging met zich meebrengt. �Hoewel we in de allerlaatste iteratie nog geen definitief uitsluitsel hebben over een keuze voor een visualisatie, hebben we toch al min of meer een bepaalde richting. Met nog een korte goed doordachte bevraging van onze laatste voorgestelde visualisatie bij een kleine groep wetenschappers kunnen we nu snel tot een conclusie komen. We hadden al langer bevestiging van onze uitvoering van het concept en de inpassing in de workflow.

CHI 2009-2010 17/17

References [1] LEE, C. How to read papers fast. http://voh.chem.ucla.edu/vohtar/fall99/258/read.html, 1999 [2] http://guijoe.wordpress.com [3] http://www.flairbuilder.com [4] Aji Annotate, http://www.jbrink.net/annotater/

APPENDIX Peter De Roovere Jan Grauwels Laurens De Vocht Joris Van den Broeck Totaal

Bespreking aanpak 4 4 4 4 16

Implementatie 4 2 0 3 9 Evaluatie: verloop 1 1 1 1 4 Evaluatie: analyse resultaten 3 3 3 3 12

Demo Video maken 0 3 0 0 3 Verslag schrijven 13 10 9 10 42 Totaal 25 23 17 21 86