Speciale juli 2010

Et kongeligt eksperiment

Usability test og IR evaluering for Det Kongelige Bibliotekaf søgesystemet REX/Primo

Aninja Helene GrønJessica Blanca Johansen

Vejleder: Peter Ingwersen

København, 1. juli 2010Royal School of Library and Information Science

Antal ord: 37152

To arrive at the perfect interface, one also needs genius,a stroke of inspiration, and plain old luck.

Jakob Nielsen, april 1994

Kolofon(Angivet i Dublin Core)

Title: Et kongeligt eksperiment - Usability test og IR evaluering for Det Kongelige Bibliotek af søgesystemet REX/PrimoTitle in English: A Royal experiment - Usability test and IR evaluation for the Royal Danish Library of their search system REX/PrimoSubject: Usability test and IR evaluation of the Royal Danish Library’s search system, REX/Primo.Keywords: IR, IIR, HCI, Usability Engineering, Royal Danish LibraryDescription: Please read the English abstract.Resource type: Text, Graduate Thesis

Creators: Grøn, Aninja Helene. Johansen, Jessica Blanca.Publisher: Royal School of Library and Information ScienceRights management: Creative Commons by-nc-ndDate: 1st of July 2010Format: A4, 157 pages, 8,92 MbLanguage: Danish, with English abstractRights holders: Grøn, Aninja Helene. Johansen, Jessica Blanca.

Creative Commons: You are free to share, copy, distribute and transmit the work.Under the following conditions:Attribution – You must mention both authors when citing or quoting.Noncommercial – You may not use this work for commercial purposes (except for improving library OPACs).No Derivative Works – You may not alter or transform this work.

2

ABSTRACT IN ENGLISH

Title in English: A Royal experiment - Usability test and IR evaluation for the Royal Danish Library of their search system REX/Primo

In our thesis we conduct an experiment of the Royal Danish Library's search system, REX/Primo. We test the usability of the user interface by observing the behahaviour of first time users and analyzing them with Usability Engineering Tools, and we examine the system’s ranking algorithm by analyzing the test subjects' relevance assessments of bibliographic entries, using tools from Information Retrieval Evaluation. REX is the name of the interface and Primo is the name of the underlying engine, an integrated search system.

We measure how the search system REX/Primo performs as an integrated search-system, and our focus is on the users. A total of 13 test persons were used for the experiment. The usability test consisted of six search tasks that the test persons had to solve inside REX/Primo. The IR evaluation consisted of three Works Tasks and a total of 90 search results. The test persons assessed the relevance of the documents according to the Work Tasks. Relevance assessments from IR evaluation were analysed by using Cumulated Gain (CG) Mean Reciprocal Rank (MRR).

We conclude that REX/Primo is a well functioning system but still has room for improvement. Our usability test found two major usability problems and 22 minor problems and take them into concideration when creating a usability design update of REX’s graphical user interface (in paper mock ups). The relevance algorithm works quite well. We conclude from our CG curves that the vast majority of the relevant documents are found within the first fifteen search results, just as there is not much noise within the first fifteen results.

3

INDHOLDSFORTEGNELSE

1 INDLEDNING (FÆLLES) 81.1 Indledning 81.2 Forskningsspørgsmål 91.2.1 Uddybning 91.2.2 Afgrænsning 101.3 Opsummering af indhold 121.4 Læsevejledning 121.5 Introduktion til REX/Primo 132 ANVENDT TEORI (FÆLLES) 152.1 Usability Engineering (AHG) 162.2 Hvad er usability? 162.3 “Discount usability” 182.3.1a Scenarier 182.3.1b Heuristisk evaluering 182.3.1c Observation af brugere og tasks 192.3.1d Tænke højt (“Simplified thinking aloud”) 192.3.2 I dette Speciale 202.4 Kognitive egenskaber ved concurrent kontra retrospektiv tænke højt 212.5 Operationaliseret usability 232.5.1a Guidance on usability, ISO 9241-11:1998 242.5.1b Nielsens fem usability-attributter 252.5.1c Hornbæks objektive og subjektive usability-mål 262.5.1d System Usability Scale, SUS 282.5.2 I dette Speciale 292.6 Information Retrieval (JBJ) 302.7 Hvad er Information Retrieval? 302.7.1 Laboratoriemodellen 312.7.2 De tre revolutioner i Information Retrieval 322.8 Information Retrieval Evaluation 342.9 Information Retrieval studier 352.9.1 Cranfield I 352.9.2 TREC 352.9.2a Pooling 36

4

2.9.3 INEX 372.10 Relevans 373 METODE I EKSPERIMENTET (FÆLLES) 393.1 Testopbygning 393.2 Opsætning af testmiljø og system 403.3 Morae 413.4 Testrunder 423.4.1a Første pilottest 423.4.1b Anden pilottest 423.4.1c Test 423.5 Pre Test-spørgeskema (demografiske data) 443.6 Testpersoner 514 METODE OG ANALYSE – USABILITY TEST (AHG) 534.1 Dataindsamling 534.2 Gennemgang af usability testens opgaver 544.3 Analyse af testpersonernes opgaveløsning 594.4 Analyse af SUS-spørgeskema 674.5 Analyse af funktioner og knapper 684.6 Forslag til usability-forbedringer i REX/Primo’s brugergrænseflade 714.6.1 At finde Det Kongelige Biblioteks website 724.6.2 Det Kongelige Biblioteks startside, www.kb.dk 724.6.2a Søgning på www.kb.dk 724.6.2b Søgning i REX 734.6.3 REX’ startside, ny søgning 744.6.4 REX, visning af søgeresultater 774.6.5 Bibliografisk post, bog 794.6.6 Bibliografisk post, samling af fotografier 804.7 Delkonklusion 825 METODE OG ANALYSE – IR EVALUERING (JBJ) 835.1 Metode 835.1.1 Fremgangsmåde for vores IR evaluering 835.2 Pre Task-spørgeskema 845.3 Work Tasks til IR evaluering 855.3.1a Work Task A: 865.3.1b Work Task B: 875.3.1c Work Task C: 87

5

5.4 Randomisering og rotation 885.5 Relevansskala 895.6 Databehandling af Pre Task- Spørgeskema 915.7 Cumulative Gain (CG) 935.7.1a Discounted Cumulated Gain (DCG) 935.7.1b Ideal Cumulated Gain (CGi) 945.7.1c Normalised Cumulated Gain (nCG) 955.7.1d Databehandling af Cumulated Gain 955.8 Mean Reciprocal Rank (MRR) 975.8.1a Document cut-off (DCV) 985.8.2 Databehandling af Mean Reciprocal Rank 995.9 Analyse 1005.9.1 Cumulated Gain 1005.9.2 MRR 1045.9.2a MRR for dokumenttyperne 1055.10 Delkonklusion 1076 DISKUSSION 1097 KONKLUSION 1118 PERSPEKTIVERING 1139 KILDER 11410 BILAG 118

LISTE OVER FIGURER

Figur 1: Interactive Information Seeking, Retrieval and Behavioral Processes (Ingwersen & Järvelin, 2005). I dette Speciale har vi fokus på modellens venstre halvdel, “Interface”, “IT” og “Document objects”. Vi inddrager begge halvdele, ved at anvende testpersoner i vores eksperiment. 15Figur 2: Nielsens “System Acceptability Model” illustrerer de forskellige egenskaber, et system skal tage hensyn til, for at blive accepteret af omverdenen og slå igennem på markedet, herunder usability (Nielsen, 1993, s. 25). 17

6

Figur 3: Simpel model af IR (Ingwersen, 1992, side 49). 30Figur 4: Laboratoriemodellen (Ingwersen & Järvelin, 2005) 31Figur 5: Oversigt over de tre IR revolutioner (Ingwersen, 1992). 33Figur 6: Foto af testopsætning. Observator 1 er placeret bag testpersonen. For at sikre testpersonernes anonymitet, anvender vi en (noget yngre) model i testpersonens stol. 40Figur 3 - INEXs relevanskategorier. Fra Malik, Tombros og Larsen (2007). Som det kan ses på figuren, anvender INEX fem meget forskellige kategorier . Der er tale om fem meget forskellige relevanstyper 89Figur 1 – Vores relevansskala, som vi anvender i IR evalueringen. 90Figur 7: En liste over alle de gode og dårlige usability-funktioner, vi har fundet i vores samlede arbejde med REX, det vil sige både inspektionen, som førte til opgavebeskrivelserne, og selve usability testen af vores 13 testpersoner, herunder post test-interviewet. Fejl! Bogmærke er ikke defineret.Figur 8: Fordeling af testpersonerns kendskab til emnerne for de tre Work Tasks. 91Figur 9: Fordeling af testpersonernes interesse for emnerne i de tre Work Tasks. 92Figur 10: Beregningen for CGi (Järvelin & Kekäläinen, 2002) 94Figur 11: Eksempel på hvordan vi har beregnet CG. Vi har lagt alle værdierne sammen for et enkelt dokument og fundet middelværdien. Dette tal er G-værdien, CG er derefter beregnet ved at lægge G-værdierne sammen. 95Figur 12: Eksempel på hvordan vi beregner CGi. Dataene er fra Work Task A. Alle relevansvurderinger er lagt sammen og middelværdien er fundet. Disse middelværdier bliver akkumuleret for at finde CGi. 96Figur 13: Beregning af nCG. Dette gøres ved at dividere hver enkelt CG-værdi med CGi-værdien fra den tilsvarende placering på listen. 97Figur 14: Oversigt over hvordan de enkelte dokumenttyper har fordelt sig i vores tre Work Tasks. 99Figur 15: Eksempel på, hvordan vi beregner MRR. Dataene er taget fra Work Task A. 99Figur 16: Kurverne for CG og CGi for Work Task A. Den prikkede linie er CGi, mens den fuldt optrukne linie er CG. 100Figur 17: Kurver for CG og CGi for Work Task B. Den fuldt optrunke linie er CG, mens den prikkede linie er CGi. 101Figur 18: Kurver for CG og CGi for Work Task C. Den prikkede linie er CGi, mens den fuldt optrukne linie er CG. 102Figur 19: nCG-kurverne for de tre Work Tasks. Den fuldt optrukne linie er Work Task A. Den stiplede linie er Work Task B. Den prikkede linie er Work Task C. 103Figur 22 - Tabel over MRR for de enkelte relevanskategorier ved de tre Work Tasks og middelværdien på relevanskategorierne. 104Figur 23 - Tabel over dokumenttyper og antal 105Figur 24 - MRR for bøger. MRR er angivet for de enkelte relevanskategorier i hver Work Task. Middelværdi angivet for hver enkelt relevanskategorie på tværs af Work Tasks. 106Figur 25 - MRR for billeder. MRR er angivet for de enkelte relevanskategorier i hver Work Task. Middelværdi angivet for hver enkelt relevanskategorie på tværs af Work Tasks. 107

7

1 INDLEDNING (FÆLLES)

1.1 Indledning

Indenfor de sidste 15 år har Det Kongelige Bibliotek (herefter benævnt KB) som nationalbibliotek fået IT-værktøjer i hænderne, som giver dem mulighed for, for første gang at åbne deres samlinger for hele befolkningen, uden at tænke på hverken logistiske problemer, overvågning eller hvide handsker.

Digitaliseringsarbejdet er i fuld gang, og på nuværende tidspunkt er den første del af KB’s billeder, fotografier, kartografisk materiale, håndskrifter, brevvekslinger, noder, med meget mere blevet affotograferet og gjort tilgængeligt ved at enkelt klik på et link i REX' bibliografiske poster. I en af KB's Billedsamlinger, som endnu ikke har fået en "pæn" webadresse (http://www.kb.dk/editions/any/2009/jul/editions/da/), kan brugerne finde de første digitaliserede monografier fra samlingerne David Simonsens Håndskrifter, Judaistisk Samling og Orientalske håndskrifter side om side, og man kan bladre i bøgerne og zoome ind på pennestrøgene i en mageløs grad af detaljering.

Det er to år siden, KB sidst gennemgik en usability-undersøgelse, som testede hele REX. Dengang blev REX/Primo som integrated search-system ikke for alvor sat på en prøve. Så denne del af REX/Primo tester vi. Vi vil se på mulighederne for at søge efter, afgrænse efter, udvælge, vise og åbne udvalgte af REX' 13 forskellige dokumenttyper.

Vores personlige motivation til at skrive dette Speciale, er at vi ønskede at fordybe os i et emne, som ikke kun er teoretisk men også har kvaliteter, der kan overføres på og dække et konkret behov. Det er en realitet, at der hvert år bliver publiceret mange Specialer ved de danske universiteter, som aldrig kommer længere end til Det Kongelige Biblioteks arkiver som pligtaflevering. Vi har følt, at det vigtigste ved vores Speciale var at få lov til at sætte alle vores kompetencer i spil i et arbejde, som kan komme andre til gode, og som vi kan glæde andre med, gerne så mange som muligt. Og selv om vi har valgt en retning på Danmarks Biblioteksskole, som bringer os langt nærmere IT-sektoren end biblioteket og kulturen, så har vores underviser i Bibliotek og Samfund på første semester, den nu pensionerede Jørgen Svane Mikkelsen, formået at tildele Biblioteksbrugerne en helt særlig status hos alle sine studerende, os selv inklusive.

Det er vores håb, at vores eksperiment udført for Det Kongelige Biblioteks Brugbarhedsgruppe, som dette Speciale er et produkt af, vil være med til at forbedre bibliotekets søgesystem, REX, ikke bare for de eksisterende brugergrupper, som især kommer fra universitetsmiljøet, men også for nye brugergrupper, som er drevet af nysgerrighed efter, hvad Det Kongelige Bibliotek har at tilbyde i sine digitaliserede samlinger.

8

REX/Primo er et system, som allerede er implementeret og har været i brug i et par år. Vi ønsker at undersøge, hvilke usability-forbedringer REX har mest brug for, for at få mere tilfredse brugere.Afhængig af Det Kongelige Biblioteks budget og planlægning, vil nogle af disse forbedringer forhåbentlig blive implementeret løbende, nogle vil blive tænkt ind i en kommende version af REX og andre igen vil måske blive forkastet, fordi de viser sig at skabe konflikter med andre dele af usability-området. Under alle omstændigheder anskuer vi den nuværende version af REX som en prototype på, hvad den næste version af REX skal kunne.

1.2 Forskningsspørgsmål

Med nuværende version af REX/Primo og biblioteksbrugernes tilfredshed for øje, udformer vi følgende forskningsspørgsmål og operationaliserer det i to sæt uddybende spørgsmål:

Hvordan performer Det Kongelige Biblioteks søgesystem, REX/Primo, som integrated search-system, med henblik på brugerne?

På hvilke områder kan systemets usability forbedres i forhold til førstegangsbrugere? På hvilke områder kan systemets usability forbedres i forhold til integrated search, det vil

sige i forhold til visning og håndtering af forskellige dokumenttyper?

Hvordan performer REX/Primos relevans-algoritme? Hvordan performer REX/Primos relevans-algoritme i forhold til integrated search, det vil

sige i forhold til rankingen af forskellige dokumenttyper?

1.2.1 Uddybning

I vores speciale foretager vi et eksperiment af Det Kongelige Biblioteks søgemaskine, REX/Primo. Vi tester brugergrænsefladens usability ved at observere førstegangsbrugeres reaktioner og analyserer dem med Usability Engineering-værktøjer, og vi undersøger ranking-algoritmen ved at analysere testpersonernes relevansvurderinger af bibliografiske poster, ved hjælp af instrumenter fra Information Retrieval Evaluation.

For at besvare vores forskningsspørgsmål, udfører vi et eksperiment med testpersoner, som repræsenterer en udvalgt gruppe af Det Kongelige Biblioteks brugere.

Til en usability test er 6 eller 12 testpersoner et passende tal. Til en IR evaluering er 10 testpersoner minimum. Vi gik som udgangspunkt efter 2 pilottestpersoner og 10 testpersoner, og vi endte med 13 testpersoner i alt.

Vi laver en usability test af REX, hvilket indebærer, at vores testpersoner afprøver de funktioner, som allerede findes, og vi på den baggrund kommer med forslag til forbedringer af deres brugbarhed, placering og synlighed.

9

Eftersom systemet har været i brug i et par år og sidst blev usability-testet for to år siden af et privat usability-firma, Snitker og Co., forventer vi ikke at finde nogle katastrofale usability-problemer i systemet.

Vi leder efter mere eller mindre signifikante problemer, som efter Nielsen's definition er kendetegnet ved, at signifikante problemer bør ændres i systemet så hurtigt som muligt, mens mindre signifikante problemer kan accepteres for nu og tænkes ind i fremtidige udgaver af systemet i stedet (Nielsen, 1993).

Vi laver en IR evaluering af REX/Primos ranking-algoritme, hvor vi lader testpersonerne måle relevansen af rankede søgeresultater i REX/Primo og analyserer, om rækkefølgen bør forbedres, ikke blot i forhold til graden af relevans, men også indenfor de forskellige dokumenttypers popularitet hos testpersonerne i søgeresultaterne.

Til IR evalueringen anvender vi to instrumenter til databehandlingen, Cumulated Gain og Mean Reciprocal Rank. IR evalueringen er bygget op omkring tre Work Tasks, hvor vi har været ude og foretaget forskellige søgninger. De første tredive søgeresultater vil vi stille op over for testpersonerne, som bliver bedt om at relevanvurdere de enkelte bibligrafiske poster.

For at kunne måle performance af relevansalgoritmen anvender vi forskellige typer af Cumulated Gain (CG). Vores relevanskala består af fire kategorier, som vi har givet en værdig mellem 0 og 3. CG foretager beregninger på relevansvurderingernes værdier og udregner et gennemsnit for alle testpersonerne for et enkelt dokument af gangen. Resultatet af de mange beregninger vil være forskellige kurver, hvor af vi vil kunne se hvordan relevansalgoritmen performer i REX / Primo (Järvelin & Kekäläinen, 2002).

Derudover anvender vi Mean Reciprocal Rank (MRR), som foretager beregninger af hvor og hvornår de forskellige relevanskategorier bliver brugt af testpersonerne. Ud af disse beregninger vil vi se lidt mere på, hvordan relevansalgoritmen performer og vi vil se hvordan REX/Primo performer som integrated search system (Voorhees, 1999).

1.2.2 Afgrænsning

Målgruppe for vores forskningsspørgsmål:Det Kongelige Biblioteks Brugbarhedsgruppe, som vi udfører eksperimentet for. Dette har indflydelse på metoden i eksperimentet, hvor dele af dataindsamlingen er rettet mod Det Kongelige Bibliotek og ikke anvendes i dette Speciale. Og det har indflydelse på Specialet, som er produktorienteret og præsenterer forslag til forbedring af usability og tweaking af REX/Primo’s ranking-algoritme.

Vi opstiller følgende rammer for metoden anvendt i dette Speciale:

Udførsel af eksperiment: Eksperimenttype: Test i laboratorium. Sted: Danmarks Biblioteksskole. Antal testpersoner: Minimum 10-12. Indkaldelser: Hver testperson bliver testet én gang. Varighed: Eksperimentet varer maksimalt to timer pr. testperson.

10

Testpersoner:I vores usability test og IR evaluering af REX/Primo anvender vi testpersoner med følgende egenskaber: Aldersgruppe: 50 til 67 år (eller ældre, hvis personen stadig er erhvervsaktiv). Kønsfordeling: Jævn fordeling af mænd og kvinder. IT-kundskaber: Kender som minimum browseren Internet Explorer og bruger internettet. Informationssøgningsniveau: Ingen informationsspecialister. Kendskab til REX: Har aldrig eller højst et par gange anvendt REX/Primo. Uddannelse: Akademisk baggrund er ikke et krav. Enten akademisk baggrund eller

undervisningsbaggrund. Testpersonerne skal have en potentiel grund til at anvende KB, f.eks. for til at tilrettelægge undervisningsmateriale til deres elever/studerende, til personligt uddannelsesforløb.

Metode, usability test: Brugerniveau: Førstegangsbrugere og nybegyndere af systemet. Fokus: Usability-problemer observeret under indlæring af systemet. Mikro-niveau: Vi måler funktioner indenfor korte tidsrum á sekunder eller minutter. Dataindsamling:

o Kvantitative variabler, f.eks. løsningstid, effektivitet, antal museklik.o Anvendte løsningsmetoder og observeret søgeadfærd.o Kvalitative udsagn under test og i post test-interview. Ingen kvalitative data

anvendes, uden samtidig at blive underbygget dem med kvantitative data.

Metode, IR evaluering: Vi anvender simulerede Work Tasks. Vi udfører tre forskellige søgninger på tre forskellige emner. Søgeresultaterne skal

indeholde mindst tre forskellige dokumenttyper. Vi producerer tre forskellige Work Tasks, som indeholder søgeresultaterne. Testpersonerne evaluerer de første 30 søgeresultater fra hver søgning.

Anvendte dele af systemet:Vi tester specifikt: Adgangen til og søgemulighederne i REX på www.kb.dk's startside. Hvilke af REX' funktioner der bliver benyttet, og hvilke der er usynlige, på: REX's søgeside. Visning af søgeresultater. Visning af en enkelt bibliografisk post. Visning af en post, som rummer flere end ét dokument (særligt for billeder). REX/Primo's ranking-algoritme, i form af en IR-evaluering.

Vi tester ikke: System-fejl. Selve websitet, www.kb.dk med underdomæner, med undtagelse af startsiden. REX’ “Avanceret søgning”. REX’ søgning under fanebladene “Artikler” og “www.kb.dk”. Udlåns-funktionen, idet den bliver skiftet ud 1. juli 2010. Funktioner, som kræver login. Hjælp-funktionen.

11

Søgeresultaternes oplysninger og de enkelte posters oplysninger. Disse oplysninger er udvalgt efter bibliotekariske principper, som ikke er afhængige af REX/Primo-systemet.

Installation af plug-in til visning af kartografisk materiale, da det er et trediepartsprogram.

1.3 Opsummering af indhold

Kapitel 1: Introduktion er introduktion til specialet, herunder vores forskningsspørgsmål og en introduktion til Det Kongelige Bibliotek.Kapitel 2: Anvendt teori beskriver videnskabelig praksis og teorier, som danner grund for vores usability test og vores IR evaluering.Kapitel 3: Metode i eksperimentet gennemgår opstilling og dataindsamling i de fælles dele af vores eksperiment.Kapitel 4: Metode og analyse - Usability test. Dette metode rummer metode, databehandling og analyse af usability testen. Vi producerer fem mock ups med forslag til usability-forbedringer af brugergrænsefladen.Kapitel 5: Metode og analyse - IR evaluering. Dette metode rummer metode, databehandling og analyse af IR evalueringen. Vi præsenterer en metode, som KB kan anvende til at tweake deres ranking algoritme.Kapitel 6: Diskussion argumenterer for vores resultater og diskuterer, hvordan KB kan anvende dem i praksis.Kapitel 7: Konklusion besvarer vores forskningsspørgsmål.Kapitel 8: Perspektivering beskriver det videre samarbejde med KB.

1.4 Læsevejledning

Sådan skal ansvarsfordelingen forstås:• AHG: Aninja Helene Grøn• JBJ: Jessica Blanca Johansen

Vi angiver ansvarsfordeling i Indholdsfortegnelsen, ved at tilføje ansvarshavendes initialer angivet i parantes efter udvalgte overskrifter. Ansvarsfordelingen skal læses sådan, at den nævnte forfatter har ansvar for denne og alle de efterfølgende overskrifter (også overskrifter af samme niveau), indtil andet bliver nævnt, altså indtil ansvar skifter til den anden forfatter, til vi angiver et fælles-afsnit, eller til vi begynder på et helt nyt kapitel.

Sådan læses vores citationer:Nå vi citerer direkte, så vil ophav, udgivelsesår og sidetal være angivet. Eksempel: (Hansen, 1977, side 999). Når vi henviser til et dokument uden at citere direkte, angiver vi ophav og udgivelsesåret. Eksempel: (Hansen, 1977).

Ordliste:

Brugergrænseflade: Den danske term for user interface.

12

CG: Cumulated Gain.DCV: Document Cut-off Value.Eksperiment: Den overordnede betegnelse for hele vores undersøgelsesforløb af KB.HCI: Human computer interaction.IIR: Interactive Information Retrieval. Område inden for IR, som koncentrer sig om bruger-system-interaktionen.IR evaluering: Forskningsområde, som koncentrerer sig om at undersøge performance af systemer.IR: Information Retrieval. Forskningsområde indenfor informationsvidenskaben.IVA / DB: Det Informationsvidenskabelige Akademi / Danmarks Biblioteksskole.KB: Det Kongelige Bibliotek.MRR: Mean Reciprocal Rank.OPAC: Online Public Access Catalog.Opgaver: De opgaver, som vi stiller testpersonerne i løbet af usability testen (vi kalder dem opgaver i stedet for tasks, så læseren ikke forveksler dem med Work Task'ene fra IR evalueringen).Primo: Det Kongelige Biblioteks integrated search-CMS (Content Management System).REX/Primo: Den betegnelse vi bruger, når vi taler om hele KB’s elektroniske service.REX: Det Kongelige Biblioteks søgefunktions brugergrænseflade.Search tasks: De opgavebeskrivelser, som vi anvender i forbindelse med usability testen.Test: De enkelte dele af vores eksperiment.Usability: Forskningsområde, som koncentrerer sig om brugbarhed.Work tasks: De opgavebeskrivelser, som vi anvender i forbindelse med IR evalueringen.

1.5 Introduktion til REX/Primo

Det Kongelige Bibliotek består af forskellige databaser, et interface og en søgemaskine som tilsammen kaldes REX/Primo. KB købt systemet Primo af det israelske firma Exlibris, som løbende tilpasset Primo til bibliotekets behov, står for updates og for løbende support. Det eksisterende REX, KB’s eget interface, er styret af ”integrated search-systemet”, Primo, som faciliterer søgningen i samtlige arkivariske databaser uanset sprog og format, ved at høste informationen i baserne med en bot (Madsen, 2007), på samme måde som Google og andre søgemaskiner crawler nettet jævnligt og opdaterer deres egne lagrede kopier af websiderne, som gøres tilgængelig for brugeren at søge i fremfor den oprindelige webside, for at sætte søgehastigheden i søgemaskinerne op til et acceptabelt niveau.

Det Kongelige Bibliotek udgør i sig selv et såkaldt ”digital library”, som indeholder både OPACs, fuld-tekst dokumenter, billeder, lyd- og video-optagelser, alt sammen i forskellige fil-formater og fra forskellige servere. (Chowdhury, 2004).

KBs database kaldes i faglige termer for OPAC. Online Public Access Catalogs (OPACs) er det system og interface, som gør, at brugere kan søge i bibliotekskataloger via internettet. Typisk, giver OPACs adgang til søgning i bibliotekets katalog og udlånsstatus. Via login kan brugere også få adgang til deres lånerstatus, hvor de kan forny lånte dokumenter, reservere dokumenter o.lign. (Chowdhury, 2004). Det er typisk biblioteker, som anvender OPACs, hvor de kun har bibliografiske poster og stort set ingen fuld-tekst dokumenter.

13

Der findes indtil videre tre generationer af OPACs (Chowdhury, 2004): Første generation: Det var muligt at søge på ophav, titel og muligvis ID. De

bibliografiske poster var ikke udformet efter et standard-format. Anden generation: Det blev muligt at anvende Boolske operatorer i søgningen og

browsing via emneord. Tredje generation: Søgemuligheder lig dem, der findes på internettet, blev mulige at

anvende. REX/Primo tilhører den tredje generation af OPACs. Man kan uden problemer foretage en ”quick ’n dirty”-søgning i REX/Primo og stadig forvente at få et resultat.

Som sagt, så har KB mange forskellige dokumentsamlinger og databaser. Disse skal Primo crawle og gøre til én stor søgbar samling. Det kan der være mange problemer i, fordi der findes mange forskellige formater for metadata. F.eks. anvendes MARC-formatet typisk til bibliografiske poster i bibliotekerne og Dublin Core anvendes til websider. Ex Libris har udviklet SFX, et stykke software, der anvendes som til at gøre søgning på tværs af databaser lettere (Chowdhury, 2004). Vi er ikke klar over, om KB anvender SFX som en del af REX/Primo, men andet virker usandsynligt.

I 2008 gennemførte KB en usability test, som blev udført af den private usability-virksomhed, Snitker og Co. De 11 testpersoner i denne test var udvalgt blandt universitetsstuderende, Ph.D'er og forskere, og seks af dem havde stor erfaring i at bruge REX. Denne test blotlagde en usability-problemer i søgeboksen til bøger og andre dokumenttyper, i søgeboksen til videnskabelige artikler, i afgrænsningsmenuen, søgeresultaterne og bestillingsmetoden (Snitker & Co., 2008). Disse problemer blev efterfølgende løst af KB (såvidt det kunne lade sig gøre, uden at skabe nye usability-problemer i løsningen af de gamle).

Usability testen var rettet imod KB's kernebrugere fra universiteterne og testede systemet bredt, herunder også de kollaborative funktioner, mens REX/Primo som integrated search-system ikke var ikke et hovedfokus i testen.

Det Kongelige Bibliotek har en gennemgribende opdatering undervejs, som bliver implementeret 1. juli 2010, samme dato som dette Speciale bliver afleveret. Opdateringens hovedformål er at få overført de sidste funktioner, som stadig bliver varetaget af det gamle søgessystem, Aleph, herunder hele den del, som har at gøre med opdatering af de fysiske materialers placering, bestilling og udlån. Vi er altså garanteret store ændringer i systemet over sommeren, og billedet vil have ændret sig, når vi skal forsvare vores Speciale i juni. Det Kongelige Bibliotek er et stort lokomotiv at få til at rulle, der er mange afdelingers bidrag til ændringerne i REX, som skal koordineres, og alle ideer og ændringer skal synkroniseres med ExLibris i Israel, det firma som leverer søgesystemerne Aleph (lidt endnu) og Primo til KB og står for al support og opdateringer. Da vi kontaktede KB i februar, var disse ændringer allerede fastlagt.

Vi forventer dog ikke, at vores eksperiment vil være spildt arbejde af den grund, idet Det Kongelige Biblioteks Brugbarhedsgruppe har forklaret, at de ikke, hverken til denne opdatering eller tidligere, har haft tid til at se på REX med en designers øjne, hverken æstetisk eller usability-mæssigt. Brugbarhedsgruppens prioriteter er hovedsalig udvikling af funktionalitet og systemdesign, og her findes KB's motivation til at indgå samarbejde med os speciale-studerende.

14

2 ANVENDT TEORI (FÆLLES)

I dette afsnit redegør vi for sammenhængen mellem usability engineering og IR. Derefter gennemgår vi anvendte teorier inden for usability engineering og test af brugere, og i anden halvdel af dette kapitel gennemgår vi teorier inden for Information Retrieval.

Metodisk falder dette Speciale ind under Information Retrieval, IR, og Human Computer Interaction, HCI, herunder Usability Engineering.

Vi oplever, at de to forskningsområder kan være tæt knyttede. Usability engineering foregår i brugergrænsefladen, mens IR dækker funktionaliteten i det bagvedliggende system.

Figur 1 er en model over interaktiv informationssøgning. De tre kategorier i venste halvdel af figuren, “Interface”, “Information objects” og “IT”, kan anvendes til at definere dele af REX/Primo.

Interface er REX/Primos grafiske brugergrænseflade, GUI, altså den del af computersystemet, som brugerne, “information seekers”, kan se på skærmen. Interface er også brugergrænsefladen på den computer, brugeren anvender (skærm, mus, keyboard).

Information objects dækker over Det Kongelige Biblioteks samling, hvis dokumenter og dokumentrepræsentationer (bibliografiske poster) er lagret elektronisk og findes frem fra de forskellige databaser, de er lagret i, med REX/Primo.

Figur 1: Interactive Information Seeking, Retrieval and Behavioral Processes (Ingwersen & Järvelin, 2005). I dette Speciale har vi fokus på modellens venstre halvdel, “Interface”, “IT” og “Document objects”. Vi inddrager begge halvdele, ved at anvende testpersoner i vores eksperiment.

15

IT, forstået som det bagvedliggende system, udgøres af Primo uden REX. REX er det søgesystem, som brugeren møder i brugergrænsefladen, mens systemets engine er Primo, der kan beskrives som et integrated search-CMS (content management system). Primo sørger for, at alle Det Kongelige Biblioteks elektroniske samlinger kan samles i én database uanset sprog of format, søges via samme interface, d.v.s. REX, og samles i ét sæt søgeresultater uanset dokumenttype, ranket efter relevans.

Information seeker(s) er Det Kongelige Biblioteksbrugere, som har forskellig baggrund og forskellige mål. Brugerens formål kan være arbejdsrelateret, hvilket giver informationssøgningen en “Organisational context”. Baggrunden for brugerens informationsbehov kan også have en “social context”  eller en “cultural context”, hvor informationsbehovet kan udspringe af familie og venner, eller af brugeren selv.

Pilene i modellen illustrerer den interaktion, der foregår mellem de forskellige elementer.  “Information seeker” og ”interface” bliver kædet sammen, når brugeren retter en forespørgsel til systemet, og systemet giver synlig feedback i brugergrænsefladen. På samme måde, som forbindelsen mellem “information seeker” og “Context” opstår, når brugeren interagerer med sin omverden og får feedback.

I vores speciale har vi fokus på modellens venstre halvdel "interface", ”IT" og ”Document objects”. Men vi inddrager også den højre halvdel, da vi anvender testpersoner i vores eksperiment, som blandt andet bidrager med, automatisk at sætte udførslen af opgaver og tasks ind i testpersonens personlige kontekst.

2.1 Usability Engineering (AHG)

I de følgende afsnit introducerer vi usability engineering, en disciplin som falder ind under forskningsområdet Human Computer Interaction, HCI. Vi redegør for vores valg af usability-eksperten Jakob Nielsens definition af og tilgang til usability. Og vi beskriver det teoretiske grundlag, som danner rammen om metoden i vores usability test.

Anden halvdel af afsnit 2: Anvendt teori (fælles), omhandler Information Retrieval, IR.

2.2 Hvad er usability?

Usability kan defineres som de egenskaber ved et system, f.eks. et computerprogram, som gør, at brugerne ønsker - eller ikke ønsker - at vende tilbage og bruge det igen. Selvfølgelig skal systemet kunne udføre alle de funktioner, det markedsføres med. Men for at levere varen må det også leve op til brugernes forventninger om, at det skal være nemt tilgængeligt på flere forskellige planer.

16

En detaljeret tilgang til usability gives af Jakob Nielsen, der beskriver usability som en af de egenskaber, der falder ind under systemets samlede “acceptability”, hvilket vel bedst fortolkes som “omverdenens accept” på dansk (Nielsen, 1993).

Nielsens “System Acceptability Model” (Figur 2) skal læses fra venstre mod højre og symboliserer til en vis grad udviklingen af et system over tid.

Figur 2: Nielsens “System Acceptability Model” illustrerer de forskellige egenskaber, et system skal tage hensyn til, for at blive accepteret af omverdenen og slå igennem på markedet, herunder usability (Nielsen, 1993, s. 25).

Omverdenens accept af et system, altså systemets overordnede acceptability, afhænger i første omgang af to ting: 1) At systemet er socialt acceptabelt, så det ikke f.eks. bliver censureret eller tvunget af markedet ved udgivelse (det kan man især forestille sig gælder computerspil); og 2) at systemet er acceptabelt rent praktisk, altså at både udvikler, investorer og slutbrugere kan være tilfredse med systemets udviklingsomkostninger og pris, pålidelighed, kompatibilitet med eksisterende systemer, muligheden for support efter udgivelse, og så videre.

Under punkt 2) hører også kategorien Usefulness, systemets reelle brugbarhed, som igen inddeles i to lige vigtige dele, utility og usability. Utility er et systems funktionalitet eller evne til, principielt at kunne det, det lover, rent teknisk. Er det et system, som skal bruges i forbindelse med undervisning, skal det rumme gode, pædagogiske metoder til indlæring. Er det et computerspil beregnet på at underholde, skal det være sjovt for at have høj utility, ifølge Nielsen.

