ggso project - verslag...een bepaalde fase of taak had met het vak evaluatie van user interfaces. we...

GGSO

Project - verslag

Michiel Grauwels

Jelle Polders

Eveline Van Daal

Academiejaar 2007-2008

Master in de Informatica

G G S O P r o j e c t : V e r s l a g | 2

Grauwels Michiel, Polders Jelle & Van Daal Eveline

Inhoudstabel

1. Inleiding ................................................................................................................................................. 4

2. Personas en scenario ............................................................................................................................ 5

3. Taakmodel en dialoogmodel................................................................................................................. 5

• Verklaring update scenario ............................................................................................................... 6

4. Low-fidelity Prototyping ....................................................................................................................... 6

• Gebruikte tools ................................................................................................................................. 6

o Webbrowser: PowerPoint ............................................................................................................. 6

o Mobiel: DENIM .............................................................................................................................. 7

o Vergelijking tools met Gummy ..................................................................................................... 8

• Opmerkingen low-fidelity prototype website .................................................................................. 8

• Verklaring updates taakmodel – dialoogmodel ................................................................................ 9

• Expert review medestudenten ......................................................................................................... 9

o Prototype Website ........................................................................................................................ 9

o Prototype PDA ............................................................................................................................. 13

• Verklaring updates 2: scenario, taakmodel, dialoogmodel, low-fidelity prototypes ..................... 17

5. High-fidelity Prototyping ..................................................................................................................... 18

• Gebruikte toolkits ........................................................................................................................... 18

o Webbrowser ............................................................................................................................... 18

o Mobiel ......................................................................................................................................... 18

• Extra veranderingen aan prototype ................................................................................................ 18

• Pre-test: veranderingen aan prototypes......................................................................................... 18

• Wizard of Oz .................................................................................................................................... 19

• Remote Logging .............................................................................................................................. 21

• Gebruikte design patronen ............................................................................................................. 21

o Card Stack (1) .............................................................................................................................. 21

o Carousel (2) ................................................................................................................................. 23

o Center Stage (3) .......................................................................................................................... 24



o Clear Entry Points (4) .................................................................................................................. 25

o Diagonal Balance (5) ................................................................................................................... 26

o Dropdown Chooser (6) ................................................................................................................ 27

o Edit-in-Place (7) ........................................................................................................................... 28

o Global navigation (8) ................................................................................................................... 29

o Jump to Item (9) .......................................................................................................................... 30

o Liquid Layout (10)........................................................................................................................ 32

o Page Grids (11) ............................................................................................................................ 33

o Quick Access Pattern ................................................................................................................... 33

o Row striping (12) ......................................................................................................................... 34

o Sortable Tabel (13) ...................................................................................................................... 34

o Tool Tip Invitation (14) ................................................................................................................ 35

o Visual Framework (15) ................................................................................................................ 36

6. Usability test ....................................................................................................................................... 38

• Website ........................................................................................................................................... 38

• PDA .................................................................................................................................................. 38

• Opmerkingen .................................................................................................................................. 39

7. Besluit.................................................................................................................................................. 39

Bibliografie .................................................................................................................................................. 41



1. Inleiding

In het project voor het vak GGSO is het de bedoeling dat we nader kennis gingen maken met hoe de

UCD cyclus in de praktijk wordt toegepast. Deze cyclus bestond voor ons uit de volgende fasen, die op

hun beurt weer zijn opgebouwd uit verschillende deeltaken. Waar nodig, vermelden we ook de link die

een bepaalde fase of taak had met het vak Evaluatie van User Interfaces.

We geven even een kort overzicht van het gevolgde proces:

1. Personas en scenario's opstellen

2. Opstellen van een taakmodel

3. Opstellen van een dialoogmodel

4. Maken van low-fidelity prototypes

5. Low-fidelity prototypes werden gerecenseerd (expert review) door medestudenten (EvalUI:

Heuristische evaluatie).

6. Aanpassen van low-fidelity prototypes op basis van de verkregen feedback uit de expert review

7. Bouwen van high-fidelity prototypes

8. Opstellen van een usability test (EvalUI) + inbouwen van remote logging + wizard of oz techniek

in prototypes om de usability test te ondersteunen

9. Usability test 1 (eerder informeel) met medestudenten als deelnemers

10. Opnemen van feedback in high-fidelity prototypes

11. Usability test 2 (formeel) met studenten 1 Bach Informatica als deelnemers.

12. Beschrijving geven van hoe we de feedback uit formele test zouden toepassen op high-fidelity

prototypes.

Het is dus duidelijk dat we te maken hebben met een iteratief proces waarbij resultaten uit de

verschillende fasen steeds worden gebruikt om het uiteindelijke resultaat positief te beïnvloeden. We

zetten doorheen dit verslag het gevolgde proces gedetailleerd uit en geven een kritische kijk op onze

ervaringen. Maar allereerst geven we een beschrijving van de applicatie die het centrum vormde van dit

project.

Het thema van de te ontwikkelen toepassing betreft “Concerten & Festivals” en is een Content

management systeem. We hebben voor de applicatie twee rollen gedefinieerd, dus meer bepaald twee

types van gebruikers die in de toekomst met de applicatie zullen werken.

Rol 1

De toepassing stelt de gebruikers ervan in staat om een reportage toe te voegen en hieraan de

gewenste media (foto’s, video’s) te koppelen. De reportages kunnen verder onderling gelinkt

worden door de toekenning van een categorie aan elke reportage. Om deze rol te vervullen, dient de

gebruiker ingelogd te zijn.

Rol 2

Een reportage, inclusief zijn bijhorende foto’s & video’s, kan via een overzicht geraadpleegd en in

detail bekeken worden. De gebruiker kan via het overzicht reportages bekomen die enkel tot de

categorie van zijn interesse behoren. Iedere gebruiker van de toepassing heeft het recht om deze rol

te mogen vervullen en kan tevens commentaar geven op een reportage.



Het doelpubliek van de te ontwerpen toepassing betreft 18-19 jarigen. Meer specifiek denken we

hierbij dan aan 1ste Bachelor studenten (Informatica/ICT), maar we bakenen dit echter helemaal niet

strikt af zodanig dat er ook op zekere hoogte rekening gehouden wordt met minder ervaren

computergebruikers.

2. Personas en scenario

Om de personas op te stellen hebben we geen interviews kunnen afleggen omdat hier geen tijd voor

ingelast was in de opdracht. We hebben daarom onze personas verzonnen op basis van onze eigen

ervaringen met contentmanagement systemen en "Concerten & Festivals". We hebben aan onze eerste

persona ‘Stefan’ redelijk lang gewerkt, omdat we nog niet goed wisten hoe we het moesten aanpakken.

Ook moesten we er rekening mee houden dat alle verschillende vereisten (doelen, max. 2 persoonlijke

ervaringen en gedragspatronen) zeker opgenomen werden in het persona. Het opstellen van de

volgende personas ging een stuk sneller.

Bij het opstellen van het scenario waren we eerst teveel in detail gegaan. We hielden te weinig rekening

met de "taken" die de personas moeten kunnen uitvoeren met de applicatie om hun doelen te bereiken.

Dit werd ons duidelijk na een e-mail aan onze begeleidster, aangezien we totaal geen notie hadden van

het feit hoe gedetailleerd een scenario moet zijn en hoe het moest worden opgesteld.

De meerwaarde van het maken van de personas en scenario is dat we reeds in de beginfase van het

project een goed beeld hadden van de functionaliteit van de applicatie en dat we ons beter konden

inleven in de gedachtegang van de gebruiker die steeds centraal stond tijdens het ganse proces. De

personas hebben bijgedragen bij het opstellen van het scenario, met name de taken die het moest

bevatten. Het scenario zelf heeft later tot hulpmiddel gediend bij het analyseren van de taken voor het

opbouwen van een taakmodel, hetgeen we in het UCD zien als dé fundering voor het ontwerp van de

applicatie. Persoonlijk vinden we dat de tijd die het opstellen van de personas heeft ingenomen te veel

was in vergelijking met de rest en we zien dan ook het verder nut van deze niet verder in tijdens het

vervolg van het proces. Het scenario opstellen ging uiteindelijk veel sneller en deze heeft wel zijn

bijdrage geleverd tot het proces, namelijk het opstellen van een degelijk taakmodel.

3. Taakmodel en dialoogmodel

Het taakmodel hebben we opgesteld op basis van het geschreven scenario (taakanalyse). We sommen

even enkele trucjes op die we hebben toegepast in de taakanalyse om atomaire operaties te filteren uit

het scenario en ze vervolgens in een CTT te modelleren:

• herken de rollen,

• herken de verschillende taken,

• herken de verschillende atomaire operaties die tot de verschillende geïdentificeerde taken

behoren.



De overgang van het taakmodel naar dialoogmodel verliep vrij vlot. We hebben hiervoor de CTT, het

taakmodel, genomen en vervolgens atomaire operaties gegroepeerd naargelang het feit of ze al dan niet

in combinatie met elkaar plaatsvinden. Indien dit het geval is, nemen we ze op in één dialoog binnen het

dialoogmodel. Na het opstellen van het dialoogmodel konden we reeds zeer goed vaststellen hoe de

