Slides tweede thesispresentatie

Advertenties

DP1: Resultaten & conclusies

5) Wie, Wanneer?

Deze evaluatie werd uitgevoerd met 12 computerwetenschappers (n=12), waaronder acht mannen en vier vrouwen. De leeftijd schommelde tussen 22 jaar en 32 jaar. Alle personen studeren op masterniveau aan de Katholieke Universiteit Leuven of zijn er tewerkgesteld. Slechts twee personen gebruikten geen smartphone. Alle afspraken waren individueel en gingen door op het departement computerwetenschappen in Heverlee. Elke evaluatie nam ongeveer 35 minuten in beslag.

6) Resultaten & conclusies

Omdat het ontwerp van dit prototype heel sterk gelijkt op het ontwerp van het laatste papieren prototype, is de kans groot dat er problemen van de vorige evaluatie terugkomen in deze evaluatie. In deze sectie worden alle problemen besproken die zich tijdens deze evaluatie voordeden. Voor elk probleem worden er mogelijke oplossingen gegeven waarvan één oplossing kan worden gebruikt in een volgend prototype.

1. Afstand en tijd bij de vooruitgang niet duidelijk (n=8)

Screen Shot 2014-03-06 at 19.22.54
Probleem:
Acht van de 12 ondervraagden hadden een probleem met de afstand en tijd die naast het percentage van de vooruitgang staan. Deze personen dachten dat deze cijfers de totale afstand en tijd voorstelden die deze week dienen afgelegd te worden. Deze cijfers betekenen echter de totale afstand en tijd die deze week reeds werd afgelegd.

Mogelijke oplossing:
In de vorige evaluaties werd steeds de focus gelegd op de percentages en niet zo zeer op deze cijfers. In deze evaluatie werd voor het eerst expliciet gevraagd wat deze cijfers betekenden. Dit is hoogstwaarschijnlijk de reden waarom dit probleem zich nu pas voordoet. Een voor de hand liggende oplossing is om de totale geplande afstand en tijd toe te voegen. Indien de totale geplande afstand 10 km is en de voorlopige afgelegde afstand 7.5 km is, dan zou de tekst “7.5 km / 10 km” verschijnen. Een andere mogelijkheid is om tussen de procenten en de cijfers een ‘=-teken’ te plaatsen. Dit geeft aan dat bijvoorbeeld 48% overeenkomt met 7.5 km en 3 uur. Deze oplossing is simpeler dan de eerste oplossing en neemt minder plaats in beslag. Omdat simpliciteit een ontwerpcriterium is, zal de tweede oplossing gebruikt worden.

2. Relatie tussen activiteit en details niet duidelijk (n=8) – zelfde probleem als in pp2
Probleem:
Voor acht van de 12 personen was het niet duidelijk dat de details die aan de rechterzijde van het dashboard worden weergegeven, gekoppeld zijn aan een activiteit. Dit is exact hetzelfde probleem dat zich voordeed bij het vorige prototype (zie resultaten pp2).

Mogelijke oplossing:
Een mogelijke oplossing werd reeds besproken in sectie resultaten pp2. Deze oplossing zal worden toegevoegd in het volgende digitaal prototype.

3. Uitrekken van slider niet duidelijk (n=5)

Screen Shot 2014-03-06 at 19.43.28
Probleem:
De standaardperiode die door de slider wordt aangeduid is de huidige week. Vijf van de 12 personen vonden geen manier om ook de vorige week toe te voegen aan de huidige selectie. Het was dus niet duidelijk dat de slider kon verlengd worden door de uiteinden te verslepen.

Mogelijke oplossing:
Een mogelijke verklaring voor dit probleem is dat de slider geen aanwijzingen aan de uiteinden bevat die er op kunnen wijzen dat de slider verlengd kan worden. Dit probleem kwam niet voor in het laatste papieren prototype. Het ontwerp van de slider verschilde er echter lichtjes (zie ontwerp pp2). Daar werd aan het uiteinde van de slider een klein knopje voorzien als aanwijzing voor het verlengen van de balk. Om het probleem op te lossen, lijkt het dus aangewezen om een dergelijke aanwijzing toe te voegen aan het huidige ontwerp van de slider.

4. Het gebruik van de navigatiebalk (n=4)

Screen Shot 2014-03-06 at 20.01.01
Probleem:
Tijdens de evaluatie werd gevraagd om m.b.v. van bovenstaande navigatiebalk een maand terug te gaan in de tijd. Vier van de 12 ondervraagden hadden geen idee hoe dit op een snelle manier mogelijk was.

Mogelijke oplossing:
Wanneer er wordt geklikt op de titel van de balk, namelijk de datum, opent er een kleine kalender waarop een andere datum gekozen kan worden. Het was dus niet duidelijk dat deze kalender tevoorschijn zou komen bij het klikken op de datum. Een maatregel die getroffen werd is het wijzigen van de cursor wanneer de muis over de datum glijdt. De cursor verandert dan in een handje om aan te geven dat er op geklikt kan worden. Deze maatregel was echter reeds aanwezig in dit prototype. Een bijkomende oplossing zou kunnen zijn om een kalender-knopje toe te voegen achter de datum. Dit verlaagt echter, in kleine mate, het simplistisch uiterlijk van de navigatiebalk, wat tevens een ontwerpcriterium is. Een andere mogelijke oplossing is om de datum het uiterlijk van een knop te geven. Eén van deze oplossingen zal echter nog niet worden doorgevoerd in het volgende prototype. Er zal worden afgewacht of dit bij de evaluatie van het volgende prototype een probleem blijft vormen.

5. Navigeren doorheen de planning (n=3)