Usability er de elementer af systemet, som bestemmer hvordan og hvor godt brugeren interagerer med systemet. Det er de indtænkte funktioner i brugergrænsefladen, som sørger for, at systemets funktioner ikke kun principielt fungerer, men også i praksis bliver set og anvendt af slutbrugeren. For at udvide Nielsens eksempel med computerspil, er de ikke sjove, hvis man ikke kan handle i spillet, fordi styringen er for dårligt indtænkt eller for svær at lære. Og en OPAC som Det Kongelige Biblioteks forringes betydeligt for brugeren, hvis den giver adgang til fuldtekst-dokumenter og digitaliserede billeder, men brugeren ikke kan finde ud af at installere den nødvendige billedfremviser eller overhovedet finde linket til at få bragt det digitaliserede dokument frem på skærmen (Nielsen,1993).

17

Usability og utility er absolut lige vigtige og overlapper hinanden i systemudviklingen, selv om de ikke udgør en lige stor post i det samlede budget. I 1993 sætter Nielsen (s. 7) det absolutte minimum, som systemudviklere bør afsætte til usability, til 2% af det samlede budget til opgaven, men anbefaler 6-10% (eller helt op til 21% i store projekter på 58+ mandeår). I 2007 skriver Molich, at det er fuldt forsvarligt at sætte 5-10% af til usability-test (Molich, 2007).

2.3 “Discount usability”

Til at usability-teste Rex’ brugergrænseflade anvender vi den veldokumenterede metode, som Jakob Nielsen er ophavsmand for (udviklet igennem bl.a. fem artikler fra 1989 og ni artikler fra 1990), og som også Rolf Molich har haft stor indflydelse på (Molich & Nielsen, 1989, 1990a, 1990b). Nielsen selv kalder sin metode for “discount usability engineering”, udfra en betragtning om, at:

”using only the best methods may result in using no methods at all. [...] Therefore, I focus on achieving “the good” with respect to having some usability engineering work performed, even though the methods needed to achieve this result may not always be the absolutely “best” method and will not necessarily give perfect results” (Nielsen, 1993, s. 17).

”Discount usability” er bygget på fire “søjler”: Scenarier Heuristisk evaluering Observation af brugere og tasks Tænke højt (”Simplified thinking aloud”)

Disse fire metoder anvendes på forskellige stadier af systemudviklingen, gerne med overlap.

2.3.1a ScenarierScenarier er en metode at teste prototyper af et fremtidigt system på. Et scenarie er baseret på en historie, som bygges op omkring én bruger, som anvender én lille del af det samlede system til at opnå én bestemt løsning, under specificerede omstændigheder. Det kunne for eksempel være at hæve penge i en bankautomat. Testpersonen præsenteres for dette scenarie og bliver af testlederen, ved hjælp af mock-ups på papir eller på en skærm, guidet igennem systemets skærmbilleder hen til løsningen. Herefter diskuteres skærmbillederne på mikro-niveau og løsningsmetoden på makro-niveau (Nielsen, 1993).

Scenarier hører dermed til i de tidlige stadier af systemdesign-fasen, hvor systemet endnu ikke er færdigt, og usability tests udføres i de dele af systemet, som er nogenlunde klar til at blive udsat for test (på trods af systemfejl og manglende debugging), eller udføres med mock-ups (modeller af papir eller på skærmen, som ligner det færdige system nok til at fungere som substitut).

Da REX allerede eksisterer og er implementeret, behøver vi ikke anvende scenarier.

18

2.3.1b Heuristisk evalueringHeuristik kommer af det græske “heuriskein”, “at finde”. Indenfor pædagogik betegner heuristik en metode, som lader subjektet “selv finde oplysninger og gøre opdagelser gennem selvstændig tænkning” (Politikens Nudansk med Etymologi, 1999).

Heuristisk evaluering er en system-evaluering udført af eksperter indenfor usability engineering, systemets domæne eller begge områder (Nielsen, 1993). Eksperterne trækker på deres erfaring med usability til at beskrive et system under udvikling (ved hjælp af mock-ups) eller et eksisterende system. Metoden udelukker således brug af testpersoner, hvorimod f.eks. systemets udviklere og it-medarbejdere godt kan tage del i evalueringen. Morville & Rosenfeld (2007) foreslår at sætte en informationsspecialist, en usability-specialist og en interaction designer sammen i et heuristisk team.

De udvalgte evaluatorer går systemet igennem i sømmene, udstyret med en liste over “heuristics”, usability-principper, som alle skal være overholdt i systemet for at sikre høj usability. Disse lister eller samlinger findes i mange udgaver, Nielsen påpeger selv flere (unavngivne) lister på over 1000 retningslinier (Nielsen, 1993). Der findes fortsat forskellige heuristikker, men Molich og Nielsens egen liste på 10 principper (Molich & Nielsen, 1990b) har siden dannet skole. Sharp et.al. påstår, at “Heuristic evaluation [was] first developed by Jakob Nielsen and his colleagues (Nielsen and Mohlich, 1990)”, baseret på disse 10 principper (Sharp, Rogers & Preece, 2007).Vi vedlægger Molich og Nielsens 10 principper (1990b) som bilag 1.

Evaluatorernes erfaring og sunde fornuft er afgørende for, om principperne bliver tolket på bedste måde og problemerne blotlagt. En undersøgelse af Nielsen (1993) viser, at én evaluator, som arbejder alene, højest kan regne med at finde 35% problemer ved systemet, mens to evaluatorer i snit finder 50%, fem evaluatorer 75%, og man skal op på 12-15 evaluatorer, før kurven flader ud og cirka 90% af alle problemer er påpeget. Det er implicit, at man aldrig kan forvente at finde 100%.

2.3.1c Observation af brugere og tasksObservation af brugere gælder de brugergrupper, som systemudviklerne forventer, vil blive deres kommende systems brugere. Observation af disse brugeres tasks har til formål at kortlægge brugeradfærden i eksisterende systemer (Molich, 2007). De eksisterende systemer kan være den nuværende version af systemudviklers eget system, eller det kan være et eller flere konkurrerende systemer (Nielsen, 1993).

Observationen af brugerne kan enten foregå i brugerens eget miljø og studere udførsel af brugerens dagligdags tasks, eller undersøgelsen kan rykkes ind i laboratoriet, hvor brugeren udfører en række tasks defineret af usability-eksperten. Efter observationerne kan der opstilles en prioriteret liste over de funktioner, det kommende system skal have, og systemets funktioner kan optimeres på utility og usability-design til brugernes adfærd, mest anvendte arbejdsmetoder og udækkede behov.

Det kan for eksempel betyde et logisk design, rigt på forklaringer og med en god hjælp-funktion, så nye brugere hurtigt lærer at bruge systemet; og med indbyggede genveje indbygget, som tillader øvede brugere at arbejde langt mere effektivt, med minimal spildtid (Nielsen, 1993).

For at være sikre på, at vores testpersoner anvender de udvalgte dele af REX, som vi har valgt at teste, anvender vi foruddefinerede tasks i laboratoriet til vores testpersoner.

19

2.3.1d Tænke højt (“Simplified thinking aloud”)“Tænke højt”, hvis fulde betegnelse er “concurrent thinking aloud protocol”, er en metode, som går ud på at få testpersonen til at verbalisere sine tanker, imens testen udføres. Denne verbalisering giver en indsigt i testpersonens syn på det testede system og vedkommendes (mis)forståelse af, hvordan systemets forskellige dele skal anvendes.

Tænke højt må dermed ikke forveksles med “talk aloud protocol”, tale højt-metoden, som kun tillader testpersonen at beskrive sine handlinger, men ikke at give nogen forklaring på dem, i et forsøg på at skabe en objektiv kontekst til udførelsen af testens tasks (Ericsson & Simon, 1987).

Ligeledes må metoden heller ikke forveksles med “retrospective thinking aloud protocol”, hvor testpersonen udfører testen helt i tavshed, imens aktiviteten på computerskærmen optages. Optagelsen vises umiddelbart efter til testpersonen med observator siddende ved siden af, og testpersonen bliver nu bedt om at tænke højt, det vil sige retrospektivt at fortælle, hvorfor opgaverne blev løst som de gjorde, og også nævne sine forventninger til og mening om systemet. Observator kan også stille sine spørgsmål, uden at bekymre sig om at influere opgaveløsningen, og afspilningen kan om nødvendigt pauses kort.

Tænke højt-metoden tilskrives Ericsson og Simon, som publicerede metoden i en artikel fra 1984, “Protocol Analysis: Verbal Reports as Data” (Ball, Dodd, Egers & Stevens, 2007).

Ophavsmændene til concurrent tænke højt, Ericsson & Simon (1987), beskriver, hvordan tænke højt blev udviklet til brug indenfor psykologien og har haft meget forskellige funktioner i løbet af 1900-tallet, lige fra Jung’s “free-association tasks” i 1910 over forskellige “processes of comprehension” i 1950’erne til “memory experiments” eller binære, logiske spørgsmål i 1970’erne og 80’erne.

Nielsen lægger derfor vægt på at kalde “sin” version af tænke højt for “simplified thinking aloud”, idet indsamlingen og analysen af testpersonens verbale kommentarer kan udføres på den mest “simple” måde, som enhver computer-ekspert eller observator kan håndtere og forstå, uden at behøve inddrage en psykolog til testen eller analysen (Nielsen, 1993).

Kommentarerne fra tænke højt-testen skal, ligesom al anden kvalitativ data, behandles som subjektive holdninger og meningstilkendegivelser. De kan have stor betydning for observators forståelse af testpersonens adfærd, især til at opklare, hvis testpersonen har misforstået, hvordan en funktion virker, og forsøger at opnå noget helt andet, end det er muligt. Men kommentarerne må aldrig tillægges højere betydning end den konkrete adfærd.

2.3.2 I dette Speciale

Idet REX er et system, som allerede er implementeret og har været i brug i flere år, tilgår vi det som et iterativt system, altså som et system, som er under konstant udvikling, og hvor løbende ændringer i og opdateringer af designet er en selvfølgelighed. Og rent praktisk betragter vi den nuværende version af REX som en prototype på, hvad den næste version af REX skal kunne.

Dermed befinder vi os på dataindsamlingsstadiet til et kommende system. Først når nok data er indsamlet og bearbejdet, og den konkrete planlægning af den næste version af

20

REX går ind i sine tidlige faser, vil det være relevant for KB at bruge scenarier til at teste ændringerne i den kommende brugergrænseflade.

For at indsamle relevante data om det nuværende REX er det derimod nødvendigt at lave en heuristisk evaluering og/eller observere brugere, mens de anvender systemet.

Vi vælger at teste REX frem for at lave en heuristisk evaluering, da vi ikke er interesserede i ekspertholdninger, og da vi ikke ønsker at slå “falsk alarm” ved at slå ned på problemer, som ikke sidenhen bliver fundet i brugernes adfærd (Sharp, Rogers & Preece, 2007). I stedet ønsker vi at lave en logfilanalyse af, hvordan udvalgte brugere anvender REX. Dét at observere brugernes egne søgetasks er ikke brugbart til at indsamle sammenlignelige logfil-data. Vi er nødt til at bruge et sæt opgaver, som alle testpersonerne skal udføre. Vi ender altså med at udsætte REX for en usability test med tænke højt-metoden. Og for at kunne designe opgaverne til at give optimal mulighed for at afprøve alle de testede funktioner i REX, laver vi inden testen en inspektion af systemet (Molich, 2007), en slags uformel heuristisk evaluering, først hver for sig og siden med to domæne-specialister fra Det Kongelige Biblioteks Brugbarhedsgruppe.

2.4 Kognitive egenskaber ved concurrent kontra retrospektiv tænke højt

Der er uenighed om, hvorvidt den kognitive proces, som foregår, idet testpersonen verbaliserer sin egen (søge-)adfærd, ændrer ved testpersonens læringsproces.

Ophavsmændene til concurrent (“samtidig”) tænke højt-metoden “claim that cognitive processes are not modified by these verbal reports, and that task-directed cognitive processes determine what information is heeded and verbalized” og viser dette empirisk (Ericsson & Simon, 1993, side 16). De to herrer siger dog, at verbaliserings-processen har den indvirkning, at testpersonen sænker hastigheden af opgaveudførelsen, til den passer med personens talen- eller tænken højt (Ericsson & Simon, 1987).

Nielsen (1993), derimod, henviser til to studier, som begge viser, at testpersoner, som tænker højt, laver færre fejl, har en højere indlæring og dermed hurtigere forstår at bruge systemet.

Og andre studier igen demonstrerer, at tænke højt har en direkte negativ effekt på eksperimentet. Ball, Dodd, Eger & Stevens refererer i 2007 til fire af den slags studier og konkluderer, at den negative effekt hovedsaligt afstedkommes af to faktorer, besvær med verbaliseringen og observators indflydelse:

“Evidence suggests that think-aloud verbalisations may be incomplete as some processes are unconscious [Bainbridge, 1999] or difficult to translate verbally [Schuck & Leahy, 1966]. […] People think quicker than they talk, such that only a sample of cognitive activity may be reported [Bainbridge, 1999]. […] Particularly striking is the ‘verbal-overshadowing’ effect [Schooler, Ohlsson & Brooks, 1993], which is revealed as markedly worse performance under verbalisation requirements for tasks involving essentially ‘non-reportable’ cognitive processes.[…]How the experimenter interacts with the participant can also interfere with normal task processes; even neutral comments can taint subsequent performance by re-directing attention [Kirk & Ashcraft, 2001]. […] In the context of usability

21

testing, practitioners typically […] use prompts such as “What do you think this means?” [Boren & Ramey,2000; Dumas & Redish, 1999]. Such prompts can disrupt the flow of task-based processing, redirect attention and invoke retrospective rationalisations. (Ball, Dodd, Eger & Stevens, 2007).

Dette taget i betragtning kan det diskuteres, om det overhovedet er en god ide at benytte tænke højt under testsessionen. Her kommer den retrospektive tænke højt-metode ind i billedet, som en måde at indsamle testpersonernes verbale kommentarer efterfølgende, uden at de blot bliver afleveret som en mundtlig rapport.

Retrospektiv tænke højt er ikke nær så anvendt en metode som tænke højt, men den har lige så høj validitet. Så længe det retrospektive tænke højt-interview begyndes umiddelbart efter, at testen er færdig, har testpersonen fortsat informationen om den specifikke kognitive process (mentale tilstande og operatorer) lagret i korttidshukommelsen, og via de kontekstuelle cues fra optagelsen kan der skaffes direkte adgang til disse informationer. Således går der ikke meget tabt ved at udskyde tænke højt-processen, til efter testen er færdiggjort (Ericsson & Simon, 1993).

Når det er sagt, er der stadig mulighed for, at testpersonen under interviewet falder tilbage på generaliseringer, efterrationaliseringer og sågar fabrikationer. Det kunne for eksempel skyldes, at testpersonens billede af systemet når at ændre sig meget undervejs i opgaveløsningen. Det samme kan naturligvis ske med anvendelsen af concurrent tænke højt, men her er sandsynligheden noget mindre, idet testpersonen kun har lidt tid og ressourcer tilovers til at kunne fabrikere eller rationalisere sine kommenterer, parallelt med opgaveløsningen. Så her er faren nærmere, at testen resulterer i en lang række ufuldstændige og uforståelige sætninger, som observator siden skal analysere og få til at give mening (Ball, Dodd, Eger & Stevens, 2007).

I det hele taget kræver det mange ressourcer for testpersonen at verbalisere den kognitive proces, hvad enten det foregår samtidig med opgaveløsningen eller retrospektivt. Så det vil også være uetisk at udsætte testpersonen for både en tænke højt test og et efterfølgende retrospektivt interview, hvis vi tager udgangspunkt i Molichs regler for en vellykket testsession (Molich, 2007).

Ball, Dodd, Eger & Stevens vælger derfor i 2007 at lave et komparativt studie, hvor de empirisk tester, hvilken af de to tænke højt-metoder, som finder flest usability-problemer. Desuden tester de specifikt den retrospektive tænke højt-metode for både optagelser af testpersonens øjenbevægelser, optaget med en Tobii eyetracker, og optagelser af skærmbilledet alene (det er ikke noteret nogle steder, men vi forventer, at man får musens bevægelser at se oveni). Hver testperson udfører to tests af internetbrowsere, én med tænke højt og én med en af de to retrospektive tænke højt-metoder. Studiets konklusion er, at begge tænke højt-metoder faktisk finder lige mange usability-problemer, og de samme typer af problemer. Først når eye tracking bliver tilføjet, finder testpersonerne flere problemer. Hermed har de eftervist, at det fortsat i 2007 er acceptabelt, at man indenfor HCI betragter de to tænke højt-metoder som jævnbyrdige:

“If an important usability problem is identified by means of retrospective reporting, then it is not especially relevant whether the participant truly encountered the problem during the task or whether it came to mind retrospectively. The critical point is that the potential usability problem has been identified, so that the analyst can reflect on its nature, determine its generality, and

22

consider ways of improving the interface accordingly.” (Ball, Dodd, Eger & Stevens, 2007).

Ball et. al. ender i deres studie alligevel med at være fortalere for den retrospektive tænke højt-metode. Dette baseres på, at deres testpersoner fandt tænke højt “significantly more unpleasant”. Men det er også beskrevet i artiklens metodeafsnit, at observator mindede testpersonen om at tænke højt, så snart denne havde været tavs i 15 sekunder. Sæt dette sammen med, at de 24 testpersoner alle var unge mennesker, med en gennemsnitsalder på 26 år, og var frivillige deltagere fundet på en internetcafé. Testpersonerne falder dermed ind under den kategori, som Nielsen (1993) kalder for superbrugere: Brugere, som er meget positivt indstillet overfor computere og har fået særligt højt it-kendskab ved at bruge computere hyppigt og som underholdning i deres fritid. Vi forestiller os, at disse brugere er blevet ekstra irriterede over påmindelsen om at tænke højt, idet den forsinkelse, som verbaliseringsprocessen er skyld i (Ericsson & Simon, 1987), kommer til at betyde en proportionelt langsommere opgaveløsning i forhold til hvor meget hurtigere, brugeren ville kunne løse opgaven “intuitivt”, uden at den kreative proces konstant bliver inddelt i brudstykker af kravet om verbalisering og rationalisering (Nielsen, 1993).

I dette Speciale anvender vi concurrent tænke højt, fremfor retrospektiv tænke højt. Det vælger vi ud fra en betragtning om, at vores testpersoner både skal udføre opgaverne til vores usability-test og IR-evaluering. Det er bedre at lade dem lægge ekstra energi i usability-testen ved at tænke højt, end at bruge dobbelt energi på at gennemse hele optagelsen. Og vi ved af egen erfaring fra vores bachelor-opgave (Grøn & Johansen, 2008), at det tager minimum 50% længere tid at lave det retrospektive interview, end selve optagelsen er lang, netop fordi det tager længere tid at beskrive sine egne handlinger uddybende og besvare observators spørgsmål, end det tager at løse opgaverne i stilhed.

Vi kan dog ikke helt undgå et posttest-interview, da det ikke vil være gavnligt for tolkningen af testpersonernes handlinger og tænke højt-kommentarer, hvis observator sidder tilbage med ubesvarede spørgsmål, når testen er overstået. Dertil kommer, at vi er interesserede i at få besvaret en række komparative spørgsmål, som går på den personlige tilfredshed med to forskellige af Det Kongelige Biblioteks billedvisnings-systemer, vi tester for KB til brug udenfor REX. Det ville være uretfærdigt overfor det andet system i testen, hvis testpersonen udover at lære at bruge det, også skulle bruge test-tiden på at sammenligne det med det første system. Derfor er et posttest-interview uundgåeligt. Denne komparative test anvender vi dog ikke i dette Speciale, som er en test af REX alene.

2.5 Operationaliseret usability

Vi har nævnt ovenfor, hvordan det er op til den enkelte testleder at studere det system, der skal testes. Lære dets brugeres behov og adfærd at kende ved at observere dem bruge systemet (eller dets forgænger), og endeligt opstille de tasks, der bedst vil kunne belyse systemets usability-problemer, hvorefter task’ene kommer i brug i usability testen.

Men når det kommer til at udføre databehandlingen, analysere og konkludere på baggrund af disse tasks, er det begrænset, hvad der er at finde i litteraturen.

Vi gennemgår ISO 9241 part 11, “Guidance on usability”, en international standard som er kommet til at danne grundlag for moderne usability engineering (ISO 9241-11:1998,

23

Hornbæk 2005, Molich 2007). ISO-standardens tre kategorier kan med fordel udbygges til Nielsens fem usability-attributter (Nielsen 1993), som vi sammenligner med Molich’s udgave af samme (Molich, 2007) og med Quesenbery’s “The 5E’s” (Quesenbery, 2004). Ingen af disse kommer med nogen konkrete forslag til, hvordan det er muligt at operationalisere de forskellige usability-kategorier eller –attributter. Det gør derimod Hornbæk i sin undersøgelse af 180 nyere usability-studier. Hornbæk uddrager fra disse studier et sæt objektive og subjektive usability-mål, som konkret kan anvendes til at måle systemets usability. Til sidst gennemgår vi SUS, the “System Usability Scale”, et spørgeskema til subjektiv tilfredshed.

2.5.1a Guidance on usability, ISO 9241-11:1998International Organization for Standardization, ISO, har udgivet en standard for usability, som falder ind under ISO 9241 med titlen “Ergonomic requirements for office work with visual display terminals (VDTs)”. Som det lidt arkaiske navn antyder, blev ISO 9241 påbegyndt i begyndelsen af 1980’erne, mens den nuværende version af usability-standarden, “Part 11: Guidance on usability”, er fra 1998.

ISO 9241-11:1998 inddeler usability i tre kategorier: Effectiveness, Efficiency og Satisfaction. Eller på dansk: Effektivitet, effektivitet over tid og tilfredshed. De tre kategorier bliver defineret, og standarden beskriver hvilke underkategorier, de tre kategorier kan operationaliseres i.

Disse beskrivelser gives tre forskellige steder i dokumentet, og alle tre steder beskrives egenskaber ved alle de tre kategorier. Vi forsøger at ordne disse omtrent ni forskellige dele af ISO 9241-11:1998, ved at samle disse underkategorier og citere dem i punktopstilling:

Effectiveness is defined as the accuracy and completeness with which users achieve specified goals.o Accuracy can be measured by the extent to which the quality of the output corresponds

to the specified criteria.o Completeness can be measured as the proportion of the target quantity which has been

achieved.

Efficiency relates the level of effectiveness (accuracy and completeness) achieved to the expenditure of resources [with which users achieve goals].o Workload includes both physical and mental aspects of tasks.o For example, human efficiency could be measured as effectiveness divided by human

effort, temporal efficiency as effectiveness divided by time, or economic efficiency as effectiveness divided by cost.

Satisfaction measures the extent to which users are free from discomfort, and their attitudes towards the use of the product.o Satisfaction can be assessed by subjective or objective measures.o Objective measures can be based on observation of the behaviour of the user (e.g.

body posture, body movement, frequency of absences) or can be based on monitoring the physiological responses of the user.

o Subjective measures of satisfaction are produced by quantifying the strength of a user's subjectively expressed reactions, attitudes, or opinions. [For example] by using an attitude scale based on a questionnaire.

24

It is normally necessary to provide at least one measure for each of effectiveness, efficiency and satisfaction.

Herefter bliver ISO-standarden desværre vag i sin beskrivelse af, hvordan disse underkategorier konkret kan måles og analyseres: “The guidance includes procedures for measuring usability but does not detail all the activities to be undertaken.” (ISO 9241-11:1998). Den nævner dog som forslag fem situationer, hvor forskellige mål kan bruges, men da disse fem situationer viser sig at matche Nielsens fem usability-attributter fuldstændigt, gennemgår vi dem i stedet.

2.5.1b Nielsens fem usability-attributterUdover at placere usability i kontekst med utility og overordnet system-accept, udvider Nielsen begrebet usability til fem kategorier: Learnability, Memorability, Efficiency, (Few and noncatastrophic) errors og Subjective satisfaction. Learnability, memorability og efficiency afhænger af testpersonernes erfaring med systemet, der testes, og er derfor indbyrdes uforenelige.

Molich anvender en stort set identisk udgave af attributterne i sin bog fra 2007, som har den fordel frem for Nielsens, at de er koncist definerede, med en lang og en kort definition. Nedenfor er Molichs korte definitioner på blot tre ord givet i kursiv. Det er dog fortsat Nielsens (1993) beskrivelse, som er bedst og mest dybdegående beskrevet:

Learnability - Easy to learn: Hvor let systemet er at lære er altafgørende, idet alle brugere jo starter med at være førstegangsbrugere. Learnability måles som læringskurven for nybegyndere. Deres færdigheder over tid og effektivitet over tid forventes at ligge indenfor et defineret tidsrum, udvalgt til usability-opgaverne, for at learnability er høj nok.

Memorability - Easy to remember: Hvor nemt det er at huske, hvordan systemet bruges, har betydning for systemer, som kun benyttes sjældent, f.eks. rapporteringsværktøjer, der anvendes hvert kvartal. Og for brugere, som f.eks. vender hjem fra ferie eller barsel. Memorability måles bedst på testpersoner, som i et specificeret tidsrum ikke har anvendt systemet, men et laboratorieforsøg med memory tests kan også opstilles.

Efficiency - Efficient to use: Når brugeren når “steady state”, altså har opnået så stor færdighed med systemet, som denne har behov for i sin arbejdsfunktion, måles systemets efficiency, altså brugerens reelle effektivitet over tid. Hvis ingen ekspertbrugere kan skaffes til testen, er det muligt at køre nybegyndere op til ekspertniveau, ved at lade dem bruge systemet, til de når “steady state” og deres læringskurve flader ud.

Few and noncatastrophic errors - Easy to understand: Fejl defineres som enhver af testpersonens handlinger, som ikke leder til dét, testpersonen forventede, ville ske. Katastrofale fejl defineres som fejl, som testpersonen ikke kan vide foregår og derfor ikke kan tage forholdsregler mod, eller fejl som er så ødelæggende for opgavens løsning, at testpersonen kun med besvær kan fortsætte. Fejl måles ved at tælle dem.

Subjective satisfaction - Satisfying to use: Hvor behageligt det er at anvende systemet, uanset om det er til arbejds- eller hjemmebrug, er også en vigtig faktor, og den eneste af de fem attributter, som er subjektiv og ikke objektiv. Den nemmeste måde at måle

25

subjective satisfaction på, er ved at spørge, f.eks. mundtligt eller ved at anvende attitude-specifikke spørgsmål til at indsamle data, gerne udformet med Likert-skalaen.

Nielsen (1993) skriver, at disse fem attributter stammer fra traditionel usability metode. Men Nielsen er sidenhen blevet kendt som ophavsmand for dem (Quesenbery, 2004).

Der findes også andre udgaver af disse fem kategorier. Whitney Quesenbery (2004) har forsøgt at gøre dem nemmere at huske (og mere tidssvarende), ved at omskrive de fem begreber med ord, som alle begynder med E. Metoden, som Quesenbery kalder “The 5Es”, bliver dermed til Effective, Efficient, Engaging, Error tolerant og Easy to learn, i hendes egen rækkefølge.

Det er diskutabelt, om det lykkes Quesenbery at gøre begreberne mere tidssvarende. De 5 E’er ser helt bort fra Memorability og bruger i stedet Effectiveness, hvilket betyder, at gruppen af tilbagevendende brugere helt er udeladt. Quesenberys beskrivelse af de fem punkter tilføjer intet nyt i forhold til Nielsen, måske med undtagelse af, at Nielsens begreb Subjective satisfaction med begrebet Engaging drejes hen imod moderne, interaktive systemer, som i højere grad kræver brugerens deltagelse, end computersystemer gjorde, da Nielsens skrev sine attributter ned i 1993.

Nielsens fem attributter forekommer noget nemmere at operationalisere end ISO 9241-11:1998 ovenfor, men ét mål for hver af de tre mulige attributter (vi kan kalde dem brugeradfærd, fejl og tilfredshed) for et usability-eksperiment, det er stadig ikke nok.

2.5.1c Hornbæks objektive og subjektive usability-målNår der i litteraturen ikke gives forslag på konkretiserede, operationaliserede usability-metoder, må man i stedet undersøge, hvad andre forskere har gjort, og hvilke metoder der ser ud til at have vundet præcedens. Dette er, hvad forskeren Kasper Hornbæk har gjort i 2005, hvor han publicerede en artikel, der sammenligner 180 forskellige usabitity-studier publiceret i anerkendte tidsskrifter indenfor HCI:

“We review current practice in measuring usability by categorizing and discussing usability measures from 180 studies published in core HCI journals and proceedings. The discussion distinguish several problems with the measures, including whether they actually measure usability, if they cover usability broadly, how they are reasoned about, and if they meet recommendations on how to measure usability.” (Hornbæk, 2005).

Artiklen har således to funktioner. Den første er at udvælge og organisere alle de measures (herefter kaldet mål) fra de 180 studier, som er blevet vurderet til at måle usability, og præsentere dem skematisk, inddelt i Measures of effectiveness, Measures of efficiency og Measures of satisfaction, altså kategorierne fra ISO 9241 part 11 (Hornbæk, 2005).

Artiklens anden funktion er at forholde sig kritisk til studiernes anvendte metoder, fremhæve gode og mindre gode eksempler og diskutere, hvordan man bedst tager højde for en række faldgruber i sit eksperiment. Disse udfordringer er inddelt i følgende afsnit, ganske kort opridset: Forskellen på objektive og subjektive mål. Hvordan learnability måles i læring og fastholdelse af lærdommen. Hvordan eksperimenter udføres over længere tid end blot nogle timer. Vanskeligheden ved at komme til enighed om de mål, som falder under satisfaction. At finde og cementere ægte korrelationer imellem mål. Og til sidst, at skelne mellem mål, som

26

analyserer systemet på mikro- og makro-niveau. Dette Speciale foregår på Mikro-niveau, idet vi måler f.eks. delopgaver løst, søgninger udført, funktioner afprøvet eller antal museklik målt indenfor korte tidsrum á sekunder eller minutter. Makro-niveau bruges i længerevarende studier, og måler f.eks. livskvalitet, indlæring, kreativitet og social kompleksitet udført periodisk i dage, uger eller år (Hornbæk, 2005).

I bilag 2 til 5 er vedlagt de fire tabeller, i hvilke Hornbæk organiserer sine mål. De begynder ved Tabel 2, da Tabel 1 ikke viser usability-mål. Tabel 2 er Effectiveness-mål, Tabel 3 er Efficiency-mål og Tabel 4 er Satisfaction-mål. Tabel 5: “Specific Attitudes” er en uddybende tabel for et specifikt satisfaction-mål fra tabel 4, punkt 3e.

Tabellerne rummer fra Hornbæks hånd ingen nummerering i punkter og underpunkter. Muligvis fordi læseren ikke skal få det indtryk, at målene er listet i rangorden. Vi henviser til hvert mål udfra Tabel 2 til 5, og derudover har vi tildelt hvert punkt et nummer og hvert underpunkt et alfanumerisk nummer.

Et eksempel: Tabel 3.1c betyder, at målet er beskrevet i Tabel 3: Efficiency, 1) at det er det første punkt i tabellen, og c) at det er det tredje underpunkt til punkt 1. Nogle punkter har ingen underpunkter.

Vores bilag 2-5 adskiller sig dermed fra Hornbæks egne grafer ved, at vi har indsat denne nummerering i venstre margen af hver tabel. Vi har også klippet Tabel 4 sammen, så den i bilaget står på én side, hvor den i artiklen er indsat i bunden af en side, så den breder sig til den følgende side. Det samme gælder Tabel 5. Men udover det grafiske, har vi ikke lavet ændringer i tabellerne.

Vi anvender tre af Hornbæks 12 effectiveness-mål og fire af de 13 efficiency-mål. Disse mål er grundlæggende indenfor usability engineering og kan fortolkes meget bredt, så de kan tilpasses hver enkelt af vores usability-opgaver.

Effectiveness: Tabel 2.1, “Binary task completion” Tabel 2.2a, “Error rate” Tabel 2.4, “Completeness”

Efficiency: Tabel 3.1a, “Task completion time” Tabel 3.1c, “Time until event” Tabel 3.3a, “Use frequency” Tabel 3.7, “Other”, som vi definerer yderligere til:

o Antal funktioner afprøveto Antal søgninger udført

Satisfaction:Til at måle satisfaction bruger vi Brooke’s SUS-spørgeskema, som beskrives i næste afnit, hvis 10 spørgsmål falder ind under Hornbæks mål, Tabel 4.3b, “Content dependent questions”.

“Completeness” og “Time until event” bruger vi til at inddele vores opgaver i stadier, så vi kan kortlægge, hvilke(n) del(e) af REX, som volder problemer i opgaveløsningen.

Indenfor IR og Biblioteks- og Informationsvidenskab skal man i øvrigt være varsom med målene Tabel 2.2c, “Precision” og det efterfølgende mål, Tabel 2.3, “Recall”, idet

27

Precision følger definitionen indenfor IR, mens Recall afviger betydeligt fra definitionen indenfor IR. I Hornbæks artikel er Recall defineret som, hvor meget testpersonen kan huske og genkalde sig fra det testede system, når testen er færdig.

Vi bruger derfor udelukkende målet “Efficiency, other” til at angive søgeadfærd, som ikke ellers er dækket i Hornbæks artikel. Vi underinddeler i, hvor mange gange REX’s forskellige funktioner bliver afprøvet (Hornbæk angiver selv denne kategori til Antal funktioner), og hvor mange søgninger testpersonen har udført for at løse hver opgave.

2.5.1d System Usability Scale, SUSBåde ISO 9241-11:1998, Nielsen og Hornbæk anbefaler som nævnt i de ovenstående afsnit, at Subjective satisfaction måles ved at anvende et eksisterende spørgeskema med attitude-specifikke spørgsmål, helst udformet med Likert-skalaen. ISO-standarden kommer ikke med konkrete forslag. Nielsen (1993) nævner QUIS (“Questionnaire for User Interface Satisfaction”), fra 1988, men advarer dog om, at den med sine 27 spørgsmål er meget lang. Hornbæk (2005) henviser til QUIS og SUMI (“Software Usability Measurement Inventory”), fra 1995.

Vi vælger dog et helt tredie spørgeskema, the System Usability Scale, oftest forkortet SUS, som er udviklet omkring 1986 af John Brooke som et led i “integrated office systems development at Digital Equipment Co. Ltd.” (Brooke, 1996). I 1996 publicerede Brooke SUS og gjorde skalaen frit tilgængelig (Brooke, 1996), og det har vist sig, at SUS-skemaet fortsat er konkurrencedygtigt:

"Recent research (Tullis & Stetson, 2004) has shown the SUS to provide superior assessments of website usability, compared to other questionnaires (for example, QUIS, CSUQ). Additionally, it has been found to have a 0.8588 correlation with the 50-item SUMI questionnaire (Holyer, 1993)." (Finstad, 2006).

Alle spørgsmål er formuleret efter Likert Skalaen, en psykometrisk skala, som udgøres af summen af spørgeskemaets spørgsmål, “Likert emnerne” (af engelsk “items”). Spørgeskemaets emner er udformet som udsagn (statements) frem for spørgende sætninger, og testpersonen besvarer hvert emne ved at evaluere udsagnet i forhold til sin egen tilstand (Likert, 1932). Spørgsmålene besvares bipolært, altså enten positivt eller negativt, på ud fra fem, syv eller ni svarmuligheder, hvor fem er det mest udbredte, udformet som:

1. Strongly disagree2. Disagree3. Neither agree nor disagree4. Agree5. Strongly agree

Likert er en summativ skala, idet Likert emnerne kan analyseres hver for sig eller i sammenhængende grupper (summativt), alt efter hvordan spørgeskemaet er udformet. Brooke (1996) påpeger, at det ikke giver mening at analysere SUS-spørgsmålene individuelt.

Brooke kalder sin skala for "a quick and dirty usability scale", som hurtigt giver et globalt overblik over testpersonernes subjektive usability-vurderinger, og som blev udviklet til at kunne bruges i alle situationer (i usability-testningen af office systems), uden at behøve at tage hensyn til den specifikke tests testpersoner eller til det testede systems brugergruppe

28

og fysiske, organisatoriske og sociale miljø. En sådan skala er desuden i stand til at sammenligne på tværs af systemer:

"Often, all that is needed is a general indication of the overall level of usability of a system compared to its competitors or its predecessors. Equally, when selecting metrics, it is often desirable to have measures which do not require vast effort and expense to collect and analyse data." (Brooke, 1996).