navigatie doorheen de applicatie door het model benadrukt werd. Samengevat kunnen we dus stellen

dat het dialoogmodel een werkwijze oplevert om acties te groeperen binnen een user interface en een

zicht te krijgen op hoe de navigatie doorheen de applicatie gebeurt. Het opstellen van het dialoogmodel

op de zonet beschreven manier, leverde ons achteraf bekeken echter een nogal sequentiële navigatie

op. Dit is hoogst waarschijnlijk te wijten aan het groeperen van acties binnen het taakmodel en dit in

combinatie met het groeperen van deze acties in afzonderlijke dialogen. In de toekomst zullen we hier

dus beter rekening mee moeten houden. We zouden dit kunnen doen door in elk dialoog meer globale

operaties, die voorkomen in zowat elke taak, op te nemen. Natuurlijk vereist dit op zijn beurt natuurlijk

ook weer een zeer goede beschrijving van de taken in scenario's. We zien hier dus een eerste nadeel van

de beginfase van het gevolgde proces. Bij ons weten is dit dus niet iteratief genoeg, zodanig dat

problemen zoals hierboven beschreven reeds vroeg worden opgelost. De nodes uit het dialoogmodel

hebben we vervolgens gebruikt om uit elk van deze een prototype window te synthetiseren.

• Verklaring update scenario

Bij het opstellen van het taakmodel zijn we tot de vaststelling gekomen dat ons scenario niet

meteen relevante eigenschappen van de te creëren applicatie bevat. We verstaan hieronder een

kalendersysteem, een commentarensysteem en een systeem om artiesten aan reportages te

koppelen. Vanwege de omvang van de taken die we dan zouden krijgen, hebben we ervoor

geopteerd om uiteindelijk enkel de extra optie commentaren in te bouwen. De applicatie

voldoet hierdoor nog steeds aan de opgelegde eisen aangezien we tevens de personas hier

lichtjes aan hebben aangepast. We beseffen natuurlijk wel dat dit in de praktijk niet mogelijk is

aangezien je de eisen van de klant niet zomaar kan wijzigen, maar we hebben dit gewoon

gedaan om ons taakmodel niet al te complex te maken.

4. Low-fidelity Prototyping

• Gebruikte tools

o Webbrowser: PowerPoint

Het ontwerpen van de website is redelijk intuïtief daarom hebben we een prototype gemaakt

dat al meer naar medium prototyping toe leunt. We hebben hiervoor PowerPoint gebruikt

omdat het hier net als bij denim mogelijk is om interactieve prototypes te ontwerpen. Het

prototypen ging in PowerPoint vrij vlot, één van de oorzaken hiervan is waarschijnlijk dat we al

veel met PowerPoint gewerkt hebben.



Beoordeling PowerPoint:

PowerPoint is een tool waar je relatief snel en gemakkelijk een prototype mee kunt maken.

Dankzij de gebruiksvriendelijke interface kun je snel verschillende kleuren, vormen, … gebruiken

om je low-fidelity prototype te ontwerpen. Het is ook handig dat je op een eenvoudige manier

interactie aan je prototype kan toevoegen. We kunnen besluiten dat we PowerPoint een

handige en aangename tool vinden om onze protypes mee te maken.

o Mobiel: DENIM

Voor de PDA versie hebben we gebruik gemaakt van DENIM. We hebben voor deze tool gekozen

omdat we een tool wilden gebruiken die we niet bij traditionele programmeerprojecten

gebruiken. Wij hadden voordien nog nooit met denim gewerkt en dit leek ons het ideale

moment om er mee te werken. Bijkomend voordeel is dat denim storyboard ondersteunt en

hier hebben we handig gebruik van gemaakt.

Als je het dialoogmodel en het denim model naast elkaar legt, is er weinig verschil merkbaar.

Beide modellen zijn opgedeeld in de sequentiële stappen van de PDA en worden verbonden met

pijlen die de navigatie aanduiden.

Beoordeling DENIM:

Denim is een tool gemaakt om user interfaces te sketchen met behulp van een computer. Het

achterliggende idee van denim is goed, namelijk dat de gebruiker kan sketchen op een computer

in plaats van met pen en papier. Zo zou de gebruiker tijd kunnen uitsparen. Helaas is DENIM niet

zo gebruiksvriendelijk om mee te werken en heeft het een lange leercurve.

Om een paar voorbeelden op te sommen: om een component te verplaatsen moet je de cursor

op het component houden met de muisknop ingedrukt. Pas na een aantal seconden kun je de

component dan verplaatsen. Dit is niet intuïtief en hier zijn we bijgevolg pas na lange tijd achter

gekomen. Dit is ook niet goed terug te vinden in de help functie. Ook komt er soms een rode lijn

rond een component en we zijn er niet achter gekomen waarom dat soms gebeurt. Ook het

herladen van het scherm duurt regelmatig te lang en heeft vaak als gevolg dat het programma

niet meer werkt. We hadden over het algemeen veel problemen met de stabiliteit van DENIM,

het programma liep regelmatig vast, wat erg vervelend was. Dit alles zorgt ervoor dat er met het

programma niet sneller gesketched kan worden dan met de hand, integendeel, door de lange

leercurve moet men hier veel meer tijd in steken.

De storyboard functie die ingebouwd zit in DENIM is dan wel zeer handig om te gebruiken. Door

pijlen te trekken tussen de verschillende schermen leg je relaties tussen de verschillende

schermen. Met de ‘run’ functie kun je dan de applicatie runnen en krijg je de verschillende

schermen te zien. De applicatie heeft ook een zoomfunctie waardoor je een beter overzicht

krijgt van de verschillende schermen en krijg je een goed beeld hoe de applicatie er in

werkelijkheid gaat uit zien.

In vergelijking met PowerPoint ging het prototypen met PowerPoint een stuk sneller en

eenvoudiger.



o Vergelijking tools met Gummy

Het prototypen met Gummy ging een stuk sneller en eenvoudiger dan met PowerPoint. Het

grote verschil is dat we met Gummy de gebruikelijke user interface elementen gewoon kunnen

slepen naar het canvas, en bij PowerPoint moeten we ze nog zelf gaan tekenen. Dit zorgt ervoor

dat prototyping met Gummy een stuk sneller verloopt. We vonden het dan ook over het

algemeen aangenamer om met Gummy te werken dan met PowerPoint. We missen bij Gummy

wel een manier om interactie toe te voegen aan onze prototypes.

Ook tussen DENIM en Gummy is het belangrijkste verschil dat je onmiddellijk componenten op

je user interface kan slepen, bij denim moet je deze nog eerst zelf tekenen. Het handige aan de

layer versie van Gummy was ook dat de componenten automatisch werden overgenomen naar

de nieuwe layers, waar je deze bij denim telkens opnieuw moest tekenen. Het gebruik van zones

bij Gummy is een positieve ontwikkeling die in andere prototyping tools vaak ontbreekt. Door

gebruik te maken van zones kun je bepalen welke elementen zichtbaar zijn voor verschillende

user interfaces. Over het algemeen vonden we het aangenamer om met Gummy te werken dan

met Denim. Gummy heeft betere functionaliteiten om een user interface te ontwerpen, maar bij

Gummy missen we dan wel het storyboard.

Eén lid van onze groep heeft de versie van Gummy met layers getest en was hier zeer positief

over, de andere groepsleden die de andere versie van Gummy hebben getest waren minder

overtuigd en hebben Gummy ook elk kunnen laten vastlopen.

• Opmerkingen low-fidelity prototype website

De knoppen kunnen mogelijk anders gelabeld zijn dan in het dialoogmodel, maar dit verandert

hun bedoelde interactie niet.

Messageboxen met bevestiging of feedback zijn niet opgenomen in het dialoogmodel aangezien

deze slechts zéér kleine onderdelen zijn van de verschillende taken uit het taakmodel en niet

bijdragen tot het overzicht van navigatie waarvoor het dialoogmodel bedoeld is.

Dialoogmodel versus low prototype website

In de eerste van de low prototypes was het zo dat de PDA volledig gerelateerd was aan het

dialoogmodel, maar het low prototype van de website niet. De volgende zaken zijn anders

opgesteld vanwege de vele ruimte beschikbaar voor de website in vergelijking met de PDA en de

niet zozeer sequentiële aard van de navigatie in een website.

• Geen main dialog venster voorzien.

• Visit Comment is opgenomen in visit article en dus geen aparte dialoog.

• Vanuit het visitgedeelte kan er overal rechtstreeks overgegaan worden naar het controle

paneel.

• Vanuit het controle paneel kan er overal uitgelogd worden ipv enkel en alleen via het article

overview dialoogvenster.



• Het update media en add media dialoog venster zijn in de website popup vensters waarbij

de backknop impliciet via het sluitingsicoon beschikbaar is en de knoppen submit article en

cancel article niet aanwezig zijn aangezien deze zichtbaar zijn in het onderliggende dialoog

om een artikel te updaten of toe te voegen.

Het is namelijk onmogelijk om beide verschillende types low prototypes volledig op elkaar af te

stemmen. Ze zijn echter wel voorzien van dezelfde functionaliteit en deze kleine verschillen ten

opzichte van de PDA low prototype en het dialoogmodel vereisen totaal geen veranderingen