Screen Shot 2014-03-06 at 20.24.51
Probleem:
Drie van de 12 computerwetenschappers gebruikten de pijlen die aan de planning vasthangen om te navigeren naar de vorige week. Navigeren dient echter gedaan te worden m.b.v. de navigatiebalk bovenaan de planning. Toen de drie personen merkten dat er aan deze pijlen geen actie hing, werd de navigatiebalk gebruikt.

Mogelijke oplossing:
Dit fenomeen kwam enigszins onverwacht omdat deze pijlen werden toegevoegd als aanwijzing en niet als knop. Deze pijlen proberen duidelijk te maken dat de planning is opgedeeld in drie rijen en dat elke rij overeenkomt met de sport naar waar de pijl wijst. Dit fenomeen heeft zich echter nooit voorgedaan bij de evaluatie van het laatste papieren prototype. Dit probleem wordt echter gecreëerd door het inconsistent gebruiken van een pijl, waardoor aan een pijl meerdere betekenissen worden gekoppeld. Omdat consistentie een ontwerpcriterium is, zal de vooruitgang van elk van de drie sporten worden vastgehecht aan de planning. Dit zorgt ervoor dat deze aanwijzingspijlen achterwege gelaten kunnen worden.

6. Grafiek tijdsverdeling niet altijd gevonden (n=4)
Probleem:
Tijdens de evaluatie werd er gevraagd waar een grafiek van de tijdverdeling in de drie disciplines te zien was. Vier van de 12 testpersonen hadden niet door dat deze grafiek kon worden opgevraagd door op het grafiek-knopje boven de planning te klikken.

Mogelijke oplossing:
Dit probleem deed zich, op één individu na, niet voor bij de evaluatie van het laatste papieren prototype met triatleten. Omdat de testpersonen van deze evaluatie niet behoren tot het doelpubliek, zal dit probleem nog niet worden aangepakt in de uitwerking van het volgende prototype. Er zal met dit probleem meer rekening worden gehouden indien het zich ook talrijk voordoet in de volgende evaluatie.

7. Kopiëren van een activiteit in de planning
Het kopiëren van een activiteit is mogelijk door de combinatie van het indrukken van de SHIFT-toets en het verslepen van de activiteit naar het juiste vakje. Aan alle ondervraagden werd gevraagd welke toets ze zouden indrukken om een activiteit te kopiëren. De antwoorden waren verdeeld als volgt:
– (n=7): CRTL-toets (of de CMD-toets op Mac)
– (n=3): Kopie maken door met de rechtermuisknop te klikken op de activiteit en dan aan te duiden om de activiteit te dupliceren
– (n=2): SHIFT-toets

Conclusie:
De CRTL-toets wordt duidelijk meer gerelateerd aan kopiëren in vergelijking met de SHIFT-toets. Drie van de 12 personen stelden echter voor om een andere werkwijze te hanteren. Het klikken met de rechtermuisknop op een activiteit zou een lijstje tonen met de acties die voor de activiteit ondernomen kunnen worden. Daar zou dan de optie staan om de activiteit te dupliceren. De gedupliceerde activiteit dient dan wel nog naar de juiste dag versleept te worden. Het nadeel van deze techniek t.o.v. de CRTL-toets is dat het een stap langer duurt om een activiteit te kopiëren naar een andere dag. Het nadeel van de CRTL-toets t.o.v. deze techniek is dan weer dat gebruikers hoogstwaarschijnlijk niet weten dat het kopiëren van een activiteit op deze manier mogelijk is. De combinatie CRTL-toets en verslepen is namelijk geen bekende techniek, terwijl de rechtermuisknop actie reeds wordt gebruikt in programma’s als Google Drive [1] en Apple Calendar [2]. Omdat beide technieken voor- en nadelen hebben, kan ervoor gekozen worden om beide mogelijkheden aan te bieden.

8. De drukte van het dashboard
In de doelstelling van deze evaluatie werd vermeld dat er opnieuw zou worden gevraagd of het ontwerp te druk overkomt. Acht van de 12 personen gaven aan dat het dashboard niet te druk overkwam, terwijl de overige vier het omgekeerde aangaven. Opmerkelijk is dat volgens drie van deze vier personen deze drukte vooral veroorzaakt werd door de drukke invulling van de details van een activiteit aan de rechterzijde van het ontwerp. Daar worden de verschillende gegevens op zeer korte afstand van elkaar weergegeven, waarbij het tekstvak van de notities alle aandacht naar zich toe blijkt te trekken. Deze laatste opmerking werd nog niet gegeven in vorige prototypes, hoogstwaarschijnlijk omdat dit tekstvak toen nog geen waarde bevatte. Omdat het tekstvlak te klein is, moeten gebruikers door de persoonlijke notities scrollen terwijl er belangrijke informatie in kan staan.

Een mogelijke oplossing is om deze persoonlijke notities in een apart tabblad onder te brengen. Dit tabblad is belangrijker voor het dashboard dan het tabblad waar de route van de activiteit kan worden opgevraagd. Het bekijken van de echte details van een activiteit, inclusief grafieken en de route, werd reeds goed uitgewerkt door andere softwareproducenten. Daarom ligt het ook verder van het doel van dit dashboard en kan ervoor gekozen worden om dit tabblad te vervangen door een tabblad van de persoonlijke notities. Deze strategie helpt de twee bovengenoemde problemen op te lossen. Ten eerste komt er meer plaats vrij voor de details van een activiteit, waardoor de verschillende gegevens meer kunnen worden gespreid. Ten tweede is er meer ruimte voor de persoonlijke notities, waardoor de nood om te scrollen in het tekstvlak kleiner wordt. Bij de evaluatie van het volgende prototype kan er getest worden of deze oplossing wel degelijk ten goede komt van de drukte in het dashboard.

9. SUS questionnaire
susscore