Hvert andet spørgsmål er stillet som en positivt ladet sætning, såsom "I thought the system was easy to use", og hvert andet med en negativt ladet sætning, såsom "I found the system unnecessarily complex". Ideen med dette er, at det gerne skulle tvinge testpersonen til at tænke over hvert svar og dermed forhindre besvarelser, hvor respondenten sætter kryds i samme søjle hele vejen igennem spørgeskemaet. Systemets Overordnede Usability beregnes med værdierne fra alle 10 spørgsmål.

Ti år efter Brooke publicerede SUS-spørgeskemaet, har Kraig Finstad lavet en test af SUS på internationale testpersoner med andet modersmål end engelsk, på medarbejdere fra “Intel Corporation” af forskellig nationalitet, 18 testpersoner fordelt på syv nationaliteter. Finstad konkluderer, at ni af spørgeskemaets ti spørgsmål var forståelige for alle testpersonerne og gav konsistente svar. Spørgsmål 8, derimod, anvender ordet “cumbersome”, som 50% af testpersonerne ikke forstod, før det blev oversat af observator til “awkward” (Finstad, 2006).

Vores egen erfaring med at anvende SUS-spørgeskemaet gav dog et noget andet billede. Vi anvendte spørgeskemaet i vores Bachelor-projekt, som var en usability-test af en ny internetbrowser (Grøn & Johansen, 2008). Vores testpersoner var mellem 19 og 36 år gamle og havde som minimum en gymnasial uddannelse. Alligevel havde størstedelen problemer med at forstå flere af spørgsmålene, ikke kun spørgsmål 8, og vi endte med at kassere SUS-testens Overordnede Usability-værdi, fordi vi ikke kunne stole på, at testpersonerne havde forstået spørgsmålene ens (og på samme måde som os).

Da vi i dette speciale ønsker at være helt sikre på, at hver testperson har tolket spørgsmålene på samme måde, og at de har forstået dem på samme måde, som vi selv har – og da vi anvender testpersoner, som i gennemsnit er 30 år ældre end dem i vores Bachelor-projekt - vælger vi at oversætte SUS-spørgeskemaet til dansk. Oversættelsen er foregået så direkte som muligt, som det kan ses, hvis man sammenligner bilag 6 og 7. Denne beslutning betyder, at vi går på kompromis med den Overordnede Usability-værdis evne til at blive sammenlignet med andre systemer.

2.5.2 I dette Speciale

Som nævnt i afsnit 2.5.1b: Nielsens fem usability-attributter, inddeler Nielsen (1993) usability i fem attributter, som passende kan anskues som tre kategorier: Brugeradfærd, fejl og tilfredshed. Brugeradfærd dækker over de første tre attributter, Learnability, memorability og efficiency, som måles på tre forskellige typer brugere, nemlig nybegyndere, sjældent tilbagevendende brugere og ekspert-brugere. I vores eksperiment bruger vi førstegangsbrugere til at teste REX, og vores studie falder derfor ind under Learnability. Vi

29

anvender også de sidste to attributter: (Few and noncatastrophic) Errors og Subjective Satisfaction.

De tre kategorier fra ISO 9241-11:1998, Effectiveness, efficiency og satisfaction, bliver automatisk inddraget i vores databehandling, når vi anvender Hornbæks usability-mål, som er inddelt i de samme tre kategorier. Vi udvælger tre specifikke effectiveness-mål og fire speficikke efficiency-mål til vores test.

ISO-kategorien Satisfaction og Nielsens attribut Subjective Satisfaction er identiske. Vi følger den anbefaling, som gives af både Nielsen (1993), ISO 9241-11:1998, Hornbæk (2005) og Molich (2007), og bruger et eksisterende og gennemtestet spørgeskema til at indsamle kvantitative data om testpersonernes subjektive holdninger til systemet (Kvalitative data indsamler vi med tænke højt-metoden under testen og i post test-interviewet). Vi anvender Brooke’s SUS-spørgeskema, som er overskueligt og har høj statistisk troværdighed i forhold til længere, mere avancerede spørgeskemaer. Vi oversætter spørgeskemaet til dansk, hvilket delvist kompromitterer vores data i forhold til at sammenligne med lignende undersøgelser og SUS-værdier, men som til gengæld hæver niveauet af fælles forståelse af spørgsmålene for både afsender (testopstillere) og modtager (testpersonerne).

2.6 Information Retrieval (JBJ)

I dette afsnit introducerer vi Information Retrieval (IR) ved at præsentere enkelte, udvalgte modeller. Derefter gennemgår forskellige studier inden for IR-området, herunder også studier indenfor IR evaluation. Vi afslutter denne del af kapitel 2: Anvendt teori (fælles) med at redegøre for relevans.

Hvor usability engineering omhandler brugervenlighed og brugergrænserflader, forsker Information Retrieval i systemet bag brugergrænsefladen. Sat i kontekst til vores Speciale, handler IR om at optimere søgeprocessen, og usability om at optimere brugerens oplevelse.

2.7 Hvad er Information Retrieval?Kernen i IR er forskning i præsentation, organisation og adgang til information. Forskningen i IR indeholder, ifølge Baeza-Yates & Ribeiro-Neto (1999) :

“… modeling, document classification and categorization, systems architecture, user interfaces, data visalization, filtering, languages, etc.” (Baeza-Yates & Ribeiro-Neto, 1999, side 2)

Formålet med IR er at forske i og forstå IR processer, så det er muligt at designe, bygge og teste systemer, som gør information let tilgængelig for alle typer brugere, uanset informationsbehov (Ingwersen, 1992).

Modellen nedenfor viser IR i sin simpleste form:

30

Documents

Represen-tation

Database

SearchRequ0est0

Query

Matching

Represen-tation

QueryResult

EvaluationResultEvaluation

Relevance assessment

Recallbase

Context

Figur 3: Simpel model af IR (Ingwersen, 1992, side 49).

Kassen til venstre indeholder information, præsenteret i form af indekseringstermer, bibliografisk post, fuld-tekst dokument, o. lign. Kassen til højre indeholder en informationsbehov formuleret i søgetermer i form af en query, natural language, o. lign. Kassen i midten indeholder en ”matching function”, som har til opgave at parre informationsbehovet med relevant information. Det er klart, at tre kasser og to pile er en meget simpel udgave af hele IR processen.

2.7.1 LaboratoriemodellenNedenstående laboratoriemodel er taget direkte fra undervisningsmateriale udarbejdet af Peter Ingwersen i forbindelse med faget ”Information Retrieval Theories” fra efteråret 2009. En anden afbildning af modellen kan findes i Ingwersen & Järvelin (2005). Modellerne er ens i indholdet og begreber, de eneste forskelle er selve billedet af mennesket, som i vores model har en krop. Derudover er begrebet context en del af vores model. Vi ser laboratoriemodellen som indbegrebet af IR, fordi den indeholder alle de elementer, som vi undersøger i Specialet.

Figur 4: Laboratoriemodellen (Ingwersen & Järvelin, 2005)

31

Laboratoriemodellen (Figur 4) indeholder naturligvis elementer fra Figur 3, denne gang i form af begreberne documents, search og matching. Modellen har sin oprindelse i Cranfield II-studiet fra 1960’erne, dengang hvor IR havde sit fokus på laboratorie-forskning og anvendte fiktive brugere i lukkede scenarier og test-databaser. I nyere tid har forskningen undergået en revolution og flyttet fokus over på brugerne og deres informationsbehov, derfor blev et menneske tilføjet modellen (Ingwersen & Järvelin, 2005).

Laboratoriemodellen viser, hvordan IR processen virker. Vi anvender REX/Primo som eksempel. En bruger har et informationsbehov, altså et hul i sin viden, som vedkommende vil have tilfredsstillet. Brugeren udtænker sine søgeord og indtaster sin query i REX/Primo. Databasen indeholder naturligvis forskellige dokumenter, som er repræsenteret i form af bibliografiske poster. Når queryen er indtastet, går systemet i gang med at matche query’en med dokumenter fra databasen.

Laboratoriemodellen kan også kaldes hule-modellen. Man skal forestille sig, at man står som brugeren ude i solen og kigger ind i en mørk hule. Solen er konteksten, altså kilden til det informationsbehov som er opstået hos brugeren. Solen skinner ned på det, som brugeren kan se. Resten ligger hen i sort mørke og kan ikke ses af brugeren. Ligesom når man normalt ville søge i eksempelvis REX/Primo, så kan man ikke se hvordan systemet behandler en query og giver et søgeresultat ud fra søgeordene. (Ingwersen & Järvelin, 2005).

2.7.2 De tre revolutioner i Information Retrieval

Revolutionerne i IR kaldes også for ”research approaches”. I vores speciale har vi valgt at kalde dem for revolutioner, fordi de er meget end bare tre måde at se på forskningen i IR på. Efterhånden som de kom til, revolutionerede de hver for se IR-forskningen, de fik forskningen til at udvikle sig og tage en ny drejning. Derfor kalder vi dem revolutioner (Ingwersen, 1992). Der findes tre revolutioner:

Traditional User-oriented Cognitive

Figur 5 nedenfor giver et overordnet indtryk af, hvad de tre revolutioner handler om indenfor fire forskellige områder (kolonnen længst til venstre); mål og fokus, resultater, forståelse af information, samt teoretisk metoder og instrumenter. Figuren er taget direkte fra Ingwersen (1992), side 58:

32

Den traditionelle revolution fokuserede på at indeksere og klassificere dokumenter, så de kunne genfindes via automatiserede processer. Alting blev foregik i lukkede laboratorie-forsøg, hvor man målte performance af systemer (Ingwersen, 1992). I laboratorie-modellen (jf. afsnit 2.7.1) er den traditionelle revolution repræsenteret i alle de elementer, som har med systemet at gøre, altså alle elementerne som findes i venstre side.

Den bruger-orienterede revolution fokuserede på søgeadfærd hos virkelige brugere. Alting blev testet, som om det foregik ude i den virkelige verden, hvor real-life situationer kunne opstå. Dette er stik modsat den traditionelle revolution, hvor man ikke skænkede virkelige brugere en tanke (Ingwersen, 1992). I laboratorie-modellen er den bruger-orienterede revolution repræsenteret i form af brugeren ude i højre side.

Den kognitive revolution fokuserer ikke kun på brugere, men på mennesker generelt. Denne revolution ser på alle de informationsprocesser og interaktioner, som et menneske kan generere eller har til hensigt at generere (Ingwersen & Järvelin, 2005). Den kognitive revolution er repræsenteret i form af kontekst-solen, som giver brugeren et informationsbehov og derfor begynder at interagere med systemet.

Vores speciale tager udgangspunkt i den kognitive revolution, hvor vi især fokuserer på, at Interactive Information Retreival (IIR), som handler om, at IR er en interaktiv proces for den enkelte bruger. I indledningen præsenterede vi ”spaceship”-modellen (jf. afsnit 2), som illustrerer, hvor og hvordan interaktionen mellem bruger og system foregår.

Figur 5: Oversigt over de tre IR revolutioner (Ingwersen, 1992).

33

2.8 Information Retrieval Evaluation

Information Retrieval Evaluation (IR evaluering) begyndte oprindeligt med undersøgelser af OPAC-systemer og ekspert-systemer, hvor det handlede om at undersøge, hvorvidt et system overhovedet fungerede (Saracevic,1992). Formålet med at foretage IR evaluering er, at undersøge og måle performance af et givent system. Mens usability handler om brugerens oplevelse af f.eks REX/Primo, handler IR evaluering mere om søgemaskinen inde bagved.

Ifølge Robertson & Hancock-Baulieu (1992) har der været tre revolutioner inden for evalueringsprocesser i IR:

• Relevance• Cognitive• Interactive

Relevans-revolutionen handlede om, at et informationsbehov ikke var det samme, som at foretage en søgning, altså en ”search request”. Man måtte derfor begynde at opfatte informationsbehovet, som baggrunden for en relevansvurdering og ikke, som hidtil antaget, at ”search request” var baggrunden. Med andre ord, så måtte man tager hensyn til, at der foregik en form for ”mental activities” hos søgeren inden vedkommende formede søgeordene.

Den kognitive revolution tager primært udgangspunkt i Belkins ASK, som er forkortelsen for ”Anomalous State of Knowledge”, hvilket betyder, at en person har et unormalt vidensniveau, et form for hul i sin viden. Systemer blev derefter opfattet som en interaktiv process for personen, hvor vedkommende kunne indtaste et input. Resultatet ville herefter være med til at ændre personens ”state of knowledge”.

Den interaktive revolution handler om, at systemer nu er blevet mere interaktive. Det er ikke længere end bedrift i sig selv, at man kan indtaste noget i et system og få et resultat. Man må i stedet forvente, at brugere foretager flere søgninger i et system, eller modificerer deres søgninger, for at få mere viden om et emne (Robertson & Hancock-Baulieu, 1995).

Saracevic (1992) har en liste med 5 punkter, som han mener SKAL indgå i en evaluering:1. a system together with a process2. a criterion or criteria3. measure(s)4. a measuring instrument(s)5. methodology

Der skal naturligvis være et system, som er emnet for evalueringen. Systemet kan være en prototype eller den ægte vare. Derudover, skal der være et mål med testen, eller et formål med systemet i sig selv. I en IR evaluering skal der også være noget at måle, det kan være recall og precision eller performance. Dertil kommer naturligvis måleinstrumenter, som skal bearbejde dataene og operationalisere disse. Metoden og forskningen bag IR evalueringen skal være klar. Man skal kunne forklare hvad man gør og hvordan man gør det.

Vi foretager en IR evaluering af REX/Primo og dens rankingalgoritmen. Formålet med REX/Primo er, at se hvor godt relevansalgoritmen performer. Dette vil vi undersøge ved at lade testpersoner relevansvurdere 90 forskellige bibliografiske poster, som vi finder til dem.

34

Vi anvender Cumulated Gain og Mean Reciprocal Rank til at måle hvor godt relevanalgoritmen fungerer. Vi laver tre forskellige Work Tasks og foretager søgninger, hvor vi finder i alt 90 poster fordelt på de tre tasks. Vi beder derefter vores testpersoner om at relevansvurdere disse poster.

2.9 Information Retrieval studier

Der findes mange IR studier, især når det handler om IR evaluering. I dette afsnit vil vi kort opridse de studier og workshops, som vi har taget inspiration fra.

2.9.1 Cranfield I

Første gang IR evaluering for alvor startede var med Cranfield I tilbage i 1957 og blev styret af Cleverdon. Cranfield I havde til formål at sammenligne fire indekseringssystemer. Chowdhury nævner to ting, som Cranfield 1 var med at fremhæve:

"Firstly it identified the major factors that affect the performance of retrieval systems. Secondly it developed for the first time the methodoligies that could be applied successfully in evaluation of information retrieval systems." (Chowdhury, side 258, 2004)

Derudover kunne det konkluderes ud af resulaterne fra Cranfield at precision og recall er de to vigtigste parametere, når man skal måle performance af et system, og at disse parametre er tæt knyttede. (Chowdhury, 2004).

Precision handler om at få så mange relevante dokumenter som muligt ud af en søgning, uden at få noget støj, altså ingen ikke-relevante dokumenter. Recall handler om at få alle relevante dokumenter, men dette kan ikke gøres uden også at få støj. Man kan ikke have begge dele i en database, så man er nødt til at skrue på knapperne for at få den indstilling som passer bedst til databasen. Man er nødt til at tage stilling til, om man vil have mange poster i sit søgeresultat og dermed risikere at få meget støj. Eller om man vil have få men meget relevante dokumenter (Morville & Callender, 2010).

2.9.2 TREC

TREC er forkortelsen for Test REtrieval Conference og gør det muligt for forskere at mødes og samarbejde på tværs af landegrænser, hvor de kan undersøge og teste den samme ”test collection” og bagefter sammenligne resultater og udveksle viden. TREC har en stor test collection, hvilket betyder, at databasen indeholder mange forskellige dokumenter, som dækker mange forskellige emner. Test collection’en er bliver styret af the National Institute of Science and Technology (NIST) i USA. TREC har fire formål (punktopstilling citeret fra Voorhees & Harman, 2005, side 5):

35

To encourage retrieval research based on large test collections. To increase communication among industry, academia, and government by

creating an open forum for the exchange of research ideas. To speed the transfer of technology form rearch labs into commercial products

by demonstrating substantial improvement in retrieval methodologies on real world problems.

To increase the availability of appropriate evaluation techniques for use by industry and academia, including development of new evaluation techniques more applicable to current systems.

TREC havde den første konference i 1992 og antallet af deltagende organisationer og forskningsinstitutioner er steget stødt siden da. Der er kommet mange gode resultater ud af TREC (Chowdhury, 2004) . Her i specialet anvender vi værktøjerne Mean Reciprocal Rank (MRR) og Cumulated Gain (CG), som begge første gang blev præsenteret og afprøvet i forbindelse med TREC.

2.9.2a PoolingDet som vi har lagt mest mærke til hos TREC, er brugen af pooling. Harman forklarer hvordan pooling fungerer med disse ord:

“For each topic within a set og results, the top X-ranked documents were selcted for input to the pool. These results were merged acress all systems and sorted by document numbers, and then dublicate documents were removed” (Harman, side 33, 2005).

Pooling er med andre ord, at foretage forskellige søgninger efter samme emne. Man vælger et antal dokumenter indenfor den øverste og bedste ranking og samler dem i en pulje i et stort bassin. Når alle resultaterne er samlet for det pågældende emne, så sorterer man dokumenterne efter deres ID-nummer og fjerner de dokumenter, der er flere af. Alt dette er processen for hvordan man pooler dokumenter. Denne dokumentsamling kan man så kalde sin ”test collection” og eksperimentere med.

Vi anvender ikke pooling i vores speciale, fordi vi mente, at det ville være for tidskrævende i forhold til, at vi kun skal bruge denne ”test collection” en enkelt gang. Hvis nogen andre allerede havde anvendt pooling i REX/Primo, så ville vi have brugt deres dokumentsamling. Vi har i stedet valgt at lave tre forskellige Work Tasks og søge én enkelt søgning til hver af ud fra en søgestreng, som vi mener en normal bruger selv vil kunne forstå og anvende.

36

2.9.3 INEX

Jeanette Mai-Britt Jensen opsumerer ganske kort, hvad INEX handler om:

“INEX (INitiative for the Evaluation of XML retrieval) startede i 2002 og er et international koordineret samarbejde til fremmelse af forskning I forbedring af IR-processer og evalueringsprocedurer for indholdsbaseret ad hoc XM-retrieval. INEX stiller en XML-dokumentsamling til rådighed sammen med topics og relevansbedømmelser, som deltagende institutioner kan anvende til eksperimenter”. (Jensen, 2007, side 26-27).

INEX har især fokus på relevans og relevansvurderinger, hvor de har lavet deres helt egen skala, som ikke er liniær men i stedet formet som et T.Vi præsenterer T-skalaen i afsnit 5.5: Relevansskala, men forklarer samtidig, hvorfor vi ikke anvender denne skala. Herunder viser vi relevanskategoriernes navne (Malik, Tombros & Larsen, 2007):

Relevant Relevant, but too broad Relevant, but too narrow Partial answer Not relevant

INEX har i de seneste år anvendt Wikipedia som deres test collection. Dertil har de udviklet en række forskellige Search Tasks, som testpersonerne skal forsøge at besvare. Når testpersonerne har foretaget en søgning, har de også mulighed for at relevansvurdere hele eller dele af fuld-tekst-dokumentet. Derudover har INEX en række spørgeskemaer, som testpersonerne bliver bedt om at besvare i løbet af testen (Malik, Tombros & Larsen, 2007). Vi anvender dele af deres spørgeskema som hedder “Pre Task Questionnaire”. Dette beskriver vi nærmere i afsnit 5.2: Pre Task-spørgeskema.

2.10 Relevans

Relevans er et stort forskrningsområde, hvor mange forskere har deltaget, men pladsen i vores speciale er begrænset. Derfor kan vi desværre ikke gå så meget i dybden med emnet, som vi ønsker. Der er kun plads til at fremhæve et lille udvalg af forskere, som har arbejdet med relevans, og som ligger til grundlag for vores perspektiv på relevans.

Relevans er et komplekst emne indenfor IR. I 1960'erne og 1970'erne opstod der fokus på relevans for første gang. Derefter tabte forskere langsomt interessen for forskningsområdet indtil det blev genoplivet i 1990 af Shamber, Eisenberg og Nilan (Ingwersen & Järvelin, 2005).

37

Schamber, Eisenberg & Nilan (1990, s. 774) konkluderede tre ting omkring relevans:

“Relevance is a multidimensional cognitive concept whose meaning is largely dependent on users perceptions of information and their own information need situations;

Relevance is a dynamic concept that depends on user's judgements of quality of the relationship between information and information need at a certain point in time;

Relevance is a complex but systematic and measurable concept if approached conceptually and operationally from the user's perspective.”

Summa summarum, relevans er komplekst, men det kan måles, hvis en undersøgelse tager udgangspunkt i brugerens synspunkt og dermed også tager højde for, at relevans er dynamisk og en subjektiv holdning.

Ifølge Borlund (2000), er relevans det primære testmetode, når man foretager IR evaluering. Afprøvning og indsamling af relevans kan også anvendes til mange beregninger. I vores speciale anvender vi Mean Reciprocal Rank og Cumulated Gain. Begge instrumenter tager udgangspunkt i relevansvurderinger.

Der findes mange forskellige indgangsvinkler til relevans. Utallige forskere har deltaget i debatten om hvad relevans egentlig er for en størrelse og om hvilke kriterier en testpersoner anvender, når han / hun skal relevansvurdere et dokument.

Vi har valgt at fokusere på, at relevans er dynamisk, sådan som Schamber, Eisenberg & Nilan beskriver det ovenfor. Vi ser på relevans som et dynamisk fænomen, fordi at en persons opfattelse af hvad der er relevant kan ændre sig i løbet af en søgning. Man kan tale om, at der sker en ændring i personens ”cognitive state of mind”, hvor en persons indsigt i et emne ændrer sig og derved kan hele synet på et givent emne ændre sig (Borlund, 2000). Vi forventer derfor, at vores testpersoner skifter mening om deres relevansvurderinger undervejs.

Spink, Greisdorf & Bateman (1998) foretog et eksperiment, hvor de undersøgte hvorfor relevans kan være dynamisk. Her kom de frem til, at personer oftest lærer mest fra de dokumenter, som er delvist relevante. Når dokumenter er relevante, så vil de ofte kun repræsentere den information, som en person allerede kender. Et delvist relevant dokument kan derimod indeholde yderligere information, som ændrer personens ”cognitive state og mind”.

Vi fokuserer også på situationel relevans, som handler om, hvad intentionen er med den fundne information. Hvis man skal bruge et kort over vejene i Tyskland, fordi at man ikke kan finde Berlin, og kun finder et kort over centrum af Berlin, så er dette kort ikke relevant, fordi at informationsbehovet i pågældende situation er en helt anden, men derfor kan det fundne godt blive relevant senere når man har fundet vej til Berlin og nu skal navigere rundt i centrum.

”…situationel relevance is a user-centred, empirically-based and realistic as well as dynamic type of relevance.” (Borlund, 2000).

Den situationelle relevans tager dermed også højde for, at relevans er dynamisk. Den situationelle relevans er bruger-orienteret, hvilket passer helt perfekt ind i vores kontekst, hvor vi vil se alting fra fra brugernes perspektiv. Vi ønsker at anvende situationel relevans i et kontrolleret miljø, hvor vi giver vores testpersoner deres informationsbehov via en “simulated Work Task”

38

3 METODE I EKSPERIMENTET (FÆLLES)

I de følgende afsnit gennemgår vi dataindsamlingen i eksperimentet i detaljer, således at eksperimentet ville kunne eftergøres efter vores anvisninger.

De samme regler gælder for usability engineering, som gælder for alle videnskaber: Fremfor alt skal den viden, der fremskaffes empirisk/eksperimentelt, have nøjagtighed, validitet og pålidelighed. Nøjagtighed (engelsk: accuracy) er i ordets bogstavelige forstand, med hvor stor præcision og opmærksomhed eksperimentet udføres. Validitet (engelsk: validity) får eksperimentet, når det metodologisk afspejler virkeligheden udenfor laboratoriet. Eksperimentet vinder pålidelighed (engelsk: reliability), i det øjeblik, det kan gennemføres af en udenforstående fagmand udfra eksperimentets forsøgsbeskrivelse, og denne er i stand til at komme frem til samme resultat og således eftervise det (Dermed naturligvis ikke sagt, at det er et krav at gennemføre en usability test to gange).

3.1 Testopbygning

Eksperimentet består af to dele i form af en usability test og en IR evaluering. Usability testen er igen inddelt i to dele i form af en opgaveløsning med tænke højt og et post test-interview. IR evalueringen er inddelt i tre Work Tasks. Helt simplificeret er formen:

Spørgeskema Usability test Spørgeskema Usability interview Spørgeskema IR evaluering

Herunder beskrives testsessionen for en enkelt testperson som et scenarie med klokkeslæt. Vi kalder det et scenarie, fordi hvert punkt viser vejledende tider.

10.00 Velkomst.Pre Test-spørgeskema udfyldes (demografiske data).Introduktion til usability testen og til tænke højt-metoden.

10.10 Usability test, opgave 1 til 5 løses i REX.10.25 Post test-spørgeskema om REX udfyldes, herunder et SUS-spørgeskema.10.35 Usability test opgave 6 og 7 udføres i to forskellige af KB’s online billedbaser.10.45 Post test-spørgeskema, tillæg omkring opgave 6 og 71.10.50 Post test-interview, 15 min. om REX, 10 min. om billedbaserne.11.20 Op til 10 minutters pause.

Introduktion til IR evalueringen, de udførte Search Tasks og testpersonens Work Tasks.11.30 IR evaluering, tre Work Tasks, hver indledt med et pre task-spørgeskema.12.00 Testpersonen får en lille erkendelse som tak for hjælpen og følges ud af universitetet.

1 De data vi har indsamlet i KB’s billedbaser, har ikke noget med dette Speciales test af REX’ performance at gøre, og vil derfor ikke blive behandlet i Specialet. De henlægges til et komparativt studie i den rapport, vi udfærdiger til KB i juli-august. Vi vender kort tilbage til disse data i afsnit 8: Perspektivering.

39

3.2 Opsætning af testmiljø og system

Testen udføres i Danmarks Biblioteksskoles “Lille Usability-Laboratorium”, et kontor på 5 gange 4 meter. Et foto af testopsætningen ses i Figur 6. Observator 1, JBJ, sidder placeret ved sit eget bord skråt bag ved testpersonen, så det ikke virker på vedkommende, som om man bliver overvåget.

Observator 1’s rolle er at vurdere, hvilke af testpersonens spørgsmål, det er sikkert for hende at besvare; at tage tid på usability-opgaverne og stoppe en opgave, hvis tiden bliver overskredet; og styre hele dataindsamlingen til IR-evalueringen.

Selve overvågningen af testpersonens usability-opgaveløsning foretages af Observator 2, AHG, som befinder sig i nabolokalet ved en computer. Testpersonens computers skærmbillede transmitteres direkte til Observator 2’s skærm i realtime (med et par sekunders forsinkelse), mens en webcam-optagelse af testpersonen selv vises i et hjørne af skærmen.

Observator 2 tager noter til post test-interviewet, som følger efter usability-testen, både noter på papir og mærker i videooptagelsen, hvor der sker noget vigtigt. Testpersonen er klar over, at vedkommende bliver overvåget af Observator 2, og at formålet er at tage noter til interviewet.

Figur 6: Foto af testopsætning. Observator 1 er placeret bag testpersonen. For at sikre testpersonernes anonymitet, anvender vi en (noget yngre) model i testpersonens stol.

40

Testcomputerens hardware- og software-opsætning:

Skærmstørrelse: 20” Skærmopløsning: 1152 x 864 pixels (4:3-format, ikke widescreen). Mus: Standardmus med venstre-, højre- og scroll-knap. Webcam: Monteret på skærmen.

Styresystem: Windows XP, engelsk sprog. Webbrowser: Internet Explorer 7 (version 7.0.5730.11), engelsk sprog. Herefter kaldet IE. Logging software: Morae (version 3.1.1).

Forberedelse af test og testmiljø:

Inden hver test slettes browserdata i IE (Tools → Delete browsing history → Delete all). Det sikres, at bogmærkerne i IE, som skal anvendes til opgave 6 og 7, stadig findes. Introduktionsbrev og spørgeskemaer er printet ud. Kortene med usability-opgaverne ligger klar, så testpersonen kan vende dem en af gangen. Spørgeskemaer og IR-evalueringens tasks udleveres derimod af observator under testen. Papir og pen ligger klar, men testpersonen opfordres ikke, til at skrive noget ned. Testpersonen har et glas vand, en kop kaffe el.lign. i nærheden under testen.

3.3 Morae

Morae er et computerprogram udviklet til usability test. Programmet optager både et billede af, hvad der sker på testpersonens skærm, og testpersonens ansigt via webcam. Desuden logger Morae alle handlinger fra tastetur og mus, og programmet noterer, hvor på skærmen og i hvilke programmer, der er klikket med musen eller indtastet en kommando.

I databehandlingen er det muligt sortere handlingerne således at man kan koncentrere sig om anvendelsen af en enkelt funktion på skærmen. Derved er det kvantitativt muligt at optælle, hvor mange funktioner der bliver klikket på i REX, og hvor mange gange de bliver anvendt.

Morae består af tre dele. Test-delen optager selve testen. Observator-delen kan følge med i testen fra en anden computer og skrive noterne ind i Morae, som gemmer dem. Databehandlingsdelen samler Test-delen og observator-delen. Her er det muligt at skære stykker af optagelser fra, som kan gemmes og vedlægges som elektroniske bilag. Det er også muligt at arbejde videre på noterne fra observator-delen og anvende dem i selve databehandlingen.

Vi har tidligere anvendt Morae i forbindelse med vores bacheloropgave, hvor vi undersøgte hvilke funktioner, der blev brugt i en web browser (Grøn & Johansen, 2008). I Specialet anvender vi Morae til usability testen af REX, hvor vi, blandt andet, undersøger hvordan testpersonerne anvender menuerne.

41

3.4 Testrunder

Vores eksperiment blev gennemført af vores 13 testpersoner over i alt tre omgange. Vi planlagde at lave en pilottest med to testpersoner, efterfulgt af den egentlige test med 10 testpersoner. Vi endte med at lave to pilottestrunder med i alt tre testpersoner og den egentlige test med 10 testpersoner. Imellem de tre testrunder lavede vi nogle justeringer som beskrevet nedenfor, men vi konstaterede efterfølgende, at disse justeringer ikke fik indflydelse på de dele af de indsamlede data, som vi har valgt at anvende i dette Speciale, altså hverken på selve usability testen eller IR evalueringen. Derfor anvender vi (så vidt muligt) alle 13 testpersoners testresultater.

3.4.1a Første pilottestVi udførte første pilottest med én testperson (nr. TP801), med øje for især spørgeskema- og opgavebeskrivelser, opgavernes sværhedsgrad og tid, som både Nielsen (1993) og Molich (2007) fremhæver. Vi fandt efterfølgende, at det ikke var nødvendigt at ændre usability-opgaverne, udover formalia i nummereringen af opgaverne (opgave 2a-2d blev til 2a-2b, opgave 3 blev til 3a-3b). Vi tilføjede ekstra spørgsmål til spørgeskemaerne, bl.a. demografiske oplysninger, som TP801 besvarede efterfølgende pr. email. Og vi lavede om på randomiseringen af IR Work Task’ene, men lavede ellers ingen ændringer i IR evalueringen.

Efter testen af første testperson skete der to vigtige ændringer i eksperimentet, som betød, at usability testen blev væsentligt forskellig for alle efterfølgende testpersoner. Derfor indledte vi anden pilottest, frem for at gennemføre første pilottest. Den ene ændring var et møde med Det Kongelige Bibliotek, hvor vi blev gjort opmærksomme på de ændringer, den kommende version af REX/Primo får pr. 1. juli 2010. Den måske væsentligste ændring ligger i udlånssystemet, hvorfor der ikke længere var nogen grund til, at vi undersøgte, om testpersonerne kunne finde ud af at låne materialer. Vi slettede derfor usability-opgaverne 2c og 2d.

Den anden ændring var et skift fra det Store til det Lille Usability Laboratorium på grund af for mange studerende om for lidt plads, hvilket ændrede AHG og JBJ’s roller til de beskrevne roller for Observator 1 og Observator 2 i afsnit 3.2: Opsætning af testmiljø ogsystem. Inden da havde AHG rollen som både Testleder, Observator 1 og Observator 2 i usability-testen, mens JBJ var både Testleder og Observator i IR Evalueringen, idet alle observator-poster var placeret i det samme rum som testpersonen, bag en skærm som tillod naturlig kommunikation mellem testperson og observator.

3.4.1b Anden pilottestAnden pilottest blev udført på to testpersoner, TP802 og TP803. Vi var tilfredse med alle elementer af testens opbygning og ændrede intet væsentligt (TP802 påpegede to stavefejl).

3.4.1c TestDen egentlige test gennemførtes på 10 testpersoner over tre uger, på de tidspunkter af dagen, som passede testpersonerne. Vi overvejede at nøjes med ni testpersoner, idet vi havde dataene fra de tre testpersoner fra pilottestene, som problemfrit kunne indgå med dataene fra testen. Men da en af vores testpersoner, TP807, ved en fejl kom til at annullere optagelsen af sin usability-opgaveløsning i Morae, valgte vi at holde fast i antallet 10 testpersoner.

42

I alt gav testrunderne os 12 fulde sæt spørgeskemaer (og et delvist sæt fra TP801), 12 Morae-optagelser af usability-opgaveløsning med logfiler (TP807 mangler), 13 notater med løsningsmetoder til usability-opgaveløsningen, 13 post test-interviews og 13 IR evalueringer.

43

3.5 Pre Test-spørgeskema (demografiske data)

I dette afsnit vil vi redegøre for de forskellige spørgsmål i Pre Test-spørgeskemaet og forklare, hvorfor vi udvalgt netop disse spørgsmål. Hele spørgeskemaet, sådan som det blev udleveret til testpersonerne, er vedlagt i bilag 8.

Testpersonen besvarer pre test-spørgeskemaet inden selve testen går i gang, og inden testleder forklarer, hvad eksperimentet drejer sig om. Testpersonen har dog på forhånd modtaget et introduktionsbrev pr. email om, hvad formålet med testen er, og hvad vi skal bruge de indsamlede data til. Dermed er testperson til en vis grad informeret om, hvad der vil komme til at foregå. Introduktionsbrevet er vedlagt som bilag 9.

Ifølge Johannsen & Pors (2002), kan et spørgeskema have fire formål: Holdninger Adfærd Viden Baggrundsfaktorer

I Pre Test-spørgeskemaet undersøger vi baggrundsfaktorer, som handler om testpersonernes køn, alder, uddannelse og lignende. Vi undersøger også adfærd og viden hos vores testpersoner, hvor vi spørger ind til deres brug af folkebiblioteker og Det Kongelige Bibliotek, samt afdækker forskellige dele af deres IT-kundskaber.

Johannsen & Pors har tre gode råd til, hvordan et spørgeskema udformes. De anbefaler, at man inddeler spørgeskemaet i emner, starter med de generelle spørgsmål og anvender filterspørgsmål (Johannsen & Pors, 2002). Som det kan ses i bilag 8, følger vi disse råd. Pre Test-spørgeskemaet er inddelt i emne-blokke, som begynder med generelle spørgsmål om testpersonernes baggrund. Vi anvender filterspørgsmål flere steder, hvor det ikke giver mening for en testperson at svare på det efterfølgende spørgsmål, hvis de ikke har kunnet svare bekræftende på det foregående spørgsmål.

Vi har inddelt spørgsmålene i fire kategorier, A til D. A er overordnede, demografiske spørgsmål (spm 1-4). B relaterer til testpersonens arbejdsliv (spm 5-7). C er søgeadfærd på internettet (spm 8-15) D er biblioteksbrug, herunder tidligere brug af REX (spm 16-20 eller 23)

Herunder gennemgås de enkelte spørgsmål i Pre Test-spørgeskemaet. Hvert spørgsmål er vist i en tekstboks under den tilhørende tekstbeskrivelse.

Første spørgsmål, som ses i boksen herunder, var udfyldt på forhånd. Det er vigtigt, at testpersonerne får hvert deres individuelle ID, så vi både kan holde dem anonyme og samtidig henvise til dem enkeltvis, uden at skulle bruge deres rigtige navne og derved overtræde persondataloven, hvor personlige oplysninger ikke må videregives (Datatilsynet, 2000). TP8xx kommer af, at vi er flere studerende, som anvender samme laboratorium og testcomputere. TP8 er vores unikke kode til at genkende vores testpersoner på computerne, xx er fortløbende nummerering.