aan het taakmodel hetgeen het feit van dezelfde functionaliteit bevestigt.

We vermelden enkel deze verschillen van het low prototype van website ten opzichte van het

dialoogmodel en passen deze niet aan in het dialoogmodel, omdat we anders hetzelfde zouden

moeten doen voor de PDA en voor de PDA versie gelden deze veranderingen niet.

• Verklaring updates taakmodel – dialoogmodel

We hebben bij het maken van de prototypes gemerkt dat we de ‘cancel’ knop vergeten waren

bij het login venster. Dit hebben we aangepast in het taakmodel en dialoogmodel zodat alles

consequent blijft overeenkomen.

• Expert review medestudenten

o Prototype Website

Verwijderen van artikels

o Heuristiek: Constraints

o Beschrijving: Het is mogelijk artikels van andere auteurs te editen en te verwijderen. Dit

zou niet mogelijk mogen zijn.

o Prioriteit: Hoog

o Aanbeveling: Na het oproepen van het controlpanel en het noodzakelijke inloggen,

enkel de artikels laten zien van de aangemelde gebruiker, zodat deze ook geen controle

heeft over andere artikels.

o Aangepast in prototype: Niet van toepassing: het is net de bedoeling dat de ganse

redactie werkt als een team (kwestie van opvatting natuurlijk).

Navigatie

o Heuristiek: Visibility of system status, flexibility & efficiency of use

o Beschrijving: Het is niet duidelijk waar men zich bevindt als men een pagina bezoekt.

o Prioriteit: Hoog

o Aanbeveling: Breadcrumbs voor een idee te geven waar de gebruiker zich bevindt, om

hem zo sneller een idee te laten vormen van de werkomgeving & een vlottere navigatie

te bekomen.

o Aangepast in prototype: Gebruik van breadcrumbs.

Labels van invoervelden



o Heuristiek: Consistency

o Beschrijving: Op enkele plaatsen ( commentaar toevoegen, artikel toevoegen, media

bestand toevoegen ) is er een veld dat niet voorzien wordt van een label waar de rest

dat wel heeft.

o Prioriteit: Laag

o Aanbeveling: Van een label voorzien en uitlijnen.

o Aangepast in prototype:

� Tekstvak voor commentaar en voor tekst artikel voorzien van label

� Browsevak voorzien van label + vermelding van beperkingen op bestandstypen

Datuminvoer

o Heuristiek: Error prevention

o Beschrijving: Voor het invoeren van de datum is het niet duidelijk of het

dag/maand/jaar is of maand/dag/jaar.

o Prioriteit: Medium

o Aanbeveling: Voorzien van een template naast het invoergedeelte, om zo de gebruiker

van de eerste maal de juiste volgorde te laten invullen of gebruik maken van

selectievakken of gebruik maken van een datepicker.

o Aangepast in prototype: Niet meer van toepassing: datum wordt gezien als date of

creation en wordt dus automatisch ingevuld.

Onduidelijk welke datum men dient in te geven


o Beschrijving: Het is onduidelijk welke datum men dient in te geven bij het aanpassen of

toevoegen van een artikel, is het deze van het evenement, of de datum van toevoegen.

o Prioriteit: Laag

o Aanbeveling: Indien datum van wijzigen of toevoegen, deze automatisch invoeren,

indien datum van het evenement, dient dit duidelijk vermeld te worden.

o Aangepast in prototype: Niet meer van toepassing: datum wordt gezien als date of

creation en wordt dus automatisch ingevuld.

Browse/Attach

o Heuristiek: User control / Error Prevention

o Beschrijving: De benaming is wat dubbelzinnig en het is mogelijk om beide acties in een

willekeurige volgorde uit te voeren.

o Prioriteit: Laag

o Aanbeveling: Eventueel Attach hernoemen, maar niet nodig als bijvoorbeeld deze actie

pas mogelijk wordt als browse succesvol is uitgevoerd.

o Aangepast in prototype: Herschikking van beide knoppen + naam wijziging van Attach

naar “Add to media list”.

Soorten media

o Heuristiek: Documentation

o Beschrijving: Het is niet duidelijk welke media allemaal kunnen worden toegevoegd.

o Prioriteit: Hoog

o Aanbeveling: Een opsomming voorzien van toegestane mediatypes.

o Aangepast in prototype: Boven het invoerveld van een mediabestand is er nu een label

voorzien dat tevens zegt welke bestandstypen zijn toegelaten.



Bevestigen van toevoegen media

o Heuristiek: Consistency and standards

o Beschrijving: Bij het toevoegen van media is het onduidelijk hoe te beves6gen. Er is

geen “Save”, “OK”, “Accept” of ander type knop wat het uiteindelijk toevoegen van de

geselecteerde media uitvoert.


o Aanbeveling: Knop “Accept”, “OK” of “Save” toevoegen.

o Aangepast in prototype: Bevestiging is nu duidelijker geworden mede door de

herschikking van de knoppen en diens naam wijziging.

Geen mogelijkheid tot registreren


o Beschrijving: Bij het inlogformulier bestaat er niet de mogelijkheid om te registreren.

Ook wordt er geen extra informatie getoond voor wie het inloggen voorzien is. Hierdoor

kan de gebruiker verward worden en niet meer weten wat te doen.

o Prioriteit: Hoog

o Aanbeveling: De mogelijkheid tot registreren inbouwen en/of gepaste informatie tonen.

o Aangepast in prototype: Er wordt nu gepaste informatie voorzien + een manier om uit

het loginscherm te ontsnappen (geen cancel meer, maar hyperlink in mededeling).

Link naar control panel


o Beschrijving: Links bovenaan de lijst van het overzicht van alle activiteiten, en de

activiteitpagina staat een knop die naar het control panel verwijst. Als de gebruiker de

pagina van boven naar onder bekijkt (en van links naar rechts), dan zal deze knop

meteen in het gezichtsveld opvallen, waardoor de gebruiker snel geneigd zal zijn om

hierop te klikken. Door het klikken op de knop komt de gebruiker ook onmiddellijk op de

inlogpagina terecht, waar geen verder informatie vermeldt staat en waardoor de

gebruiker op een soort doodlopend punt is gekomen op de site, indien deze niet kan

inloggen.

o Prioriteit: Hoog

o Aanbeveling: De link naar het control panel op een andere plaats zetten, die wel nog

steeds eenvoudig te bereiken is voor de personen die hierop moeten klikken. Dit kan

bijvoorbeeld onderaan de overzichtslijst of de activiteitpagina, of eventueel rechts

boven (iets minder uit het gezichtsveld van de gebruiker).

o Aangepast in prototype: Knop staat nu rechtsboven, net als de Logout knop wanneer

men zich in het control panel bevindt.

Activiteitenlijst sorteren

o Heuristiek: User control and freedom

o Beschrijving: De activiteitenlijst bevat een opsomming van de activiteiten met allerlei

kolommen zoals title, category, author en date. Voor de gebruiker kan het eenvoudiger

zijn als er de mogelijkheid bestaat om de lijst alfabetisch te sorteren naargelang de

kolom die aangeduid wordt. Dit biedt de gebruiker een beter overzicht waardoor het

gemakkelijker wordt om de lijst te doorzoeken, wat zeker van pas kan komen als de lijst

een groot aantal items bevat.

o Prioriteit: Laag



o Aanbeveling: De mogelijkheid om bijvoorbeeld op de header van de kolom te klikken

waardoor de lijst alfabetisch geordend wordt t.o.v. de aangeklikte kolom. Door een

tweede keer te klikken kan bijvoorbeeld de kolom andersom gesorteerd worden.

o Aangepast in prototype: Sorteerbare tabel (kolommen zijn voorzien van pijltje dat de

ordenrichting bepaalt).

Categoriekeuze bij de activiteitenlijst

o Heuristiek: User control and freedom

o Beschrijving: Bij het overzicht van de activiteiten staat er rechtsboven een drop-down

box, waarbij de gebruiker een categorie kan kiezen, waardoor vervolgens enkel de

bijbehorende items getoond worden. Deze lijst zou alfabetisch geordend moeten zijn,

hetgeen zeker tijdbesparend kan zijn indien er veel items toegevoegd zijn, zodat de

gebruiker niet te lang moet zoeken.

o Prioriteit: Laag

o Aanbeveling: Het alfabetisch ordenen van de categorieën in de dropdown box.

o Aangepast in prototype: De categorieën in de dropdown box zijn nu alfabetisch

gerangschikt.

Terug naar overzichtslijst

o Heuristiek: Mapping

o Beschrijving: Als men op de pagina van een activiteit is, staat er bovenaan een knop

Home. Door hierop te klikken gaat de gebruiker terug naar de

homepagina/overzichtslijst van de activiteiten. Deze naamgeving van Home kan

verwarring veroorzaken.

o Prioriteit: Laag

o Aanbeveling: De tekst Home bijvoorbeeld vervangen worden door Overzicht

activiteiten.

o Aangepast in prototype: Home knop vervangen door Article Overview knop.

Pop-ups

o Heuristiek: Consistency and standard

o Beschrijving: Bij het verwijderen van items wordt er een pop-up window getoond,

waarin de boodschap staat om het item te verwijderen of te annuleren. Het gebruik van