Een boxplot van de SUS-scores staat weergegeven in bovenstaande grafiek. Deze evaluatie werd afgesloten met een gemiddelde SUS-score van 84,6. Twee van de 12 testpersonen waren minder tevreden over de integratie van de verschillende functies in het dashboard en gaven een score van 70. De koppeling tussen de verschillende delen van het dashboard zal in het volgende prototype worden aangepakt. Dit zal worden besproken in het ontwerp van het tweede digitaal prototype. Deze gemiddelde SUS-score ligt in het gebied van uitstekend [1].

7) Algemene conclusie

Deze evaluatie bracht een aantal nieuwe problemen aan het licht. Enkele van deze problemen waren het gevolg van de digitalisering van het laatste papieren prototype. Omdat deze evaluatie werd uitgevoerd met mensen buiten het doelpubliek, zullen niet alle problemen worden aangepakt in de uitwerking van het volgende prototype. Er zal worden afgewacht of deze problemen zich ook voordoen bij de evaluatie van het volgende ontwerp met triatleten.

Eén van de problemen van het vorige papieren prototype, namelijk de onduidelijke koppeling tussen een activiteit en de details ervan (zie 2), kwam opnieuw voor in dit prototype. Dit zal aangepakt worden in het volgende prototype. Merk op dat het probleem van de fysieke proeven waarbij maar één afstand per sport mogelijk was, zich niet heeft voorgedaan in deze evaluatie met computerwetenschappers. Hierin wordt het duidelijk dat de invalshoek waaruit beide groepen het dashboard bekijken, verschillend is. Deze verschillende soorten van inbreng is voordelig voor de kwaliteit van het uiteindelijke dashboard.

Referenties

[1] https://drive.google.com

[2] http://support.apple.com/kb/HT2513

DP1: Doel en methode

Een eerste digitaal prototype kan nieuwe gebruiksproblemen met zich meebrengen die in een papieren prototype niet aan het licht kwamen. Vermits de inhoud van dit eerste digitaal prototype sterk gelijkt op de inhoud van het laatste papieren prototype, zal deze evaluatie zich volledig concentreren op het gebruik van het ontwerp. Er werd gekozen om dit ontwerp te evalueren met een meer technisch publiek dan triatleten, namelijk computerwetenschappers. In deze blogpost zal het doel van deze evaluatie uiteengezet worden, alsook de manier waarop de evaluatie werd aangepakt.

1) Doel van de test

De keuze om dit ontwerp te evalueren met computerwetenschappers is heel doelbewust. Dit publiek zal hoogstwaarschijnlijk het dashboard vanuit een meer technisch standpunt bekijken dan het uiteindelijke doelpubliek. Door te evalueren met meer technisch gezinde personen, wordt er getracht om mogelijke inconsistenties in dit eerste digitaal prototype aan het licht te brengen. Dit is belangrijk voor het ontwerpcriterium van consistentie.

Het doel van deze evaluatie is om te controleren of de concepten waarbij geen problemen waren op papier, ook geen problemen bevatten in deze digitale versie. Omdat het grootste probleem na de evaluatie van het eerste digitaal prototype de drukte van het ontwerp was (zie resultaten pp1), zal ook bij dit doelpubliek worden nagegaan of het ontwerp al dan niet te druk overkomt. Het is interessant om te onderzoeken of computerwetenschappers hieromtrent een andere mening hebben dan triatleten (zie resultaten pp2).

2) Gebruikte methode

Deze evaluatie zal dezelfde methodes hanteren als de vorige evaluatie (zie methode pp2).

3) Motivering van de gebruikte methode (rationale)

De think-aloud methode en de SUS questionnaire zijn goede methodes om gebruiksproblemen en inconsistenties aan het licht te brengen. De gerichte vragen achteraf zal in deze evaluatie worden gebruikt om na te gaan of het ontwerp te druk overkomt.

4) Wat?

Deze evaluatie zal niet veel verschillen van de vorige evaluatie, rekening houdend dat er vooral zal getest worden op functionaliteit die reeds werkt. Daarom zullen de gestelde vragen hier niet meer worden herhaald en wordt er verwezen naar methode pp2.

Het verwijderen van activiteiten en het kopiëren van activiteiten in de planning werden echter nog niet getest op papier. Deze twee acties zullen daarom in deze evaluatie aan bod komen. Bij het kopiëren van een activiteit dient de gebruiker de SHIFT-toets in te houden bij het verslepen van de activiteit. Er zal worden nagegaan of dit de toets is die het meest wordt gerelateerd aan kopiëren.

Omdat computerwetenschappers minder afweten van de inhoud van het dashboard, zullen er geen vragen worden gesteld omtrent de inhoud.

DP1: Design

Het zoeken van testpersonen binnen het doelpubliek voor het tweede papieren prototype verliep heel moeizaam. Daardoor werd tijdens de evaluaties van het tweede papieren prototype gewerkt aan de implementatie van een eerste digitaal prototype. In dit prototype werden de eerdere besproken problemen (zie resultaten pp2) dus nog niet opgelost, waardoor de aanpassingen t.o.v. het vorige ontwerp miniem zijn. In deze blogpost wordt het ontwerp van dit eerste digitaal prototype besproken. Sectie 1 gaat in op de functionaliteiten die reeds werden geïmplementeerd in dit prototype, maar ook op functionaliteiten waarvan de implementatie wordt uitgesteld tot een volgend digitaal prototype.

1) Ontwerp

Het ontwerp van dit digitaal prototype is te vinden via deze link. Een schermafdruk van dit ontwerp staat weergegeven in onderstaande figuur. Deze implementatie bevat nog geen back-end (bv. een databank), waardoor er gebruik werd gemaakt van onechte data. Dit heeft als gevolg dat veel tekst statisch is en blijft, ook al onderneemt de gebruiker enkele acties.

Screen Shot 2014-03-06 at 11.49.00