A01.Testpersonens ID

44

Ved at have testpersonernes rigtige navne, opstår der ikke tvivl om nummereringen af dem. Vi har ikke anvendt testpersonens navn til andet end dette.

En jævn kønsfordeling mellem testpersonerne er vigtig eksperimentmæssigt. Vi forventer dog ikke, at der er væsentlig forskel på de to køns resultater, viden og søgeadfærd.

I spørgsmål 4 beder vi testpersonerne angive deres alder i antal år. Vi tester testpersoner i alderen 50 og ældre. Spørgsmålet giver os mulighed for at inddele testpersonerne i aldersgrupper.

Nedenstående spørgsmål handler om testpersonernes uddannelsesniveau. Kategorierne er fra Danmarks Statistiks website (Danmarks Statistik, 2009). Vi har valgt at anvende disse kategorier, fordi de til sammen dækker alle de typer uddannelser, som findes i Danmark på nuværende tidspunkt. Beskrivelserne i parentes bruges til at sammenligne med dengang testpersonerne tog deres uddannelse.

A02.Hvad er dit navn?

A03.Hvilket køn er du? Mand Kvinde

A04.Hvad er din alder?

B05.Hvad er din højeste, færdiggjorte uddannelse?

Grundskole (de første 9-10 års skolegang) Almengymnasial uddannelse (gymnasium, studenterkursus, HF-kursus) Erhvervsgymnasial uddannelse (HHX, HTX) Erhvervsfaglig uddannelse (f.eks. erhvervsudd., landbrugs- og søfartsudd.,social- og sundhedsudd.) Kort videregående uddannelse (varighed op til 2 år efter studentereksamen) Mellemlang videregående uddannelse/Professionsbachelor (varighed 2-4 år efter studentereksamen) Bachelor (varighed 3 år efter studentereksamen) Lang videregående uddannelse/Kandidatuddannelse (varighed 2 år efter bachelor) Forskeruddannelse/Ph.d.-uddannelse

45

I forlængelse af det foregående spørgsmål, beder vi testpersonerne angive deres nuværende stillingsbetegnelse. Spørgsmål B06 skal med andre ord ses som en uddybning af B05. Vi tager hensyn til, at vores testpersoner kan være pensionerede, og derfor kan de i stedet skrive den sidste stillingsbetegnelse, de havde.

Det nedenstående spørgsmål hjælper os til at inddele testpersonerne i fagområder. I usability testen og især i IR evalueringen beder vi testpersonerne udføre opgaver inden for bestemte fagområder (jf. afsnit Work Tasks til IR evaluering). Det er klart, at testpersoner, som har et godt kendskab til et bestemt fagområde, også vil have en fordel, når de udfører nogle af testopgaverne. Testpersonerne har også mulighed for at uddybe deres ekspertise, hvis de ikke synes, at vores kategorier dækker godt nok.

Spørgsmålene C08 - C15 handler om testpersonernes adfærd på internettet. Dette indbefatter både deres informationssøgningsadfærd og deres generelle anvendelse af internettet.

Spørgsmål C08 handler om internetbrowsere. Vi forventer, at testpersonerne som minimum vil kunne angive en enkelt browser som deres foretrukne. Vi ved, at Internet Explorer er installeret som standard browser i Windows-styresystemet. Og det samme gælder for Safari på Mac-computere. Brugere, som ønsker en anden browser, må selv finde og installere den.

B06.Hvad er din nuværende beskæftigelse?

Hvis du er på efterløn/pension eller uden arbejde, så skriv din seneste beskæftigelse, du definerer dig selv ud fra, her:

B07.Hvilket videnskabsområde har du hovedsagelig beskæftiget dig med i dit arbejdsliv?

Medicin/sundhedsvidenskab Naturvidenskab Humaniora Samfundsfag Andet?

C08. Hvilken internetbrowser bruger du oftest til at gå på nettet? (det er tilladt at sætte flere krydser)

Internet Explorer Firefox Safari Chrome Andre (nævn gerne flere) Ved ikke

46

Spørgsmålene C09 – C12 handler om testpersonernes søgeadfærd og foretrukne søgesystemer. Svarkategorierne er inddelt i en fem-punktsskala som går fra ”dagligt” til

”aldrig”. Formålet med disse spørgsmål er at undersøge, hvor meget testpersonerne anvender forskellige søgesystemer. Ud fra deres besvarelser kan vi redegøre for, hvor meget erfaring de har med med systemerne. Forventningen er, at de testpersoner, som har meget erfaring med forskellige databaser, også vil have lettere ved at anvende REX.

Nedenstående spørgsmål er endnu et spørgsmål om testpersonernes erfaring med IT. Vi gætte på, at de fleste testpersoner har anvendt computer i mindst 10 år.

Spørgsmål C14 er testpersonernes subjektive vurdering af, hvor gode de er til informationssøgning. Som svarkategori har vi anvendt Likert-skalaen (jf. afsnit om Likert, afsnit 2.5.1d: System Usability Scale, SUS)

Hvor ofte søger du: En eller flere gange om dagen

En eller flere gange om ugen

En eller flere gange om måneden

Sjældnere end en gang om måneden Aldrig

C09. På internettet?

C10. På Wikipedia?

C11. På bibliotek.dk?

C12. I videnskabelige databaser?

C13.For hvor mange år siden begyndte du at anvende computer til at søge efter information?(f.eks. i videnskabelige databaser, bibliotekskataloger eller på world wide web) ____________ år siden

Meget uenig UenigHverken enig eller uenig Enig Meget enig

C14. "Når jeg søger efter noget online, finder jeg generelt det, jeg leder efter."

47

I forlængelse af spørgsmål C14 har vi C15, hvor vi beder testpersonerne angive, hvad de normalt bruger internettet til. Jo flere kategorier de afkrydser, des mere trygge forventer vi, de er ved at anvende internettet. Formålet med spørgsmålet er at undersøge, i hvor høj grad testpersonen er vant til at bruge nettet, og dermed automatisk også computere mere generelt, så vi kan nuancere billedet af brugen af nettet specifikt til informationssøgning fra C9-C12.

De resterende spørgsmål handler om brugeradfærd i forbindelse med folkebiblioteker og Det Kongelige Bibliotek. Formålet med spørgsmålene er at afdække, hvor meget erfaring vores testpersoner har med at anvende biblioteker. Hvis de anvender folkebibliotekernes service ofte, så kan der også være mulighed for, at de kender til Det Kongelige Bibliotek og dettes service.

Nedenstående spørgsmål handler om testpersonernes anvendelse af biblioteker helt generelt, uden at skelne mellem fysiske og elektroniske besøg.

D16.Hvor ofte bruger du bibliotekerne? For eksempel til at låne bøger eller musik, slå informationer op, læse aviser eller gå til arrangementer? Både fysiske biblioteksbesøg og brug af hjemmesider tæller med.

Flere gange om ugen En gang om ugen Et par gange om måneden En gang om måneden Nogle gange om året En gang om året Aldrig

C15.Hvad bruger du internettet til:(sæt gerne flere krydser) Finde personer, adresser, vejbeskrivelser Købe billetter, dagligvarer, beklædning, rejser, eller andet Bestille billetter til transport, underholdning eller andet Offentlige hjemmesider, f.eks. www.skat.dk eller www.borger.dk Netbank til overførsel af penge ol.

48

Spørgsmål D17 er et filterspørgsmål. Hvis en testperson aldrig har været bruger biblioteket, så vil vedkommende heller ikke kunne svare på nedenstående spørgsmål. Formålet med spørgsmålet er at undersøge, hvorvidt vores testpersoner foretrækker fysiske besøg på biblioteket eller besøg på bibliotekets webside. Ved at få svar på dette, får vi en ide om, hvor godt kendskab testpersonerne har til et elektronisk bibliotekskatalog.

Testpersonernes besvarelser i nedenstående spørgsmål klarlægger, hvorvidt de anvender Det Kongelige Bibliotek. Hvis de anvender Det Kongelige Bibliotek meget, vil der også være mulighed for, at de har et godt kendskab til, hvordan biblioteket indekserer og opstiller materialerne; derved har de en fordel i vores usability test og IR evaluering.

Spørgsmål D18 fungerer også som et filterspørgsmål. Hvis testpersonerne aldrig har anvendt Det Kongelige Bibliotek, vil de ikke have mulighed for at besvare de resterende spørgsmål.

Nedenstående spørgsmål handler om brugeradfærden hos vores testpersoner. Ved at vide, med hvilke formål de anvender Det Kongelige Bibliotek, kan vi også få et overblik over, hvad de har erfaring med. Vores usability test og IR evaluering lægger sig mest op ad ”informationssøgning” og ”underholdning”.

D17.Hvis du ikke svarede aldrig i spørgsmål D16:

Bruger du oftest bibliotekernes forskellige hjemmesider hjemmefra, eller går du oftest på fysisk biblioteksbesøg?

Hjemmefra Biblioteksbesøg

D18.Kommer du indimellem på Det Kongelige Bibliotek?

Flere gange om ugen En gang om ugen Et par gange om måneden En gang om måneden Nogle gange om året En gang om året Aldrig

D19.I hvilken forbindelse anvender du Det Kongelige Bibliotek (sæt gerne flere krydser)?

På jobbet Privat, til informationssøgning eller artikelsøgning Privat, til slægtsforskning Privat, som underholdning Andet: __________

49

Formålet med spørgsmål D20 er at undersøge, om testpersonerne tidligere har anvendt REX/Primo. Det er et krav til vores testpersoner, at de skal falde under kategorien førstegangsbrugere eller nybegyndere, men det er acceptabelt, hvis de har anvendt systemet enkelte gange før, eller måske har brugt REX meget i en tidligere version, før Primo blev implementeret. De testpersoner, som måtte have kendskab til REX/Primo, vil have en lille fordel i usability testen, fordi har set brugergrænsefladen før.

Hvis testpersonen svarer nej til filterspørgsmålet i D20, slutter spørgeskemaet her.

Spørgsmål D21 kræver et ja til spørgsmål D20.

Ligesom foregående spørgsmål, er nedenstående spørgsmål uddybende i forhold til besvarelsen i spørgsmål D20. Hvis testpersonen imod al forventning svarer, at vedkommende benytter REX ofte, vil vedkommende have et så godt kendskab til de forskellige funktioner, at vi ikke ville kunne bruge testpersonen til vores usability-test til nybegyndere.

D20.Har du tidligere anvendt Det Kongelige Biblioteks hjemmesides søgefunktion til at finde og bestille bøger eller andre materialer?

Ja Nej

D22. Hvor ofte anvender du hjemmesidens søgefunktion?

Flere gange om ugen En gang om ugen Et par gange om måneden En gang om måneden Nogle gange om året En gang om året Aldrig

D21. Hvor længe er det siden, du sidst anvendte hjemmesidens søgefunktion?

En uge eller mindre En måned eller mindre Tre måneder eller mindre Et halvt år eller mindre Et år eller mindre Mere end et år siden

50

Spørgsmål D23 kan potentielt give et interessant billede af testpersonens emne for tidligere søgninger. Vi er nysgerrige efter at vide, hvad testpersonerne måtte ønske at søge efter. Vi forventer dog ikke som udgangspunkt, at testpersonerne vil kunne huske deres sidste søgning.

3.6 Testpersoner

Idet usability tests anvender testpersoner til at finde og verificere usability-problemer, opstår der automatisk en potentiel, eksperimentel usikkerhed i forhold til testens pålidelighed. Testpersoner har så mange personlige og faglige egenskaber, som kan spille ind i forsøget, at det kan være vanskeligt at klarlægge. Dermed bliver det også mere vanskeligt at lave en nøjagtig forsøgsbeskrivelse af eksperimentet og dets (testpersoners) variabler. For slet ikke at tale om vanskeligheden for dén, som måtte ønske at eftergøre eksperimentet og skal skaffe nye testpersoner til sit eksperiment, som skal matche den oprindelige gruppe testpersoner (for eksempel være negativt indstillede førstegangsbrugere af systemet, indenfor samme fag- og aldersgruppe), uden at matche dem så godt, at eksperimentet bliver så kunstigt, at det mister sin validitet.

Aldersfordeling: Vi definerer vores testpersoners aldersgruppe til 50-67 år eller højere, hvis testpersonen

stadig er erhvervsaktiv. De 13 testpersoner er mellem 50 og 67 år gamle, med en enkelt afstikker på 73 år (TP813)

der stadig er erhvervsaktiv som vikarierende underviser. Med 6 personer i 50'erne, 6 personer i 60'erne og 1 person i 70'erne, får vi en

gennemsnitlig alder på 59,8 år.

Kønsfordeling: Tespersonerne er fordelt på 6 mænd og 7 kvinder.

D23. Kan du huske, hvad du søgte efter, sidste gang du brugte Det Kongelige Biblioteks hjemmeside?

Ja: Nej

Uddyb gerne:

51

Erhverv: 10 af testpersonerne arbejder eller har arbejdet med undervisning:

o 7 er lærere i grundskolen, fra tre københavnske skoler (to folkeskoler og en privatskole).

o 2 er lektorer på alment gymnasielle uddannelser, fra to københavnske gymnasier.o 2 har undervist i musik (forskellige musikinstrumenter og musikteori) på danske

musikkonservatorier (den ene arbejder i dag som lærer, den anden er selvstændig). De resterende 3 testpersoner er i det private erhvervsliv som hhv. sekretær, selvstændig og

arbejdssøgende med handelsuddannelse.

Uddannelse: 1 testperson har en almen gymnasial uddannelse. 1 testperson har en kort videregående uddannelse. 7 testpersoner har en mellemlang videregående uddannelse. 4 testpersoner har en lang videregående uddannelse.

Ikke alle testpersoner er i et arbejde, hvor de (længere) udnytter deres uddannelse: Testpersonen med en almen gymnasial uddannelse arbejder som dekoratør. Testpersonen med en kort videregående uddannelse arbejder som sekretær. Af de 7 testpersoner med en mellemlang videregående uddannelse, er de 5

læreruddannede, 1 konservatorie-uddannet som operasanger og 1 har en handelsuddannelse.

De 5 med en lang videregående uddannelse er de 2 gymnasielærere, som har kandidaturer bag sig, og 2 af de 3 konservatorieuddannede musikere.

52

4 METODE OG ANALYSE – USABILITY TEST (AHG)

I denne kapitel gennemgår vi metoden for usability testen, herunder hvordan vi indsamler data i de forskellige dele af eksperimentet, som alle har at gøre med usability.

Vi beskriver dataindsamlingen for de tre dele af usability testen: Selve opgaveløsningen, besvarelsen af SUS-spørgeskemaet og post test-interviewet.

Vi udfører analysen af usability testen med værktøjer, som måler forskellige områder af usability: Opgaveløsningen analyseres med Hornbæks (2005) operationaliserede mål for effectiveness og efficiency. Vi analyserer dataene fra SUS-spørgeskemaet og beregner REX’s Overordnede Usability-værdi for subjective satisfaction. Og vi udfører en funktionsanalyse for at kortlægge synlige og skjulte funktioner og knapper i REX.

Til sidst præsenterer vi vores forslag til at forbedre REX’ usability, som vi har indtænkt i det eksisterende REX og illustrerer ved hjælp af mock ups.

4.1 Dataindsamling

Den del af eksperimentet, som undersøger REX/Primo’s usability, består af tre dele: Usability test Post test-spørgeskema i form af SUS Post test-interview

Alle tre dele optages i Morae, da det giver os mulighed for at se og høre den fulde tekst igennem under databehandlingen, inklusive kommentarer imellem delene af testen. Eneste undtagelse er de fem minutter, det tager at gemme optagelsen fra usability testen på computeren og starte en ny optagelse til interviewet.

Usability testen i brugergrænsefladen REX består af 6 opgaver, hvoraf de anvender de 5 opgaver i dette Speciale (den sidste opgave indsamler kun data om Subjective satisfaction, ikke nogle objektive data). Vi gennemgår opgaverne i det følgende afsnit.

Dataindsamling med SUS-spørgeskemaet har vi gennemgået i afsnit 2.5.1d: SystemUsability Scale, SUS.

Post test-interviewet foregår umiddelbart efter usability testen, mens opgaverne stadig er klare i testpersonens hukommelse. I afsnit 2.4: Kognitive egenskaber ved concurrentkontra retrospektiv tænke højt, diskuterede vi fordele og ulemper ved at lave post test-interviewet som en retrospektiv tænke højt-test, og vi argumenterede for, at de data vi indsamler med tænke højt-metoden under selve usability testen, ikke behøver suppleres yderligere. Derfor er et post test-interview alligevel vigtigt, så observator kan få svar på alle de spørgsmål, som måtte være opstået under testen, imens testpersonen ikke måtte forstyrres.

Mange af spørgsmålene, som bliver stillet i interviewet, er opstået under observationen af testpersonen, men vi har også en Dagsorden for interviewet, som bl.a. rummer spørgsmål angående konsistensen mellem begreber i REX og testpersonens holdning

53

til forskellige dele af systemet. Vi præsenterer ikke disse subjektive data individuelt i specialet, men Dagsordenen kan ses i bilag 10.

54

4.2 Gennemgang af usability testens opgaver

I dette afsnit beskriver vi de usability-opgaver, som testpersonerne løser i REX. Vi har inddelt opgaverns indhold i mindre dele, for bedre at kunne give en overskuelig gennemgang af usability testens opgaver. Indholdet skal læses på denne måde:

Formål: Hvad vi forventer at observere og lære af at lade testpersonen løse opgaven. Formulering: Den opgavetekst, testpersonen får udleveret. Beskrivelse: Forklaring på spørgsmålets formulering og beskrivelse af, hvilke

løsningsmuligheder testpersonen har. Tidsbegrænsning: Hver af opgaverne skal løses indenfor et fastsat antal minutter. Mål: De metoder og mål (measures), vi anvender til at måle usability.

Målene inddeler vi i kategorierne effectiveness og efficiency. Spørgsmålene bliver analyseret med mål fra en eller flere kategorier.Alle mål er taget fra Hornbæk (2005), som beskrevet i afsnit 2.5.1c: Hornbæks objektive ogsubjektive usability-mål, og vi henviser til hvert mål udfra artiklens Tabel 2 til 5 (Tabel 1 viser ikke usability-mål). I Specialets bilag 2-5, har vi har indskrevet vores nummerering i punkter og underpunkter, så det er lettere for læseren at finde rundt i målene.

Opgave 1

Formål: Den første opgave har til formål at undersøge, om testpersonerne kan finde ind på Det Kongelige Biblioteks webside. Vi observerer hvilke webadresser testpersonen afprøver, og om personen bruger en af KB’s to webadresser.

Formulering: Find Det Kongelige Biblioteks hjemmeside.

Beskrivelse: Når testen går igang, er Internet Explorer åben og viser et blankt faneblad. Testpersonen kan løse opgaven ved at gætte en af KB’s webadresser (domænenavne), www.kb.dk eller www.detkongeligebibliotek.dk, eller ved at bruge en søgemaskine. Denne opgave er valgt som opgave 1, fordi den er meget nem at løse, sådan at opgaveløsningen kan hjælpe eventuelle, nervøse testpersoner til at slappe mere af i testsituationen (Molich, 2007). Molich foreslår samme sted, at man bør undersøge om testens webside kan findes, selvom svaret virker indlysende, fordi det vil være en katastrofal fejl hvis det rent faktisk viser sig, at siden ikke kan findes.

Tidsbegrænsning: 5 minutter.

Mål:Effectiveness:Tabel 2.1, “Binary task completion”: Løser testpersonen opgaven korrekt eller ej?Tabel 2.2a, “Error rate”: Antal forsøg (“fejl”), der bruges på at løse opgaven.Efficiency:Tabel 3.1a, “Task completion time”: Antal sekunder der går, før websiden findes og åbnes.

55

Opgave 2a

Formål: At undersøge, om testpersonerne finder Søgeboksen på KB’s startside (www.kb.dk), og hvor lang tid der går før boksen bliver fundet og brugt. Samt en måde at få testpersonerne fra startsiden og ind i selve REX, fremfor at bede dem om at indtaste REX’ webadresse.

Formulering:Forfatteren Benny Andersen fyldte 80 år i november, og du er nysgerrig efter at lære noget mere om hans liv og arbejde. Så du tager et kig på, hvilke bøger Det Kongelige Bibliotek har om forfatteren.

2a. Søg på Benny Andersen.

Beskrivelse: Vi har valgt en kendt, dansk forfatter til den første search task, fordi vi ønsker: Et søgeemne, som testpersonerne nemt kan relatere til og føler er velkendt; At testpersonen ikke er i tvivl om, at der i søgeboksen skal vælges “bøger, tidsskrifter,

m.m.”

Valget faldt på Benny Andersen, fordi: Der findes otte ud af elleve mulige, forskellige dokumenttyper om ham. De eneste

kategorier der mangler, er tidsskrifter, aviser og kartografisk materiale. Fem ud af de ti første søgeresultater viser indscannede bogforsider i posterne. De viste

bogforsider er meget utydelige, men vi håber netop, at testpersonerne vi kommentere på størrelse og manglende rammer på billederne. Og hvis testpersonerne ikke ser dem, har vi et godt argument for, at de bør gøres tydeligere.

Tidsbegrænsning: 2 minutter til at finde Søgeboksen.

Mål:Effectiveness:Tabel 2.1, “Binary task completion”: Løser testpersonen opgaven korrekt eller ej?Efficiency:Tabel 3.1c, “Time until event”: Antal sekunder der går, før der søges i den korrekte søgeboks.Tabel 3.3a, “Use frequency”: Antal klik testpersonen bruger, frem til at søgeresultaterne vises.

Opgave 2b

Formål: 2b undersøger, om testpersonerne kan finde en funktion i Afgrænsningsmenuen til venstre for søgeresultaterne, ud fra dens navn alene. Undersøger, om testpersonerne forstår ordet dokumenttyper og ser en sammenhæng mellem ordene dokumenttyper og materialer.

Formulering:2b. Hvor mange forskellige slags dokumenttyper har Det Kongelige Bibliotek om Benny Andersen?

56

Beskrivelse: Opgave 2b har et selvstændigt formål i forhold til opgave 2a. Den blev lagt ind under opgave 2 for at illustrere overfor testpersonen, at opgaven skulle besvares ud fra det søgeresultat, som blev fundet i 2a.

Tidsbegrænsning: 2 minutter til at finde funktionen til at afgrænse efter dokumenttype.

Mål:2bEffectiveness:Tabel 2.1, “Binary task completion”: Løser testpersonen opgaven korrekt eller ej?Tabel 2.4, “Completeness”: Ses knappen “Vis X mere”? Ellers er opgaven kun halvvejs løst.Efficiency:Tabel 3.1a, “Task completion time”: Antal sekunder der går, før løsningen læses højt.

Opgave 3a

Formål: Opgave 3a er et åbent spørgsmål, hvor vi giver testpersonerne mulighed for at udforske REX på egen hånd.

Formulering:Der er sikkert en by eller et område i Danmark, som betyder noget særligt for dig.

3a. Søg efter dette område,og find et historisk billede, foto, tryk, kort eller noget helt femte, som viser området før i tiden.

Det skal være et billede, du kan få lov til at se (Ellers må du vælge et andet område).

Beskrivelse: Denne opgave er bevidst stillet som en åben opgave. Dét, vi ønsker at teste i opgave 3, er søgeadfærd når testpersonerne bliver bedt om at søge efter et emne valgt efter interesse. Og om testpersonerne med det samme forstår, at kun en lille procentdel af KB's billedmedier er blevet digitaliseret og gjort tilgængelige online endnu, en information, der ikke står nogen steder i REX.

Tidsbegrænsning: Opgaven stoppes efter ca. 5 minutter, efter observators vurdering.

Mål:Effectiveness:Tabel 2.1, “Binary task completion”: Løser testpersonen opgaven korrekt eller ej?Tabel 2.4, “Completeness”: Får testpersonen lavet en søgning, som rummer billeder med online adgang? Scrollet forbi et billede (evt. uden at lægge mærke til det)? Åbnet et billede?Efficiency:Tabel 3.7, “Other”: Antal søgninger i REX, der bruges på at finde løsningen.Tabel 3.7, “Other”: Antal funktioner afprøvet i forsøget på at finde løsningen.Tabel 3.1c, “Time until event”: Antal sekunder der går, før testpersonen laver en søgning, som rummer billeder med online adgang første gang.

57

Tabel 3.1c, “Time until event”: Antal sekunder der går, før testpersonen får vist en side med søgeresultater, hvoraf der er online adgang til mindst ét af dem.Tabel 3.1a, “Task completion time”: Antal sekunder der går, før testpersonen åbner et billede.

Opgave 3b

Denne opgave har til formål at indsamle testpersonernes subjektive holdninger til kvaliteten af det billede eller kartografiske materiale, som blev fundet i opgave 3a, for Det Kongelige Bibliotek. Vi anvender ikke opgave 3b i specialet, da vi kun analyserer objektive data.

Opgave 4

Formål: Formålet med opgave 4 er at undersøge hvad der sker, når testpersonerne anvender REX/Primo, som de ville en internetsøgemaskine såsom Google. Vi observerer testpersonernes indlæring, og hvilke søgemetoder de forsøger at anvende.

Formulering:Nu åbner Tivoli snart... Du er blevet inviteret derind af nogle venner, som har sagt, at I skal mødes ved statuen af ham, som lavede Tivoli.

Men hvad er det nu, han hedder?

Du må kun bruge REX til at prøve at finde svaret.

Beskrivelse: Dette spørgsmål kræver, at testpersonen er kreativ i sit valg af søgetermer. Vi forærer bevidst ingen søgetermer til at løse opgaven, udover at personen er en mand. Vi har testet følgende kombinationer og fundet, at de kan bruges til at gennemskue løsningen: Georg Carstensen, med søgningerne: “tivoli grundlægger”, “tivoli stifter”, “tivoli historie” og “tivoli statue”. Søges der på f.eks. “tivolis” eller “statuer”, træder forslagsfunktionen “Mente du: tivoli ?” ind.

Løsningen er blandt de øverste 1-20 søgeresultater, altså første to sider. Søger man derimod blot på "tivoli", får man 1.996 søgeresultater, hvoraf de 465 er billeder.

Tidsbegrænsning: Opgaven stoppes efter ca. 5 minutter, efter observators vurdering.

Mål:Effectiveness:Tabel 2.1, “Binary task completion”: Løser testpersonen opgaven korrekt eller ej?Efficiency:Tabel 3.7, “Other”: Antal søgninger i REX, der bruges på at finde løsningen.Tabel 3.7, “Other”: Antal funktioner afprøvet i forsøget på at finde løsningen.Tabel 3.1a, “Task completion time”: Antal sekunder der går, før løsningen læses højt.

58

Opgave 5

Formål: Denne opgave er en fortsættelse af opgave 4. Testpersonerne skal finde et billede af en statue af Tivolis stifter fra opgave 4. Her er altså tale om known item-search.

Formulering:Du kom endelig i tanke om, at grundlæggeren hedder Georg Carstensen. Nu vil du gerne finde et billede af denne statue, som I skal mødes ved inde i Tivoli.

Find et billede af statuen af Georg Carstensen.

Beskrivelse: Der findes kun to digitaliserede billeder af statuen i REX, men opgaven har flere end to løsningsmuligheder. En søgning på "Georg Carstensen" og materialet "billeder" giver blot seks søgeresultater. To af disse poster rummer et billede af statuen. En søgning på "Georg Carstensen statue" giver kun disse to poster. En søgning på "tivoli statue" giver seks poster, "tivoli statuer" giver én; statuen er med i begge disse sæt poster.

Det interessante ved denne søgning er ikke så meget valgte søgemetoder, men selve de bibliografiske poster, som billederne befinder sig i. Begge rummer mere end ét dokument: Den ene post består af syv, den anden af 13 fotografier. I den ene post er billedet af Statuen nummer fire på listen, i den anden post er det nummer ni. I søgeresultat-listen vises kun titlerne på de tre første billeder, og under titlerne et link med "Vis alle". Det interessante er altså, om testpersonen kan regne ud, at der er flere end ét fotografi i hver af de fundne, relevante poster. Om der bliver klikket på "Vis alle", eller om testpersonen klikker på posterne og inde på selve posterne finder Georg Carstensens navn i postens indholdsfortegnelse over fotografier. Eller om testpersonen giver fortabt uden at finde nogen af billederne.

Tidsbegrænsning: Opgaven stoppes efter ca. 5 minutter, efter observators vurdering.

Mål:Effectiveness:Tabel 2.1, “Binary task completion”: Løser testpersonen opgaven korrekt eller ej?Tabel 2.4, “Completeness”: Får testpersonen lavet en søgning på Georg Carstensen? Åbnet en af de to billedposter, som rummer et billede af statuen? Vist selve billedet?Efficiency:Tabel 3.7, “Other”: Antal søgninger i REX, der bruges på at finde løsningen.Tabel 3.7, “Other”: Antal funktioner afprøvet i forsøget på at finde løsningen.Tabel 3.1c, “Time until event”: Antal sekunder der går, før testpersonen laver en søgning på Georg Carstensen.Tabel 3.1c, “Time until event”: Antal sekunder der går, før testpersonen åbner en af de to billedposter, som rummer et billede af statuen. Hvis billedet da ikke åbnes direkte fra søgeresultaterne.Tabel 3.1a, “Task completion time”: Antal sekunder der går, før et korrekt billede åbnes.

59

4.3 Analyse af testpersonernes opgaveløsning

I det følgende afsnit analyserer vi testpersonernes søgeadfærd og løsningsmetoder i usability-opgaverne. Som nævnt i 2.5.1c: Hornbæks objektive og subjektive usability-mål, anvender vi Hornbæks usability-mål (“measures”) til at måle de forskellige elementer af hver opgave indenfor effectiveness og efficiency (Hornbæk, 2005). Vi anvender Nielsens metode til at evaluere hvert mål efter en målestok, som vi tilpasser subjektivt til hver opgave og hvert mål.

Evalueringerne er af formen “Kravet er, at minimum [antal] % af testpersonerne løser opgaven indenfor [en udvalgt ramme], hvor rammen matcher usability-målet, f.eks. et passende tidsinterval til efficiency-målet om “task completion time” (Nielsen, 1993).

Det Kongelige Biblioteks startside, www.kb.dk:

Opgave 1: At finde Det Kongelige Bibliotek’s webside

I opgave 1 testede vi, om websiden er til at finde. Alle 13 testpersoner var i stand til at komme ind på Det Kongelige Biblioteks webside uden problemer.

Idet eksperimentet foregik i Biblioteksskolens usability laboratorium, som deles med andre forskere og studerende, havde vi ikke helt frie hænder til at ændre på computerens opsætning. En af de ting, vi ikke ændrede på, er at Internet Explorer’s standard-søgemaskine er sat til den relativt ukendte “My Way” i stedet for Google. Tre testpersoner, som valgte at søge i IE’s adressefelt i stedet for i søgefeltet i øverste, højre hjørne af IE, kom derfor ud for at skulle navigere rundt i søgeresultaterne og reklamerne på “My Way”, hvilket betyder, at opgaveløsningen tog længere tid for to af de tre testpersoner.

Tabel 2.1, “Binary task completion”: Løser testpersonen opgaven korrekt eller ej? 13 ud af 13 = 100% løste opgave 1 korrekt.Vores krav til antal testpersoner, som løste opgaven, blev mødt.Kravet var min. 90% af testpersonerne, 12 ud af 13.

Tabel 2.2a, “Error rate”: Antal forsøg (“fejl”), der bruges på at løse opgaven. 9 ud af 13 = 69% fandt websiden i første forsøg. 1 ud af 13 = 8% brugte 2 forsøg, før vedkommende kom ind på websiden. De sidste 3 = 23% brugte 4 forsøg, før de kom ind på websiden, de to p.g.a. “My Way”.Vores krav til max. antal forsøg nødvendige, blev mødt.Kravet var max. 3 forsøg for 80% af testpersonerne, 11 ud af 13, og “My Way” ser vi bort fra.

60

Tabel 3.1a, “Task completion time”: Antal sekunder der går, før websiden findes og åbnes. TP802 og TP807’s tider kendes ikke, men den var under 5 minutter. Opgaven blev løst på gennemsnitligt 1 min 7 sek blandt de 11 testpersoner. Hurtigste tid er 32 sek, langsomste 2 min 34 sek. Uden testpersonerne TP806, TP811 og TP813, som anvendte søgemaskinen “My Way”,

bliver gennemsnittet 52 sek.Vores krav til tiden brugt på at løse opgaven, blev mødt.Kravet var 5 minutter for 100% af testpersonerne, 13 ud af 13.

Søgeadfærd: Ingen testpersoner ved i forvejen, at adressen er www.kb.dk . To personer kom i tanke om,

at de havde set adressen før, da de først kom ind på websiden. 3 ud af 13 fandt på at prøve www.detkongeligebibliotek.dk, alle 3 i første forsøg. 7 ud af 13 brugte Google til at finde KB, de 5 af dem i første forsøg. 3 ud af 13 brugte IE’s standardsøgemaskine, “My Way”. 2 testpersoner prøvede adressen www.dkb.dk, 1 prøvede www.kglbibl.dk og 1 prøvede

www.kgb.dk, men skyndte sig at rette det og grine af sig selv. Blandt de 10, som brugte søgning som metode til at finde KB, søgte 3 på “det kongelige

bibliotek”, 3 på “kongelige bibliotek”, 2 på “det kgl. bibliotek” og 1 på “kgl bibliotek”. TP802’s søgetermer kendes ikke.

Vi konkluderer, at der ikke er nogen grund til, at Det Kongelige Bibliotek anskaffer sig andre webadresser (domænenavne) end de to, de allerede ejer. Testpersonerne var ikke konsekvente i deres forsøg på at gætte KB’s webadresser, og der blev ikke stillet nogle forslag fra testpersonerne om andre webadresser i post test-interviewet, heller. Sålænge KB bliver ved med at dukke op som det første søgeresultat i Google, vil ingen førstegangsbrugere få problemer.

Opgave 2a: Søgeboksen på startsiden

Opgave 2a undersøgte testpersonernes søgemetoder på startsiden. Alle testpersoner endte i sidste ende med at anvende den store, “blå søgeboks”, som leder ind til REX, men to af testpersonerne forsøgte først at løse opgaven på andre måder end via søgeboksen. Den ene brugte den “hvide søgeboks”, og den anden brugte drop down-menuen “Materialer” som en slags emneindgang.

Begge måtte have hjælp af observator, med en besked om at vende helt tilbage til www.kb.dk og forsøge at gribe opgaven an på en ny måde. Herefter fandt de begge søgeboksen hurtigt og gættede, at den var løsningen på opgaven. De øvrige 11 testpersoner var meget hurtige til at se og anvende søgeboksen.

Tabel 2.1, “Binary task completion”: Løser testpersonen opgaven korrekt eller ej?

61

11 ud af 13 = 85% løste opgave 2a korrekt. 2 ud af 13 = 15% forsøgte andre metoder, og løste derfor ikke opgaven indenfor de 2 min. 1 af disse 2 søgte desuden i “www.kb.dk” i stedet for i “Bøger, artikler m.m.”, hvilket

også betyder, at testpersonen ikke løste opgaven korrekt.Vores krav til antal testpersoner, som løste opgaven, blev mødt.Kravet var min. 80% af testpersonerne, 11 ud af 13.

Tabel 3.1a, “Task completion time”: TP807’s tider kendes ikke. Opgaven blev løst af på gennemsnitligt 51 sek blandt de 12 testpersoner. Hurtigste tid er 7 sek, langsomste 3 min 40 sek. Uden testpersonerne TP801 og TP802, som først anvendte Søgeboksen efter at have

prøvet andre alternativer, bliver gennemsnittet 18 sek, og langsomste tid 41 sek.Vores krav til tiden brugt på at løse opgaven, blev mødt.Kravet var 2 minutter for min. 80% af testpersonerne, 10 ud af 12.

Tabel 3.3a, “Use frequency”: Antal klik testpersonen bruger, frem til at søgeresultaterne vises.Vi tæller brug af Enter-knappen og Backspace-knappen med under muse-klik, idet disse to knapper almindeligvis bruges til at navigere frem og tilbage i IE. TP807’s data kendes fra observators noter. 11 ud af 13 = 85% bruger kun ét enkelt muse-klik fra opgave 2a er læst færdig, på at