pop-ups wordt op websites vaak vermeden, aangezien veel gebruikers over een pop-up

blokkering beschikken, waardoor er een extra melding getoond gaat worden. Hetzelfde

is van toepassing bij het linken van media aan een activiteit.

o Prioriteit: Hoog

o Aanbeveling: De vraag of de gebruiker het item wel degelijk wil verwijderen/het linken

van media aan een activiteit in hetzelfde window tonen.

o Aangepast in prototype:

� Het linken van media aan een activiteit wordt nu in hetzelfde venster getoond

als het artikel (onder de invoervakken van het artikel zelf).

� De bevestigingen worden nog steeds getoond door middel van

dialoogvenstertjes aangezien deze voor ons niet onder de categorie van pop-up

vensters vallen.

Item verwijderen

o Heuristiek: Visibility of system status



o Beschrijving: Als een item verwijderd wordt, wordt er geen feedback gegeven aan de

gebruiker dat dit item wel degelijk verwijderd is. Het zal waarschijnlijk uit de lijst

verdwijnen, die dan wel eerst vernieuwd moet worden. Maar als het een lange lijst is,

dan moet de gebruiker eerst nog zoeken of het item wel degelijk weg is.

o Prioriteit: Hoog

o Aanbeveling: Een boodschap tonen aan de gebruiker dat het item verwijderd is.

o Aangepast in prototype: Er wordt nu na elke mogelijke verwijdering van gegevens een

gepaste informatieboodschap weergeven over wat er precies verwijderd is.

Indeling bij het linken van media


o Beschrijving: De indeling bij het linken van media aan een activiteit kan ervoor zorgen

dat de gebruiker op knoppen klikt, die niet doen hetgeen ze verwachten. Zo is de

Delete-knop rechtsonder het window geplaatst, een plaats waar vaak knoppen staan om

het window te sluiten of te bevestigen. Het is dus mogelijk dat de gebruiker hierop klikt,

uit gewoonte, maar niet heeft gemerkt dat het om te verwijderen is.

o Prioriteit: Hoog

o Aanbeveling: De knoppen verplaatsen, zodat er geen consistentiebreuk is met

bestaande applicaties.

o Aangepast in prototype: Herschikking van alle elementen die bijdragen tot het

toevoegen of verwijderen van media

o Prototype PDA

Navigatie

o Heuristiek: Visibility of system status, flexibility & efficiency of use

o Beschrijving: Het is niet duidelijk waar men zich bevindt als men een pagina bezoekt.

o Prioriteit: Hoog

o Aanbeveling: Breadcrumbs voor een idee te geven waar de gebruiker zich bevindt, om

hem zo sneller een idee te laten vormen van de werkomgeving & een vlottere navigatie

te bekomen.

o Aangepast in prototype: We hebben gekozen om gebruik te maken van een combobox

voor de navigatie op de PDA in plaats van breadcrumbs, wegens de beperkte

schermruimte. Deze combobox geeft aan op welke pagina de gebruiker zich momenteel

bevindt en geeft de gebruiker de mogelijkheid om op ieder moment naar een andere

pagina te navigeren.

Submit

o Heuristiek: Consistency & Standards

o Beschrijving: Het gebruik van het woord submit op meerdere plaatsen.

o Prioriteit: Laag

o Aanbeveling: Hernoemen naar een meer specifieke actielabel zoals “Login”.

o Aangepast in prototype: Hernoemen van submit label naar “login” op de login pagina,

de labels in de andere schermen hebben we zo behouden. De functie van deze knoppen

is bij al deze knoppen gelijk aan ‘save’ en zorgt niet voor verwarring.

Manage Media



o Heuristiek: Consistency

o Beschrijving: De lay-out is verwarrend, het is niet duidelijk welke items bij elkaar horen.

Sommige velden zijn niet voorzien van een titel. Het gebruik van “back” & “cancel” in

hetzelfde dialoog lijkt dubbelzinnig.

o Prioriteit: Hoog

o Aanbeveling: Een betere ordening van de widgets voorzien van een duidelijk label en de

“cancel” knop weglaten om zo een gelijkaardig dialoog te bekomen met het toevoegen

van een artikel.

o Aangepast in prototype: Om dit te kunnen oplossen hebben we de design grondig

aangepast en gebruikt gemaakt van tabbladen om de vele informatie op een ordelijke

manier op één pagina te kunnen behouden. Op het eerste tabblad staat de informatie

betreffende het toevoegen/updaten van een artikel en op het andere tabblad het

toevoegen/updaten van media. Zo is er een coherent geheel en moet de gebruiker niet

meer naar verschillende schermen gaan en kan hij op ieder moment het artikel bewaren

of annuleren.

Visit: Ok-knop

o Heuristiek: Visibility

o Beschrijving: Het is niet duidelijk waartoe deze knop dient.

o Prioriteit: Laag

o Aanbeveling: Beter schikken & labelen.

o Aangepast in prototype: We hebben vanwege de onduidelijkheid van deze knop

besloten de knop weg te laten. Als de gebruiker een categorie kiest in de combobox,

wordt de lijst met artikels meteen vernieuwd. De doelgroep zijn immers ict studenten,

een extra tussenstap is niet nodig en zou bovendien mogelijk voor irritatie zorgen.

Inefficiënte vensterindeling “Visit Overview”

o Heuristiek: Flexibility and efficiency of use

o Beschrijving: Het sorteren op categorie neemt de helft van de pagina in, waardoor het

belangrijkste van deze pagina, namelijk de lijst van festivals, weinig plaats over heeft om

de vele informatie weer te geven.

o Prioriteit: Hoog

o Aanbeveling: De beperkte schermruimte beter indelen, sorteren bovenaan of onderaan,

lijst groot centraal op het scherm.

o Aangepast in prototype: Om meer schermruimte te creëren hebben we besloten de

‘OK’ knop en de ‘view’ knop in dit scherm weg te laten. Dit levert geen problemen op

want de knoppen hebben een overbodige functie en waren niet efficiënt voor de

gebruiker.

Inefficiënte artikelselectie “Visit Overview”


o Beschrijving: Het selecteren van een artikel vereist twee klikken, eerst een titel

selecteren en daarna op de “View” knop klikken, waarna men pas naar het artikel

navigeert.


o Aanbeveling: De lijst groter weergeven en direct selecteerbaar maken, zonder

tussenknop “View”.



o Aangepast in prototype: Deze opmerking hebben we al opgelost bij het voorgaande

punt.

Inefficiënte sorteer / zoekfunctie “Visit Overview”


o Beschrijving: Men kan enkel sorteren op categorie. Er is geen zoekfunctie aanwezig om

in de grote hoeveelheid data vlug een bepaald festival of een bepaalde gebeurtenis

terug te vinden.


o Aanbeveling: Een zoekfunctie voorzien op datum, locatie, auteur en trefwoorden.

o Aangepast in prototype: De zoekfunctie werd uitgebreid met een zoekfunctie op

trefwoorden. Voor een uitgebreidere zoekfunctie is er wegens de beperkte

schermruimte van de PDA geen plaats. Ook is het mogelijk om de lijst zelf alfabetisch te

rangschikken door op de kolomtitel te klikken.

Delete/Quit/Logout

o Heuristiek: Consistency / User Control

o Beschrijving: Delete & Quit gebruiken elk een ander lettertype. Quit & Logout leiden

niet tot hetzelfde resultaat. Logout is niet voorzien van een tussendialoog.

o Prioriteit: Laag

o Aanbeveling: Lettertypes consistent houden, dialoog voorzien bij logout .

o Aangepast in prototype: Als de gebruiker op logout klikt wordt er een extra dialoog

getoond.

Geen mogelijkheid tot registreren


o Beschrijving: Bij het inlogformulier bestaat er niet de mogelijkheid om te registreren.

Ook wordt er geen extra informatie getoond voor wie het inloggen voorzien is. Hierdoor

kan de gebruiker verward worden en niet meer weten wat te doen.

o Prioriteit: Hoog

o Aanbeveling: De mogelijkheid tot registreren inbouwen en/of gepaste informatie tonen.

o Aangepast in prototype: Het is niet de bedoeling van de applicatie dat iedereen toegang

kan krijgen. Enkel goedgekeurde personen mogen artikels toevoegen. Om dit te

verduidelijken wordt er bij het inlog scherm extra informatie weergeven hierover.

Instellen van de categorie bij de activiteitenlijst


o Beschrijving: Bij de overzichtslijst van de activiteiten staat er bovenaan een drop-down

box om de categorie te kiezen, waarop gefilterd kan worden. Daaronder staat een Ok-

knop, die niet duidelijk aangeeft wat de bedoeling is.

o Prioriteit: Laag

o Aanbeveling: Het verplaatsen van de knop naast de drop-down box en het hernoemen

naar Filter bijvoorbeeld kan de duidelijkheid verhogen.

o Aangepast in prototype: Deze opmerking wordt ook besproken bij ‘Visit: Ok-knop:‘ en

daar hebben we beslist om deze knop weg te laten.

Plaatsing Back-button




o Beschrijving: De Back-knop bij de activiteitpagina staat onderaan. Als de pagina een

aantal gegevens (uitleg, foto’s, . . . ) bevat, kan het zijn dat er gescrolld moet worden om