De planning
Gebruikers hebben in dit ontwerp reeds de mogelijkheid om trainingen in te plannen, namelijk door te klikken in het juiste vakje. Trainingen kunnen ingepland worden op basis van afstand of tijd. Het toevoegen van een resultaat wordt gedaan door op de betreffende activiteit te klikken, maar dit proces werd nog niet geïmplementeerd. Het is ook mogelijk om trainingen te kopiëren en te verwijderen. Het kopiëren van een training kan door het inhouden van de SHIFT-toets en het verslepen van de training naar het juiste vakje. Het verwijderen van een activiteit kan door met de muis over de activiteit te glijden. Op dat moment verschijnt er een kruis-symbooltje waarmee de activiteit kan verwijderd worden. Gebruikers kunnen ook navigeren door de planning m.b.v. van de navigatiebalk die bovenaan gepositioneerd staat.

In het vorige ontwerp stond de effectieve afstand onder de geplande afstand weergegeven (zie ontwerp pp2). Dit veroorzaakte een probleem in combinatie met de kleine hoeveelheid ruimte in een vakje (zie resultaten pp2). De twee mogelijke oplossingen die hieromtrent besproken werden, lieten beide de effectieve afstand weg. Vandaar dat de effectieve afstand alvast in dit ontwerp niet meer onder de geplande afstand wordt weergegeven. Het implementeren van één van de twee oplossingen wordt echter uitgesteld naar het volgende prototype.

Relatie tussen activiteit en details
Gebruikers hebben nog niet de mogelijkheid om de details van een activiteit te bekijken door er op te klikken. Door de eerder vermelde omstandigheden, werd het probleem dat de relatie tussen activiteit en details niet duidelijk was (zie resultaten pp2) nog niet opgelost.

Opslaan van persoonlijke eigenschappen
Persoonlijke eigenschappen kunnen in dit ontwerp reeds worden opgeslagen. Gebruikers kunnen dit verwezenlijken door op het symbool van de eigenschap te klikken. Er verschijnt dan een ruimte waarin de laatst gekende waarde is ingevuld. Deze waarde kan door de gebruiker worden aangepast door bijvoorbeeld gebruik te maken van de afgebeelde symbolen. Dergelijke manier van werken zorgt ervoor dat gebruikers zo weinig mogelijk tijd verliezen met het opslaan van deze eigenschappen. Eigenschappen zoals gewicht en hartslag kennen namelijk geen drastische verandering van dag op dag. Navigeren doorheen de tijd kan op dezelfde manier als bovenaan de planning. Zoals eerder vermeld sluit dit mooi aan bij het ontwerpcriterium van consistentie.

Inschatten van de trainingsintensiteit
Triatleten kunnen hun trainingsintensiteit inschatten aan de hand van vier waarden die worden berekend in een bepaalde periode. De standaardperiode is de huidige week, maar deze tijdsperiode kan aangepast worden m.b.v. de slider die bovenaan de kader staat. De individuele waarden kunnen ook vergeleken worden met de gemiddelde waarden van alle gebruikers. De gebruikers die worden opgenomen in de berekening van deze gemiddelde waarden kunnen gekozen worden m.b.v. de filter bovenaan de kader.

Grafieken
Het ontwerp toont reeds de knopjes die zullen worden gebruikt voor het tonen van grafische voorstellingen. Deze grafieken kregen in dit ontwerp een lagere prioriteit omdat ze initieel niet zichtbaar zijn op het hoofdscherm. Dit wil niet zeggen dat er geen belang zal worden gehecht aan deze grafieken. De implementatie ervan wordt uitgesteld naar het volgende prototype. Het is dan de bedoeling om deze grafieken uitgebreid te evalueren. Ook de grafiek van de fysieke proeven is voorlopig nog statisch en hangt niet af van de gekozen tijdsperiode in de slider.

PP2: Resultaten & conclusies

5) Wie, Wanneer?
Deze evaluatie werd uitgevoerd met acht triatleten (n=8), waarvan zeven mannen en één vrouw. De leeftijd van deze personen ligt tussen 22 en 41 jaar. Twee personen hadden geen ervaring met het gebruik van een smartphone. Alle personen gaven aan regelmatig een computer te gebruiken en over een basiskennis van het Engels te beschikken. Er werd telkens een afspraak gemaakt met elke testpersoon. Deze afspraken gingen steeds door bij de persoon thuis en duurde ongeveer 45 minuten.

6) Resultaten & Mogelijke oplossingen
De problemen die zich doorheen de evaluaties hebben voorgedaan staan hieronder opgelijst. Onderstaande problemen hebben betrekking tot zowel de inhoud als het gebruik van het dashboard. Er wordt telkens getracht om voor elk probleem een aantal mogelijke oplossingen te bespreken. Het is dan de bedoeling dat in een volgend ontwerp voor elk van deze problemen de beste oplossing gekozen wordt.

1. Te weinig plaats in planning (n=4)
Screen Shot 2014-03-05 at 11.59.27

Probleem:
Vier van de acht triatleten hadden een probleem met de voorstelling van de activiteiten in de planning. Op het design is te zien dat het vakje dat overeenkomt met een bepaalde sport op een bepaalde dag maximaal twee activiteiten kan bevatten. Het vakje is te klein om er meer activiteiten in weer te geven, terwijl deze triatleten aangaven vaak dagelijks meer dan twee activiteiten per sport af te leggen.

Mogelijke oplossing:
Dit probleem wordt voornamelijk veroorzaakt door onder de geplande afstand of tijd van een activiteit ook de afstand of tijd die effectief werd afgelegd weer te geven. Een bijkomend nadeel van deze representatie is de onmogelijkheid om in één oogopslag te bepalen of er effectief meer of minder werd afgelegd dan gepland. Gebruikers moeten eerst beide cijfers met elkaar vergelijken vooraleer tot een conclusie te kunnen komen.