klikke i søgeboksen og skrive deres søgeord. De 2 testpersoner som forsøger andre metoder (TP801 og TP802), bruger hhv. 19 og 18

klik, før de er kommet tilbage til startsiden og er klar til at skrive deres søgeord i søgeboksen.

Vores krav til antal klik brugt på at løse opgaven, blev mødt.Kravet var max. 1 klik for min. 40% af testpersonerne, 6 ud af 13, og samtidig max. 4 klik for min. 80% af testpersonerne, 11 ud af 13.

Søgeadfærd: 11 af testpersonerne søger på “benny andersen”. 1 testperson søger på “benny andersen forfatter”. 1 testperson søger på “benny andersen alt”, for at finde alt om Benny Andersen. I opgavebeskivelsen står der, at testpersonen skal søge efter bøger. Og testpersonerne får

at vide, at testen skal udføres på KB’s webside. 1 testperson vægter tilsyneladende ordet webside højere end ordet bøger og søger derfor i “www.kb.dk” i stedet for i “Bøger, artikler m.m.”.

6 af de 12 testpersoner søger ved at klikke på “Søg”-feltet. De andre 6 bruger enter-knappen. TP807’s metode kendes ikke.

Vi konkluderer, at den blå søgeboks på KB’s startside, som fører ind i REX, er synlig nok for testpersonerne. Da vi bruger førstegangsbrugere, har dette ikke noget at gøre med, at de ser konsistensen mellem placeringen af søgefeltet i REX og her på startsiden. Det skyldes simpelthen, at den blå søgeboks er velplaceret og skiller sig godt ud fra resten af startsiden.REX:

62

Opgave 2b: Find antal Dokumenttyper

Her stiller testpersonerne en opgave om dokumenttyper, som besvares ved at spotte ordet Dokumenttyper i Afgrænsningsmenuen og læse højt, hvad denne funktion dækker over. I post test-interviewet spurgte vi testpersonerne, om de havde forstået, hvad opgaven gik ud på, da de først læste opgavebeskrivelsen, og 46% (6 ud af 13) svarer nej til dette.

Tabel 2.1, “Binary task completion”: Løser testpersonen opgaven korrekt eller ej? 8 ud af 13 = 62% løste opgave 2b korrekt. 5 ud af 13 = 38% løser ikke opgaven korrekt. Blandt disse 5 er der 2 som slet ikke løser opgaven, 2 som løser den for langsomt, og 1

som kun løser den delvist.Vores krav til antal testpersoner, som løste opgaven, blev ikke mødt.Kravet var min. 80% af testpersonerne, 11 ud af 13.

Tabel 2.4, “Completeness”: Ses knappen “Vis X mere”? Ellers er opgaven kun halvvejs løst. 2 ud af 13 = 15% løser slet ikke opgaven. 1 ud af 13 = 8% får afgrænset sin søgning til kun tre dokumenttyper, således at “Vis X

mere”-linket slet ikke bliver vist (TP811). 9 ud af 10 = 90% ser knappen “Vis X mere”. 1 ud af 10 = 10% ser de tre dokumenttyper, men overser knappen “Vis 5 mere” (TP807).Vores krav til antal testpersoner, som løste opgaven, blev mødt.Kravet var, at blandt de testpersoner, som løste opgaven, skulle min. 80% af testpersonerne anvende knappen “Vis X mere”.

Tabel 3.1a, “Task completion time”: Antal sekunder der går, før løsningen læses højt. TP807’s tider kendes ikke. Opgaven blev løst af på gennemsnitligt 1 min 18 sek blandt de 10 testpersoner, som

gennemførte den. Hurtigste tid er 24 sek, langsomste 4 min 10 sek. Uden testpersonerne TP801 og TP805, som løste opgaven for langsomt, bliver

gennemsnittet 55 sek, og langsomste tid 1 min 24 sek.Vores krav til tiden brugt på at løse opgaven, blev ikke mødt.Kravet var 2 minutter for min. 80% af testpersonerne, 10 ud af 12.Kun 9 ud af 12 = 75% kunne løse opgaven indenfor tidsrammen.

Søgeadfærd: 3 testpersoner læste først opgaven som antal søgeresultater i stedet for dokumenttyper. 3 testpersoner forsøgte at løse opgaven ved at bladre igennem de første mange sider med

søgeresultater. Disse samme 3 testpersoner løste opgaven for langsomt. 3 testpersoner læste opgaven som, hvor mange af hver dokumenttype, der findes. 2 testpersoner (TP808 og TP811) associerede under selve testen ordet “dokumenttyper”

fra opgavebeskrivelsen med drop down-menuen “Materialetyper”, men fandt også straks ud af, at opgaven ikke kunne løses ad denne vej.

Denne opgave var svær at løse for nogle af testpersonerne, nem for andre og uløselig for de to sidste. Vores formål med opgaven var at se, hvor lang tid der går, før et element i

63

Afgrænsningsmenuen bliver set. Ud fra dette kan vi udtale os om Afgrænsningsmenuens placering og vi konkluderer, at Afgrænsningsmenuen ikke er synlig nok, selv om den er placeret lige ved siden af listen med søgeresultater. Der mangler noget i brugergrænsefladen til at binde de to lister sammen i brugerens øjne.

Opgave 3a: Find et billede fra Danmark

I denne opgave får testpersonen besked om at søge efter et område i Danmark efter eget valg, uden at det nævnes, at der sandsynligvis kun vil være billeder at finde fra storbyer og tilsvarende store områder. Vi observerer indlæring og inddragelse af søgefunktioner, mens testpersonen leder efter digitaliserede billeder med trial and error-metoden.

Tabel 2.1, “Binary task completion”: Løser testpersonen opgaven korrekt eller ej? 5 ud af 13 = 38% løste opgave 3a korrekt. 8 ud af 13 = 62% løser ikke opgaven korrekt.Vores krav til antal testpersoner, som løste opgaven, blev ikke mødt.Kravet var min. 80% af testpersonerne, 11 ud af 13.

Tabel 2.4, “Completeness”: Får testpersonen lavet en søgning, som rummer billeder med online adgang? Scrollet forbi et billede (evt. uden at lægge mærke til det)? Åbnet et billede? 4 ud af 13 = 31% løser slet ikke opgaven. De bliver stoppet af observator, fordi tiden

overskrides. 9 ud af 13 = 69% laver mindst én søgning, som rummer billeder med online adgang. Af

disse testpersoner , bliver de 3 stoppet p.g.a. tidsmangel, og 1 giver op tidligere. 5 ud af 13 = 38% gennemfører både “completeness”-trin 2 og 3. 9 ud af 10 = 90% ser knappen “Vis 5 mere”. 1 ud af 10 = 10% ser de tre dokumenttyper, men overser knappen “Vis 5 mere” (TP807).Vores krav til antal testpersoner, som løste opgaven, blev mødt.Kravet var, at blandt de testpersoner, som løste opgaven, skulle min. 80% af testpersonerne anvende knappen “Vis 5 mere”.

Tabel 3.1c, “Time until event”: Antal sekunder der går, før testpersonen laver en søgning, som rummer billeder med online adgang første gang. Denne del blev løst af på gennemsnitligt 1 min 59 sek blandt de 8 testpersoner, som

gennemførte denne del af opgaven. Hurtigste tid er 20 sek, langsomste 3 min 31 sek.

Tabel 3.1c, “Time until event”: Antal sekunder der går, før testpersonen får vist en side med søgeresultater, hvoraf der er online adgang til mindst ét af dem. Denne del blev løst af på gennemsnitligt 1 min 33 sek blandt de 4 testpersoner, som

gennemførte denne del af opgaven. Hurtigste tid er 32 sek, langsomste 4 min 3 sek.

Tabel 3.1a, “Task completion time”: Antal sekunder der går, før testpersonen åbner et billede, fra søgeresultaterne bliver vist.

64

Denne del blev løst af på gennemsnitligt 21 sek blandt de 4 testpersoner, som gennemførte denne del af opgaven.

Hurtigste tid er 6 sek, langsomste 41 sek.

Tabel 3.7, “Other”: Antal søgninger i REX, der bruges på at finde løsningen. 2 ud af 12 = 17% laver 1 søgning i forsøget på at løse opgaven. 1 ud af 12 = 8% laver 2 søgninger i forsøget på at løse opgaven. 4 ud af 12 = 33% laver 3 søgninger i forsøget på at løse opgaven. 4 ud af 12 = 33% laver 4 søgninger i forsøget på at løse opgaven. 1 ud af 12 = 8% laver 5 søgninger i forsøget på at løse opgaven.

Tabel 3.7, “Other”: Antal funktioner afprøvet i forsøget på at finde løsningen. 6 ud af 12 = 50% bruger drop down-menuerne til at raffinere sine søgninger. 2 ud af 12 = 17% bruger Afgrænsningsmenuen til at raffinere sine søgninger. 4 ud af 12 = 33% bruger ingen funktioner til at raffinere sine søgninger. 2 ud af 12 = 17% bruger søgeboksen på www.kb.dk til den første af sine søgninger, begge

er talt med blandt de 6 nævnt ovenfor, fordi bruger drop down-menuerne, da de kommer tilbage i REX.

Vi er overraskede over, at vores mål for “binary task completion” ikke blev nået i denne opgave. Opgaveformuleringen var tænkt sådan, at testpersonen skulle indse efter kort tid, om der var digitaliserede billeder at finde, og hvis ikke, så søge efter et nyt landområde. Men mange af testpersonerne viste sig at holde stædigt fast ved deres søgetermer, så vi kunne givetvis have lavet opgaveformuleringen anderledes med et bedre resultat.

Det er interessant at se, hvor stor forskel der er på den tid, det tager testpersonerne at åbne et billede i en bibliografisk post, fra posten bliver vist på skærmen. Over et halvt minut.

Opgave 4: Tivolis grundlægger

I denne opgave tvinger vi REX ud i en unormal situation, idet testpersonen skal bruge REX til at besvare et spørgsmål, som internet-søgemaskiner kan håndtere, men OPAC’s ikke er gode til. Selvfølgelig har vi sikret os, at der er flere løsningsmetoder til opgaven, heriblandt mange søgetermer. Vi tvinger også nogle at testpersonerne ud i en unormal situation, idet de skal lade som om, de ikke ved, at de søger efter Georg Carstensen. Det lykkes for alle pånær én testperson (TP802).

Tabel 2.1, “Binary task completion”: Løser testpersonen opgaven korrekt eller ej? 7 ud af 13 = 54% løste opgave 3a korrekt. 6 ud af 13 = 62% løser ikke opgaven korrekt. 1 af disse 6 søger på Georg Carstensen i stedet for at finde ham på anden vis. 2 af de 6 giver op (efter hhv. 1½ og 3 minutter). 3 af de 6 bliver stoppet af observator, fordi tiden overskrides. Tabel 3.1a, “Task completion time”: Antal sekunder der går, før løsningen læses højt. TP807’s tider kendes ikke. Denne del blev løst af på gennemsnitligt 2 min 48 sek blandt de 7 testpersoner, som

gennemførte denne del af opgaven.

65

Hurtigste tid er 49 sek, langsomste 5 min 26 sek.

Tabel 3.7, “Other”: Antal søgninger i REX, der bruges på at finde løsningen (Testpersonen, som søger direkte på Carstensen tæller ikke med). 1 ud af 11 = 9% laver 1 søgning i forsøget på at løse opgaven. 3 ud af 11 = 27% laver 2 søgninger i forsøget på at løse opgaven. 3 ud af 11 = 27% laver 3 søgninger i forsøget på at løse opgaven. 2 ud af 11 = 18% laver 4 søgninger i forsøget på at løse opgaven. 1 ud af 11 = 9% laver 6 søgninger i forsøget på at løse opgaven. 1 ud af 11 = 9% laver 7 søgninger i forsøget på at løse opgaven.

Tabel 3.7, “Other”: Antal funktioner afprøvet i forsøget på at finde løsningen. 8 ud af 11 = 73% bruger drop down-menuerne til at raffinere sine søgninger. 2 ud af 11 = 18% bruger Afgrænsningsmenuen til at raffinere sine søgninger. 1 ud af 11 = 9% bruger ingen funktioner til at raffinere sine søgninger. 1 ud af 11 = 9% bruger søgeboksen på www.kb.dk til den første af sine søgninger.

Vi stiller ikke nogle krav til denne opgave, udover at opgaven skal løses på omtrent fem minutter. Vi udsætter REX for søgninger med et formål, som næppe vil fremkomme i virkeligheden. Det vigtigste ved opgave 4 er at observere brugernes anvendelse af REX’ forskellige funktioner. Iøvrigt giver opgaven et godt indblik i vores testpersoners niveau af stædighed, når det kommer til informationssøgning, hvilket vi dog ikke måler på.

Opgave 5: Find et billede af en statue af… (known item search)

Tabel 2.1, “Binary task completion”: Løser testpersonen opgaven korrekt eller ej? 7 ud af 13 = 54% løste opgave 3a korrekt. 6 ud af 13 = 62% løser ikke opgaven korrekt.Vores krav til antal testpersoner, som løste opgaven, blev ikke mødt.Kravet var min. 80% af testpersonerne, 11 ud af 13.

Tabel 2.4, “Completeness”: Får testpersonen lavet en søgning på Georg Carstensen? Åbnet en af de to billedposter, som rummer et billede af statuen? Vist selve billedet? 13 ud af 13 = 100% laver en søgning, som giver de korrekte søgeresultater. 9 ud af 13 = 69% åbner en af de to korrekte billedposter. Af de resterende 4 testpersoner

giver 3 op, mens den sidste: 1 ud af 13 = 8% springer “completeness”-trin to over og åbner i stedet billedet ved at

anvende linket “vis alle” i søgeresultaterne. 7 af de 9, som gennemfører trin to = 78% får vist selve billedet.Vores krav til antal testpersoner, som løste opgaven, blev ikke mødt.Kravet var, at blandt de testpersoner som fik åbnet en af de korrekte to billedposter, skulle min. 80% af testpersonerne scrolle ned i resultaterne og få vist billedet.Tabel 3.1c, “Time until event”: Antal sekunder der går, før testpersonen laver en søgning på Georg Carstensen. Denne del blev løst af på gennemsnitligt 1 min 8 sek. Alle testpersoner gennemførte denne

del af opgaven (TP807’s tider kendes ikke). Hurtigste tid er 22 sek, langsomste 2 min 34 sek.

66

Tabel 3.1c, “Time until event”: Antal sekunder der går, før testpersonen åbner en af de to billedposter, som rummer et billede af statuen. Hvis billedet da ikke åbnes direkte fra søgeresultaterne. Denne del blev løst af på gennemsnitligt 1 min 19 sek blandt de 8 testpersoner, som

gennemførte denne del af opgaven. Hurtigste tid er 22 sek, langsomste 2 min 10 sek.

Tabel 3.1a, “Task completion time”: Antal sekunder der går, før et korrekt billede åbnes. Denne del blev løst af på gennemsnitligt 27 sek blandt de 8 testpersoner, som gennemførte

denne del af opgaven. Hurtigste tid er 11 sek, langsomste 1 min 3 sek.

Tabel 3.7, “Other”: Antal søgninger i REX, der bruges på at finde løsningen. 2 ud af 12 = 17% laver 1 søgning i forsøget på at løse opgaven. 4 ud af 12 = 33% laver 2 søgninger i forsøget på at løse opgaven. 1 ud af 12 = 8% laver 3 søgninger i forsøget på at løse opgaven. 4 ud af 12 = 33% laver 4 søgninger i forsøget på at løse opgaven. 1 ud af 12 = 8% laver 17 søgninger i forsøget på at løse opgaven.

Tabel 3.7, “Other”: Antal funktioner afprøvet i forsøget på at finde løsningen. 6 ud af 12 = 50% bruger drop down-menuerne til at raffinere sine søgninger. 4 ud af 12 = 33% bruger Afgrænsningsmenuen til at raffinere sine søgninger. 2 ud af 12 = 17% bruger ingen funktioner til at raffinere sine søgninger.

Den sidste usability-opgave er muligvis den vanskeligste for testpersonerne at løse. Den er ellers enkelt formuleret, alle søgetermer er givet i teksten (georg carstensen, statue, tivoli), og alle testpersoner løser da også det første “completeness”-trin i opgaven på maks. 2 minutter. Det andet trin i opgaven kræver, at testpersonen enten ser ordet “statuer” i navnet på den bibliografiske post med et af fotografierne i, eller stoler på REX og åbner posterne i søgeresultatet fra en ende af.

Det tredje og sidste trin viste sig at være mindst lige så vanskeligt som det andet trin. Flere af testpersonerne udtrykte ærgrelse over, at posterne kun indeholdt billeder af H.C. Lumbye, men løsningen virker så lige for, idet man blot skal scrolle ned i bunden af posten for at finde Georg Carstensen.

67

4.4 Analyse af SUS-spørgeskema

Beregning af SUS-værdiSom nævnt i afsnit 2.5.1d: System Usability Scale, SUS, er de 10 spørgsmål i SUS-spørgeskemaet formuleret skiftevis positivt og negativt, således at hvis testpersonen er konstant i sin ros eller ris af systemet, vil svarene falde på skift i højre og venstre halvdel af de fem svarmuligheder, fra “Meget uenig” til “Meget enig”.

Brooke giver de fem svarkategorier værdi fra 1 til 5, hvor 5 er højest; disse værdier, 1 til 5, er skrevet i spørgeskemaet, så testpersonen kan se dem. I beregningen af systemets Overordnede Usability-værdi ændrer Brooke som det første disse værdier til at gå fra 0 til 4, hvor 4 er højest. Vi mener, at Brooke burde have udfærdiget skemaet sådan, at testpersonerne blev gjort opmærksom på, at skalaen, der reelt anvendes, går fra 0 til 4. Det ville dog skævvride vores SUS-besvarelser, hvis vi ændrede på dette.

Efter at have sat værdierne til at gå fra 0 til 4, finder Brooke gennemsnitsværdien af hver af de 10 spørgsmåls svar-værdier.

Det er vigtigt at huske, at man altid skal vente så længe som muligt i sine beregninger med at lave gennemsnit, da decimal-afrundingen på en gennemsnitlig værdi vokser, når værdien udsættes for multiplikation eller division med andre værdier. Dette bliver relevant senere i specialet, i databehandlingsdelen af IR-evalueringen, men idet SUS’ beregningsmetode kun anvender sum og differens, får denne regel ingen betydning.

Herefter skal der korrigeres for, at hver andet af spørgsmålene er negativt formuleret. Dette gøres simpelt, ved at tage de gennemsnitlige værdier for spørgsmål 2, 4, 6, 8 og 10, og trække hver af værdierne fra tallet 4, hvilket vender skalaen på hovedet, som det kan ses:4 – 4 = 0 4 – 3 = 1 4 – 2 = 2 4 – 1 = 3 4 – 0 = 4

Til sidst beregnes summen af de gennemsnitlige værdier for spørgsmål 1, 3, 5, 7 og 9 og de korrigerede, gennemsnitlige værdier for spørgsmål 2, 4, 6, 8 og 10. Denne værdi giver et resultat mellem 0 og 40. Endelig ganges værdien med 2,5, sådan at den kommer til at ligge imellem 0 og 100. Vi formoder, at dette er for at angive Overordnet Usability i procentpoint.

Vi benytter metoden og får følgende gennemsnitsværdier (vist her med 4 betydende cifre):

Spm1 Spm2 Spm3 Spm4 Spm5 Spm6 Spm7 Spm8 Spm9 Spm101,167 2,167 1,417 2,250 2,167 2,000 2,333 2,333 1,333 2,583

Herefter korrigerer vi for spørgsmålene med negativ ordlyd:

Spm1 4-Spm2 Spm3 4-Spm4 Spm5 4-Spm6 Spm7 4-Spm8 Spm9 4-Spm101,167 1,833 1,417 1,750 2,167 2,000 2,333 1,667 1,333 1,417

Summen af disse 10 tal giver 17,08.Til sidst ganges denne værdi med 2,5, så vi får den Overordnede Usability-værdi:

17,08 • 2,5 = 42,71 procentpoint

68

4.5 Analyse af funktioner og knapper

Vi foretager en funktionsanalyse, hvor vi tæller op, præcis hvor mange testpersoner, som har anvendt hver at REX’ funktioner, og hvor mange gange funktionen er blevet anvendt tilsammen af disse testpersoner.

Vi har ikke udvalgt alle funktioner, links, og knapper i REX, idet de har forskellige funktioner og ikke alle er gyldige for vores brugergruppe og testopgaver. Vi talte sammen, at REX i alt har 115 funktioner, som i princippet alle kan undersøges for, om brugerne ser dem, eller om de er “usynlige”. I langt de fleste tilfælde er en logfil-analyse den eneste rigtige måde at analysere brugen af funktioner på, men som værktøj til at udvikle vores modeller af REX’ websider, som vi optimerer i forhold til usability, er en funktionsanalyse perfekt.

Vi ha valgt, ikke at funktionsanalysen i detaljer for læseren. I stedet kan funktionerne ses i bilag 11, hvor de er skrevet ind som:

Antal testpersoner, som har anvendt funktionen/

Antal gange, funktionen i alt blev anvendt i hele eksperimentet.

Desuden beskriver vi mange af funktionerne, når vi præsenterer vores mock ups og i detaljer beskriver et tonedannende udvalg af de usability-problemer, vi har fundet.

69

Gode og dårlige usability-egenskaber ved

Det Kongelige Biblioteks startside og REX(side 1)

Beskrives i afsnit

Mindre signifikant

problem

Signifikant problem

Katastrofalt problem

Positiv funktion

Forslag til ny funktion

At finde KB’s websiteKB’s webadresser/domænenavne xRanking i Google’s søgeresultater x

KB’s startside, www.kb.dkPladsudnyttelse i bredden xFjern støj og gør siden overskuelig xLav tre informationssøjler xDe to søgebokses placering x“Søg”-knappen som link til REX xDe to søgebokses kontekst xFjern støj i menubjælken x

REX’ startside, ny søgningLad header’en linke til REX xFjern støj i menubjælken xFjern hjælp-funktionen xSøgeboks, placering af “ny søgning” xSøgefeltet og menuernes bredde xDrop down-menuernes indhold xBrugerens personlige boks xForslags-“postkassen” xSidefod x

REX, visning af søgeresultaterKonsistens med REX’s startside xSynliggør Afgræsningsmenuen xResultat-bjælkens proximitet xRelevans-drop down-menuen xPlacering af “Mente du: ?” xDe 4 knapper i bjælken “Resultater” xFå brugerne til at scrolle xUdvidet bladrefunktion xDokumenttype-ikoner xThumbnails af billeder/bogforsider xSynliggør forslagene til ny søgning x

70

(side 2)

Beskrives i afsnit

Mindre signifikant

problem

Signifikant problem

Katastrofalt problem

Positiv funktion

Forslag til ny funktion

Rex, bibliografisk postKonsistens med REX’s startside xKonsistens med REX’ søgeresultater xLink: “Tilbage til søgeresultater” xGør thumbnail af bogforsiden større xUdvidet bladrefunktion x

REX, bibl. post med flere billeder iKonsistens m. andre bibl. poster xJævn afstand mellem billed-links xKnapper: konsistens i valg af blå pile xGør thumbnail af billedet større xAlternativ: Brug en billedfremviser x

Områder med konsistensREX, den øverste del af websitet xMenubjælker i www.kb.dk og i REX xSøgeboks på www.kb.dk og i REX xBegreb: Dokumenttyper / Materialer xBegreb: Kort / Kartografisk data x

Figur 7: En liste over alle de gode og dårlige usability-funktioner, vi har fundet i vores samlede arbejde med REX, det vil sige både inspektionen, som førte til opgavebeskrivelserne, og selve usability testen af vores 13 testpersoner, herunder post test-interviewet.

Summen af egenskaber ved REX nævnt i Error: Reference source not found:

Katastrofale problemer: 2 Signifikante problemer: 10 Mindre signifikante problemer: 12 Positive funktioner: 14 Forslag til nye funktioner: 5

71

4.6 Forslag til usability-forbedringer i REX/Primo’s brugergrænseflade

I det følgende afsnit beskriver vi REX i fire dele, inddelt efter de fire websider, som brugeren kommer igennem, fra vedkommende går ind på Det Kongelige Biblioteks webside, til den fundne bibliografiske post vises i REX.

Vi baserer vores mock ups på en række elementer, for at give et så nuanceret billede af de fundne usability problemer, som muligt, og for at skabe et forslag til KB, som er så altfavnende som muligt, når det kommer til at vælge løsningsmetoder på de usability problemer, vi har observeret.

Usability testen (kvantitative data)o Løsning af opgaver.o Analyse af funktioner og knapper.

Inspektion af systemet, med Det Kongelige Biblioteks Brugergruppe. Molich og Nielsens 10 heuristikker (1990b), bilag 1. Princippet om læseretning (se nedenfor). Gestaltlovene (se nedenfor).

Princippet om læseretningTekst på en computerskærm læses og skimmes i samme retning som på papir. Information der præsenteres “først” i forhold til læseretningen, får normalt størst opmærksomhed.

GestaltloveneEr en psykologisk teori, der blandt andet bliver brugt indenfor usability i computersystemer. Den grundlæggende tese er, at helheder betyder mere end de enkelte dele hver for sig. Man kan få forskellige oplysninger og objekter til at hænge sammen rent visuelt ved brug af gestaltlovene, som i Error: Reference source not found. Gestaltlovene indeholder lovene om nærhed (closeness/ proximity), similaritet og lukkethed (closure) (Nielsen, 1993).

Figur 8: Gestaltlovene (Nielsen, 1993) indeholder lovene om nærhed (closeness/proximity), similaritet og lukkethed (closure).

72

4.6.1 At finde Det Kongelige Biblioteks website

Som beskrevet i afsnit 4.3: Analyse af testpersonernes opgaveløsning, er det nemt at finde Det Kongelige Biblioteks website. 77% af vores testpersoner, 10 ud af 13, anvendte en søgemaskine (og foretrak Google). Kun tre af de 10 prøvede at gætte KB’s webadresse inden da, ingen af dem med succes.

De to webadresser, KB allerede ejer, er nok, det er ikke nødvendigt at tilføje flere.Omvendt er der heller ingen grund til at skille sig af med den ene af de to adresser. Til førstegangsbrugere er www.detkongeligebiblikotek.dk god. Den blev gættet i første forsøg af de resterende 23 %, altså de sidste 3 testpersoner. Den anden adresse, www.kb.dk, er god til de hyppigt tilbagevendende brugere: 2 af de 4 testpersoner, som havde været inde på websitet før, nævnte, mens de tænkte højt, at de godt kunne genkende www.kb.dk, nu da de så adressen stå på skærmen.

4.6.2 Det Kongelige Biblioteks startside, www.kb.dk

Vi har produceret et mock up, som foreslår en gennemgribende ændring af KB’s startside. I dette Speciale, som undersøger hvordan REX/Primo performer, er den mest relevante ændring i forhold til den eksisterende version, et forslag om at gøre søgeboksen på startsiden, som fører ind i REX, mere selvforklarende, ved at give den en større kontekst.

Slå venligst op på bilag 12 og bilag 13 og fold dem ud. Bilag 12 er et screendump af KB’s startside i den eksisterende version. Bilag 13 er vores mock up med forslag til forbedring af usability.

Det Kongelige Biblioteks startside har kun ganske få formål eller funktioner, den skal leve op til. Vi definerer dem således:

1) Være vejviser til resten af KB’s website. 2) Levere nyhedsopdateringer om biblioteket. 3) Reklamere for kommende, kulturelle arrangementer i biblioteket. 4) Fungere med søgefunktion til KB og vejviser til REX.

Hver funktion går igen mange steder. Dette skaber så meget “støj” på websiden, at vi valgte ikke at lade vores testpersoner undersøge funktionerne på selve siden, men kun teste, om det var muligt for dem at finde vej fra websiden ind til REX.

4.6.2a Søgning på www.kb.dkSøgninger på KB’s website foretages af integrated search-systemet Primo. KB behøver således ikke en ekstern søgemaskine som f.eks. Google’s til websitet. Søgeresultaterne vises i REX, og det er ligeledes muligt at søge på KB’s website inde fra REX, (se Error: Referencesource not found nedenfor).

73

Figur 9: Søgning på websites. Til venstre en søgning lavet i www.iva.dk. Sådan ser størstedelen af website-søgninger ud, med “Google Brugertilpasset Søgning”. Til højre ses den samme søgning i www.kb.dk, hvis søgeresultater bliver vist i REX.

Denne dobbeltfunktion Primo har, er snedig for KB rent systemmæssigt - og også for testpersonerne når de lærer at udnytte den - men firmaet Snitker & Co.’s to år gamle usability test af REX/Primo (Snitker & Co., 2008) tydeliggjorde, at brugerne ikke er vant til at kæde de to funktioner sammen. Testpersonerne udtrykte begejstring, men deres søgeadfærd viste, at de aldrig selv var kommet på den tanke at søge i REX efter noget på websitet.

4.6.2b Søgning i REXI usability- testen fik vi den gode oplevelse, at 11 ud af vores 13 førstegangsbrugere,

dvs. 85 %, fandt den blå søgeboks, som viser vej ind i REX, med en gennemsnitstid på 18 sekunder og uden først at forsøge at klikke andre steder end i selve søgefeltet.

De sidste 2 testpersoner, dvs. 15 %, var ikke i stand til at løse opgaven på egen hånd. De behøvede hjælp fra observator til at komme videre. Dette skyldtes i begge tilfælde, at de fór vild i startsidens mange gentagelser.

Den blå søgeboks (som vist i Error: Reference source not found) er i det eksisterende system ganske lav. Som nævnt ovenfor blev den fundet af 85 % af vores testpersoner ved første øjekast og ved første klik på startsiden, på mellem 6 og 41 sekunder. Så søgeboksens ringe højde betyder ikke, at den bliver overset.

Omvendt kan det ikke skade at gøre den større, i håb om at få de sidste 15 % med. I vores mock up bevarer vi de tre dots, som korresponderer med de tre slags søgninger i REX, men vi ændrer beskrivelserne betydeligt. (se Error: Reference source not found nedenfor).

Den første og anden dot skabte stor forvirring allerede for to år siden i Snitker & Co.’s usability test af REX/Primo. Testpersonerne forstod ikke forskellen på “tidsskrifter” og “artikler”, og det på trods af, at testpersonerne var kandidatstuderende, Ph.D’er og forskere (Snitker & Co., 2008). Det er på tide, at KB tager en beslutning om en navneændring, som ikke skaber forvirring hos KB’s brugere. Vi kalder den første dot for “Bøger og andre dokumenttyper”.

I den anden dot tilføjer vi ordet “Videnskabelige” foran “artikler”, i et forsøg på at illustrere, hvilke brugergrupper der har behov at søge i denne del af REX. Desuden tilføjer vi “(kræver login udenfor biblioteket)”, så brugere uden login, heriblandt førstegangsbrugere

74

som vores testpersoner, ikke spilder tid på at prøve at søge i “Videnskabelige artikler”, for så at få besked inde i selve REX om, at de ikke har adgang.

Den tredie dot uddyber vi til “Søg lokalt på hjemmesiden www.kb.dk”. Her har vi en af vores testpersoner i tankerne (TP801) som tog for givet, at når usability- testen gik ud på at teste Det Kongelige Bibliotek, så skulle alle søgninger udføres i “materialer til udlån på www.kb.dk”. Andre brugere kommer muligvis på samme tanke, når de ser www.kb.dk.

Figur 10: Den blå søgeboks. Øverst søgeboksen som fører ind i REX, som den ser ud i det eksisterende system. Nederst vores forslag til en søgeboks som udnytter, at websiden har fået bedre plads, til at levere beskrivelser af de forskellige valgmuligheder, i stedet for at lade brugeren gætte, hvad de dækker over. For at skabe endnu mere konsistens mellem søgeboksen på startsiden og i REX, end der allerede skabes af boksenes placering og baggrundsfarve, har vi indsat REX’ “Søg”-knap.

Vi overvejede at lægge et link til Avanceret Søgning ind i søgeboksen, men vi vil ikke risikere, at brugeren kommer til at vælge Avanceret Søgning, i stedet for at udføre sin søgning direkte i denne søgeboks og på rette vis blive bragt over i Simpel Søgning i REX.Vi er meget tilfredse med, at brugeren bliver ledt over i REX ved at klikke på “Søg”-knappen, uanset om der er skrevet noget i søgefeltet eller ej, hvilket vi selv har anvendt meget. Vi har dog ikke haft nogen mulighed for at teste denne funktion på vores testpersoner.

4.6.3 REX’ startside, ny søgning

Brugeren dirigeres til REX’ startside, når et af de to links på KB’s startside eller et eksternt link til REX følges, eller når brugeren klikker på et af REX’ to links til “ny søgning”.

Søgesystemet REX’ startside er tilpasset i størrelsen til at passe på en almindelig computerskærm, som f.eks. vores 15”-skærm, uden at brugeren behøver at scrolle for at se det nederste af skærmen. Det ses tydeligt i bilag 14, som er et screendump af REX’ startside i den eksisterende version. Bilag 15 er vores mock up med forslag til forbedring af usability.

Slå venligst op på bilag 14 og bilag 15.

75

Vi vælger at inddele REX’ startside ud fra fire områder eller blokke med hver sin funktion: 1) Header og menubjælke2) Søgeboks3) Brugerens personlige boks4) KB’s kontaktoplysninger: Sidefod og Forslags-“postkasse”

Alle fire blokke går igen hele REX, både i visning af søgeresultater og bibliografiske poster. Vi finder, at der kan laves små forbedringer i alle fire blokke, men det eneste sted, vi vores eksperiment har vist os, at der er et katastrofalt problem, er i Søgeboksen.

Drop down-menuerne blev ivrigt benyttet af vores testpersoner, hvilket antyder, at de er placeret hensigtsmæssigt. 62 % (8 ud af 13) anvendte en eller flere af drop down-menuerne.

“Alle materialer” er blevet undersøgt (klikket på) 18 gange i testen, og de 15 gange er en indstilling blevet valgt. Menuen “Som indeholder mit søgeord” bliver undersøgt 12 gange, men kun afprøvet 3 gange. Menuen “Alle felter” blev undersøgt i alt 8 gange, men kun anvendt en eneste gang. Menuen “Alle samlinger/biblioteker” er blevet undersøgt 8 gange og anvendt de 3 gange.

De to links til “Ny søgning” og “Avanceret søgning” er placeret meget langt fra hinanden, i forhold til gestaltloven om nærhed, selv om deres udseende antyder, at de hører sammen (gestaltloven om similaritet) (Nielsen, 1993). Avanceret søgning er placeret langt fra alt andet i søgeboksen, hvilket enten betyder, at brugeren ser linket med det samme, eller at brugerens blik aldrig når derhen.

Vi testede ikke REX’ avancerede søgning, men vi forhindrede heller ikke testpersonerne i at undersøge søgefunktionen under usability testen. Kun én ud af de 12 testpersoner, vi har Morae-optagelsen af, brugte linket til avanceret søgning.

Linket ”Ny søgning” har en yderst problematisk placering, set med vores øjne. Vi anvender princippet om læseretning (Nielsen, 1993), som siger, at information der præsenteres “først” i forhold til læseretningen, normalt får størst opmærksomhed. Vi flytter linket til “Ny søgning”, for at løse et alvorligt usability-problem, som potentielt kan blive til så stor gene for brugeren, at vi klassificerer det som et katastrofalt problem.

76

Figur 11: Søgeboksen i REX. Øverst søgeboksen fra det eksisterende system. Nederst et mock up, hvori vi har lavet tre synlige ændringer og løst tre usability-problemer: At “Alle felter” bliver overset, at “Tip: Brug * som wildcard” optager plads uden at være nødvendig, og det katastrofale problem, at flere testpersoner klikkede på “Ny søgning” i stedet for “Søg”-knappen og måtte begynde helt forfra.

Vi anvender fortsat princippet om læseretning (Nielsen, 1993). Tekst på en computerskærm læses og skimmes i samme retning som på papir. I den eksisterende søgeboks betyder det, at brugeren:

Begynder i søgefeltet og skriver sine søgetermer, Foretager sine ændringer i første række drop down-menuer, Foretager sine ændringer i den nederste drop down-menu, Lader øjnene springe videre ned ad “linjerne på papiret”, spotter et ord, som

indeholder bogstaverne s ø g, og klikker på “ny søgning”, inden øjet får nærlæst.