de knop te vinden.

o Prioriteit: Laag

o Aanbeveling: De Back-knop bovenaan het window van de activiteit plaatsen.

o Aangepast in prototype: Dit vormt geen enkel probleem aangezien de knop altijd op

dezelfde plaats blijft staan en er dus nooit gescrolld hoeft te worden.

Feedback na toevoegen van reactie

o Heuristiek: Feedback

o Beschrijving: Als er een reactie toegevoegd wordt aan een activiteit wordt er geen

feedback getoond aan de gebruiker dat de reactie toegevoegd is.

o Prioriteit: Hoog

o Aanbeveling: Gepaste boodschap uitschrijven.

o Aangepast in prototype: Er is een nieuw scherm toegevoegd zodat de gebruiker naar

een overzicht kan gaan van alle commentaar.

Feedback bij management categorieën/activiteiten

o Heuristiek: Feedback

o Beschrijving: Bij het management van de categorieën/activiteiten wordt weinig

feedback getoond. Na het toevoegen, bewerken of verwijderen wordt er geen melding

gegeven of de uitgevoerde actie door de gebruiker wel succesvol verlopen is.

o Prioriteit: Hoog

o Aanbeveling: Gepaste boodschappen uitschrijven na het uitvoeren van de acties.

o Aangepast in prototype: Er moet een grens gevonden worden tussen het geven van

feedback en zorgen dat de gebruiker niet op teveel dialoogboxen moet klikken iedere

keer als hij een bewerking uitvoert. Dit evenwicht is moeilijk in te schatten, want wat

vervelend of handig is voor de ene persoon is dit niet voor de andere persoon. Omdat

dit door de expert review een hoge prioriteit kreeg, hebben we besloten bij alle

bewerkingen extra feedback voorzien in de vorm van dialoogboxen.

Onduidelijkheid van de Browse-button


o Beschrijving: Bij het management van het linken van de media aan een activiteit staat er

een Browse-knop achter een tekstveld. Bij het tekstveld is nergens vermeld wat er

precies aangeduid moet worden.

o Prioriteit: Laag

o Aanbeveling: Het vermelden van een label voor het tekstveld, waardoor het duidelijk

wordt voor de gebruiker wat precies geselecteerd moet worden.

o Aangepast in prototype: Er is een extra label voorzien met de types die toegelaten

worden.

Back & Cancel –button


o Beschrijving: Bij het management van het linken van de media aan een activiteit staat er

zowel een Cancel als een Back-knop. De Cancel -knop gaat terug naar de overzichtslijst



van de activiteiten, terwijl de Back-knop doorlinkt naar de toevoegpagina van een

activiteit. De gebruiker kan in de war geraken en niet weten waarop te klikken.

o Prioriteit: Hoog

o Aanbeveling: Een andere naamgeving aan de knoppen geven.

o Aangepast in prototype: Zie ook de opmerking ‘manage media’. Als oplossing wordt er

nu gebruik gemaakt van tabbladen.

• Verklaring updates 2: scenario, taakmodel, dialoogmodel, low-

fidelity prototypes

Nadat we de expert reviews hadden verwerkt, moesten er een aantal aanpassingen gebeuren

aan de voorgaande modellen om alles consequent te houden.

Concreet zijn er volgende dingen veranderd:

Scenario

In ons scenario lieten we ons persona nog de datum invullen van het artikel,maar aangezien

deze datum de datum van creatie is, hoeft deze niet ingevuld worden en moest het scenario

hieraan aangepast worden.

Taakmodel

• Datum weggehaald bij toevoegen en updaten van een artikel in managegedeelte

• Search functie toegevoegd in visitegedeelte

• View comments toegevoegd in visitgedeelte

Dialoogmodel

• Date veld weggehaald bij add/update article

• Labels gezet bij comment / text article / add jpg, wmv, information bij login

• Login scherm: submit vervangen door login

• Een zoek veld toegevoegd bij visit overview

• Venster view comments toegevoegd (schermruimte PDA te klein, in website als onderdeel

van een artikel zelf gezien, dus geen apart venster)

Low-fidelity prototypes

Search opgenomen in PDA voor de lijst van artikels vanwege plaatsgebrek voor een

uitgebreidere sorteerfunctionaliteit. Deze is dan wel weer voorzien in de website en hier is geen

search opgenomen aangezien er meer plaats is om de gebruiker van een snel en duidelijk

overzicht te voorzien. Deze kan in een latere iteratie mogelijk wel opgenomen worden indien dit

van nut blijkt in de usability tests. Net zoals een paginanavigatie (1-2-3-4) om het aantal artikels

per venster te beperken op voornamelijk de PDA, maar ook voor de website. Hierover waren er

in de expert review echter nog geen klachten.



5. High-fidelity Prototyping

• Gebruikte toolkits

o Webbrowser

We hebben als UIbuilder voor de webbrowser gekozen voor Dreamweaver. Dit omdat je er snel

een website mee kunt opbouwen door middel van ‘drag and drop’. Er is een aparte tab voor de

code en een aparte tab voor design voorzien: hierdoor zie je onmiddellijk wat je hebt gemaakt

en hoe het eruit gaat zien in de webbrowser. We hebben hierbij gekozen om gebruik te maken

van HTML als opmaaktaal. Het is de afkorting van HyperText Markup Language en is de

dominante opmaaktaal voor de specificatie van documenten op het Word Wide Web.

o Mobiel

Voor de PDA versie wilden we eerst gebruik maken van Java (Swing) in de ontwikkelomgeving

van NetBeans. Maar omdat het niet evident is om Java op een PDA emulator te laten

compileren en omdat bovendien niet alle PDA’s Java ondersteunen, hebben we voor een andere

toolkit gekozen. Dit is de Visual Studio ontwikkelomgeving geworden met als programmeertaal

C#. Dit heeft als voordeel dat het makkelijker is om de PDA te testen op de ingebouwde

emulator van Visual Studio. Een ander voordeel is dat C# door het merendeel van de PDA’s

zeker wordt ondersteund.

• Extra veranderingen aan prototype

Website

o Tonen van extra tussendialoog als de gebruiker wilt uitloggen.

o Als je een artikel aan het updaten bent of aan het toevoegen: + "without saving?"

o Show all categories link naast categoryfilter

PDA

o Visit kant: main knop toegevoegd, zodat de gebruiker op elk gewenst moment naar het

main scherm kan terug keren.

o Manage kant: logout link toegevoegd, zodat de gebruiker op elk gewenst moment kan

uitloggen en naar het main scherm kan terug keren.

• Pre-test: veranderingen aan prototypes

Website

o Tooltips

o Zoekveld + zoekknop

PDA

o Een wis knop toegevoegd bij commentaar venster



o Zoek knop toegevoegd (was onduidelijk voor de gebruiker hoe ze hun zoek term

moesten doorgeven aan het systeem)

o Extra check als gebruiker op kruisje klikt om de applicatie af te sluiten

o Logging geplaatst achter de knoppen

o Back to main verwijdert op overviewpanel (dubbele knop)

• Wizard of Oz

We hebben ervoor gekozen om de Wizard of Oz te implementeren in de PDA applicatie. De

wizard of Oz simuleert de functionaliteit van de PDA. Het oorspronkelijke plan was om de

navigatie door de wizard te laten bepalen, maar voor een kleine applicatie als de onze was

dit niet erg nuttig. We hebben er dan voor gekozen om data te laten manipuleren door de

wizard (zie Figuur 1). Op deze manier kunnen we bepalen welke data de testgebruiker te

zien krijgt om zo de functionaliteit van de applicatie te simuleren. Als de testgebruiker moet

wachten op input van de wizard hebben we ervoor gekozen om het scherm van de

testgebruiker te ‘locken’ zodat hij geen gebruik meer kan maken van de applicatie (zie

Figuur 2). Voor de website wordt er echter geen gebruik gemaakt van een dergelijk principe,

maar volgen we een vast scenario om de testgebruiker tijdens de gebruikerstest doorheen

de applicatie te loodsen. Dit scenario is zo gekozen dat alle mogelijke functionaliteit aan bod

komt.



Figuur 1 - Wizard of Oz

Figuur 2 - PDA: wait scherm



• Remote Logging

o Voor de remote logging hebben we logberichten geplaatst achter de knoppen van de

PDA. De logberichten worden dan via het netwerk doorgestuurd naar de wizard die deze

berichten bewaart in een bestand (log.txt).

o Voorbeeld log bestand

-----------------------------------------------------------

Logging started on: dinsdag 20 mei 10:38:17 AM

-----------------------------------------------------------

10:38:22 -- Connected with wizard

10:38:56 -- ------------ ManageArticleButton_Click -------

10:39:00 -- LoginBtn_Click - Username: admin Pwd: admin

10:39:03 -- manageCategoriesBtn_Click

10:39:05 -- addCategoryBtn_Click

10:39:21 -- submitCatBtn_Click (add category)

10:39:24 -- backToOverviewCatBtn_Click

10:39:26 -- addArticleBtn_Click

10:39:50 -- browseBtn_Click (add article)

10:39:59 -- submitBtn_Click (Add article)

10:40:24 -- editBtn_Click

10:40:40 -- deleteEditMediaBtn_Click (Edit article)