Een mogelijke oplossing is om kleuren te introduceren die aangeven of er meer of minder werd gedaan. Kleuren worden echter reeds gebruikt om de trainingscategorie van een activiteit aan te duiden. Daarom lijkt deze oplossing niet aangeraden. Er kunnen minstens nog twee andere mogelijke oplossingen in overweging worden genomen. Een eerste voorstel is het toevoegen van een progress-bar in de balk van de activiteit. Deze geeft aan hoeveel procent van de geplande afstand of tijd er effectief werd afgelegd. Een tweede voorstel is het toevoegen van een small indicator in de balk van de activiteit. Hierbij kan bijvoorbeeld een pijl worden toegevoegd die naar boven wijst indien er meer werd gedaan dan gepland, en het omgekeerde indien er minder werd gedaan.

In beide voorstellen wordt de effectieve afstand of tijd niet weergegeven, waardoor er meer plaats vrijkomt in het vakje. Beide oplossingen elimineren bovendien ook de stap van de vergelijking tussen twee cijfers, waardoor in één oogopslag te bepalen is of er effectief meer of minder werd afgelegd dan gepland. Het voordeel van de progress-bar t.o.v. de small indicator is dat de gebruiker ook kan inschatten hoeveel meer of minder er werd afgelegd dan gepland. Een moeilijkheid in de weergave van de progress-bar is echter wanneer er meer werd gedaan dan gepland. Een bijkomend nadeel is dat de planning hoogstwaarschijnlijk een minder simplistisch uiterlijk krijgt.

2. Relatie tussen activiteit en details niet duidelijk (n=6)
Screen Shot 2014-03-05 at 12.50.17kopie

Probleem:
Voor zes van de acht ondervraagde triatleten was het niet duidelijk dat de details die aan de rechterzijde van het dashboard worden weergegeven, gekoppeld zijn met een activiteit. Vier van deze zes triatleten hadden het idee dat dit een wekelijkse samenvatting was van een bepaalde sport. De andere twee triatleten hadden geen idee.

Mogelijke oplossing:
Het klikken op een activiteit waarvan de resultaten reeds werden ingegeven heeft als effect dat de details aan de rechterzijde worden weergegeven. Dit probleem dient een beetje genuanceerd te worden omdat de details leeg zouden zijn zolang er niet wordt geklikt op een activiteit. In dit ontwerp staan echter de details die gekoppeld zijn aan de loopactiviteit op dinsdag al weergegeven. Langs de andere kant moet de relatie tussen de details en de activiteit die er aan gekoppeld is altijd zichtbaar zijn. In dit ontwerp bevat de planning geen aanwijzing die aangeeft van welke activiteit de details momenteel worden weergegeven.

Een mogelijke aanwijzing zou kunnen zijn om de balk van de geselecteerde activiteit een gekleurde rand te geven. Indien er geen activiteit geselecteerd is, kan er op de plaats waar normaalgezien de details worden afgebeeld een hint worden getoond. Deze hint kan de gebruiker dan aansporen om op een activiteit te klikken indien hij de details ervan wenst op te vragen.

3. Slechts één afstand bij fysieke proeven (n=7)
Screen Shot 2014-03-05 at 14.07.22

Probleem:
Zeven van de acht ondervraagden vonden het problematisch dat per sport steeds dezelfde afstand werd gebruikt voor alle fysieke proeven.

Mogelijke oplossing:
In realiteit hebben deze proeven vaak een verschillende afstand. Deze afstand hangt af van een aantal factoren. Zo is de periode waarin een proef wordt afgelegd bepalend. In het tussenseizoen zullen deze afstanden meestal korter zijn dan in de periode waarin de triatleet moet pieken naar het hoogste niveau. Ook de wedstrijd naar waar de triatleet toeleeft is van belang. Vaak wordt de afstand van een fysieke proef beïnvloed door de afstand van de volgende wedstrijd. Gegeven het feit dat triatleten aan wedstrijden deelnemen van een verschillend formaat, lijkt het aangewezen om te werken met verschillende afstanden voor deze proeven. De gebruiker moet dan de mogelijkheid hebben om de afstand te kiezen waarvan de tijden van deze proeven moeten worden weergegeven.

4. Eén hartslagzone voor alle sporten (n=5)
Probleem:
In de profielpagina kunnen triatleten hun hartslagzones ingeven. Deze zones worden gebruikt in de details van de resultaten van een activiteit en zijn in dit ontwerp voor elke sport hetzelfde. Vijf van de acht triatleten gaven aan dat in realiteit de hartslagzones voor elk van de drie sporten verschillend zijn.

Mogelijke oplossing:
Omdat de drie sporten een andere intensiteit hebben, zal de hartslag bij het beoefenen van deze sporten verschillend zijn. Daarom dient er in de toekomst de mogelijkheid te zijn om in de profielpagina hartslagzones op te geven voor elk van deze drie sporten.

5. Het concept van fysieke proeven
De triatleten werden gevraagd om een mening te geven over het concept van de fysieke proeven. Meer bepaald of ze het zelf gebruiken of willen gaan gebruiken in de toekomst, m.a.w. of het een nuttig concept is om de toename in conditie in te schatten. De verdeling van de antwoorden ziet er als volgt uit:
– (n=6): Geven aan dat ze het concept van fysieke proeven zelf toepassen of in de toekomst zeker willen gaan toepassen.
– (n=2): Geven aan dat het concept van fysieke proeven niet interessant is.

Conclusie:
Aan het einde van de evaluaties van het eerste papieren prototype werd de beslissing genomen om de vooruitgang van conditie voortaan weer te geven aan de hand van fysieke proeven in de plaats van het vergelijken van gemiddelde snelheden (zie resultaten pp1). Het resultaat op deze vraag bevestigt grotendeels dat het huidige concept de moeite waard is om op te nemen in het dashboard en verder te onderzoeken.