42 % (5 af 12) oplevede dette. For to af de fem testpersoner sker det tre gange, så det er ikke engang en engangshændelse. Flere af testpersonerne tænkte højt imens, så vi kender deres egen fortolkning af hændelserne. De udtrykker alle sammen overraskelse, en af dem påstår, at REX har smidt ham af (altså haft en systemfejl), de resterende fire forstår slet ikke hvad der er sket, de tror simpelthen, at de har udført deres søgning og har fået 0 søgeresultater, så de prøver at søge på nye søgetermer bagefter.

Vi betragter dette som et katastrofalt problem, da det satte testpersonerne tilbage til nul i deres informationssøgning, og skabte forvirring efterfulgt af frustration, som til sidst udmundede i manglende lyst til at bruge systemet igen og en negativ holdning til hele REX. Dette fremgik senere i SUS-spørgeskemaet og i udtalelserne i post test-interviewet.

Vi håber at løse problemet ved at flytte de to links op ovenfor søgefeltet, som i den eksisterende søgeboks står “først”. “Avanceret søgning” flyttes for at sikre linkets synlighed, og ”Ny søgning” ud fra de angivne begrundelser.

77

4.6.4 REX, visning af søgeresultater

Vi oplevede i vores usability test, at testpersonernes største svaghed og dermed websidens største usability-problem er testpersonernes manglende opdragelse i at søge i et system som REX/Primo, som ikke (eller næsten ikke) opererer med fuldtekst, men med bibliografiske poster.

Det gælder først og fremmest uvanen fra søgemaskiner som Google, som lærer brugerne, at de relevante søgeresultater er placeret blandt de første måske tre søgeresultater. Tre er i hvert fald det omtrentlige tal, vores testpersoner har haft tålmodighed til at undersøge i mange af deres informationssøgninger.

Lige nu tillader REX kun meget begrænsede muligheder for at bladre. Vi foreslår en mere synligt placeret, mere avanceret søgefunktion, som forhåbentlig vil gøre det mere tillokkende for brugerne at bladre i søgeresultaterne.

Slå venligst op på bilag 16 og bilag 17 og fold dem ud. Bilag 16 er et screendump af KB’s startside i den eksisterende version. Bilag 17 er vores mock up med forslag til forbedring af usability.

I et lukket system som REX, der ikke nødvendigvis tilføjer nye poster hver eneste dag, er det muligt at lave en søgning, kigge de første måske 180 søgeresultater igennem, vende tilbage dagen efter, lave den samme søgning og så slå op på side 19 og fortsætte med de næste 180 søgeresultater, uden der er kommet ændringer til. På denne måde kan forskere f.eks. gennemgå samtlige søgeresultater for at være sikker på, at dataindsamlingen er baseret på udtømmende søgninger.

Kravet til REX er i denne henseende, at man kan springe i sine søgeresultater. Det kan man ikke i det nuværende system.

Figur 12: Den nuværende bladrefunktion har vist sig at være usynlig for 67% af vores testpersoner. Princippet om læseretning placerer årsagen til dette hos “Næste”-knappen, som er anbragt helt ude til højre i vinduet, længere til højre end noget tekstafsnit.

Vores usability test viste, at kun 33% af testpersonerne (4 ud af 12) valgte at bladre i søgeresultaterne. De resterende 67% så aldrig mere end 10 resultater.

Dette er vi nødt til at tolke som, at det er vanskeligt for brugeren at se knappen “Næste” i det eksisterende system. Vi er overbeviste om, at det skyldes placeringen af knappen helt ude i højre side (Princippet om læseretning, Nielsen, 1993).

78

Brugeren er i færd med at læse ned over siden/søgeresultaterne, og blikket ryger ikke på noget tidspunkt så langt ud til højre, men fortsætter lige nedad og ser i stedet tekstboksen “Prøv også”, som indeholder linket “Søg på 'benny andersen' i bibliotek.dk”. 75 %, 9 ud af 12 testpersoner, var på vej ind i bibliotek.dk eller nåede derind, inden observator fik stoppet dem. Sammenlagt forsøgte de 9 personer at “flygte fra REX” 16 gange.

Vi foreslår, at KB kopierer den metode, som anvendes i to af deres offentligt tilgængelige billeddatabaser, og som ser sådan her ud:

………………………………………………………………………………………………

Figur 13: Bladrefunktionen i REX, som vi kunne forestille os den i vores mock up. Knapperne til at bladre er vist både over og under listen med søgeresultater, og knapperne står samlet, frem for at stå helt yderst i hvert sit hjørne, hvor brugerens blik aldrig når ud.

Metoden med at have sidetal stående inde i et skrivefelt, kender de fleste, for ikke at sige alle, computerbrugere fra den gratis software Adobe Acrobat Reader. For at springe til en ny side, skal brugeren klikke i skrivefeltet, skrive et nyt sidetal og trykke Enter.

Det er ikke et krav fra vores side, at KB implementerer denne form for skrivefelt. En liste af sidetal og tegn kunne være nok, for eksempel:

<< < 42 43 44 45 46 47 48 49 50 51 52 > >>

Det vigtigste er, at brugeren har mulighed for at springe imellem siderne med søgeresultater, helst med større interval end i taleksemplet lige herover, hvor man kan springe fem sider frem af gangen. Og at brugeren har mulighed for at bladre én side frem og tilbage eller for at gå helt tilbage til det første resultat eller helt frem til det sidste.

Og så synes vi som søgeeksperter, at det er vigtigt, man kan få lov at bladre både i toppen og bunden af søgeresultaterne. Som eksempel kan man i det eksisterende REX sortere sine søgeresultater efter udgivelsesår, og i Afgrænsningsmenuen afgrænse efter et årti, f.eks. ”Efter 2000”. I screen dump’et af søgeresultaterne for Benny Andersen, bilag 16 (og i vores mock up af samme, bilag 17) ses det, at hvis søgningen blev afgrænset til “Efter 2000”, er der stadig 184 resultater at kigge igennem. Hvis brugeren ønsker at bladre igennem alle udgivelser fra 2004-2006 (et interval, der ikke er dækket i Afgrænsningsmenuen), er der ingen grund til at tvinge testpersonen til at scrolle ned over siden med søgeresultater, for at kunne nå bladre-funktionen.

79

4.6.5 Bibliografisk post, bog

Fra listen over søgeresultater ledes brugeren ind i “Detaljer”, som er REX/Primo’s præsentation af den bibliografiske post. I udvalgte poster med bøger vises bogens forside som thumbnail, men de er så små, at det er meget vanskeligt at se, hvad de forestiller.

Slå venligst op på bilag 18 og bilag 19 og fold dem ud. Bilag 18 er et screendump af KB’s startside i den eksisterende version. Bilag 19 er vores mock up med forslag til forbedring af usability.

Error: Reference source not found herunder viser et udsnit af de to øverste søgeresultater fra mock up’en af Benny Andersen-posten. Vi valgte blandt andet Benny Andersen som søgeterm for usability testens opgave 2a, fordi halvdelen af de 10 søgeresultater på side 1 er illustrerede med en bogforside. Og alle disse bogforsider er hvide.

I post test-interviewet blev testpersonerne spurgt, om de kunne huske at have set nogen bogforsider eller bare grafik, da de søgte efter Benny Andersen. 100% svarede nej til dette, også da interviewer gentog søgningen for dem på computerskærmen.

Figur 14: Thumbnail i bibliografisk post, her af bogforsider (søgeresultat nummer to, når der søges på Benny Andersen). Vi flytter linket “Bestil (Klik her)” for at få plads til den større bogforside, men resten af teksten i posten kan blive stående uden problemer. Vi har fundet en Benny Andersen-forside, der ikke er hvid, til vores mock up.

80

Som vi havde forudset, da vi lavede en inspektion af REX, en slags uformel, heuristisk evaluering (Molich, 2007), virker det umuligt for testpersonerne at nå at lægge mærke til de thumbnails, som falder i et med baggrunden p.g.a. deres farve.

Det ville sandsynligvis have haft stor betydning for testpersonernes svar, hvis vi havde guidet brugerne til at finde et sæt søgeresultater, hvis bogforsider var farvestrålende og ikke kridhvide. Og det havde været en mere retfærdig test af REX. Men i forhold til dette usability-problem har vi tilladt os at skære vores pointe ud i pap.

Til vores mock up har vi fundet en bogforside af Benny Andersen, som ikke er kridhvid, så det er tydeligt at se forskel på de to thumbnails’ størrelser.

Vi anbefaler KB at få lagt en diskret ramme rundt om alle thumbnails (bogforsider og billeder) af denne praktiske årsag, og vi anbefaler, at thumbnails får lov at fylde så meget i højden som muligt indenfor søgeresultatets rammer (de stiplede linier), især fordi 100% af vores testpersoner har efterspurgt mere synlige thumbnails, da de løste opgave 3, 4 og 5.

Vores forslag gælder ikke kun for thumbnails i de bibliografiske poster. Det vil blive endnu hurtigere og nemmere for brugerne at se, om de har fundet et materiale de kan bruge til noget, hvis de allerede ude i listen med søgeresultater bliver præsenteret for thumbnails, som er kantet med en ramme og gjort så store, som det kan lade sig gøre på den begrænsede plads.

4.6.6 Bibliografisk post, samling af fotografier

Som nævnt i afsnit 4.2: Gennemgang af usability testens opgaver, adskiller billeder sig fra de andre dokumenttyper, idet de bibliografiske poster kan indeholde langt flere end et billede. 5-15 billeder er ikke unormalt.

Slå venligst op på bilag 20 og bilag 20 og fold dem ud. Bilag 20 er et screendump af KB’s startside i den eksisterende version. Bilag 21 er vores mock up med forslag til forbedring af usability.

I usability testens sidste opgave, Opgave 5, oplevede vi, at to store og gennemgående usability-problemer begge spillede ind på samme tid og sted:

Testpersonerne foretrækker, ikke at scrolle og er tydeligvis ikke vandt til at behøve at scrolle langt ned i søgeresultater, når de udfører almindelig informationsssøgning i Google eller andre internetbrowsere.

Testpersonerne er ikke klar over, at de bibliografiske poster i REX kan indeholde flere end ét dokument, hvilket da også er forbeholdt billedposter. Og REX har ingen måde at gøre testpersonen opmærksom på dette på, så testpersonen må selv regne det ud.

Disse to usability-problemer i samme opgave, gør at mange af testpersonerne bliver frataget muligheden for at gennemskue og løse det problem, de er blevet stillet. Det mest frustrerende som observator er at vide, at testpersonen ved blot at scrolle ned over siden kunne løse opgaven i løbet af få sekunder (hurtigste tid er 11 sek), og så samtidig opleve, at testpersonen er helt uvidende om dette. Vi hæver de to nævnte usability-problemer til

81

katastrofale problemer, fordi de efterlader brugeren helt uvidende om, at brugergrænsefladen (og førstegangsbrugerens manglende OPAC-opdragelse) er skyld i, at søgningen ikke giver nogen resultater.

Figur 15: Billedfremviser. Vi foreslår en mere radikal måde at vise billederne i en billedpost på, end blot at forstørre thumbnail’en. Indsæt billedfremviseren, som KB allerede har implementeret i deres fotografiske database, “Danmarksbilleder”.

Vi foreslår en løsning på problemet med at få brugerne til at indse, at billedposter indeholder flere end ét billede. Vores løsning i dette mock up er mere radikal end nogen af de andre, idet vi ikke blot tager de funktioner, som allerede findes på websiden, men tilføjer en helt ny funktion, nemlig en billedfremviser.

Denne billedfremviser, som ses på Figur 15, er taget fra en af Det Kongelige Biblioteks billeddatabaser, “Danmarksbilleder”, som vi har testet for KB, samtidig med at vi har udført usability testen af REX/Primo. Derfor kan vi udtale os om, at størstedelen af vores testpersoner forstod billedfremviseren og var i stand til at bruge alle dens funktioner:

13 ud af 13 testpersoner forstod at bruge zoom-funktionen. 9 ud af 13 testpersoner fandt linket til at vise billedet i fuldskærm i nyt vindue. 7 ud af 13 testpersoner prøvede at bruge bladre-funktionen med held.

Hvis det er muligt for KB at indføre billedfremviseren i REX/Primo og på dét sted, vi foreslår (hvor der i øvrigt ikke er nogen anden funktion på nuværende tidspunkt), så vil det med stor sandsynlighed kunne løse det største usability-problem, vi har fundet i REX/Primo.

82

4.7 Delkonklusion

I SUS-spørgeskemaet finder vi, at den Overordnede Usability-værdi ligger på 42,71 procentpoint. Dette tal ligger nogenlunde pænt, kun 7% under middelværdien, men det havde bestemt været bedre, hvis tallet havde været højere end 50%.

Vi har forsøgt at få adgang til usability-firmaet Snitker & Co’s indsamlede data fra 2008 til sammenligning, men uden held.

Når man læser den Overordnede Usability-værdi er det vigtigt at huske på, at vi i usability testen har ladet testpersonerne udføre et opgavesæt, som adskiller sig en del fra normal søgeadfærd i en OPAC som REX. I en af opgaverne beder vi testpersonerne finde et billede over et område i Danmark uden at vi kan vide, om de vælger at søge efter et landområde, der findes digitaliserede billeder af i REX. Og i en anden opgave lader vi testpersonen udføre en søgning på en kendt, dansk person, hvis navn de skal foregive at have glemt. Den slags søgeopgaver er REX slet ikke udformet til at kunne håndtere, de hører nærmere til i internet-søgemaskiner. Derfor var det forudsigeligt, at brugerne ville vurdere REX til at være utilfredsstillende i forhold til den søgesession, de har udført.

Vi bruger disse opgaver til at observere brugernes søgeadfærd, hvilke funktioner til afgrænsning, de vælger at inddrage i deres informationssøgning, og hvor høj deres indlæring af disse funktioner er, når de kommer til at lave den samme slags søgning flere gange, med en lille variation, f.eks. at søge efter billeder i de to ovennævnte eksempler.

Når SUS-spørgeskemaet måler, at testpersonernes gennemsnitlige, subjektive tilfredsstillelse er 42,71 procentpoint, er det altså i højere grad et udtryk for, hvor gode testpersonerne selv har været til at få REX til at arbejde for sig, ved selv at udvikle kreative søgestrategier. Og imens har vi fået indsamlet nok data til vores analyse af anvendte funktioner og usability-problemer.

Hvad vi har ofret af brugernes utilfreds med systemet på grund af udførslen af svære og skæve testopgaver, det har vi vundet i dataindsamling af anvendte funktioner og søgeadfærd. Disse oplysninger bruger vi til at foreslå 6 mock ups, én til hver af de websider, som vores testpersoner er stødt på i REX/Primo.

Vi har præsenteret et usability-problem for hver webside, som er typisk for websiden. Vi har i alt fundet 24 usability-problemer, men vi har også observeret 14 funktioner, som er meget positive og som testpersonerne anvendte uden problemer. Og vi kommer med 5 forslag til helt nye funktioner eller nye måder at anskue REX på. Disse gode og dårlige usability-punkter kommer vi ikke mere ind på i dette speciale, men vi arbejder på en rapport til Det Kongelige Biblioteks Brugbarhedsgruppe, som i detaljer beskriver samtlige punkter og kommer med konstruktive forslag ud fra vores mock ups og beskrivelser.

83

5 METODE OG ANALYSE – IR EVALUERING (JBJ)

I denne del af opgaven vil vi først gennemgå metoden bag hvordan vi har behandlet vores data. Vi præsenterer Pre Task-spørgeskemaet og forklarer, hvorfor vi har valgt netop disse spørgsmål. Vi præsenterer de to instrumenter, som vi anvender til at analysere dataene fra IR evalueringen. Vi begynder med teorien bag Cumulated Gain (CG) og redegører for, hvordan vi anvender beregningerne på vores data. Derefter præsenterer vi Mean Reciprocal Rank (MRR) og forklarer, hvordan vi anvender dette instrument.

I de efterfølgende afsnit analyserer vi vores data ved hjælp af CG og MRR og nærmer os en besvarelse af nogle af forskningsspørgsmålene for dette speciale. Vi slutter denne del af med at opsummere og konkludere på IR-delen af specialet.

5.1 Metode

I dette afsnit vil vi først gennemgå fremgangsmåden for vores IR evaluering. Derefter vil vi gennemgå dataene fra Pre Task-spørgeskemaet og redegøre for besvarelserne. Vi introducerer måleinstrumenterne Cumulated Gain (CG) og Mean Reciprocal Rank (MRR) enkeltvis, hvor vi også redegører for hvordan vi har anvendt instrumenterne og hvordan vi har foretaget beregningerne på vores egne data.

5.1.1 Fremgangsmåde for vores IR evaluering

Efter at testpersonerne er blevet interviewet, bliver de bedt om at relevansvurdere en række bibliografiske poster, som vi har fundet frem fra REX/Primo. I dette afsnit vil vi beskrive, hvordan vi udførte vores IR evaluering.

Vi har udformet tre forskellige Work Tasks og dertilhørende søgestrenge. Søgninger har vi foretaget på forhånd, dermed skal testpersonerne ikke selv søge efter et svar på en given Work Tasks. Fremgangsmåden for evalueringen er, at testpersonerne får udleveret den første Work Task sammen med et spørgeskema, hvor de fortæller os hvor meget de kender til emnet og hvor spændende de synes det er. Vi har gemt de første 30 søgeresultater i powerpoint-programmet fra Open Office. Derved undgår vi eventuelle fejl, såsom nedbrud af webside eller internetforbindelse, der kan opstå i forbindelse med, at hele evalueringen kører online i REX/Primo. Desuden, så sikrer vi, at vi har de samme 30 bibliografiske poster i den rigtige rækkefølge til alle 13 testpersoner.

Vi beder testpersonerne relevansvurdere de enkelte bibliografiske poster ud fra deres egen fortolkning af Work Taskens ordlyd. Derudover, så skal de se på hver enkelt post, som om, at det er første gang de ser et dokument om det emne. Relevansvurderingerne gemmer vi i et excel-ark. Evalueringen bliver optaget med Morae (jf. afsnit 3.3: Morae), dermed har vi mulighed for at dobbelttjekke mulige fejl i relevansbedømmelserne. F.eks kan et dokument være blevet bedømt to gange, eller der mangler en relevansbedømmelse ved et dokument.

84

5.2 Pre Task-spørgeskema

I dette afsnit gennemgår vi Pre Task-spørgeskemaet og redegør for de spørgsmål, som vi har valgt at anvende.

Spørgsmålene fra Pre Task-spørgeskemaet har vi fra et andet spørgeskema, der oprindeligt bliver brugt i forbindelse med INEX. Pågældende spørgeskema indeholder flere spørgsmål end dem, som vi har valgt at anvende. Vi har i afsnit 2.9.3beskrevet hvad INEX handler om. Vi har valgt at oversætte vores udvalgte spørgsmåls til dansk, fordi at vi ikke kender vores testpersoners engelsk-kundskaber. Vi har ikke oversat spørgsmålene direkte, men i stedet oversat meningen.

Der er to spørgsmål i vores Pre Task- spørgeskema og formålet med disse er at afdække testpersonernes kendskab til og interesse i de tre Work Tasks. Spørgeskemaet, sådan som det bliver udleveret til vores testpersoner kan ses i bilag 22. Testpersonerne bliver bedt om at besvare Pre Task- i forbindelse med IR evalueringen, hvor de først læser Work Task’en igennem og umiddelbart derefter besvarer spørgeskemaet. Derefter foretager de relevansvurderingerne. Dette gentages to gange mere, i det at vi har tre Work Tasks i alt. I afsnit 5.3: Work Tasks til IR evaluering beskriver vi vores Work Tasks nærmere.

De to

ovenstående spørgsmål bliver besvaret af os, så vi selv kan holde styr på, hvilke testpersoner, der har besvaret hvad. Dette gør vi, fordi at vi roterer Work Task’ene og derudover har randomiseret de poster, som testpersonerne skal relevansvurdere. Vi forklarer randomiseringen og rotationerne nærmere i afsnit 5.4: Randomisering og rotation.

Meget uenig UenigHverken enig eller uenig Enig Meget enig

01. "Jeg er godt bekendt med opgavens emne”

Spørgsmål 1 har til formål at afdække hvor meget den enkelte testperson kender til emnet for pågældende Work Task. Det er klart, at en testperson som kender emnet meget godt også vil

Spørgeskema til Search task A B C(sæt ring om den rigtige)

Search task udført som den 1. 2. 3. af testpersonen(sæt ring om den rigtige)

85

have lettere ved at gennemskue hvad de enkelte bibliografiske poster indeholder. En testperson som intet kender til emnet, vil muligvis have sværere ved at gennemskue de samme poster. Derfor forventer vi, at testpersonerne vil relevansvurdere de enkelte poster forskelligt.

Meget uenig UenigHverken enig eller uenig Enig Meget enig

02. "Jeg synes, at opgavens emne er interessant”

Spørgsmål 2 handler om testpersonernes interesse for emnet. Vi forventer, at folk som har en interesse for emnet også vil være mere koncentrerede og opmærksomme, når de foretager relevansvurderingerne. De testpersoner, som muligvis har mindre interesse i emnet, vil ikke være helt så koncentrere og måske endda skynde sig igennem. Dette vil være endnu et grundlag for, hvorfor der kan være stor forskel på relevansvurderingerne.

Pre Task-spørgeskemaet bliver afsluttet med et kommentarfelt, hvor testpersonerne har mulighed for at uddybe deres besvarelser.

5.3 Work Tasks til IR evaluering

En Work Task er med et dansk ord, en opgavebeskrivelse. Som tidligere nævnt, foretog vi søgningerne til vores IR evaluering på forhånd. Vi har med andre ord foretaget de indledende Search Tasks, hvor vi fandt frem til de bedst egnede søgestrenge og emner til vores testpersoner, så de kan løse Work Task’ene. Et vigtigt kriterium for vores søgninger var, at resultaterne skulle indeholde mindst tre forskellige dokumenttyper inden for de første tredive hits. Det var den eneste måde vi kan sikre, at vi får undersøgt, hvordan de enkelte dokumenttyper performer i REX/Primo (jf. bilag 23).

Formålet med en Work Task er, at give testpersoner et informationsgrundlag, så de har mest mulig viden til at kunne løse en given opgave. I vores eksperiment er Work Task’ene simulerede, hvilket betyder, at de er opdigtede opgavebeskrivelser som skal give testpersonerne et kontrolleret informationsbehov (Ingwersen & Järvelin, 2005).

En Work Task bør, ifølge Borlund & Ingwersen (1997, side 229), indeholde og beskrive følgende elementer:

1. the source of need 2. the environment of the situation 3. the problem which has to be solved 4. serves to make the test person understand the objective of the search.

Vi anvender de fire punkter som en tjekliste, så vi kan kontrollere, at testpersonerne har de mest optimale muligheder for at forstå baggrunden bagved hver enkelt søgning og derved give den bedst muligt relevansvurdering.

86

Vi er ikke erfarne i at udforme Work Task scenarier, derfor brugte vi også den første testperson som testpilot på vores Work Tasks. Vi bad ganske enkelt vedkommende om at komme med forslag til forbedringer eller ændringer, som kunne gøre forståelsen af de enkelte opgaver nemmere. Der vil dog stadig være mulighed for, at testpersonerne har tolket Work Task scenarierne forskelligt, på samme måde som relevans er en subjektiv og situationel holdning.

Der findes 8 typer Work Tasks, ifølge Ingwersen & Järvelin (2005):• Known item• Known data element• Known topic or contents• Factual data• Muddled item• Muddled data element• Mudddled topic or contents• Muddled factual

”Known item” betyder, at man søger efter en bestemt bog, artikel, film og lign. Det kan også være dele af et dokument. ”Know data element” betyder, at man søger efter efter et bestemt stykke information. Dette kan være en adresse, email-adresse, telefonnummer synonyme ord o. lign. ”Known topic og contents” betyder, at man søger efter information om et bestemt emne, f.eks Anden Verdenskrig. Det kan også være indspilninger af et bestemt stykke musik. ”Factual data” betyder, at man søger efter et svar på et specifikt spørgsmål.

De sidste fire typer på ovenstående liste er de uklare udgaver af de første fire typer. Man kan med andre ord sige, at der findes to kategorier af Work Tasks; veldefinerede informationsbehov og mudrede / uklare informationsbehov (Ingwersen & Järvelin, 2005).

Ved at have fulgt listen fra Borlund & Ingwersen (1997), undgår vi at anvende de typer Work Tasks, som er mudrede (muddled).

Nedenfor findes de tre Work Task, som vi kreerede til vores IR evaluering. Bilag 23 er de tre Work Tasks, sådan som testpersonerne fik dem udleveret. Overfor testpersonerne, kaldte vi Work Task’ene ”opgavebeskrivelser”.

5.3.1a Work Task A:

I kassen nedenfor står hele beskrivelsen for Work Task A. Work Task A definerer vi som “Known topic”, fordi emnet er Knud Rasmussen og hans ekspeditioner til Thule.

87

5.3.1b Work Task B:

Work Task B derfinerer vi som “Known item”, fordi task’en handler om at finde indspilninger, billeder og andet af komponisten Carl Nielsen.

5.3.1c Work Task C:

Work Task C definerer vi som “Known topic”, fordi besvarelsen handler om at finde materiale som handler om personlige beretninger fra Danmarks befrielse og besættelse.

Vi har valgt at anvende tre Work Tasks til IR evalueringen, fordi vi ønsker at få et nuanceret billede af relevansalgoritmen og hvordan den performer i REX/Primo. Dette billede ville vi ikke kunne opnå ved kun af bruge en enkelt Work Task. Vi afprøvede lidt forskellige antal og valgte antallet tre, fordi at IR evalueringen dermed kunne gøres på cirka en halv time.

Som nævnt tidligere, foretog vi selv søgningerne. Testpersonerne skal dermed ikke besvare Work Taskene ved selv at søge efter et svar, men i stedet undersøge udvalgte

Work Task A:Din nevø har været på ekspedition til Thule i Grønland, hvor han har været i Knud Rasmussens fodspor. Han har fået gjort dig interesseret i selv, måske en dag, at foretage en sådan ekspeditionsrejse i Grønland. For nu er din egen interesse mere akademisk: Du vil gerne vide noget om Knud Rasmussens egne Thule-ekspeditioner, så du kan diskutere med, når din nevø fortæller om ”alle de ting, han og Knud Rasmussen har oplevet”.

Work Task B:Du er blevet inviteret til en Carl Nielsen-koncert af din søster. Du kender dog ikke ret meget til den gamle danske komponist. Du vil gerne imponere din søster med din viden om Carl Nielsen og er derfor nu gået i gang med at finde billeder, bøger, kompositioner og andet om ham.

Work Task C:Din ven er i gang med at skrive en bog om Danmarks befrielse og besættelse, som handler om personlige historier fra den tid. Han har ansat dig som assistent og har bedt dig hjælpe med researchen. Du er derfor i gang med at finde materiale til bogen.

88

bibliografiske poster og relevansvurdere disse efter hvor godt den enkelte post kan besvare opgaven i en given Work Task.

5.4 Randomisering og rotation

For at sikre den bedst mulige blanding af dokumenter og Work Tasks, har vi randomiseret dokumenterne og roteret Work Task’ene.

Vi blandede søgesresultaterne, altså de enkelte bibliografiske poster, ved at lave 30 små sedler med et nummer på. Vi blandede sedlerne i en skål og trak sedlerne op enkeltvis. Dette gjorde vi tre gange og fik på den måde randomiseret søgeresultaterne tre gange.

Vi blandede derudover de tre tasks indbyrdes og trak en tilfældig udgave af hver task, inden testpersonerne skulle arbejde med dem. Ved at rotere de tre Work Tasks, har vi sikret, at søgeresultaterne er blevet så blandede som muligt. Nedenstående tabel (

Error: Reference source not found) viser hvordan de tre tasks og randomiseringer er blevet fordelt over vores testpersoner. Bilag 24er en tabel over, hvordan søgeresultaterne har placeret sig efter randomiseringerne.

Ved pilottesten havde vi endnu ikke færdiggjort vores randomisering og rotation og testpersonen har derfor relevansbedømt søgeresultaterne i rækkefølge efter hvordan REX/Primo spyttede dem ud, derfor står der ”0” ud for Work Task’ene ved TP801. Vi fortalte dog til testpersonen, at vi havde blandet dokumenterne.

Testpersoner Work TasksTP801 A0 B0 C0TP802 A1 B1 C3TP803 A2 B3 C1TP804 B2 C1 A3TP805 C1 B2 A3TP806 B2 C3 A1TP807 B3 A1 C2TP808 C2 A2 B3TP809 A3 B1 C2TP810 A1 C2 B1TP811 B1 C3 A2

89

TP812 C3 A3 B3TP813 C3 A2 B2

Figur 16: Fordeling af rotationer og randomiseringer for vores Work Tasksog tilhørende bibliografiske poster.

5.5 Relevansskala

Vi har valgt at anvende 4 kategorier i vores relevansskala. Dette har vi valgt at flere grunde. Først og fremmest, så vil vi undersøge vores resultater ved at anvende Cumulated Gain, derfor skal vi bruge en relevansskala, som kan gå fra f.eks. 0-3. Dette udelukkede INEX skalaen, som har fem punkter og hvor skalaen mere er formet som et T, som det også kan ses på figuren nedenfor.

Figur 17: INEXs relevanskategorier. Fra Malik, Tombros og Larsen (2007). Som det kan ses på figuren, anvender INEX fem meget forskellige kategorier. Der er tale om fem meget forskellige relevanstyper

90

For at kunne anvende Cumulated Gain til behandling af vores data fra IR evalueringen, skal vi bruge en lineær skala. Her har vi valgt at anvende en fire-punkts skala, meget lig Sormunen’s skala (2000, side 63):

• Totally of target• Marginally relevant, refers to the topic but does not convey more information

than the topic description itself• Relevant, contains some new facts about the topic• Highly relevant, contains valuable information, the article’s main focus is on

the topic.

Vi har taget udgangspunkt i Sormunen’s skala ovenfor og oversat kategoriernes navne til dansk. Vi anvender Sormunen’s værdier sammen med de fire punkter, som vi anvender Cumulated Gain til databehandlingen (jvf afsnit 5.7: Cumulative Gain (CG)). Sormunen (2002) beskriver i en senere udgivelse, hvad der ligger bag de enkelte relevanskategorier, som vi har beskrevet nedenfor. Vi anvender disse definitioner som grundlag for vores kategorier i relevansskalaen:

• Dokumentet indeholder ingen information om emnet.• Dokumentet indeholder kun en enkelt sætninger eller fakta om emnet.• Dokumentet indeholder mere information om emnet end der er nødvendig, eller det

indeholder kun dele af den information som er ønsket.• Dokumentet indeholder tilpas med information til at dække emnet, eller det indeholder

nok information til at kunne dække informationsbehovet.

Vores egen relevanskala findes nedenfor. Vi har valgt, ikke at oversætte kategoriernes engelske navne direkte, men i stedet valgt nogle lidt andre navne. Definitionen af, hvad kategorierne indeholder, er dog stadig den samme som Sormunen har beskrevet og som står nævnt ovenfor. Vi forklarede testpersonerne inden de gik i gang med IR evalueringen, hvad vi mente med de forskellige kategorier, og hvordan relevansværdierne ligger fordelt.

Figur 18: Vores relevansskala, som vi anvender i IR evalueringen.

0 = Ikke-relevant1 = Delvist ikke-relevant2 = Delvist relevant3 = Relevant

91

92

5.6 Databehandling af Pre Task- Spørgeskema

I dette afsnit præsenterer vi testpersonernes kendskab og interesse for emnerne i de tre Work Tasks. Dataene har vi fra Pre Task-spørgeskemaet, som vi præsenterede i afsnit 5.2. Figur 19 nedenfor illustrerer, hvor meget testpersonerne kendte til emnerne, inden de gik i gang med IR evalueringen. Vi gennemgik Work Task’ene og deres indhold i afsnit 5.3: Work Tasks tilIR evaluering.

Figur 19: Fordeling af testpersonerns kendskab til emnerne for de tre Work Tasks.

Figur 19 viser, hvor meget testpersoner kendte til de enkelte emner i de tre Work Tasks, inden de gik i gang med IR evalueringen. Det er tydeligt, at de havde det største kendskab til Work Task C, som handler om besættelsen og befrielsen af Danmark. Kendskabet til de to andre Work Tasks ser ud til at være lige fordelt ved, at den ene halvdel kendte til emnet i mere eller mindre grad og den anden halvdel intet kendte til emnet, eller ikke kunne tage stilling.

Fordeling af testpersonernes kendskab til emne for Work Task

Meg

et u

enig

Meg

et u

enig

Meg

et u

enig

Uen

ig

Uen

ig

Uen

ig

Hve

rken

elle

r

Hve

rken

elle

r

Hve

rken

elle

r

Eni

g

Eni

g

Eni

g

Meg

et e

nig

Meg

et e

nig

Meg

et e

nig

0

1

2

3

4

5

6

7

A B C

Work Task

Anta

l

Meget uenig

Uenig

Hverken eller

Enig

Meget enig

93

Fordeling af testpersonernes interesse for emne i Work Task

Meg

et u

enig

Meg

et u

enig

Meg

et u

enig

Uen

ig

Uen

ig

Uen

ig

Hve

rken

elle

r

Hve

rken

elle

r

Hve

rken

elle

r

Eni

g

Eni

g

Eni

g

Meg

et e

nig

Meg

et e

nig

Meg

et e

nig

0

1

2

3

4

5

6

7

8

9

A B C

Work Tasks

Anta

l tes

tper

sone

r

Meget uenigUenigHverken ellerEnigMeget enig

Figur 20: Fordeling af testpersonernes interesse for emnerne i de tre Work Tasks.

Figur 20 viser, hvor meget testpersoner havde interesse i de enkelte Work Tasks’ emner, inden de begyndte IR evalueringen. Igen er det tydeligt, at Work Task C er den mest populære. Der er også interesse for Work Task B, som handler om komponisten Carl Nielsen, og for Work Task A, som handler om Knud Rasmussen og sine ekspeditioner til Thule. Så selvom, at testpersonerne ikke kender lige meget til alle emnerne, så viser den sidste graf overordnet set, at testpersonerne har en positiv interesse for vores emner. Dette tager vi som et godt tegn på, at de vil gå til de enkelte opgaver med en positiv indstilling, og ikke føle, at forsøget er en sur pligt.

94

5.7 Cumulative Gain (CG)

Vi anvender CG til at undersøge performance af relevans-algoritmen i REX/Primo. Relevansalgoritmen er den algoritme, som REX/Primo anvender som standard indstilling til at sortere søgeresultater efter.

Cumulative Gain (CG) blev udviklet af Järvelin og Kekäkeläinen (2002) og første gang præsenteret i 2001. Der findes forskellige typer af Cumulated Gain, vi anvender tre forskellige; Cumulated Gain (CG), ideal Cumulated Gain (CGi) og normalised Cumulated Gain (nCG).

Järvelin & Kekäkeläinen beskriver, hvordan CG beregnes:

“...the relevance score of each document is somehow used as a gained value measure for its ranked position in the result and the gain is summed progressively from ranked postion 1 to n. ... The cumulated gain at ranked position i is computed by summing from position 1 to i, when i ranges from 1 to 200.” (Järvelin & Kekäläinen, 2002).

Med andre ord, så handler CG at lægge relevansvurderingerne sammen og derved udregne en værdi. Relevansvurderingerne giver point, hvor 3 er relevant og 0 er ikke-relevant. Nedenstående eksempel er fra Järvelin & Kekäläinen (2002).

G' = <3,2,3,0,0,1,2,2,3,0,...>

CG' = <3,5,8,8,8,9,11,13,16,16,...>

G er listen med relevansvurderingerne sorteret efter søgeresultaternes placering. Det første dokument har dermed værdien 3. CG er Cumulated Gain og udregnes ved at lægge tallene fra relevansvurderingerne sammen. Hvis man vil have CumGain for dokument 5: G=(3+2+3+0+0)= 8. CG=8.

Järvelin & Kekäkeläinen har desuden udviklet supplerende beregninger til CG. Vi beskriver dem nedenfor og forklarer, hvordan de anvendes.