10:40:52 -- submitEditBtn_Click (Edit article)

10:40:59 -- deleteArtBtn_Click (article)

10:41:05 -- manageCategoriesBtn_Click

10:41:06 -- editCatBtn_Click

10:41:19 -- submitEditCatBtn_Click (edit category)

10:41:28 -- deleteCatBtn_Click

10:41:39 -- ------------ logoutBtn_Click ------- User stayed for

00:02:39.0937500 on manage side

10:41:40 -- ------------ VisitArticlesButton_Click -------

10:41:51 -- Articles Search/Filter performed

10:42:01 -- CommentsLinkLabel_Click

10:42:02 -- 'add comment' tab selected

10:42:18 -- 'view comment' tab selected

10:42:20 -- BackToArticleButton_Click

10:42:23 -- ------------ MainButton_Click ------- User stayed for

00:00:43.0625000 on visit side.

10:42:24 -- ------------ QuitApllicationButton_Click ------

• Gebruikte design patronen

o Card Stack (1)

- Wat

Zet de inhoud op verschillende panelen of “cards”, en stapel ze op zodat er

maar één zichtbaar is; gebruik tabs om gebruikers ertoe toegang te geven

- Wanneer gebruiken



Wanneer er teveel informatie staat op een pagina. Wanneer de tekst of

componenten verspreid zijn over de user interface, zonder gebruik te maken

van een structuur. Dit kan leiden tot afleiding voor de gebruiker. Een oplossing

zou zijn om de inhoud in verschillende sectie op eenzelfde pagina te plaatsen,

maar dan zou de pagina te groot worden. En gebruikers hebben de neiging om

niet meer dan één sectie tegelijkertijd te zien.

- Waarom

De gelabelde “cards” rangschikken de inhoud in gemakkelijk te lezen deeltjes,

elk deeltje kan nu zonder moeite begrepen worden. Ook is het gebruik van tabs

erg vertrouwd om mee te werken voor gebruikers.

- Toegepast in prototype PDA

� De gebruikers van onze applicatie kunnen commentaar bekijken en

toevoegen aan artikels. Om deze verschillende acties bij elkaar te

houden op één scherm hebben we ze opgesplitst in twee secties en op

verschillende tabbladen gezet(zie Figuur 3).

� Voor het toevoegen en wijzigen van artikels hebben we ook gebruik

gemaakt van tabbladen. We hebben hiervoor gekozen omdat er veel

informatie moest ingevuld worden en dit wegens de kleine

schermruimte van de PDA niet op één scherm paste (zie Figuur 4). Voor

de website was deze opsplitsing niet nodig want daar hadden wel

voldoende schermruimte.

Figuur 3 - PDA: gebruik van Card Stack



Figuur 4 - PDA: gebruik van Card Stack

o Carousel (2)

- Wat

Het carousel design patroon houdt in dat er slechts een subset van een ganse

verzameling afbeeldingen op het scherm getoond wordt. De gebruiker wordt

uitgenodigd om de niet-getoonde of gedeeltelijk getoonde afbeeldingen te

bekijken door middel van pijltjes (scrollen) en/of resp. gradiënt bewerkte

afbeeldingen op de uiteinden van de weergegeven afbeeldingen.

- Wanneer gebruiken

Dit patroon wordt gebruikt om een gebruiker te laten bladeren doorheen een

aantal afbeeldingen.

- Waarom

Dit patroon wordt voornamelijk gebruikt wanneer er te weinig schermruimte ter

beschikking is om alle afbeeldingen te tonen.

- Toegepast in prototype website en PDA

We hebben dit principe toegepast voor het weergeven van de media die

gerelateerd is aan een artikel. Op de PDA hebben we enkel gebruik gemaakt van

pijltjes die aangeven dat de gebruiker horizontaal door de afbeeldingen kan

navigeren (zie Figuur 5). Op de website hebben we dit ook toegepast in

combinatie met een gradiënt op de afbeeldingen op de uiteinden van de

afbeeldingenruimte (zie Figuur 6).



Figuur 5 - PDA: gebruik van Carousel

Figuur 6 - Website: gebruik van Carousel

o Center Stage (3)

- Wat

Plaats het meest belangrijke deel van de UI in de grootste subsectie van de

pagina of het venster, cluster secundaire tools en inhoud er rond in kleinere

panels.

- Wanneer gebruiken

Wanneer de pagina’s primaire taak er uit bestaat samenhangende informatie te

tonen aan de gebruiker, laat hem een document wijzigen of stel hem in staat

een zeker taak uit te voeren. De meeste applicaties kunnen gebruik maken van

Center stage.

- Waarom

Je moet ervoor zorgen dat de gebruiken onmiddellijk de meest belangrijke

informatie (of taak) ziet, zonder dat hij eerst de het hele scherm moet kijken.




We hebben er telkens voor gezorgd dat de belangrijkste informatie zich in het

midden van het scherm bevindt (zie Figuur 7).

Figuur 7 - PDA: gebruik van Center Stage

o Clear Entry Points (4)

- Wat

De interface bevat slechts een klein aantal toegangspunten die taak

georiënteerd en beschrijvend genoemd worden.

- Wanneer gebruiken

Wordt gebruik wanneer we een taakgebaseerde applicatie ontwerpen of een

applicatie die veel gebruikt wordt door first-time of infrequente gebruikers. Het

is ook handig voor sommige websites. Maar als het doel van de applicatie voor

iedereen duidelijk is, en als de meeste gebruikers geïrriteerd zijn door één of

meerdere navigatiestappen (zoals applicaties ontworpen voor middelmatige tot

expert gebruikers), gebruik dit dan niet.

- Waarom

Sommige applicaties en websites tonen de gebruiker een moeras van informatie

en structuur wanneer ze geopend worden. Ze geven de aarzelende gebruiker

geen duidelijk raad van wat eerst te doen. “OK, daar ben ik. Wat nu?”.

Toon voor deze gebruikers een aantal opties om te starten. Als deze opties

overeenkomen met de verwachtingen van de gebruikers, kan hij één van deze

opties kiezen en beginnen te werken. We maken zo de applicatie meer

zelfverklarend.




We hebben bij het main-menu van de applicatie gekozen voor clear entry points

(zie Figuur 8).

Figuur 8 - PDA: gebruik van Clear Entry Points

o Diagonal Balance (5)

- Wat

Plaats pagina elementen op een asymmetrische manier, maar breng het in

evenwicht door de visuele elementen in de linker boven en rechter onderhoek

te plaatsen.

- Wanneer gebruiken

Wanneer er een pagina wordt gemaakt met aan de bovenkant een titel of een

header en een paar linken of actie knoppen (zoals ‘ok’ en ‘cancel’) aan de

onderkant. De pagina is kort genoeg om op het scherm te passen zonder dat de

gebruiker met scrollen.

- Waarom

Visueel aanwezige features zoals titels, tabs, en knoppen moeten bijleveren tot

een gebalanceerde compositie op het scherm. De elementen worden geplaatst

op tegengestelde plaatsen van de pagina en wanneer ze dan ook nog eens op

tegengestelde posities geplaatst worden, brengen ze elkaar in evenwicht.

Het zorgt er ook voor dat de oogbeweging van de gebruiker vlot beweegt van

links bovenaan naar rechts onderaan – dit is een ideale visuele flow voor links-

naar-rechts sprekende talen.




Titels of belangrijke elementen worden standaard links bovenaan het scherm

geplaatst (zie Figuur 9).

Figuur 9 - PDA: gebruik van Diagonal Balance

o Dropdown Chooser (6)

- Wat

Breidt het concept van een menu uit door te kiezen voor een dropdown panel.

- Wanneer gebruiken

De gebruiker moet uit een set van keuzes zijn input bepalen. Dit kan een datum

zijn, of een nummer, als het maar geen tekst is die vrij ingetypt kan worden op

een toetsenbord. Als je wilt dat je user interface die keuze ondersteunt, moet

men gebruik maken van een Dropdown Chooser.

- Waarom

De meeste gebruikers zijn vertrouwd met de dropdownlist component

(combobox). Veel applicaties breiden deze component uit zodat het niet simpele

lijsten zijn. Dit zorgt ervoor dat gebruikers ze zonder probleem begrijpen, zolang

als de componenten een naar beneden gerichte pijl hebben die aangeeft dat ze

geopend worden wanneer er op geklikt wordt.

Door gebruik te maken van een Dropdown Chooser wordt er minder ruimte

ingenomen van het scherm. Zo moet men er niet extra ruimte voor voorzien op

de hoofdpagina.


Om media toe te voegen aan een artikel wordt er gebruikt gemaakt van een

filedialog, die deze Dropdown Chooser ingebouwd heeft(zie Figuur 10 ).



Figuur 10 - Website: gebruik van Dropdown Chooser

o Edit-in-Place (7)

- Wat

Gebruik een kleine dynamische tekst editor zodat de gebruiker tekst kan

veranderen ‘ter plaatse’: plaats de editor direct over de originele tekst in plaats

van een afzonderlijk panel of dialog box te gebruiken.

- Wanneer gebruiken

De user interface bevat tekst die de gebruiker wil veranderen. De namen van de

objecten, labels zijn goede kandidaten.