6. De drukte van het dashboard
De triatleten dienden aan te geven of ze het dashboard al dan niet te druk vonden. De verdeling van de antwoorden ziet er als volgt uit:
– (n=7): Het design komt niet druk over.
– (n=1): Het design komt erg druk over.

Conclusie:
Waar bij het vorige ontwerp (zie resultaten pp1) nog zeven van de negen ondervraagden aangaven dat het ontwerp heel erg druk overkwam, doet dit ontwerp het met slechts één van de zeven ondervraagden veel beter.

7. Ontbrekende informatie
Op het einde van de evaluatie werd er gevraagd naar informatie die niet staat weergegeven op het dashboard, maar die de triatleet wel nodig vindt. Eén van de acht triatleten gaf aan wedstrijden te willen plannen in de kalender en de mogelijkheid om van deze wedstrijden een resultaat op te slaan. Een andere triatleet wilde de mogelijkheid om doelstellingen voorop te stellen en proberen deze na te streven.

Conclusie:
Slechts twee van de acht triatleten gaven aan dat er informatie ontbrak. Beide voorstellen werden geïntroduceerd in het eerste digitale prototype (zie ontwerp pp1). De persoon die aangaf het concept van wedstrijden te missen, wilde enkel wedstrijden inplannen en een kort resultaat ervan opslaan. Dit zonder wedstrijden met elkaar te kunnen vergelijken, zoals wel het geval was in het eerste papieren prototype. De motivatie hiervoor is dat triatleten toeleven naar wedstrijden en dat deze daarom ook zeker op de planning thuishoren. De mogelijkheid bieden om ook wedstrijden in te plannen, kan later nog worden overwogen.

8. SUS questionnaire
susscore

Een boxplot van de SUS-scores is te zien in bovenstaande figuur. De gemiddelde SUS-score is 86,3 en er zijn deze keer geen uitschieters. Uit [1] weten we dat deze SUS-score de grens van uitstekend bereikt. Deze gemiddelde SUS-score ligt hoger dan die van het vorige ontwerp (zie resultaten pp1). De score geeft een indicatie dat er zich bij dit ontwerp geen grote gebruiksproblemen voordoen.

7) Algemene conclusie
Er zijn een aantal nieuwe problemen opgedoken die meestal te maken hebben met de veranderingen die werden doorgevoerd in het ontwerp. Voor alle genoemde problemen werd telkens ook minstens één mogelijke oplossing aangehaald dat in een volgend ontwerp kan geïntroduceerd worden. Bij het plannen van activiteiten en het toevoegen van resultaten van deze activiteiten zijn geen grote gebruiksproblemen aan het licht gekomen. Er werd echter wel een groter probleem gevonden bij de koppeling tussen een activiteit en de details die rechts worden weergegeven. Na de evaluatie van het eerste papieren prototype werd beslist om concepten zoals wedstrijden, het vooropstellen van doelen en het verdienen van badges weg te laten (zie resultaten pp1). Deze beslissing lijkt goed te zijn op basis van de antwoorden op de vraag of er informatie op het dashboard ontbreekt. Door onder andere deze concepten niet meer op te nemen in het ontwerp, komt dit ontwerp veel minder druk over, waardoor dit ook hier een goede beslissing lijkt te zijn.

Een gemiddelde SUS-score van 86,3 geeft een indicatie dat er zich bij dit ontwerp geen grote gebruiksproblemen voordoen. Deze manier van testen zal echter steeds herhaald blijven worden. Het oplossen van bepaalde problemen kan immers nieuwe problemen introduceren.

Referenties
[1] Bangor, A., Kortum, P. T., & Miller, J. T. (2009). Determining what individual SUS scores mean: Adding an adjective rating scale. Journal of Usability Studies, 4(3), 114-123.

PP2: Doel en methode

Het ontwerp van het tweede papieren prototype werd in deze blogpost voorgesteld. Dit ontwerp heeft een heel ander uitzicht dan het ontwerp van het eerste papieren prototype. Het is dus belangrijk om dit opnieuw te testen met gebruikers uit het doelpubliek. In deze blogpost zal het doel van deze evaluatie uiteengezet worden, alsook de manier waarop de evaluatie zal worden aangepakt.

1) Doel van de test

Ten opzichte van het vorige prototype bevat dit prototype minder informatie en wordt het op een andere manier voorgesteld. Daarom is het belangrijk om na te gaan of de nieuwe voorstelling duidelijk is in gebruik bij het doelpubliek. Zo zijn de ontwerpcriteria ‘data captatie’ en ‘plannen van activiteiten’ grondig gewijzigd. Het doel van deze evaluatie ligt daarom sterk in het ontdekken van eventuele problemen bij het plannen van activiteiten en het toevoegen van resultaten van deze activiteiten. Dit komt neer op het gebruiken van de kalender in het gedeelte “My planning & progress”. Daarnaast is het mogelijk om in dit prototype de details op te vragen van een activiteit. Er zal dus worden nagegaan of de koppeling tussen een activiteit en de details ervan gevonden wordt.

Een belangrijk nieuw concept in het dashboard zijn de fysieke proeven waarvan de tijden worden weergegeven op een grafiek. Vermits dit concept sterk bijdraagt tot het ontwerpcriterium van ‘evolutie bekijken’, zal deze nieuwe invulling uitgebreid aan bod komen in deze evaluatie. Andere concepten zoals wedstrijden, het vooropstellen van doelen en het verdienen van badges werden niet meer opgenomen in dit ontwerp. Deze evaluatie zal nagaan of dit een goede beslissing was, namelijk door te controleren of ze niet worden gemist door de triatleet. Het verwijderen van deze concepten had als doel om het ontwerp te ontlasten van drukte. Deze evaluatie heeft daarom ook als doel om te controleren of de gebruikers het ontwerp nog steeds te druk vinden.

2) Gebruikte methode

