UNIVERSITEIT GENT
FACULTEIT POLITIEKE EN SOCIALE WETENSCHAPPEN
USABILITY EVALUATIE ONDERZOEK & USER-CENTERED DESIGN: DROBOTSAPPLICATIE
Beleidsrapport aantal woorden: 23.494
VINCENT VAN ELSUE
MASTERPROEF COMMUNICATIEWETENSCHAPPEN afstudeerrichting COMMUNICATIEMANAGEMENT
PROMOTOR: (PROF.) DR. GINO VERLEYE
COMMISSARIS: MR DIMITRI SCHUURMAN
COMMISSARIS: MR TOM EVENS
ACADEMIEJAAR 2011 - 2012
Dankwoord
Voor de totstandkoming van deze thesis ben ik velen een oprechte dank verschuldigd.
Allereerst gaat mijn dank uit naar mijn promotor, Prof. Dr. Gino Verleye aan de Universiteit Gent, die mij geholpen heeft bij het zoeken naar een onderwerp dat aansluit bij mijn opleiding Communicatiewetenschappen, studierichting Communicatiemanagement. Een paar besprekingen en gedachtewisselingen boden mij een antwoord op vele vragen en namen aanvankelijk bestaande twijfels weg. Een woord van dank wens ik tevens te richten aan de heer Dimitri Schuurman die mij, met enige praktische wenken en pragmatisme motiveerde bij aanvang van het onderzoek.
Uiteraard zou deze Masterproef niet tot stand kunnen komen zijn zonder de bereidwillige medewerking van de 8 respondenten die steeds de tijd vonden om met mij de diverse stadia van het onderzoek te doorlopen en mij, met scherpzinnigheid, tips en suggesties hebben aangereikt waardoor het onderzoek, het beoordelen en het uitschrijven van de resultaten een interessante uitdaging werd.
Het onderwerp van de studie en het verrichte onderzoek heeft mij een solide praktijkervaring bijgebracht en mij geïnspireerd en georiënteerd in het uitvoeren van een aantal taken bij aanvang van mijn prille professionele activiteit.
Een bijzonder woord van dank is gericht aan mijn ouders en mijn vriendin die mij gedurende mijn studies en het uitwerken van deze thesis, steeds met raad en daad hebben bijgestaan.
I
Inhoudstabel Dankwoord ......................................................................................................................................... I Inhoudstabel ...................................................................................................................................... II Lijst met figuren ................................................................................................................................ V Lijst met tabellen ............................................................................................................................ VII Hoofdstuk 1: Executive summary........................................................................................................1 1.1
Doelstellingen ..................................................................................................................1
1.2
Uitgangspunten ................................................................................................................1
1.3
Methodologie ..................................................................................................................2
1.4
Resultaten en aanbevelingen ............................................................................................2
Survey setup ............................................................................................................................3 Survey Analyzer ......................................................................................................................4 Hoofdstuk 2: Inleiding ........................................................................................................................6 Hoofdstuk 3: Gestelde objectieven ......................................................................................................8 Hoofdstuk 4: Theoretische achtergrond ...............................................................................................9 4.1
4.2
4.3
Het onderzoeksobject .......................................................................................................9 4.1.1.
Achtergrond van de de Drobotsapplicatie .............................................................9
4.1.2.
Drobots als innovatie en haar innovatiekenmerken ...............................................9
Het begrip ‘usability’ .....................................................................................................10 4.2.1
Situering van usability als deel van systeem acceptabiliteit .................................10
4.2.2
Usability als multidimensionaal concept .............................................................12
4.2.3
Belang van usability en usability-evaluatie .........................................................13
Usability evaluatie modellen ..........................................................................................15 4.3.1
ISO
9126:
usability als
deel
van
het
productgeoriënteerde
software
kwaliteitsmodel .................................................................................................................16 4.3.2
ISO 9241-11: usability als procesgeoriënteerd evaluatiemodel ............................20
4.3.3
Geconsolideerde modellen en uitbreidingen ........................................................23
4.3.4.
Usability evaluatie en User-centerd design .........................................................26
Hoofdstuk 5: Methodologie...............................................................................................................32 5.1
Observationele gebruikerstest en types ...........................................................................32 II
5.2
5.3.
Verloop van de observationele gebruikerstest en toegepaste technieken ..........................35 5.2.1
Voorbereidingsfase ............................................................................................35
5.2.2
Introductiefase ...................................................................................................36
5.2.3
Uitvoeringsfase van de test .................................................................................37
5.2.4.
Debriefingfase ....................................................................................................37
Data en toegepaste dataverzamelingsmethodes ...............................................................38 5.3.1
Kwantitatieve data ..............................................................................................38
5.3.2.
Kwalitatieve data................................................................................................42
5.4
Gebruikers en Sample ....................................................................................................44
5.5
Beperkingen ..................................................................................................................45 5.5.1
De invloed van de think aloud methode op performantie metingen......................45
5.5.2
Grootte van het sample .......................................................................................45
5.5.3
Omgeving van observatietest ..............................................................................46
5.5.4
Exhaustief testen ................................................................................................47
Hoofdstuk 6: Resultaten ....................................................................................................................48 6.1
“Survey Setup” ..............................................................................................................48 6.1.1
Effectiviteit ........................................................................................................49
6.1.2. Efficiëntie ................................................................................................................50 6.1.3 Error tolerance ..........................................................................................................64 6.1.4 Learnability ..............................................................................................................65 6.1.5 Subjective Satisfaction ..............................................................................................65 6.2 “Survey Analyzer” ..............................................................................................................68 6.2.1 Effectiveness.............................................................................................................69 6.2.2 Efficiency .................................................................................................................69 6.2.3 Error Tolerance .........................................................................................................79 6.2.4 Learnability ..............................................................................................................81 6.2.5 Subjective Satisfaction ..............................................................................................81 Hoofdstuk7: Conclusies ....................................................................................................................84 Hoofdstuk 8: Aanbevelingen .............................................................................................................89 8.1
Survey Setup .................................................................................................................89 III
8.1.1
Effectiviteit, Error Tolerance en Subjective Satisfaction .....................................89
8.1.2
Efficiëntie en Learnability ..................................................................................90
8.2
Survey Analyzer ............................................................................................................94 8.2.1
Efficiëntie, Learnability en Subjectieve Satisfactie..............................................94
8.2.2
Error Tolerantie..................................................................................................95
Bibliografie Bijlagen
IV
Lijst met figuren
Figuur 1: Een model van de attributen van systeem acceptabiliteit (Nielsen, 1993, p. 25) Figuur 2: Attributen van usability testing (Jeng, 2005, p. 99) Figuur 3: Software kwaliteitsmodel (2001, ISO 9126-1 geciteerd in Bevan, 2002, pp. 539-541) Figuur 4: De vier componenten van een Human-Machine-System (Jeng, 2005, p. 98) Figuur 5: Beschrijving van de componenten van usability – usability framework (ISO 9241-11, 1998, p. 3) Figuur 6: Usability-evaluatiemodel (Nielsen, 1993, geciteerd in Abran, Khelefi, Suryn, & Seffah, 2003, p. 13) Figuur 7: De vijf aspecten van usability (Quesenbery, 2004, p. 286) Figuur 8: Het “waterval”-model (Hambling et al., 2010, p. 36) Figuur 9: Iteratieve ontwikkeling (Hambling et al., 2010, p. 40) Figuur 10: UCD-process (Bevan & Curson, 1999, pp. 137). Figuur 11: Usability testing troughout the product lifecycle (Rubin & Chisnell, 2008, p. 28) Figuur 12: Types van Usability testen (Nemeth, 2004, p.269) Figuur 13: Categorie van fouten en ernstgraad Figuur 14: Figuur 14: Toegepast meetmodel voor subjectieve satisfactie gebaseerd op Jeng (2005, p. 102) Figuur 15: Screenshot Drobots: The most powerful survey – Analysis software Figuur 16a: Screenshot Drobots: Lijst van de ingegeven variabelen Figuur 16b: Screenshot Drobots: Ingave van nieuwe variabele Figuur 17: Screenshot Drobots: Ingave van naam van antwoordcategorie Figuur 18a: Screenshot Drobots: Controleren van variabelen en aanpassen Figuur 18b: Screenshot Drobots: Verbeteren Figuur 19a: Screenshot Drobots: Selecteren van antwoordcategorie Figuur 19b: Screenshot Drobots: Aanpassen selecteren Figuur 19c: Screenshot Drobots: Verbeteren Figuur 20a: Screenshot Drobots:Question to Facet Figuur 20b: Screenshot Drobots: Facet to Concept Figuur 21a: Screenshot Drobots: Aanpassingen maken en overzicht Figuur 21b: Screenshot Drobots: Interface voor aanpassingen en verwijderingen Figuur 22a: Screenshot Drobots: Interface voor Data Load Figuur 22b: Screenshot Drobots: Interface New Survey Figuur 23a: Screenshot Drobots: Dataselectie V
Figuur 23b: Screenshot Drobots: Selectie maken Figuur 24a: Screenshot Drobots: Means (grafieken) Figuur 24b: Screenshot Drobots: Means gemiddelden Figuur 25a: Screenshot Drobots: All Means (tabellen) Figuur 25b: Screenshot Drobots: All Means: overzichtslijst Figuur 26a: Screenshot Drobots: Frequencies>Questions Figuur 26b: Screenshot Drobots: Frequencies>Questions Figuur 26c: Screenshot Drobots: Frequencies>Questions Figuur 27a: Screenshot Drobots: Sample results menu Figuur 27b: Screenshot Drobots: Frequencies Figuur 27c: Screenshot Drobots: Functionaliteit Figuur 27d: Screenshot Drobots: Verdeling van de sample
VI
Lijst met tabellen
Tabel 1: Tasks: Survey Setup Tabel 2: Percentage participanten die de taak correct uitvoeren Tabel 3: Efficiëntie Survey Setup: Percentage van participanten die enkele nodige acties uitvoeren om de taak te vervolledigen Tabel 4: Percentage van participanten die enkel foute acties hebben gemaakt van categorie (2) en (3) Tabel 5: Percentage van participanten die geen hulp vroegeng Tabel 6: Slecht scorende taken op hulpfrequenties Tabel 7: Score van error tolerance: survey setup Tabel 8: Scores op facetten van subjectieve satisfactie Tabel 9: Q10: Gepercipieerde toegankelijkheid van de Drobots login-applicatie op de site Tabel 10: Gemiddelde score voor uploaden databestand (Q7) Tabel 11: Frequentiescore voor uploaden databestand (Q7) Tabel 12: Taken Survey Analizer Tabel 13: Effectiviteit Survey Analizer Tabel 14: Efficiëntie Survey Analizer: Percentages van participanten die geen onnodige acties maken Tabel 15: Error tolerantie: Survey Analyzer Tabel 16: Facetten van subjectieve satisfactie: Survey Analyzer Tabel 17: Q6: Gemiddelde score voor duidelijkheid van labels Tabel 18: Q6: Frequentiescore voor duidelijkheid van labels Tabel 19: Q3: Gemiddelde score voor dataselecties Tabel 20: Q3: Frequentiescore voor dataselectie Tabel 21: Algemene score usabilitydimensies voor Survey Setup en Survey Analyzer Tabel 22: Problematisch scorende taken voor Survey Setup Tabel 23: Problematisch scorende taken voor Survey Analyzer
VII
Hoofdstuk 1: Executive summary
1.1
Doelstellingen
We hebben in dit beleidsrapport een usability-evaluatie uitgevoerd aan de hand van observatietest met gebruikersbetrokkenheid. Het primaire doel is de “gemakkelijkheid in gebruik” (usability) van de Drobotsapplicatie te evalueren en te valideren op vijf usability-dimensies. Vervolgens hebben wij de kritieke “hot spots” van de Drobotsapplicatie geïdentificeerd. Daarbij wensen we te achterhalen wat de oorzaak is van een waargenomen gebruiksfout. Dat laat toe de vastgestelde gebruiksproblemen in categorieën te definiëren en een duidelijk beeld te krijgen van de aard van het usability-probleem.
Tot slot worden door analyse van de hotspots aanbevelingen voorop gesteld teneinde de kwaliteit in gebruik (usability) en algemene aanvaarding van Drobots te vrijwaren.
1.2
Uitgangspunten
Het uitgangspunt van Drobots is dat traditionele statistische software een tamelijk hoge graad van knowhow over statistiek vereisen om juiste conclusies uit resultaten te kunnen opmaken. Een andere benadering van Drobots is te weten welke statistische analyses voor welke onderzoeksvragen moeten worden toegepast en wat de voorwaarden zijn om tot statistische betrouwbare uitspraken en conclusies te komen.
Door gebruik te maken van statistische intelligente software doet de Drobots webapplicatie de analyse voor de gebruikers, rekening houdend met de statistische regels en missing data, zodat de gebruiker hun
aandacht
kunnen
toespitsen
op
de
inhoud
van
het
onderzoek.
De door Drobots geboden voordelen zijn snellere resultaten, minder vergissingen, ingebouwde statistische expertise, snelle en gemakkelijke interpretatie van resultaten, betrouwbaarheid en lagere kosten.
Door de nadruk te leggen op betrouwbaarheid en gebruikseenvoud in haar positioneringstrategie en de differentiërende rol die deze aspecten kunnen hebben tegenover van alternatieve statistische verwerkingssoftware werden wij gemotiveerd om een usability-evaluatie uit te voeren, waaruit een
1
beoordeling van de usability-graad van Drobots werd gegeven. Het onderzoek resulteerde in het verstrekken van verbeteringen en aanbevelingen die de acceptatie van Drobots verzekeren.
1.3
Methodologie
Een software evaluatie kan vele vormen hebben. In dit onderzoek richten we ons op een nonfunctioneel usability onderoekl uitgevoerd aan de hand
van een observatie test met
gebruikersbetrokkenheid, toepassing van de think aloud methode en een vragenlijst (Bijlage 26, 27, 28). Op die manier werden kwantitatieve performantie data, kwantitatieve voorkeurs data en kwalitatieve feedback verzameld.
De kwantitatieve performantie- en voorkeursdata, verzameld aan de hand van observatie, helpt ons om de Drobotsapplicatie op de vijf onderscheiden usability dimensies te beoordelen en “hot spots” betreffende usability te definiëren. De dimensies werden gemeten aan de hand van concrete maatstaven. Om de usability-dimensies te beoordelen werd gebruik gemaakt van een 70%slagingspercentage voor het uitvoeren van de taken.
De kwalitatieve data, verzameld aan de hand van de think aloud methode, helpt ons de waargenomen prestaties en “hot spots” te verklaren en vervolledigen.
Hiervoor werden acht deelnemers betrokken die voorafgaandelijk een introductie les tot de Drobotsapplicatie hebben gekregen. Een week later nam de observatietest plaats waarin de drie soorten data werden verzameld. Tijdens het uitvoeren van de test werden respondenten gevraagd om enkele gebruikstaken uit te voeren met de Drobotsapplicatie en daarover luidop na te denken. Door observatie en audio-opnames werden gebruikers acties en opmerkingen vastgelegd. Na de test werden de acht participanten bevraagd aan de hand van een vragenlijst (Bijlage 27, 28). Tot slot werd getracht, voor elke deelnemer, de prestaties in gebruik te verklaren door bijkomende feedback te vragen betreffende gemaakte fouten en opmerkingen.
1.4
Resultaten en aanbevelingen
Alle usability-dimensies hebben een aanvaardbare (70%-90%) tot zeer hoge scores (>90%), zowel voor het “Survey Setup”-gedeelte, als het “Survey Analyzer”-gedeelte. Als de scores voor de taken werden nader worden bestudeerd kunnen wel enkele problematische taakprocessen aangeduid worden.
2
Survey setup Voor het “Survey Setup”-gedeelte werden zes problematische taakprocessen geïdentificeerd: ·
De login-taak
Gebruikers vonden de login-functie niet terug op de startpagina van Drobots. Deze functie werd beschreven als te klein en niet duidelijk genoeg afgebeeld. Daarom stellen wij voor om de loginfunctie groter, duidelijker en opvallender af te beelden. ·
Ingeven van variabelen
Voor het ingeven van variabelen werd een verlies van overzicht tijdens het aanmaken en benoemen van variabelen vastgesteld. Op grond van deze vaststelling opteren wij ervoor om de overzichtstabel van het hoofdmenu “Questionnaire” eveneens toe te voegen in het menu om variabelen te benoemen. ·
Ingeven van waarden
Vele efficiëntiefouten werden gemaakt tijdens het ingeven van waarden van gebruikte Likertschalen om de data op te meten. Een minder technische labelling voor de invulvelden in dit menu en een andere volgorde voor die invulvelden zou hieraan kunnen verhelpen. ·
Correctie van de waarden
Om zowel de efficiëntie in gebruik als de learnability van dit proces te verhogen stellen we voor dat ingegeven antwoordcategorieën een eigen correctie menu krijgen door een “Edit”-menu toe te voegen naast de antwoordcategorie afgebeeld in de lijst. Op die wijze worden gebruikers bewust gemaakt van deze handige functionaliteit. ·
Ingeven van model
Om de efficiëntie van dit proces te verbeteren lijkt het ons gepast om een “wizard” te implementeren in het hoofdmenu “Model” en de submenu’s “Question to Facet”, “Facet to Concept”, “Concept to Topic”. Dit kan de gebruikers verduidelijken en begeleiden in de wijze waarop een topic, concepten, facetten en items kunnen aangemaakt en gelinkt worden. ·
Correctie van het ingegeven datamodel:
Wij stellen voor om, net zoals in het menu “Questionnaires” (cf. het ingeven van variabelen), een overzichtstabel en aanpassingsmenu te implementeren in het hoofdmenu “Model”, alwaar controle van de ingegeven modelelementen plaatsneemt, zodat verkeerd aangemaakt elementen kunnen worden aangeklikt in de tabel om te corrigeren.
3
·
Uploaden van een dataset:
Tijdens het uploaden van de dataset werd steeds opnieuw één bepaalde stap overgeslagen, namelijk het ingeven van “New Survey Name”. Het verlies aan efficiëntie kan verholpen worden door beide menu’s “New Survey Name” en “Data Loading” op dit tijdstip van elkaar gescheiden in twee “tabbladen”- samen te brengen op één tabblad. Door bijkomend voor beide velden proactief aan te geven dat deze verplicht zijn in te vullen, zullen gebruikers meteen ingelicht zijn dat beide invulvelden moeten worden ingevuld.
Survey Analyzer Voor het “Survey Setup”-gedeelte werden zes problematische taakprocessen geïdentificeerd: ·
Opzoeken van een vragenlijst
Alle betrokken deelnemers vergaten de data te selecteren, omdat het bijschrift in het hoofdmenu kennelijk de aandacht niet te trekt. Om dit te voorkomen kan gekozen worden om het bijschrift groter en kleurrijk te maken teneinde de aandacht te vestigen. ·
Vinden van een tabel en grafieken van gemiddelden en frequenties
Gebruikers hadden moeilijkheden met het vinden van tabellen of grafieken van gemiddelden en frequenties. De opdeling van de means-submenu’s tussen “Lists” en “Frequencies” werd als verwarrend ervaren. Ook de opdeling van de submenu’s “Frequencty Tables” en “Questions” onder “Lists” en “Frequencies” bleek onlogisch te zijn volgens de betrokken respondenten. Vandaar opteren wij voor een andere indeling en duidelijker labelling van de menu’s van “Question Level”. ·
Verdeling van het sample raadplegen
Er werd een hoge hulpfrequentie vastgesteld voor het raadplegen van het sample. Wij stellen daarom voor om het tussenmenu, “Frequencies”, te verwijderen. Op deze wijze zien gebruikers meteen beide submenu’s “total sample en “valid responses” en wordt verwarring voorkomen. ·
Opzoeken van een kruistabel voor 2 items
Wij opteren voor een aanpassing/verandering van de kleur in de legende voor de invalide elementen, hetzij door gebruik van een sober kleur, hetzij door de niet valide elementen in de tabel aan te duiden met een pictogram met negatieve connotatie.
4
·
Verandering van de kleur van de Ranking-meter
Om het terugvinden van deze functionaliteit te bevorderen stellen wij voor een zichtbaar menu te ontwikkelen in de interface, door middel van een “change diagram color”-button toe te voegen aan de interface. ·
Impact Diagram van concepten
Twee gebruikers rapporteerden dat zij zich vergist hadden in het aflezen van het diagram als gevolg van het ontbreken van informatie in de tabel. Een weergave van zowel de impact als de score voor elk concept in de tabel zal het overzicht vervolledigen ten behoeve van de interpretatie. De gebruikers krijgen de keuze tussen beide complementaire weergaven van resultaten en kunnen de tabel als een volwaardig hulpmiddel aanwenden voor de interpretatie van het regressiediagram. ·
Het verdere ontwikkelingsproces van de Drobotsapplicatie
Door op een systematische wijze usability-evaluaties te combineren met tevredenheidvragenlijsten, kan informatie verzameld worden betreffende nodige aanpassingen. Iteratie van aanpassingen in Drobots en evaluatie op de vijf gedefinieerde usability-dimensies kunnen dan zorgen voor gerichte aanpassingen naar de behoeften van de huidige doelgroep en prospecten. De hier besproken resultaten kunnen daarbij als benchmark dienen voor verder onderzoek.
5
Hoofdstuk 2: Inleiding
In de hedendaagse samenleving, zijn informatie- en communicatietechnologie (ICT) niet meer weg te denken. Iedere software biedt een aantal functies waarmee specifieke taken en gebruiksdoelen kunnen vervuld worden. De kwaliteit van een softwaresysteem zal, in hoofde van de gebruikers, beoordeeld worden in functie van de door deze gebruikers gewenste verwachtingen waaraan de software zal dienen te beantwoorden (Nielsen, 1993, 24-25) .
In het kader van New Product Development (NPD) zal niet alleen moeten rekening gehouden worden met het implementeren van de, door gebruikers, gewenste functies in een software. De beoordeling van gebruikers strekt verder dan de functionaliteit van de software. Een belangrijk deel van de waargenomen kwaliteit heeft immers te maken met de gemakkelijkheid waarin deze functies zich laten aanwenden (Bevan, 1995, p. 4; Quesenbery, 2004, p. 281). Deze usability kan het verschil maken ten over staan van een vergelijkbare concurrerende software en speelt dus een differentiërende rol.
In dit rapport hebben we onderzoek verricht naar de gemakkelijkheid in gebruik van een statistische verwerkingssoftware ontwikkeld door het IBBT (Interdisciplinaier Instituut voor Breedband en Technologie) Drobots genoemd. Drobots is een online web-applicatie die gebruikers toelaat statistische analyses snel en betrouwbaar uit te voeren. De voordelen die Drobots wenst te bieden tegenover van klassieke software zijn een sneller resultaat, minder vergissingen, ingebouwde statistische expertise, gemakkelijkheid in delen van resultaten, meer betrouwbaarheid en een lagere kostprijs (Drobots.com, 2010, 22 december).
Vanwege de positionering van Drobots op betrouwbaarheid, efficiëntie en eenvoud in gebruik, lijkt het ons waardevol om de “gemakkelijkheid in gebruik” of de gebruiksvriendelijkheid van Drobots onder te bestuderen en te evalueren. Bijkomend laat deze evaluatie ons toe de usability “hot spots” van de Drobots-applicatie te identificeren.
Drobots werd al in het verleden geëvalueerd aan de hand van tevredenheidenquêtes. Het is de eerste keer dat Drobot aan een usability-evaluatie onderworpen werd. De resultaten van deze studie kunnen daarbij als een vergelijkingsstandaard of “benchmark” dienen voor de volgende evaluatie-iteraties en ontwikkelingscyclussen. Wij hebben in dit rapport vooreerst getracht om “usability”zo volledig mogelijk te definiëren en het belang ervan te omschrijven. Na de theoretische situering van een usability-evaluatie werden een aantal usability-evaluatiemodellen toegelicht om dan te komen tot de bijhorende usability-facetten 6
(dimensies). Deze laatste maken het mogelijk om de gemakkelijkheid in gebruik van software te meten, te evalueren en te valideren. Verder gaan we dieper in op het User-Centered Design (UCD) en verduidelijken we de theoretische achtergrond van software development.
In het daaropvolgend deel van het rapport komt de bespreking aan bod van de aangewende methoden, de gebruikte technieken en de verzamelde data nodig om de usability-evaluatie van Drobots en de daarbij horende
usability-“hot-spots” te identificeren.
Deze technieken bestaan uit
een
observatieonderzoek van gebruikers tijdens aanwending van de Drobotsapplicatie en de toepassing van de think aloud-methode. Na het geven van een overzicht van de belangrijkste resultaten en de daaropvolgende conclusies stellen we enkele aanbevelingen voorop in het vooruitzicht de graad usability van Drobots te verbeteren door oplossingen aan te bieden voor problematisch scorende onderdelen ten aanzien van “usability”. Daarbij trachten we een concrete oplossing te bieden van de in beeld gebrachte problemen door het opstellen van aanbevelingen.
7
Hoofdstuk 3: Gestelde objectieven
1. Bieden van een theoretische situering en verduidelijken van het begrip usability binnen het kader van software development.
2. De lezer informeren betreffende de bestaande usability-evaluatiemodellen en bijhorende gedefinieerde facetten en meetmaten die het mogelijk maken om Drobots te evalueren met als doel de interpretatie van het gevoerde onderzoek en resultaten mogelijk te maken.
3. De lezer een inzicht bieden in de theoretische achtergrond betreffende software ontwikkeling, UCD en de plaats van usability–evaluatie daarbinnen.
4. Verduidelijken van de toegepaste technieken zoals het observatie-onderzoek van gebruikers en de think aloud-methode.
5. Beoordelen van Drobots op basis van de vijf onderscheiden usability-dimensies in dit onderzoek toegepast en op basis daarvan de hot-spot en hun oorzaak achterhalen.
6. Formuleren van oplossingen en aanbevelingen met screenshots betreffende deze usability-hot spots om de algemene gebruiksvriendelijkheid van Drobots te verhogen.
8
Hoofdstuk 4: Theoretische achtergrond
4.1
Het onderzoeksobject
We zullen een korte beschrijving geven betreffende het programma Drobots, alvorens dieper in te gaan op de theorie en methodologie betreffende usability als evaluatiemethode van software. Deze omschrijving zal de lezer helpen om een beeld te krijgen van het onderzoeksobject en de context van het usability-onderzoek te begrijpen.
4.1.1. Achtergrond van de de Drobotsapplicatie Drobots werd ontwikkeld door het Interdisciplinair Instituut voor Breedband en Technologie (IBBT). Het IBBT is een onafhankelijk onderzoekscentrum dat in opdracht van de Vlaamse Overheid werkt en als doel heeft “het innoveren en het stimuleren van ICT door organisaties te ondersteunen bij innovatie onderzoek en ontwikkeling” (IBBT, n.d.).
Het IBBT hield zich oorspronkelijk, onder de spin-off Kpiware, bezig met het ontwerpen en uitwerken van statistische projecten voor privéorganisaties en overheden. Na verloop van tijd werden steeds dezelfde problemen vastgesteld bij het uitwerken van statistische projecten; moeilijke statistische analyses die te weinig geautomatiseerd of efficiënt zijn, te weinig duidelijke grafische functies bevatten en een gebrek aan gebruiksvriendelijkheid en eenvoud hebben (IBBT, n.d.).
Vanuit deze vaststellingen bleek de nood om een efficiënte oplossing te zoeken en werd hiervoor het statistisch intelligent programma, Drobots ontwikkeld met als doel het proces van statistische analyses en interpretatie tegelijk betrouwbaar, gemakkelijk en te vereenvoudigen.
4.1.2. Drobots als innovatie en haar innovatiekenmerken Drobots en de innovatie die de software biedt, bestaat uit het creëren van enerzijds een nieuw statistisch intelligent programma dat statistische analyse vergemakkelijkt en anderzijds gebruik maakt van de interactieve mogelijkheden van de bestaande technologie die zorgen voor het gemakkelijk delen van resultaten. Hierdoor worden er, in vergelijking met traditionele statistische programma’s, enkele belangrijke voordelen geboden.
Het uitgangspunt van Drobots is dat traditionele statistische software een tamelijk hoge graad van knowhow betreffende statistiek vereisen om juiste conclusies te trekken uit resultaten, te weten welke 9
statistische analyses voor welke onderzoeksvragen moeten worden toegepast en wat de voorwaarden zijn om tot statistische betrouwbare uitspraken en conclusies te komen. De complexe functionaliteiten van een verwerkingsprogramma in combinatie met een ingewikkeld vakgebied (cf. statistiek) zorgen voor een behoefte aan een gemakkelijk in gebruik zijnde verwerkingssoftware (Drobots.com, 2010, 22 oktober).
Door gebruik te maken van statistische intelligente software doet de Drobotsweb-applicatie de analyse voor de gebruikers, rekening houdend met de statistische regels en missing data, zodat de gebruiker zijn aandacht kan toespitsen op de inhoud van het onderzoek. Er worden automatisch de juiste methodes en modellen gekozen om de data van de gebruiker te verwerken tot resultaten. Om de interpretatie te vergemakkelijken zijn duidelijke grafische figuren ontwikkeld die op basis van een kleurenschema aangeven welke resultaten belangrijk zijn en hoe deze moeten worden gepercipieerd. (Drobots.com, 2010, 22 oktober) Zodoende wordt naast de rapporteringfase ook de verwerking- en analysefase versneld in het onderzoeksproces.
De voordelen die Drobots wenst te bieden zijn snellere resultaten, minder vergissingen, ingebouwde statistische expertise, snelle en gemakkelijke distributie van resultaten, meer betrouwbaarheid en lagere kosten (Drobots.com, 2010, 22 oktober). Vanuit deze omkadering zullen wij de Drobotsoftware aan een usabilityevaluatieonderzoek onderwerpen. Het usability aspect van Drobots speelt een belangrijke en zelfs differentiërende rol tegenover van klassieke software programma’s. Drobots legt naar gebruikers toe, de nadruk op de snelheid, flexibiliteit en eenvoud. Vanuit dit oogpunt lijkt een usability evaluatie van Drobots op zijn plaats om het verdere commerciële succes ervan te verzekeren.
4.2
Het begrip ‘usability’
4.2.1
Situering van usability als deel van systeem acceptabiliteit
Usability zou eenvoudig kunnen omschreven worden als de gebruiksvriendelijkheid waarmee een product kan gebruikt worden om enkele specifieke taken te vervullen. Het gebruik van de term gebruiksvriendelijkheid wordt echter gemeden, omdat usability naar een veel bredere inhoud en toepassingen verwijzen (Nielsen, 1993, p. 23). Termen die als synoniem voor usability gelden zijn “gemakkelijkheid in gebruik” of “kwaliteit in gebruik” (Bevan, 1995, pp. 3-6). We verklaren ons nader.
10
Binnen het kader van “software testing en development” zal usability deel uitmaken van de acceptabiliteit van een systeem in hoofde van gebruikers. Usability zal in dit opzicht bijdragen aan de adoptie van een softwaresysteem door het product aantrekkelijk te maken en frustraties tijdens ingebruikname te verlagen. Gebruikers zullen gemakkelijker doorheen de software en interface navigeren om bepaalde taken met het programma effectief uit te voeren. Een hoge graad van usability zal op die manier onrechtstreeks het commercieel belang in softwareproductie dienen (Nielsen, 1993, pp. 24-26).
Systeem acceptabiliteit kan onderverdeeld worden in praktische acceptabiliteit en sociale acceptabiliteit. Sociale acceptabiliteit –zoals de term zelf aangeeft- handelt over de aanvaarding van het systeem gebaseerd op heersende normen en waarden binnen de cultuur (Nielsen, 1993, p. 24).
De praktische acceptabiliteit gaat over aanvaarding van het systeem vanuit praktische overwegingen zoals de “usefulness” van een software systeem of de mate waarin de software gebruikers toelaat om het
doel
van
gebruik
(functie)
te
verwezenlijken.
(Nielsen,
1993,
p.
24).
Het is op deze praktische acceptability dat usability zich zal toespitsen.
Zoals de schets verder illustreert kunnen we, de usefulness terug in twee verschillende concepten opsplitsen namelijk “utility” en “usability”. De eerstgenoemde term verwijst naar de mate waarin de software de functies bevat die gewenst zijn door gebruikers. Usability zal daarentegen verwijzen naar de gemakkelijkheid waarmee de gewenste functies van een softwaresysteem te gebruiken zijn.
Figuur 1: Een model van de attributen van systeem acceptabiliteit (Nielsen, 1993, p. 25)
11
4.2.2
Usability als multidimensionaal concept
Zoals uit bovenstaande figuur blijkt is usability een abstract multidimensionaal concept dat wordt beschreven als bestaande uit meerdere, verschillende concrete aspecten of dimensies. In dit voorbeeld zijn dat er vijf, namelijk: Efficiency, Effectiveness, Erroro Tolerance, Learnability en Memorability. Deze dimensies definiëren het abstracte concept “usability”. Een belangrijk toepassingsgebied van ‘usability’ is, zoals eerder vermeld, terug te vinden in software ontwikkelingen en specifiek in software verificatie en software validatie (Myers, Corey & Badgett, 2012, p. 143). De aangewende term usability verwijst, in het kader van softwaredevelopment, naar een evaluatiemethode en -model waarbij de “gemakkelijkheid in gebruik” van een softwareproduct wordt gemeten en geëvalueerd (Jeng, 2005, pp. 101).
Om dit abstract concept te meten wordt gebruik gemaakt van de concretere, bijhorende dimensies waarmee usability wordt gedefinieerd (supra.). De “ease of use” (cf. usability) wordt dan bepaald door concrete metingen betreffende elke dimensie (Rubin & Chisnell, 2008, pp. 156-157). Zo zal bijvoorbeeld effectiviteit van het gebruik vaak als deel van usability worden gedefinieerd. De dimensie effectiviteit kan dan bijvoorbeeld gemeten en beoordeeld worden door het aantal respondenten dat slaagt in het uitvoeren van zijn taak met de software (Jeng, 2005, pp. 101-103).
Door voor elke dimensie van usability concrete meetstaven toe te passen kunnen de bijhorende dimensies gekwantificeerd worden en kan een usability meetmodel of evaluatiemodel worden opgesteld (Rubin & Chisnell, 2008, pp. 166-167). Dit usability-evaluatiemodel kan dan, aan de hand van de concrete dimensies, de graad van usability van een software meten en evalueren (Elbing & Bonnie, 2000, pp. 291-292).
We dienen op te merken dat verschillende auteurs en internationale standaarden in de literatuur verschillende usability-dimensies hebben beschreven, wat tot gevolg heeft dat er geen eenduidig usability-evaluatiemodel is ontwikkeld (Tabel 1). Vaak zal de toepassing van en keuze voor een evaluatiemodel grotendeels afhankelijk zijn van de mate waarin de dimensies passen bij de ontwikkelingsnoden van het softwareproduct (Jeng, 2005, pp. 98-99).
12
Figuur 2: Attributen van usability testing (Jeng, 2005, p. 99)
We zullen verder in dit beleidsrapport enkele invullingen van het usability evaluatiemodel bespreken en vergelijken.
Verder verwijst usability niet enkel naar een software evaluatiemodellen om de gemakkelijkheid in gebruik te valideren, maar ook naar een software ontwikkelingsproces gericht is op het ontwikkelen van een usable product; het user-centered design. Usability en gebruikersbetrokkenheid zal daarbij gebruikt worden als bron voor innovatie van bij het begin van het ontwikkelingsproces. Alvorens dieper in te gaan op de usabilityevaluatiemodellen en het UCD zullen we hierna vooreerst het belang van usability-evaluatie in software development uiteenzetten.
4.2.3
Belang van usability en usability-evaluatie
Usability moet gezien worden vanuit het standpunt van New Product Develoment, waarin een meerwaarde wordt gecreëerd voor gebruikers, door aandacht te geven aan de “ease of use” van een softwareproduct. Het in rekening nemen van usability in het kader van software development door middel van usability-evaluatie kan bijdragen tot commercieel succesvolle, hoog kwalitatieve en winstgevende softwareproducten (Bevan & Macleod, 1994, pp. 132-133; Dumas & Redisch, 1999, p. 14).
Producten kunnen vele functionaliteiten bevatten die kunnen helpen in het vervullen van onze dagdagelijkse en professionele doelen. Belangrijk is dat deze functionaliteiten eveneens gemakkelijk te gebruiken zijn om de barrières tot adoptie en in gebruikneming bij de doelgroep te reduceren (Rubin & Chisnell, 2008, p. 22). Een systeem dat “unusable” is kan mogelijks veel van zijn commercieel potentieel verliezen, ondanks de vele en goed werkende functies die het kan bevatten. 13
Usability-evaluatie van softwareproducten zal het mogelijk maken de frustratie bij gebruik te reduceren door vóór de “release” te anticiperen op ergernissen van gebruikers (Rubin & Chisnell, 2008, p. 22). Dit gegeven zorgt ervoor dat kwalitatieve producten kunnen worden geproduceerd en brengt voor software producerende organisaties enkele bijzondere voordelen met zich mee. Een door gebruikers hoog kwalitatief gepercipieerd product biedt de mogelijkheid een hoge vraagprijs te vragen en heeft een belangrijk financieel en commercieel voordeel tot gevolg (Bevan & Macleod, 1994, pp. 132-133; Rubin & Chisnell, 2008, p. 22; Dumas & Redisch, 1999, p. 14).
Een ander competitief voordeel is differentiatie. Hoge mate van gemakkelijkheid in gebruik maakt het mogelijk om producten te onderscheiden van andere en gelijkaardige producten op de markt (Rubin & Chisnell, 2008, p. 23; Dumas & Redisch, 1999, p. 14). Hierbij kan verwezen worden naar het succes van Apple.
De aandacht voor usability kan een positieve basis vormen voor interactie en communicatie met gebruikers (Rubin & Chisnell, 2008, p. 22). Eerste ervaringen met een product kunnen het daaropvolgend gebruik beïnvloeden. Een hoog kwalitatief product dat gemakkelijk aan te leren (een aspect van usability) en te gebruiken is kan een motivatie vormen voor consumenten om het product op regelmatiger basis te gebruiken (Flavian, Guialiu. & Gurrea, 2005, pp. 10-14; Dumas & Redisch, 1999, pp. 14-15).
Op grond hiervan kan een positieve marketing- en vertrouwensrelatie worden opgebouwd, waaruit een organisatie een lange termijn relatie kan opbouwen met zijn klanten en andere stakeholders (Fjermestad. & Romano , 2003; 585-589; Dumas & Redisch, 1999, Pp. 14-15).
Het verifiëren en valideren van software, en specifiek de usability ervan biedt tenslotte een oplossing voor de onzekerheid om een innovatie op de markt te brengen, doordat het product op een geïnformeerde manier kan worden aangepast aan gebruiksnoden. Zo kan het risico van het op de markt brengen van een software met zware usabilityproblemen gereduceerd wordt. (Rubin & Chisnell, 2008, p. 23).
Door software aan een usability-evaluatieonderzoek te onderwerpen, kan de usabiliy van een software worden geëvalueerd en wordt er een basis gevormd waarop de software kan aangepast worden in de richting naar gebruikersnoden toe. Gemakkelijkheid in gebruik kan dan aan de hand van een model gemeten en geëvalueerd worden en in de vorm van een iteratief ontwikkelingsproces verbeterd worden (Mao, Vredenburg, Smith & Carey, 2005, pp. 105-109; Bevan & Curson, 1999, pp. 137).
14
Na de bespreking van deze voordelen zullen we hier verder twee internationale standaarden omschrijven, betreffende usability, die van belang zijn voor het usability-onderzoek van Drobots. Wij zullen deze met mekaar vergelijken en onze keuze voor het hier toegepast evaluatiemodel motiveren.
4.3
Usability evaluatie modellen
De usability evaluatiemodellen worden beschreven in Internationale Standaarden (ISO 9126-1 en 9241-11). De Internationale Organisatie voor Standaardisatie (ISO) is een non-governementele organisatie die een samenwerking voorziet tussen technische en academische experts om onderzoek te voeren naar methodes en gebruiken van uiteenlopende vakgebieden. Experts uit verschillende landen, sectoren, private en academische instituties werken samen in heterogeen samengestelde onderzoekscomités, met als doel, zowel vanuit industrieel, technisch als academisch perspectief concensus te vinden over de best toe te passen methodes en praktijken in kader van bepaalde ontwikkelingsprocessen. Software development en -testing is een van die zaken waar de ISO (International Organisation for Standardization, n.d) zich op toespitst. De internationale standaarden betreffende het “usability-aspect” van een software zijn ISO 9126 -1 en 9241-11. Ze bieden een theoretisch kader voor usability en definiëren de bijhorende dimensies waaruit het concept bestaat. Beide hanteren weliswaar verschillende definities van usability en definiëren verschillende bijhorende dimensies (Bevan, 2009, p. 109; Bevan, 2002, pp.35-38). Bijgevolg komt men tot verschillende usability evaluatiemodellen.
Het grote onderscheid tussen beide standaarden kan in grote lijnen samengevat worden door te omschrijven dat de ISO 9126 -1 een productgeoriënteerde visie is, waarbij geen rekening gehouden wordt met de context of use en de ergonomische aspecten in gebruik van software. Deze spelen echter een belangrijke rol in het reëel gebruik van een software en dienen dan ook betrokken te worden in een usability meet –en evaluatiemodel. ISO 9241-11 neemt deze elementen wel in rekening in de definiëring en evaluatie van “usability” (geciteerd in Abran, Khelefi, Suryn, & Seffah , 2003, p. 1-11).
Wij zullen beide standaarden omschrijven en vergelijken, omdat ze beiden relevant zijn voor de usability-evaluatie van Drobots.
15
4.3.1 ·
ISO 9126: usability als deel van het productgeoriënteerde software kwaliteitsmodel
Het Software Quality model
Om de algemene kwaliteit van software te evalueren kunnen enkele kwaliteitskarakteristieken worden onderscheiden. Deze worden samengevat in het “quality model”, zoals beschreven in de ISO standaard 9126 (Bevan, 1999, pp. 89-90). Dit quality model kan worden aangewend zowel in het ontwikkelingsproces als in het validatieproces van een softwareproduct en zal gehanteerd worden om te controleren of het software product beschikt over de relevante software karakteristieken (Behkamal, Kahani & Akbari, 2009, pp. 599-600; Bevan, 2002, pp. 539-541).
Er
worden
binnen
het
“Software
Quality
Model”
zes
algemene
multidimensionale
kwaliteitskarakteristieken van een softwaresysteem onderscheiden. Deze zouden kunnen gezien worden als kwaliteitskarakteristieken of factoren die een softwareproduct kan bevatten en meerwaarde bieden betreffende de kwaliteit van een product (Abran, Khalifi & Suryn, 2003, pp. 325-327). De zes onderscheiden (hoofd)karakteristieken zijn usability, relaibility, functionality, efficiency, maintainibility en portability.
Figuur 3: Software kwaliteitsmodel (2001, ISO 9126-1 geciteerd in Bevan, 2002, pp. 539-541)
16
De hoofdkarakteristieken zijn multidimensionaal en bevatten bijgevolg subkenmerken waaruit ze zijn opgebouwd (Figuur 3). Deze maken de hoofdkarakteristieken, net zoals in het eerder omschreven multidimensionaal concept usability, meetbaar (Jung, Kim & Chung, 2004. p. 89).
Elk van deze hoofdkarakteristieken staan onafhankelijk tegenover elkaar en leveren een onderscheiden en individuele bijdrage aan de kwaliteit van het software product Abran, Khalifi & Suryn, 2003, p. 327). . Afhankelijk van de noden van gebruikers en de daarbij aansluitende doelstellingen van het software development en -testproces zullen alle of sommige karakteristieken al dan niet in verschillende mate relevant zijn om te onderzoeken. Het “Quality Model” wordt dus niet altijd in haar geheel toegepast in de ontwikkeling en evaluatie van software. In plaats daarvan zal op enkele relevante factoren aandacht besteed worden in softwareontwikkeling en –evaluatie (Behkamal, Kahani & Akbari, 2009, pp. 599-600). Zo zal voor een banksoftware eerder het aspect van security belangrijk zijn, terwijl voor een commerciële entertainment software, usability een meer belangrijk element zal zijn dan het element security. In het kader van onderhavige studie zullen we het verder specifiek hebben over het “usability-concept” en gaan we niet in op andere kwaliteitskarakteristieken van het “Software Quality Model”. We zullen ons vooral concentreren op het hierin beschreven usabilitymodel en de mate waarin een evaluatiebasis vormt voor de usability van een softwareproduct. ·
De software kwaliteitskarakteristiek “usability” binnen het “Software Quality Model”
Usability wordt binnen de internationale standaard 9126 gedefinieerd als “a set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users” (1991, ISO 9126-1 geciteerd in Bevan, 2002, p. 538). Volgens dit model worden de volgende subkarakteristieken van usability gedefinieerd: understandability, learnability, operatability en attractiveness.
We lichten kort de definities toe (ISO 9126-1, 2001, p. 9): -
Understandability “the capability of the software product to enable the user to understand whether the software is suitable, and how it can be used for particular tasks and conditions of use”
-
Learnability “the capability of the software product to enable the user to learn its application“
-
Operatability “the capability of the software product to enable the user to operate and control it.”
-
Attractiveness “the capability of the software product to be attractive to the user.”
Alhoewel in de dimensie “Understandability” rekening wordt gehouden met “particular tasks and conditions of use” blijft usability binnen deze het “Software Quality Model” en ISO 9126-1 beschreven vanuit een productgeoriënteerde visie. De nadruk in de definitie wordt gelegd op de 17
attributen (eigenschappen) waaraan een product moet beantwoorden om –volgens zijn definitie- als een ‘usable product’ door te gaan. Anders gezegd, de evaluatie van usability zal gebeuren op grond van de eigenschappen dat een softwareproduct bevat, zonder daarbij de interactie van die attributen met context van gebruik (Cf. context of use) in rekening te nemen (Abran, Khalifi & Suryn, 2003, p. 327; Seffah, Donyaee, Kline & Padda, 2006, pp. 160-163). De “context of use” bestaat naast het systeem zelf uit drie kenmerken, namelijk wie de gebruikers zijn, voor welke taken of doelen en in welke omgeving gebruikers de software zullen toepassen (Shackel, 1991, pp. 22-24; Maguire, 2001, pp. 454-464; Jeng, 2005, p. 98). De productkenmerken van een software, betreffende usability, moeten dus worden gerelateerd aan deze drie elementen om tot een volwaardige evaluatie te komen (Dix, Finlay, Abowd & Beale, 2004, 154-155).
Een productgeoriënteerde evaluatie, zoals het usability-evaluatiemodel beschreven in ISO 9126-1, dat enkel rekening houdt met karakteristieken van een systeem zal dan tekortkomen in het bieden van een beoordeling van reëel en gebruik en praktisch acceptatie van de software (Abran, Khalifi & Suryn, 2003, p. 327-330; Bevan & Azuma, 1997, pp. 170-174). Om dit alles nader te verklaren dienen we te verwijzen naar wat het “Human-Computer Interaction” wordt genoemd. ·
Human-Computer Interaction
HCI is een vakgebied binnen informatie en -communicatietechnologie dat de interactie tussen gebruiker en systeem onderzoekt, waaruit kwaliteit in gebruik uit voortvloeit. Daarbij wordt gesteld dat rekening gehouden moet worden met drie verschillende elementen van de context van gebruik die invloed kunnen hebben op de interactie tussen gebruikers en systeem (Shackel, 1991, pp. 22-24; Sarmento, 2005, pp. 1-5; Dix, Finlay, Abowd & Beale, 2004, pp. 3-4). Het gemakkelijk functioneren van een software wordt aldus afhankelijk gezien van de gebruiker, de taak die met het softwaresysteem dient vervuld te worden, de karakteristieken van het systeem zelf en de interactie tussen deze elementen. Dit alles neemt plaats binnen een bepaalde omgeving wat eveneens zijn invloed zal hebben op deze elementen en het gebruik. Bijgevolg oefenen deze elementen hun invloed uit op de “gemakkelijkheid in gebruik” van een software en dienen deze eveneens ingecalculeerd te worden in een evaluatieonderzoek betreffende de usability van een software. Deze elementen zijn het softwaresysteem zelf, de gebruiker, de specifieke taak waarvoor de software gebruikt wordt en de omgeving (Shackel, 1991, pp. 22-24; Judy Jeng, 2005, p. 98; Bevan, pp. 115-127; Yokela, Iivari, Matero & Karukka, 2003, pp. 56-57).. De vier elementen die de uiteindelijke “usability” beïnvloeden en bepalen worden hier verder beschreven.
18
Figuur 4: De vier componenten van een Human-Machine-System (Jeng, 2005, p. 98)
Naast het in rekening brengen van systeemattributen, mogen de kenmerken van gebruikers en hun achtergrond niet uit het oog worden verloren. Zo zal de groep gebruikers waar men zich op kan richten ervaren zijn of reeds veel kennis hebben opgebouwd in gebruik van gelijkaardige systemen (Nielsen, 1993, pp. 27-31). Daarentegen kan de gebruikerspopulatie of doelgroep van een software net niet ervaren zijn en kunnen zij vrijwel leken zijn in hun vakgebied. Hoe het ook zij, er zal moeten rekening gehouden worden met deze elementen van gebruikers wil men een reële beoordeling geven met betrekking tot de “usability” (Nielsen, 1993, pp. 175-178, 43-48; Rubin & Chisnell, 2008, pp. 77-78).
Vaak zal een systeem een bepaalde functie bevatten waarmee de gebruiker een specifieke taak of gebruiksdoel kan oplossen. Ook de aard van deze taak dient in rekening genomen te worden (Maguire, 2001, p. Guillemette, 1995, p. 215). Zo kan het taakproces en de opeenvolgende uit te voeren acties om een bepaald doel of taak te verwezenlijken met een software verschillen in tijdsduur en complexiteit wat zijn invloed zal hebben om de “usability” van een software (Nielsen, 1993, pp. 185187). Een bestand uploaden bijvoorbeeld, zal minder complex en langdradig zijn dan manueel gehele lijst van gegevens in te voeren in een systeem. Belangrijk is dat de taak uit het onderzoek vergelijkbaar en representatief is met een realistisch taakscenario. De kwaliteit van gebruik van de functies zal dan eveneens afhankelijk zijn van de aard van specifieke taken waarvoor de software bedoeld is. Vandaar moet het onderzoek betreffende usability gericht zijn op het in rekening nemen van dat specifiek, representatief taakscenario (Rubin & Chisnell, 2008, pp.182-184).
Tenslotte kan het uitvoeren van een taak met een systeem door een bepaalde gebruiker in verschillende omgeving gebeuren (Maguire, 2001, pp. 459-461). Zo kan het reëel gebruik bijvoorbeeld thuis plaatsnemen of op kantoor. Afhankelijk van de omgeving kunnen meerdere of andere externe invloeden tijdens gebruik een rol spelen (Yokela, Iivari, Matero & Karukka, 2003, pp. 58; Rubin & Chisnell, 2008, pp. 94-99). Ook de manier van gebruik kan eveneens verschillend zijn in andere omgevingen (cf. thuis of professioneel gebruik). Ook deze factoren dienen te worden ingecalculeerd in de beoordeling van de usability van een software. 19
De eenzijdige benadering van de definitie zoals beschreven in ISO 9126-1, die usability als een onafhankelijke productgebonden factor percipieert, kan derhalve niet welslagen (Bevan & Azuma, 1997, pp. 173). Het zal immers de interactie zijn tussen de productkenmerken enerzijds en de gebruikscontext anderzijds, die de gemakkelijkheid in gebruik van het systeem volwaardig zullen bepalen. Wil men tot een volwaardige beoordeling van usability van een product komen dan dient tevens de context van gebruik in acht te worden genomen (Shackel, 1991, pp. 22-24; Bevan, 1995, pp. 115-127).
Vanuit dit standpunt kunnen we stellen dat het kwaliteitsmodel van de ISO 9126 geen gepaste definitie en model voor de evaluatie van usability biedt. De statistische verwerkingssoftware, Drobots, vertoont, net als andere softwareproducten, enkele specifieke contextgebonden kenmerken betreffende het gebruik. Deze moeten in rekening gebracht worden om tot een genuanceerd en evenwichtig beeld te komen betreffende de evaluatie van de kwaliteit in gebruik. Wij zullen verder gaan met de bespreking van een alternatief ISO model dat zich wel leent tot een usability evaluatie waarbij rekening wordt gehouden met de context van gebruik. Op die manier wordt usability vanuit een realistische gebruiksituatie beoordeeld.
4.3.2 ·
ISO 9241-11: usability als procesgeoriënteerd evaluatiemodel
Context of use
Als evaluatiemethode erkent de ISO standaard 9241-11 (1998, pp. 3-7) het belang van het interactieproces tussen gebruiker, systeem en omgeving om de usability van een software te meten
Volgens de ISO standard 9241-11 (1998, p. 2) betreffende usability (ISO 9241, 1998) kan deze term gedefinieerd worden als “the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use”. Een opmerkelijk verschil met het begrip “usability” besproken binnen het kwaliteitsmodel van ISO 9126-1 is het in rekening nemen van het concept “context of use” en diens bijhorende invloedsfactoren. Bovendien brengt de definitie van ISO 9241-11 de geleverde performantie van het systeem in een realistische gebruikssituatie en de individuele bevrediging bij gebruikers in rekening (Abran, Khalifi & Suryn, 2003, p. 329-330; Bevan, 2009 pp. 109-110). Door de incorporatie van deze context of use wordt dit meetmodel beschouwd als een betere basis om usability evaluatieonderzoek op toe te passen. De mate van efficiëntie, effectiviteit en satisfactie, die te samen de usability vormen, zullen daarbij beïnvloed worden door de elementen van context of use (Seffah, Donyaee, Kline & Padda, 2006, pp. 165-166; Bevan, 1994, pp. 134-136; ISO 9241, 1998, pp. 3-6).
20
Figuur 5: Beschrijving van de componenten van usability – usability framework (ISO 9241-11, 1998, p. 3)
We kunnen besluiten dat de definitie van usability, zoals besproken in de ISO standaard 9241, een goede evaluatiebasis vormt om de kwaliteit in gebruik van een software te meten en te beoordelen doordat de gebruikscontext en de performantie van gebruikers in het behalen en het uitvoeren van enkele specifieke taken en doelstellingen, in acht wordt genomen. ·
Dimensies
In deze definitie worden slechts drie meetbare subkarakteristieken onderscheiden, zulks in tegenstelling tot de productgeoriënteerde visie op usability in het software kwaliteitsmodel beschreven volgens ISO 9126-1. De te onderscheiden dimensies van usability zijn effectiveness, efficientie en satisfactie. Deze concretere subkarakteristieken of dimensies van “usability” maken het mogelijk om bepaalde concrete kwantificeerbare data betreffende de usability-graad van een softwareproduct te verzamelen (ISO 9241-11, 1998, p. 10; Jeng, 2005, pp. 101-110).
Effectiviteit en efficiëntie zullen gemeten worden aan de hand van objectieve, performantie data, verzameld door observatie en waarnemingen betreffende de prestaties van gebruikers in het uitvoeren van taken met het softwaresysteem (cf. realistisch gebruik en taakscenario). Subjectieve satisfactie en aantrekkelijkheid zullen gemeten worden door preference data, verzameld aan de hand van vragenlijsten of aantal positieve commentaren gegeven door gebruikers (Nielsen & Levy, 1994, pp. 66-72; Frokjear, Hertzum, & Hornbaek, 2000, pp. 347-351; Rubin & Chisnell, 2008, pp. 166-167).
21
Figuur 6: Usability -evaluatiemodel (Nielsen, 1993, geciteerd in Abran, Khelefi, Suryn, & Seffah ,2003, p. 13)
Effectiviteit De effectiviteit kan worden gedefinieerd als de “completeness and accuracy with which users achieve their goals” (ISO 9241-11, 1998, p.2). Dit betekent dat deze dimensie vooral zal onderzoeken in welke mate gebruikers contextgebonden doelen kunnen verwezenlijken met het softwareproduct. Wat deze taken en doelen specifiek zijn kan variëren naargelang de software of applicatie die onderzocht wordt (Rubin & Chisnell, 2008, 182-184). Toegepast op Drobots zou het percentage van gebruikers die slagen in het uitvoeren en invoeren van statistische data, één van de processen binnen de Drobotsapplicatie, een voorbeeld kunnen zijn van een effectiviteitsmaatstaf.
Efficiëntie De efficiëntie - waarmee doelstellingen kunnen worden uitgevoerd - verwijst naar het aantal middelen dat nodig is om een bepaald taak te verwezenlijken (ISO 9241-11, 1998, p. 2). Een efficiënte software zal dus zorgen voor een verhoogde werkproductiviteit met eenzelfde aantal middelen (Ovaska, 1999 Augustus, p. 59). Deze middelen kunnen het aantal acties bevatten dat gebruikers nodig hebben om aan de hand van de software of applicatie een taak of doel te vervolledigen. Efficiëntie kan dan bijvoorbeeld gemeten worden door het aantal acties (klikken met de muis, leeg veld invoeren, ...) die gebruikers nodig hebben om een taak te vervolledigen in vergelijking met het minst aantal mogelijke acties waarmee een taak kan vervolledigd worden . (Quesenbery, 2008, pp. 84; Rubin & Chisnel, 2008, p. 166; Jeng, 2005, p. 101).
Efficiëntie kan verder enkele belangrijke aanwijzingen geven met betrekking tot de organisatie en duidelijkheid van informatie binnen de interface (Jeng, 2005, p. 108).. Een efficiënte interface maakt 22
het mogelijk om gemakkelijk te navigeren doorheen de applicatie. Vertragingen in de acties van gebruikers zullen vaak te maken hebben met verwarring of onduidelijkheid betreffende de plaats of inhoud van een bepaald menu’s en label’s, die een functie voorzien binnen de interface (Quesenbery, 2008, pp. 84-85; Rubin & Chisnel, 2008, pp. 4). Als men de motivatie van een foute actie kan achterhalen, kan men usability-problemen detecteren en corrigeren.
Subjectieve satisfactie De bevrediging of voldoening van gebruikers betreffende een software zal meten in welke mate het systeem als aantrekkelijk en bevredigend in gebruik wordt gezien door de gebruikers (ISO 9241-11, 1998, p.2; Nielsen, 1993, p. 26; Bevan & Macleod, 1994, pp. 132).. Deze dimensie zal meestal gemeten worden aan de hand van vragenlijsten (Bijlage 27, 28), waarbij gebruikers bevraagd worden over hun subjectieve voorkeuren betreffende de software (Rubin & Chisnell, 2008, p. 166).
Aantrekkelijkheid van een software is van belang voor de acceptatie van een software. Een software zal niet enkel taken effectief en efficiënt moeten kunnen uitvoeren, maar dient daarnaast een bepaalde visuele aantrekkelijkheid en bevrediging in het gebruik van het product bieden. De waargenomen aantrekkelijkheid in gebruik van een programma kan met andere woorden een belangrijke factor zijn voor de aanvaarding en potentiële adoptie van een software(Nielsen, 1993, pp. 24).
4.3.3
Geconsolideerde modellen en uitbreidingen
Op basis van de vorige beschreven modellen hebben verschillende auteurs geconsolideerde en uitgebreide modellen ontwikkeld met verschillende dimensies en verschillend aantal dimensies. We dienen op te merken dat de verschillende dimensies en modellen, globaal gezien vaak sterk lijken op elkaar.
Vaak worden in deze verschillende modellen de definitie van usability zoals beschreven in ISO 9241, vanwege de incorporatie van de “context of use”, als basis gebruikt voor de opbouw van een usability evaluatiemodel. Daarbij worden andere dimensies toegevoegd om de volledigheid van de usabilitymeting betreffende de software te garanderen.
De bespreking en vergelijking van alle varianten van de usability evaluatie modellen overschrijdt het doel van dit rapport. Wij zullen ons daarom slechts richten op het usability software model van Quesenbery dat toegepast is in het usability onderzoek gericht op de Drobotsapplicatie.
23
·
Usability evaluatie model van Quesenbery
Het model van Quesenbery bestaat uit vijf dimensies, namelijk “Efficiency”, “Effectiveness”, “Satisfaction”, “Learnability” en “Error tolerance” (Quesenbey, 2008, pp. 82-89.). Daarbij worden de dimensies van het usability model beschreven in ISO 9241-11 integraal opgenomen in en vormen “Efficiency”, “Effectiveness” en “Satisfaction” de basis van het Usability evaluatie model van Quesenbery. Deze drie dimensies werden reeds uitvoerig besproken.
Figuur 7: De vijf aspecten van usability (Quesenbery, 2004, p. 286)
Twee belangrijke dimensie “Learnability” en “Error Tolerance” zijn toegevoegd aan het standaard evaluatie model beschreven in ISO 9241-11.
Learnability Learnability werd overgenomen van het model beschreven in ISO 9126-1. De “ease to learn” wordt daarbij beschreven als “the capability of the software product to enable the user to learn its application“ (1991, ISO 9126-1 geciteerd in Abran et al., 2003. p. 12). Quesenbery heeft echter het Learnability-aspect binnen zijn usability evaluatiemodel definieerd als “how well the product supports both initial orientation and deepening understanding of its capabilities” (Quesenbery, 2008, pp. 88). Learnability zal dan nagaan hoe goed respondenten de software leren gebruiken binnen een bepaalde tijdsperiode, wat afhankelijk is van de mate waarin de initiële oriëntatie en ervaring in complementair gebruik wordt toegelaten.
Een interface, wil hij gemakkelijk aan te leren zijn, dient eveneens begrepen te worden. Daarom moet deze consistent en voorspelbaar zijn, in die zin dat gebruikte terminologie en de plaats van informatie, controle en functies gelijkaardig zijn. Deze functies zouden moeten verschijnen daar waar ze verwacht worden door gebruikers. Een duidelijke structuur en categorisering van menu’s of een “wizard”, die begeleiding geeft bij complexe stappen, helpen de learnability–rate in een software te verhogen (Quesenbery, 2008. p. 88-89). We benadrukken dat de contextuele kenmerken zoals eerdere 24
ervaringen en bestaande kennis van gebruikers een grote invloed zullen uitoefenen op de beoordeling van learnability.
Het belang van deze dimensie ligt hem in het principe dat de eerste ervaringen met een product het daaropvolgend gebruik kan beïnvloeden (Nielsen, 1993, p. 27-28). Het leerproces zal daarbij de eerste gebruikservaringen met een systeem vormen. Een systeem dat gemakkelijk aan te leren is, zou voor een doorsnee gebruiker een motivatie kunnen zijn om het product op meer regelmatige basis te gebruiken (Flavian, Guialiu. & Gurrea, 2005, pp. 10-14 ;Dumas & Redisch, 1999, pp. 14-15).
Error Tolerance Error Tolerance is een usability-aspect dat initieel werd toegevoegd in het pioniersmodel van Jacob Nielsen (Jeng, 2005, p. 99; Nielsen, 1993, pp 32-33). Quesenbery heeft deze dimensie overgenomen en gedefinieerd als “how well the design prevents errors, or helps with recovery from those that occur” (Quesenbery, 2008, p. 87). Een usable software zal met andere woorden helpen voorkomen dat gebruikers fouten maken enerzijds en gemaakte fouten helpen corrigeren anderzijds.
Een taak zal bestaan uit een aantal acties die een gebruiker dient te vervolledigen om het doel van de taak te bereiken. Vaak zal er een takenscenario aangemaakt zijn met daarin de te volgen stappen of acties om de taak te vervolledigen (Pinelle & Gutwin, 2003, pp. 293-294; Rubin & Chisnell, 2008, pp. 184-187; Nielsen, 1993, pp. 185-187). Om dit concreet voor te stellen kan verwezen worden naar de nodige acties die iemand moet ondernemen om in een bepaald programma een bestand op te laden. Deze taak zou dan kunnen bestaan uit: login, klik op OK, ga naar menu “upload”, klik op uploud, selecteer het bestand, bevestig. Een foute actie zou dan kunnen zijn dat men niet het juiste paswoord ingeeft of een verkeerd “menu” selecteert.
Foute acties kunnen voorkomen worden indien gebruikers voorzien worden van informatie die zal helpen om de juiste keuzes te maken binnen het systeem. Het herstellen van foute acties zal dan vooral een kwestie zijn van de mate en de snelheid waarmee een software, feedback geeft over de fout die werd gemaakt door gebruikers. Dit biedt de mogelijkheid om de fout te herstellen (Quesenbery, 2008, pp. 87-89). Bijvoorbeeld aan de hand van een waarschuwingsvenster dat de gebruiker wijst op de fout en duidelijk aangeeft waar de fout zich bevindt.
Engaging Tenslotte dienen we op te merken dat met “Engaging” wordt verwezen naar de subjectieve bevrediging of satisfactie dat een software bij gebruikers teweeg brengt en wordt gedefinieerd als ‘the degree to which the tone and style of the interface makes the product pleasant or satisfying to use” (Quesenbery, 2008, pp. 86).. De definitie komt dus overeen met de beschrijving van de dimensie 25
subjectieve satisfactie, zoals beschreven in ISO 9241-11, hetgeen verwijst naar de mate waarin de software bevredigend in gebruik is.
4.3.4. Usability evaluatie en User-centerd design Usability evaluatie verwijst naar de verificatie en validatie van een ontwikkelde of in ontwikkeling zijnde software in functie van gemakkelijkheid in gebruik (Rubin & Chisnell, 2008, pp. 35-37).
Met User-centerd design (UCD) wordt verwezen naar een software development model waarin usability onderzoek en gebruikers centraal worden gesteld en een belangrijke bron vormen voor de design van het softwareproduct. UCD berust op een cyclisch of iteratief-incrementeel softwaremodel. Het iteratief karakter verwijst naar het herhalen van usability evaluatieonderzoek doorheen het ontwikkelingsproces van software-innovaties (Gulliksen, Goransson, Boivie, Blomkvist, Persson, & Cajander, 2003, pp. 401-403; Bevan & Curson; 1991, pp. 137; Mayhem, 1998, pp. 127-128; Yokela et al, 2003, p. 55; Olson & Olson, 1991, pp. 61-67).
Wij zullen vooreerst een toelichting geven van enkele fundamentele kenmerken van algemene software development modellen, om het belang van het iteratief-incrementeel te verduidelijken. Verder gaan we dieper in op het UCD, dat op het algemeen iteratief-incrementeel model en ontwikkelingsproces gebaseerd is. ·
Algemene software modellen
Software developmentmodellen structureren het software developmentproces. Het doel van deze modellen is op een adequate en coherente manier tot een gewenst softwareproduct te komen door gestructureerd en gefaseerd het ontwikkelingsproces te doorlopen. Het softwareontwikkelingsproces bestaat uit verschillende fasen, waaronder software testing er één van is (Software testen kan zich richten op het testen van zowel functionele als non-functionele aspecten van software, zoals usability.) De verschillende ontwikkelingsmodellen hanteren vrijwel dezelfde fasen. Wat deze modellen in hoofdzaak onderscheidt is de plaats van de fase van software testen binnen het developmentproces (Hambling, Morgan, Samaroo, Thompson, & Williams, 2010, pp. 36-41, 144; Chung, & Leite, 2009, pp. 364-374).
Het ontwikkelingsproces van een softwareproduct wordt een development lifecycle genoemd, wat verwijst naar het proces waarin initieel de wensen van klanten worden verkregen, onderzocht, geïdentificeerd en vervolgens verder in functionele en non-functionele vereisten worden vertaald om het softwaresysteem op basis daarvan stapsgewijs te ontwikkelen en achteraf te testen (James, 2009, pp. 5-6). 26
Software testing alsook usability testing, zullen in meer klassieke software developmentmodellen, slechts hun toepassing kennen op het einde van de ontwikkelingscyclus (Hambling et al., 2010, pp. 3640, 46).
Het traditionele “Waterfall”-model is een klassiek lineair model waarin een reeks fasen worden doorlopen en de noden van gebruikers worden vertaald naar functionele en technische vereisten van het systeem. Op grond van deze specificaties wordt stapsgewijs een softwareprogramma ontwikkeld. De volgende fase van ontwikkeling kan slechts beginnen nadat de vorige fase beëindigd is. Het is pas op het einde van de ontwikkelingscyclus dat een testfase wordt gepland alwaar het systeem wordt getoetst aan de initieel geïdentificeerde gebruikersnoden. Dit geldt als een laatste check-up om eventuele aanpassingen te maken of om vertrouwen te krijgen in de software teneinde deze op de markt te brengen (Agarwal, & Tayal ,2007, pp. 28-31).
Figuur 8: Het “waterval”-model (Hambling et al., 2010, p. 36)
Een laattijdig en eenmalig testmoment houdt in dat reeds veel beslissingen zijn genomen met betrekking tot het design van de innovatie en veelal investeringen zijn uitgevoerd vooraleer fouten en tekortkomingen in het softwareproduct geïdentificeerd worden. Software is een specifiek product waarbij modules of componenten worden ontwikkeld en geïntegreerd tot een systeem. Dit betekent dat problemen in de software niet zomaar kunnen worden opgelost door zich te focussen op een specifiek deel waarin de tekortkomingen zich bevinden. Daarbij komend kan het zijn dat onbedoelde effecten optreden in goed functionerende onderdelen als gevolg van een correctie in een bepaalde probleemcomponent (regression testing) (Hambling et al., 2010, pp. 36-37; Engstrom & Runeson, 2010, pp. 3-4). Een verandering of verwijdering van een element zal alsdan gevolgen hebben voor het gehele systeem en zal opzijn beurt dienen te worden gecorrigeerd en getest. Verder kunnen niet enkel
27
de goede onderdelen, zonder de slechte onderdelen van het softwareproduct geproduceerd en op de markt gebracht worden. Gebruikers willen een volledig afgewerkt product waarmee ze kunnen werken om bepaalde gebruiksdoeleinden te bereiken (Hambling et al., 2010, pp. 50).
Dit impliceert dat het corrigeren van de tekortkomingen recht evenredig meer kosten met zich meebrengen in verhouding tot de fase en tijdstip waarin het developementprocess gevorderd is. Een fout die vroeg en in het beginstadium van ontwikkeling is geïntroduceerd en pas laat wordt ontdekt zal gedupliceerd zijn in de volgende fasen van ontwikkeling. Het vorenstaande wordt beschreven in het kosten-escalatiemodel van Boehm (1987, pp. 43-54; Bhoem, B. & Bassil, 2001, pp. 135-137).De kosten in geld en tijd voor het identificeren en corrigeren van fouten wordt vergeleken met de tijd binnen het verloop in de ontwikkelingscyclus.
Tegenover dit model werd een verbeterde versie ontwikkeld, zijnde het V-model. De belangrijkste wijziging is de accentverlegging naar de verhouding tussen het software developmentproces en het testproces doorheen de levenscyclus. Het komt er op neer dat beide processen dichter bij mekaar gebracht worden waarbij met elke level van development een software testingfase moet worden gepland en uitgevoerd. Het software ontwikkelingsproces wordt opgedeeld in een aantal levels, waar bijhorende testlevels worden aan gelinkt. Bij elk opeenvolgend designlevel zal het werkproduct telkens parallel getest worden. Op die wijze worden vier testlevels onderscheiden, namelijk component testing, integratietesting, system testing en acceptance testing. Testing (Takanen, Demott & Miller, 2008, pp. 78-79).
Alhoewel in dit model de verificatie van software doorheen het ontwikkelingsproces verhoogd wordt, gebeurt de validatie van de software door gebruikers nog steeds op het einde van het ontwikkelingsproces. In zover de, in de beginfase opgenomen, wensen en verwachtingen van gebruikers wijzigen dan zal late validatie en gebruikersbetrokkenheid het risico inhouden dat op het einde van het ontwikkelingsproces van een softwaresysteem een product ontwikkeld werd dat uiteindelijk niet gewenst is door gebruikers of nog steeds veel aanpassingen vergt (Hambling et al., 2010, pp. 35-40).
Verificatie onderzoekt in welke mate het ontwikkelde werkproduct, na elke developmentfase, aansluit bij de wensen, initieel aan het developmentproces gesteld, door gebruikers. De nadruk ligt zodoende op de conformiteit van het software product afgezet tegen de aanvankelijk gestelde vereisten (De Almeida, H.O., Silva, L., Ferreira, G., Loureiro, E. & Perkusich, 2007, pp. 25-26).
Validatie spits zich toe op de evaluatie van het werkproduct op grond van de op dat tijdstip geldende gebruikersnoden die zich in de loop van het developementproces stellen en kunnen verschillen van de 28
aanvankelijk gestelde noden. Validatie zal onderzoeken of het ontwikkeld product op het einde van de ontwikkelingcyclus voldoet aan de verwachtingen van klanten (De Almeida et al., 2007, pp. 25-26).
Om het hiervoor geschetst risico in te dijken kwam er een evolutie op gang naar geavanceerde flexibele development modellen. Deze modellen worden cyclical models of iterative-incrementele modellen genoemd en het softwareproduct wordt stap voor stap (incrementeel) ontwikkeld in een aantal iteraties (herhalingen). Bij elke iteratie doorloopt er telkens een deel van de software de vier fasen van de developmentcyclus. Namelijk definiëren van de noden, ontwikkelen, coderen en testen (Hambling et al., 2010, pp. 40-41).
Het cyclisch softwaremodel typisch gekenmerkt door een hoge flexibiliteit in verband met het inspelen op veranderingen in de noden van gebruikers. Door het herhalen van de cyclus ontstaat een interactie tussen het testen en developement wordt meteen een zicht geboden op veranderende requirements vanwege gebruikers. Op die manier kan na elke iteratie gepeild en geëvalueerd worden welke eigenschappen van het werkproduct er dienen aangepast of toegevoegd te worden. Dit alles laat toe de veranderde gebruikersbehoeften telkens opnieuw als stuwende kracht te gebruiken voor het verbeteren en verfijnen van de software en fouten vroeg te ontdekken (Westfall, 2009, pp. 140-145; Geordiadou, 2003, pp. 125-132. Hambling et al., 2010, pp. 35-40).
Figuur 9: Iteratieve ontwikkeling (Hambling et al., 2010, p. 40)
Het is op dit laatstgenoemde developmentmodel waarop het UCD gebaseerd is.
29
·
User-centered design
UCD is de toepassing van het algemeen iteratief-incrementeel software development-model op usability. Het specifiek karakter van het UCD-model is dat het in het bijzonder gericht is op usability of op het ontwikkelen van usable software (Bevan & Curson, 1999, 137-138).
De definitie van usability zoals geponeerd in ISO 9241 wordt hernomen en centraal wordt gesteld. Het model wordt als basis voor de usability evaluatie gebruikt binnen het UCD-ontwikkelingsproces. De incorporatie van de context of use in de definitie van ISO 9241 is van belang voor de integratie van het evaluatiemodel in het UCD-proces. Zoals eerder omschreven heeft de context een groter impact op de waargenomen kwaliteit in gebruik (Yokela et al., 2003, pp. 54-56). De vier fasen in het UCD-proces zijn onderzoek naar de noden op grond van een analyse van “context of use” (taken, gebruikers, omgeving), design, ontwikkelen van een prototype en evaluatie van het prototype. Na de evaluatie van het prototype herbegint de gehele cyclus van begin af aan opnieuw (Maguire, 2001b, pp. 578-598).
Figuur 10: UCD-process (Bevan & Curson, 1999, pp. 137).
De ontwikkeling van de software begint met het verzamelen van de noden en de daarbij horende definiëring van de context of use waarop een werkproduct (prototype) gebouwd wordt (Gulliksen, 2003, pp. 401-404). Vervolgens wordt het werkproduct geëvalueerd aan de hand van een usability evaluatiemodel zoals beschreven in de standaard ISO 9241 of een verdere uitbreiding ervan (Yokela et al., 2003, pp. 54-58; Abran et al., 2003, pp. 3, 8-11). Usability-evaluatie zal dus plaatsgrijpen op het einde van elke iteratie en als bron dienen voor de verdere aanpassingen in de volgende cyclus. 30
Doorheen de iteraties zal het design steeds dichter tegen de veranderende usability-noden van de gebruikers worden opgebouwd. De korte cyclus, de snelle herhaling en opeenvolging van de usability evaluatiefasen zorgen ervoor dat de usability van een systeem vroeg kan worden gemonitord en daardoor het ontwikkelingsproces sturen (Rubin & Chisnell, 2008, pp. 11-18).
Het UCD zal een probleem van laattijdige ontdekking van usability-fouten vermijden en zal door de flexibele en iteratieve structuur snel een prototype produceren dat kan getest worden op zijn usabilitywaarde van bij aanvang van ontwikkeling. De resultaten van usability evaluatie zullen, doorheen elke cyclus, de verdere ontwikkeling stuwen naar een usable product (Gulliksen, 2003, pp. 405-407).
UCD zal, door haar iteratief karakter, de beperkingen, zoals herwerkingsrisico’s en logheid van klassieke modellen voorkomen. Niet enkel kosten worden gereduceerd in de toepassing van deze ontwikkelingsmethode; er worden tevens vroegtijdig kwalitatieve producten geproduceerd (Abras, Maloney-Krichmar & Preece, 2004, p. 767; Hambling et al., 2010, pp. 35-41).
31
Hoofdstuk 5: Methodologie
In dit deel gaan we in op de toegepaste technieken, methodes en meetmaten om de usability van de Troostapplicatie te meten. Wij hebben gebruik gemaakt van een gebruikerstest waarin de usability van Drobots werd geëvalueerd door observatie van gebruik. Daarin hebben we enkele methodes gecombineerd om zowel kwalitatieve als kwantitatieve informatie betreffende usability te verzamelen.
5.1
Observationele gebruikerstest en types
In ons onderzoek hebben we gebruik gemaakt van een observationele methode met betrokkenheid van gebruikers om data te collecteren. Concreet worden gebruikers geobserveerd gedurende het hanteren van het softwareproduct (Dumas, 2003, p. 1096). Verschillende informatie zal bekomen worden in functie van de onderzoekdoelstellingen en usability-evaluatie types.
Een gebruikerstest ter evaluatie van de usability van een software kent verschillende vormen. We kunnen vier types onderscheiden, namelijk een exploratory, assessment, validation en comparison onderzoek (Rubin & Chisnell, 2008, p. 28). Elk type evaluatie zal in minderde en meerdere mate gericht zijn op het verzamelen van hetzij kwalitatieve informatie, hetzij kwantitatieve informatie of een combinatie van beide.
Elk van deze types heeft zijn plaats in het UCD-ontwikkelingsproces. Het type dat het meest toepasselijk zal zijn, is afhankelijk van de informatienoden van het ontwikkelingsproces waarin de software zich bevindt. Zo zullen de informatienoden in het begin van een ontwikkelingsproces eerder bij een oriëntering en validatie van de basisassumpties liggen voor verdere ontwikkeling, terwijl tegen het einde van het ontwikkelingsproces vooral een verificatie en validatie zal nodig zijn om te zien of de gevalideerde functies op een adequate manier zijn geïmplementeerd. Het ontwikkelingsstadium bepaalt met andere woorden de informatienoden en onderzoeksdoelen van de usability-evaluatie (Rubin & Chisnell, 20008, pp. 28-43).
32
Figuur 11: Usability testing troughout the product lifecycle (Rubin & Chisnell, 2008, p. 28)
Een exploratory onderzoek zal in de beginfase van een onderzoek worden toegepast en zal gebruik maken van informele, theoretische testmethoden die vooral gericht zijn op het verzamelen van kwalitatieve data om de software te beoordelen. Deze kwalitatieve data zullen verzameld worden door een intense interactie en bespreking van het gebruik tussen participant en “evaluator” Vaak kan enkel gebruik gemaakt worden van een conceptuele voorstelling van de software in plaats van een echt werkzaam prototype (Nemeth, 2004, p.269; Galitz, 2007, pp. 770).
Een assessment-test zal eerder halfweg in de ontwikkelingscyclus de software beoordelen. Daarin zal kwalitatieve data alsook bijkomende kwantitatieve performantiedata verzameld worden door gebruikers taken te laten uitvoeren om de usability te observeren ter beoordeling van de software. De nadruk ligt op kwalitatieve informatie, niet op verzameling van kwantitatieve performantiedata. In vergelijking met een exploratory onderzoek zal de interactie tussen participant en “evaluator” tijdens de test worden gereduceerd en meer formeel gehouden (Galitz, 2007, pp. 770; Rubin & Chisnell, 2008, pp. 34-35).
Een validation test zal laat in het ontwikkelingsstadium worden toegepast, wanneer een volwaardige afgewerkte software voor handen is en er nood is aan het verkrijgen van een beeldvorming met betrekking tot de acceptatie van de kwaliteit in het gebruik. De nadruk zal dan liggen op het evalueren van de software tegenover enkele vooropgestelde gebruikseisen (Nemeth, 2004, p.268-269). In 33
tegenstelling tot de assessment test zal de nadruk liggen op het verzamelen van kwantitatieve performantie data betreffende het gebruik. Bijkomend zal er kwalitatieve informatie verzameld worden om de performantie te verklaren en te ondersteunen. Vanwege de nadruk op kwantitatieve meetmaten zal de interactie tussen participant en “evaluator” tijdens de test nog sterker worden gereduceerd en tot een minimum worden herleid. Het gevolg hiervan is dat er aangepaste kwalitatieve data verzamelingmethoden moeten toegepast worden (Rubin & Chisnell, 2008, pp. 34-37).
Tenslotte kan een comparative test in alle stadia van ontwikkeling worden toegepast. Dat kan gaan om het vergelijken van het gebruik tussen verschillende groepen, de vergelijking van verschillende softwareversies of het vergelijken van de software tegenover andere concurrerende software (Rubin & Chisnell, 2008, pp. 37-44).
Figuur 12: Types van Usability testen (Nemeth, 2004, p.269)
Wij hebben gekozen voor een gebruikerstest in de vorm van een validation test omdat Drobots zich reeds in een ver stadium van ontwikkeling bevindt. Daarbij is er geen nood aan een grotendeels kwalitatieve evaluatie (cf. assessment test) of oriëntering betreffende verdere ontwikkeling (cf. explorative test). Een vergelijking met andere software en andere groepen lijkt ons voorbarig in dit stadium (cf. comparison test). Wel is er nood aan een evaluatie waarin Drobots wordt gevalideerd in zijn opzet om een gemakkelijk te gebruiken software te ontwikkelen (cf. validation test). Via een validation test hebben we, aan de hand van arbitrair vooropgestelde “benchmarks”, trachten te evalueren in welke mate Drobots geslaagd is in zijn opzet om een gebruiksvriendelijk software te produceren (Rubin & Chisnell, 2008, pp. 36-37, pp. 80-82). Dit werd verwezenlijkt door gebruikers de software te laten gebruiken en kwantitatieve performance en preference data te verzamelen tijdens de observatie. De kwantitatieve performance en preference data meten de vijf hiervoor beschreven dimensies van het evaluatiemodel van Quesenbery. 34
Bijkomend hebben we kwalitatieve informatie verzameld die verklaart waarom er bepaalde slechte prestaties tijdens het geobserveerd gebruik werden vastgesteld in de kwantitatieve performantiedata. Zodoende kunnen we usability “bottlenecks” identificeren en nader bepalen hoe deze volgens de gebruikers kunnen worden opgelost. Dit werd bewerkstelligd door tijdens de validation test gebruik te maken van een “think aloud”-methode.
5.2
Verloop van de observationele gebruikerstest en toegepaste technieken
In het kader van “usability evaluatie onderzoek” kan de implementatie van de test verder worden ingedeeld in de volgende ondergeschikte fasen. Dit zijn de voorbereidingsfase, introductiefase, de eigenlijke testuitvoering en een debriefingfase (Nielsen, 1993, pp. 187-192). Wij bespreken deze fasen hier verder met betrekking tot Drobots.
5.2.1
Voorbereidingsfase
In de voorbereidingsfase worden de testomgeving, takenscenario’s en log-instrumenten voorbereid zoals bepaald in de strategie van aanpak (cf Rubin & Chisnell, 2008, pp. 65-91; Nielsen, 1993, p. 187). Een usability test neemt niet noodzakelijk plaats in een laboratorium, wel in een omgeving die het natuurlijk en representatief gebruik van de software mogelijk maakt. Dit houdt in dat als het toekomstige toepassingsgebied van de software voor een gebruiker een werkomgeving is, dat het softwaresysteem eveneens getest moet worden binnen deze of een gelijkaardige omgeving (Ovaska, 1999 Augustus, pp. 59).
Wij hebben gekozen om gebruikers in hun normale werkomgeving te laten werken opdat een zo natuurlijk mogelijke werkomgeving wordt geëvenaard wat dan voor onze respondenten representatief is voor effectief gebruik (Tullis, Fleischman, McNulty, Cianchette, & Bergel, 2002, pp. 7-8). Bij sommige respondenten, zoals in het geval van de participerende studenten, was dat hun studieruimte. De usability test uitgevoerd met de medewerkers van de VUB en privé-sector namen plaats in hun professionele werkruimte (kantoor), wat voor de betrokkenen een natuurlijke omgeving uitmaakt en representatief is voor het in gebruik nemen van software zoals Drobots.
Daarbij komend wordt in deze fase testmateriaal, nodig voor de test, opgelijst en voorbereid (Rubin & Chisnell, 2008, pp. 153-199). Het in dit onderzoek gebruikte testmateriaal bestaat uit een inleiding, pretest, posttest, takenstructuur met gespecificeerde acties die moeten gevolgd worden, audioapparatuur, instructies voor de deelnemers en een checklist (Bijlage 25, 26, 27, 28). 35
Verder werden beslissingen genomen ten aanzien van loginstrumenten om kwalitative en kwantitatieve data te verzamelen (Dix et al., 2004, p. 344). De kwalitatieve data werd verzameld aan de hand van audiotapes. De kwantitatieve data werd verzameld door middel van een manuele logmethode, waar de acties van gebruikers stap voor stap konden gevolgd, beschreven en genoteerd worden volgens een gestructureerde takenlijst (Bijlage 25).
5.2.2
Introductiefase
De introductiefase verwijst naar het voorstellen van de software, test doelstellingen en de testprocedure aan de gebruikers. Gebruikers dienen namelijk voorbereid te worden (Nielsen, 1993, pp. 188-189).
Belangrijk is immers te zorgen voor een minimum aan kennis betreffende software in hoofde van gebruikers vooraleer hen een product te laten gebruiken en op basis daarvan de software te valideren (Rubin & Chisnell, 203, pp. 187-188). Omwille van de complexiteit van een statistische software werd een introductieles en training gegeven aan de deelnemers. Daarbij werd een introductiefilmpje getoond, een presentatie gegeven over de verschillende functies en een toelichting over de wijze waarop deze functies dienen gebruikt te worden. Daarenboven werd de software kort individueel met elk van de respondenten doorlopen in een interactieve “tutorial”. Dit alles nam ongeveer één uur in beslag. Elk van de respondenten kreeg daarna gedurende een week de kans om Drobots te leren kennen en uit te proberen, vooraleer het starten van de werkelijke observatietest. Op die manier leerden de respondenten de basisfunctionaliteiten, nodig voor gebruik en dus ook voor de usability evaluatie van Drobots, kennen.
Verder werd vóór de test toelichting verstrekt om de rol van gebruikers te verduidelijken in de usability test. Eén van de besproken punten is de vermelding dat het de software is die beoordeeld wordt en niet gebruikers zelf (Nielsen, 1993, pp. 188-189). Verder werden gebruikers, volgens de think aloud-methode, aangemoedigd om opmerkingen en feedback, tijdens de test, de vrije loop te geven.
Tenslotte werden de gebruikers geïnformeerd over de toegepaste log-technieken (cf. audio) en werden ze ook gerustgesteld omtrent de vertrouwelijkheid van de verzamelde gegevens (Rubin & Chisnell, 2008, pp. 151). Daarbij werden de gebruikers gewezen op hun veronderstelde bereidwilligheid om afstand te doen van hun intellectuele rechten die verband kunnen houden met de input om de software te verbeteren. 36
Bij de introductie werd een checklist opgesteld ter begeleiding van de “evaluator” in de bespreking van de aan te snijden thema’s.
5.2.3
Uitvoeringsfase van de test
Voor de test werd een pretest vragenlijst afgenomen (Bijlage 26). De pretest vragenlijst bestaat uit vragen betreffende geslacht, leeftijd, hoogst behaald diploma, ervaring met statistiek, ervaring met statistische software en het aantal uur dat met het Drobots softwareprogramma geoefend werd. Deze pretest vragenlijst strekte er toe achtergrondinformatie te verzamelen over de deelnemers (Rubin & Chisnell, 2008, pp. 174-177). Tijdens de test is het als “evaluator” belangrijk om geen persoonlijke indrukken te uiten of hulp te bieden in het uitvoeren van taken. De rol en interactie van de “evaluator” moet zoveel mogelijk gereduceerd worden tijdens de test, teneinde de objectiviteit van de geobserveerde prestaties en performantie data van gebruikers te vrijwaren (Nielsen, 1993, pp. 90). Daarom hebben wij gebruikers hier op voorbereid door voor de test te vermelden dat geen hulp zal worden geboden en interactie beperkt zou zijn.
De gebruikers werden geobserveerd en hun acties gelogd. De uitvoering van de test zelf nam ongeveer één uur in beslag. De kwantitatieve performantiedata werden verzameld en dit op grond van de vijf onderscheiden dimensies van het usabilitymodel van Quesenbery. Wij hebben het genoegen gehad respons te krijgen op de toegepaste think aloud methode zoals gevraagd aan de participanten. Op die manier werd kwalitatieve informatie verzameld die de geleverde performantie van de respondenten verklaart. De uitvoering van introductieles en observatietesten nam plaats van 14 november tot en met 18 december 2011.
5.2.4. Debriefingfase In deze fase werd een posttest vragenlijst voorgelegd aan gebruikers ter verzameling van preference data (cf. Subjective Satisfaction) (Bijlage 27, 28). Het voordeel van een debriefingfase is dat gebruikers de mogelijkheid krijgen opmerkingen te formuleren over het verloop van de test. Daarbij kunnen onduidelijkheden of moeilijk te interpreteren taakscenario’s worden geoptimaliseerd (Nielsen, 1993, pp. 191; Rubin & Chisnell, 2008, pp. 199).
37
5.3.
Data en toegepaste dataverzamelingsmethodes
In dit deel bespreken we de verschillende soorten verzamelde data en de methoden die werden toegepast om deze data te verzamelen. Daarbij kan een indeling gemaakt worden van kwantitatieve performantiedata, kwantitatieve preference data en kwalitatieve data. Deze data werd verzameld aan de hand van een pretest vragenlijst, posttestvragenlijst, de think aloud-methode en een observatietest (Bijlage 26, 27, 28).
5.3.1
Kwantitatieve data
De kwantitatieve data werd in dit onderzoek verzameld volgens de vijf onderscheiden dimensies van usability door Quesenbery (2008, pp. 75-94): learnability, effectiveness, efficiency, error tolerance en subjective satisfaction. De dimensie subjectieve satisfactie wordt gemeten aan de hand van “kwantitatieve preference data”, verzameld via vragenlijsten (Bijlage 27, 28). De overige vier dimensies worden gemeten met behulp van “kwantitatieve performance data”, door observatie van gebruikers die enkele taken uitvoeren met de software (Rubin & Chisnell, 2008, pp. 88-91).
De combinatie van deze voorkeurbevragingen met de performantiedata bekomen door het uitvoeren van usability observatie test geeft een grotere betrouwbaarheid inzake de interpretatie van resultaten. Tijdens de analyse van performantie- en preferentiedata kunnen patronen vastgesteld worden. Een patroon in resultaten kan bijvoorbeeld waargenomen worden wanneer een groot deel van gebruikers een bepaalde taak of actie verkeerd uitvoert. Als patronen in performantie en voorkeursdata overeenkomen kunnen met meer zekerheid en betrouwbaarheid uitspraken gedaan worden over bepaalde gedetecteerde usability-problemen (Rubin & Chisnell, 2008, pp. 246-259). ·
Kwantitatieve performantiedata
De performantiedata werd bij de observatie verzameld door middel van een op voorhand voorbereide en gestructureerde takenlijst teneinde de acties van de gebruikers manueel te loggen (Bijlage 25). Met bepaalde codes werden de acties van gebruikers aangegeven.
Wij zullen hierna uiteenzetten welke performantiemaatstaven gebruikt zijn om elke dimensie te meten. Verschillende performantie meetmaten, beschreven door verschillende auteurs, werden gebruikt (Jeng, 2005; Rubin & Chisnell, 1993, Ebling & John, 2000; Quesenbery, 2008; ISO 9241-11, 1998; Nielsen, 1993).
38
Effectiviteit Deze dimensie werd gemeten aan de hand van het gemiddelde percentage van gebruikers die slaagden in het uitvoeren van een taak, berekend op het aantal respondenten die slaagden in het uitvoeren van de taak tegenover het totaal aantal gebruikers die de taak uitvoerden.
Om dit te berekenen hebben we enkel het optreden van de categorie foute acties meegeteld die aanleiding gaven tot het gegeven dat de gebruiker hun taak niet meer correct kon uitvoeren. Dit zijn de foute acties van categorie één (severe) die niet meer te corrigeren zijn (infra). Foute acties van andere categorieën zullen er weliswaar toe geleid hebben dat respondenten meer acties nodig hadden om de taak uit te voeren, maar brengen het realiseren van de taak op zich niet in gevaar. Aangezien effectiviteit gaat over het al dan niet behalen van de doelen/taken werden deze dan ook niet in rekening gebracht.
Efficiëntie Efficiëntie wordt gemeten aan de hand van het percentage van respondenten dat enkel noodzakelijke acties heeft uitgevoerd. Dit werd berekend door vóór de test, de noodzakelijke stappen en acties om een taak uit te voeren, te analyseren. Tijdens de test werd deze taakstructuur dan gebuikt om de verschillende acties van gebruikers op te volgen. Op deze wijze konden de doorlopen stappen van gebruikers vergeleken worden tegenover het kortste aantal acties nodig om een taak uit te voeren.
Bijkomend werd de dimensie efficiëntie gekwantificeerd door het gemiddelde percentage te betrekken van de respondenten die geen fouten maakten van het type (2) en (3). Dit zijn fouten die niet leiden tot het falen van een taak, maar er wel voor zorgen dat er meer acties nodig zijn voor het volbrengen van een taak zoals een foute selectie of het fout ingeven van gegevens(infra). Dit werd berekend door observatie en notitie van het aantal juiste acties en foute acties die werden uitgevoerd doorheen de taken.
Ter controle van bovenstaande meetmaten werd het aantal en gemiddeld percentage van respondenten berekend die erin slaagden de taken te volbrengen zonder hulp. Dit werd berekend aan de hand van het noteren van het aantal keren dat iemand om hulp verzocht bij het uitvoeren van een taak (hulpfrequentie). In zover deze meetmaat resultaten oplevert, die gelijklopend zijn met de twee hierboven beschreven meetmaten, zal er met meer zekerheid, een uitspraak kan gedaan worden over de gebruiksefficiëntie.
Learnability
39
Learnability werd gemeten aan de hand van het slagingspercentage per respondent die de taak succesvol afwerkte, en dit naar verhouding met de tijd die ze geoefend hadden. Respondenten werden daarvoor bevraagd in een pretest vragenlijst om aan te geven hoeveel tijd er besteed werd aan het oefenen met de software (Bijlage 26). Dit gegeven werd dan vergeleken met het resultaat van de respondenten die een totaal foutloos parcours hadden afgelegd in het vervullen van de taken. Op die manier hopen we conclusies te kunnen trekken over hoeveel oefening nodig is om de software aan te leren.
Error tolerance Error tolerance werd gekwantificeerd door het aantal gemaakte fouten die hersteld konden worden tegenover het totaal aantal gemaakte foute acties. Om deze dimensie te meten werden de mogelijke foute acties vanwege gebruikers ingedeeld in categorieën (Rubin & Chisnell, 2008, pp. 260-263; Ebling & John, 2000, pp. 293-294). Tijdens observatie en na analyse werd aangeduid tot welke categorie elk van de gemaakte foute acties behoorde. Door fouten op te delen in categorieën is het mogelijk om de aard en oorzaak ervan verder te onderzoeken en specificeren. Vier categorieën werden onderscheiden. Categorie van fouten 1
Severity level
Opeenvolgende
grote
fouten (sneeuwbaleffect) 2
Fout
ingeven
van
gegevens 3
Verkeerde selecties
4
Interpretatiefouten
"Severe"
"Moderate" "Moderate" "Irritant/Low"
en overige
Figuur 13: Categorie van fouten en ernstgraad
Fouten van de eerste categorie zijn zware fouten die de software “unusable” maken en het gevolg hebben dat de taak niet verder kan worden vervuld of de fout kan worden hersteld. Zij hebben een hoge impact op de usability en Error Tolerance. Daarom worden zij aangeduid als “severe”.
Fouten van categorie 2 en 3 zijn verzamelingen van fouten die verwijzen naar acties die een minder grote impact hebben op het eindresultaat. Gebruikers zullen nog steeds in staat zijn om hun doel te verwezenlijken. Dit soort foute acties zal tot gevolg hebben dat gebruikers meer stappen nodig hebben om de taak te vervolledigen.
40
De laatste categorie van fouten zal gaan over foute interpretaties omtrent de interface of resultaten van een uitgevoerde analyse met Drobots. ·
Kwantitative preference data
Via kwantitatieve voorkeursdata wordt informatie verzameld die een beeld geeft van de subjectieve tevredenheid en de acceptatie van Drobots. De dimensie subjectieve satisfactie kan dan worden gemeten aan de hand van een vragenlijst (Bijlage 27, 28).
In dit onderzoek werd gebruik gemaakt van een vragenlijst met hoofdzakelijk vijfpunt Likertschalen (cf. gesloten vragen) en bijkomend enkele half open vragen. Bij half open vragen kan dieper worden ingegaan op enkele antwoorden (Rubin & Chisnell, 2008, pp. 192-199).
De vragenlijst die de vijfde dimensie meet van het usability-evaluatiemodel van Quesenbery, “subjectieve satisfactie”, is gebaseerd op enkele onderzochte facetten en vragen uit de literatuur (Jeng, 2005, pp. 102, 107-109;Nielsen, 1993, p. 209-213; Rubin & Chisnell, 2008, p. 90). Daarbij werd de tevredenheid met het gebruik gemeten aan de hand van vijf facetten.
De vijf onderscheiden facetten zijn Ease of Use, Organization of functions, Labelling, Error correction and Visual attractiveness. Voor elk van deze facetten werden enkele vragen opgesteld die beantwoord werden aan de hand van een vijf-punt Likertschaal. Elk facet werd op die manier gekwantificeerd, waardoor een conclusie kan getrokken worden betreffende de algemene subjectieve satisfactie.
Figuur 14: Toegepast meetmodel voor subjectieve satisfactie gebaseerd op Jeng (2005, p. 102) Het facet “ease of use” werd gemeten aan de hand van enkele vragen waarvan gebruikers de gebruiksvriendelijkheid moeten kwantificeren van enkele functies, binnen de Drobotsapplicatie, op een vijf-punt Likertschaal. 41
Met het facet “organisation of information” werd gevraagd aan respondenten om hun voorkeur te verduidelijken ten aanzien van de plaats en beschikbaarheid van informatie zoals menu’s, iconen, helpmogelijkheden, functies of andere elementen van interface die een efficiënte navigatie doorheen de applicatie toelaten. Met “labelling” werden de voorkeuren verzameld betreffende de duidelijkheid van de iconen, menu’s en functies voor gebruikers. Daarbij werd dan vooral gecontroleerd of het label van een functie voldoet aan wat de gebruiker denkt waar de functie voor gebruikt moet worden. Mogelijk kan hierbij een label of naam van een functie verkeerd worden geïnterpreteerd door de gebruiker. De vragen over “visual attractiveness“ handelen vooral over de visuele en esthetische aspecten van de Drobotsinterface. Er werd gevraagd de Drobotsapplicatie te scoren onder meer naar kleur en lay-out.
Tot slot vroegen we aan gebruikers wat hun ervaring was over de mate waarin de ingevoerde gegevens gemakkelijk te corrigeren zijn. Het invoeren van data in Drobots vormt een belangrijk deel van de functionaliteit van deze software. Daarbij moet niet enkel het ingeven van gegevens gemakkelijk te verrichten zijn, maar tevens het corrigeren ervan. Dit facet betreft de “error correction”. Aan de hand van deze vijf facetten werd een algemene score bekomen met betrekking tot de subjectieve satisfactie van Drobots.
5.3.2. Kwalitatieve data Bijkomend aan deze kwantitatieve verzamelde data in verband met voorkeuren en prestaties van gebruikers werd ook de kwalitatieve informatie verzameld. Na analyse, kan dan de goede of slechte performantie van een onderdeel van de software verklaard worden (Nielsen, Clemmensen, & Yssing, 2002; Rubin & Chisnell, 2008, pp. 52-55, pp. 88-90).
Zoals eerder gemeld werd de verzameling van kwalitatieve data verwezenlijkt door gebruikers tijdens de test luidop te laten nadenken en opmerkingen en suggesties te geven. Deze opmerkingen en suggesties werden genoteerd en opgenomen aan de hand van audio-opnames. Deze feedback over de foute acties van gebruikers maakt het mogelijk om de oorzaak van de waargenomen usabilityproblemen te verduidelijken (Dix et al., 2004, p. 344).
In verband met het luidop laten nadenken van gebruikers kunnen verschillende methodes worden gebruikt zoals de “co-discovery method”, “coaching method”, “question-asking method” en de “think 42
aloud-methode” (Nielsen, 1993, pp. 195-199). Deze technieken zijn zeer waardevol in de studie naar het waarom van een usability-probleem. We lichten deze methodes kort toe. In toepassing van de “co-discovery method” worden gebruikers, net zoals in andere think aloudmethodes, gevraagd om zoveel mogelijk luidop na te denken en uitleg te geven bij hun uitgevoerde acties. Deze methode onderscheidt zich van andere, omdat niet één respondent, maar wel twee of meerdere gebruikers samen zullen werken en gevraagd worden om een bepaald gemeenschappelijk doel (taak) uit te voeren en te vervolledigen. Hierbij dienen ze elkaar te helpen en te communiceren. Deze methode wordt dan vooral gebruikt om software te testen waarvan het toekomstige gebruik zal liggen in teamverband (Gamberini, L. & Valentini, E.,2003, p. 119). In geval van de “coaching method” zullen gebruikers eveneens gevraagd worden luidop na te denken. Wat deze methode van andere onderscheidt is dat de “evaluator” zich niet afzijdig houdt van de particpant, maar net een intensieve interactie aangaat. De “evaluator” neemt de rol in van een coach die de respondent helpt in het vervullen van zijn of haar taak (Nielsen, 1993, pp. 196-197). De “question-asking method” is een specifieke vorm van luidop nadenken tijdens uitvoeren van taken. In plaats van de respondent vrijuit luidop te laten nadenken zal de “evaluator” systematisch feedback vragen en op een directe wijze de gebruiker bevragen betreffende motivaties van bepaalde acties (Norlin & Winters, 2002, p.4). Wij hebben gekozen voor de “concurrent think-aloud method” waarbij wij één gebruiker luidop laten nadenken tijdens het uitvoeren van de taken. Daarbij houdt de “evaluator” zich afzijdig van interactie en zal de gebruiker zo weinig mogelijk worden geholpen. Dit geeft een zicht op percepties en verwachtingen van de gebruiker over de plaats van een functie of bepaalde opeenvolgende uit te voeren acties om een taak op te lossen. Daardoor worden misverstanden en frustraties gedetecteerd. Discrepantie tussen hoe gebruikers denken de software te gebruiken en hoe de software feitelijk dient te worden gebruikt kunnen usability-problemen blootleggen (Van Den Haak, De Jong, & Schellens, 2003, pp. 339-344, Nielsen , 1993, pp. 195-196).
Als besluit kunnen we stellen dat de keuze voor deze laatst genoemde methode voor de hand ligt. De co-discovery method is gericht op software usability-evaluatie in het kader van teamverband en vandaar
niet
passend
met
de
gebruikscontext
van
Drobots.
De coaching method en question-asking method zijn niet verenigbaar met het verzamelen van kwantitatieve performantie data. De nadruk op kwalitatieve data beïnvloedt de objectieve verzameling van performantiedata door een te informeel interactieproces tussen deelnemer en “evaluator”. De “concurrent think-aloud methode” is dan de enige kwalitatieve verzamelingmethode die enigszins 43
verenigbaar is met een observatietest waarin performantiedata verzameld wordt. Door aangepaste technieken kan de objectiviteit van kwantitatieve dataverzameling tijdens de observatie gewaarborgd worden en kunnen oorzaken van slechte prestaties toch worden geïdentificeerd. 5.4
Gebruikers en Sample
Wij hebben besloten in ons onderzoek om gebruik te maken van een sample van tien participanten. Daarin hebben echter slechts acht van de respondenten het volledige proces van de usability test doorlopen daar twee participanten na de introductie hebben afgehaakt. We dienen hier te verwijzen naar een intensieve karakter van de test en invloed daarvan op de bereidheid bij representatieve respondenten om te participeren en vol te houden om het volledige onderzoeksproces te doorlopen.
Van belang is ook dat de uitvoering van de taakscenario’s in de test, gebeurt door representatieve eindgebruikers. Participanten die betrokken worden in de “usability test” zullen gemeenschappelijke kenmerken moeten hebben ten aanzien van de doelgroep waar de software voor bedoeld is.
Uit een gesprek met de CEO van Drobots, Dhr. Gino Verleye, hebben wij begrepen dat Drobots vooral mikt op eindgebruikers die binnen de publieke of private sector statistische analyse en verwerking aanwenden in het kader van hun studie of beroepsactiviteit. Vaak zullen deze doelgroepen gebruik maken van reeds bestaande, maar complexe software programma’s.
De doelgroep heeft een tamelijk goede kennis van statistiek en reeds veel ervaring met statistische verwerkingssoftware. Hierbij hebben ze om efficiënt te werken nood aan een software die gemakkelijk is in gebruik en waarmee snel resultaten kunnen bekomen worden.
Uit een analyse van voornoemd gesprek zijn wij tot het besluit gekomen een klein sample gebruikers van tien (acht) personen samen te stellen. Daarvoor hebben wij gekozen voor een groep participanten die gemeenschappelijke eigenschappen met de doelgroep hebben, namelijk goede kennis van statistiek en ervaring in gebruik van statistische verwerkingssoftware.
Deze sample van participanten bestaat grotendeels uit universiteitsstudenten die in hun opleiding ervaring en kennis van statistiek hebben verworven. Het gaat om zes participanten, studenten aan de Universiteit van Gent en de Vrije Universiteit van Brussel (VUB)die Communicatieswetenschappen of Psychologie studeren. Verder hebben we één medewerker van de VUB uitgenodigd die regelmatig statistische analyses uitvoert in het kader van gesubsidieerd overheidsonderzoek. Tenslotte hebben we eveneens een persoon uit de privésector (verzekeringsmaatschappij) uitgenodigd die als actuaris vaak statistische analyses maakt.
44
5.5
Beperkingen
5.5.1
De invloed van de think aloud methode op performantie metingen
Een welbekend nadeel van de “think aloud” methode is dat de denktijd wordt verlengd doordat gebruikers twee opdrachten tegelijk moeten uitvoeren (Van Den Haak, De Jong & Schellens, 2003, p. 349). Zij moeten gelijktijdig een taak met de software uitvoeren en tegelijk uitleg geven over de acties alsook de wijze waarop ze denken de functies te gebruiken. Dit heeft een negatieve invloed op de performantie van gebruikers waarmee zij taken uitvoeren. De prestaties van gebruikers en de verzamelde performantiedata zijn - door het luidop nadenken - mogelijk gedeeltelijk vertekend. Daarom is het bij deze methode minder aangewezen zijn om de gebruikelijke tijdsmetingen van performantie te verrichten.
Een alternatief is het optimaal gebruik maken van andere performantiemaatstaven dan tijd, zoals bijvoorbeeld het minimum aantal acties nodig om een taak uit te voeren tegenover de uitgevoerde acties van gebruikers. Deze gehanteeerde performantiemeetstaaf kan ook usability-problemen aan het licht brengen (Van Den Haak, De Jong & Schellens, 2003, p. 341).
Er kan ook geopteerd worden om in plaats van tijdens de test, na de test participanten verder te bevragen over de geobserveerde moeilijkheden met het gebruik van de software. Door gebruik van video-opnames of vooropgestelde takenlijsten met takenstructuur, waar de evaluator op aanduidt welke de moeilijkheden en opmerkingen van de participanten waren, kan kwalitatieve dataverzameling tijdens de test gereduceerd worden en plaatsnemen na de test (Rubin & Chisnell, 2008, pp. 235-236; Nielsen, 1993, p. 208; Van Den Haak, De Jong & Schellens, 2003, p. 341).
Om de beïnvloeding van de performantie data door verzameling van kwalitatieve data te beperken hebben wij geopteerd voor de laatste twee genoemde wijzen van dataverzameling. Er werd zodoende geen rekening gehouden met de tijd nodig om een taak te vervullen en er volgde een uitgebreide bespreking van de ondervonden moeilijkheden na de gedane test. Daarbij kan een verlies aan informatie plaatsgevonden hebben, maar het betrouwbaarheidsniveau van de resultaten werd hiermee niet aangetast.
5.5.2
Grootte van het sample
45
Omwille van het intensief karakter van usability testing is kan slechts een klein aantal gebruikers worden betrokken. Zelf hadden wij vooropgesteld een sample te gebruiken met tien participanten. Twee deelnemers hebben op het laatste moment afgehaakt zodat het aantal, ten node, terug gebracht werd tot acht respondenten.
Door verschillende auteurs werd aan de hand van empirisch onderzoek bevestigd dat een sample van vijf gebruikers reeds 80% van de usability-problemen in een software kan blootleggen (Virzi, 1992, p. 468; Nielsen, 1993, pp. 17-20; Myers, Corey & Badgett, 2012, pp. 148-150). Gebruikers zouden daarbij vaak dezelfde problemen aanmerken waardoor vrij snel een aantal duidelijk patronen gevonden worden in hun prestaties.
Daar tegen over staat dat andere auteurs, na het voeren van empirisch onderzoek, tot resultaten komen waarbij vijf respondenten als een te klein aantal wordt beschouwd om tot stabiele usability-resultaten te komen. Over het optimaal aantal nodige deelnemers voor een usability test zijn de meningen van de auteurs uiteenlopend en verdeeld, maar het aantal kan worden vastgesteld op zes tot twaalf deelnemers (Dumas & Redish, 1999, pp. 128-129; Faulker, 2003, pp. 380-382, Rubin & Chisnell, 2008, p. 29).
Spijts de kleine sample gebruikers betrokken in dit onderzoek, kan gesteld worden dat acht respondenten reeds een betrouwbare basis vormt voor het uitvoeren van een usability-test. Bijkomend kon door de combinatie van verschillende data (performantiedata, preferentiedata en kwalitatieve data) verzameld aan de hand van een observatietest en de think aloud-methode, de vastgestelde patronen in kwantitatieve
performantie-
en
preferentiedata
worden
gevalideerd.
Deze
gecombineerde
informatieverzameling liet ons toe met grote betrouwbaarheid conclusies en uitspraken te doen over waargenomen prestaties van de deelnemers.
5.5.3
Omgeving van observatietest
Usability testing in de vorm van observatietesten met gebruikers kan in een laboratorium of te velde gebeuren (Tullis et al., 2002, pp. 1-8). De testsituatie voor participanten zal, hoe dan ook, altijd als een kunstmatige situatie worden ervaren. Hoewel wij de testomgeving en context zo natuurlijk mogelijk hebben trachten te houden, door de deelnemers in hun normale werkomgeving te observeren en geen gebruik te maken van video-opnames, moet worden opgemerkt dat het uitvoeren van de test een onvermijdelijke invloed heeft op het gedrag en prestaties van de betrokken respondenten (Rubin & Chesnil, 2008, p. 26).
46
5.5.4
Exhaustief testen
Het testen en evalueren van een de volledige software is moeilijk realiseerbaar en niet wenselijk. Exhaustief testen brengt een grote meerkost in tijd en in geld met zich mee. Er zullen afwegingen dienen gemaakt te worden tussen dekkingsgraad van de usability-test enerzijds en de tijd en het budget dat voor handen is anderzijds. Wij hebben daarom in dit onderzoek onze aandacht vooral toegespitst op het testen van de belangrijkste functies van Drobots (Graham, Van Veenendaal, Evans & Black, 2008, pp. 10-12).
47
Hoofdstuk 6: Resultaten
De bespreking van de resultaten gebeurt in twee delen. Deze indeling is niet willekeurig, maar volgt de logische workflow van de Drobotsapplicatie. Vooreerst worden de verzamelde statistisch data ingevoerd in Drobots. Nadien kunnen aan de hand van deze ingevoerde data, statistische analyses uitgevoerd worden. Survey Setup verwijst naar het eerstgenoemde proces. De analyse van de data wordt “Survey Analyzer” genoemd. Beide processen hebben andere kenmerken en verschillen van aard, vandaar de opsplitsing.
We zullen hier de kwantitatieve data bespreken, waarin usability-problemen kunnen geïdentificeerd worden. Aan de hand van kwalitatieve data kunnen we het probleem verder situeren, afbakenen en verklaren.
Om de resultaten betreffende kwantitatieve performantie- en preferentiedata te beoordelen zullen we een 70%-regel gebruiken. Dit betekent dat een taak of bepaald deel van het Drobotsproces als problematisch zal worden gezien wanneer deze onder de 70% scoort. De 70%-regel is arbitrair en voor het uitvoeren van de tests vastgelegd. Deze is het gevolg van een berekende schatting van de nodige usability-prestaties van Drobots en is vastgelegd aan de hand van een bespreking tussen het testteam en het managament (bussiness requirement).
Verder zullen in elk van de delen de dimensies en hun score besproken worden om dan dieper in te gaan op problematisch geïdentificeerde taken en delen die de score van elke dimensie medebepaald. Deze verduidelijken we en vullen we verder aan door kwalitatieve informatie betreffende het waarom van deze fouten. Op die manier neemt een validatie plaats van de Drobotsapplicatie aan de hand van kwantitatieve data en kan het waarom van de daarin ontdekte usability “hot-spots” worden verduidelijkt dankzij kwalitatieve informatie.
6.1
“Survey Setup”
Het eerste proces, “Survey Setup”, wordt aangewend voor de invoer van de data, de codes en het model. In ons testscenario bestaat dit proces uit 12 verschillende taken. De bespreking van de dimensie en hun score volgen hier verder.
48
Tasks: Survey Setup 1
Website en toegangspoort naar de Drobotsapplicatie vinden
2
Ingeven van projectnaam
3
Variabelen ingeven
4
Waarden voor variabelen ingeven
5
Corrigeer fout in labels
6
Corrigeer foute waarden (antwoordcategorieën)
7
Facetten aanmaken + aan facetten binden
8
Concepten aanmaken en aan facetten binden
9
Concepten binden aan topic en aanmaken van topic
10 Controleren van "Model" 11 Corrigeren van fout ingegeven concepten, facetten en links ertussen 12 Invoeren van een surveynaam en selecteren van het databestand in kwestie Tabel 1: Tasks: Survey Setup
6.1.1
Effectiviteit
Effectiviteit is berekend op het percentage die slagen in het uitvoeren van hun taken. % participanten die taak correct Taken 1 Website en toegangspoort naar de Drobotsapplicatie vinden
uitvoeren 62,50%
2 Ingeven van projectnaam
100%
3 Variabelen ingeven
100%
4 Waarden voor variabelen ingeven
100%
5 Corrigeer fout in labels 6 corrigeer foute waarden (antwoordcategorien) 7 facetten aanmaken + aan facetten binden 8 concepten aanmaken en aan facetten binden 9 concepten binden aan topic en aanmaken van topic 10 aanklikken van "Model" om te controleren 11 Corrigeren van fout ingegeven 12 Invoeren van een surveynaam en
100% 100% 100% 100% 100% 100% 100% 100%
Tabel 2: Percentage participanten die de taak correct uitvoeren
49
Op het vlak van effectiviteit kunnen we één cruciale taak identificeren die een problematische score aangeeft. In slechts 1/12 taken (8.3%) zijn er 5/8 participanten (62.5%) die hun taak hebben kunnen uitvoeren. Dit is de “logintaak”. We stellen vast dat de score net onder de vooropgestelde 70% slaginspercentage valt. Deze score kan echter als een problematische score worden aangerekend, te meer deze taak één van de belangrijkste stappen is in de workflow van de Drobotsapplicatie (toegang tot functionaliteit). Potentiële gebruikers zouden immers de site kunnen bezoeken zonder toegang te vinden.
De andere elf taken (91.5%) werden door de acht respondenten (100%) correct volbracht. Dit geeft een algemene, gemiddeld slagingspercentage voor de effectiviteit van “Survey Setup” van 97%, wat volgens de vooropgestelde 70%-regel een zeer goede en aanvaardbare score is.
Deze resultaten werden ondersteund door de verzamelde kwalitatieve data waar 5/8 participanten (62.5%) vermeldden dat de login-applicatie te moeilijk terug te vinden is op de Drobots-startpagina. De moeilijkheden met het vinden van de “Login-functie” wordt, volgens analyse van de feedback van de respondenten, veroorzaakt door de te kleine afbeelding ervan op de site. Ook de onopvallende kleur en onduidelijke label van de deze functie is een steeds terugkerende kritiek.
Figuur 15: Screenshot Drobots: The most powerful survey – Analysis software
6.1.2. Efficiëntie
Efficiëntie moet worden gezien als de relatie tussen gebruikte middelen en behaalde resultaten. In het onderzoek betreffende Drobots werd het aantal acties waarmee respondenten een taak uitvoeren als
50
effeciëntiemeetmaat gebruikt. Het gemiddelde percentage respondenten dat daarbij geen onnodige acties uitvoerde bedroeg 69%. Dit betekent dat de algemene gebruiksefficiëntie, volgens de vooropgestelde 70%-regel, niet als uitgesproken problematisch beschouwen is. Doch enkele kleine aanpassingen kunnen deze score verbeteren.
% van participanten die
enkel
nodige
acties uitvoeren om Taken
taak te vervolledigen
1 Website en toegangspoort naar de Drobotsapplicatie vinden
100%
2 Ingeven van projectnaam
87,50%
3 Variabelen ingeven
25,00%
4 Waarden voor variabelen ingeven
62,50%
5 Corrigeer fout in labels
100%
6 corrigeer foute waarden (antwoordcategorieën)
25,00%
7 facetten aanmaken + aan facetten binden
75,00%
8 concepten aanmaken en aan facetten binden
87,50%
9 concepten binden aan topic en aanmaken van topic
87,50%
10 aanklikken van "Model" om te controleren
87,50%
11 Corrigeren van fout ingegeven concepten, facetten en links ertussen
50%
12 Invoeren van een surveynaam en selecteren van het databestand in kwestie
37,50%
Tabel 3: Efficiëntie Survey Setup: Percentage van participanten die enkele nodige acties uitvoeren om de taak te vervolledigen
In vijf van de twaalf taken (42%) werden er problematische scores vastgesteld (70%-regel) betreffende het uitvoeren van de taak zonder onnodige acties. Deze zijn ”the input of variables”, “the input of values”, “the correction of the model”,-“the correction of values” en “uploading a dataset”.
Daarbij komend werden enkele andere meetmaten gebruikt die deze scores valideren op haar waarheidsgetrouwheid. Deze zijn enerzijds de gevraagde hulpfrequentie en anderzijds de gemaakte fouten van categorie twee en drie. In deze controlemeetmaten werden gelijkaardige gemiddelde scores in resultaten vastgesteld voor gevraagde hulpfrequentie (54%) en foute acties van categorie twee en drie (68%).
51
Eveneens werden gelijkaardige patronen van problematische taken vastgesteld in deze drie meetmaten. De verschillende meetmaten duiden met andere woorden op dezelfde slecht scorende acties en taken. Dit laatste dient genuanceerd te worden met betrekking tot hulpfrequentie. Een specifieke reeks taken die zorgen voor de ingave van het datamodel (taak 7 tot en met 9) worden gekenmerkt door een hoge hulpfrequentie, hoewel geen fouten of extra acties werden gemaakt bij het ingeven van het model. % van participanten die enkel foute acties Taken hebben gemaakt van categorie (2) en (3) 1 Website en toegangspoort naar de Drobotsapplicatie vinden 100,00% 2 Ingeven van projectnaam 87,50% 3 Variabelen ingeven 37,50% 4 Waarden voor variabelen ingeven 25% 5 Corrigeer fout in labels 100% 6 corrigeer foute waarden (antwoordcategorien) 37,50% 7 facetten aanmaken + aan facetten binden 87,50% 8 concepten aanmaken en aan facetten binden 87,50% 9 concepten binden aan topic en aanmaken van topic 87,50% 10 aanklikken van "Model" om te controleren 75,00% 11 Corrigeren van fout ingegeven concepten, facetten en links ertussen 50% 12 Invoeren van een surveynaam en selecteren van het databestand in kwestie 50% Tabel 4: Percentage van participanten die enkel foute acties hebben gemaakt van categorie (2) en (3)
% van participanten die geen hulp vroegen Taken 1 Website en toegangspoort naar de Drobotsapplicatie vinden 2 Ingeven van projectnaam 3 Variabelen ingeven 4 Waarden voor variabelen ingeven 5 Corrigeer fout in labels 6 corrigeer foute waarden (antwoordcategorien) 7 facetten aanmaken + aan facetten binden 8 concepten aanmaken en aan facetten binden 9 concepten binden aan topic en aanmaken van topic 10 aanklikken van "Model" om te controleren
Totaal hulpfrequentie
62,50% 100% 37,50% 37,50% 75% 37,50% 25% 50% 50% 75%
11 Corrigeren van fout ingegeven concepten, facetten en links ertussen 12 Invoeren van een surveynaam en selecteren van het databestand in kwestie
0 5 5 3 5 12 5 9 2
50%
5
37,50%
5
Tabel 5: Percentage van participanten die geen hulp vroegen
We gaan dieper in op de taken waar respondenten moeilijkheden mee hadden inzonderlijk gebruiksefficiëntie. Aan de hand van de verzamelde kwalitatieve data trachten we deze te verklaren.
52
3
·
Ingave van variabelen
Het invoeren van variabelen blijkt een problematisch proces te vormen voor onze participanten. Slechts 2/8 respondenten (25%) hebben deze taak kunnen vervolledigen zonder onnodige acties uit te voeren. Deze extra acties zijn grotendeels (72% van de foute acties) het gevolg van het verkeerd ingeven van de naam van variabelen.
Uit verzamelde kwalitatieve feedback kan vastgesteld worden dat de belangrijkste reden voor deze fouten het verlies is van het overzicht waaruit blijkt welke variabelen reeds wel en niet zijn ingevuld. Respondenten vergaten doorheen het ingeven van een twintigtal variabelen vaak welke de vorige variabele men reeds ingevoerd hadden in het systeem. Vaak werd dezelfde variabele twee keer ingevoerd of een variabele werd vergeten. Participanten hadden kennelijk nood aan een soort overzicht omtrent de reeds ingevoerde variabelen zijn.
We verduidelijken dit aan de hand van enkele screenshots.
Figuur 16a: Screenshot Drobots: Lijst van de ingegeven variabelen
In dit voorbeeld duidt het rode kader op de lijst van de reeds eerder ingevoerde variabelen door de participant. Om een nieuwe variabele aan te maken dient men hier op “new” te klikken, waarna de volgende interface te zien is.
53
Figuur 16b: Screenshot Drobots: Ingave van nieuwe variabele
In dit menu verdwijnt de lijst van reeds ingegeven variabelen. Wellicht vormt dat geen probleem bij het ingeven van een kleine dataset met weinig variabelen. We hebben geconstateerd dat het niet vanzelfsprekend is als gebruikers een meer omvangrijke (volwaardige) dataset dienen in te voeren. ·
Ingave van waarden
Het invoeren van waarden (cf. taak 4) leverde eveneens enkele problematische scores op. Slechts 5/8 respondenten (62,5%) kon deze opdracht vervullen zonder onnodige acties. 69% van de gemaakte fouten namen plaats bij het ingeven van een naam voor de antwoordcategorie en het ingeven van de code van een waarde. Gebruikers dachten dat het de bedoeling was om de naam van de waarde in te geven bij “Answer Category Code”, terwijl hier de naam dient ingegeven te worden van de antwoordcategorie (supra). Ook bij “Answer Value” kunnen we de oorzaak van de meeste foute ingaven terugbrengen tot de misvatting van gebruikers waarbij, in plaats van de naam van de waarde, het ordinaal nummer voor de waarde zelf werd ingevuld. Dit terwijl het ordinaal nummer reeds aangegeven stond.
54
Figuur 17: Screenshot Drobots: Ingave van naam van antwoordcategorie
Uit verdere analyse van feedback vanwege gebruikers werd vastgesteld dat dit te wijten zou zijn aan de onduidelijke labelling van invulvelden voor “Answer categorie name” en “Answer value”. Feedback van gebruikers maakte duidelijk dat de labels van de invulvelden “Answer Category Code en “Answer Value voor gebruikers niet veel betekenis en daardoor verkeerd werden geïnterpreteerd. Het ontbreken van een vertaling in het Nederlands zou daarbij eveneens van tel kunnen zijn. ·
Correctie van waarden
Tijdens het invoeren van variabelen en waarden hebben we onze respondenten eveneens bewust een foute waarde en variabele laten ingeven. Deze werden vanzelfsprekend niet meegerekend als foute acties, maar hadden als doel de gebruikers te verplichten enkele verkeerde inputvariabelen en waarden te corrigeren, na het ingeven ervan. Ook de correctie van waarden en variabelen dient immers gemakkelijk in gebruik te zijn.
De correctie van verkeerd ingegeven variabelen kon vlot en zonder fouten worden uitgevoerd door onze deelnemers. De correctie van waarden verliep daarentegen minder vlot. Slechts twee van de acht van de respondenten (25%) konden, zonder onnodige acties, de taak vervullen waarin correcties in waarden dienen te gebeuren (supra). Daarbij werd het model gecontroleerd aan de hand van een overzicht van alle gelinkte vragen met bijhorende facetten en concepten. Deze problematische score is het gevolg van een misvatting bij deelnemers, waarbij op de 55
variabele werd geklikt om de waarden van een antwoordcategorie aan te passen in plaats van rechtstreeks op de antwoordcategorie zelf. Hierdoor werden bijkomende en onnodige acties geregistreerd. Het aanpassen van variabelen omvat volgende acties:
Figuur 18a: Screenshot Drobots: Controleren van variabelen en aanpassen
Figuur 18b: Screenshot Drobots: Verbeteren
Het aanpassen van waarden verloopt in volgende stappen:
56
Figuur 19a: Screenshot Drobots: Selecteren van antwoordcategorie
Figuur 19b: Screenshot Drobots: Aanpassen selecteren
57
Figuur 19c: Screenshot Drobots: Verbeteren
Uit analyse van de verzamelde kwalitatieve data werd vastgesteld dat gebruikers zich niet bewust waren dat de antwoordcategorie rechtstreeks kon worden aangepast. Vandaar werd meestal eerst de variabele geselecteerd om dan de bijhorende antwoordcategorie aan te passen. Daarom zal op een bepaalde manier duidelijk moeten worden gemaakt dat zowel de variabele als antwoordcategorie rechtstreeks kunnen worden aangepast. ·
Ingeven van het datamodel
Zowel de meetmaat die enkel rekening houdt met foute acties van categorie twee en drie, als de meetmaat gebaseerd op onnodige acties tonen aan dat er weinig verlies was van efficiëntie in het ingeven van het datamodel. We dienen echter dienen we op te merken dat er een zeer hoge hulpfrequentie werd waargenomen bij het uitvoeren van deze taak. Specifiek nam 66% van de hulpfrequentie plaats in de acties nodig om een facet aan te maken en de vragen te linken aan de facetten.
58
Figuur 20a: Screenshot Drobots:Question to Facet
Figuur 20b: Screenshot Drobots: Facet to Concept
De hulpfrequentie daalde echter opvallend nadat de eerste facetten werden aangemaakt en werden gelinkt aan de bijhorende vragen. In het aanmaken van concepten en linken van deze aan facetten werden opvallend minder hulp gevraagd (cf. Taak 7).
59
Taken
Hulpfrequentie
Percentages
7
Facetten aanmaken en aan facetten binden
12
46%
8
Concepten aanmaken en aan facetten binden
5
19%
9
Concepten binden aan topic en aanmaken van topic
9
35%
Tabel 6: Slecht scorende taken op hulpfrequenties
Uit feedbackinformatie van gebruikers hebben we vernomen dat het begin moeilijk leek, maar dat het steeds terugkeren van dezelfde interface voor het ingeven van facetten, ingeven van concepten, ingeven van topic en links daartussen een goede basis vormt om te leren werken met het datamodel. De kennis opgedaan in de vorige interface kon immers telkens opnieuw worden gebruikt. Telkens opnieuw dient men eerst een element aan te maken om nadien te linken aan een abstracter element (bijvoorbeeld een vraag aan, een facet of een facet aan een concept). De daling van de hulpfrequentie zou dan kunnen te maken hebben met de gewenning aan de manier van werken doorheen de werkflow bij het invoeren van een datamodel. Tot slot werd een hoge hulpfrequentie waargenomen bij het aanmaken van een topic en het binden van concepten aan deze topic. Daarbij bleek uit kwalitatieve feedback dat gebruikers geen problemen ervaarden met de wijze waarop een topic dient aangemaakt te worden, maar wel waarom zij dit moesten aanmaken. De respondenten begrepen precieze doelstelling hiervan niet altijd even goed.
Figuur 20c: Screenshot Drobots: Concepts do topic
60
Ondanks het weinig aantal gemaakte fouten wijst de hoge hulpfrequentie bij de genoemde taken er op dat het ingeven van een model als een complexe taak wordt ervaren door gebruikers. Daarom zouden bepaalde begeleidingen dienen voorzien te worden vanuit het programma die de gebruiker helpt in het ingeven van het datamodel. ·
Correctie van het ingegeven datamodel
Ook hier werden bewust enkele fouten ingegeven om nadien te verifiëren in welke mate gebruikers er in slagen om deze te corrigeren. We hebben vastgesteld dat de correctie van het model door vier van de acht deelnemers (50%) uitgevoerd werd met onnodige acties. Uit analyse van onze kwalitatieve data hebben we vastgesteld dat deze extra uitgevoerde acties te wijten zijn aan het feit dat gebruikers de ingeven fout moeilijk konden terugvinden. Eigen aan het datamodel is dat de correctie dient te gebeuren in hetzelfde menu waarin het model wordt ingegeven. De correctie van het model werkt daarbij totaal anders dan de correctie van foutief ingegeven variabelen en waarden. Voor de correctie van variabelen of waarden wordt een overzichtelijke lijst van de ingegeven variabelen en antwoordcategorieën gepresenteerd die gebruikers toelaten rechtstreeks een variabele te selecteren en te verbeteren (cf. supra). Aanpassingen maken gebeurt niet door in de lijst een facet, concept of item te klikken. Wel door op de bovenstaande menu’s te klikken gebruikt om het datamodel in te voeren (“Question to Facet”, “Facet to concept”, “Concept to Topic”).
Figuur 21a: Screenshot Drobots: Aanpassingen maken en overzicht
61
Door bovenaan te klikken op de menu’s krijgen we volgende interface te zien, waarin aanpassingen en verwijderingen kunnen worden gemaakt.
Figuur 21b: Screenshot Drobots: Interface voor aanpassingen en verwijderingen
Uit kwalitatieve data werd ondersteund dat de manier van corrigeren betreffende ingegeven variabelen moeilijker te hanteren is dan het corrigeren van het meetmodel, omwille van de mogelijkheid van het rechtstreeks aanpassen in het overzicht van de ingegeven data. Continuïteit in de correctiemethode zou de gebruikers kunnen helpen fouten in het datamodel gemakkelijker terug te vinden. ·
Uploaden van een dataset
Slechts drie van de acht participanten (37.5%) zijn erin geslaagd om zonder onnodige stappen een databestand up te loaden, alhoewel dit een tamelijk gemakkelijke taak is. Hierbij wordt een naam ingegeven voor het databestand en de dataset (xlsx-bestand) geselecteerd om de data up te loaden.
62
Deze interface krijgen gebruikers te zien wanneer “Data Load” wordt geselecteerd.
Figuur 22a: Screenshot Drobots: Interface voor Data Load
Hier kan het databestand worden geselecteerd en opgeladen. Bijkomend dient “New Survey” worden aangeklikt, waarbij een naam voor de survey dient te worden ingegeven.
Figuur 22b: Screenshot Drobots: Interface New Survey
63
Door op “Submit” te klikken en nadien “Update” wordt de data opgeladen. Zonder het invoeren van de naam in “New Survey” zal de data-upload mislukken, wat in ons onderzoek tot meer nodige acties heeft geleid bij om de data up te loaden. Alle fouten die hier werden gemaakt waren het gevolg van het niet invullen van de “Survey name”, omdat de participanten dit over het hoofd zagen, overbodig vonden of dachten dat ze dit al gedaan hadden in het aanmaken van het project.
6.1.3 Error tolerance Error tolerance geeft de mate weer waarin Drobots de gebruikers toelaat om gemaakte fouten te corrigeren. 95% van de fouten gemaakt door respondenten konden daarbij hersteld en verbeterd worden . De taak met de slechtste Error tolerantiescore is daarbij de login-taak, aangezien deze fouten niet meer konden hersteld worden.
Tasks: Survey Setup Website
en
toegangspoort
naar
Aantal
Aantal
gemaakte
herstelde
Percentages
fouten
fouten
hersteld/totaal
de
1
Drobotsapplicatie vinden
3
0
0%
2
Ingeven van projectnaam
1
1
100%
3
Variabelen ingeven
11
11
100%
4
Waarden voor variabelen ingeven
13
13
100%
5
Corrigeer fout in labels
-
-
-
6
Corrigeer foute waarden (antwoordcategorieën)
7
7
100%
7
Facetten aanmaken + aan facetten binden
3
3
100%
8
Concepten aanmaken en aan facetten binden
1
1
100%
Concepten binden aan topic en aanmaken van 9
topic
1
1
100%
10
Controleren van "Model"
2
2
100%
6
6
100%
8
8
100%
Corrigeren van fout ingegeven concepten, 11
facetten en links ertussen Invoeren van een surveynaam en selecteren van
12
het databestand in kwestie
Tabel 7: Score van error tolerance: survey setup
64
Deze hoge score voor de dimensie Error Tolerance verklaart gedeeltelijk het hoge niveau van dimensie Effectiviteit en lage score van de dimensie Efficiëntie. Doordat fouten konden hersteld worden en niet leidden tot zware fouten (fouten type (2) en (3)) slaagden respondenten erin om een groot deel van de taken te volbrengen (Effectiviteit wordt daarbij berekend op basis van fouten van het type één). Het grote aantal fouten van het type twee en drie heeft gezorgd voor een negatieve invloed op Efficiëntie (Bijlage 1).
6.1.4 Learnability We hebben getracht de Learnability te meten door het aantal uren oefening van een respondent met Drobots in verhouding te zetten met het aantal volbrachte taken zonder het maken van enige fout. We hebben daarbij vooropgesteld dat respondenten die tot 3 uur geoefend hadden met de software een gemiddeld slagingspercentage zouden moeten kunnen halen van 70% of meer. De gemiddelde score zonder fouten voor alle respondenten is daarbij 67%.Dit kan als een goede score worden aanzien voor een software die complexe statistische analyses uitvoert in een compleet nieuwe vorm. De gemakkelijkheid om Drobots aan te leren (cf. Learnability) zou echter wel kunnen verhoogd worden als de problemen, vermeld in de dimensies effectiviteit en efficiëntie, verbeterd en opgelost worden. Vijf respondenten hebben minder dan één uur geoefend en behaalden een gemiddelde slaagscore van 8/12 (66%) zonder fouten uit te voeren. Één respondent oefende een periode van 1 tot 3 uur en voerde daarbij 9/12 (75%) van de taken uit op een correcte manier. Twee respondenten oefenden daarbij meer dan drie uur en haalden een score van 8/12 of 66%.
Hieruit kunnen we afleiden dat 6/8 respondenten minder dan 1uur tot maximum 3 uur nodig hadden om een gemiddeld slagingspercentage te behalen van 68% met betrekking tot taken waar geen enkele fout gemaakt werd. Deze score benadert de 70% die we als evaluatieregel toepassen in dit onderzoek. Aandacht aan en aanpassingen aan bovengenoemde besproken problematische functies en processen zouden deze scores voor “Learnability” echter sterk kunnen optimaliseren.
6.1.5 Subjective Satisfaction Deze dimensie werd gemeten aan de hand van een vragenlijst die de subjectieve satisfactie beoordeelt op basis van vijf onderscheidde facetten: Ease of Use, Organization of functions, Labelling, Error correction and Visual Attractiveness (Bijlage 27, 28). Elk facet werd gemeten aan de hand van verschillende vragen, waarbij de voorkeuren van respondenten op hun beurt gemeten wordt aan de hand van een vijfpunten-Likertschaal. De gemiddelde usability score van het concept “subjective satisfaction” is 78%, wat een goede en aanvaardbare score (cf. 70%-regel). 65
Daarbij scoren alle facetten vrij hoge gemiddelden. Er is één facet dat een iets lagere score aangeeft dan
de
andere
facetten
(6.8/10),
namelijk
Facetten
Gemiddelden scores
Ease of Use
8.2/10
Labelling
7.6/10
Error correction
7.8/10
Visual attractiveness
7.9/10
Organtisation of information
6.8/10
Organtisation
of
information.
Tabel 8: Scores op facetten van subjectieve satisfactie
Als we dieper ingaan op het facet Organisation of information merken we dat respondenten een zeer lage score (2.5/10) hebben gegeven aan de plaats van de login op de startpagina. Dit komt overeen met onze bevindingen uit analyses van de kwantitatieve performantie data en kwalitatieve data (supra). Respondenten hebben moeilijkheden met het vinden van de login applicatie op de startpagina. De plaats van de login-module wordt als weinig opvallend ervaren, vooral in vergelijking met het belang van haar functie (toegang tot de Drobotsapplicatie).
(Q10) De toegang van de Drobots login-applicatie is gemakkelijk terug te vinden op de site
1
helemaal
niet
akkoord
3
2
niet akkoord
3
3
Neutraal
1
4
Akkoord
1
5
helemaal akkoord
0
8
37.50 % 37.50 % 12.50 % 12.50 % 0.00 %
Tabel 9: Q10: Gepercipieerde toegankelijkheid van de Drobots login-applicatie op de site
Tevens wordt een tamelijk lage score vastgesteld in het onderscheid tussen menu’s en submenu’s. Het onderscheid en de duidelijkheid van menu’s en submenu’s scoorde gemiddeld 6.8/10.
66
Naast deze negatieve gescoorde onderdelen (<70%) van de Drobotsapplicatie werden daartegenover ook enkele zeer goede gemiddelde scores vastgesteld (>90).
Volgens respondenten biedt Drobots logische workflow die de software aanbiedt aan gebruikers in het invoeren van data. Deze zijn het ingeven van de naam van het project, het verder labelen van variabelen, benoemen van waarden, het ingeven van facetten, ingeven van concepten en tot slot het uploaden van de dataset om naderhand analyses op uit te voeren. Merk op dat het hier gaat om de workflow en niet de gemakkelijkheid in gebruik van de functionaliteit.
Respondenten bleken, in tegenstelling tot onze bevindingen in performantiedata, een goede score te geven aan de gemakkelijkheid om een bestand up te loaden (9.3/10). Daarbij kunnen we stellen dat, hoewel de efficiëntie werd verlaagd bij het uitvoeren van de taak, dit niet als irriterend werd ervaren.
Concept (1) TEVREDENHEID
Facet
EASEOFUSE
Mean(scale
Question
10)
(Q7) Het selecteren en uploaden van de dataset zelf (excelbestand) verloopt vlot en gemakkelijk
9.3750
Tabel 10: Gemiddelde score voor uploaden databestand (Q7)
(Q7) Het selecteren en uploaden van de dataset zelf (excelbestand) verloopt vlot en gemakkelijk
Scaled 8
(1) helemaal niet akkoord
0 0.00 %
(2) niet akkoord
0 0.00 %
(3) neutraal
0 0.00 %
(4) akkoord
2
(5) akkoord
helemaal
6
25.00 % 75.00 %
Tabel 11: Frequentiescore voor uploaden databestand (Q7)
Hetzelfde bleek het geval te zijn voor het invoeren van variabelen en waarden (7.8/10), evenals correctie van facetten en concepten (8.7/10). Hoewel de merkbare daling van efficiëntie in de
67
observatie van gebruik en objectieve performantiedata, bleken gebruikers zich weinig te ergeren aan het verlies van deze efficiëntie in deze delen van de applicatie. Tot slot werd het “Survey Set up-gedeelte” van Drobots als een visueel aantrekkelijke site gezien. Respondenten gaven een hoge gemiddelde score aan de lay-out (9/10) en professioneel uitzien (8/10) van de Drobotsinterface. 6.2 “Survey Analyzer” Het tweede deel van de Drobotsapplicatie bestaat uit analyses, rapportering en interpreteren op grond van de ingevoerde data en meetmodel. De analyse bestaat uit een aantal menu’s waarvan een selectie dient gemaakt worden. Het klikken op een menu zorgt dat er meteen tabellen en grafieken te zien krijgen die interpretatie mogelijk maken. Opnieuw hebben we twaalf taken opgesteld die gebruikers doorheen de belangrijkste analyses laat navigeren en de resultaten interpreteren.
Tasks: Survey Analyser 1
Vragenlijst opzoeken
2
Meetmodel opzoeken
3
Verdeling total sample nagaan
4
Missing data aanduiden
5
Gemiddeldes opzoeken van alle items
6
Grafische gegeven score opzoeken voor 1 item
7
Kijken met vergrootglas naar leeftijd van zeer ontevredenen van vraag "x"
8
Opzoeken van een kruistabel voor 2 items
9
Ranking van concepten
10 Verander kleur van Ranking-thermometer 11 Impact Diagram van concepten 12 Gebruik van Vergelijkingsanalyses o.b.v. splitvariabele leeftijd
Tabel 12: Taken Survey Analizer
We bespreken hierna opnieuw de dimensie en hun score, waarbij we dieper ingaan op problematisch geïdentificeerde taken voor elke dimensie.
68
6.2.1 Effectiveness Het gedeelte Survey Analyzer heeft, net zoals Survey Setup, een zeer hoge effectiviteitgraad, wat betekent dat gebruikers hun taken uiteindelijk toch kunnen volbrengen, ondanks het uitvoeren van foute acties. Het volbrengen van de taak bestond uit het selecteren van de nodige anlyse en het correct interpreteren van de resultaten.
De gemiddelde succesgraad voor het uitvoeren van de taken is 94%. Dit betekent dat gemiddeld zeven tot acht respondenten er in geslaagd zijn om de juiste analyse te selecteren en de resultaten juist te interpreteren, wat een goede score is gezien onze vooropgestelde 70%-regel.
%
of
participants who Tasks: Survey Analyser
completed tasks
1
Vragenlijst opzoeken
100%
2
Meetmodel opzoeken
100%
3
Verdeling total sample nagaan
100%
4
Missing data aanduiden
100%
5
Gemiddeldes opzoeken van items
100%
6
Grafische gegeven score opzoeken voor 1 item
87%
7
Kijken met vergrootglas naar leeftijd van zeer ontevredenen van vraag "x"
100%
8
Opzoeken van een kruistabel voor 2 items
75%
9
Ranking van concepten
100%
10 Verander kleur van Ranking-thermometer
87%
11 Impact Diagram van concepten
75%
12 Gebruik van Vergelijkingsanalyses o.b.v. splitvariabele leeftijd
100%
Tabel 13: Effectiviteit Survey Analizer
6.2.2 Efficiency Voor de dimensie efficiëntie hebben we opnieuw gebruik gemaakt van het gemiddelde percentage van gebruikers dat geen onnodige acties uitvoerde. Daarbij werden, ter controle, enkele andere meetmaten gebruikt zoals vooreerst de gevraagde hulpfrequentie en ten tweede de gemaakte fouten van categorie twee en drie.
We stellen vast dat gemiddeld 73% van de respondenten de taken zonder onnodige acties kon uitvoeren. Dit percentage wordt ondersteund door het aantal deelnemers dat geen hulp vroeg (68%).
69
Ook het gemiddeld percentage gemeten aan de hand van respondenten die geen efficiëntie fouten maakten (type 2 en 3) ligt hier dicht bij (72%).
Deze percentages zijn behoorlijke scores volgens de 70%-regel, maar een verbetering zou de verwachtingen beter tegemoet komen. Daarbij konden overheen de drie efficiëntie meetmaten, in dezelfde drie van de twaalf taken (25%), duidelijke ondermaatse scores worden vastgesteld. De patronen in performantiedata kennen aldus hun bevestiging overheen de drie efficiëntie meetmaten (Bijlage 2 en 3). Een vierde taak werd als problematisch geïdentificeerd vanwege een tamelijk hoge hulpfrequentie.
%
of
participants who made only necessary Tasks: Survey Analyser
actions
1
Vragenlijst opzoeken
0%
2
Meetmodel opzoeken
100,00%
3
Verdeling total sample nagaan
87,50%
4
Missing data aanduiden
100%
5
Gemiddeldes opzoeken van items
12,5%
6
Grafische gegeven score opzoeken voor 1 item
25,00%
7
Kijken met vergrootglas naar leeftijd van zeer ontevredenen van vraag "x"
87,50%
8
Opzoeken van een kruistabel voor 2 items
100%
9
Ranking van concepten
75%
10 Verander kleur van Ranking-thermometer
100,00%
11 Impact Diagram van concepten
87,50%
12 Gebruik van Vergelijkingsanalyses o.b.v. splitvariabele leeftijd
100%
Tabel 14: Efficiëntie Survey Analizer: Percentages van participanten die geen onnodige acties maken
·
Opzoeken van een vragenlijst
De lage score voor de eerste taak kan verklaard worden doordat alle acht deelnemers (100%) vergaten de data te selecteren alvorens te starten met het analyseren van de gegevens, wat vanzelfsprekend onnodige stappen met zich meebracht.
70
Figuur 23a: Screenshot Drobots: Dataselectie
Figuur 23b: Screenshot Drobots: Selectie maken
Uit kwalitatieve feedback bleek dat respondenten dachten dat de laatst ingegeven data (cf. Survey Setup) automatisch werd geselecteerd voor analyse of dit reeds was gebeurd in het “Survey Setup”gedeelte bij het aanmaken van een nieuw project (cf. taak 2). Toen gebruikers gewezen werden op het bijschrift in het hoofdmenu, waarin vermeld staat om eerst een selectie van data te maken, werd beargumenteerd dat deze over het hoofd werd gezien omdat deze weinig opvalt in de interface.
71
Verdere begeleiding van gebruikers door de applicatie is daarbij noodzakelijk om dit op probleem te vangen. ·
Vinden van een tabel met alle gemiddelden opgelijst
Alle respondenten hadden problemen bij de taak waarbij gevraagd werd de opgelijste gemiddelden van alle vragen in een tabel weer te geven. Dat wordt bevestigd door alle drie de meetmaten gebruikt om efficiëntie te meten (cf. supra). Gebruikers konden de taak vervullen, maar slechts 12.5% (1/8 respondenten) konden deze taak volbrengen zonder daarbij onnodige acties uit te voeren, verkeerde selecties te maken en frequent hulp te vragen. 80% van de onnodige acties nam plaats bij het zoeken van de “All means”-functie die in tabelvorm de gemiddelden weergeeft.
De voornaamste reden voor deze slechte score is er bij de respondenten verwarring ontstond door twee functies die sterk op elkaar lijken, namelijk “Means” en “All means”. Terwijl “Means” de grafieken weergeven per facet, geeft “All means” een volledig overzicht van alle gemiddelden van items in tabelvorm. Zeven van de acht deelnemers selecteerden telkens opnieuw de functie “Means” waar slechts de gemiddelden kunnen geraadpleegd worden voor elk facet in grafiekvorm en geen volledig overzicht van alle gemiddelden van items kan worden weergegeven in tabelvorm. De volgende interface kregen gebruikers te zien tijdens het uitvoeren van de opdracht. De drie hoofdmenu’s hier zijn “Lists”, “Frequencies” en “Means”. Respondenten verwachtten het terugvinden van de gemiddelden bij de “Means” functie, terwijl de tabel met gemiddelden onder het menu “Lists”>”All Means” terug te vinden is.
Hier verder een voorbeeld van de verkeerde acties uitgevoerd door participanten en weergave van gemiddelden via het “Means”-menu.
72
Figuur 24a: Screenshot Drobots: Means (grafieken)
Figuur 24b: Screenshot Drobots: Means gemiddelden
De volgende “screenshots geven dan de acties weer die respondenten hadden moeten uitvoeren om de taak zonder onnodige acties te vervullen via “List”>”All means”
73
Figuur 25a: Screenshot Drobots: All Means (tabellen)
Door “All means” aan te klikken kreeg men dan volgende tabel te zien:
Figuur 25b: Screenshot Drobots: All Means: overzichtslijst
74
Uit kwalitatieve feedback van gebruikers hebben we vastgesteld dat gebruikers het verkeerd voor hadden door de onlogische opsplitsing van twee functies die gemiddelden weergeven, enerzijds in grafieken en anderzijds in tabellen. Gebruikers verwachten bij het uitvoeren van deze taak dat de functie “Means” alles weergeeft van gemiddelden, zowel in tabel als grafiek, wat meteen de hoge graad van onnodige acties in deze taak verklaart. ·
Vinden van frequentiegrafiek en score voor één bepaald item
Respondenten vonden het blijkbaar moeilijk om de grafieken van frequenties voor de items terug te vinden. 25% of 2/8 van de respondenten selecteerden daarbij telkens het verkeerde menu in het zoeken van de grafische weergave voor items, wat tot bijkomende acties zorgde.
Om de frequentiegrafieken van items weer te geven dienen 2 menu’s te worden opengeklikt (Frequencies>Questions). Daarbij dienen volgende stappen doorlopen worden. Opnieuw kregen gebruikers de interface van “Question Level” te zien, waarbij de drie reeds eerder besproken menu’s aanwezig zijn (Lists, Frequencies en Means).
Figuur 26a: Screenshot Drobots: Frequencies>Questions
75
Na het openklikken van “Frequencies” en”Questions” krijgt men volgende interface te zien.
Figuur 26b: Screenshot Drobots: Frequencies>Questions
Figuur 26c: Screenshot Drobots: Frequencies>Questions
Gebruikers leken daarbij niet te verwachten dat “Questions”, een submenu van “Frequencies”, toegang zou geven tot grafieken voor de score op items. Respondenten bleken daarbij het label “Questions”niet te associëren met weergave van grafieken voor frequenties. Net zoals in de hierboven beschreven taak vonden deelnemers de label voor het menu niet duidelijk en kan gesteld worden dat er door gebruikers nood hebben aan een duidelijkere indicatie in de naam van een menu die aangeeft of het om grafieken of tabellen gaat. 76
·
Verdeling van het sample raadplegen
We bemerken een tamelijk hoge hulpfrequentie op bij de taak waarin gevraagd werd aan deelnemers om te kijken hoe de sample verdeeld is volgens de ingegeven nominale variabelen (cf. splitvariabelen). Gebruikers dienden daarvoor drie acties uit te voeren, namelijk klikken op “Sample results”, open klikken van “Frequencies” en een selectie maken tussen “Total sample” (wat de verdeling van het sample weergeeft) en “Valid responses” (wat een overzicht geeft van missing data). Het volgende krijgt men te zien als “Sample results” wordt geselecteerd.
Figuur 27a: Screenshot Drobots: Sample results menu
Figuur 27b: Screenshot Drobots: Frequencies
77
Figuur 27c: Screenshot Drobots: Functionaliteit
Figuur 27d: Screenshot Drobots: Verdeling van de sample
Drie van de acht (62.5%) gebruikers gaven aan dat ze in de war werden gebracht doordat ze in op “Sample results” klikten en vervolgens het menu “Frequencies” zagen verschijnen, maar geen specifieke menu’s zoals “Total sample” en “Valid responses” beschikbaar waren. Deze werden pas zichtbaar wanneer gebruikers verder klikten op “Frequencies”. Drie respondenten bleven echter wachten tot zij iets te zien kregen, wat natuurlijk niet gebeurde doordat ze een actie waren vergeten. Daardoor werd een tamelijk hoge hulpfrequentie vastgesteld. Uit kwalitatieve feedback konden we besluiten dat gebruikers de tussenstap, waarin “Frequencies” nogmaals dient te worden open geklikt, als onlogisch werden aanzien doordat zij meteen de menu’s
78
“Total sample” en “Valid responses” verwachten te zien. Daarbij werd het tussenmenu en haar label, “Frequencies”, als een onnodige en verwarrende stap in het proces om de verdeling van een sample te raadplegen aanzien. Deze tussenstap geeft met andere woorden geen meerwaarde aan de usability van deze menu’s en haar functionaliteit.
6.2.3 Error Tolerance De score van Error tolerantie voor het “Survey Analyzer”- gedeelte bedraagt 86%. Van alle gemaakte foute acties konden gemiddeld 86% van de fouten hersteld worden. Dit is met een zeer goede score rekening houdend met de 70%-doelstellingen. Deze score ondersteunt de resultaten voor Effectiviteit, waarbij eveneens een hoge gemiddeld slagingspercentage per taak werd vastgesteld, ondanks de vele gemaakte efficiëntiefouten (Bijlage 4).
Taken die een slechte score haalden voor deze dimensie worden afgebeeld in de tabel. Aantal
Aantal
gemaakte
herstelde
Tasks: Survey Analyzer
fouten
fouten
Percentages
1
Vragenlijst opzoeken
16
16
100%
2
Meetmodel opzoeken
1
1
100%
3
Verdeling total sample nagaan
1
1
100%
4
Missing data aanduiden
-
-
-
5
Gemiddeldes opzoeken van items
10
10
100%
6
Grafische gegeven score opzoeken voor 1 item
6
5
83%
Kijken met vergrootglas naar leeftijd van zeer 7
ontevredenen van vraag "x"
1
1
100%
8
Opzoeken van een kruistabel voor 2 items
2
0
0%
9
Ranking van concepten
2
2
100%
10
Verander kleur van Ranking-thermometer
1
0
0%
11
Impact Diagram van concepten
3
1
33,30%
-
-
-
Gebruik 12
van
Vergelijkingsanalyses
o.b.v.
splitvariabele leeftijd
Tabel 15: Error tolerantie: Survey Analyzer
79
Er werden enkele niet te verbeteren fouten(type (1)) gemaakt. De taak kon daarbij niet worden volbracht doordat een menu niet kon worden gevonden (veranderen van kleur van de Ranking-meter) of doordat de resultaten van een grafiek of tabel verkeerd werd geïnterpreteerd (Impact diagram en kruistabel).
De kruistabel en de impact diagram werden verkeerd geïnterpreteerd. De interpretatie wordt aanzien als één van de noodzakelijke acties om juiste resultaten te rapporteren en werden om die reden eveneens geregistreerd. Een slechte interpretatie zou immers het gevolg kunnen zijn van een slechte weergave in tabellen, grafieken, legendes of lay-out waardoor vergissingen kunnen gemaakt worden in het interpreteren van resultaten.
In geval van de impact of regressiediagram (cf. taak 11) werden twee interpretatiefouten gemaakt door twee deelnemers. Gebruikers gaven daarbij een verkeerd antwoord op de vraag welke van de concepten met de slechtste score het meeste impact heeft op een het facet “LOON”. Toen gebruikers herinnerd werden aan de y-as, die de gemiddelden voor elk concept weergeeft, konden beide respondenten wel een juist antwoord geven. Toen de reden van de misvatting werd gevraagd antwoordden de respondenten dat zij enkel oog hadden gehad voor de tabel onder de figuur, waar enkel de impact van de concepten wordt afgebeeld. Wij vroegen echter de score met eveneens het laagste gemiddelde en hoogste impact. Het laagste gemiddelde kon niet worden waargenomen in de tabel, wel aan de hand van de figuur. De tabel kan in dit geval een handig hulpinstrument in zijn om deze te interpreteren (Bijlage 5).
De kruistabel werd eveneens door twee respondenten verkeerd geïnterpreteerd. Eén respondent verklaarde daarbij dat hij niet goed gekeken had naar de legende. De tweede participant stelde dat hij de legende en figuur niet zo duidelijk vond doordat er teveel kleuren worden gebruikt. Wanneer werd gewezen op de gradaties in kleur die wijzen op gradaties van significantie (blauw, licht blauw, licht rood, rood), antwoordde de respondent dat vooral de gele kleur teveel aan is. De gele kleur geeft de invalide elementen in de kruistabel weer (Bijlage 6).
De Ranking-functie (cf. taak 9) werd gemakkelijk weergevonden door onze participanten en slechts één participant kon de additionele taak, “veranderen van de kleuren van de Ranking-meter” niet terugvinden. Dit menu biedt een interessante functionaliteit waarmee via een rechter muisklik op de figuur de kleur van de meter kan worden aangepast (Bijlage 7). Uit kwalitatieve feedback blijkt dat de participant zich wel leek te herinneren dat de kleuren van de figuur kunnen worden aangepast, maar niet meer wist hoe hij toegang tot deze functie kreeg (rechter muisklik op figuur). De respondent motiveerde dat deze functie niet duidelijk genoeg is aangeduid in de interface. Daarbij suggereerde de participant dat een menu voor deze functie naast de grafiek gemakkelijker zou zijn om deze terug te 80
vinden. We dienen te nuanceren dat deze verkeerde acties alleenstaande gevallen, waarvan, bij andere gebruikers, geen duidelijke patronen konden worden teruggevonden.
6.2.4 Learnability De Learnbility werd geëvalueerd door het aantal uur dat geoefend werd met Drobots in verhouding te stellen met het aantal taken dat foutloos volbracht werden door deelnemers. Wij hebben daarbij vooropgesteld dat respondenten die tot 3 uur geoefend hadden met de software een gemiddeld slagingspercentage zouden moeten kunnen halen van 70% of meer. Gemiddeld konden de participanten 69% van de taken vervullen zonder één enkel fout.
Hieruit kunnen we betrekken dat vijf van de acht respondenten minder dan één uur oefenden met software om een gemiddeld slagingspercentage te behalen van 9/12 (75%) in het uitvoeren van taken zonder één enkele fout van de drie onderscheiden types. Eén respondent oefende tussen 1 en 3 uur en haalde daarbij een gemiddelde score van 9/12 (75%). Twee personen haalde een gemiddelde score van 7/12 (58%).
Hieruit kunnen we concluderen dat 6/8 respondenten minder dan 1 uur tot maximum 3 uur nodig hadden om een gemiddeld slagingspercentage te behalen van 75% met betrekking tot taken waar geen enkele fout in werd gemaakt.
Dit is een behoorlijk goede score en wijst op een zeer gemakkelijk aan te leren interface betreffende Survey Analyzer. Moesten bovenstaande problematische aangeduide efficëntieproblemen van Drobots worden verbeteren, zou gemiddelde score voor gemakkelijkheid in aanleren sterk kunnen stijgen.
6.2.5 Subjective Satisfaction De gemiddelde score van subjectieve aantrekkelijkheid werd vastgesteld op 82.5% (8.25/10). Alle facetten van Subjectieve Satisfactie betreffende Survey Analyzer hebben daarbij een hoge gemiddelde score gekregen van gebruikers.
Facetten
Gemiddelden scores
Ease of Use
8.06/10
Labelling
7.89/10
Visual attractiveness
7.9/10
Organtisation of information
7.9/10
Tabel 16: Facetten van subjectieve satisfactie: Survey Analyzer
81
In dit gedeelte werden slechts vier facetten in rekening genomen, aangezien het facet Error Correctie in dit software gedeelte niet mogelijk is. Deze wordt berekend aan de hand van de door gebruikers gepercipieerde gemakkelijkheid betreffende het ingeven van verbeteringen voor verkeerd ingevoerde gegevens. Aangezien Survey Analyzer niet gaat om het ingeven van gegevens, maar wel om het maken van analyses werd is het facet achterhaald en niet toepasselijk. Het verbeteren van ingegeven data is niet mogelijk en is daardoor achterwege gelaten in de voorkeursbeoordeling van het “Survey Analyzer”-gedeelte.
Als we dieper ingaan op de gemiddelden per vraag zien we algemeen hoge scores (boven 70%) tot zeer hoge scores (boven 90%). Slechts één vraag scoorde daarbij slechter (65%) en onder de vooropgestelde doelstelling (cf. 70%-regel). Het gaat om de vraag “het is voor mij meteen duidelijk welke analyses ik dien aan te klikken om het verwachte resultaat te verkrijgen”.
Concept
(1) tevredenheid
Facet
Mean
Question
(scale 10)
(Q6) Als ik een analyse wil uitvoeren is voor mij meteen LABEL duidelijk welke menu’s ik moet aanklikken om het verwachte 6.5625 resultaat te krijgen
Tabel 17: Q6: Gemiddelde score voor duidelijkheid van labels
(Q6) Als ik een analyse wil uitvoeren is voor mij meteen duidelijk welke menu’s ik moet aanklikken Scaled om het verwachte resultaat te krijgen
8
(1)
helemaal
akkoord
0
(3) neutraal
4
(4) akkoord
3
akkoord
82
0
(2) niet akkoord
(5)
Tabel 18: Q6: Frequentiescore voor duidelijkheid van labels
niet
helemaal
1
0.00 % 0.00 % 50.00 % 37.50 % 12.50 %
Deze score komt overeen met wat werd vastgesteld in de performantiedata voor taken in “Question level”, waarin gebruikers niet altijd wisten welke menu de juiste functie was om te gebruiken tijdens het opzoeken van gemiddeldes (cf. taak 5) en opvragen van een frequentiegrafiek (cf. taak 6). Daarin bleek dat de labels inderdaad niet altijd overeenstemmen met de verwachtingen van gebruikers betreffende de beschrijving van een functie. Dit was het geval voor de labels “All means” (cf. taak 5) en “Question” (cf. taak 6).
Er werd een tamelijk hoge gemiddelde score gehaald op de vraag of gebruikers het selecteren van het databestand om analyses op uit te voeren gemakkelijk in gebruik is (75%). Dit terwijl uit de performantiedata blijkt dat alle gebruikers deze taak met extra acties hebben uitgevoerd omwille van het vergeten selecteren van dit databestand (cf. Efficientie, Taak 1). Hieruit kunnen we stellen dat alhoewel alle gebruikers deze fout maakten, uit de preference data blijkt dat zij niet als irritant of frustrerend werd bevonden door onze respondenten.
Concept (1) tevredenheid
Facet
EASEOFUSE
Mean
Question
(scale 10)
(Q3) Het databestand selecteren om dan analyses op te doen vind ik gemakkelijk in gebruik
7.5000
Tabel 19: Q3: Gemiddelde score voor dataselecties
(Q3) Het databestand selecteren om dan analyses op te doen vind ik gemakkelijk in Scaled 8 (1) helemaal niet akkoord
0 0.00 %
gebruik (2) niet akkoord
1 12.50 %
(3) neutraal
0 0.00 %
(4) akkoord
5 62.50 %
(5) helemaal akkoord
2 25.00 %
Tabel 20: Q3: Frequentiescore voor dataselectie
Tot slot werden eveneens zeer goede scores vastgesteld. Dit was het geval voor de duidelijkheid van iconen en hoofdmenu’s (90%) (niet submenu’s), de volgorde waarmee selectiekaders ingevuld dienen te worden om een bepaald item te isoleren (90%) (cf. Drill down) en werd de manier waarop analyses werden uitgevoerd door gewoon op een menu te klikken als zeer gemakkelijk te gebruiken gescoord (93%). 83
Hoofdstuk7: Conclusies Uit de resultaten van het onderzoek kan met betrekking tot de prestaties van Drobots aangaande usability het volgende geconcludeerd worden.
Algemeen kan gesteld worden dat voor alle usability-dimensies de norm van de 70%-doelstelling behaald of bijna behaald werd. Dit geldt zowel voor Survey Setup, als voor Survey Analyzer. We kunnen daaruit besluiten dat voor beide onderdelen van de Drobotsapplicatie aanvaardbare (>70%) tot zeer goede (>90%) scores werden vastgesteld.
Dimensies
Survey Setup
Survey Analyzer
Effectiviteit
97%
94%
Efficiëntie
*69%
*73%
Error Tolerantie
95%
86%
Learnability
**68%
**75%
78%
82%
Subjectieve Bevrediging
* Enkel score van de meetmaat aantal onnodige acties afgebeeld ** Score voor participanten die minder dan één uur tot maximum 3 uur met de Drobotsapplicatie hebben geoefend
Tabel 21: Algemene score usabilitydimensies voor Survey Setup en Survey Analyzer
Opvallend is dat in beide onderdelen, zowel in “Survey Setup”, als voor “Survey Analyzer” de dimensie efficiëntie minder goed scoort in vergelijking met de overige vier dimensies die gemiddelde scores halen tussen 80% tot 100%. De lage efficiëntiescore is het gevolg van het vaststellen van een hoog aantal foute acties van het type (2) en (3). Efficiënt navigeren en gebruik blijkt op een minder succesvolle manier geïmplementeerd te zijn in de Drobotsapplicatie. Bij het “Survey Setup”-gedeelte zijn de slechtst scorende taken betreffende efficiëntie “het ingeven van variabelen” (taak 3), “ingeven van waarden” (taak 4), “correctie van waarden” (taak 6), “de correctie van het model” (taak 11), “het uploaden van een databestand” (taak 12). Voor het “Survey Analyzer”-gedeelte stellen we vast dat verbeteringen nodig zijn aan de wijze waarop data dient geselecteerd en ge-upload te worden (taak 1). Ook het “Question level”- menu bleek weinig efficiënt te zijn in gebruik ten aanzien van het weergeven van gemiddelden in tabellen of grafieken (taak 5). Hetzelfde kan gesteld worden met betrekking tot het opzoeken van grafieken voor frequenties 84
(taak 6). Tot slot werd eveneens een hoge hulpfrequentie vastgesteld bij het opzoeken van het meetmodel (Taak 4) wat wijst op de nood aan bijkomende begeleiding.
Voor learnabilty werd voor beide onderdelen van de Drobotsapplicatie, in vergelijking met de andere dimensies, eveneens een minder goede score vastgesteld. Aangezien Drobots slechts een matig efficiënt gebruik toelaat heeft dit eveneens een negatieve invloed op learnability. Deze dimensie wordt immers bepaald door het in rekening nemen van alle gemaakte fouten. Voor “Survey Setup” zijn 95% van alle gemaakte foute acties efficiëntiefouten (cf. type (2) en (3) fouten). Voor Survey Analyzer zijn 86% van alle foute acties efficiëntiefouten. Het hoge aantal efficiëntiefouten heeft daarbij een sterke negatieve impact op learnability. Het oplossen van de in beide onderdelen vastgestelde problemen door de efficiëntiematen zal niet enkel de Efficientie, maar tevens de gemakkelijkheid in het aanleren van gebruik (Learnability) optimaliseren. Het mogelijk maken van meer efficiënt gebruik zorgt ervoor dat er minder efficiëntiefouten kunnen gemaakt worden, wat er op zijn beurt voor zal zorgen dat het aanleren van gebruik en functies voor beide onderdelen gemakkelijker kan verlopen.
Tegenover deze twee matig scorende dimensies staan, voor beide onderdelen, hoge scores voor Effectiviteit en Error Tolerantie, wat er op wijst dat gebruikers weinig onherstelbare foute acties (type (1) en (4)) kunnen maken waardoor de taak of het gebruiksdoel niet meer kan volbracht worden. In het “Survey Setup”-gedeelte waren slechts 5% van de fouten onherstelbaar (type (1) en (4)), waardoor de taak niet kan worden uitgevoerd. Bij “Survey Analyzer” werden zes (14%) onherstelbare fouten vastgesteld die hebben geleid tot het falen van de taak. Algemeen kunnen we stellen dat de taken gemakkelijk volbracht konden worden (effectiviteit) doordat slechts weinig “onherstelbare foute acties” kunnen worden gemaakt (error tolerantie). Als we dieper ingaan op enkele taken kunnen we echter enkele slecht presterende taken identificeren die in de algemene gemiddeldes niet waar te nemen zijn. Voor het “Survey Setup”-gedeelte scoren effectiviteit en error tolerantie ondermaats met betrekking tot de logintaak (taak 1). Drie (38%) van de acht participanten konden deze taak niet uitvoeren en maakten daarbij een “onherstelbare fout” (cf. type (3) of (4)). De ernst van de effectiviteitscore van deze taak kent zodoende bevestiging in de scores van Error Tolerantie, waarbij geen van de gemaakte foute acties, bij de logintaak, konden hersteld worden. Voor het “Survey Analyzer”-gedeelte kunnen in alle taken hoge effectiviteitsscores worden waargenomen. Als we dieper ingaan op de scores van error tolerantie stellen we echter vast dat in een aantal taken enkele onherstelbare acties zijn waargenomen. De taken met betrekking tot het opzoeken van een kruistabel voor twee items (Taak 8) en impact diagram van concepten (Taak 11) werd
85
verkeerd geïnterpreteerd door 25% van de respondenten (2/8). Slechts één respondent kon de verandering van kleur niet uitvoeren bij de Ranking-diagram (Taak 10).
De vastgestelde foute acties bij de taken (taak 8, 11, 10) zijn alleenstaande gevallen en kunnen niet weergevonden worden bij andere participanten. Derhalve zijn deze gemaakte “onherstelbare acties” niet van aard de gemiddelde effectiviteitgraad sterk te beïnvloeden. Ze werden volledigheidshalve wel vermeld omwille van de ernst en het onherstelbaar karakter van de fout (fouten van type (4)).
In beide onderdelen werden hoge algemene gemiddelde scores vastgesteld voor de dimensie subjectieve bevrediging en haar facetten. Als we dieper ingaan op de vragen stellen we enige slechte scores vast. Enkele van de hierboven vernoemde problemen in de dimensies effectiviteit en efficiëntie (performance data) worden daarbij ondersteund door de Subjectieve Satisfactie (gemeten aan de hand van kwantitatieve preference data). Sommige taken die slechte efficiëntie of effectiviteit in gebruik vertonen worden daarbij als irritant beschouwd. We kunnen besluiten dat de lage effectiviteit of efficiëntie in deze taken een negatieve invloed hebben gehad op de tevredenheid en gepercipieerde gemakkelijkheid in gebruik (cf. infra). Bij het onderdeel “Survey Setup” werden ondermaatse scores vastgesteld in verband met het facet: de organisatie van informatie. De oorzaak hiervan is de slechte score op de vraag of de loginfunctie gemakkelijk is terug te vinden op de Drobotssite (Q3). We kunnen besluiten dat de lage effectiviteitsscore en error tolerantie vastgesteld voor het vinden van de te onopvallende login-button voor gebruikers als irritant werd bevonden (taak 1). Daarbij komend merkten we dat volgens kwalitatieve data, vijf (62%) van de acht respondenten op dat de loginfunctie ofwel te onduidelijk was ofwel te onopvallend of te klein werd afgebeeld in de interface. Het belang van de loginfunctie, de ernst van een gemaakte onherstelbare foute acties en de invloed op de subjectieve tevredenheid doet ons besluiten dat de moeilijk te vinden loginfunctie een grote invloed heeft op de efficiëntie, effectiviteit, subjective satisfactie van het “Survey Setup”-gedeelte. Het vastgestelde verlies van efficiëntie voor “Survey Setup” bij het ingeven van variabelen (taak 3), het ingeven van waarden (taak 4) en het uploaden van een databestand (taak 12) werden door de deelnemers niet als irritant ervaren en hadden geen invloed op de subjectieve satisfactie. Het “Survey-Analyzer”-gedeelte kende een lage tevredenheidscore voor de duidelijkheid van labels (Facet Labelling). De oorzaak hiervan is de slechte score op de vraag in welke mate gebruikers het gevoel hadden te weten welke menu’s zij moesten aanklikken om een bepaalde analyse uit te voeren (Q6). Dit wordt duidelijk bevestigd door de slechte score van efficiëntie betreffende de taken in “Question level”-menu, bij het opzoeken van tabellen voor gemiddelden van vragen (taak 5) en het 86
weergeven van grafieken voor de frequenties per vraag (taak 6). We kunnen besluiten dat het efficiëntieverlies in deze taken als irritant wordt beschouwd door de betrokken respondenten en hun invloed hadden, niet enkel op efficiëntie, maar eveneens op de tevredenheid (subjectieve satisfactie).
De mindere goede prestaties van de dimensie efficiëntie voor de het selecteren van data (taak 1), had geen negatieve invloed op de subjectieve satisfactie. Deze opdracht kende een hoge preferentiescore vanwege respondenten. Hieruit volgend kan gesteld worden dat, ondanks de vele gemaakte efficiëntiefouten, dit proces, niet als irritant of frustrerend was voor gebruikers.
Problematisch scorende taken: Survey Setup 1 Website en toegangspoort naar de Drobotsapplicatie vinden 3 Variabelen ingeven
Betrokken Dimensies Effectiviteit, Error Tolerance, Subjectieve Satisfactie Efficiëntie, Learnability
4 Waarden voor variabelen ingeven
Efficiëntie, Learnability
6 Corrigeer foute waarden (antwoordcategorien)
Efficiëntie, Learnability
11 Corrigeren van fout ingegeven concepten, facetten en links ertussen
Efficiëntie, Learnability
12 Invoeren van een surveynaam en selecteren van het databestand in kwestie
Efficiëntie, Learnability
7,8,9 Ingave model (topic>concepten>facetten>questions linken)
Efficiëntie, Learnability
Tabel 22: Problematisch scorende taken voor Survey Setup
87
Reden De login-functie is te onapvallend, te onduidelijk en te klein afgebeeld in de Drobotsinterface Een verlies van overzicht van de reeds ingegeven variabelen waardoor duplicatie of overslaan van variabelen Onduidelijke labelling van de invulvelden voor antwoordcategorie en antwoordwaarde Respondenten werden te onduidelijk geinformeerd door de interface betreffende de mogelijkheid om een antwoordcategorie rechtstreeks aan te passen vanuit de overzichtstabel van variabelen Participanten konden foute ingave van facet moeilijk terugvinden om te verbeteren door het onbreken van een aanpassingsmenu en gebrek aan consistentie met correctiemenu betreffende variabelen Participanten dachten dat dit overbodig of reeds gebeurd was bij het toekennen van een naam aan het project bij "Project Name" (cfr. taak 2) door onduidelijke labeling en weergave van invulvelden Hoge hulpfrequentie vastgesteld als gevolg van het complex aanvoelen van dit menu door participanten
Problematisch scorende taken: Survey Analyser 1 Vragenlijst opzoeken
Betrokken Dimensies Efficiëntie, Learnability
Reden Deelnemers vergaten de data te selecteren om analyses op uit te voeren, omdat zij dachten dat deze reeds automatisch werd geselecteerd als gevolg van de net ingegeven data Deelnemers vonden de tussenstap waarbij "Frequencies" diende opengeklikt te worden om toegang te krijgen tot de verdeling van de sample onlogisch. Zij verwachtten iets te zien te krijgen bij het openklikken van deze menu, wat niet het geval was. Participanten werden verward door de onlogische opsplitsing van de menu's voor weergave van gemiddelden in grafiek en weergave gemiddelden in tabellen
3 Verdeling total sample nagaan
Efficiëntie, Learnability
5 Gemiddeldes opzoeken van items in tabelvorm
Efficiëntie, Learnability, Subjectieve Satisfactie
6 Grafische gegeven score opzoeken voor 1 item
Efficiëntie, Learnability, Subjectieve Satisfactie
Het label van het menu "Questions" verwijst niet duidelijk genoeg naar grafieken voor frequenties op een item
8 Opzoeken van een kruistabel voor 2 items
Error Tolerance
10 Verander kleur van Ranking thermometer
Error Tolerance
11 Impact Diagram van concepten
Error Tolerance
Verkeerde interpretatie door veelheid aan kleuren in de legende Functie om kleur te veranderen werd niet teruggevonden doordat deze functie nergens staat aangeduid in de interface Foute interpretatie. Respondenten bleken nood te hebben aan een tabel waar zowel de impact als de gemiddelde score van de concepten af te lezen om te helpen bij de interpretatie van de regressie-diagram
Tabel 23: Problematisch scorende taken voor Survey Analyzer
88
Hoofdstuk 8: Aanbevelingen Na de bespreking van de usability-validatie en aanduiding van de “usability-hotspots” van de Drobotsapplicatie zullen we enkele aanbevelingen formuleren die er toe strekken de kwaliteit in gebruik en acceptatie van Drobots te verbeteren. Aldus kan de score op de usability-dimensies en daardoor de algemene usability van Drobots verhoogd worden. Voor elke gedefinieerde “hot spot” zullen we een zo passend mogelijke aanbeveling trachten voorop te stellen.
Het bespreken van de aanbevelingen gebeurt in twee delen volgens de twee onderdelen van Drobots, namelijk “Survey Setup” en Survey Analyze. Daarbij situeren we geïdentificeerde probleemgebieden en gaan we verder in op de nodige aanpassingen die aan deze probleemgebieden tegemoet komen.
Tot slot geven wij nog een algemene aanbeveling mee voor de verdere ontwikkeling en verfijning van de Drobotsapplicatie.
8.1
Survey Setup
8.1.1
Effectiviteit, Error Tolerance en Subjective Satisfaction
Alhoewel Survey Setup een hoge graad van effectiviteit in gebruik toelaat, wordt op één belangrijke taak een problematische effectiviteitscore vastgesteld, namelijk de login-taak. De slechte effectiviteitscore wordt ondersteund door error tolerantie en subjectieve bevrediging. Daarbij werd melding gemaakt van onherstelbare foute acties die door de betrokken participanten als irriterend werden bevonden. ·
Login-functie
Gebruikers vonden de login-functie niet terug op de startpagina van Drobots. Deze functie werd beschreven als te klein en niet duidelijk genoeg afgebeeld. Daarom stellen wij voor om de loginfunctie groter, duidelijker en opvallender af te beelden.
Er wordt op de site van Drobots een grote hoeveelheid bijkomende content en informatie aangeboden die een antwoord bieden over de doelstelling, de werking, het aanbod en het ontstaan van Drobots. De login-functie komt daarbij voor in elk van deze verschillende pagina’s wat de consistentie en usability ten goede komt. De grijs-witte kleur van de login-functie valt niet op in vergelijking met de achtergrond van de Drobotswebsite. De daarbij komende kleine vorm van de “login-button” tegenover de grote hoeveelheid informatie op de website, zorgt dat deze “button” niet meteen wordt opgemerkt. 89
De “login-button”zou het eerste moeten zijn wat gebruikers in het oog springt bij het bezoeken van de Drobotswebsite. Dit kan geïmplementeerd worden door deze “button” een opvallende kleur te geven of groter af te beelden op de interface. Ook het opschrift van de login-functie van de interface kan helpen in het verduidelijken van het doel van dit menu. Zo zou in plaats van het label “Applicatie Portal Login” het label “Drobotsapplication Login” of eenvoudigweg “Login” kunnen worden gebruikt zodat de gebruikers een duidelijk idee krijgen van wat men kan verwachten wanneer deze functie wordt aangeklikt.
Ter illustratie van de mogelijkheden geven wij een voorbeeld hoe de login-functie van de Drobotsapplicatie op de Drobotswebsite prominenter weergegeven zou kunnen worden (Bijlage 8).
8.1.2
Efficiëntie en Learnability
De minst goed scorende dimensie voor “Survey Setup” is efficiëntie. Dit verlies van efficiëntie werd volgens de scores van subjectieve bevrediging niet als irriterend beschouwd en had eveneens weinig impact op de effectiviteit van gebruikers betreffende die problematisch geïdentificeerde dimensies. De lage efficiëntie vastgesteld in de hierna vermelde taken, heeft wel de score van “gemakkelijkheid in het aanleren van gebruik” (cf. Learnability) naar beneden getrokken. Vandaar dat aanpassing van deze processen noodzakelijk is om zowel de efficiëntie als de learnability van Survey Setup te verhogen. ·
Ingeven van variabelen
Voor het ingeven van variabelen werd een groot aantal efficiëntiefouten teruggevonden tijdens het benoemen van variabelen. De belangrijkste reden voor deze fouten is het verlies van overzicht tijdens het aanmaken en benoemen van variabelen. Voor de respondenten was het niet altijd duidelijk welke variabele reeds wel of niet werden ingegeven, waardoor variabelen overgeslagen of gedupliceerd werden. De reden hiervoor is dat de overzichtstabel van alle ingegeven variabelen - zichtbaar in de “Questionnaire”-hoofdmenu - verdween van zodra een nieuwe variabele werd aangemaakt (Bijlage 9). Dit gebeurt dan door de selectie van “New”, waarbij het menu voor het benoemen van variabelen zichtbaar werd.
Op grond van deze vaststelling opteren wij ervoor om de overzichtstabel van het hoofdmenu “Questionnaire” eveneens toe te voegen in het menu om variabelen te benoemen (Bijlage 10). Op die manier kan een overzicht behouden worden omtrent de variabelen die reeds ingevuld zijn. 90
·
Ingeven van waarden
Veel efficiëntiefouten werden gemaakt tijdens het ingeven van waarden van gebruikte Likertschalen om de data op te meten. Daarbij dienen de waarden voor elk ordinaal nummer op de Likertschaal te worden ingevuld (bvb. 1 = helemaal akkoord, 2 = akkoord, 3 = neutraal, … etc.). Gebruikers vulden daarbij de verkeerde waarden in. De naam van de waarde werd ingegeven in “Answer Category Code”, terwijl hier de naam van de antwoordcategorie wordt gevraagd. Voor “Answer Value” werd het ordinaal nummer voor de waarde zelf ingevuld, terwijl de naam van de waarde wordt gevraagd en het ordinaal nummer reeds was gegeven.
De belangrijkste oorzaak voor de efficiëntiefouten is de onduidelijke labelling in het aanmaakmenu van de antwoordcategorie en waarden. Een minder technische labelling voor de invulvelden in dit menu en een andere volgorde voor die invulvelden zou hieraan dit kunnen verhelpen. Wij stellen daarom voor om het label van “Answer Category Code” te vervangen door “Name of Answer Category” en het label “Answer value” door “Answer for ordinal number”. Deze meer concrete en duidelijkere labels zouden gebruikers kunnen helpen in de verwarring over de in te vullen velden (Bijlage 11). Verder lijkt de volgorde van de invulvelden logischer als de plaats van “Answer value” en het gegeven “Ordinaal number” wordt omgewisseld in de interface. Op deze wijze nemen de gebruikers, na het invullen van de naam voor de antwoordcategorie, vooreerst het ordinaal nummer waar, alvorens zij “Answer value” dienen in te vullen (Bijlage 11). Dit zou voorkomen dat extra acties moeten gemaakt worden doordat het ordinaal nummer verkeerdelijk in het invulveld van “Answer value” wordt ingegeven waar de naam voor het ordinaal nummer moet ingegeven worden (bijvoorbeeld 1 = Helemaal akkoord). Gebruikers zullen dan meteen het ordinaal nummer waarnemen en meteen begrijpen dat het “Answer Value” voor dit ordinaal nummer wordt gevraagd. ·
Correctie van de waarden
Bij de correctie van waarden vanuit de overzichtstabel werd een lage efficiëntie vastgesteld in het corrigeren van de antwoordcategorie. Daarbij voerden gebruikers extra acties uit, omdat niet duidelijk was of een ingevoerde antwoordcategorie rechtstreeks kon worden aangepast vanuit de overzichtstabel.
Om zowel de efficiëntie in gebruik als de learnability van dit proces te verhogen stellen we voor dat ingegeven antwoordcategorieën een eigen correctiemenu krijgen door een “Edit”-menu toe te voegen
91
naast de antwoordcategorie afgebeeld in de lijst (Bijlage 12). Zo worden gebruikers bewust gemaakt van deze handige functionaliteit. ·
Ingeven van model
Voor het ingeven van het model (Taak 7-9) werd een hoge hulpfrequentie vastgesteld. De hulpfrequentie daalde opvallend nadat de eerste facetten werden aangemaakt en gelinkt aan de bijhorende vragen. Ook bij het aanmaken van de topic werd een hoge hulpfrequentie vastgesteld doordat gebruikers de noodzaak van het aanmaken van een topic niet begrepen. Om de efficiëntie van dit proces te verbeteren lijkt het ons gepast om een “wizard” te implementeren in het hoofdmenu “Model” en de submenu’s “Question to Facet”, “Facet to Concept”, “Concept to Topic”. Deze kunnen de gebruikers verduidelijken en begeleiden in de wijze waarop men een topic, concepten, facetten en items kan aanmaken en linken (Bijlage 13). Om optimaal te slagen in de gebruikersbegeleiding zou deze “wizard” moeten verschijnen vanaf het moment dat gebruikers het hoofdmenu “Model” selecteren en de verschillende tabmenu’s te zien krijgen (“Model”, “Question to Facet”, “Facet to Concept”, “Concept to Topic”).
Uit de resultaten werd vastgesteld dat de hulpfrequentie afnam nadat gebruikers de eerste facetten hadden aangemaakt gebonden aan vragen. Daarom zou deze “hulpwizard” een optioneel menu moeten vormen. Dit is mogelijk door een “checkbox” (Bijlage 13) in te voeren in het hoofdmenu (“Model”) en submenu’s (“Model”, “Question to Facet”, “Facet to Concept”, “Concept to Topic”) zodat de hulp van de “wizard” door de gebruiker op elk moment kan worden ingeschakeld en uitgeschakeld . Ervaren gebruikers zouden immers geïrriteerd kunnen worden door tussenkomst van een “wizard” en krijgen op deze manier de kans deze functie uit te schakelen. ·
Correctie van het ingegeven datamodel
De lage vastgestelde efficiëntie bij de correctie van het datamodel, werd veroorzaakt door het feit dat respondenten niet goed begrepen op welke wijze een fout ingegeven element kon worden aangepast. Het controleren van het model gebeurt in het submenu “Model” waar een overzicht wordt gegeven van de ingevoerde en gelinkte elementen in een tabel. Om foute elementen aan te passen dient terug gekeerd te worden naar het “submenu” waar de fout werd ingegeven. Als de fout zich bevindt in een verkeerd gelinkte vraag of verkeerd benoemd facet, dan zal naar het aanmaakmenu “Question to Facet” moeten teruggekeerd worden om deze fout te corrigeren (Bijlage 14). Dit gegeven werd als verwarrend beschouwd door participanten. Wij stellen voor om, net zoals in het menu “Questionnaires” (cf. het ingeven van variabelen), een overzichtstabel en aanpassingsmenu te implementeren in het hoofdmenu “Model”, waar controle van 92
de ingegeven modelelementen plaatsneemt, zodat verkeerd aangemaakte elementen kunnen worden aangeklikt in de tabel om te corrigeren (Bijlage 15). Door te klikken op een bepaald item, facet of concept in de overzichtstabel zou meteen het aanpassingsmenu voor dat bepaald element te zien zijn (cf. Questionnaires-menu) met de mogelijkheid te corrigeren. Op deze wijze zou de correctie van het model gelijktijdig gebeuren met de correctie van de variabelen. Door consistentie in de interface te behouden met betrekking tot de werking van bepaalde menu’s kan zowel de efficiëntie als de learnability van Survey Setup verhoogd worden. ·
Uploaden van een dataset
Tijdens het uploaden van de dataset werd steeds opnieuw één bepaalde stap overgeslagen, namelijk het ingeven van “New Survey Name”. Het ingeven ervan werd door de gebruikers als overbodig ervaren (Bijlage 16).
De oorzaak hiervan ligt in de gelijkenis van een eerder uitgevoerde taak, namelijk het aanmaken van een nieuw project. Daarin dient een naam ingegeven te worden voor de vragenlijst. Doordat gebruikers dachten dat opnieuw hetzelfde werd gevraagd in de taak “uploaden van de dataset”, werd het ingeven van een naam voor de dataset overgeslagen en als overbodig geacht. Respondenten bleken niet bewust te zijn van het feit dat in het upload-menu de naam voor het databestand gevraagd werd en niet de naam van de vragenlijst. Daarom opteren wij voor het gebruik van een duidelijkere labelling van het in te vullen veld ,in het dataset upload-menu, naar bijvoorbeeld van “Name Dataset”. Verder kan het verlies aan efficiëntie verholpen worden door beide menu’s “New Survey Name” en “Data Loading” op dit tijdstip van elkaar gescheiden in twee “tabbladen”- samen te brengen op één tabblad (Bijlage 17). Zo wordt zowel “New Survey Name” (menu voor naam van dataset in te geven) als de menu Data-loading” (Selectie en upload bestand) binnen dezelfde interface weergegeven.
Door bijkomend voor beide velden proactief aan te geven dat deze verplicht zijn in te vullen, zullen gebruikers meteen ingelicht zijn dat beide invulvelden moeten worden ingevuld zodat onnodige herhaling van acties kan worden vermeden. Dit kan bijvoorbeeld door naast het invulveld het bijschrift “Obligatory field” te vermelden (Bijlage 18).
93
8.2
Survey Analyzer
8.2.1
Efficiëntie, Learnability en Subjectieve Satisfactie
Ook in dit deel van de Dorbotsapplicatie werd een lage efficiëntie vastgesteld wat een negatieve impact lijkt te hebben op de learnability-score. De efficiëntiefouten werden als irritant aangeduid in de dimensies subjectieve bevrediging . ·
Opzoeken van een vragenlijst
Alle betrokken deelnemers vergaten de data te selecteren, omdat het bijschrift in het hoofdmenu niet de aandacht schijnt te trekken. In dit bijschrift werden gebruikers aangemoedigd om vooreerst data te selecteren, alvorens te starten met de analyse. Om dit te voorkomen kan gekozen worden om het bijschrift groter en meer kleurrijk te maken om de aandacht te vestigen.
Een andere en verder gaande oplossing bestaat erin dat gebruikers eerst het dataselectie-menu te zien krijgen na het klikken op “Survey Aanalyze”. Eens de data geselecteerd kunnen de gebruikers doorgaan naar het hoofdmenu. Zij worden dan verplicht deze stap eerst uit te voeren vooraleer te analyseren. Een duidelijk bijkomend opvallend opschrift zoals “Select your data to analyze” bijvoegen in het dataselectie-menu teneinde gebruikers duidelijk te maken dat deze stap absoluut nodig is om verder te gaan met analyse van juiste data, zou ook een bijdrage uitmaken (Bijlage 19). ·
Vinden van een tabel en grafieken van gemiddelden en frequenties
Gebruikers hadden moeilijkheden met het vinden van tabellen of grafieken van gemiddelden en frequenties. De opdeling van de means-submenu’s tussen “Lists” en “Frequencies” werd als verwarrend ervaren. Ook de opdeling van de submenu’s “Frequencty Tables” en “Questions” onder “Lists” en “Frequencies” bleek onlogisch te zijn volgens de betrokken respondenten. Bijkomend aan deze laatste vaststelling, werd de weinig zeggende labelling van “Questions” aangeduid als een deel van het probleem.
De aandacht van een gebruiker met een minimum aan statistische ervaring zal zich, bij het zoeken naar gemiddelden, eerder laten leiden door de term “Means” dan door “Lists”. Dit komt doordat de naam van de menu Means rechtstreeks weergeeft welke analyse de gebruiker kan verwachten onder dit menu. De betekenis van het label “Lists” blijkt onduidelijk te zijn voor respondenten.
94
Hetzelfde geldt voor het menu “Frequency Tables” en het menu ”Questions”. De plaats van “Frequency Tables” onder het “Lists” menu werd daartegenover als minder voor de handliggend beschouwd. Het menu “Questions”, waar de score van frequenties per vraag in grafieken kan worden waargenomen, bleek niet duidelijk gelabeld te zijn. Het label “Questions” houdt dan ook geen duidelijke verwijzing in naar welke analyse kan verwacht worden bij het aanklikken van dit menu (grafieken van frequenties). Vandaar opteren wij voor een andere indeling en duidelijkere labelling van de menu’s van “Question Level”, net zoals dat reeds het geval is bij analyses op facet en concept level. De labels van de twee laatst genoemde menu’s geven weer welke analyse zij uitvoeren. Gebruikers weten dan wat zij mogen verwachten bij het selecteren van één van deze analyses of functies (Bijlage 20). Wij stellen voor om de volgende belangrijke menu’s onder te verdelen in het Question -Level menu: Means, Frequencies, Drill Down en Open Questions. Onder Means en Frequencies zouden dan twee submenu’s kunnen worden opgeklapt; Diagrams en Tables. De naam van de menu’s krijgen dan voor gebruikers een meer relevante labelling en opdeling (Bijlage 21). ·
Verdeling van het sample raadplegen
Er werd een hoge hulpfrequentie vastgesteld voor het raadplegen van het sample. Dit werd veroorzaakt door de eerder niet logische tussenstap die bekomen wordt na het klikken van “Sample Results”, “Frequencies”. Gebruikers vonden deze tussenmenu onnodig en het label enigszins verwarrend. Het gebruik van het label “Frequencies”, net zoals in het “Question level”-menu, maakte gebruikers onzeker in het uitvoeren van de taak. De tussenstap brengt geen meerwaarde aan de usability en gebruikers lijken het belangrijker te vinden dat functies en menu’s meteen vertellen voor welke analyse ze dienen. Wij stellen daarom voor om het tussenmenu, “Frequencies”, te verwijderen. Op deze wijze zien gebruikers meteen beide submenu’s “total sample en “valid responses” en wordt verwarring vermeden (Bijlage 22).
8.2.2 ·
Error Tolerantie
Opzoeken van een kruistabel voor 2 items
Twee gebruikers interpreteerden de kruistabel verkeerd. Eén van de respondenten gaf kritiek op de onduidelijkheid van de legende omwille van het gebruik van teveel kleuren. Het toepassen van geel 95
voor invalide elementen, bijkomend aan de aanwending van vier verschillende andere kleuren voor het aangeven van significante resultaten in de kruistabel, zorgden voor verwarring (Bijlage 23).
Wij opteren voor een aanpassing/verandering van de kleur in de legendevoor de invalide elementen, hetzij door gebruik van een sober kleur, hetzij door de niet-valide elementen in de tabel aan te duiden met een pictogram met negatieve connotatie. ·
Verandering van de kleur van de Ranking-meter:
Eén gebruiker slaagde er niet in om het menu te vinden waarin de Ranking-diagram kan veranderd worden van kleur (Bijlage 7). Om het terugvinden van deze functionaliteit te bevorderen stellen wij voor een zichtbaar menu te ontwikkelen in de interface, door middel van een “change diagram color”button toe te voegen aan de interface (Bijlage 24). Door op deze functie te klikken kan dan het kleurenpalet geopend worden met een kleurkeuze van het diagram. Het voordeel is dat de gebruiker geïnformeerd is over het aanwezig zijn van deze functionaliteit en kan hij deze gemakkelijk terugvinden. ·
Impact Diagram van concepten
Twee gebruikers rapporteerden dat zij zich vergist hadden in het aflezen van het diagram als gevolg van het ontbreken van informatie in de tabel. Het diagram geeft de grafische relatie tussen impact en score voor elk concept, terwijl de tabel enkel de impact weergeeft, dit terwijl de tabel een belangrijk hulpmiddel blijkt te zijn voor gebruikers bij de interpretatie van het diagram.
Een weergave van zowel de impact als de score voor elk concept in de tabel zal het overzicht vervolledigen ten behoeve van de interpretatie. De gebruikers krijgen de keuze tussen beide complementaire weergaven van resultaten en kunnen de tabel als een volwaardig hulpmiddel aanwenden voor de interpretatie van het regressiediagram. ·
Het verdere ontwikkelingsproces van de Drobotsapplicatie
We hebben in dit rapport aangegeven hoe usability-evaluatie kan worden uitgevoerd aan de hand van een passend usability-evaluatiemodel. We hebben eveneens verwezen naar het iteratief UCD ontwikkelingsproces, waarin een usability-evaluatie op een repetitieve manier wordt uitgevoerd doorheen de ontwikkeling van een software. Aangezien het evaluatieproces van de Drobotsapplicatie tot op heden bestond uit het uitvoeren van tevredenheidenquêtes bestaat deze laatste aanbeveling uit het opnemen van iteratieve usability-evaluaties aan de hand van het UCD zodat de verdere ontwikkeling van Drobots meer gericht kan verlopen naar de noden van gebruikers toe.
96
Wij opteren ervoor deze tevredenheidsevaluatie aan de hand van enquêtes blijvend aan te wenden en verder aan te vullen met een iteratief usability-evaluatieproces. Door op een systematische wijze usability-evaluaties, - die usability-noden blootleggen - te combineren met tevredenheidsvragenlijsten, waardoor de algemene noden van gebruikers waargenomen worden, kan informatie verzameld worden voor de nodige aanpassingen. Iteratie van aanpassingen in Drobots en evaluatie op grond van de vijf gedefinieerde usability-dimensies kan dan zorgen voor gerichte aanpassingen naar de behoeften van de huidige doelgroep en prospecten. De resultaten van het hier besproken onderzoek kunnen ingepast worden als een “benchmarkstandaard” voor verder usability-evaluatie van nieuwe, innovatieve functies en geïmplementeerde aanpassingen.
97
Bibliografie ·
Internetbronnen:
Drobots.com (2010, 22 oktober). Knowledge Center: Drobots versus other survey analyses software. Geraadpleegd op 8 mei 2011 op het World Wide Web: http://www.drobots.com/KnowledgeCenter/ArticleId/10/Drobots-versus-other-survey-analysis-software Interdisciplinaier Instituut voor Breedband en Technologie (n.d.). Ondernemerschap: portfolio companies:
kpiware.
Geraadpleeg
op
4
mei
2011
op
het
World
Wide
Web:
http://www.ibbt.be/nl/ondernemerschap/portfolio-companies/kpiware International Organization for Standardization (n.d.). About us: How does ISO develop Standards?. Geraadpleegd
op
5
januari
2012
op
het
World
Wide
Web:
http://www.iso.org/iso/home/standards_development.htm ·
Wetenschappelijke artikels:
Abran, A., Khelifi, A. & Suryn, W. (2003). Usability meanings and interpretations in ISO standards. Software Quality Journal, 11(4), 323-336. Abras, C., Maloney-Krichmar, D. & Preece, J. (2004). User centered Design. Berkshire Encyclopedia of Human-Computer Interaction, 2(n.d.), pp. 763-767. Bevan, N. (1995). Measuring usability as quality of use. Software Quality Journal, 4(2), 115-150. Bevan, N. and Macleod, M. (1994) Usability measurement in context. Behaviour and Information Technology, 13(1-2), 132-145. Bevan, N. (2009). International standards for usability should be more widely used. Journal of usability studies, 4(3), 106-113. Bevan, N. (1999). Quality in use: meeting user needs for quality. Journal of System and Software, 49(1), pp. 89-96. Bevan, N. (2002). International standards for HCI and usability. International Journal of HumanComputer Studies, 55(4), 533-552. Behkamal, B., Kahani, M. & Akbari, M.K. (2009). Customizing ISO 9126 quality model for evaluation of B2B applications. Information and Software Technology, 51(3), pp. 599-509.
Boehm, B.W (1987). Improving Software Productivity, IEEE Computer, 20(9),. 43-57. Bhoem, B. & Bassil, V. (2001). Software Defect Reduction Top 10 List,” IEEE Computer, 34(1), 135137. Faulker, J. (2003). Beyond the five user assumption: Benefits of increased sample sizes in usability testing. Behavior Research Methods, Instruments and Computers, 35(3), 379-383. Flavian, C., Guialiu, M. & Gurrea, R. (2005). The role played by perceived usability, satisfaction and consumer trust on website loyalty. Information an management, 43(1), 1-14. Fjermestad, J. & Romano, N.C. (2003). Electronic customer relationship management: revisiting the general principles of usability and resistance – an integrative implementation framework. Business Process Management Journal, 9(5), 572 – 591. Georgiadou, E. (2003). Software process and product improvement: a historical perspective. Cybernetics and systems Analysis, 39(1). 125-142. Gulliksen, J., Goransson, B., Boivie, I., Blomkvist, S. Persson, J.& Cajander, A. (2003). Key principles for user-centered system design. Behaviour & Information Technology, 22(6), 397–409. ISO 9241-11 (1998). Ergonomic requirements for office work with visual display terminals (VDTs), Part 11: Guidance on usability. Geneva, Switzerland: International Standards. ISO 9126 (1991). Software product evaluation - quality characteristics and guidelines for their use. Geneva, Switzerland: International Standards Organization. ISO 9126-1 (2001). Software engineering – product quality, Part 1: Quality model. Geneva, Switzerland: International Standards Organization. Jeng, J. (2005). Usability assessment of academic digital libraries : effectiveness, efficiency, satisfaction and learnability. International journal of libraries and information services, 55(2-3), 96121. Jung, H.W., Kim, S.G. & Chung, C.S. (2004). Measuring software product quality: a survey of ISO/IEC 9126. Software IEEE, 21(5), pp. 88-92.
Maguire, M. (2001a). Context of use within usability activities. International Journal HumanComputer Studies, 55(4). 453-483.
Maguire, M. (2001b). Methods to support human-centred design. International Journal Human Computer Studies, 55(4) , 587-634. Mao, J., Vredenburg, K., Smith, P.W. & Carey, T. (2005). The state of user-centered design practice. Communications of the ACM, 48(3), 105-109. Nielsen, J. & Levy, J. (1994). Measuring usability: preference vs. performance. Communications of the ACM, 37(4), pp. 66-75. Ovaska, S. (1999, Augustus). Usability as a goal for the design of computer systems Scandinavian Journal of Information Systems, 3, pp. 47-62. Quesenbery, W. (2004). Balancing the 5 E’s : usability. Cutter IT journal, 17(2), 281-289. Seffah, A., Donyaee, M., Kline, R.B. & Padda, K.H. (2006). Usability measurement and metrics : a consolidated model. Software Quality Journal, 14(2). 159-178. Van Den Haak, M.J., De Jong, M.D.T. & Schellens, P.J. (2003). Retrospective vs. concurrent thinkaloud protocols: testing the usability of an online library catalogue. Behaviour & Information Technology, 22(5), 339–351. Virzi, R.A. (1992). Refining the test phase of usability evaluation: how many subjects is enough? Human Factors, 34(4), 457-468.
Boeken en reader(s) Agarwal, B.B. & Tayal, S.P. (2007). Software Engineering (1st Ed.) New Dehli: Laxmi Publications (P) LTD. Chung, L. & Leite, J.C.P. (2009). On Non-Functional Requirements in Software Engineering. In A.T. Borgida, V.K. Chaudhri & P. Giorgini. (Eds.), Conceptual Modeling: Foundations and Applications (pp. 363-379). Heidelberg: Springer-Verlag Berlin. De Almeida, H.O., Silva, L., Ferreira, G., Loureiro, E. & Perkusich (2007). A.Verification, validation of software sustems using virtual reality and coloured petri nets. In A. Dasso & A. Funnes Eds.). Verification, Validation And Testing in Software Engineering (pp. 24-46). United Kingdom, UK: Idea Group Publishing.
Dix, A., Finlay, J., Abowd, G.D. & Beale, R. (2004). Human-computer interaction. Edinburgh Gate : Pearson Education Limited. Dumas, J.S. & Redish, J. (1999). A practical guide to usability testing (Revised Ed.). Exeter: Intellect Books. Dumas, J.S. (2003). User based evaluations. In J.A. Jacko & A. Sears (Eds.), The Human-Computer Interaction Handbook: Fundamentals, Evolving Technologies and emerging Applications (pp. 10931117 ). Mahwah: Lawrence Elbaum Associates. Galitz, W.O. (2007). The Essential Guide to User Interface Design: An Introduction to GUI Design principles and techniques (3th ed.). Indianapolis: Wiley Publishing Inc. Gamberini, L. & Valentini, E. (2003). Web Usability Today: Theories, Approach and Methods. In G. Riva & C. Galimberti (Eds.), Towards CyberPsychology: Mind, Cognitions and Society in the Internet Age (pp. 110-126). Amsterdam, IOS Press, Graham, D., Van Veenendaal, E., Evans, I. & Black, R. (2008). Foundations of Software Testing: ISTQB Certification. London: Cengage Learning EMEA. Guillemette, R.A. (1995). The evaluation of usability in interactive information systems. In J.M. Carey (Ed.), Human Factors in Information Systems: Emerging Theoretical Bases (pp. 207-222). New Jersey: Ablex Publishing Corporation. Hambling, B., Morgan, P., Samaroo, A., Thompson, G. &Williams, P. (2010). Software testing: an ISTQB-ISEB foundation guide (2nd Ed.). Chippenham: British Informatics Society Limited. James, K. L. (2009). Software ingineering. New Delhi: PHI, Learning Private Limited. Meyers, G.J., Badgett, T. & Sandler, C. (2012). The art of software testing (3th ed.). New Jersey: John Wiley & Sons. Nemeth, C.P. (2004). Human Factors Methods for Design: Making Systems Human-Centered. Florida, Boca Raton; CRC Press. Nielsen, J. (1993). Usability engineering. Londen: Acadamic Press. Norlin, E. 1 Winters, C.M. (2002). Usability Testing for Library Web Sites: A Hands-on Guide. Washington D.C.: American Library Association.
Quesenbery, W. (2008). The five dimensions of usability. In M.J. Alberts & B. Mazur (Eds.), Content and complexity: information design in technical communication (pp. 75-94). Mahwah: Lawrence Elbaum Associates. Rubin, J. & Chisnell, D. (2008). Handbook of usability testing: how to plan, design and conduct effective test (2nd Ed.). Indianapolis: Wiley Publishing Inc. Sarmento, A. (2005). Issues of human computer interaction. United States of America: IRM Press. Shackel, B. (1991). Usability- context, framework, definition, design and evaluation. In B. Shackel. & S. Richardson (Eds.), Human factors for informatics usability (pp. 1-21). Cambridge: Press Syndicate of the University of Cambridge. Takanen, A., Demott, J. D. & Miller, C. (2008). Fuzzing for software security testing and quality assurance. Norwood: Artech House. Westfall, L. (2009). The certified software quality engineer handbook. Milwaukee: Quality Press. ·
Niet-gepubliceerde congresbijdragen:
Tullis, T., Fleischman, S., McNulty, M., Cianchette, C., & Bergel, M. (2002). An empirical comparison of lab and remote usability testing of Web sites. Paper gepresenteerd in proceedings of Usability Professionals Association Conference. ·
Gepubliceerde congresbijdragen:
Abran, A., Khelefi, A., Suryn, W. & Seffah, .A (2003). Consolidating the ISO usablity models. In submitted to the 11th International Software Quality Management Conference and the 8th Annual INSPIRE Conferenc (23-25 april). Glasgow: Springer. Bevan, N. & Azuma, M. (1997). Quality in use: incorporating human factors into the software engineering lifecycle. Proceedings of the Third International Symposium and Forum on Software Engineering Standards ISESS'97 (pp. 169 - 179). Washington D.C.: IEEE Computer Society Bevan, N. & Curson, I (1999). Planning and implementing user-centred design. Extended abstracts on Human factors in computing systems CHI '1999 (pp. 137-138). New York, NY: ACM Press. Ebling, M.R. & John, E.B. (2000). On the contributions of different empirical data in usability testing. Proceedings of the 3rd conference on Designing interactive systems: processes, practices, methods, and techniques DIS 2000 (pp. 289-296). New York, NY: ACM Press.
Engstrom, E. & Runeson, P. (2010). A Quantitative Survey of Regression Testing Practices. Proceedings 11th International Conference of Software Process Improvement PROFES 2010 (pp. 316). Berlin: Springer Verlag. Frokjear, E., Hertzum, M. & Hornbaek, K. (2000). Measuring usability: are effectiveness, efficiency, and satisfaction really correlated? Proceedings of the SIGCHI conference on Human factors in computing systems CHI’00 (pp. 345-352). New York, NY: ACM Press. Nielsen, J., Clemmensen, T. & Yssing, C. (2002). Getting access to what goes on in people's heads?: reflections on the think-aloud technique. Proceedings of the second Nordic conference on Humancomputer interaction NORDCHI’02 (pp. 101-110). New York, NY: ACM. Yokela, T., Iivari, N., Matero, J. & Karukka, M. (2003). The standard of user-centered design and the standard definition of usability: analyzing ISO 13407 against ISO 9241-11. Proceedings of the Latin American conference on Human-computer interaction CLIHC ’03 (pp. 53-60). New York, NY: ACM Press.
Bijlagen Bijlage 1:
Error tolerantie Survey Setup: Aantal fouten per taak en type
Bijlage 2:
Efficiëntie Survey Setup: Percentage participanten die geen fouten maakten van het type (2) en (3)
Bijlage 3 :
Efficiëntie Survey Setup: Percentage van hulpfrequentie
Bijlage 4:
Error tolerantie Survey Analyzer: aantal fouten per taak en type.
Bijlage 5:
Screenshot Drobots: Survey Analyzer: Taak 11: Impact Diagram
Bijlage 6:
Screenshot Drobots: Survey Analyzer: Taak 7: Kruistabel
Bijlage 7:
Screenshot Drobots: Survey Analyzer: Taak 10: Verandering van kleur van Rankingdiagram
Bijlage 8:
Screenshot Drobots: Survey Setup: Taak 1: Login
Bijlage 9:
Screenshot Drobots: Survey Setup: Taak 3: Variabelen ingeven (Questionnaires): Overzichtstabel
Bijlage 10:
Screenshot Drobots: Survey Setup: Taak 3: Benoemen van variabelen (Questionnaires) - Toevoegen van overzichtstabel
Bijlage 11:
Screenshot Drobots: Survey Setup: Andere labelling en volgorde van invulvelden antwoordcategorie
Bijlage 12:
Screenshot Drobots: Survey Setup: Toevoegen van edit-menu voor aanpassing van antwoordcategorie (Questionnaires)
Bijlage 13:
Screenshot Drobots: Survey Setup: Toevoegen van wizard-menu in het aanmaken van modellen (Model)
Bijlage 14:
Screenshot Drobots: Survey Setup: Stappen voor correctie van modelelementen
Bijlage 15:
Screenshot Drobots: Survey Setup: Implementeren van aanpassingsmenu in modeloverzicht
Bijlage 16:
Screenshot Drobots: Survey Setup: Ingave questionnaire name
Bijlage 17:
Screenshot Drobots: Survey Setup: Data upload opgesplitst in twee tabbladen
Bijlage 18:
Screenshot Drobots: Survey Setup: Data upload in één tabblad met verplichte invulvelden
Bijlage 19:
Screenshot Drobots: Survey Analyzer: Data selectie als eerste interface van Survey Analyzer
Bijlage 20:
Screenshot Drobots: Survey Analyzer: Menu’s concept level die weergeven voor welke analyses ze staan
Bijlage 21:
Screenshot Drobots: Survey Analyzer: Duidelijker labelling voor menu’s op Question level
Bijlage 22:
Screenshot Drobots: Survey Analyzer: Verdeling van een sample raadpleging (Sample Results)
Bijlage 23:
Screenshot Drobots: Survey Analyzer: Kleurenlegende voor kruistabel
Bijlage 24:
Screenshot Drobots: Survey Analyzer: Toevoegen van Change Diagram Color-menu
Bijlage 25:
Gestructureerde takenlijst en bijhorende acties
Bijlage 26:
Pre-test vragenlijst
Bijlage 27:
Post- test vragenlijst: Survey Setup
Bijlage 28:
Post-test vragenlijst: Survey Analyzer
Bijlage 1
Error tolerantie Survey Setup: Aantal fouten per taak en type
Aantal fouten per taak en type Tasks: Survey Setup Website
en
toegangspoort
naar
Type 1
Type 2
Type 3
Type 4
de
1
Drobotsapplicatie vinden
3
0
-
-
2
Ingeven van projectnaam
-
1
0
-
3
Variabelen ingeven
-
11
0
-
4
Waarden voor variabelen ingeven
-
9
4
-
5
Corrigeer fout in labels
-
-
0
-
Corrigeer
foute
waarden
6
(antwoordcategorieën)
-
-
7
-
7
Facetten aanmaken + aan facetten binden
-
-
3
-
-
-
1
-
-
-
1
-
-
-
2
-
-
-
6
-
-
4
4
-
Totaal
3
25
28
-
Percentages
6%
44%
50%
-
Concepten aanmaken en aan facetten 8
binden Concepten binden aan topic en aanmaken
9
van topic
10 Controleren van "Model" Corrigeren van fout ingegeven concepten, 11 facetten en links ertussen Invoeren
van
een
surveynaam
en
12 selecteren van het databestand in kwestie
Bijlage 2
Efficiëntie Survey Setup: Percentage participanten die geen fouten maakten van het type (2) en (3)
% die
participanten geen
maakten
fouten van
Tasks: Survey Analyser
type (2) en (3)
1
Vragenlijst opzoeken
0%
2
Meetmodel opzoeken
87,50%
3
Verdeling total sample nagaan
87,50%
4
Missing data aanduiden
100%
5
Gemiddeldes opzoeken van items
12,5%
6
Grafische gegeven score opzoeken voor 1 item
25%
7
Kijken met vergrootglas naar leeftijd van zeer ontevredenen van vraag "x"
87,50%
8
Opzoeken van een kruistabel voor 2 items
75%
9
Ranking van concepten
75%
10 Verander kleur van Ranking-thermometer
87,50%
11 Impact Diagram van concepten
75,00%
12 Gebruik van Vergelijkingsanalyses o.b.v. splitvariabele leeftijd
100%
het
Bijlage 3
Efficiëntie Survey Setup: Percentage van hulpfrequentie
% participanten die geen hulp Tasks: Survey Analyser
vroegen
1
Vragenlijst opzoeken
37,50%
2
Meetmodel opzoeken
87,50%
3
Verdeling total sample nagaan
62,50%
4
Missing data aanduiden
100%
5
Gemiddeldes opzoeken van items
12,50%
6
Grafische gegeven score opzoeken voor 1 item
50%
7
Kijken met vergrootglas naar leeftijd van zeer ontevredenen van vraag "x"
75,00%
8
Opzoeken van een kruistabel voor 2 items
87,50%
9
Ranking van concepten
75%
10 Verander kleur van Ranking-thermometer
75%
11 Impact Diagram van concepten
75%
12 Gebruik van Vergelijkingsanalyses o.b.v. splitvariabele leeftijd
100%
Bijlage 4
Error tolerantie Survey Analyzer: aantal fouten per taak en type.
Aantal fouten per taak en type Type 1
Type 2
Type 3
Type 4
Taks: Survey Analyzer
-
-
16
-
1
Vragenlijst opzoeken
-
-
1
-
2
Meetmodel opzoeken
-
-
1
-
3
Verdeling Total monster nagaan
-
-
-
-
4
Missing data aanduiden
2
-
8
-
5
Gemiddeldes opzoeken van onderwerpen
1
-
5
-
-
-
1
-
-
-
-
2
Grafische gegeven score opzoeken voor 1 6
onderwerp Kijken met vergrootglas naar leeftijd van
7
zeer ontevredenen van vraag "x" Opzoeken van een kruistabel voor 2
8
onderwerpen
-
-
2
-
9
Banking van concepten
1
-
-
-
10 Verander kleur van Banking thermometer 2
-
1
-
11 Impact Diagram van concepten
0
-
-
-
-
-
-
-
Totaal
6
-
35
2
Percentages
14%
-
81%
5%
Gebruik van Vergelijkingsanalyses o.b.v. 12 splitvariabele leeftijd
Bijlage 5
Screenshot Drobots: Survey Analyzer: Taak 11: Impact Diagram
Bijlage 6
Screenshot Drobots: Survey Analyzer: Taak 7: Kruistabel
Bijlage 7
Screenshot Drobots: Survey Analyzer: Taak 10: Verandering van kleur van Ranking-diagram
Bijlage 8
Screenshot Drobots: Survey Setup: Taak 1: Login
Bijlage 9
Screenshot
Drobots:
Overzichtstabel
Survey
Setup:
Taak
3:
Variabelen
ingeven
(Questionnaires):
Bijlage 10 Screenshot Drobots: Survey Setup: Taak 3: Benoemen van variabelen (Questionnaires) – Toevoegen van overzichtstabel
Bijlage 11
Screenshot Drobots: antwoordcategorie
Survey
Setup: Andere labelling en volgorde van
invulvelden
Bijlage 12
Screenshot Drobots: Survey Setup: Toevoegen van edit-menu voor aanpassing van antwoordcategorie (Questionnaires)
Bijlage 13
Screenshot Drobots: Survey Setup: Toevoegen van wizard-menu in het aanmaken van modellen (Model)
Bijlage 14
Screenshot Drobots: Survey Setup: Stappen voor correctie van modelelementen
Bijlage 15
Screenshot Drobots: Survey Setup: Implementeren van aanpassingsmenu in modeloverzicht
Bijlage 16
Screenshot Drobots: Survey Setup: Ingave questionnaire name
Bijlage 17
Screenshot Drobots: Survey Setup: Data upload opgesplitst in twee tabbladen
Bijlage 18
Screenshot Drobots: Survey Setup: Data upload in één tabblad met verplichte invulvelden
Bijlage 19
Screenshot Drobots: Survey Analyzer: Data selectie als eerste interface van Survey Analyzer
Bijlage 20
Screenshot Drobots: Survey Analyzer: Menu’s concept level die weergeven voor welke analyses ze staan
Bijlage 21
Screenshot Drobots: Survey Analyzer: Duidelijker labelling voor menu’s op Question level
Bijlage 22
Screenshot Drobots: Survey Analyzer: Verdeling van een sample raadpleging (Sample Results)
Bijlage 23
Screenshot Drobots: Survey Analyzer: Kleurenlegende voor kruistabel
Bijlage 24
Screenshot Drobots: Survey Analyzer: Toevoegen van Change Diagram Color-menu
Bijlage 25
Gestructureerde takenlijst en bijhorende acties
Performance Measure Table Opdrachten
Taak
1. Inloggen
a) Website en toegangspoort naar de Drobotsapplicatie vinden
Bijhorende acties
J F T
H
naar site van Drobots gaan vinden en klikken op application login ingeven van gebruikersnaam en paswoord klikken op “login” 2. Survey Setup
a) Ingeven van projectnaam klik op “Survey Setup” klik op “Project” klik op “New Project” geef naam in “Project Name”, “Questionnaire Name” en selecteer “taal” klik op "Submit" b1) Variabelen ingeven Fout insteken CHEF44
klik op “Questionnaire” klik op “New” vul de naam in van de variabele (identiek zoals in dataset) in “Question code” vul de bijhorende vraag in “question phrase” vul de bijhorende “question tupe” in klik op “New Awnser Categorie”/selecteer een reeds aangemaakte antwoordcategorie
b2) Waarden voor variabelen ingeven Verkeerde waarde bij leeftijd 64+ vul gepaste naam in “Answer Category Code” vul juiste naam in “Answer Value” klik op “submit” klik op “New” vul juiste naam in “Answer Value” voor 2de, 3de, 4de en 5de waarde klik op “Finish” klik op "Submit"in het kader van variabelen c1) corrigeer fout in labels selecteer de variabele die je wil aanpassen in Fout insteken CHEF44 "List View" klik op "Edit" geef de juiste naam in "question code" klik op "Submit" en controleer c2) corrigeer foute waarden (antwoordcategorien) selecteer de antwoordcategorie die je wil Verkeerde waarde bij leeftijd 64+ aanpassen bij "List View" klik de waarde aan die moet aangepast worden of doe dit via pijltjesmenu klik op "Edit" pas aan klik op "Submit" klik op "Finish" d1) facetten aanmaken + aan facetten binden Verkeerd Facet laten aanmaken COMMTMENT klik op “Model” klik op het menu “Question to Facet” maak gepast facet aan door op “New Facet” te kllikken geef technische naam in “Facet Code” en naam voor in resultaten weer in “Facet Name” klik op “Submit” verbind het net aangemaakte facet met de juiste vragen klik op “Clear”
Tijd
S/P
d2) concepten aanmaken en aan facetten binden klik op het menu “Facet to Concept” klik op “New Concept” geef technische naam in “Concept Code” en naam voor in resultaten weer in “Concept Name” klik op “Submit” verbind het net aangemaakte concept met de juiste facetten klik op “Clear” d3) concepten binden aan topic en aanmaken van topic klik op het menu “Topic” klik op “New Topic” geef technische naam in “Topic Code” en naam in “Topic Name” klik op “Submit” verbind het net aangemaakte concept met de juiste concepten klik op “Clear” d4) aanklikken van "Model" om te controleren klik op Model controleer en interpreteer
3. "Survey Setup"
e) Corrigeren van fout ingegeven concepten, facetten en links ertussen Verkeerd Facet laten aanmaken COMMTMENT Klik op "Question to facet" klik op "edit" pas aan "Submit" f) Invoeren van een surveynaam en selecteren van het databestand in kwestie klik op “Data Load” klik op “New Survey” en voer naam in klik op “Submit” klik op “Data Loading” selecteer bestand klik op “Upload” kijk of alles ok is geupload a1) Vragenlijst opzoeken klik op “Dataselection” selecteer het juiste “Project”iconen maak gebruik van efficiënte "Info"/omtoer klik op het “vraagtekenicoontje” kijk welke antwoordmogelijkheden de splitvariabele "leeftijd" heeft a2) Meetmodel opzoeken scroll naar onder en klik op het icoon "piramide" / klik bovenaan op "Info" controleer de structuur b) Verdeling total sample nagaan klik op efficiënte iconen bovenaan aan pagina “Sample Results”/ omtoer klik op “Frequencies” klik op Total Sample” selecteer “age” als splitvariabele interpreteer b2) Missing data? menu op “Total Sample”/klikken op “Valid Responses” selecteren van “age” als splitvariabele c1) Gemiddeldes opzoeken van items en kijken bij welk facet/concept ze behoren klik via de efficiënte knoppen op het icoon 7,11 Q18: (ORG) van“Question level” / Ga via omweg klik op “Lists”c klik op “All Means” kijk in tabel
c2) Grafische gegeven score opzoeken voor 1 item Weinig akkoord klik op “Frequencies” klik op “Questions” selecteer het concept, het facet en de vraag interpreteer c3) Kijken met vergrootglas naar leeftijd van zeer ontevredenen van vraag "x" klik op “Drill Down” selecteer concept, facet, vraag, item, “antwoordcategorie helemaal ontevreden” en splitvariabele leeftijd interpreteer c4) Opzoeken van een kruistabel voor 2 items klik op “Cross Tables” selecteer "rij en kolomvariabele" interpreteer d1) Ranking van concepten klik op “Concept level” via efficiente knoppen /via “Survey Analyzer” klik op “Ranking” interpreteer d2) Verander kleur van Ranking thermometer klik op afbeelding met rechter muisknop stel 1ste kleur in als groen en 2de als rood sluiten van kader d3) Impact Diagram van concepten Commitment klik op “Impact Diagram” klik op “Regressie analyses” interpreteer d4) Gebruik van Vergelijkingsanalyses obv splitvariabele leeftijd klik op “Group Comparison” selecteer de splitvariabele “age” interpreteer Globale Tevredenheid
Bijlage 26
Pre-test vragenlijst Geslacht? M / V
Hoeveel tijd heeft u geoefend met het Drobotsprogramma? a) >1u b) 1u-2u c) 3u< Hoeveel ervaring heeft u met statistiek 1
2
3
4
Veel ervaring
5 weinig ervaring
Uw ervaring met andere (dan Drobots) statistische verwerkingsprogramma’s 1
2
Veel ervaring
3
4
5 weinig ervaring
Jaren ervaring in statistiek? …………………………………………………………………………………………………………… ……………………………………………………………………………………………………………
Wat is uw hoogst behaald diploma? …………………………………………………………………………………………………………… ……………………………………………………………………………………………………………
Wat is uw leeftijd? ……………………………………………………………………………………………………………
Bijlage 27
Post-test vragenlijst: Survey Setup Welk van de elementen of functies van het programma in de net overlopen oefening vond u moeilijk te gebruiken? Rangschik de elementen van moeilijk naar gemakkelijk en motiveer en leg uit wat u daar specifiek zo moeilijk aan vond: -Project -Variabelen
benoemen en
waarden
-Meetmodel
labelen invoeren
-Data uploaden Commentaar: …………………………………………………………………………………………………………… …………………………………………………………………………………………………………… …………………………………………………………………………………………………………… Welke elementen van het programma zou u zeker willen veranderd zien? -Project -Variabelen
benoemen en
waarden
-Meetmodel
labelen invoeren
-Data uploaden Commentaar: …………………………………………………………………………………………………………… …………………………………………………………………………………………………………… …………………………………………………………………………………………………………… Welke elementen van het programma zou u zeker niet willen veranderd zien? -Project -Variabelen -Meetmodel
benoemen en
waarden
labelen invoeren
-Data uploaden Commentaar: …………………………………………………………………………………………………………… …………………………………………………………………………………………………………… …………………………………………………………………………………………………………… ……………………………………………………………………………………………………………
Ik vind dat het inloggen in de Drobotsapplicatie gemakkelijke is in gebruik
1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… De toegang van de Drobots login-applicatie is gemakkelijk terug te vinden op de site
1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… Ik vind de flow van de in te geven gegevens in de data upload logisch; Maw de achtereenvolgende acties van 1) een projectnaam ingeven, 2) variabelen en waarden labelen, 3) meetmodel invoeren en tenslotte 4) excelbestand uploaden zijn logisch en gemakkelijk te gebruiken
1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… Ik vind het invullen van de projectnaam bij het menu “Project” gemakkelijk in gebruik is
1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… ……………………………………………………………………………………………………
Het menu “Questionnaire” om variabelen en waarden aan te maken en te labellen is gemakkelijk te gebruiken mbt het aanmaken en labelen van variabelen en waarden in
1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… ……………………………………………………………………………………………………
Het corrigeren van labels van fout ingevoerde variabelen en waarden kan op een gemakkelijk manier
1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… De organisatie van het menu “Questionnaire” om variabelen aan te maken en te labelen maakt efficiënte
1
ingave
2
van
3
de
4
variabelen
mogelijk
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… ……………………………………………………………………………………………………
De structuur van het menu om waarden aan te maken en te labelen maakt efficiënte ingave van de waarden mogelijk 1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… Het aanmaken van facetten en concepten in het menu “Model” (ingeven van het datamodel) vond ik gemakkelijk te gebruiken
1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… Het corrigeren van facetten en concepten vond ik gemakkelijk te gebruiken
1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… De organisatie in het menu “Model”, dat dient om het meetmodel in te geven, maakt efficiënte ingave van de facetten en concepten mogelijk
1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… ……………………………………………………………………………………………………
Ik vond het makkelijk om het ingegeven meetmodel te controleren
1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… Het selecteren en uploaden van de dataset zelf (excelbestand) verloopt vlot en gemakkelijk
1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… De organisatie en structuur van de menu’s maakt efficiënt navigeren mogelijk
1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… Het onderscheid tss menu en submenu is duidelijk
1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… ……………………………………………………………………………………………………
De namen (labels) van de menu’s en submenu’s maakten mij meteen duidelijk waar ze voor dienen
1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… ……………………………………………………………………………………………………
Ik vond het meteen duidelijk wat men vroeg in te vullen in de selectiekaders
1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… Ik vond het meteen duidelijk wat men vroeg in te vullen in een leegstaand veld 1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… Men gebruikt verstaanbare namen en terminologie zodat ik als gebruiker telkens weet wat ik kan verwachten bij het selecteren van een bepaald menu/functie
1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… ……………………………………………………………………………………………………
De functie van menu’s en selectiekaders zijn duidelijk en wijzen zichzelf uit (zelf-evident)
1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… ……………………………………………………………………………………………………
Bijlage 28
Post-test vragenlijst: Survey Analyzer Vragenlijst 2: “Survey Analyzer”: Welke functies vond u in “Survey Analyzer” moeilijk te gebruiken? …………………………………………………………………………………………………… …………………………………………………………………………………………………… ……………………………………………………………………………………………………
Welke functies of elementen van het programma zou u zeker veranderen? …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… Ik vond gemakkelijk mijn weg in het systeem en kon gemakkelijk de oefening oplossen 1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… In het uitvoeren van een oefening vond ik het gemakkelijk om bewerkingen uit te voeren 1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… Het databestand selecteren om dan analyses op te doen vind ik gemakkelijk in gebruik 1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… ……………………………………………………………………………………………………
Het analyse gedeelte is gemakkelijk te gebruiken en bewerkingen kunnen gemakkelijk uitgevoerd worden 1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… Het aanpassen van grafieken, schema’s en hun kleur zijn gemakkelijk in gebruik 1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… Als ik een analyse wil uitvoeren is voor mij meteen duidelijk welke menu’s ik moet aanklikken om het verwachte resultaat te krijgen 1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… De functie van menu’s en selectiekaders in het analysegedeelte (Sample Results, Question-, Facet- en Conceptlevel) zijn duidelijk en wijzen zichzelf uit 1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… ……………………………………………………………………………………………………
Men gebruikt verstaanbare labels en terminologie zodat ik als gebruiker telkens weet wat ik kan verwachten bij het selecteren van een bepaald menu/functie 1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… Ik vind de iconen, menu’s en hun bijhorende functie zijn duidelijk 1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… De positie van de iconen en hoofdmenu’s maken efficiënte navigatie en gebruik van de interface mogelijk 1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… De organisatie van de submenu’s maakt efficiënte navigatie en gebruik van de interface mogelijk 1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… ……………………………………………………………………………………………………
De volgorde van de in te vullen selectiekaders (zoals bij bvb. Drill Down), waarbij eerst het concept en facet dienen geselecteerd te worden en dan pas de vraag is logisch 1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… Graag hadden wij uw mening gehad over de volgende elementen die betrekking hebben op de het uiterlijk van de Interface van de Drobotapplicatie: De Drobotapllicatie is: a-Traditioneel 1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… b-Complex 1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… c-Saai 1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… ……………………………………………………………………………………………………
d- Onprofessioneel 1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… e-Donker 1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… f- Kleurloos 1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… g-Heeft een slechte lay out 1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… h-Andere opmerking over visuele aantrekkelijkheid: Commentaar: …………………………………………………………………………………………………… ……………………………………………………………………………………………………
afzonderlijke vragen: Algemeen ben ik zeer tevreden over de Drobotsapplicatie? 1
2
3
4
5
Helemaal
Helemaal
akkoord
niet akkoord
Commentaar: …………………………………………………………………………………………………… …………………………………………………………………………………………………… ……………………………………………………………………………………………………