- Waarom

Als de gebruiker naar een ander panel moet gaan om tekst aan te passen is dat

meestal geen goed idee. De gebruiker kan bijvoorbeeld de editor niet vinden. De

overgang van het ene naar het andere panel kost ook tijd en aandacht van de

gebruiker.


In de website en de PDA zit deze functie automatisch ingebouwd bij de browse

knop bij het toevoegen van media (zie Figuur 11).



Figuur 11 - Website: gebruik van Edit-in-Place

o Global navigation (8)

- Wat

Gebruik een kleine sectie van elke pagina om een consistente verzameling van

links of knoppen te tonen die de gebruiker naar de belangrijkste secties van de

site of applicatie.

- Wanneer gebruiken

Wordt gebruikt wanneer je een grote website, of een applicatie met

verschillende afgescheiden secties of tools maakt. In elk geval willen gebruikers

zich graag direct van de ene sectie naar de sectie andere verplaatsen. Het is ook

noodzakelijk dat je genoeg ruimte hebt en je het niet erg vindt extra elementen

te hebben op elke pagina.

- Waarom

Wordt gebruikt om gemakkelijke navigatie doorheen de website of applicatie

toe te laten en de algemene structuur doorheen de UI duidelijk te maken.

- Toegepast in prototype website

De gebruiker kan doorheen de website navigeren d.m.v. breadcumbs en het

controlepaneel of de ‘afmelden’ knop (zie Figuur 12).


De gebruiker kan doormiddel van de combobox en de ‘Logout’ of ‘Main’ knop

navigeren doorheen de applicatie (Zie Figuur 13).



Figuur 12 - Website: gebruik van globale navigatie

Figuur 13 - PDA: gebruik van globale navigatie

o Jump to Item (9)

- Wat

Wanneer de gebruiker de naam van een item typt, springt het recht naar het

item en selecteert het item.

- Wanneer gebruiken

We gebruiken dit wanneer de interface een srollbare lijst, tabel, dropdown of

combobox of boom om een grote verzameling items voor te stellen. Deze items



zijn meestal alfabetisch of numeriek gesorteerd. De gebruiker wil een bepaald

item snel en accuraat selecteren en liefst nog met het toetsenbord.

Dit patroon wordt dikwijls gebruikt in file browsers, lange lijsten van namen, en

dropdown boxen voor landselectie en dergelijke. Het kan ook gebruikt worden

voor nummers of zelf van kalendertijden zoals maanden of dagen van de week.

- Waarom

Dit wordt gebruikt om mensen te helpen met scannen van lange lijsten van

woorden of nummers. Mensen zijn hier niet goed in, maar computers wel.

Een ander voordeel is dat het de gebruiker toelaat zijn hand op het keyboard te

houden. Scrollen en klikken zijn door deze heuristiek niet nodig en daarom is het

nodig de hand van keyboard naar de muis te verplaatsen.


Gebruikt bij het bladeren naar bestanden. Deze functionaliteit zit al ingebouwd

in de filedialog zelf (zie Figuur 14).


Ook hier gebruikt bij het bladeren naar bestanden. De functionaliteit zit al

ingebouwd in de filedialog zelf (zie Figuur 15).

Figuur 14 - PDA: gebruik van Jump to Item



Figuur 15 - Website: gebruik van Jump to Item

o Liquid Layout (10)

- Wat

Als de gebruiker het venster resized, dan verandert de pagina inhoud consistent

mee zodat de pagina constant “gevuld” is.

- Wanneer gebruiken

Als de gebruiker meer/of minder ruimte wil. Bijvoorbeeld wanneer een pagina

veel tekst bevat (bijvoorbeeld een webpagina).

- Waarom

Het is moeilijk om te voorspellen onder welke omstandigheden een gebruiker

jouw user interface ziet. De grootte van het scherm, de font voorkeuren, en

andere vensters op het scherm van de gebruiker heb je niet onder controle. Het

is met andere woorden moeilijk een optimale pagina grootte te bepalen voor

alle gebruikers.

De gebruikers controle geven over de lay-out van de pagina’s maakt je user

interface flexibeler. Het zorgt e rook voor dat de gebruikers zich minder

angstmatig voelt tegenover de user interface want hij kan de user interface

omvormen naar zijn noden.


Als de webpagina geresized wordt, veranderd de breedte van de kolommen

mee met de schermgrootte, zodat de pagina altijd gevuld is.



o Page Grids (11)

- Wat

Websites hebben nood aan consistentie doorheen gemeenschappelijke

elementen, pagina breedte, gebruik van pagina ruimte en gebruik.

- Wanneer gebruiken

� Creëren / beheren van een groot aantal webpagina’s

� Webpagina’s die gecreëerd zijn door verschillende groepen en

individuen.

- Waarom

Succesvolle websites maken gebruik van een onderliggend grid systeem. Bij het

maken van de grid moet men rekening houden met de ruimte die gaat

ingenomen worden door advertenties, dynamische elementen enz..


Gebruikt gemaakt van templates om de ontwikkelaars en ontwerpers te

ondersteunen. Prototype van website in PowerPoint gemaakt zodat er al een

duidelijk visueel idee is van hoe de website er gaat uit zien. Ook wordt er

gebruikt van een CSS bestand om een consistente stijl te behouden doorheen de

website

o Quick Access Pattern

- Wat

Dit patroon helpt de gebruiker om specifieke pagina’s met belangrijke

informatie of veel bezochte pagina’s te bereiken, waar de gebruiker zich ook

bevindt op de website.


Voor de webbrowser wordt dit ingebouwd als een toolbar en voor de PDA

wordt er gebruik gemaakt van een combobox (zie Figuur 16).

Figuur 16 - Gebruik van Quick Access Pattern



o Row striping (12)

- Wat

Gebruik twee verschillende schaduwen om de achtergrondkleur van de rijen van

een tabel te alterneren.

- Wanneer gebruiken

Wordt gebruikt wanneer de rijen moeilijk visueel te onderscheiden zijn, vooral

wanneer er meerdere kolommen zijn (of meerdere lijnen op een rij).

- Waarom

De informatie in de blokken worden omlijnd en gedefinieerd door zachte

kleuren, zelfs wanneer je geen witruimten kan gebruiken om de gegevens in de

verschillende blokken te onderscheiden. Row striping helpt de gebruiker ook om

een lijn van links naar rechts te volgen zonder dat men zich van lijn vergist.


Er wordt in de tabellen afgewisseld tussen twee soorten blauw zodat de

gebruiker zodat de gebruiker gemakkelijk onderscheid kan maken tussen de

verschillende rijen (zie Figuur 17).

Figuur 17 - Website: gebruik van Row Striping

o Sortable Tabel (13)

- Wat

Het sortable table patroon houdt in dat we bepaalde gegevens in een tabel

plaatsen en de gebruiker de mogelijkheid geven om de gegevens over de rijen te

sorteren volgens de waarde van de kolommen

- Wanneer gebruiken



We gebruiken dit patroon wanneer de gebruiker gegevens moet ordenen,

verkennen of naar specifieke gegevens op zoek is.

- Waarom

De beschikbare gegevens kunnen geordend worden en daarom wordt het

verkennen van gegevens voor de gebruiker vergemakkelijkt en wordt een

zoektocht naar een specifiek gegeven plots zeer efficiënt.


We hebben dit principe toegepast in de website binnen het overzicht van de

artikels (zie Figuur 18).

Figuur 18 - Website: gebruik van Sortable Table

o Tool Tip Invitation (14)

- Wat

Ontwerper geeft de gebruiker hints over wat er zal gebeuren wanneer de

gebruiker klikt op een object.

- Wanneer gebruiken

Je wilt de gebruiker uitnodigen om te klikken of gebruik te maken van het object

waar hij met muis even boven blijft hangen. Zo maak je het duidelijk voor de

gebruiker wat er zal gebeuren wanneer hij hier op klikt.

Je wilt de gebruiker aanmoedigen om gebruik te maken van de feature.

- Waarom

Tooltips zorgen ervoor dat de gebruiker weet welke actie uitgevoerd zal worden

alvorens hij op een object klikt. Dit zorgt ervoor dat de gebruiker gemakkelijker

doorheen de website navigeert.


Dit patroon hebben we enkel toegepast op de website aangezien er op de PDA

geen gebruik gemaakt kan worden van tooltips. De tooltips worden op zoveel

mogelijk plaatsen gebruikt op de website (zie Figuur 19).



Figuur 19 - Website: gebruik van tooltips

o Visual Framework (15)

- Wat

Bij elke pagina gebruik maken van dezelfde basis lay-out, kleuren en stilistische

elementen, maar zorg ervoor dat je het ontwerp genoeg flexibiliteit geeft zodat

je variërende pagina inhoud kan beheren.

- Wanneer gebruiken

Wanneer je een website maakt met verschillende pagina’s of een user interface

met verschillende vensters. Je wilt dat je ontwerp samenhangt en er als één

geheel uitziet. Het zorgt ervoor dat je ontwerp gemakkelijk om te gebruiken is

en dat de gebruiker goed kan navigeren doorheen de applicatie of website.

- Waarom

Als een user interface consistent gebruik maakt van kleur, fonts en lay-out en