De volgende methodes worden gebruikt in deze evaluatie:

  • Think-aloud methode waarbij gebruikers moeten beschrijven wat ze denken dat er staat weergegeven
  • Think-aloud methode tijdens het uitvoeren van enkele opdrachten met het ontwerp
  • Achteraf gerichte vragen stellen omtrent het nieuwe ontwerp en het ontbreken van informatie
  • De gebruiker dient achteraf ook een SUS questionnaire in te vullen

3) Motivering van de gebruikte methode (rationale)

De think-aloud methode waarbij gebruikers moeten beschrijven wat ze zien is zeer nuttig bij het testen van de kalender. Omdat de kalender een heel belangrijk onderdeel is van het dashboard, moet er worden nagegaan of de gebruiker begrijpt wat er in de kalender staat weergegeven en hoe dat gerelateerd kan worden aan de andere onderdelen in “My planning & progress”. Ook bij het uitvoeren van gerichte taken is de think-aloud methode een goede manier om te testen op welke manier gebruikers deze taken volbrengen en hoe de applicatie wordt gebruikt. Deze methode geeft op een snelle manier informatie waaruit gebruiksproblemen onderscheiden kunnen worden.

Het gebruik van een SUS questionnaire helpt ook om een idee te krijgen omtrent de usability van het ontwerp. Het resultaat van deze vragenlijst geeft een indicatie over de consistentie en de simpliciteit van het ontwerp. Dit is belangrijk omdat consistentie en simpliciteit één van de ontwerpcriteria is (zie deze blogpost).

Gerichte vragen over het ontwerp worden vooral gebruikt om na te gaan of de gebruiker dit ontwerp te druk vindt. Dit was een belangrijke kritiek op het eerste papieren prototype, vandaar dat deze vraag opnieuw zal worden gesteld. Daarnaast zal er ook gepolst worden naar het ontbreken van bepaalde informatie op het dashboard, alsook de het toegevoegde concept van fysieke proeven.

4) Wat?

Er volgt een bondig overzicht van de vragen die tijdens de evaluatie werden gesteld, alsook de taken die de gebruikers per onderdeel moesten uitvoeren.

Progress – Planning – Detail
– Think-aloud: Wat wordt er in de bovenste kader allemaal getoond. Is dit snel duidelijk?

Met deze vraag worden de volgende zaken gecontroleerd:

  • De gebruiker snapt de relatie tussen planning en progress
  • De gebruiker begrijpt hoe de planning (kalender) is opgebouwd
  • De gebruiker ziet de koppeling tussen een activiteit uit de planning en de details van deze activiteit aan de rechterzijde van het dashboard

Deze opdracht draagt bij tot het controleren van de kwaliteit van de ontwerpcriteria ‘data captatie’, ‘interactiviteit’ en ‘plannen van activiteiten’.

Plannen van een activiteit
– Een nieuwe activiteit inplannen
– Het wijzigen van een activiteit

Deze opdrachten hebben een rechtstreeks verband met het ontwerpcriterium ‘plannen van activiteiten’. Vermits de gebruiker eerst een activiteit moet inplannen alvorens er resultaten van toe te voegen, hebben deze opdrachten ook onrechtstreeks invloed op het ontwerpcriterium ‘data captatie’.

Toevoegen van de resultaten van een (geplande) activiteit
– Manueel toevoegen van een resultaat
– Toevoegen van een resultaat door het inladen van een bestand dat werd gegenereerd door een sporthorloge/gps

Het toevoegen van een resultaat heeft rechtstreeks invloed op het ontwerpcriterium ‘data captatie’.

Navigeren doorheen de planning en bekijken van tijdsverdeling
– Het opzoeken van een activiteit die in een eerdere week werd afgelegd
– Zoeken van de grafiek waarop de tijdsverdeling van de drie disciplines is weergegeven
– Think-aloud: Wat staat er weergegeven op de grafiek en heeft de grafiek een meerwaarde?

Beide opdrachten brengen bij tot het ontwerpcriterium van ‘evolutie bekijken’.

Bekijken van de details van een activiteit
– Opzoeken van een bepaalde waarde uit de details
– Gebruik maken van de tabbladen in de details

Deze opdrachten dragen bij tot het ontwerpcriterium ‘interactiviteit’.

Persoonlijke eigenschappen opslaan
– Think-aloud: wat betekenen de vier symbolen die staan weergegeven? Andere eigenschappen die je zou willen opslaan?
– Het toevoegen van de ochtendpols op de huidige dag
– Het toevoegen van het gewicht op de vorige dag
– Het terugkeren van een subscherm naar het hoofdscherm m.b.v. de links-georiënteerde pijl (cfr. ontwerp pp2)

Deze opdrachten behoren tot de ontwerpcriteria ‘data captatie’ en ‘evolutie bekijken’.

Inschatten en vergelijken van trainingsintensiteit
– Think-aloud: Tot welke personen behoren de twee rijen waarvan de waarden staan weergegeven?
– Gebruik maken van de slider om de gegevens in een andere tijdsperiode te laten berekenen
– Vergelijking met de gemiddelde gebruiker, gebruik makend van de filter

Deze taken hebben te maken met de ontwerpcriteria ‘interactiviteit en aanpasbaarheid’ en ‘evolutie bekijken’.

Inschatten van conditietoename
– Think-aloud: Vind je dit een goede manier om de vooruitgang in fysieke conditie te ontdekken?
– Gebruik maken van tabbladen en slider
– Het inplannen van een fysieke proef zodat het resultaat wordt opgenomen in de grafiek

Deze opdrachten hebben invloed  op volgende ontwerpcriteria: ‘interactiviteit en aanpasbaarheid’, ‘evolutie bekijken’ en ‘plannen van een activiteit’.

