Informatica — Universiteit van Amsterdam
Bachelor Informatica
Ontwikkeling van User interfaces
Stephan van Eijkelenburg
26 april 2010
Supervisor(s): Dick van Albada, Andy Pimentel Signed:
2
Samenvatting User interfaces bevinden zich overal om ons heen. In het geval van software zijn ze het enige deel van een programma dat door de eindgebruiker gezien wordt. Daarom is de kwaliteit en gebruiksvriendelijkheid hier zeer belangrijk. In dit onderzoek wordt onderzocht wat de eisen zijn voor een goede user interface. Met behulp van deze informatie wordt de kwaliteit van de user interface van Blackboard bepaald en wordt er geprobeerd om op dit vlak verbeteringen aan te brengen.
2
Inhoudsopgave
1 Introductie
5
2 Het onderzoek 2.1 Doel . . . . . . . . . . . . . . . . . . . . 2.2 Methode . . . . . . . . . . . . . . . . . . 2.2.1 Literatuur over user interfaces . 2.2.2 Kwaliteit van bestaande software 2.2.3 Zelf een user interface maken . . 2.2.4 User interface vergelijken . . . . 2.2.5 Verbeteringen voorstellen . . . .
. . . . . . . . . . . . testen . . . . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
7 7 7 8 8 8 8 8
3 Literatuur 3.1 Basis . . . . . . . . . . . . . . 3.2 Tekst . . . . . . . . . . . . . . 3.3 Tijd . . . . . . . . . . . . . . 3.3.1 Interface leren kennen 3.3.2 Frequentie en snelheid 3.4 Nielsen’s heuristics . . . . . . 3.5 SUMI vragenlijst . . . . . . . 3.6 Conclusie . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
9 9 9 10 10 12 13 13 14
4 Blackboard 4.1 Introductie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Methode . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Nielsen’s heuristics . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Visibility of system status . . . . . . . . . . . . . . . . . 4.2.2 Match between system and the real world . . . . . . . . 4.2.3 User control and freedom . . . . . . . . . . . . . . . . . 4.2.4 Consistency and standards . . . . . . . . . . . . . . . . 4.2.5 Error prevention . . . . . . . . . . . . . . . . . . . . . . 4.2.6 Recognition rather than recall . . . . . . . . . . . . . . . 4.2.7 Flexibility and efficiency of use . . . . . . . . . . . . . . 4.2.8 Aesthetic and minimalist design . . . . . . . . . . . . . 4.2.9 Help users recognize, diagnose, and recover from errors . 4.2.10 Help and documentation . . . . . . . . . . . . . . . . . . 4.3 SUMI vragenlijst . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Algeneme kwaliteit . . . . . . . . . . . . . . . . . . . . . 4.3.2 Leerbaarheid . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3 Duidelijkheid . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Specifieke problemen . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Startpagina . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 Grades module . . . . . . . . . . . . . . . . . . . . . . . 4.4.3 Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
15 15 15 15 15 16 16 16 16 16 16 16 17 17 17 17 17 17 17 18 18 19
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
3
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
19 19 19 20
5 Motherboard 5.1 Introductie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 De assignments pagina . . . . . . . . . . . . . . . . . . . . . . . 5.3 Technieken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Wicket . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 Db4o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.3 Dojo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 De opbouw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5 Resultaat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.1 ListPage . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.2 DetailsPage . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.3 AddPage . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.4 EditPage . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6 Problemen en vraagstukken . . . . . . . . . . . . . . . . . . . . 5.6.1 Hergebruiken, of zelf programmeren . . . . . . . . . . . 5.6.2 Fouten en gebreken in bestaande frameworks . . . . . . 5.6.3 Zaken die weinig met de user interface te maken hebben
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
21 21 21 22 22 23 23 23 23 24 24 24 26 26 27 27 28
6 Gebruikersonderzoek 6.1 opzet . . . . . . . . . . . . . . . . . . . . 6.2 resultaten . . . . . . . . . . . . . . . . . 6.3 Opmerkingen bij een dergelijk onderzoek 6.3.1 Nieuw voor de gebruiker . . . . . 6.3.2 doelgroep . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
29 29 30 31 31 31
7 Vergelijking met Sakai 7.1 Assignments module . . . . . 7.2 Opdracht toevoegen . . . . . 7.2.1 Datum invullen . . . . 7.2.2 Validatie . . . . . . . 7.2.3 Rest van het formulier 7.3 Lijst van opdrachten . . . . . 7.4 Opdracht inleveren . . . . . . 7.5 Conclusie . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
33 33 33 33 33 34 34 34 35
8 Conclusie 8.1 Literatuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Huidige software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3 Motherboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37 37 37 37
4.5
4.4.4 JavaScript . . Assignments pagina 4.5.1 Deadlines . . 4.5.2 Conclusie . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
4
. . . .
. . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
HOOFDSTUK 1
Introductie User interfaces zijn vrijwel overal te vinden. Ze worden bijvoorbeeld gebruikt bij het bedienen van een telefoon, het opwarmen van een pizza of bij het programmeren van een videorecorder. User interfaces zijn de onderdelen van een apparaat die een gebruiker gebruikt om het apparaat te bedienen. Bij een telefoon vallen hier bijvoorbeeld de knoppen en het beeldscherm onder. Ook het deel van de software dat de gebruiker ziet en gebruikt valt onder de user interface. Omdat deze user interfaces overal gebruikt worden, is het van groot belang dat ze goed functioneren, en vooral gebruiksvriendelijk en intu¨ıtief werken. Alleen al op het gebied van user interfaces in software zijn er talloze gevallen bekend waar verkeerde beslissingen in het ontwerp gemaakt zijn. Dit heeft als gevolg dat de gebruikers van deze software, die vaak alleen de gebruiksaanwijzing erbij pakken als het echt niet anders kan, niet of moeilijk de gewenste taak kunnen volbrengen[1]. Er is verscheidene literatuur beschikbaar waarin beschreven wordt hoe goede user interfaces gemaakt moeten worden, hoe bestaande user interfaces verbeterd kunnen worden en hoe vervolgens het resulterende user interface getest kan worden op kwaliteit. Tidwell beschreef het maken van goede user interfaces in zijn boek[3]. Ook Joel Spolsky beschreef dit proces, in 2001[1]. Dit deed hij onder andere met behulp van voorbeelden van zowel goede als slechte user interfaces. In deze boeken werd er verder ook uitgelegd wat de gebruikers willen zien bij user interfaces, en wat de reden daarvan is. Al jaren lang zijn onderzoekers bezig geweest met het oplossen van problemen die kunnen optreden bij het maken van software user interfaces. Bij deze problemen kan bijvoorbeeld gedacht worden aan: te ingewikkelde menu’s, knoppen die te klein zijn om makkelijk te kunnen klikken en verkeerd vertaalde teksten. In 1993 schreven Thimbleby en Thimbleby hier al een artikel over[2]. In de jaren hierna is er steeds meer bekend geworden over het gedrag van software gebruikers en hun wensen. De praktijk laat zien dat de resultaten van deze jarenlange onderzoeken lang niet overal toegepast worden[1]. Bij het ontwikkelen van software worden nog steeds fouten gemaakt die soms al meerdere keren zijn beschreven en opgelost. Het is bekend dat er veel fouten gemaakt worden en het is bekend hoe deze opgelost moeten worden. Maar onderzoek over de problemen die tijdens de software-ontwikkeling optreden en als gevolg hebben dat dezelfde fouten opnieuw in de software voorkomen is schaars. Dit onderzoek is gericht op de user interfaces van software. Er wordt gezocht naar het antwoord op de vraag wat de reden is dat er, ondanks de beschikbaarheid van literatuur over het maken van user interfaces, producten op de markt zijn die geen gebruiksvriendelijke user interface hebben. Ook wordt onderzocht wat mogelijke maatregelen en oplossingen voor dit probleem zijn. De beperkingen die bij het ontwikkel-proces opgelegd worden door bijvoorbeeld gebrek aan tijd of geld moeten zo min mogelijk in de weg staan tijdens het maken van een user interface. Om deze probleemstelling op te lossen moet onder andere onderzocht zijn hoe goede user interfaces moeten worden gemaakt, hoe deze moeten worden getest en hoeveel tijd en geld het kost om werknemers dusdanig op te leiden dat ze minder reeds opgeloste fouten maken. Het resultaat van dit onderzoek kan software-bedrijven helpen om, zonder opnieuw het wiel uit te moeten vinden hun software te voorzien van goede user interfaces en hiermee zowel geld als tijd 5
te winnen.
6
HOOFDSTUK 2
Het onderzoek 2.1 Doel De kwaliteit van user interfaces verschilt per software. De ene interface wordt door gebruikers beter ervaren als een ander. Dit onderzoek houdt zich bezig met een aantal vragen betreffende de kwaliteit en de ontwikkeling van user interfaces. Het doel is om antwoord te krijgen op de volgende vragen. 1. Welke kenmerken zorgen ervoor dat een bepaalde user interface als goed en gebruiksvriendelijk wordt ervaren? 2. Welke problemen doen zich voor bij user interfaces van bestaande software? 3. Hoe is het om zelf een user interface te maken? 4. Wat is de kwaliteit van de zelf gemaakte user interface vergeleken met bestaande software en hoe kan het beter? De eerste vraag wordt beantwoord door middel van het naslaan van bestaande literatuur. Hierin worden onderzoeken beschreven waarin onder andere onderzocht wordt wat de gemiddelde gebruiker als ’goed’ beschouwd, en hoe deze ’goede’ user interfaces gemaakt kunnen worden. Ook zijn er in de literatuur methodes te vinden die aangeven hoe een user interface op kwaliteit beoordeeld kan worden. Voor de tweede vraag moet er naar huidige software worden gekeken. Aan welke eisen voor een goede user interface voldoet bestaande software wel en aan welke niet? Voor dit project is vooral software met een, volgens de literatuur, minder goede user interface van belang. Als ´e´enmaal vastgesteld is dat een user interface niet goed is, kan er een poging worden gedaan om te onderzoeken wat hiervoor de reden is. Komt dit bijvoorbeeld door een gebrek aan geld, of tijd? Of heeft de opdrachtgever het belang van een goede user interface onderschat? Met behulp van de antwoorden van de vorige twee vragen wordt er gepoogd een user interface met minder fouten en problemen te ontwikkelen. Dit wordt gedaan door een deel van de functionaliteit van bestaande software na te maken, en hierbij vooral aandacht te besteden aan het gebruiksvriendelijk maken van de user interface.
2.2 Methode In het vorige deel is het doel van dit onderzoek beschreven, en onderverdeeld in vier deelvragen. Voor elk van deze deelvragen is een aparte methode vereist. 7
2.2.1 Literatuur over user interfaces Bij het eerste deel van deze scriptie wordt bestaande literatuur over user interfaces gebruikt. Hier zijn verschillende boeken en artikelen voor beschikbaar, die allemaal omschrijven welke punten ervoor zorgen dat een user interface door de gebruikers als goed ervaren wordt. De meeste van deze boeken zijn bedoeld om programmeurs te helpen met het ontwerpen van een user interface, maar ze kunnen in dit geval ook goed gebruikt worden voor het beoordelen van bestaande software. Of een user interface goed is of niet, wordt door veel mensen als een kwestie van smaak beschreven. In de literatuur wordt er echter een groot gedeelte van dit gebied wetenschappelijk omschreven met feiten en goed onderbouwde argumenten. Hieruit blijkt dat dit gebied van software-ontwikkeling toch wetenschappelijk benaderd kan worden.
2.2.2 Kwaliteit van bestaande software testen In het tweede deel wordt er gekeken naar de user interfaces van bestaande software. Voor deze software is hier het Blackboard systeem, dat onder andere op de UvA gebruikt wordt, gekozen; De Blackboard Academic Suite1 . Dit systeem wordt door meer dan 5.000 instellingen en miljoenen mensen gebruikt2 en is voor veel studenten en docenten een belanglijk stuk software. Blackboard zal, aan de hand van de in het eerste deel van deze scriptie gevonden punten, worden onderzocht op het gebied van user interfaces. Deze informatie kan in het derde deel gebruikt worden om verbeteringen aan te brengen.
2.2.3 Zelf een user interface maken Uiteindelijk wordt er geprobeerd om een applicatie te bouwen die een deel van de functionaliteit van Blackboard bevat, maar een betere user interface heeft. Hierbij kan geleerd worden van de fouten die bij het vorige deel ontdekt worden. Bij dit project wordt er een deel van een applicatie gebouwd die vergelijkbaar is met assignments pagina’s van Blackboard. De functionaliteit hiervan wordt verderop nog precies beschreven. Het doel is om een user intreface te bouwen die niet dezelfde problemen vertoont als die gevonden zijn bij Blackboard Omdat Blackboard een ingewikkeld, closed-source programma is, wordt deze user interface niet direct voor Blackboard geschreven. Als plaatsvervanger van Blackboard wordt het Motherboard project genomen. Het idee achter Motherboard is vergelijkbaar met Blackboard en de functionaliteit is uitbreidbaar met behulp van plugins zoals bijvoorbeeld een ’Assignments’ plugin. Dit project neemt back-end en database werk uit handen, zodat de focus vooral op het ontwikkelen van de user interface kan liggen.
2.2.4 User interface vergelijken Om een volledige beoordeling te kunnen geven is het nodig om een vergelijking te maken tussen verschillende vergelijkbare user interfaces. Naast Blackboard en Motherboard zal hiervoor Sakai gebruikt worden. Op deze wijze kan onderzocht worden welk systeem op bepaalde onderdelen van de user interface voor de beste oplossing heeft gekozen en op welke punten de andere systemen hier verbeteringen kunnen aanbrengen.
2.2.5 Verbeteringen voorstellen Het zelf ontwikkelen van een user interface levert uiteraard geen perfect resultaat op. Uiteindelijk moet ook de kwaliteit van de user interface van MotherBoard beoordeeld worden. In dit hoofdstuk worden er aan de hand van deze beoordelingen suggesties besproken die minpunten van de nieuwe user interface zouden kunnen oplossen.
1 http://blackboard.ic.uva.nl/ 2 http://blackboard.com/Company/What-We-Do.aspx
8
HOOFDSTUK 3
Literatuur Over het onderwerp ’user interfaces’ is minder literatuur beschikbaar dan over veel andere onderwerpen in de programmeer-wereld. Dit komt mogelijk doordat het ontwikkelen van user interfaces tussen informatica en andere vakgebieden valt. Enerzijds is er een design-team verantwoordelijk voor het ontwerp. Dit team moet er vooral voor zorgen dat de interface er mooi uitziet. Anderzijds moeten programmeurs uitzoeken of het ontwerp technisch haalbaar is, of alles snel genoeg kan laden, of de ruimte op knoppen groot genoeg is voor de tekst in alle talen, enzovoorts. Verder is er nog een team dat moet testen of de interface gebruiksvriendelijk is, en of gebruikers makkelijk, zonder al te veel documentatie te lezen voldoende de belangrijkste taken kunnen volbrengen. Bij kleinere projecten zullen de ontwikkelaars in meerdere teams tegelijk zitten, programmeurs zullen dan bijvoorbeeld ook het testwerk doen. Ook in dit geval blijft gelden dat er kennis van meerdere vakgebieden vereist is om een goede user interface te maken. In dit hoofdstuk worden er een aantal theorie¨en en methodes besproken voor het maken van een goed user interface en het beoordelen ervan.
3.1 Basis Het is belangrijk om te weten wat het meest belangrijke doel is bij het maken van user interfaces. In het boek van Joel Spolsky [1] wordt genoemd dat een interface goed ontworpen is als de applicatie zich precies zo gedraagt als de gebruiker het verwacht. Dit wordt hier als volgt omschreven: A user interface is well designed when the program behaves exactly how the user thought it would. Het komt erop neer dat gebruikers van software een bepaald verwachtings-model hebben, ook wel het user model genoemd. Verder gedraagt een programma zich op een bepaalde manier, als er op een knop gedrukt wordt dan wordt er bepaalde code uitgevoerd. Het gedrag van een applicatie wordt het program model genoemd. Het belangrijkste bij het ontwerpen van een user interface is dat het programma zo veel mogelijk doet wat er door de gebruikers verwacht wordt. Oftewel: Het user model moet zoveel mogelijk overeen komen met het program model. Er worden verschillende manieren genoemd om achter het user model van de gebruikers te komen. De makkelijkste manier is om simpelweg een (grote) groep mensen te vragen wat ze zouden verwachten. De beste methode om iets te implementeren is dan de manier die door de meeste gebruikers verwacht wordt. Hierbij moet de groep test-gebruikers wel goed overeen komen met de uiteindelijke doelgroep.
3.2 Tekst Het leesgedrag van de gemiddelde gebruiker wordt door Joel Spolsky [1] beschreven aan de hand van twee stellingen. 9
1. Gebruikers hebben geen gebruiksaanwijzing bij de hand, en als ze die wel zouden hebben, zouden ze hem niet lezen. 2. Gebruikers lezen eigenlijk helemaal niks, en willen dat ook niet. Deze punten laten de manier zien waarop Spolsky verwacht dat een groot deel van de gebruikers zich zal gedragen. Gebruikers van software willen het liefst de applicatie kunnen bedienen zonder een handleiding of een groot stuk tekst te hoeven lezen, en verder willen ze zo min mogelijk lezen. In tegenstelling tot bijvoorbeeld bij het schrijven van een brief, is een correcte zinsopbouw of een beleefde vraagstelling, hier minder belangrijk. Bij een dialoog-scherm die als doel heeft om de gebruiker te vragen of hij echt het programma wil afsluiten, is de tekst: Bedankt voor het gebruiken van dit programma, weet U zeker dat U ” dit programma wil afsluiten?” veel minder functioneel dan de tekst: Stoppen?”. Ondanks dat ” de eerste tekst veel beleefder en een volledige zin is, zien gebruikers liever de tweede tekst bij het afsluiten van een programma. Dit komt doordat men de neiging heeft om zo snel mogelijk op Ja of Nee te drukken. Aangezien bij de eerste tekst de echte informatie pas aan ’t einde staat zal een deel van de mensen de verkeerde knop drukken als ze bijvoorbeeld de dialogen met ’wilt U het bestand opslaan?’ zijn gewend, en daar altijd Nee drukken om af te sluiten. Een ander deel van de gebruikers zal zich eraan ergeren dat ze zich nog moeten concentreren op het lezen en begrijpen van een tekst van het programma, terwijl ze juist zo snel mogelijk willen stoppen met het programma. In figuur 3.1 zijn twee versies van een modem dialoog-scherm te zien[1]. Bij de bovenste versie heeft de maker geprobeerd om duidelijkheid te cre¨eren door middel van een relatief grote hoeveelheid tekst; In het onderste voorbeeld staat vrijwel geen uitleg. Ook hier is de versie met de minste woorden het meest gebruiksvriendelijk. De meeste gebruikers blijken in eerste instantie de uitleg over te slaan, en proberen direct hun taak te volbrengen met behulp van de knoppen waarvan zij verwachten dat het hun zal helpen bij deze taak. Gebruikers die wel de uitleg lezen zullen vaak eerder in de war raken van de tachtig woorden tellende tekst dan dat ze geholpen worden. Het onderste voorbeeld laat zien dat het ook kan zonder uitleg; de woorden ’Add’, ’Remove’ en ’Properties’ spreken voor zich en hebben geen lange uitleg nodig. Deze stellingen over (het lezen van) tekst in programma’s zijn terug te herleiden naar de basisstelling. Als alle onderdelen van een programma precies doen wat de gebruiker ervan verwacht, oftewel: het user model komt overeen met het program model, dan is de behoefte aan een lange tekst met uitleg ook minder. De hoeveelheid uitleg die bij een user interface meegeleverd wordt, is daarom ook vaak een maatstaf voor een deel van de kwaliteit van de user interface.
3.3 Tijd Tijd is een belangrijk concept bij de ontwikkeling van user interfaces. Zowel de programmeur als de eindgebruiker hebben op verschillende manieren met tijd te maken. 1. Een programmeur heeft veel meer tijd om de bediening te leren dan de gebruiker. 2. Taken die vaak gedaan moeten worden, moeten snel gedaan kunnen worden.
3.3.1 Interface leren kennen Programmeurs en ontwerpers zijn vaak maanden of jaren bezig met een applicatie. Door zo lang met de interface bezig te zijn kunnen deze ontwikkelaars zelf vaak moeilijk bepalen of de applicatie gebruiksvriendelijk is of niet. Ze zijn namelijk zo bekend geraakt met de interface dat onderdelen die voor de programmeurs simpel lijken, voor de eindgebruikers totaal onlogisch en ingewikkeld zouden kunnen zijn. Een voorbeeld hiervan zijn de hoeveelheid knoppen op afstandsbedieningen. Elk merk heeft zijn eigen opvattinging over de indeling van de knoppen. Veel types hebben knoppen als: ’function’, ’mode’, ’menu’, ’select’, ’set’, ’source’ en ’program’. De ontwerpers zijn vaak al maanden bezig en voor hen is het volkomen logish welke knop wat doet. Echter, voor een gebruiker die net een nieuwe dvd-speler gekocht heeft van een voor hem onbekend merk, is de knoppen-indeling niet altijd duidelijk. Onder andere prins Philip heeft dit ondervonden 1 . Dit resulteert vaak in 1 http://www.nos.nl/nos/artikelen/2009/10/art000001CA4A62C3ACC42B.html
10
Figuur 3.1: Een voorbeeld van een slechte (boven) en een goede (onder) tekst in een user interface [1]
11
Figuur 3.2: verschillende soorten afstandsbedieningen
twee mogelijkheden voor de gebruiker: de gebruiksaanwijzing lezen of gokken. Beide opties zijn niet optimaal, gebruikers houden niet van lezen, en gokken op de juiste knop kan ongewenste effecten hebben en de kans dat de functie alsnog niet gevonden wordt is ook aanwezig. De conclusie hiervan is dat het belangrijk is om de applicatie zo te ontwerpen, dat ook iemand die niet bekend is met het programma het makkelijk kan leren te bedienen. De ervaring van de programmeur moet dus geen obstakel zijn voor het simpel houden van de interface. De beste user interfaces zijn vaak ook de simpelste.
3.3.2 Frequentie en snelheid Bij het ontwikkelen van een applicatie moet rekening gehouden worden met de doelgroep. De doelgroep heeft een grote invloed op de soort user interface die ontworpen moet worden. Software op een foto-print-computer in een winkel waar men tegen betaling foto’s mee kan afdrukken, die een persoon waarschijnlijk slechts een paar keer per jaar gebruikt, moet een heel ander soort interface hebben dan een programma dat thuis dagelijks gebruikt wordt. Ook per taak, die de applicatie kan uitvoeren, moet gekeken worden naar het aantal keer dat een gebruiker dit ongeveer zal doen. Een functie die zeer weinig gebruikt wordt door gebruikers, zoals de installatie die vaak maar ´e´en keer gedaan wordt, hoeft niet snel uit te voeren te zijn. De prioriteit ligt hier bij de duidelijkheid van de interface. Gebruikers moeten in ´e´en keer alles goed kunnen doen, ook al kost het wat meer tijd. Oftwel, de leertijd voor dit deel van de applicatie moet zeer kort zijn, en dit mag ten koste gaan van de effici¨entie. Een voorbeeld hiervan is een wizard. Het doorlopen van een wizard kost vaak meer tijd, maar als een gebruiker deze maar ´e´en of twee keer gebruikt is dit toch een goede keuze, omdat de duidelijkheid toe- en de kans op fouten afneemt. Aan de andere kant moeten veel uitgevoerde taken snel uitgevoerd kunnen worden. Dit mag op zijn beurt weer ten koste gaan van een uitgebreide uitleg. Een voorbeeld hiervan is het opslaan van een word-document. Tijdens het schrijven van een tekst wordt dit vaak om de paar minuten gedaan. Omdat deze functie zo veel gebruikt wordt, moet deze makkelijk aan te roepen zijn ´en snel uitgevoerd zijn zonder dat de gebruiker er hinder van heeft. In software met een goede user interface is te zien dat hieraan gedacht is. Als een document eenmaal een naam heeft, wordt de gebruiker niet lastig gevallen met een dialoog-scherm met de vraag waar het opgeslagen moet worden en de gebruiker heeft verder ook geen last van het opslaan, omdat hij gewoon door kan typen. Ook is de toetsen-combinatie ctrl + s toegewezen aan het opslaan van het document, hierdoor is de opslaan-functie n´ og sneller beschikbaar. Een uitgebreide uitleg hierover krijgt een gebruiker echter niet te zien. Hierdoor duurt het leerproces voor nieuwe gebruikers langer, maar de effici¨entie voor gebruikers die het wel begrijpen is hier stukken hoger. 12
3.4 Nielsen’s heuristics In 1994 publiceerde Jakob Nielsen een lijst met tien heuristieken die nog steeds veel gebruikt worden. Deze punten geven weer wat er onder andere belangrijk is aan een user interface, en waarop gelet moet worden bij het testen en beoordelen van een user interface. Deze heuristieken kunnen ook gebruikt worden om problemen in bestaande user interfaces op te sporen en in groepen onder te verdelen. 1. Visibility of system status: Het systeem moet de gebruiker altijd laten weten wat er op dat moment gebeurt. 2. Match between system and the real world: Het systeem moet termen en beschrijvingen gebruiken die voor de gebruiker bekend zijn. Hierbij kan gedacht woorden aan de juiste taal of icoontjes die overeen komen met echte objecten. 3. User control and freedom: Wanneer een gebruiker per ongeluk een verkeerde functie kiest moet er een duidelijke uitweg geboden worden. De gebruiker moet makkelijk van een pagina of deel van het programma waar hij niet wil zijn, (terug) kunnen navigeren naar de gewenste pagina. Ook undo en redo functionaliteit helpen hierbij. 4. Consistency and standards: Termen binnen het programma moeten consequent gebruikt worden en zoveel mogelijk aan standaarden voldoen. 5. Error prevention: Fouten moeten zo veel mogelijk voorkomen worden. Gebruikers die op het punt staan iets te doen dat ze wellicht niet willen zouden een bevestigingsscherm te zien moeten krijgen, of de optie zou uitgeschakeld moeten worden. 6. Recognition rather then recall: Het moet zo min mogelijk nodig zijn voor de gebruiker om dingen te onthouden. Alle relevantie opties en objecten moeten op het scherm getoond worden. 7. Flexibility and efficiency of use: Acties die vaak door door een gebruiker uitgevoerd worden, moeten ook snel uitgevoerd kunnen worden. Dit kan bijvoorbeeld met behulp van sneltoetsen. 8. Aestetic and minimalist design: Het ontwerp van de user interface moet alleen informatie bevatten die relevant is. Elk extra stuk informatie maakt de rest van de interface minder duidelijk. 9. Help users recognize, diagnose, and recover from errors: Foutmeldingen moeten duidelijk zijn, precies het probleem omschrijven en mogelijk een oplossing bieden. 10. Help and documentation: Het programma moet een goed help-systeem bieden die makkelijk te benaderen, en gericht is op de taak die de gebruiker wil uitvoeren. Deze lijst met heuristieken kan worden gebruikt om problemen van user interfaces te ontdekken en deze in te delen in categorie¨en.
3.5 SUMI vragenlijst SUMI is een commerci¨ele vragenlijst voor het bepalen van het bruikbaarheidsnieveau van software. De SUMI vragenlijst bestaat uit 50 multiple-choice vragen over bruikbaarheid die elk beantwoord kunnen worden met: ’mee Eens’, ’Geen oordeel’ en ’oneens’. In dit onderzoek wordt deze lijst gebruikt om te meten in hoeverre de eerder gevonden user interface problemen een belemmering vormen voor normaal gebruik van de software. 13
3.6 Conclusie Samengevat zijn dit de belangrijkste eisen voor een goed user interface: 1. Het program model moet zo veel mogelijk gelijk zijn aan het user model ; Het programma moet precies zo reageren als de gebruiker ervan verwacht. 2. De user interface moet zo duidelijk mogelijk zijn. De gebruiker moet zo min mogelijk tekst en uitleg nodig hebben om te bereiken wat hij wil. Te veel of te weinig tekst kan al snel onduidelijkheid cre¨eren 3. De user interface moet voor iedereen duidelijk zijn, en niet alleen voor mensen die er maandenlange ervaring mee hebben (zoals de makers van de software zelf). 4. Veel gebruikte functies moeten snel werken en makkelijk aan te roepen zijn. Bij minder vaak gebruikte functies is dit veel minder belangrijk en heeft duidelijkheid de prioriteit. Het belangrijkste punt blijft dat een user interface goed is als het programma reageert zoals de gebruiker het verwacht. Niet-triviale oplossingen in programma’s zijn vrijwel altijd verkeerd.
14
HOOFDSTUK 4
Blackboard 4.1 Introductie Om erachter te komen wat de kwaliteit van de user interface van Blackboard is en waar mogelijk de problemen liggen, is er een gebruikersonderzoek gedaan. Hierbij hebben docenten, studenten en assistenten hun mening gegeven over onderdelen van Blackboard. Naast de gebruikers van Blackboard worden er ook docenten die ondervraagd die Blackboard weinig of helemaal niet gebruiken. De testgroep bestaat uit vier docenten, twee student-assistenten en twee studenten.
4.1.1 Methode Het gebruikers onderzoek bestaat uit verschillende onderdelen. Een deel van de groep bestond uit personen die regelmatig van Blackboard gebruik maken, en een ander deel gebruikt Blackboard niet of nauwelijks. De Blackboard gebruikers konden op de volgende manieren hun mening geven. • De gebruikers werden gevraagd om een aantal taken met behulp van Blackboard te volbrengen en hierbij hardop na te denken, en eventuele struikelblokken te benoemen. De taak was om onder andere een nieuwe assignment voor een groep studenten toe te voegen, deze aan te passen, in te leveren, en uiteindelijk de resultaten te bekijken. Het doel van dit onderdeel is om erachter te komen waar de problemen in Blackboard liggen, en welke problemen gebruikers tegenkomen bij het uitvoeren van gebruikelijke taken. • Iedere gebruiker vult een SUMI vragenlijst in (3.5). Dit onderdeel heeft als doel om de mate van problemen en ergenissen te bepalen. • Ook krijgen de gebruikers de kans om opmerkingen te plaatsten over de werking van Blackboard in het algemeen. Verder werd er gevraagd naar de reden dat sommige personen Blackboard niet of maar in beperkte mate gebruiken.
4.2 Nielsen’s heuristics Tijdens het onderzoek is er een aantal problemen van Blackboard gevonden. Deze kunnen grotendeels worden onderverdeeld in heuristieken van Nielsens (3.4).
4.2.1 Visibility of system status Uit het onderzoek is gebleken dat gebruikers het onder andere lastig vinden om te zien waar ze zich in de applicatie bevinden, en wat de status is. 15
4.2.2 Match between system and the real world Blackboard gebruikt vaak termen waar de gebruiker niet direct de betekenis van kan afleiden. Bij het weergeven van de lijst met assignments staan bijvoorbeeld knoppen met ’manage’ en ’modify’, hierbij is het niet duidelijk welke knop naar welke functionaliteit leidt. Ook de ’ok’ knoppen hebben meerdere functies: soms wordt deze knop gebruikt om een actie te bevestigen en soms leidt deze knop de gebruiker terug naar de vorige pagina. In dit geval zou de tekst ’terug’ of ’back’ veel duidelijker zijn.
4.2.3 User control and freedom Gebruikers vinden de navigatie in Blackboard vaak onduidelijk. Hierdoor heeft de docent vaak geen idee hoe hij na een verkeerde keuze of actie weer terug kan keren naar de vorige pagina.
4.2.4 Consistency and standards De gebruikers vinden het vervelend dat Blackboard t´e consequent is in het weergeven van bevestigingen. Na het uitvoeren van bijna elke actie krijgt de gebruiker een nieuwe pagina te zien met een bericht dat de actie wel of niet succesvol was, hierna kan de gebruiker verder gaan door op de ’ok’ knop te drukken. Hierdoor moeten gebruikers vaker klikken dan ze nodig vinden om acties uit te voeren en dit wordt als vervelend ervaren. Verder hebben gebruikers last van gebrek aan consistentie bij de functies van bepaalde knoppen. Zoals hierboven genoemd vinden gebruikers het lastig in te schatten wat knoppen als ’ok’ betekenen, omdat de functie van deze knop niet standaard is in de hele applicatie.
4.2.5 Error prevention Tijdens het testen zijn de gebruikers een aantal problemen en fouten tegen gekomen. Een aantal van deze problemen hadden voorkomen kunnen worden als Blackboard op een aantal punten anders was opgezet. Het veelvuldig gebruik van JavaScript en Java Applets vergroot de kans op problemen in verschillende browsers. Dit heeft eerder tot problemen met het uploaden van bestanden geleid en ook tijdens het onderzoek was een pagina vol JavaScript die het niet in een bepaalde browser deed. Zelfs in de documentatie wordt uitgelegd dat bij gebruikers met windows Vista en Internet explorer 7 het invoeren van tekst niet goed werkt. Ook is het hierdoor voor de gebruiker verplicht om JavaScript in Java ingeschakeld te hebben om normaal van Blackboard gebruik te kunnen maken.
4.2.6 Recognition rather than recall Wanneer de gebruiker een taak wil uitvoeren moet hij goed hebben onthouden hoe dat in zijn werk ging. De gebruikers vinden het door onduidelijke navigatie en grote keuze aan mogelijkheiden moeilijk om de juiste functionaliteit te vinden. Een voorbeeld hiervan was een gebruiker die zes maanden geleden voor het laatst een assignment had toegevoegd en nu moeite had om te achterhalen hoe dat weer moest. Dit lukte pas na drie pogingen.
4.2.7 Flexibility and efficiency of use Blackboard biedt ondersteuning voor het klonen van cursussen. Hierdoor kan een docent een cursus die elk jaar gegeven wordt snel opnieuw instellen voor gebruik in het nieuwe jaar. Op andere punten kunnen gebruikers echter minder efficient werken. Onder andere doordat vrijwel elke actie ´e´en of meerdere bevestigingspagina’s oplevert vinden gebruikers dat effici¨ent en snel werken lastig gemaakt wordt.
4.2.8 Aesthetic and minimalist design Gebruikers vinden de user interface van Blackboard zeer onduidelijk en omschrijven het als afschrikwekkend en log. Er zijn te veel mogelijkheden voor de gemiddelde en deze worden niet logisch weergegeven. 16
4.2.9 Help users recognize, diagnose, and recover from errors Meldingen ter voorkoming van fouten zijn volgens de gebruikers niet toereikend. Blackboard helpt de gebruiker niet genoeg om het probleem te op te lossen door de fout goed te omschrijven en een mogelijke oplossing te bieden. Als het een docent bijvoorbeeld niet gelukt is om een assignment goed toe te voegen, hebben zij vaak geen idee hoe dit komt, en hoe ze dit kunnen oplossen.
4.2.10 Help and documentation Documentatie zou volgens Nielsen’s heuristics makkelijk doorzoekbaar, gericht op de taak van de gebruiker en niet te groot en overzichtelijk moeten zijn. E´en van de klachten over de help paginas is dat ze niet makkelijk te vinden en te bereiken zijn. De help is te vinden in ´e´en van de modules op de beginpagina van de gebruiker. Als de gebruiker deze module gesloten heeft is de help echter moeilijker te vinden. Ook is het verwarrend dat de help knop die altijd zichtbaar boven aan de pagina te vinden is, naar een andere help pagina leidt. Mede hierdoor maken niet veel gebruikers gebruik van de help paginas.
4.3 SUMI vragenlijst Het invullen van de SUMI vragenlijst leverde gegevens op over de problemen waarvan gebruikers last ondervinden en de hoeveelheid irritatie die deze opleveren. Bij iedere van de 50 stellingen kan de gebruiker kiezen tussen een positief antwoord, een negatief antwoord of voor de optie ’Geen oordeel’. Gemiddeld hebben de gebruikers bij slechts 8 procent van de stellingen positief antwoord gekozen. Over gemiddeld 41 procent van de stellingen hadden de gebruikers geen oordeel en op de resterende 51 procent van de punten vond men Blackboard niet goed. Verder waren de gebruikers het op ongeveer 20 procent van de punten allemaal met elkaar eens. De belangrijkste resultaten worden in dit hoofdstuk beschreven.
4.3.1 Algeneme kwaliteit Op de stelling ’Het gebruik van dit computerprogramma is frustrerend.’ antwoorde iedere gebruiker bevestigend. Hieruit blijkt dat de eerder genoemde problemen als gevolg hebben dat het werken in de Blackboard omgeving onprettig is. Verder was iedereen het er mee eens dat Blackboard niet altijd doet wat de gebruiker ervan verwacht en dat het onhandig werkt als men iets wil doen dat afwijkt van het normale.
4.3.2 Leerbaarheid De leerbaarheid van Blackboard wordt ook door de gebruikers bekritiseerd. Iedereen vindt dat het leren omgaan met Blackboard in het begin veel problemen oplevert en gebruikt het liefst aleen voorzieningen waar hij of zij bekend mee is.
4.3.3 Duidelijkheid Verder wordt het programma zeer onduidelijk gevonden. Het is niet in ´e´en oogopslag, gemakkelijk te zien wat de verschillende mogelijkheden zijn. Ook wordt gevonden dat de berichten van Blackboard niet behulpzaam zijn en niet helpen ter voorkoming van fouten.
4.4 Specifieke problemen Naast de punten die hiervoor als resultaten zijn genoemd, zijn er ook een aantal specifiekere problemen van de user interface van Blackboard naar voren gekomen. 17
Figuur 4.1: Het beginscherm van Blackboard
4.4.1 Startpagina Te veel keuze Direct na het inloggen vallen er een aantal dingen op bij blackboard (figuur 4.1). De pagina bestaat, afgezien van het logo en de bovenste paar knoppen, volledig uit kleine panelen, of hoe ze door Blackboard genoemd zijn: modules. Deze modules kunnen door de gebruiker toegevoegd, aangepast en verwijderd worden. Hierdoor krijgen de gebruikers een grote mate van vrijheid en kunnen ze zelf precies bepalen hoe hun blackboard-startpagina eruit ziet. Deze hoeveelheid en keuze is in sommige gevallen goed, maar het kan ook de oorzaak van problemen zijn. De actie die gemiddeld genomen waarschijnlijk het meest uitgevoerd wordt vanaf deze pagina, is het kiezen van een vak of cursus waar men informatie over wil weten. Omdat het kiezen van een cursus via ´e´en van de modules gaat, en deze volledig aan te passen zijn, kan dit op veel verschillende manieren. Er is dus geen globale manier voor het navigeren naar een cursus. Dit heeft ook als gevolg dat het wisselen tussen verschillende cursussen moeizaam gaat; eerst moet de gebruiker terug gaan naar de start-pagina, en dan pas kan er via de course-module een andere cursus aangeklikt worden. Hierdoor duurt een taak die naar verwachting veel wordt uitgevoerd door een gebruiker, het wisselen tussen cursussen, twee keer zo lang als nodig is. Hier scoort de ’Flexibility and efficiency of use’ zoals uitgelegd in 3.4 dus laag. Figuur 4.1 laat ook nog een probleem zien. Er staan drie modules open die allemaal de mogelijkheid bieden om een cursus te kiezen. Twee daarvan geven zelfs precies dezelfde data weer, met als enige verschil een andere titel en iets andere opmaak. Deze inconsistentie kan als verwarrend worden ervaren. Kort gezegd is goed dat Blackboard keuze biedt voor het aanpassen van de pagina, maar te veel keuze op dit gebied kan tot onduidelijkheid of ongewenste situaties leiden.
4.4.2 Grades module Een voorbeeld van een onderdeel waar het user model niet overeen komt met het program model (probleem uit 3.1). Bij de grades module, die aan de startpagina toegevoegd kan worden, hebben gebruikers een bepaalde verwachting. Veel gebruikers verwachten dat hier het gemiddelde of gewogen cijfer van een aantal vakken te zien zal zijn. Het gedrag van de grades module wijkt echter sterk van deze verwachting af. Bij het merendeel cursussen is er achter de naam van de cursus geen cijfer te vinden. Dit komt soms doordat er geen cijfers van het vak bekend zijn, maar in andere gevallen zijn er wel degelijk cijfers bekend maar worden deze niet weergegeven. Bij de overige vakken, waar Blackboard er wel in geslaagd is om cijfers van een cursus te achterhalen, wordt er geen gemiddelde weergegeven. In plaats daarvan worden alle cijfers bij elkaar opgeteld hierdoor zijn er cijfers als 41.5 mogelijk. Dit alles maakt de grades module op de startpagina 18
onbruikbaar voor iedereen die verwacht zijn gemiddelde- of eindcijfer te zien.
4.4.3 Logo Een ander (klein) probleem op de startpagina heeft te maken met het logo linksboven aan de pagina. Over het algemeen is het standaard dat klikken op de link van het logo-plaatje van een website resulteert in het navigeren naar de begin- of startpagina van de website. In het geval van Blackboard, gaat de link naar http://www.uva.nl. Gezien er op de klikbare afbeelding staat ’UvA Blackboard’ zouden gebruikers kunnen verwachten naar het begin van de UvA Blackboard site te navigeren.
4.4.4 JavaScript Het gebruik van JavaScript breng extra complexiteit met zich mee. Er moet voor elke (grote) browser apart getest worden of alles nog werkt en verschillen in JavaScript implementaties moeten per browser worden opgelost. Browserproblemen Dat dit tot problemen kan leiden bleek aan het begin van het academisch jaar 2008/2009 aan de UvA. Na een update van Blackboard bleek dat de upload-functie, die van groot belang is voor de assignments pagina, niet meer werkte voor gebruikers met een andere browser dan Internet Explorer of Safari. Bijna de helft1 van de gebruikers kon geen opdrachten meer inleveren via hun standaardbrowser.
4.5 Assignments pagina De assignments pagina is een veel gebruikt onderdeel van Blackboard. Op deze pagina kunnen studenten de opdrachten bekijken die door docenten of assistenten zijn toegevoegd voor een bepaalde cursus. Deze opdrachten kunnen bestaan uit een stuk tekst en een lijst van meegeleverde bestanden. De studenten kunnen vervolgens de opdracht inleveren door middel van een formulier met een tekstveld en de mogelijkheid om bestanden te uploaden. De ingeleverde opdrachten kunnen uiteindelijk weer door de docent of assistent bekeken en beoordeeld worden.
4.5.1 Deadlines Onoverzichtelijk Andere problemen van de assignments pagina hebben betrekking op de deadlines. Voor een gebruiker is het moeilijk om een overzicht van alle deadlines te krijgen. Ten eerste moet er per cursus de assignments pagina bezocht worden. Ten tweede, heeft Blackboard zelf geen manier om deadlines weer te geven. Docenten kunnen bij het toevoegen van een assignment wel kiezen tot welk moment de opdracht ingeleverd kan worden, na dit tijdstip verdwijnt de opdracht voor de studenten uit de lijst, maar dit tijdstip wordt niet door Blackboard aan de gebruiker getoond. Dit legt de verantwoordelijkheid van het weergeven van de deadline bij de docent, die het moment van de deadline ergens in de beschrijving of titel van de opdracht kwijt moet. Elke docent kiest hier zijn eigen manier voor, en dit kan tot onduidelijke situaties leiden. Als een deadline weergegeven wordt als bijvoorbeeld: ’11 april’, dan is het voor de student niet duidelijk of de opdracht v´o´or 11 april ingeleverd moet worden, of of dit nog kan op 11 april zelf tot 23:59. Ook bij tijden kan er onduidelijkheid ontstaan over er bijvoorbeeld 10 uur ’s ochtends of ’s avonds bedoeld wordt. Verder kan het allemaal nog ingewikkelder worden als er meerdere tijdzones en/of zomertijd in het spel komen. Dit kan opgelost worden door Blackboard de deadline op een geschikte manier te laten weergeven. 1 http://www.w3schools.com/browsers/browsers
stats.asp
19
Figuur 4.2: Nep-formulier voor het inleveren van opdrachten Beveiliging E´en van de doelen van de assignments pagina is om gebruikers de opdracht op tijd te laten inleveren. Hiervoor is het van belang dat studenten hun werk niet na de deadline kunnen inleveren. Hier zijn verschillende problemen mee geweest die inmiddels deels opgelost zijn. Het eerste probleem had te maken met de ’Save’ functie. Hiermee kunnen gebruikers hun oplossing tijdelijk opslaan, voordat ze deze definitief verzenden. Het was echter mogelijk om na de deadline deze opgeslagen (en niet ingeleverde) oplossing te laden, aan te passen, en vervolgens alsnog te verzenden. Het tweede probleem werd direct na het dichten van het bovenstaande lek ontdekt. Na het verstrijken van de deadline verdwijnt het inlever-formulier voor de opdracht van Blackboard. Een inlever-formulier dat echter voor deze tijd is opgehaald kon nog steeds ingeleverd worden. Op deze manier was het openhouden van de browser genoeg om een opdracht later te kunnen inleveren. Dit resultaat kon ook bereikt worden met een nagemaakt formulier, waarbij de content id en de course id vrij instelbaar is. Figuur 4.2 laat een voorbeeld van zo een formulier zien. Dit probleem had opgelost kunnen worden met ´e´en regel code die vlak voor het opslaan van de inzending van de student de server-tijd controleert.
4.5.2 Conclusie De conclusie van dit gebruikersonderzoek is dat Blackboard op elk van de tien Nielsen’s Heuristics (3.4) tekort schiet. De grootste klacht van de gebruikers is dat Blackboard te onoverzichtelijk is; er wordt niet goed aangegeven wat de verschillende mogelijkheden zijn en het is ook niet duidelijk hoe bepaalde taken moeten worden volbracht. Het gevolg hiervan is dat het gebruik van dit programma frustrerend is en bij sommige gebruikers tot hoofdpijn leidt.
20
HOOFDSTUK 5
Motherboard 5.1 Introductie Motherboard is een open-source project dat opgestart is door Hraban Luyat, Patrick de Kok, Rory Breuk en mijzelf. Het doel is om een schaalbaar en uitbreidbaar project-beheer-systeem te maken dat in meerdere situaties toepasbaar is. ’Project’ is een breed begrip, en kan dus in veel situaties toegepast worden. Als we de term project specificeren naar ’vak’ of ’cursus’ kan Motherboard gezien worden als een ’cursus-beheer-systeem’. Dit is vergelijkbaar met wat blackboard doet, en is dus geschikt als framework om een vergelijkbare applicatie mee op te zetten. Het Motherboard project is uit te breiden met plugins. Deze leveren alle functionaliteit, en zijn onafhankelijk van elkaar te ontwikkelen en toe te voegen. Door het gebruik van deze plugins kan Motherboard flexibel in verschillende situaties gebruikt worden, en doordat alles open-source is kan iedereen plugins ontwikkelen die voor een bepaalde situatie nodig zijn. Net als bij Blackboard, is de server-code van Motherboard geschreven in Java. De kern van Motherboard bestaat de basisfunctionaliteit voor een project-beheer-systeem. De ingelogde gebruiker kan een lijst met projecten waar hij voor ingeschreven bekijken, en er ´e´en kiezen. Vervolgens geeft Motherboard een lijst weer met ’plugins’ (of pagina’s) die voor dat project ingeschakeld zijn. Als de gebruiker een plugin aanklikt, wordt de code van deze plugin uitgevoerd. Kortgezegd, bestaat Motherboard uit drie onderdelen. 1. Projecten. In ons geval de verschillende vakken die bij een universiteit of hoge school gegeven worden. 2. Plugins. Plugins bepalen de functionaliteit, en zijn vergelijkbaar met verschillende pagina’s op Blackboard. Zoals ’Announcements’, ’Grades’ en ’Assignments’. 3. Frontends. Een frontend is een gedeelte van de applicatie dat alles weergeeft. Het belangrijkste, en op dit moment het enige, is het web-frontend dat alle data en plugins kan weergeven via de browser. De poging om een goed werkende user interface te maken tijdens dit afstudeer-project, zal zich richten op ´e´en van deze plugins, op pagina’s; de ’Assignments’ pagina. De keuze is hierop gevallen omdat het ´e´en van de belangrijkere en ingewikkeldere pagina’s van blackboard is, en omdat hier ruimte voor verbetering is.
5.2 De assignments pagina E´en van de belangrijkste functies van Blackboard is de mogelijkheid om opdrachten of assignments te beheren. Dit houdt in dat een docent of assistent opdrachten kunnen toevoegen. Deze opdrachten kunnen vervolgens door studenten ingeleverd worden, en worden uiteindelijk weer 21
door de docent of assistent opgehaald en nagekeken. Dit alles gebeurt op de ’Assignments’ pagina van Blackboard en dit is wat de ’Assignments’ plugin op van Motherboard moet kunnen. Opgesomd, en in taken onderverdeeld, moet de Motherboard-plugin het volgende kunnen: 1. Een docent kan een opdracht toevoegen. Deze opdracht kan een titel, een beschrijving, ´e´en of meerdere bestanden en een deadline bevatten. 2. Bestaande opdrachten kunnen worden aangepast. 3. Opdrachten kunnen worden weergegeven in een lijst, gesorteerd op deadline. Bijbehorende bestanden kunnen worden gedownload. 4. Studenten kunnen, zolang de deadline niet verstreken is, opdrachten inleveren. Hierbij kunnen ze een commentaar-veld invullen en ´e´en of meerdere bestanden uploaden. 5. Zolang de deadline niet verstreken is, kunnen studenten hun inzending bewerken. 6. Als de deadline verstreken is, kunnen studenten niet meer de opdracht inleveren, of hun inzending aanpassen.
5.3 Technieken Zoals gezegd wordt Motherboard, en de assignmens plugin geschreven in Java. Verder worden er een aantal frameworks gebruikt op bepaalde punten. ’Wicket’ helpt bij het maken van de serverside code voor de user interface, ’Db4o’ is een Object-database die zorgt voor alle database functionaliteit en ’Dojo’ helpt bij het schrijven van JavaScript.
5.3.1 Wicket Wicket is een Java web applcication framework, dat wordt gebruikt voor de implementatie van het Motherboard web-frontend. Het levert een deel van de basisfunctionaliteit die nodig is voor het maken van een web-applicatie. Een pagina, in dit voorbeeld genaamd ’TestPage’, geschreven voor wicket, is als volgt ingedeeld: 1. TestPage.html Dit is de statische html, dit bestand bepaalt de opbouw en structuur van de pagina. Elementen die vervangen moeten worden door bijvoorbeeld tekst uit de database krijgen een wicket:id attribuut. 2. TestPage.java In dit bestand bevindt zich de server-side code. Bij het laden van de pagina wordt deze code uitgevoerd, en vervangt het de in TestPage.html aangegeven elementen, met panelen, knoppen, formulieren, labels of andere dingen. 3. TestPage.properties / TestPage nl.properties / etc. De ’.properties’ bestanden geven de mogelijkheid tot internationalisatie. Naast de standaard TestPage.properties, kan er voor elke taal of land een TestPage xx.properties (taalcode) of TestPage xx XX.properties (taal- en landcode) bestand aangemaakt worden. Wicket probeert zelf achter de taal van de gebruiker te komen, maar de taal is ook handmatig in te stellen. 4. TestPage.js / TestPage.css Per pagina is er de mogelijkheid om aparte JavaScript of CSS bestanden te laden. Deze worden in de zelfde map als de .class bestanden opgeslagen, en Wicket zorgt voor een manier om deze bestanden vanuit de package of archive file beschikbaar te maken voor de gebruiker. Verder zorgt wicket voor andere functies die veel werk uit handen kan nemen. Formulieren kunnen makkelijk gevalideerd worden, er is ondersteuning voor Ajax-functionaliteit waarbij er teruggevallen wordt op ’normale’ links als javascript niet aanstaat in de browser, enzovoorts. Een belangrijk onderdeel van wicket is de ondersteuning voor pagina’s die andere pagina’s kunnen bevatten. Om door te gaan met het bovenstaande voorbeeld: er kan een java class genaamd ’InnerPage’ aangemaakt worden die ’TestPage’ extend. Dit heeft als gevolg dat de html in InnerPage.html ingevoegd wordt op een aangegeven punt in TestPage.html. Verder kunnen pagina’s 22
ook aangevuld worden met panelen. Op dit laatste punt is het web-frontend van Motherboard gebaseerd. Elke plugin die geschikt is voor dit frontend, bevat een method genaamd ’handleWWW’. Deze method geeft een Panel terug, en deze wordt weergegeven op de pagina. Dit is feitelijk alles wat een plugin moet kunnen; de plugin krijgt parameters mee via de url, en geeft een Panel terug dat het frontend vervolgens weergeeft.
5.3.2 Db4o Db4o is een Object-database. Deze database is in staat om hele java-objecten in zijn geheel op te slaan. Dit in tegenstelling tot de bekendere relationele databases (zoals mysql en postgresql) waarbij het nodig is om java-objecten te ’mappen’ naar een structuur waar het database systeem mee om kan gaan. Db4o maakt het gebruik van Object-relational-mapping software zoals ’Hibernate’ overbodig, en houdt de code op dat gebied dus simpel. Voor dit project betekent dit dat de focus nog meer op het maken van de user interface kan gaan liggen.
5.3.3 Dojo Dojo is ´e´en van de vele JavaScript-frameworks, en neemt op dit gebied veel werk uit handen. Problemen ontstaan door verschillende interpretaties van JavScript code door verschillende browsers wordt afgehandeld door Dojo. Een voorbeeld van een situatie waarin Dojo goed van pas komt is bij de client-side validatie van formulieren. Dit scheelt de eindgebruiker tijd, omdat de velden tijdens het typen gecontroleerd kunnen worden, en de gebruiker niet moet wachten tot het formulier naar de server wordt gestuurd, de server het formulier controleert, en terugstuurt wat er niet goed is ingevuld. Ook aan de kant van de server levert dit besparingen op in de vorm van minder verbruikte cpu-tijd.
5.4 De opbouw in 5.2 zijn de taken beschreven die met behulp van de Assignments plugin uitgevoerd moet kunnen worden. Op basis hiervan is de Assignments plugin onderverdeeld in een aantal pagina’s. 1. AddPageOp deze pagina kunnen docenten nieuwe assignments toevoegen. Hierbij kan een beschrijving worden gegeven, een deadline ingesteld en bestanden worden ge¨ upload. 2. ListPage Deze pagina geeft een lijst van assignments weer die voor het gekozen vak gelden. Deze lijst is gesorteerd op de datum van de deadline en geeft de belangrijkste informatie over de assignments weer. 3. DetailsPage Deze pagina toont de student de details van een assignment. Hieronder vallen onder andere de beschrijving van de opdracht en een lijst met bijgevoegde bestanden. Deze pagina bevat ook een formulier voor het inleveren van de opdracht. Dit formulier bestaat uit een tekstveld waar de student commentaar in kwijt kan, en een upload mogelijkheid waarme de student ´e´en of meerdere bestanden kan toevoegen 4. EditPage Deze pagina bevat het zelfde formulier als de AddPage, hiermee kunnen bestaande assignments door de docent of assistent aangepast worden. Verder kan hier ook de assignment verwijderd of inactief gemaakt worden en kunnen de ingeleverde opdrachten van alle studenten hier gedownload worden.
5.5 Resultaat Met behulp van de technieken uit hoofdstuk 5.3 en de opbouw uit 5.4 is uiteindelijk een plugin voor Motherboard tot stand gekomen die voldoet aan de eisen gesteld in 5.2. Veel problemen van de Blackboard assignments pagina die in hoofdstuk 4 zijn beschreven worden hier opgelost. 23
Figuur 5.1: De ListPage geeft een overzicht van alle assignments voor ´e´en vak
5.5.1 ListPage Deze pagina geeft een overzicht weer van alle assignments van een cursus (figuur 5.1). De gebruiker kan in ´e´en oogopslag zien welke opdrachten nog gemaakt moeten worden en voor waneer (probleem uit 4.5.1). Vanaf deze pagina kan genavigeerd worden naar de DetailsPage van een bepaalde assignment; docenten kunnen vanuit hier ook naar de Editpage van een assignment gaan. De icoontjes voor de opdrachten geven de inlever-status weer: een groen vinkje betekend dat de gebruiker de opdracht ingeleverd heeft, een oranje uitroepteken geeft aan dat de opdracht nog niet ingeleverd is en een rood uitroepteken betekend dat de opdracht nog niet ingeleverd is ´en dat de deadline binnen 24 uur is, of dat de deadline al verlopen is. Verder wordt er bij het weergeven van de deadline rekening gehouden met het land en de taal van de gebruiker. In figuur 5.1 staat de taal op Nederlands, als deze op Engels staat, wordt de eerste deadline weergegeven als: Deadline: Aug 12, 2009 9:30 PM”. Dit voorkomt onduidelijkheden over de ” precieze deadline.
5.5.2 DetailsPage De DetailsPage geeft de details van een bepaalde assignment weer (figuur 5.2). De titel, deadline, en volledige beschrijving van de assignment zijn hier te vinden. Ook zijn hier alle bestanden te downloaden die door de docent zijn bijgevoegd. De belangrijkste nieuwe functie hier is de mogelijkheid om alle bestanden in ´e´en keer te downloaden. De ’Download all’ knop zipt alle bijbehorende bestanden en stuurt deze naar de gebruiker. Verder bevindt onder het details-paneel zich een inlever-formulier. Deze wordt uitgeklapt na het klikken op ’Hand in solution’ of ’Lever opdracht in’. Hier kan de gebruiker op dezelfde manier als bij Blackboard, zijn oplossing inleveren. Het enige verschil hier zit in het feit dat er bij het uploaden geen JavaScript gebruikt wordt, hierdoor is dit formulier minder kwetsbaar voor browser-bugs (4.4.4).
5.5.3 AddPage De AddPage, (figuur 5.4) is voor docenten bedoeld die een nieuwe assignment aan de pagina willen toevoegen. Dit kan met behulp van het formulier op deze pagina. Hier kan onder andere de titel, beschrijving, deadline, en meegeleverde bestanden ingesteld worden. Een aantal velden zijn met behulp van Wicket en Dojo aangepast om het werk voor de gebruiker makkelijker te maken. Op de verplichte velden zit een JavaScript validator die controleert of het veld goed is ingevuld. Deze validatie gebeurd nog een keer op de server, na het versturen van het formulier; hierdoor werkt deze pagina ook voor gebruikers zonder JavaScript. Verder heeft het deadline 24
Figuur 5.2: De DetailsPage
Figuur 5.3: Het inlever formulier
25
Figuur 5.4: De AddPage veld een JavaScript datePicker die het invoeren van een datum makkelijker maakt. Tenslotte is ook het uiterlijk van een aantal velden met behulp van Dojo aangepast, zo is onder andere het standaard checkbox-vinkje vervangen.
5.5.4 EditPage De EditPage (figuur 5.5) bevat een paneel met het zelfde formulier als bij de AddPage gebruikt wordt. Hiermee kunnen bijna alle eigenschappen van de assignment aangepast worden. Hiernaast bevat deze pagina ook een knop om de assignment mee te verwijderen. Ook kan er gezien worden hoeveel van de ingeschreven studenten de opdracht ingeleverd hebben. Een belangrijk onderdeel van deze pagina is de mogelijkheid om met ´e´en knop alle inzendingen te downloaden. Per student wordt het commentaar dat ze op de inleverpagina hebben ingevuld opgeslagen in een tekstbestand. Dit tekstbestand wordt samen met al hun ge¨ uploade bestanden in een map verzameld en deze map wordt samen met de mappen van de andere studenten in een zip bestand gestopt en ter download aangeboden aan de docent.
5.6 Problemen en vraagstukken Tijdens het maken van de Assignments plugin voor Motherboard dook er een aantal problemen en onverwachte situaties op. Uiteindelijk duurde het uitvoeren van een bepaald idee altijd langer dan verwacht. Hier is een overzicht van de problemen en moeilijke beslissingen die voor de meeste 26
Figuur 5.5: De EditPage belemmering zorgden.
5.6.1 Hergebruiken, of zelf programmeren E´en van de belangrijkste vragen bij het maken van deze user interface was de vraag hoe een bepaald idee verwezenlijkt zou moeten worden. In vele gevallen was er de keuze tussen het zelf verzinnen van een implementatie, of het zoeken naar een bestaande library die de gewenste functionaliteit implementeert. Beide keuzes hebben hun voor- en nadelen, en in het maken van deze afweging kan veel tijd gaan zitten. Bij het maken van deze plugin waren er de volgende problemen: Bij het zelf implementeren, was het resultaat vaak minder goed dan een bestaande oplossing en bij het hergebruiken van een bestaande oplossing, was het vaak veel werk om deze precies naar wens aan te passen, en bleek de oplossing soms toch niet mogelijk voor die situatie. Een bestaand framework gebruiken kan veel werk uit handen nemen, en stabielere code opleveren, maar elke keer dat er een framework overwogen wordt, moet de programmeur zich verdiepen in de documentatie ervan, en hopen dat alles naar wens werkt en er geen bugs zijn.
5.6.2 Fouten en gebreken in bestaande frameworks In dit project worden ’slechts’ twee frameworks gebruikt voor het frontend. Beide hebben ze veel werk uit handen genomen, maar door ontbrekende functies en fouten leverde Wicket en Dojo toch enige problemen op. Nested dir zip Wicket had standaard de mogelijkheid om zip-link aan een pagina toe te voegen. Deze link zipte na het aanklikken in-memory een bepaalde directory en uploadde dat naar de gebruiker. Dit werkte perfect voor het downloaden van een map met bestanden die bij een assignment horen. Deze link zou ook gebruikt kunnen worden voor het downloaden van een zip bestand met de inzendingen van alle studenten. Het probleem was echter dat de bestanden van de studenten verdeeld over verschillende mappen waren (voor elke student ´e´en) en dat de zip-link van Wicket geen ondersteuning bood voor nested directories en een foutmelding teruggaf. Om dit netjes op te 27
lossen moest de source-code van Wicket veranderd worden. Het doorzoeken van onbekende code kan moeilijk en tijdrovend zijn, en de tijd die dit kost was vaak niet vantevoren te voorspelen. In dit geval is het gelukt om succesvol een aanpassing te maken in de source. Deze patch is vervolgens geaccepteerd en toegepast in de trunk van het Wicket project 1 . Dojo, uitbreidbaar tekstveld Dojo heeft de mogelijkheid om een text-area uitbreidbaar te maken. Hierbij ’groeit’ het textveld in de hoogte elke keer als een gebruiker een nieuwe regel gebruikt. Dit leek perfect te zijn voor de ’beschrijving’ en ’commentaar’ text-areas van de formulieren. Na enig test-werk bleek dit goed te werken in vrijwel elke grote browser en werden deze verbeterde textareas toegepast. Een paar weken later, en een aantal ’stille’2 Chrome updates later, bleken deze velden niet meer goed te werken in Google Chrome, het veld groeide een aantal pixels bij elke toetsaanslag, ook bij het drukken van een pijltjes-toets of het aan- of uitzetten van caps-lock. Dit soort fouten zijn vaak onverwachts, en kunnen veel tijd kosten als blijkt dat de functie hierdoor t´ och niet bruikbaar is en uit de applicatie gehaald moet worden.
5.6.3 Zaken die weinig met de user interface te maken hebben Uiteindelijk is er het probleem dat de programmeur van de user interface, zich veel moet bezig moet houden met zaken uit andere vakgebieden. Hij moet bijvoorbeeld enige database en cache kennis hebben, om de interface zo te implementeren dat de database efficient aangeroepen wordt, en niet onnodig veel belast wordt. Aan de andere kant moet er bepaald worden in hoeverre deze data gecached moet worden en of hier geen problemen kunnen ontstaan. Ook moet de user interface ontwerper enige kennis van de psychologie van zijn doelgroep hebben om er zo achter te komen wat het user model van de doelgroep is. Verder moet de interface ook nog mooi gevonden worden. Deze punten zorgen ervoor dat het vakgebied van het ontwerpen van user interfaces erg verstrengeld is met andere wetenschappen. Hierdoor blijft het moeilijk om een team hiermee bezig te laten zijn.
1 https://issues.apache.org/jira/browse/WICKET-2230 2 http://www.zdnet.com.au/news/software/soa/Google-quietly-updates-Chrome/0,130061733,339291869,00.htm?omnRef=1337
28
HOOFDSTUK 6
Gebruikersonderzoek Om de kwaliteit van de uiteindelijke user interface te testen is er een gebruikersonderzoek nodig. Hierbij wordt de applicatie getest door een aantal personen, die zonder eerdere ervaring met Motherboard, een aantal basistaken proberen uit te voeren. Op basis van deze ervaringen vullen ze een beoordelingsformulier in waarin ze de gebruiksvriendelijkheid van de applicatie beoordelen.
6.1 opzet Elke tester begint zijn onderzoek op een startpagina. Op deze pagina is te vinden: 1. Een uitleg over het doel van het onderzoek en een introductie. 2. Een lijst van opdrachten en taken die de gebruiker moet proberen uit te voeren. 3. Een link naar de applicatie die getest wordt. 4. Een link naar het beoordelingsformulier. Ook wordt bij het bezoeken van deze startpagina de database naar een bepaalde beginsituatie hersteld. In deze beginstaat, geeft de database een realistische situatie weer waarin er twee assignments op de pagina staan. Vervolgens is het de bedoeling dat de tester een lijst van opdrachten en taken volbrengt. Deze lijst bevat taken voor zowel docenten als studenten. De tester wisselt dus tijdens het uitvoeren van de taken van rol tussen docent en student. Dit staat per opdracht aangegeven. De taken zijn onder andere: 1. Voeg een nieuwe assignment toe 2. Lever deze opdracht in als student 3. Wijzig een bestaande opdracht 4. Download de ingezonden oplossingen van een opdracht Uiteindelijk kunnen de testers aan het einde van het onderzoek een beoordelingsformulier invullen waarin zij hun mening en commentaar kunnen geven. In dit formulier worden de volgende vragen aan de gebruikers gesteld. 1. Worden de deadlines overzichtelijk weergegeven? 2. Is het goed te zien welke opdrachten je wel en niet hebt ingeleverd? 3. Worden de beschikbare opties duidelijk weergegeven? 4. Ging het invullen van het fomulier makkelijk en zoals verwacht? 29
Figuur 6.1: Resultaten gebruikersonderzoek
5. Ging het wijzigen van de deadline goed? 6. Ging het downloaden van de opdrachten goed? 7. Wat is de algemene gebruiksvriendelijkheid? Bij elk van deze vragen is er de mogelijkheid om een cijfer, en commentaar te geven.
6.2 resultaten De testgroep bestaat uit tien mensen met verschillende achtergronden, vari¨erend van student en docent tot oprichter van een website-ontwikkel bedrijf. Drie testpersonen waren docenten of student-assistenten, vijf waren studenten, en twee waren personen zonder eerdere ervaring met Blackboard. Het gemiddelde cijfer voor de algemene gebruiksvriendelijkheid kwam op een 8.2 te staan, met als mediaan een 9. De rest van de cijfers zijn te zien in figuur 6.1. Het meest nuttige onderdeel van de resultaten waren echter de opmerkingen van de gebruikers. Hierin wordt duidelijk gemaakt op welke punten de testers kritiek hadden. Het onduidelijkst werd het uploaden van bestanden gevonden. Een punt van verwarring is dat het uploaden op twee manieren kan: de ’upload’ knop kan gebruikt worden, maar men kan ook het hele formulier verzenden met de ’save’ knop. Hierbij wordt ook het gekozen bestand geupload. Ook is er onduidelijkheid ontstaan over de twee velden naast het datum veld. Deze zijn bedoeld om een tijd op te geven, maar dit is niet direct voor iedereen duidelijk. Verder zijn er nog een aantal tips gegeven voor toevoegingen aan de user interface zoals een melding die aangeeft dat het toevoegen van een assignment gelukt is. Niet al deze punten zijn gemakkelijk op te lossen. Ontwikkelaars hebben bijvoorbeeld uiteenlopende oplossingen bedacht voor het uploaden van meerdere bestanden. Gmail gebruikt een flash object dat ervoor zorgt dat er meerdere objecten tegelijk ge¨ upload kunnen worden. Deze bestanden worden asynchroon verstuurd naar de server, waarschijnljk met behulp van een iframe (aangezien een XMLHttpRequest geen bestanden kunnen bevatten). Bij afwezigheid van flash of javascript wordt er teruggevallen op een simpelere versie. Een groot bedrijf als Google kan dit probleem dus netjes oplossen, maar voor anderen voegt dit vaak te veel complexiteit toe om te kunnen gebruiken. Het uploaden van bestanden moet immers blijven werken in elke grote browser en met elke versie van flash die gebruikt wordt. 30
6.3 Opmerkingen bij een dergelijk onderzoek 6.3.1 Nieuw voor de gebruiker De testers die de applicatie hebben beoordeeld, hadden deze nog niet eerder gezien. Hierdoor kan het soms even duren voordat zij hebben gevonden hoe iets precies werkt. Dit kan door de tester als negatief opgevat worden, ze moeten immers even zoeken. Voor de eindgebruiker is dit uiteindelijk geen enkel probleem. Nadat ze de eerste keer hebben gevonden hoe iets werkt, hoeven ze de volgende keren hier niet meer naar te zoeken. De tester gebruikt de applicatie ´e´en keer en de eindgebruiker gebruikt deze soms jarenlang.
6.3.2 doelgroep De mening over de applicatie hangt onder andere af van de achtergrond van de gebruiker. Een gebruiker met veel ervaring op het gebied van informatica kan vaak goede punten van kritiek aankaarten, maar is zelf niet representatief voor de algemene doelgroep. Hier moet rekening mee gehouden worden bij het uitvoeren van een gebruikersonderzoek.
31
32
HOOFDSTUK 7
Vergelijking met Sakai Sakai is, net als Blackboard, een elektronische leeromgeving, en wordt door de UvA als toekomstige vervanger voor Blackboard beschouwd. Daarom is het interessant om deze applicatie te vergelijken met Blackboard en Motherboard. De vergelijking wordt gedaan met behulp van de online demo-versie van Sakai op ’http://testdrivesakai.com/’
7.1 Assignments module Ook Sakai heeft de mogelijkheid om opdrachten toe te voegen en te laten inleveren door studenten. In dit hoofdstuk zal deze assignments module vergeleken worden met de reeds besproken Motherboard en Blackboard varianten.
7.2 Opdracht toevoegen Het toevoegen van opdrachten gaat in grote lijnen hetzelfde als bij Motherboard, maar er zitten wat kleine verschillen in.
7.2.1 Datum invullen Het invullen van een datum, kan ook hier met een JavaScript datepicker. E´en van de verschillen hier is dat de datapicker in een nieuw browser-venster opent. Dit kan een paar nadelen hebben: Bepaalde pop-up blockers zouden de datepicker kunnen tegenhouden, en de datepicker kan achter het grotere browser-scherm terecht komen wat de gebruiker kan verwarren. De standaard pop-upblocker van internet explorer stopt bijvoorbeeld op de hoogste stand de date-picker. Ook wordt bij het wisselen tussen maanden, het hele pop-up scherm opnieuw geladen, hierdoor duurt het wisselen tussen maanden langer dan nodig is. Voor al deze problemen zijn tientallen oplossingen beschikbaar in de vorm van java-libraries zoals jquery, dojo, extjs en de yahoo user interface library (yui) die gebruikt wordt voor de Motherboard datepicker.
7.2.2 Validatie De validatie van het formulier gebeurt grotendeels op de server. Op ´e´en punt gaat dit met behulp van javaScript, en dit is op een punt waar misschien geen validatie zou moeten plaats vinden. Het nadeel van validatie aan alleen de serverkant, is dat de gebruiker het formulier moet opsturen, en moet wachten op de reactie van de server, voor hij erachter komt of het formulier juist is ingevuld. Bij een trage internetverbinding is dit vervelend voor de gebruiker, en de server wordt extra belast. Bij de Motherboard versie vindt de validatie zowel aan de server- als aan de clientkant plaats, hierdoor hoeft de gebruiker het formulier pas echt te versturen als er geen fouten meer inzitten. Verder gebeurt het valideren bij Sakai niet altijd op het juiste moment. Bijvoorbeeld bij het toevoegen van een attachment, hier wordt het hele formulier gecontroleerd. 33
Figuur 7.1: Foutmelding bij gebruik van de datepicker De gebruiker moet dus eerst de titel van de assignment invullen voor er bestanden kunnen worden toegevoegd. Ook bij het openen van de datepicker wordt er een deel van het formulier gecontroleerd, namelijk het bijbehorende datum-veld. Dit kan een foutmelding opleveren als de gebruiker een handmatig ingevoerde datum wil wijzigen met de datepicker (figuur 7.1). De datepicker heeft dus wel de mogelijkheid om een datum te valideren met behulp van javaScript, maar dit wordt niet gebruikt bij het verzenden van het formulier. Met andere woorden: de gebruiker kan geen foutieve datum wijzigen met behulp van de datepicker, maar kan deze wel verzenden naar de server toe.
7.2.3 Rest van het formulier Een positief punt van de Sakai versie van dit formulier is het gebruik van de fck-editor voor het Assignment Instructions” veld. Deze editor stelt gebruikers in staat om de opmaak van ” hun tekst aan te passen. Helaas gebruikt Sakai een verouderde versie waardoor de editor niet werkt voor Safari en Chrome (ongeveer 10% van de gebruikers1 ), maar het tekstveld zonder de bijbehorende editor blijft wel bruikbaar.
7.3 Lijst van opdrachten De opdrachtenlijst van Sakai bevat net als bij Motherboard informatie over de naam, deadline en status van de opdracht. Naast deze informatie bevat deze pagina nog extra informatie over onder andere de datum waarop de opdracht geopend werd en de manier waarop de cijfers gegeven zullen worden. Over deze informatie kunnen vragen gesteld worden of ze belangrijk genoeg zijn om in de lijst weergegeven te worden zoals: ’Is de openingsdatum van de opdracht net zo belangrijk als de datum van de deadline?’. Afhankelijk van de mening van de gebruiker kan deze extra informatie positief of negatief worden opgevat; te veel informatie maakt de pagina immers onoverzichtelijk. Een deel van de pagina dat in het algemeen zeker onnodig is, is weergegeven in figuur 7.2. Met dit deel van de pagina kunnen gebruikers door verschillende pagina’s heen lopen, in het geval dat de lijst met opdrachten te lang is voor ´e´en pagina. Volgens de standaardinstellingen is dit pas het geval bij meer dan 200 opdrachten. Aangezien vakken met meer dan 200 opdrachten zeer zeldzaam zijn, hebben gebruikers het grootste gedeelte van de tijd een ongebruikt menu in hun scherm staan.
7.4 Opdracht inleveren Net als bij de andere pagina’s is deze pagina iets uitgebreider, maar iets minder geavanceerd dan de Motherboard versie. Deze pagina gebruikt de fck-editor voor het invullen van de tekst, heeft de mogelijkheid om een preview weer te geven, en heeft een knop om een draft op te slaan. Het uploaden van bestanden gaat bij Sakai iets omslachtiger, dit gebeurt op een nieuwe pagina. 1 http://www.w3schools.com/browsers/browsers
stats.asp
34
Figuur 7.2: Verdeling van opdrachten in pagina’s Bij de Motherboard pagina kan het toevoegen en verwijderen van bestanden op dezelfde pagina als de rest van het formulier. Sakai heeft overigens wel de extra mogelijkheid om te linken naar bestanden op een externe lokatie doormiddel van het opgeven van een url.
7.5 Conclusie In grote lijnen bevatten de assignments module van Sakai en de assignments plugin van Motherboard dezelfd functionaliteit. Een groot verschil is echter dat de assigments module van sakai samenwerkt met de grades module. In Motherboard is deze functionaliteit (nog) niet ingebouwd. Verder is de Sakai versie wat uitgebreider in de mogelijkheden, maar zijn veel onderdelen wel minder geavanceerd. Bijvoorbeeld het toevoeg-formulier, deze heeft meer velden dan de Motherboard versie, maar mist wel client-side-validation van het formulier.
35
36
HOOFDSTUK 8
Conclusie Uit de voorgaande hoofdstukken kunnen een aantal conclusies getrokken worden, waarmee de vragen uit hoofdstuk 2 beantwoord kunnen worden.
8.1 Literatuur Samengevat, zegt de literatuur over user interfaces dat een user interface echt goed is, als de verwachting van de gebruiker precies overeen komt met het gedrag van de applicatie. Alle andere stellingen over de kwaliteit van een user interface kunnen vanuit deze stelling afgeleid worden.
8.2 Huidige software De software die in deze scriptie onderzocht wordt, voldoet lang niet op alle punten aan de bovengenoemde eisen voor een goede user interface. Er zijn (te) veel voorbeelden te vinden van onderdelen waarbij het programma niet op de manier reageert die door de gemiddelde gebruiker verwacht wordt. Ook op de assignments pagina is er genoeg ruimte voor verbetering. Bij het gebruikersonderzoek is gebleken dat gebruikers Blackboard ook in de praktijk niet altijd even gebruiksvriendelijk is. Bij de SUMI vragenlijst scoorde Blackboard op gemiddeld vijftig procent van de punten onvoldoende.
8.3 Motherboard In een poging om de user interface van de assignments pagina van Blackboard te verbeteren, is de Assignments plugin voor Motherboard ontwikkeld. Het is gelukt om de functionaliteit van de assignments pagina deels te implementeren. Hierbij zijn verbeteringen aangebracht op de punten die in hoofdstuk 4 als ’niet goed’ omschreven werden. Hierbij is gebleken dat de moeilijkheden vooral liggen bij punten waar ze in eerste instantie niet verwacht werden. Deze problemen waren vantevoren niet, of lastig te voorspellen. Hieruit volgt ook een mogelijke reden voor de soms slechte kwaliteit in huidige software. Een (groot) bedrijf trekt vaak een bepaalde tijd uit voor bepaalde onderdelen van een te ontwikkelen applicatie. De onvoorspelbare problemen kosten erg veel tijd, en bij een bedrijf betekent een langere ontwikkelingstijd vaak ook meer kosten. Bij een tekort aan tijd moet er ergens bezuinigd worden op tijd. Dit bezuinigen kan makkelijk op het gebied van user interfaces. Zolang de software uiteindelijk alle functies bevat die beloofd zijn, hoeft de user interface niet van hoge kwaliteit te zijn. Op deze manier kan een software-bedrijf bezuinigen en de software goedkoper produceren, zonder beloftes te breken, of functionaliteit te schrappen. Uiteindelijk is Motherboard getest door een groep gebruikers en alhoewel er volgens hen veel ruimte voor verbetering is, is de score toch positief uitgevallen. De functionaliteit van de assignments pagina van Motherboard is veel minder uitgebreid dan bij de assignments module van 37
Blackboard, maar voor zover aanwezig wordt deze door de meeste gebruikers als gebruiksvriendelijk ervaren.
38
Bibliografie [1] Joel Spolsky. User Interface Design for Programmers. APress, Berkeley, 2001. [2] W. Thimbleby, H.;Thimbleby. Solutioneering in user interface design. ACM Press Frontier Series, 1993. [3] J. Tidwell. Designing Interfaces. O’Reilly, 2005.
39
