Transaction / Regular Paper Title
CHI 2009-201016/17
CHI 2009-201017/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 applicatie
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 gebruikers 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
worden 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 onderdelen bijna steeds
terugkeerden als zijnde belangrijk in papers. Verdere ontwikkeling
van de applicatie is dus gerechtvaardigd. 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 papieren 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.
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 markeren 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 belangrijke 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.
2 Iteratie I
2.1 Aanpak
Deze iteratie vormt het begin van het ontwikkelingsproces van
onze applicatie. We gingen van start met een brainstorm-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 gelijkaardige 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 alternatieve 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 paragraaf 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 veronderstelden 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 opmerking 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 concept
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.
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 onderzoekers 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 belangrijkste 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 gebruiken. 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 uitvoering 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.
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 verslag
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
prototype uit verslag 1.
Conclusies
Conclusies worden besproken in de subparagraaf Conclusies
uit de evaluatie van paragraaf 4. Papieren
prototype 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. Papieren
prototype uit verslag 1 worden de conclusies gegeven
volgens eenzelfde structuur:
conclusies reeks A
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 samenvattingen 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.
3. Iteratie II
3.1 Aanpak
In deze iteratie hebben we enerzijds ons papieren prototype
omgezet in een Flash prototype met behulp van
Flairbuilder 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 vonden het belangrijk om binnen
deze tijdslimieten te blijven omdat we tijdens onze eerste iteratie
van een aantal onderzoekers 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 componenten aanwezig zijn zoals buttons, tabellen,
menu's, enz.. Er was ook een bibliotheek van iPhone componenten
aanwezig. 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 prototype. 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 vergeleken 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 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 verwacthtten 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 gezien was dit misschien
een foute inschatting, want zoals Joannes Vandermeulen van Namahn
in de laatste sessie opmerkte 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 paragraaf 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 markeringen mee te
doen en om een markeer applicatie mee te maken. De resultaten van
hiervan worden hieronder weergegeven.
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 selecteren
Muis
TouchPad
Papier (markeren)
Iphone standaard selectie 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
4. Iteratie III
4.1 Aanpak
Als derde iteratie hebben we nagegaan hoe we de markeringen van
de community het best zouden weergeven. Als criterium voor "beste
manier van weergeven" veronderstelde we dat de weergave waarbij de
testpersonen het meest van een paper onthielden (na hem vluchtig
overlopen te hebben), de beste was. Het oorspronkelijke 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. Deze hebben we
uiteindelijk verworpen:
· Afbeelding 6: links
· Niet makkelijk om woorden/zinnen te laten opvallen. Nogal druk
om efficiënt te kunnen lezen.
· Afbeelding 6: rechts
· Omdat bij dit principe volledige regels gekleurd zijn is de
granulariteit te groot. Ook kunnen belangrijke 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) 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 tijdens 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 aanduidingen dan voor
deze met gradient.
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 vragenlijsten.
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 achterhalen 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 systeem achter de getinte
zones meteen duidelijk.
Bijvoorbeeld: Naar gelang het percentage van de gebruikers dat
een stuk tekst heeft gemarkeerd. 'Van de gebruikers' 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 "highlighted (by)" en
i.p.v. copies "users" als termen worden gekozen.
5. Vergelijking met andere applicaties
5.1 Mendeley
Om te beginnen merken we op dat Mendeley een volledig uitgebouwd
systeem is met verschillende functionaliteiten 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 eigen 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 geupload?"
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.
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 project. 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 vermeld 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.
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 aanleiding geeft tot heel wat moeilijke keuzes.
Zelfs nu na een derde iteratie hebben we nog enkele belangrijke
vragen omtrent 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ïntegreerde 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 markeren 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
visualisatiemethode 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 gebruik 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.
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
Afbeelding 1
Afbeelding 2
Afbeelding 3
Afbeelding 4
Afbeelding 5
Afbeelding 6
Afbeelding 7
Afbeelding 8
Afbeelding 9
Afbeelding � SEQ Afbeelding \* ARABIC �0�0
� 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.