5.7.1a Discounted Cumulated Gain (DCG)Discounted Cumulated Gain (DCG) er en udvidelse af Cumulative Gain-metoden, som forsøger at tager højde for, at testpersoner bliver mere trætte, som testen og relevansvurderingerne skrider frem. Metoden sænker værdien på de dokumenter, som er blevet vurderet relevante, men er placeret langt nede på listen, sådan at de ikke vægtes helt så højt, som relevante dokumenter placeret længere oppe i søgeresultaterne. Dette gøres ved at subtrahere en værdi fra hver af relevansvurderingerne. Denne værdi vokser logaritmisk for hvert dokument (Järvelin & Kekäläinen, 2002).

Samtidig tager metoden højde for, at jo længere nede et dokument er placeret, des mindre chance er der for, at brugeren i en ægte situation (udenfor laboratoriet) ville se dette dokument (Ingwersen & Järvelin, 2005).

95

Vi anvender ikke Discounted Cumulated Gain (DCG), idet vi ikke mener, at der findes nok dokumentation omkring, hvilken betydning størrelsesordenen af den logaritmisk stigende værdi, som bruges til at nedskrive værdien på de lavest placerede dokumenter, har. Järvelin & Kekäläinen (2002) kommer med to forslag til størrelsen på værdien, nemlig log2(2) og log2(10), men skriver, at disse to værdier kun er vejledende. DCG tager desuden ikke hensyn til, at testpersonernes trætheds-tærskel er individuel.

Vi tager i stedet højde for eventuel skævvridning i relevansvurderingerne p.g.a. træthed ved at randomisere vores søgeresultater (som beskrevet i afsnit 5.4 om randomiseringen). Dermed ved vores testpersoner ikke, hvordan dokumenterne er placeret på den oprindelige resultatliste, og alle dokumenter bliver i løbet af hele eksperimentet både vurderet blandt de første og sidste i testen. Derudover har de fået besked om at relevansvurdere hvert enkelt dokument, som om det er første det første dokument, de ser.

5.7.1b Ideal Cumulated Gain (CGi)Vektor G, listen med relevansvurderingerne sorteret efter søgeresultaternes placering, har en tilhørende ideal-vektor I, som illustrerer, hvordan vektor G ville have set ud, hvis dokumenterne var placeret ideelt i resultatlisten, efter hvor relevante, testpersonen finder dem.Ideal-vektoren beregnes på følgende måde: Først samles alle relevansvurderinger, som giver højeste antal point. I nedenstående eksempel er dette 3. Dernæst tilføjer man alle de relevansvurderinger, som giver næsthøjest antal point, som i eksemplet er 2. Sådan fortsætter man, indtil alle point igen er blevet samlet på en liste. Når man genererer kurven ud af tallene, vil man få den ideelle kurve, altså Ideal Cumulated Gain (CGi). Den ideelle kurve viser, hvordan utopien ser ud for et givent søgeresultat. Det er jo ideelt, at alle relevante dokumenter ligger først, og de mindst relevante ligger til sidst.

BV[i] =

Figur 21: Beregningen for CGi (Järvelin & Kekäläinen, 2002)

Vi anvender samme eksempel som i foregående afsnit. G er stadig de enkelte relevansvurderinger for dokumenterne #1 - #10. I er den ideelle sortering, hvor de mest relevante dokumenter er placeret først.

G' = <3,2,3,0,0,1,2,2,3,0,...>

I' = <3,3,3,2,2,2,1,1,1,1,0,0,0...>

Formålet med CGi er at have den ideelle kurve opstillet op imod CG. Derved kan vi undersøge, hvordan relevansalgoritmen opfører sig, vist i CG-kurven, og sammenligne denne kurve med CGi-kurven, som er den ideelle kurve. Grafisk afbildet vil CGi-kurven altid ligge

3, if i ≤ m,2, if m < i ≤ m + l 1, if m + l < i ≤ m + l +k0, otherwise

96

højrere (eller oven i) CG-kurven. De to kurver sammenlignes ved at måle højdeforskellen på kurverne, ud for hvert dokument, altså ud for hvert hele tal på førsteaksen.

5.7.1c Normalised Cumulated Gain (nCG)Normaliseret Cumulated Gain (nCG) beregnes med denne formel fra Järvelin & Kekäläinen (2002):

nCG' = norm-vect (CG', CG'i)

Med andre ord, så beregner man nCG ved at dividere hver enkelt værdi fra CG med den tilsvarende værdi fra CGi.

Ved at normalisere vores CG-kurver for hver enkelt IR Search Task, vil vi være i stand til at sammenligne dem. De tre Search Tasks er meget forskellige og vil dermed også give forskellige resultater (jf. afsnit 5.3 om Work Tasks). Ved at normalisere vores data fra de enkelte CG- og CGi-værdier, vil vi have et stabilit og ensformigt datagrundlag, som vi vil have mulighed for at undersøge nærmere. Kort sagt, uden normaliseringen af vores data, vil vi ikke være i stand til at sammenligne de tre Search Tasks.

5.7.1d Databehandling af Cumulated GainVi har forklaret hvad Cumulated Gain (CG), Ideal Cumulated Gain (CGi) og Normalised Cumulated Gain (nCG) er og hvordan de bliver udregnet. I dette afsnit vil vi beskrive hvordan vi har udregnet de forskellige typer af CG for vores egne data og hvordan vi anvender disse tal.

Vores relevansskala går fra 0-3, hvor ikke-relevant har værdien 0 og relevant har værdien 3. Vi beregnede CG ved at stille alle testpersonernes relevansvurderinger op ved siden af hinanden. Derefter lagde vi værdierne sammen for hvert dokument og beregnede derefteer gennemsnittet. Dette tal blev så værdien for Gain (G). Bilag 25 er oversigt over vores datagrundlag. Nedenstående er et eksempel på, hvordan en udregning på G og CG ser ud. Eksemplet er fra vores egne data fra Work Task A:

Søgeres. 1 2 3 4 5TP801 3 3 3 2 3TP802 3 3 2 1 3TP803 0 3 0 2 3TP804 1 1 1 3 3TP805 2 2 2 2 3TP806 1 0 1 0 0TP807 3 3 2 3 3TP808 3 2 3 2 3TP809 3 2 1 3 2TP810 3 3 2 1 3TP811 3 1 2 3 3TP812 3 3 3 3 3TP813 0 1 0 0 2MIDDEL 2,20 2,40 2,40 3,00 0,60

97

CG 2,20 4,60 7,00 10,00 10,60Figur 22: Eksempel på, hvordan vi har beregnet CG. Vi har lagt alle værdierne sammen for et enkelt dokument og fundet middelværdien. Dette tal er G-værdien, CG er derefter beregnet ved at lægge G-værdierne sammen.

Vi anvender CG til at undersøge hvordan relevanalgoritmen perfomer. For at kunne undersøge relevansalgoritmen anvender vi også den ideelle CG, som har til formål at vise hvordan den optimale relevevansalgoritme ville fungere. CGi beregnes ved at vi først sorterer alle relevansvurderinger efter værdi, så de bliver sorteret i faldende orden. Dermed er alle relevante placeret først i rankingen og de ikke-relevante bliver placeret sidst. Derefter anvender vi samme fremgangsmåde, som da vi beregnede CG, nemlig at vi finder midddelværdien for hver enkelt ranking og derefter akkumulerer dem for at finde CGi. Nedenstående eksempel viser hvordan vi har foretaget en sådan beregning. Vi anvender igen de første fem relevansvurderinger fra testpersonerne fra Work Task A:

Ranking 1 2 3 4 5TP801 3 3 3 3 3TP802 3 3 3 3 3TP803 3 3 3 3 3TP804 3 3 3 3 3TP805 3 3 3 3 3TP806 2 2 2 1 1TP807 3 3 3 3 3TP808 3 3 3 3 3TP809 3 3 3 3 3TP810 3 3 3 3 3TP811 3 3 3 3 3TP812 3 3 3 3 3TP813 3 3 3 3 3MIDDEL 2,92 2,92 2,92 2,85 2,85CGi 2,92 5,85 8,77 11,62 14,46

Figur 23: Eksempel på hvordan vi beregner CGi. Dataene er fra Work Task A. Alle relevansvurderinger er lagt sammen og middelværdien er fundet. Disse middelværdier bliver akkumuleret for at finde CGi.

I grafen vil CGi vil stige meget kraftigt og tilsidst flade ud, når der ikke er flere relevante dokumenter tilbage. CG-kurven vil også stige, men vi forventer, at den gør det i små trinvise ryk, fordi at det ikke er alle relevevante dokumenter, som ligger først i søgeresulatet. Dette kan vi se allerede ved bare at sammenligne tallene fra de to tabeller ovenfor.

Vi anvender den normaliserede CG (nCG) til at sammenligne de tre Work Tasks. Dette gør vi for at undersøge om der er nogen forskel på, hvordan relevansalgoritmen performer mellem de tre Work Tasks. Vi beregner nCG ved at dividere CG med CGi. x

98

Eksemplet er endnu en gang taget fra Work Task A:

CG CGi nCG2,15 2,92 0,744,23 5,85 0,725,92 8,77 0,687,85 11,62 0,6810,46 14,46 0,72

Figur 24: Beregning af nCG. Dette gøres ved at dividere hver enkelt CG-værdi med CGi-værdien fra den tilsvarende placering på listen.

Formålet med at normalisere CG er at eliminere forskellen med CG og CGi. Beregningen fjerner forskellene mellem de to kurver og finder i stedet en form for middelværdi. Nedenstående eksempel viser hvordan vi har beregnet nCG for de første fem værdier fra CG og CGi.

5.8 Mean Reciprocal Rank (MRR)

Vi anvender Mean Reciprocal Rank (MRR) til at undersøge, hvordan de forskellige dokumenttyper performer i REX/Primo. MRR blev udviklet af Ellen Voorhees, som definerer MRR med følgende ord:

“An individual question received a score equal to the reciprocal of the rank at which the first corret response was returned, or 0 if none of the five responses contained a correct answer. The score for a submission was then the mean of the individual question’s reciprocal ranks.” (Voorhees, 1999).

Vi tager udgangspunkt i Voorhees’ undersøgelse, hvor ovenstående citat også er taget fra, til at forklare hvordan MRR udregnes. Et antal deltagere har søgt svar på en række spørgsmål. De har fundet op til fem svar på hvert spørgsmål. En ekspert har derefter set på disse svar og verificeret om de er korrekte. Hvis et af de fem svar er korrekte, får dette svar værdien 1 og resten af sættet får værdien 0.

For at udregne Reciprocal Rank (RR) skal man dividere værdien 1 med svarets placering. Dvs., hvis det korrekte svar er svarmulighed 2, så er RR = 1 / 2 = 0.5. For at udregne MRR skal man beregne gennemsnittet af alle spørgsmål for den enkelte deltager. Eksempelvis kan en deltager have løst fem spørgsmål med RR: 0.5 ; 0,5 ; 0 ; 0,2 ; 1. Dermed vil MRR så være (0,5 + 0,5 + 0 + 0,2 + 1) / 5 = 0,44 (Voorhees, 1999).

99

I vores speciale anvender vi MRR til at undersøge hvordan de enkelte dokumenttyper perfomer i REX/Primo. Derudover undersøger vi også nærmere, hvordan relevansalgoritmen perfomer. Dette gør vi ved at undersøge hvor og hvonår de enkelte relevanskategorier optræder første gang og beregne MRR ud fra disse tal.

5.8.1a Document cut-off (DCV)Vi har valgt at anvende Document Cut-off Value som supplement til MRR, for at give et bedre billede af hvordan relevansalgoritmen fungerer. Document Cut-off Value (DCV) betyder ganske enkelt, at vi vælger at koncentere os om, eksempelvis, de første fem poster i hver af de tre Work Tasks. Med andre ord, så skærer vi de første fem dokumenter fra resten af listen og koncentrerer os om dem (Baeza-Yates & Ribeiro-Neto, 1999).

Vi vil anvende DCV både når vi undersøger hvordan relevansvurderinger er fordelt, men også når vi undersøger hvordan dokumenttyperne performer. DCV-værdien. Vi har valgt at DCV-værdien skal være fem. Vi tæller dermed kun de første fem søgeresultater når vi undersøge relevansalgoritmen. Vi tæller også kun de fem første, når vi undersøger dokumenttyperne. Vi tæller dog kun den enkelte dokumenttype, så vi kan ende længere nede i rankingen end kun top fem, fordi at nogle dokumenttyper findes meget langt nede i rankingen. F.eks, så kan der være meget få billeder i en Work Task, dermed kan vi være nødt til at tælle billeder, som ligger langt nede på rankingen, men det vil stadig være inden for de første fem søgeresultater, som indeholder billeder. Nedenfor er en oversigt over hvordan dokumenttyperne er placeret i vores tre Work Tasks.

Søgeres.

Dok.typ. Dok.typ.

Dok.typ.

1 bog bog bog2 bog noder billeder3 bog billeder billeder4 bog bog bog5 bog noder bog

6 boghåndskrift bog

7 bog noder bog8 bog bog bog9 bog billeder bog10 kort billeder bog11 bog bog bog12 bog lyd bog13 bog bog bog14 bog billeder bog15 bog billeder billede16 bog billeder bog17 kort billeder bog18 bog billeder bog19 bog billeder bog20 billeder billeder bog21 bog billeder bog

100

22 bog billede bog23 bog billeder bog24 bog billeder billeder25 bog billeder speciale26 bog billeder bog27 bog billeder bog28 bog billeder bog29 bog billeder bog30 bog bog billede

Figur 25: Oversigt over hvordan de enkelte dokumenttyper har fordelt sig i vores tre Work Tasks.

5.8.2 Databehandling af Mean Reciprocal RankVi har forklaret hvordan vi anvender Mean Reciprocal Rank til at undersøge hvordan relevansalgoritmen performer i REX/Primo. Som nævnt i foregående afsnit, beregner vi MRR ved at hvornår de enkelte relevanskategorier optræder første gang i hver af de tre Work Tasks. Nedenstående tabel er et eksempel på, hvordan vi beregner MRR.

TP RelevantDelvist relevant

Delvist ikke-relevant

Ikke-relevant

801 1 0,25 0 0802 1 0,33 0,25 0803 0,5 0,25 0 1804 0,25 0 1 0805 0,2 1 0 0806 0 0 1 0,5807 1 0,33 0 0808 1 0,5 0 0809 1 0,5 0,33 0810 1 0,33 0,25 0811 1 0,33 0,5 0812 1 0 0 0813 0 0,2 0,5 1MRR 0,688 0,309 0,295 0,192

Figur 26: Eksempel på, hvordan vi beregner MRR. Dataene er taget fra Work Task A.

I dette afsnit beskriver vi, hvordan vi har beregnet MRR på vores egne data. Vi har optalt de enkelte relevanskategorier inden for vores Document Cut-off Value (DCV), som er de første fem dokumenter i hver Work Task. Første gang en relevanskategori optræder hos pågældende testperson, får denne kategoriværdien 1. Hos TP801, eksempelvis, er det første relevante dokument også det første relevante dokument i søgeresulatet.

Reciprocal Rank beregnes ved at dividere værdien med dokumentets placering. Reciprocal Rank for ”relevant” hos TP801 med formelen: 1 / 1 = 1. Dermed bliver RR 1.

101

For at beregne MRR, skal vi først beregne RR for alle relevante dokumenter hos alle testpersoner. Derefter beregner vi middelværdien, og dette tal er MRR.

5.9 Analyse

I dette afsnit vil vi præsentere vores resultater i IR evalueringen i form af forskellige grafer. Vi vil kommentere og analysere graferne enkeltvis. Vi starter med at se på graferne for Cumulated Gain og derefter på Mean Reciprocal Rank.

5.9.1 Cumulated Gain

I Figur 27 ses CG- og CGi-kurven for Work Task A. Den stiplede linie er CGi-kurven og den anden linie er CG-kurven.

Figur 27: Kurverne for CG og CGi for Work Task A. Den prikkede linie er CGi, mens den fuldt optrukne linie er CG.

CG kurven har en stor stigning fra dokument 1 til dokument 9 og igen fra dokument 24-30. De mest relevante dokumenter ligger dermed først og sidst i søgereresulatet. Når kurven stiger lidt i trin, kan det betyder, at der er støj i søgeresulatet, altså, at der var ikke-relevante dokumenter. Det er klart, at det optimale er CGi-kurven, som viser en jævn og stejl

Work Task A

0

5

10

15

20

25

30

35

40

45

50

55

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29

Dokumenter 1-30

CG-v

ærd

i

CGCGi

102

stigning og derefter begynder at flade ud omkring dokument #24. Ud fra Work Task A, kan vi overordnet se, at relevansalgoritmen gør et ganske godt stykke arbejde og lægger langt de fleste af de ikke-relevante dokumenter sidst i søgeresulatet. Denne udtagelse kan vi hurtigt være nødt til at trække land, når vi nu går i gang med at kigge på næste Work Task.

103

I ses… CG- og CGi-kurven for Work Task B. Den stiplede linie er CGi-kurven og den anden linie er CG-kurven.

Figur 28: Kurver for CG og CGi for Work Task B. Den fuldt optrunke linie er CG, mens den prikkede linie er CGi.

er CG- og CGi-kurverne for Work Task B. CG-kurven er meget ujævn indtil dokument #13 og slutter af med at stige kraftigt fra dokument #28. CGi-kurven stiger kraftigt ind til omkring dokument #8, derefter stiger den kun langsomt og ser ud til først at flade ud omkring dokument #29. Det er tydeligt, at der er meget støj i søgeresulaterne i først halvdel, dokumenterne #1-15. Med andre ord, så fungerer relevansalgoritmen langt fra lige så godt i Work Task B som den gjorde i Work Task A.

Work Task B

0

5

10

15

20

25

30

35

40

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29

Dokumenter 1-30

CG-v

ærd

i

CGCGi

104

I Figur 29 ses CG- og CGi-kurven for Work Task C. Den stiplede linie er CGi-kurven og den anden linie er CG-kurven.

Work Task C

0

5

10

15

20

25

30

35

40

45

50

55

60

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29

Dokumenter 1-30

CG-v

ærd

i

CGCGi

Figur 29: Kurver for CG og CGi for Work Task C. Den prikkede linie er CGi, mens den fuldt optrukne linie er CG.

Figur 29 viser CG- og CGi-kurverne for Work Task C. CG-kurven har en pæn og jævn stigning hele vejen. Der er enkelte små udsving, men intet så markant som i de andre Work Tasks. CGi-kurven begynder at flade ud omkring dokument 27.

En CGi-kurve begynder at flade ud, når der ikke er flere relevante dokumenter tilbage i blandt søgeresultaterne. Som beskrevet tidligere, beregnede vi CGi ved at sortere relevansvurderingerne, så de højeste værdier lå først (værdien 3 = relevant) og de laveste værdier ( værdien 0 = ikke-relevant) lå sidst i rankingen. Derfor begynder en CGi-kurve at flade ud. Fordi alle tre CGi-kurver begynder at flade ud i vores grafer, så kan vi med stor sikkerhed sige at vi, via vores søgninger, fandt alle relevante dokumenter inden for de første 30 søgeresultater.

Umiddelbart kan vi ikke se en sammehæng mellem kendskab til emnet (jf. afsnit 5.6: Databehandling af Pre Task- Spørgeskema) og CG-kurverne. Det var Work Task C, som testpersonerne havde det bedste kendskab til, her er CG-kurven pæn og jævn. Testpersonerne var jævnt fordelte mellem ”intet kendskab” og ”kendskab” ved de to andre tasks. CG-kurverne for disse to tasks har vist sig at være meget forskellige. CG-kurven for Work Task A ligner mere CG-kurven for Work Task C, mens CG-kurven for Work Task B falder helt udenfor. Med andre ord, så er der ingen sammenhæng mellem kendskab til et emne for en Work Task og hvordan relevansvurderingerne arter sig.

105

Overordnet set for de tre CG-grafer, så har der været støj i første halvdel af søgeresulaterne, altså i dokumenter #1-15. Work Task B falder helt udenfor og har meget mere støj end de to andre. Nedenstående figur er normaliseringen af CG, altså nCG. Vi har har samlet alle tre Work Tasks i samme graf, for bedst muligt at kunne sammenligne dem.

I Figur 30 ses… nCG-kurverne for de tre Work Tasks. Den prikkede linie er ncCG-kurven for Work Task C, den stiplede linie er nCG-kurven for Work Task B og den sidste linie er nCG-kurven for Work Task A.

Figur 30: nCG-kurverne for de tre Work Tasks. Den fuldt optrukne linie er Work Task A. Den stiplede linie er Work Task B. Den prikkede linie er Work Task C.

Ovenstående Figur 30 viser, at Work Task A og C følger hinanden nogenlunde, mens Work Task B falder helt udenfor. Der er en hel del udsving i starten af kurverne, men de begynder alle at flade ud og stige jævnt omkring dokument 15. Ud fra de ovenstående figurer kan vi se, at relevansalgoritmen finder langt de fleste relevante dokumenter indenfor de første 15 poster, men den er langt fra optimal, i det at den også finder en del støj.

Grunden til, at Work Task B falder så meget uden for, kan være at selve opgaveformuleringen har lagt op til for meget fortolkning fra testpersonernes side. Det har resulteret i store forskelle mellem de enkelte testpersoners relevansvurderinger. Bilag 25 viser

nCG for Work Tasks

0,0

0,2

0,4

0,6

0,8

1,0

1,2

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29

Dokumenter 1-30

nCG

-væ

rdi

ABC

106

datagrundlaget, hvori testpersonernes individuelle relevanvurderinger også er angivet. Det er sandsynligt, at det skyldes en fejl fra vores side, idet vi kunne have haft formuleret Work Task’en mere klart, men på den anden side er det jo netop derfor, vi anvender tre forskellige Work Tasks i dette speciale. Ved at anvende tre forskellige, kan vi se på tværs af relevansvurderingerne og de enkelte Work Tasks og i stedet undersøge helheden.

Ud fra vores analyse af de forskellige CG-kurver kan vi konludere, at relevansalgoritmen performer tilfredsstillende, fordi at langt de fleste relevante dokumenter kan findes inden for de første femten søgeresultater.

5.9.2 MRRNedenstående tabel er en oversigt over, hvordan MRR ser ud for de enkelte relevanskategorier. Vi har anvendt Document Cut-off Value (DCV), som vi beskriver i afsnit 5.8.1a: Document cut-off (DCV), hvilket vil sige, at vi kun har undersøgt de første fem søgeresultater i hver af de tre Work Tasks.

MRR

Work Task RelevantDelvist relevant

Delvist ikke-relevant Ikke-relevant

A 0,688 0,309 0,295 0,192B 0,250 0,438 0,415 0,380C 0,596 0,415 0,447 0,198Middelværdi 0,512 0,387 0,386 0,257

Figur 31: Tabel over MRR for de enkelte relevanskategorier ved de tre Work Tasks og middelværdien på relevanskategorierne.

Det optimale vil være, hvis MRR-værdierne for ”relevant” er højere end værdierne for ”ikke-relevant”. Forstået på den måde, at der skal være flest relevante dokumenter og helst slet ingen ikke-relevante, hvis altså relevansalgoritmen performer optimalt. Work Task A er den eneste, som har MRR-værdier, der falder efterhånden, som dokumenterne bliver mindre relevante.

Vi har beregnet middelværdien af MRR på tværs af de tre Work Tasks for hver af relevanskategorierne. Dette har vi gjort for at se på, hvordan relevansalgoritmen overordnet performer. Som det kan ses af ovenstående

Error: Reference source not found, så performer den ganske godt. MRR-værdien for de relevante og delvist relevante dokumenter er langt højere end de mindre relevante dokumenter. Dog, så er dataene jo kun taget ud af de første fem bibliografiske poster fra hver task, så de ikke-relevante dokumenter er højt repræsenterede i forhold til, hvad der kan forventes. Hvis en relevansalgoritme skal performe bedst muligt, så mener vi ikke, at der bør findes ikke-relevante dokumenter inden for de første fem søgeresultater.

107

5.9.2a MRR for dokumenttyperne

Et af kriterierne for vores Work Tasks var, at de skulle indeholde mindst tre forskellige dokumenttyper. Vi er endt med at have fundet syv forskellige dokumenttyper ud af tretten mulige. Det er ca. halvdelen og det er ganske udmærket, taget i betragtning af, at det drejer sig om de første 30 søgeresultater fra tre forskellige søgninger. Nedenstående tabel viser fordelingen af antallet af fundne dokumenttyper:

Dokumenttype

Antal

Billede 3Billeder 22Bog 57Håndskrift 1Kort 2Lyd 1Noder 3Speciale 1I alt 90

Figur 32: Tabel over dokumenttyper og antal

Dokumenttypen “bøger” står for næsten 2/3 af alle fundne dokumenter, mens billeder står for ca. 1/4. Der er ingen forskel på “billede” og “billeder”, udover at “billeder” er bibliografiske poster, som indeholder mindst to billeder. Vi behandler “billede” og “billeder” som samme kategori, da de indeholder samme dokumenttype.

Vi vælger, kun at undersøge bøger og billeder, fordi det er de dokumenttyper, som optræder mest i vores søgeresultater. Vi undersøger dem ved at inddele dem i relevanskategorier. Derved kan vi også se, om der er nogen forskel på, hvor anvendelige de er. Vi har valgt, ikke at lægge vægt på tilgængeligheden, når vi sammenligner, fordi det stadig er begrænset, hvor mange dokumenter KB har fået gjort tilgængelige elektronisk. Her er der materiale til et studie mere, hvor der testes om tilgængeligheden er en faktor for, om et materiale vurderes relevant eller ikke-relevant.

Vi behandler MRR for f.eks. bøger, ved først at trække alle bøger og de dertilhørende relevansvurderinger ud af alle tre Work Tasks. De har naturligvis beholdt deres oprindelige ranking, så vi har ikke blandet søgeresultaterne på tværs af Work Tasks. Hele formålet er jo at undersøge hvordan REX/Primo performer som intergrated search system, derunder også relevansalgoritmen i sig selv. Desuden, vi ønsker at sammenligne bøger og billeder og finde ud af, om de performer forskelligt i REX/ Primo.

Som nævnt tidligere (jf. afsnit 5.8.1a: Document cut-off (DCV)), så anvender vi DCV-værdien fem, når vi undersøger dokumenttyperne. Vi bruger samme fremgangsmåde, som da vi bearbejdede DCV for alle tre Work Tasks på tværs af dokumenttyperne. Vi tæller

108

relevansvurderinger for, hvor og hvornår de første gang dukker op. Dette gør vi for de første fem poster med bøger og de første fem poster med billeder. Derefter beregner vi Reciprocal Rank-værdien (jf. afsnit 5.8: Mean Reciprocal Rank (MRR)), hvor efter vi beregner MRR. Nedenstående tabel viser MRR for bøger, beregnet ud fra dataene fra vores tre Work Tasks.

relevantdelvist relevant

delvist ikke-relevant ikke-relevant

Work Task A 0,688 0,309 0,295 0,192Work Task B 0,280 0,375 0,231 0,398Work Task C 0,481 0,268 0,397 0,218MIDDEL 0,483 0,317 0,307 0,270

Figur 33: MRR for bøger. MRR er angivet for de enkelte relevanskategorier i hver Work Task. Middelværdi angivet for hver enkelt relevanskategorie på tværs af Work Tasks.

Tallene fra Work Task A er helt identiske med tallene fra samme Work Task i Figur 24. Dette skyldes, at alle bøger lå placeret som de første fem søgeresultater i søgningen. Ud fra middelværdien, som går på tværs af de tre Work Tasks, så falder MRR-værdien, jo mindre relevante dokumenterne er. Dette er klart en positiv tendens, da det jo er meningen, at relevansalgoritmen skal placere de mest relevante dokumenter først i søgeresultatet. Bøger står for lidt over halvdelen af alle fundne dokumenter. I bilag 26, viser vi de rå data bag vores beregninger. Her kan det også læses, hvordan bøgerne har fordelt sig over de tre Work Tasks.

Der var meget få bøger i Work Task B, taget i betragtning af, hvor mange bøger der er i alt. Dette kan ses ved, at vi måtte helt ned i bunden af søgeresultaterne for at finde fem bøger, derfor er MRR-værdien for ”ikke-relevant” størst.

Generelt er der et problem ved, at testpersonerne kun kan se de bibliografiske poster for de enkelte bøger. Poster består ikke af ret meget mere end angivelse af titel, ophav, udgivelsesdato, sidetal og lidt andre små oplysninger. Der er yderst sjældent et resume af bogen, hvilket kan have gjort det svært på testpersonerne at vurdere hvor relevant den pågældende bog er. Hvis testpersonerne havde haft bøgerne i hånden og dermed også haft mulighed for at bladre i dem eller bare se indholdsfortegnelsen, så kan der være mulighed for, at relevansvurderingerne havde set anderledes ud. Men sådan er virkeligheden ikke i et OPAC-system. Her er det kun muligt at se de bibliografiske poster. Selvom KB er i gang med at digitalisere deres dokumenter, så er der stadig langt til, at det vil være muligt at se bøgerne elektronisk.

Nedenstående figur viser MRR-værdierne for billederne i de tre Work Tasks. Der var meget få billeder i Work Task A og C, faktisk var der kun et enkelt billede i Work Task A. Vi har dog alligevel valgt at tage dette dokument med i beregningen.

relevantdelvist relevant

delvist ikke-relevant ikke-relevant

Work Task A 0,013 0,015 0,012 0,012Work Task B 0,024 0,065 0,182 0,148Work Task C 0,275 0,236 0,109 0,053

109

MIDDEL 0,104 0,105 0,101 0,071

Figur 34: MRR for billeder. MRR er angivet for de enkelte relevanskategorier i hver Work Task. Middelværdi angivet for hver enkelt relevanskategorie på tværs af Work Tasks.

Det er tydeligt, at billederne er placeret meget længere nede i søgeresultaterne, når vi sammeligner med MRR-værdierne for bøgerne. Selvom der i alt kun er halvt så mange billeder, som der er bøger, så er det overordnede indtryk af billederne stadig, at MRR-værdien faldet efterhånden som billederne skal findes længere og længere nede på listen over søgeresulater.

KB har allerede gjort mange billeder elektronisk tilgængelige, men vi har ikke optalt hvor mange billeder, som vores testpersoner havde mulighed for at se i de bibliografiske poster. Vi har valgt ikke at tælle, hvor mange af vores dokumenter fra de tre Work Task, der er tilgængelige, fordi vi mener, at der ligger materiale nok et helt nyt speciale gemt i disse data.

MRR-værdierne for billederne er meget forskellige, men i Work Task C, som kun indeholdt fem billeder, er værdierne overraskende høje. Som det også kan ses i bilag 27, så er billederne fordelt ud over alle tredive søgeresulater. Der er både nogen i toppen og i bunden, men alligevel er MRR-værdierne meget høje. Work Task B indeholder langt de fleste af billederne, men disse har ikke fået samme høje relevansvurdering som i Work Task B. Dette kan skyldes opgavebeskrivelserne i de to Work Tasks. I Work Task B bliver testpersonerne bedt om at finde information om Carl Nielsen. Her har testpersonerne ment, at billeder ikke siger ret meget om Carl Nielsen som person og komponist.

Det har været svært at finde tre søgninger, som rummede mindst tre forskellige dokumenttyper. Hvilket også kan ses i antallet af de enkelte dokumenttyper, som vi har fundet. Det krævede mange søgninger i form af ”trial and error” inden vi fandt noget, som kunne bruges. Enten har vi valgt de forkerte emner, hvor der ikke findes mange forskellige dokumenter, eller også indeholder REX/Primo ret mange forskellige dokumenter udover massevis af bøger og lidt færre billeder.

Vi kunne selvfølgelig have valgt, at testpersonerne skulle relevansvurdere et større antal dokumenter, eller vi kunne have flere Work Tasks. Vi har dog så vidt muligt valgt at anvende søgetermer, som en helt normal gennemsnitlig bruger kunne finde på at bruger. Derfor har vi også begrænset vores anvendelse af wildcard i søgningen. Uanset hvad, så var det svært at finde flere forskellige dokumenttyper, uden at vi skulle søge specifikt på en dokumenttype. Vi kan med andre ord sige, at REX/Primo ikke fungerer godt, når det kommer til performe som integrated search system.

5.10 DelkonklusionFørst og fremmest, så illustrerede CG-kurverne for de enkelte Work Tasks, at der var stor forskel på, hvordan testpersonerne fortolker emnerne. Work Task B har hele vejen igennen skilt sig ud og mere været med til at afkræfte end at bevise en tendens i relevansalgoritmens performance.

110

Ud fra CGi-kurverne kan vi konludere, at relevansalgoritmen placerer langt de fleste relevante resultater inden for de første femten søgeresultater. Der er dog stadig en smule støj, som viser sig i store udsving i de tre kurver. Kurverne stabiliserer sig dog også i sidste halvdel af kurven, hvilket viser, at der ikke er mere støj sidst i søgeresultaterne, og dermed heller ikke flere relevante dokumenter tilbage, som kan få kurven til at stige stejlt.

Alt i alt, så fungerer relevansalgoritmen ganske godt, også set ud fra MRR-værdierne. Endnu en gang skiller Work Task B sig ud, men overordnet set, så falder MRR-værdierne, hvilket er et tegn på, at der er få ikke-relevante dokumenter inden for de fem søgeresultater.

Når vi ser på dokumenttyper og undersøger, hvordan REX/Primo performer som integrated search system, så er et det første vi lægger mærke til, at det har været svært at finde nok forskellige dokumenttyper. Kravet til vores Work Task var, at vi ville have mindst tre forskellige dokumenttyper inden for de første 30 poster. Langt de fleste dokumenter viste sig at være bøger og billeder. Der var et meget lille antal af andre dokumenttyper. Derfor mener vi ikke, at REX/Primo fungerer optimalt, hvis man ønsker at finde forskellige dokumenttyper.

Der er ingen tvivl om, at der findes mange forskellige dokumenttyper i REX/Primo, der findes ganske ikke nok af alt andet end billeder og bøger til, at integrated search kan performe godt.

111

6 DISKUSSION

Vi har udført en usability test og en IR evaluering af REX/Primo med testpersoner, som falder ind under den brugergruppe, vi har defineret for dette eksperiment. Det kan diskuteres, om vi havde fået andre resultater, hvis vi havde valgt en brugergruppe, som ligeledes var førstegangsbrugere af systemet, men som ikke kun havde en potentiel, men også en konkret grund til at begynde at bruge Det Kongelige Bibliotek. Det kunne for eksempel være nye studerende, som endnu ikke har nået at være på kursus på deres lokale forskningsbibliotek. Men så havde vi ikke længere testet den aldersgruppe, vi var interesseret i. Vi har testet 50-70 årige, fordi vi har et håb om, at Det Kongelige Bibliotek for fremtiden vil være associeres mindre med lukket land og mere med underholdning indenfor en årrække, efterhånden som midlerne til digitalisering er der. Og KB har, underholdning eller ej, ikke unge studerende som målgruppe i dén henseende, der er det den aldersgruppe, som vi har testet, der vil føle sig underholdt på det digitale bibliotek.

Vores usability test er resulteret i, at vi har lavet fem mock ups af de fem websider i REX, som brugeren kommer igennem i sin søgning. Vi har indhentet dataene til at lave disse mock ups fra gode metoder: Analyse af synligheden af funktioner og knapper, observation af opgaveløsning og søgeadfærd, indsamling og analyse af objektive data. Det er vigtigt for os at påpege, at vi nu, hvor vores mock ups er produceret, “bevæger os ind på ukendt territorium”.

Vi kan kun teste det, vi kan se. For at vores testpersoner kan evaluere en funktion, er den nødt til at findes. Når vi undersøger, om testpersonerne anvender en knap eller et link, kan vi kun gøre det ved at observere, om de finder og klikker på knappen eller ej under testen. Hvis testpersonen ikke så knappen, og interviewer i post-test interviewet udpeger den for vedkommende og spørger om, hvor knappen i stedet burde have været placeret for at blive set, så er det testpersonens holdning, der spørges ind til. Og sådanne meningstilkendegivelser er stort set ubrugelige i en usability test, ligegyldigt om det er systemudviklerens, usability-ekspertens eller testpersonens mening, der er tale om.

Den eneste måde at finde ud af, om knappen skal flyttes et andet sted hen på skærmen, er at flytte den og teste systemet igen.

Når vi kommer med forslag til, hvor oversete knapper, links eller ikoner kan flyttes hen for at blive set og brugt, så er det dermed også vores holdning, vi beskriver. Vores holdninger har vi dannet efter at have observeret og analyseret optagelserne af testpersonerne og kombineret analysen med vores viden om ikoner og menuer, om gestalt-lovene og om godt design af brugergrænseflader generelt, så vi er ikke i tvivl om, at vi med vores mock ups har skabt et velkvalificeret bud på næste opdatering af REX/Primo, som omhandler brugertilfredshed.