wanneer titels en navigatiehulpen telkens op dezelfde plaats staan, weten de

gebruikers waar ze zijn en waar ze dingen kunnen terugvinden. De gebruiker

moet niet telkens opnieuw iedere lay-out onderzoeken van een nieuwe pagina.


We hebben gebruik gemaakt van een consistent kleur en font gebruik doorheen

de website. Ook de navigatiehulpen zoals de ‘Afmelden’ knop staat telkens op

de zelfde plaats, net zoals de breadcrumbs en de linken om een nieuwe

categorie / artikel toe te voegen (zie Figuur 20).


Bij het prototype van de PDA is er ook consistent gebruik gemaakt van kleuren

en font. Belangrijke navigatieknoppen staan altijd op dezelfde plaats op het

scherm (bijvoorbeeld de ‘Logout’ knop) (zie Figuur 21).



Figuur 20 - Website: gebruik van Visueel Framework

Figuur 21 - PDA: gebruik van Visueel Framework



6. Usability test

• Website

Bij de website werden de schermen voor het uitvoeren van de taken gemakkelijk bereikbaar

bevonden. Men kon de taken gemakkelijk voltooien.

Ook de oriëntatie en feedback werden goed onthaald.

We hebben volgende belangrijke problemen ontdekt:

o Zoekknop is niet gekoppeld aan de enter knop.

Oplossing: koppel de zoekknop aan de enter knop.

o De uitwerking van de sortable table was niet duidelijk in de zin dat gebruikers niet wisten

dat ze op de kolomheader moesten klikken om de tabel te sorteren op kolomwaarden.

Oplossing: Aangeven met behulp van het gekende sorteerpijltje.

o De aangebrachte bookmarks op een artikelpagina om naar de top van de pagina te gaan of

secties binnen het artikel te bezoeken werden niet gebruikt. Er werd gewoon gescrolld, we

zouden deze echter niet willen verwijderen aangezien deze waarschijnlijk wel gebruikt

zouden worden op lange termijn.

o Ondanks de korte introductie bleek het niet duidelijk te zijn dat men ingelogd moest zijn om

beheerfuncties uit te voeren. Dit zorgde ervoor dat men niet meteen doorhad dat de

beheerfuncties in het controlepaneel verscholen zitten. Wij zien dit echter niet echt als een

groot probleem in onze applicatie aangezien deze sectie slechts toegankelijk select groepje

door de websitebeheerder samengesteld.

o De titel van media werd, ondanks het gevraagd werd in het testplan, niet altijd ingevuld. Dit

zou er op kunnen duiden dat gebruikers dit overbodig vinden.

Oplossing: we kunnen dit vermijden en mogelijk op basis van de bestandsnaam een gepaste

titel laten genereren.

We hebben verder ook bij telkens één testpersoon enkele problemen ontdekt die het

vermelden waard zijn, maar voor ons niet belangrijk genoeg zijn om op te lossen:

o Het was voor één testpersoon niet duidelijk dat er een zoekfunctie is om artikels te zoeken.

Deze persoon ging gewoon in het overzicht kijken. Aangezien er gewerkt wordt met pagina's

in het overzicht is het van belang de zoekfunctie toch te houden ondanks de intuïtie om de

lijst af te scannen.

o Ook werd het filteren van artikels door één persoon niet als duidelijk ondervonden.

o Eén gebruiker bewaarde zijn artikel niet nadat hij het bewerkt had. Ofwel veronderstelde

deze gebruiker dat het automatisch gebeurde, ofwel veronderstelde hij de verkeerde

functionaliteit bij de Artikeloverzicht hyperlink.

• PDA

Ook bij de PDA werden de schermen voor het uitvoeren van de taken gemakkelijk bereikbaar

bevonden. Er werd wel als opmerking gegeven dat de kleinheid van het PDA-scherm het wat

moeilijker maakte om dingen te vinden. Men vond ook hier dat de taken gemakkelijk te

voltooien waren. Net zoals de oriëntatie en feedback weer als goed onthaald werden.



o We hebben bij de PDA gezien dat het ondanks de korte introductie niet voor iedereen

duidelijk was dat er voor de beheertaken het manage gedeelte moest gebruikt worden.

o We hebben opgemerkt dat wanneer we vroegen af te sluiten bijna iedereen dit met de

knop 'Quit application'-knop in het main-menu deed en niet via het kruisje in de

rechterbovenhoek. De knop "Quit application" bleek in tegenstelling tot wat we dachten

dus toch nuttig.

o De combobox die gebruikt werd voor de globale navigatie werd slechts zeldzaam gebruikt,

we verkiezen er echter voor deze toch te behouden om globale navigatie te ondersteunen.

o We hebben gemerkt dat een aantal gebruikers vergeet te ‘submitten’ na het bewerken van

een artikel. Een oplossing hiervoor zou kunnen zijn het artikel automatisch te bewaren. We

kiezen er echter voor de gebruiker expliciet te laten aangeven dat het artikel bewaard moet

worden. We zouden eventueel wel een waarschuwing kunnen weergeven op de pagina die

aangeeft dat het artikel na aanpassing bewaard moet worden.

o Het tabblad ‘media’ bij het toevoegen en bewerken van een artikel werd door sommige

testpersonen niet onmiddellijk gevonden. We vinden het niet nodig dit probleem op te

lossen aangezien de meerderheid van de testpersonen onmiddellijk door hadden waar ze

de media moesten toevoegen.

o Sommige gebruikers denken een artikel te kunnen aanpassen door er op te dubbelklikken,

dit heeft ons doen beseffen dat dit wel degelijk mogelijk moet zijn.

o Het was voor twee gebruikers niet onmiddellijk duidelijk waar het commentaarvenster zich

bevond. We kiezen er echter voor onze manier van commentaar weergeven te behouden

aangezien wij er van overtuigd zijn dat onze manier een goede manier is op de PDA.

o Het was voor één gebruiker niet onmiddellijk duidelijk dat er uitgelogd moest worden om

naar het visit gedeelte te gaan. Dit zouden we kunnen oplossen door in de navigatie

combobox een link naar het visit gedeelte op te nemen. Als de gebruiker zich in de manage

kant bevindt, kan hij op deze manier onmiddellijk naar het visit gedeelte. Hierbij wordt de

gebruiker automatisch uitgelogd. Op dezelfde manier kunnen we een link opnemen naar

het manage gedeelte in het visit gedeelte.

• Opmerkingen

o De facilitator heeft dikwijls moeten ingrijpen tijdens de gebruikerstest van de website.

Omdat de website een prototype is en dus niet alle functionaliteit aanwezig is, zorgde dit

soms voor verwarring bij de testgebruikers die een vast scenario moesten volgen. Het was

noodzakelijk voor de test dat de facilitator ingreep, anders zou de gebruiker verdwalen

doorheen de website en zich niet meer aan het scenario kunnen houden.

o Think aloud: niet alle testgebruikers waren hier even enthousiast over. Eén testgebruikers

voelde zich duidelijk ongemakkelijk en deed het dan ook bijgevolg niet. Misschien volgende

keer hiermee rekening houden en ervoor zorgen dat ze zich in een afzonderlijke ruimte

bevinden waar niemand hun kan horen. Er waren echter wel gebruikers die dit

voortreffelijk deden en we hebben hier dan ook het één en het ander kunnen uit afleiden.

7. Besluit



We hebben in het project van het vak GGSO van naderbij kennis kunnen maken met de UCD-

procedure. Hierbij hebben we voornamelijk geleerd dat het taakmodel een goede fundering

vormt binnen dit proces en hebben het belang leren inzien van prototyping in combinatie met

testen en aanpassen (iteratief) om zo te komen tot een degelijke user interface. Verder hebben

we ingezien dat de Wizard of Oz techniek echt wel handig kan zijn, maar dan eerder in het geval

van een complexere applicatie aangezien we nu in het geval van onze kleine applicatie eigenlijk

evengoed de functionaliteit volledig en niet gedeeltelijk hadden kunnen implementeren.



Bibliografie

1. [Online] http://designinginterfaces.com/Card_Stack.

2. [Online] http://developer.yahoo.com/ypatterns/pattern.php?pattern=carousel.

3. [Online] http://designinginterfaces.com/Center_Stage.

4. [Online] http://designinginterfaces.com/Clear_Entry_Points.

5. [Online] http://designinginterfaces.com/Diagonal_Balance.

6. [Online] http://designinginterfaces.com/Dropdown_Chooser.

7. [Online] http://designinginterfaces.com/Edit-in-Place.

8. [Online] http://designinginterfaces.com/Global_Navigation.

9. [Online] http://designinginterfaces.com/Jump_to_Item.

10. [Online] http://designinginterfaces.com/Liquid_Layout.

11. [Online] http://developer.yahoo.com/ypatterns/pattern.php?pattern=grid#.

12. [Online] http://designinginterfaces.com/Row_Striping.

13. [Online] http://designinginterfaces.com/Sortable_Table.

14. [Online] http://developer.yahoo.com/ypatterns/pattern.php?pattern=tooltipinvitation#.

15. [Online] http://designinginterfaces.com/Visual_Framework.

ggso project - verslag...een bepaalde fase of taak had met het vak evaluatie van user interfaces. we...

Documents