Gerichte vragen achteraf
– Welke indruk geeft dit design? Is het te druk? Nodigt het uit om het te gebruiken?
– Zijn er bepaalde concepten die je ook graag zou willen zien op het dashboard, maar die niet aan bod zijn gekomen?

PP2: Design

Dit prototype gaat verder op de resultaten van de evaluaties van het eerste papieren prototype. Er werden problemen besproken die uit de evaluaties naar boven kwamen. Voor elk probleem werden mogelijke oplossingen aangehaald waarvan voor- en nadelen werden besproken. In deze blogpost zal het tweede papieren prototype (PP2) worden voorgesteld. Dit prototype zal voor elk probleem één van de mogelijke oplossingen gebruiken om het probleem aan te pakken. Het ontwerp van dit prototype wordt hier besproken, samen met de belangrijkste aanpassingen t.o.v. het eerste papieren prototype.

1) Ontwerp

Het ontwerp van het dashboard is te zien in onderstaande figuur. Een groot probleem bij het vorige prototype was de drukte. Er werd heel veel informatie weergegeven in erg veel detail. Dit had als gevolg dat de gebruiker zou moeten scrollen doorheen het dashboard om alle informatie te bekijken. Het doel van de evaluaties van het vorige prototype was dan ook om te onderzoeken welk van de weergegeven informatie het belangrijkst was. Het nieuwe ontwerp bevat daarom enkel de concepten die de hoogste prioriteit kregen van de ondervraagde triatleten. Daardoor is de nood voor het scrollen verdwenen en is alle informatie gepositioneerd op één scherm.

Er werden ook andere strategieën gebruikt om het ontwerp van drukte te ontdoen. Het gebruik maken van symbolen in combinatie met een waarde probeert de hoeveelheid detail te beperken. Daarnaast wordt er ook gebruik gemaakt van een drieledig kleurenschema (oranje, donker- en lichtgrijs). Een beperkt aantal kleuren geeft het design een meer simplistisch uitzicht, wat bijdraagt tot het ontwerpcriterium van simpliciteit.

“My planning & progress” bleek het belangrijkste onderdeel van het dashboard (zie resultaten pp1). Zoals eerder besproken dient de belangrijkste informatie links bovenaan te staan. Daarom werd het logo van de applicatie verplaatst van links bovenaan naar links onderaan en staat “My planning & progress” voortaan bovenaan het dashboard. De details van een activiteit staan naast de planning gepositioneerd (zoals gesuggereerd in de resultaten van pp1). Het klikken op een activiteit in de planning heeft als effect dat de details van de activiteit aan de rechterkant worden weergegeven. Dit verhoogt de interactiviteit, wat ook een ontwerpcriterium is.

pp2

2) Aanpassingen

a) Toevoegen van activiteiten
Geplande- en uitgevoerde activiteiten werden in het vorige prototype niet aan elkaar gelinkt. Bij het toevoegen van het resultaat van een activiteit was er geen mogelijkheid om aan te geven met welke geplande activiteit het gekoppeld was, waardoor sommige informatie meermaals moest worden ingevuld. In dit ontwerp is de “Add activity” knop verdwenen, waardoor gebruikers activiteiten moeten plannen door in de kalender te klikken. Dit heeft als gevolg dat gebruikers enkel resultaten van geplande activiteiten kunnen ingeven, namelijk door op de activiteit te klikken. Deze nieuwe invulling vergemakkelijkt het proces van het ontwerpcriterium data captatie. Daarnaast kan het plannen van een activiteit voortaan zowel in afstand als in tijd.

b) Weergave planning
De effectieve afstand of tijd die werd afgelegd wordt nu ook weergegeven onder de geplande afstand of tijd. Ook de trainingscategorieën van elke activiteit werden toegevoegd. Beide vernieuwing dragen bij tot een hogere kwaliteit van het ontwerpcriterium ‘plannen van activiteiten’.

Een navigatiebalk werd toegevoegd bovenaan de planning. Deze navigatiebalk werd reeds gebruikt in het onderdeel “My Personal Specs”, waardoor het navigeren doorheen de tijd met een vaste tijdsperiode consistent blijft (ontwerpcriterium consistentie). Naast deze balk werd ook een grafiek-knopje toegevoegd. Indien de gebruiker hier op klikt, verschijnt een grafische voorstelling van de tijdsverdeling in de drie disciplines (zoals werd voorgesteld in resultaten pp1).

c) Verfijnde vergelijking met gemiddelde gebruiker
Er werd een “avg user filter” toegevoegd zodat gebruikers een meer verfijnde vergelijking kunnen maken met de gemiddelde gebruiker. Het is nu mogelijk om te vergelijken met een gemiddelde gebruiker die wordt berekend op basis van een aantal criteria: hetzelfde geslacht, dezelfde leeftijdscategorie en hetzelfde niveau.

d) Physical contests
De invulling van het concept “My physical fitness” (zie design pp1) wordt vervangen door het concept “My physical contests” (zoals eerder besproken in resultaten pp1). Gebruikers hebben de mogelijkheid om per discipline een grafiek te bekijken waarop alle tijden van de proeven worden getoond die binnen een bepaalde tijdsperiode werden afgelegd. Deze tijdsperiode kan gekozen worden m.b.v. de slider die bovenaan in de kader staat. Deze slider wordt bovenaan gepositioneerd omdat deze zowel van toepassing is op “My training intensity” en “My physical contests”.

e) Terugkeren naar hoofdscherm vanuit subscherm
Elke kader waarbij het opvragen van een grafiek mogelijk is, bevat nu slechts één knopje in plaats van meerdere knopjes. Indien er op het grafiek-knopje wordt geklikt, zal dit knopje vervangen worden door een links-georiënteerde pijl  back_symbol_black.  Dit heeft als doel het probleem van terugkeren naar het hoofdscherm, dat zich voordeed bij het eerste papieren prototype, weg te werken.