Performance af relevans algoritmen har vist sig at være ganske god. Der var dog noget støj i de første 15 poster, ifølge kurverne fra nCG, altså den normaliserede Cumulated Gain. Kurverne viste også, at der ikke var flere store udsving, hvilket betyder, at der kun var ikke-relevante dokumenter tilbage blandt søgeresultaterne.

Vi er godt klar over, at vi ikke har undersøgt de delvist relevante og delvist ikke-relevante dokumenter nærmere, og dermed heller ikke undersøgt hvilken indflydelse de har haft på de forskellige CG- og nCG-kurver. De må dog have haft en eller anden form for

112

indflydelse, for udsvingene i CG-kurverne er mere end bare ikke-relevante dokumenter. Vi har valgt at fokusere på det relevante og det ikke-relevante, for at kunne skære så langt ind til relevansalgoritmen som muligt. Med andre ord, så har vi forsøgt at gøre relevans så sort/hvidt som muligt.

Vi er stadig af den overbevisning, at relevans er situationel og dynamisk. Vores testpersoner har derfor kun været i stand til at give et øjebliksbillede af deres opfattelse af de enkelte bibliografiske poster. Hvis vi foretog samme IR evaluering igen, ville vi få et andet billede af relevansalgoritmen, fordi testpersonerne kan have ændret deres syn på dokumenterne. Sådan fungerer relevans.

Vores udformning af ordlyden i de enkelte Work Tasks har også været en stor faktor for, hvordan dokumenterne er blevet relevansvurderet. Dette kan tydeligt ses i Work Task B, hvor vi beder testpersonerne finde noget information om kompnisten Carl Nielsen, men langt de fleste søgeresultater er billeder, hvilket degenerelt set ikke har kunnet bruge.

Det har været noget sværere at besvare, hvordan REX/Primo performer som integrated search system. Vi kender ikke det nøjagtige tal for, hvor mange dokumenter der findes af hver type. Derudover, ændrer tallet sig fra dag til dag, fordi KB får digitaliseret og tilgængeliggjort mere og mere.

Ud fra vores arbejde med at tre Work Tasks og dertilhørende søgeresultater op at stå, så kan vi sige, at integrated search ikke fungerer optimalt. Dette skyldes, at der er sjældne dokumenttyper derude, f.eks specialer, som kan være svære at finde og som ofte handler om et meget lille niche-præget område.

Derudover, så bliver integrated search endnu mere kompliceret af, at Primo skal crawle flere forskellige databaser, som nok ikke har indekseret deres dokumenter på samme måde. Vi mener, at integrated search godt kunne trænge til en justering. Den dokumenttype, som fylder allermest i søgeresultaterne er bøger. Det er slet ikke hensigtsmæssigt, fordi de mere sjældne dokumenttyper bliver glemt eller gemt væk langt nede i søgeresultaterne.

113

7 KONKLUSION

Der er mulighed for usability forbedringer i REX/Primo. Systemet er ikke nemt at lære at bruge i alle sine facetter, som vores testpersoner har demonsteret. Vi foreslår nogle konkrete løsninger på områder, som vores usability test har vist, er særligt problematiske for førstegangsbrugere, blandt andet at gøre det nemmere og mere synligt at bladre i søgeresultater, og at gøre søgeboksene på både KB’s og REX’ startsider mere brugervenlige i forhold til deres informationsniveau.

REX/Primo som integrated search-system er i stand til at præsentere søgeresultater af blandede dokumenttyper i en liste af søgeresultater, som brugeren tager til sig med det samme. Vores testpersoner fremstod som om de havde anvendt denne slags integrated search altid, selv om de falder under betegnelsen førstegangsbrugere af REX/Primo.

Når det kommer til at vise de forskellige dokumenttyper, lader systemet dog lidt tilbage at ønske, idet alle de digitaliserede objekter, der vises i søgeresultater og bibliografiske poster, er så små, at vores testpersoner ikke kunne danne sig et ordentligt indtryk af, hvad de forestillede, og om de var relevante, før dokumentet blev åbnet i fuldskærm.

De fleste dokumenttyper, som er tilgængelige i digital form, er i pdf-format, som vores testpersoner alle er trygge ved og selv håndterer ofte. Det gælder for eksempel artikler, e-bøger og billeder. Billeder, herunder især fotografier og kartografisk materiale, kræver særlig behandling. Vi foreslår, at KB undersøger, om det er muligt at lægge en billedfremviser ind i REX, gerne som en permanent del af de bibliografiske billed-poster.

Overordnet set, fungerer relevansalgoritmen ganske godt. Ud fra CG-kurverne kan vi se, at langt de fleste af de relevante dokumenter bliver fundet inden for de første femten søgeresultater. Der er ikke ret meget støj i søgeresultaterne inden for de første femten søgeresultater.

Når vi går ind og undersøger relevansalgoritmens performance for de enkelte Work Tasks søgeresultater, så er der stor forskel på, hvor godt algoritmen performer. Det er den enkelte søgning og kontekst bag søgeordene, som gør, at relevansalgoritmen ikke performer optimalt hver gang.

Konklusionen er, at relevansalgoritmen performer tilfredsstillende.

REX/Primo har et par problemer med integrated search, set ud fra IR evalueringen. Vi fandt en del forskellige dokumenttyper, men langt de fleste var enten bøger eller billeder. REX/Primo kan tydeligvis godt finde ud af at fungere med en integrated search-funktion, men der bliver ikke taget højde for, at nogle dokumenttyper er meget sjældne og derfor godt kan tåle at blive ranket højere.

Vi er klar over, at KB langt fra er færdige med at digitalisere deres dokumenter, og derfor kan fremtiden se anderledes ud for de sjældnere dokumenttyper. Efterhånden som KB kommer igennem deres samlinger, vil der være mulighed for, at nogle dokumenttyper, eksempelvis kort, også er stærkere repræsenterede.

Selvom at REX/Primo kun indeholder bibliografiske poster, så fungerer integrated search funktionen tilfredssstillende, men der er også plads til forbedringer indenfor ranking af de mere sjældne dokumenttyper.

114

Resultaterne fra Specialet viser helt tydeligt, at REX/Primo er et velfungerende integrated search system.

KB har en masse håndtag at skrue på, men efter eget udsagn har de aldrig prøvet, fordi de ikke kan overskue konsekvensen. Men hvis det skal lykkes Det Kongelige Bibliotek, med sin høje kvalitet indenfor digitalisering, indeksering, genfinding og bugnende samlinger, at få brugerne til at blive interesserede i at bruge tid i REX (eller andre steder i KB's portal såsom deres samling af Danmarksbilleder) på at lede efter materialer, eller sågar deltage kollaborativt, så skal der forbedringer til.

115

8 PERSPEKTIVERING

Vi er i gang med at udfærdige en rapport til KB, hvor vi går mere i dybden med de resultater, som KB har fordel af at kende mere til. Vi har mange flere resultater, end vi har plads til at beskrive i Specialet. Her er der især tale om brugernes egne udtalelser omkring brugervenligheden af REX og billedbaserne.

KB gav os tidligt i samarbejdet forskellige bundne opgaver, blandt andet har vi lavet en komparativ undersøgelse deres billedbaser. KB har allerede bestemt sig for, hvilken brugergrænseflade de vil anvende, når de samler alle billedbaserne. Vi ville gerne have mere at vide om hvilke funktioner og menu-opstillinger, som brugerne foretrækker, så det system, de beholder, kan blive bedre.

Rapporten opsummerer resultaterne fra Specialet og indeholder mere af brugernes holdninger til de enkelte funktioner. Kort sagt, rapporten vil indeholde alle de resultater, som vi ikke har fået plads til i Specialet.

Resultaterne i Specialet vil KB kunne anvende til, først og fremmest, at forbedre brugervenligheden i REX. I forbindelse med de møder, vi har haft med Brugbarhedsgruppen fra KB, har de efterlyst brugeres holdninger og anvendelse af forskellige funktioner i REX. Brugbarhedsgruppen vil gerne vide mere om, eksempelvis, hvordan brugere opfatter og anvender drop-down-menuerne i REX’ søgeboks.

Specialet er også grundlaget for KB til at kunne skrue på precision- og recall-knapperne i Primo og derved forbedre ranking-algoritmen, så de mere sjældne dokumenttyper bliver placeret længere oppe i rankingen af søgeresultaterne. Dermed kan integrated search fungere bedre, fordi at brugerne får præsenteret flere forskellige dokumenttyper ud over bøger og billeder. Vi håber, at Det Kongelige Bibliotek får lyst til at prøve at forbedre ranking algoritmen, nu vi har lagt den første sten og analyseret den eksisterende algoritme.

Vi glæder os til at opleve, om vores Speciale kan give et bidrag til at forandre og forbedre brugeroplevelsen af REX/Primo.

116

9 KILDER

Alle links er verificeret 1. juli 2010.

Baeza-Yates, Ricardo & Berthier Ribeiro-Neto (1999) "Modern Information Retrieval". ACM Press. ISBN: 0-201-39829-X

Belew, Richard K, (2000): ”Finding Out About: A Cognitive Perspective on Search Engine Technology and the WWW”: Cambridge University Press. ISBN: 978-0-521-73446-2

Borlund, Pia & Peter Ingwersen (1997). ”The Development of a Method for the Evaluation of Interactive Information Retrieval Systems”. In: Journal of Documentation , vol. 53, no. 3, 225-250.

Borlund, Pia (2000): ”Evaluation of Interactive Information Retrieval Systems”. Doctoral Thesis. Åbo Akademi University.

Borlund, Pia (2003): ”The Concept of Relevance in IR” In: Journal of the American Society for Information Science and Technology, vol. 54, no.10, 913-925.

Brooke, J. (1996). SUS: a "quick and dirty" usability scale. in P. W. Jordan, B. Thomas, B. A. Weerdmeester, & A. L. McClelland. Usability Evaluation in Industry. London: Taylor and Francis.

Chowdhury, G. G. (2004): "Introduction to Modern Information Retrieval". 2. udgave. Facet Publishings. ISBN: 1-85604-480-7

Creative Commons:http://creativecommons.org/about/licenses/

Danmarks Statistik (2009) "Højest fuldførste uddannelse".http://www.dst.dk/Sites/KVM/Uddannelse/Hoejeste_fuldf.aspx

Datatilsynet (2000): "Persondataloven". ISBN: 87-601-8839-1.http://www.datatilsynet.dk/fileadmin/user_upload/dokumenter/Persondatalovspjece/Persondatalovspjece.pdf

Dublin Core:http://dublincore.org/documents/usageguide/elements.shtml

Eger, N., Ball, L. J., Stevens, R., & Dodd, J. (2007). Cueing retrospective verbal reports in usability testing through eye-movement replay. Chapter in L. J. Ball, M. A. Sasse, C. Sas, T. C. Ormerod, A.

117

Ericsson, K., & Simon, H. (1987): "Verbal reports on thinking". in C. Faerch & G. Kasper (eds.). Introspection in Second Language Research. Clevedon, Avon: Multilingual Matters. side. 24–54.

Ericsson, K. Anders & Herbert Simon (1993): Protocol Analysis - Verbal Reports as Data”. Bradford Book. ISBN: 0-262-55023-7

Finstad, Kraig (2006) : The System Usability Scale and Non-Native English Speakers, I: Journal of Usability Studies 1 4)

Grøn, Aninja Helene & Jessica Blanca Johansen (2008) “Flock – ‘The Innovative Social Browser’. Usability test af internetbrowseren Flock”. Bacheloropgave. Danmarks Biblioteksskole, København.

Harman, Donna K. (2005): “The TREC Test Collections”. Side 21-52 ibogen TREC: experiment and evaluation in Information Retrieval (edited by Voorhees & Harman). ISBN: 0-262-2207303

Hornbæk, Kasper (2006): ”Current Practice in Measuring Usability: Challenges to Usability Studies and Research”. I International Journal of Human-Computer Studies, 64(2), side79-102

Ingwersen, Peter (1992) "Information Retrieval Interaction". Taylor Graham.http://vip.db.dk/pi/iri/index.htm

Ingwersen, Peter & Kalervo Järvelin (2005): "The Turn: Integration of Information Seeking and Retrieval in Context". Springer. ISBN: 1-4020-3850-X

ISO9241-11:1998: "Ergonomic requirements for office work with visual display terminals (VDTs)" -- Part 11: Guidance on usability. International Organization for Standardization.

Järvelin, Kalervo & Jaana Kekäläinen (2002): "Cumulated gain-based evaluation of IR techniques) I ACM Transactions on Information Systems 20(4), side 422–446

Jensen, Jeannette. (2007): "Er der relevans i øjet der ser? - en undersøgelse af anvendeligheden af eye tracking i forbindelse med implicit relevans feedback" . Kandidatuddannelse speciale, Danmarks Biblioteksskole, København.

Johannsen, Carl Gustav & Niels Ole Pors (2002): "Udfordringer og forandringer". Danmarks Biblioteksforening. ISBN: 87-90849-16-7

Likert, Rensis (1932). "A Technique for the Measurement of Attitudes". Archives of Psychology 140, s. 1–55.

Madsen, Jørgen (2007): ”Fra søg til find – Primo i Danmark”. I DF Revy, 30(1), side 4-7

Malik, S., A. Tombros & Birger Larsen (2007): "The Interactive Track at INEX 2006".

118

http://www.db.dk/binaries/041_Malik-Tombros-Larsen-INEX2006-iTrack-LNCS4518.pdf

Molich & Nielsen, 1989: Teaching user interface design based on usability engineering (se Nielsen s. 329 for resten)

Molich, Rolf & Jakob Nielsen (1990a). Improving a human-computer dialogue, Communications of the ACM 33, 3 (March), 338-348

Molich, Rolf & Jakob Nielsen (1990b). Heuristic evaluation of user interfaces, Proc. ACM CHI'90 (Seattle, WA, 1-5 April), 249-256.

Molich, Rolf (2007): Usable Web Design, Nyt Teknisk Forlag. ISBN: 978-87-571-2526-9

Morae, TechSmith corporation (2007): Technical Overview of Morae – Usability Testing software with insight you can share. http://download.techsmith.com/morae/docs/whitepapers/morae_overview_whitepaper.pdf

Morae, TechSmith corporation (2007): TechSmith Rich Recording Technology™: Digitally Synchronizing Data from People and Systemshttp://download.techsmith.com/morae/docs/whitepapers/techsmith_rrt_whitepaper.pdf

Morville, Peter & Louis Rosenfeld (2007): “Information architecture for the World Wide Web”. (3. udgave) O'Reilly. ISBN 0-596-52734-9

Morville, Peter & Jeffery Callender (2010): Search Patterns. O'Reilly Media, Inc.ISBN: 978-0-596-80227-1

Nielsen, Jakob & Rolf Molich (1989). Teaching user interface design based on usability engineering, ACM SIGCHI Bulletin 21, 1 (July), 45-48

Nielsen, Jakob (1993): “Usability Engineering”. Academic Press, Boston, MA. (2. udgave, 1994) ISBN: 0-12-518406-9

Politikens nudansk med etymologi (1999)

W. Quesenbery (2004) "Balancing the 5Es: Usability,". Cutter IT Journal, vol. 17, no. 2, pp. 4-11

Robertson, Stephen E. & Micheline Hancock-Beaulieu (1992): “On the Evaluation of IR Systems.” I Information Processing & Management 28(4), side 457-466.

Saracevic, Tefko (1995): "Evaluation of evaluation in Information Retrieval" I Proceedings of the 18th annual international ACM SIGIR conference on Research and development in information retrieval, side 138-146.

Shamber, L. , M.B. Eisenberg & M.S. Nilan (1990): ”A Re-examination of Relevance: Toward a Dynamic, Situational Definition. I Information Processing & Management, 26(6), side 755-766

119

Sharp, Helen, Yvonne Rogers &  Jenny Preece (2007): "Interaction Design". Wiley. ISBN: 978-0-470-01866-8

Snitker & Co (2008). Rapport om KB og REX/Primo. (vi har fået en elektronisk udgave af KB)

Sormunen, Eero (2000). “A method for measuring wide range performance of Boolean queries in full-text databases”. Doctoral Thesis. University of Tampere. http://acta.uta.fi/pdf/951-44-4732-8.pdf

Sormunen, Eero (2002). "Liberal Relevance..."http://portal.acm.org/citation.cfm?id=564433

Spink, A., H. Greisborf & J. Bateman (1998): “From highly relevant to not relevant: examining different regions of relevance. I Information Processing & Management, 34(5), side 599-621.

Voorhees, Ellen M. (1999). "Proceedings of the 8th Text Retrieval Conference". TREC-8 Question Answering Track Report. pp. 77–82.

Voorhees, Ellen M. (2005): “The Test REtrieval Conference”. Side 3-19 ibogen TREC: experiment and evaluation in Information Retrieval (edited by Voorhees & Harman). ISBN: 0-262-2207303

120

121

10 BILAG

Bilag 1: Molich og Nielsens 10 heuristikker (1990b)Bilag 2: Hornbæk (2005), “Measures of effectiveness”Bilag 3: Hornbæk (2005), “Measures of efficiency”Bilag 4: Hornbæk (2005), “Measures of satisfaction”Bilag 5: Hornbæk (2005), “Measures of specific attitudes towards the interface”Bilag 6: Brooke (1996): System Usability Scale, SUSBilag 7: System Usability Scale, SUS, oversat til danskBilag 8: Pre test-spørgeskema (demografiske data), 5 siderBilag 9: Introduktionsbrev til testpersonerne, 2 siderBilag 10: Dagsorden til post test-interviewet efter usability testenBilag 11: Analyse af funktioner og knapper

Bilag 12: Screendump af Det Kongelige Biblioteks startside, www.kb.dkBilag 13: Mock up af Det Kongelige Biblioteks startside, www.kb.dkBilag 14: Screendump af REX’ startside, ny søgningBilag 15: Mock up af REX’ startside, ny søgningBilag 16: Screendump af REX, visning af søgeresultaterBilag 17: Mock up af REX, visning af søgeresultaterBilag 18: Screendump af REX, bibliografisk post, bogBilag 19: Mock up af REX, bibliografisk post, bogBilag 20: Screendump af REX, bibliografisk post, samling af fotografierBilag 21: Mock up af REX, bibliografisk post, samling af fotografier

Bilag 22: Pre Task-spørgeskemaBilag 23: Work TasksBilag 24: De tre randomiseringerBilag 25: Datagrundlag for CG, 3 siderBilag 26: Datagrundlag for MRR, bøger, 3 siderBilag 27: Datagrundlag for MRR, billeder, 3 sider

122

Bilag 1: Molich og Nielsens 10 heuristikker (1990b)

Simple and natural dialogue: Dialogues should not contain information that is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. All information should appear in a natural and logical order.

Speak the user's language: The dialogue should be expressed clearly in words, phrases, and concepts familiar to the user, rather than in system-oriented terms.

Minimize the user's memory load: The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

Consistency: Users should not have to wonder whether different words, situations, or actions mean the same thing.

Feedback: The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

Clearly marked exits: Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue.

Shortcuts: Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users.

Good error messages: They should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

Prevent errors: Even better than good error messages is a careful design that prevents a problem from occurring in the first place

Help and documentation: Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, be focused on the user's task, list concrete steps to be carried out, and not be too large.

123

Bilag 2: Hornbæk (2005), “Measures of effectiveness”

124

Bilag 3: Hornbæk (2005), “Measures of efficiency”

125

Bilag 4: Hornbæk (2005), “Measures of satisfaction”

126

Bilag 5: Hornbæk (2005), “Measures of specific attitudes towards the interface”

127

Bilag 6: Brooke (1996), System Usability Scale, SUS

128

Bilag 7: System Usability Scale, SUS, oversat til dansk

Post test-spørgeskema

Hvor enig/ uenig er du i følgende udsagn?Meget uenigUenigHverken enig eller uenigEnigMeget enigA01:Jeg tror, at jeg gerne vil bruge dette system ofte

129

130

131

132

133

A02:Jeg fandt systemet unødvendigt indviklet

134

135

136

137

138

A03:Jeg synes, systemet var nemt at bruge

139

140

141

142

143

A04:Jeg tror, jeg ville få brug for hjælp fra en specialist for at kunne bruge dette system

144

145

146

147

148

A05:Jeg mener, at systemets forskellige funktioner var godt integrerede

149

150

151

152

153

A06:Jeg synes, der var for meget inkonsistens i systemet

154

155

156

157

158

A07:Jeg forestiller mig, at de fleste ville lære at bruge dette system meget hurtigt

159

160

161

162

163

A08:Jeg fandt systemet meget besværligt at benytte

164

165

166

167

168

A09:Jeg følte mig meget sikker i at bruge systemet

169

170

171

172

173

A10:Jeg var nødt til at lære en del ting, før jeg kunne komme i gang med dette system

174

175

176

177

178

179

Bilag 8: Pre test-spørgeskema (demografiske data), 5 sider

A. Basis-spørgsmål:

A01.Testpersonens ID: ___________________

A02. Hvad er dit navn? _______________________________________________

A03. Hvilket køn er du? Mand

Kvinde

A04. Hvad er din alder? ___________år

B. Din uddannelse og beskæftigelse:

B05. Hvad er din højeste, færdiggjorte uddannelse?

Grundskole (De første 9-10 års skolegang) Almengymnasial uddannelse (gymnasium, studenterkursus, HF-kursus) Erhvervsgymnasial uddannelse (HHX, HTX) Erhvervsfaglig uddannelse (f.eks. Erhvervsudd., Landbrugs- og søfartsudd.,

Social- og sundhedsudd.) Kort videregående uddannelse (varighed op til 2 år efter studentereksamen) Mellemlang videregående uddannelse/Professionsbachelor (varighed 2-4 år efter

studentereksamen) Bachelor (varighed 3 år efter studentereksamen) Lang videregående uddannelse/Kandidatuddannelse (varighed 2 år efter

bachelor) Forskeruddannelse/Ph.d.-uddannelse

B 06. Hvad er din nuværende beskæftigelse? ___________________________

Hvis du er på efterløn/pension eller uden arbejde, så skriv din seneste beskæftigelse, du definerer dig selv ud fra, her:

___________________________

180

B07. Hvilket videnskabsområde har du hovedsalig beskæftiget dig med i dit arbejdsliv?

Medicin/sundhedsvidenskab Naturvidenskab Humaniora Samfundsfag Andet? _________________

Du er velkommen til at uddybe: ___________________________________________________________

___________________________________________________________

C. Dit informationssøgnings-niveau:

C08. Hvilken internetbrowser bruger du oftest til at gå på nettet? (det er tilladt at sætte flere krydser)

Internet Explorer Firefox Safari Chrome Andre (nævn gerne flere): _____________________ Ved ikke

Hvor ofte søger du: En eller flere gange om dagen

En eller flere gange om ugen

En eller flere gange om måneden

Sjældnere end en gang om måneden

181

Aldrig

C09. På internettet?

C10. På Wikipedia?

C11. På bibliotek.dk?

C12. I videnskabelige databaser?

C13.For hvor mange år siden begyndte du at anvende computer til at søge efter information (f.eks. i videnskabelige databaser, bibliotekskataloger eller på world wide web)? ____________ år siden

Meget uenig UenigHverken enig eller uenig Enig Meget enig

C14. "Når jeg søger efter noget online, finder jeg generelt det, jeg leder efter."

C15.Hvad bruger du internettet til: (sæt gerne flere krydser)

Finde personer, adresser, vejbeskrivelser Købe billetter, dagligvarer, beklædning, rejser, eller andet Bestille billetter til transport, underholdning eller andet Offentlige hjemmesider, f.eks. www.skat.dk eller www.borger.dk Netbank til overførelser af penge

D. Dit biblioteks-brug:

D16. Hvor ofte bruger du bibliotekerne? For eksempel til at låne bøger eller musik, slå informationer op, læse aviser eller gå til arrangementer? Både fysiske biblioteksbesøg og brug af hjemmesider tæller med.

Flere gange om uge En gang om uge Et par gange om månede

182

En gang om månede Nogle gange om åre En gang om året Aldrig

D17. Hvis du ikke svarede aldrig i spørgsmål D16:

Bruger du oftest bibliotekernes forskellige hjemmesider hjemmefra, eller går du oftest på fysisk biblioteksbesøg?

Hjemmefra Biblioteksbesøg

D18. Kommer du indimellem på Det Kongelige Bibliotek?

Flere gange om ugen En gang om ugen Et par gange om måneden En gang om måneden Nogle gange om året En gang om året Aldrig

D19. I hvilken forbindelse anvender du Det Kongelige Bibliotek (sæt gerne flere krydser)?

På jobbet Privat, til informationssøgning eller artikelsøgning Privat, til slægtsforskning Privat, som underholdning Andet: __________

D20.Har du tidligere anvendt Det Kongelige Biblioteks hjemmesides søgefunktion til at finde og

183

bestille bøger eller andre materialer?

Ja Nej

Hvis du svarede JA til spørgsmål D20, så gå videre i testen.Hvis du svarede NEJ til spørgsmål D20, så er du færdig.

D21. Hvor længe er det siden, du sidst anvendte hjemmesidens søgefunktion?

En uge eller mindre En måned eller mindre Tre måneder eller mindre Et halvt år eller mindre Et år eller mindre Mere end et år siden

D22. Hvor ofte anvender du hjemmesidens søgefunktion?

Flere gange om ugen En gang om ugen Et par gange om måneden En gang om måneden Nogle gange om året En gang om året Aldrig

D23. Kan du huske, hvad du søgte efter, sidste gang du brugte Det Kongelige Biblioteks hjemmeside?

Ja Nej

Uddyb gerne: ____________________________________________________________________

184

____________________________________________________________________

____________________________________________________________________

185

Bilag 9: Introduktionsbrev til testpersonerne

Kære [navn på testperson]

Tak fordi du vil hjælpe os med at teste Det Kongelige Biblioteks nuværende søgemaskine, kendt under navnet REX. Din deltagelse er en kæmpe hjælp til vores Speciale ved Danmarks Biblioteksskole. Ja, uden jer testpersoner var der intet Speciale.

Testens formål er at undersøge, hvorvidt søgefunktionen på Det Kongelige Biblioteks hjemmeside er nem og forståelig at anvende og, mere specifikt, nem at søge efter billeder i. Formålet er ikke en vurdering af dig, ligesom det ikke er en vurdering af dine evner.

Testen finder sted i Usability Laboratoriet på vores universitet:

Danmarks BiblioteksskoleBirketinget 62300 København S

Her ses universitetet på et kort: http://map.krak.dk/m/pTcoHEn nem vej at ankomme til universitetet er med metroen (retning Vestamager) til DR Byen St. (9 minutter fra Nørreport, indenfor zone 1).

Gå ned ad Grønjordsvej, drej til venstre ad Brydes Allé og til højre ad Birketinget (følg fortovet langs med den indhegnede boldbane), og du er fremme. Gåturen tager ca. 8-10 minutter.

Tidspunktet aftaler vi. Vi arbejder gladeligt eftermiddag eller weekend, for at få det til at passe med dit skema. Vi tager imod dig på aftalt tidspunkt i receptionen ved hovedindgangen (eller udendørs, hvis vi har aftalt efter kl. 16).

Testen tager ca. 90 minutter. Med en lille kaffe/te-pause i midten til at rense hjernen, kommer du ialt til at lægge 2 timer hos os.

Du skal ikke forberede dig på nogen måde til testen.Uanset, om du har nogen erfaring eller ej med at bruge Det Kongelige Biblioteks

hjemmeside til at søge efter bøger og information, så lad være med at gå ind nu og "øve dig". Brug kun hjemmesiden, hvis du ville have brugt den alligevel. Vi har brug for, at du kommer som du er.

Vi står personligt for at overse testforløbet. Ingen andre vil være til stede under testen end os.Testen er inddelt i to. I den første del får du en række biblioteksposter, altså beskrivelser af

dokumenter, indenfor et emne at se, og vi beder dig om at vurdere på stående fod, om du finder dokumenterne relevante for emnet eller ej. I den anden del beder vi dig om at udføre en håndfuld specifikke opgaver i Det Kongelige Biblioteks hjemmesides søgefunktion, især søgen efter billeder.

Imens du udfører testen, er din opgave at "tænke højt" eller "tale højt". Det vil sige, at du løbende med ord forklarer, hvad du er usikker på, hvad du synes fungerer godt, hvad du synes fungerer dårligt, etc. Ved at "tænke højt" imens du arbejder, hjælper du os til at forstå hvilke dele af hjemmesidens design, som volder problemer for brugerne eller kan gøres bedre - og hvordan Det Kongelige Bibliotek kan løse disse problemer.

186

Dette kan godt komme til at lyde lidt som en eksamen eller test af dine computer-evner. Det er det langtfra. Vi beder dig huske på, at hvis der er nogen her, som bliver testet, så er det de mennesker, som står bag Det Kongelige Biblioteks hjemmeside. Hvis du ikke kan anvende hjemmesiden, så er det hjemmesidens designere, som har skabt problemet.

Vi garanterer din anonymitet som testperson: I Specialet nævner vi din aldersgruppe og job/branchegruppe, men hverken dit navn, adresse eller andre genkendelige data.

Vi optager alt, hvad der sker på din computerskærm under hele testen, således at vi siden kan analysere, hvad du har klikket på, skrevet, og hvordan du generelt har udført testen.

Samtidig bliver du filmet med webkamera under hele testen, således at vi kan se og høre de kommentarer, du "tænker højt" imens og efterfølgende analysere dem.

For nemmest at kunne præsentere for Det Kongelige Bibliotek, hvad du og de andre testpersoner kommer frem til, vil vi gerne have lov til at kunne vise dem udvalgte, små filmklip af testen. Derfor beder vi særskilt om lov til at lade små filmklip af din test indgå i vores Speciale-aflevering, hvis det bliver relevant. Dermed forsvinder noget af din anonymitet som testperson. Specialet skal efter biblioteksloven om "pligtaflevering" gøres frit tilgængeligt til hjemlån via bibliotekerne, så studerende og forskere med interesse i feltet kan læse den.Du er velkommen til at sige nej til dette. Derfor kan du stadig være testperson.

Med venlig hilsen

Jessica Blanca Johansen, stud.scient.bibl ogAninja Helene Grøn, stud.scient.bibl

187

Bilag 10: Dagsorden til post test-interviewet efter usability testen

1. Du kom ind på Det Kongelige Biblioteks Hjemmeside ved at [metode].- Overvejede du andre metoder til at finde derind?- Overvejede du, hvad internetadressen på Det Kongelige Biblioteks hjemmeside kan være?

2a. Du fandt Benny Andersen ved at [søgemetode].- Var det [nemt/besværligt/andet] at finde Benny Andersen?- Er søgeboksen på forsiden synlig? Synlig nok? Har du forslag til forbedringer?- Lagde du mærke til, at nogle af søgeresultaterne viste et billede af bogens forside?

2b.- Var det [nemt/besværligt/andet] at finde antallet af dokumenttyper i dine søgeresultater?- Var du med på, hvad spørgsmålet gik ud på?- Vidste du i forvejen, hvad ordet dokumenttyper dækker over?- Er dokumenttyper og materialer det samme?- Hvilket af ordene dokumenttyper og materialer kan du bedst lide? Eller måske et tredie ord?

3a. Du valgte at finde et [materiale], som viste [område].- De(t) første billede(r) du fandt, kunne du [godt/ikke] få vist.- Fangede du med det samme, at kun nogle af KB's billeder er tilgængelige online?

3b.- Hvor stort kunne du gøre billedet på skærmen?- Var det stort nok?- Kunne du zoome i billedet?- Hvis ja, er du så tilfreds med, hvor meget du kunne zoome?

4. Du [fandt/fandt ikke] Georg Carstensen.Du søgte på [søgemetode] i forsøget på at finde ham.- Var det [nemt/besværligt/andet] at finde ham?- Har du lagt mærke til sætningen "Tip: Brug * som wildcard"?- Ved du, hvordan man bruger *-stjernen?- Ved du, hvad wildcard dækker over?

5. Du [fandt/fandt ikke] et billede af Georg Carstensens statue.Du [fandt/fandt ikke] nogle billeder (af statuer) fra Tivoli.

Hvis billedet blev fundet:Du fandt billedet ved at [kigge på søgeresultatet/åbne posten].- Lagde du mærke til, at der var flere end 1 billede i billedposterne?- Lagde du mærke til, at du kan åbne og se alle disse billeder, ikke bare det første?- Så du knappen "Vis alle"?- Hvor stort kunne du gøre billedet på skærmen?- Var det stort nok?- Kunne du zoome i billedet?- Hvis ja, er du så tilfreds med, hvor meget du kunne zoome?

188

Bilag 11: Analyse af funktioner og knapper

189

190

Bilag 12: Screendump af Det Kongelige Biblioteks startside, www.kb.dk

191

Bilag 13: Mock up af Det Kongelige Biblioteks startside, www.kb.dk

192

Bilag 14: Screendump af REX’ startside, ny søgning

193

Bilag 15: Mock up af REX’ startside, ny søgning

194

Bilag 16: Screendump af REX, visning af søgeresultater

195

Bilag 17: Mock up af REX, visning af søgeresultater

196

Bilag 18: Screendump af REX, bibliografisk post, bog

197

Bilag 19: Mock up af REX, bibliografisk post, bog

198

Bilag 20: Screendump af REX, bibliografisk post, samling af fotografier

199

Bilag 21: Mock up af REX, bibliografisk post, samling af fotografier

200

Bilag 22 – Pre Task-spørgeskema

Spørgeskema til Search task A B C(sæt ring om den rigtige)

Search task udført som den 1. 2. 3. af testpersonen(sæt ring om den rigtige)

Når du har læst opgaven igennem, så svar på nedenstående udsagn.Du bliver stillet de samme to spørgsmål for hver af de tre opgaver.

Meget uenig UenigHverken enig eller uenig Enig Meget enig

01. "Jeg er godt bekendt med opgavens emne”

Meget uenig UenigHverken enig eller uenig Enig Meget enig

02. "Jeg synes, at opgavens emne er interessant”

03.Du er velkommen til at uddybe dine svar: ___________________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

201

Bilag 23 – Work Tasks

Task A

Søgestreng: thule* ekspedition* knud rasmussen*

Opgavebeskrivelse:Din nevø har været på ekspedition til Thule i Grønland, hvor han har været i Knud Rasmussens fodspor. Han har fået gjort dig interesseret i selv, måske en dag, at foretage en sådan ekspeditionsrejse i Grønland. For nu er din egen interesse mere akademisk: Du vil gerne vide noget om Knud Rasmussens egne Thule-ekspeditioner, så du kan diskutere med, når din nevø fortæller om ”alle de ting, han og Knud Rasmussen har oplevet”.

NB: Det er vigtigt at du vurderer hvert enkelt dokument som om det er det første dokument du ser.

Task B

Søgestreng: carl nielsen kompon*

Opgavebeskrivelse:Du er blevet inviteret til en Carl Nielsen-koncert af din søster. Du kender dog ikke ret meget til den gamle danske komponist. Du vil gerne imponere din søster med din viden om Carl Nielsen og er derfor nu gået i gang med at finde billeder, bøger, kompositioner og andet om ham.

NB: Det er vigtigt at du vurderer hvert enkelt dokument som om det er det første dokument du ser.

Task C

Søgestreng: besætte* befri* danmark*

Opgavebeskrivelse:Din ven er i gang med at skrive en bog om Danmarks befrielse og besættelse, som handler om personlige historier fra den tid. Han har ansat dig som assistent og har bedt dig hjælpe med researchen. Du er derfor i gang med at finde materiale til bogen.

NB: Det er vigtigt at du vurderer hvert enkelt dokument som om det er det første dokument du ser.

202

Bilag 24 – De tre Randomiseringer

203

Random 1 Random 2 Random 330 12 205 20 514 17 1627 9 216 26 2918 5 1822 14 2525 11 22 25 191 2 1515 10 1726 22 129 28 3016 3 1410 18 107 29 2620 27 921 7 33 21 1224 30 114 13 2711 16 817 6 2528 1 2423 8 719 15 49 4 613 19 2212 24 138 23 23

Bilag 25 – Datagrundlag for CG

204

205

Bilag 26 – Datagrundlag for MRR over bøger

206

207

208

Bilag 27 – Datagrundlag for MRR over billeder

209

210