Eindverslag Gebruikersinterfaces Groep 地

Eindverslag Gebruikersinterfaces - Groep 地

Eindverslag Gebruikersinterfaces Groep 地 Tom De Bie, master toegepaste informatica Bram Gotink, master computerwetenschappen Michiel Staessen, master computerwetenschappen

Abstract Dit is het eindverslag voor gebruikersinterfaces, van groep 地 (uitgesproken als: chi). Wat onze toepassing vooral onderscheidt van de andere groepen is dat deze niet radicaal verschillend is van een traditionele mailapplicatie. Onze focus lag vooral op het toevoegen van een interessante feature en de uitwerking van de interface elementen voor deze feature. De belangrijkste uitdagingen bij de uitwerking van dit project was dan ook het zoeken naar een goede interface voor deze feature. Uit dit project leren wij vooral dat het ontwikkelen van een gebruikersinterface geen klein bier is. Het is de enige manier waarop de gebruiker met de applicatie kan interageren. De slaagkansen van een applicatie zijn vaak niet afhankelijk van de features maar veelal afhankelijk van de bruikbaarheid van de interface. Het is belangrijk dat features gemakkelijk te vinden zijn, op een plaats waar ze verwacht worden. Er zijn namelijk weinig gebruikers die de help-functie van een programma gebruiken. Sterker nog, men is tegenwoordig van mening dat wanneer een programma een help-functie nodig heeft, de interface ontoereikend is. Daarnaast bestaan er ook gebruikers die een eventuele tutorial overslaan, iets waaraan wij onszelf ook al eens schuldig maken. Het is dus van groot belang dat interfaces nauwgezet ontwikkeld en getest worden.

Idee Het idee achter de toepassing is ontstaan na de brainstormsessie met Marcus Specht. De opdracht was een applicatie te ontwikkelen die de problematiek van information overload en filter failure aanpakt. Het idee was een applicatie te maken die alle streams van de gebruiker inleest en alle berichten labelt op basis van filters. Dit systeem is sterk gebaseerd op de labels in Gmail waarvan wij (en niet enkel wij) vinden dat het erg goed werkt. Helaas ontbreekt dit systeem op de andere kanalen. Dit is echter een algoritmische oplossing en het 1

Eindverslag Gebruikersinterfaces - Groep 地 automagisch labelen van berichten paste niet echt in de scope van de cursus. We hebben dus deze piste verlaten en gezocht naar een andere manier om het information overload probleem aan te pakken. We zijn daarbij gaan focussen op een van de mogelijke consequenties bij information overload, namelijk de opvolging van berichten. Of eerder, de slechte opvolging van berichten. Het gebeurt wel vaker dat iemand vergeet te antwoorden op een bericht omdat hij/zij denkt “ik zal het later doen”. Uiteindelijk vergeet de persoon in kwestie te antwoorden omdat het item verdwijnt in de massa items die binnenstromen. We hebben daarom getracht om berichten op een efficiënte manier uit te stellen zodat een gebruiker hier op een later tijdstip weer aan herinnerd kan worden. Initieel waren hiervoor twee manieren voorzien: “gelezen/archiveren” of “later lezen”. De persoon moest dan zelf nog naar het label “later lezen” navigeren om te zien of er berichten moeten worden opgevolgd. Omdat dit niet erg praktisch is, hebben we de gebruiker de mogelijkheid gegeven om te kiezen wanneer hij/zij dit bericht wil terugzien. Het bericht krijgt dus niet louter een “later lezen” label maar ook een tijdstip waarop het terug moet verschijnen. Een belangrijk gevolg van deze labels is filtering. Het is mogelijk om bijvoorbeeld alle berichten met het label ‘chikul12’ te bekijken die via Twitter zijn binnengekomen en nu in de inbox staan. Om efficient te filteren maken we gebruik van een mengeling van “mappen” en labels. Hierbij zijn mappen geen echte mappen maar speciale labels die min of meer de eigenschap hebben van een map. Een bericht zit altijd in exact twee “mappen”: een locatie en een oorsprong. De mogelijke locaties zijn ‘inbox’, ‘outbox’, ‘archief’, ‘vuilnisbak’ en ‘later lezen’. De oorsprong is, zoals de naam al doet vermoeden, van waar het bericht komt. Dit kan bijvoorbeeld Twitter, Facebook, een bepaalde RSS feed, enz. zijn. Het is vanzelfsprekend dat een bericht niet tegelijkertijd van twee oorsprongen kan komen, en dat een bericht niet tegelijk in twee locaties kan thuishoren. Naast deze “mappen” kan een item ook normale labels hebben. Deze worden door de gebruiker toegekend, eventueel met behulp van (automatische) filters. Er staat geen limiet op het aantal labels die aan een item kunnen hangen. Achteraf hebben we gemerkt dat een aantal groepen een heel gelijkaardig idee hebben gehad. Er is echter toch een groot verschil tussen de verschillende ideeën. Zo is bijvoorbeeld de platformkeuze voor vele groepen verschillend: ChiGirlPower en Metro zijn voor een website gegaan, Team Sjiek en CHIll hebben voor de desktopapplicatie gekozen. Het digitale prototype van onze applicatie is met web technologie gemaakt maar kan even goed een tablet, desktop of web applicatie zijn. Naast een ander platform zijn de interfaces bij deze applicaties ook heel verschillend. Onze interface lijkt meer op een traditionele mailapplicatie, terwijl deze van bijvoorbeeld Team Sjiek daar helemaal niet op gelijkt. Een van de sterke punten van ons idee is dat de applicatie toelaat om berichten van verschillende oorsprongen onder te verdelen op een uniforme manier met behulp van het label-systeem. Zo is het bijvoorbeeld mogelijk om alle tweets met de hashtag 2

Eindverslag Gebruikersinterfaces - Groep 地 #chikul12, alle blogs van de studenten en de tweets van het didactisch team te volgen met slechts één label. Mensen worden overspoeld door informatie uit verschillende bronnen. Onze applicatie laat de gebruiker toe om berichten uit te stellen, zodat de gebruiker zelf kan kiezen welke berichten wanneer worden afgehandeld. Dit is een ander sterk punt. Een misschien zwakker punt aan ons idee is dat het onderscheid tussen een ‘gewone’ mailapplicatie en onze applicatie vrij klein is. Aan de andere kant is het ook niet onze bedoeling om het wiel te heruitvinden.

Scenario Voor het eerste idee werd het volgende scenario geschreven. Tim is a student at the University of Leuven. He follows the CHI course and is very active on a lot of social networks, including Facebook, Twitter and Google+. He also gets a lot of mail throughout the day. All of these channels generate a lot of information and Tim wishes to manage this with the relabel application. When Tim opens the application, he can see a list with all the new messages from the (activity) stream. We will call this the ‘inbox’, analogous to any email program. The items in this list are sorted by time, the most recent messages are on top. These messages are shortened if they’re too long to fit the overview. At the bottom of each message are one or more labels indicating the whereabouts of the message, status of the message (read/unread), labels based on the content or sender, etc. Tim sees a message that he wants to read so he clicks the item to see the whole message. After Tim has read the message, he clicks a button to mark the message as read and the message disappears from the list. Labels are organized in ‘toggle groups’. For instance, the origin labels compose a toggle group because there are no items that originated from two sources. Likewise, there is a toggle group for “Inbox” (unread items), “Archive” (read items) and “Read Later”. Within a toggle group, only one label can be toggled but multiple items across groups can be toggled to filter the stream. As said, each message has one or more labels. Relabel will assign labels to items in a variety of ways. In Tim’s case they are imported from the source (Gmail labels/ filters, Facebook groups, Google+ circles, …) and some are configured manually. For instance, all items from certain blogs will get the “chikul12″ label assigned. Tim has merged mail mentioning “chikul12” in the subject line together with tweets with the hashtag “#chikul12” and RSS feeds from blogs from the different teams, so he can easily follow everything concerning the CHI course. After reading a Facebook message, Tim wants to see the other unread Facebook messages. He clicks on the “Facebook” label to toggle it. Because the “Facebook” label and the “Inbox” label are in different toggle groups, both labels can be 3

Eindverslag Gebruikersinterfaces - Groep 地 activated. This way, Tim can easily filter the stream based on labels. To review all Facebook messages, he simply deactivates the “Inbox” label. At a certain moment, Tim gets a popup for a new mail about the CHI course. It has already got the chikul12 label because of the filters. He wants to read this message but he has not got enough time right now. He clicks the “Read Later” button. The message disappears from the stream and the “Inbox” label is switched for the “Read Later” label. Later, when Tim is at home and wants to work for the CHI course, he toggles both the “chikul12″ label and the “Read Later” label to toggle them. He now gets a list of all messages about the course he has yet to read, including the email he got before. After Tim posted something on his blog for the CHI course, he sees a message in his stream about this blog post. Because he just posted it, he knows the content of the blog post and doesn’t need to read it again. He clicks the “Archive” button at the bottom of the message and the message disappears from the stream without opening. Dit is misschien een te gedetailleerd scenario maar het beschrijft zeer goed wat we met de applicatie wilden bereiken. Zoals hierboven reeds beschreven is ons idee van het “Read Later”-label lichtjes gewijzigd. Tim hoeft dus niet langer naar dit label te gaan om het bericht terug in zijn inbox te krijgen, het zal namelijk automatisch daar verschijnen op het moment dat de door de gebruiker aangeduide periode is verstreken. De notificaties hebben we niet verder uitgewerkt aangezien het hier gaat om een kleine extra die los staat van het belangrijkste doel van de applicatie: het afhandelen, sorteren en uitstellen van berichten. De voorlaatste twee alinea’s uit het scenario en die ervoor worden dus vervangen door het volgende: Tim notices a new mail about the CHI course. It has already got the chikul12 label because of the filters. He wants to read this message but he has not got enough time right now. He uses the “Read Later”-slider to postpone handling the message until that evening. Later, when the chosen hour has come, the message reappears in Tims inbox, marked as unread. He can now read the message and handle it properly or postpone it again. Het maken van een scenario heeft ons geholpen om de core business van de applicatie te identificeren. Scenario’s laten dus toe om je te concentreren op wat het belangrijkste is in de applicatie. De grootste beperking is natuurlijk dat je hier zonder enige afbeeldingen zit. Alles is textueel neergeschreven en beschreven. Dit is echter ineens een voordeel. Een scenario is namelijk heel eenvoudig aan te passen. Aangezien een scenario niet meer doet dan de gebruikspatronen te beschrijven, kan je 4

Eindverslag Gebruikersinterfaces - Groep 地 het niet gebruiken om de interface te evalueren. Het is wel mogelijk om, op basis van een scenario, een storyboard te maken, dat daarvoor wel in aanmerking komt.

Storyboard Vanuit het scenario hebben we een storyboard opgebouwd. In ons geval bestaat dit uit mockups die het scenario visualiseren. In de eerste figuur wordt de inbox getoond.

Inbox De inbox bevat alle inkomende berichten van de gebruiker. Elk bericht heeft een aantal labels toegekend gekregen. De gebruiker kan de inkomende stream bekijken en verder filteren door de berichten als gelezen te markeren of uit te stellen. De gebruiker kan een item aanklikken om dit bericht te bekijken in het voorbeeldvenster (rechts).

5


Voorbeeld van een bericht Door op het Facebook-label bovenaan in het bericht te klikken, worden alle berichten gefilterd. Enkel berichten met het Facebook-label worden nu getoond.

Enkel Facebook berichten worden getoond Net zoals in het scenario, krijgt de gebruiker een nieuw bericht binnen. Hij/zij kan op de desktop notificatie klikken en de applicatie zal het bericht tonen.

6


Desktop notificatie van een nieuw bericht Omdat de gebruiker even geen tijd heeft, stelt hij/zij het bericht nog een tijdje uit door op de read later knop te klikken. Hierdoor verdwijnt het item uit de inbox en krijgt het het label ‘read later’ opgeplakt.

Het uitstellen van een bericht Wanneer de gebruiker tijd heeft om zijn “opgeslagen” berichten af te handelen, kan hij/ zij ze terugzoeken door de filters juist toe te passen.

7


Het filteren van de stream om een bericht terug te vinden Zoals eerder reeds beschreven is de uitstelfunctie gewijzigd. Dit gebeurde tijdens de paper prototyping fase. Dit is ook de reden waarom er geen nieuw storyboard gemaakt is. Het grote voordeel van een storyboard is dat het toelaat om een grafische uitwerking van een scenario te maken zonder dat je iets moet kennen van het programmeren van gebruikersinterfaces, en zonder dat je een keuze moet maken over hoe je de interface zou implementeren. Het maken van een storyboard kost echter best wat tijd. Een papieren prototype maken is veel eenvoudiger maar het heeft een ander doel. Een storyboard vertelt het scenario opnieuw in beeld, een papieren prototype is, zoals de naam al doet vermoeden, een prototype.

Opeenvolgende iteraties Papieren Prototype Doel Met dit prototype wilden we een aantal dingen nagaan. Zo wilden we nagaan of gebruikers: snel vertrouwd kunnen geraken met de functionaliteit, vinden wat ze zoeken, methoden gebruiken die we zelf over het hoofd gezien hebben en dingen deden die helemaal niet de bedoeling waren. 8


De focus bij deze iteratie lag vooral op het uitstellen van berichten omdat de interface die hiervoor ontwikkeld werd eerder nieuw is.

Aanpak Er zijn eigenlijk weinig opties om een papieren prototype te testen. Er moet altijd iemand bij zijn om de stukken papier op de juiste plaats te leggen en ze in de juiste volgorde te tonen. De keuze voor usability engineering was dus snel gemaakt. Het is niet alleen de meest voor de hand liggende keuze, het is ook de methode die de meeste informatie oplevert, zeker in functie van het aantal geteste gebruikers.

Praktisch Verloop Om het papieren prototype te evalueren, hebben we aan een vijftal medestudenten (studenten uit deze cursus en andere cursussen) op het departement gevraagd of ze ons papieren prototype wilden testen. We moeten hier dus wel de kanttekening bij maken dat deze gebruikers allemaal een sterk affiniteit met computers hebben.

De inbox van het papieren prototype

We hebben hen nooit expliciet gevraagd om luidop te denken maar de meesten deden dat uit zichzelf. De testgebruikers moesten enkele acties uitvoeren. De acties werden zodanig beschreven dat er geen specifieke interface elementen aan bod kwamen. De gebruiker startte in de inbox (zie figuur) en de uit te voeren acties waren de volgende:

9

Eindverslag Gebruikersinterfaces - Groep 地 1. Het eerste bericht in de inbox is een tweet van Tom De Bie. Ze moesten deze openen, bekijken en een uur uitstellen. 2. Het bericht van C. Harizard in de inbox moesten ze archiveren zonder te openen. 3. Ze moesten een bericht van Mark openen zodat de tweet van Tom De Bie uit het voorbeeldvenster zou verdwijnen. 4. Omdat de tweet van Tom nu weg was, moesten ze deze terugvinden en nog eens met twee dagen uitstellen.

De ‘Read Later’-slider met de kalender zichtbaar Bij het uitvoeren van deze test, hadden we drie rollen: iemand moest computer “spelen” en de juiste papieren tonen, iemand moest nauwkeurig noteren wat er gebeurde en iemand moest de uitleg doen zodat de overige twee zich konden concentreren op hun taak. Na een vijftal testen werden er weinig nieuwe problemen gevonden zodat we konden overgaan tot de analyse van de tests.

Resultaten We bespreken onze bevindingen aan de hand van de uit te voeren acties. Een bericht openen Wanneer gebruikers een bericht moesten openen, gebruikten ze in het algemeen een enkele muisklik. Er zijn echter mensen die wouden dubbelklikken. Dit is wellicht te wijten aan het feit dat zij (leden van Team Sjiek) voor hun applicatie moeten

10

Eindverslag Gebruikersinterfaces - Groep 地 dubbelklikken om een bericht te openen. Dubbelklikken kan anderzijds wel toegelaten worden. Een bericht uitstellen De gebruikers vonden de functionaliteit om een bericht uit te stellen zeer snel. Dit kan enigszins te maken hebben met het feit dat er extra nadruk op gelegd werd bij het tonen van de papieren interface elementen. Een probleem dat onze gebruikers aanhaalden was dat de schaal van de “read later”slider te groot was en dat er geen tijdsaanduiding was voor ‘1 uur’. Een gebruiker dacht dat de tijd die getoond werd het tijdstip was waarop het item terug zou verschijnen. Dit is echter niet het geval, de slider toont de duur voor het uitstellen. Een bericht archiveren Om een bericht te archiveren zonder het te openen, sleepte het merendeel van de gebruikers het item naar het label ‘Archive’. Slechts een gebruiker gebruikte het vinkje in het bericht om het te archiveren. Dit kan te wijten zijn aan het feit dat het er niet uitziet als een knop. Dat moet geverifieerd worden met het digitale prototype. Een uitgesteld bericht terugvinden Het terugvinden van een uitgesteld bericht was voor de meeste gebruikers makkelijk. Het bericht kan namelijk op meerdere manieren teruggevonden worden. Sommige mensen klikte op het “read later”-label, anderen klikten op het “Twitter”-label. Een gebruiker dacht het bericht terug te vinden in het archief maar toen hij ontdekte dat het daar niet zat, probeerde hij het “read later”-label. Nog een andere gebruiker probeerde te klikken op de “read later”-slider van een ander bericht maar ontdekte al snel dat dit niet werkte. Niet veel later had ook hij het bericht op de juiste plaats gevonden.

Pijnpunten en oplossingen Uit de resultaten kunnen we vaststellen dat er enkele problemen zijn met de interface. Het is voor de gebruiker niet helemaal duidelijk dat de aangegeven tijd bij het uitstellen de duur van uitstel is, wanneer een bericht een uur is uitgesteld (omdat er geen aanduiding voor een uur bestaat) en dat het vinkje aan een bericht dient om een bericht te archiveren. De oplossing voor het probleem met de schaal van de slider ligt voor de hand. De schaal moet aangepast worden zodat het mogelijk is om items met één uur uit te stellen. De oplossing voor het probleem met de tijdsaanduiding kunnen we oplossen door een extra veld te voorzien waarin de datum en tijd wordt getoond waarop het item terug zijn intrede zal maken. Een alternatief is zorgen voor een goede legende. Wij hebben voor het eerste alternatief gekozen omdat deze oplossing meer feedback geeft aan de gebruiker. Het is ook een pak handiger wanneer je over een langere termijn berichten uitstelt. Het is niet altijd evident om het aantal dagen te tellen. Het is eenvoudiger als het zichtbaar is in de interface tot wanneer een bericht uitgesteld zal zijn. Er is een groot vermoeden dat het vinkje niet gebruikt wordt omdat het er niet uitziet zoals een knop. Of dit ook degelijk de oorzaak van het probleem is, zal moeten

11

Eindverslag Gebruikersinterfaces - Groep 地 onderzocht worden aan de hand van een digitaal prototype. Het is ons opgevallen dat het leeuwendeel van de gebruikers heeft geprobeerd berichten te slepen. We hadden hier initieel niet aan gedacht, maar van zodra er gesleept werd, hebben we ons prototype aangepast om dit toe te laten.

Digitaal Prototype v0.1 Omdat de resultaten van het papieren prototype positief waren en er slechts enkele elementen gewijzigd moesten worden, zijn we meteen overgegaan tot het maken van een digitaal prototype. Voor de implementatie van het digitale prototype hebben we gekozen voor een mengeling van webtechnologieën waaronder HTML5, jQuery, jQueryUI, Less, Bootstrap en Hogan.js. Het prototype kan getest worden op http://mstaessen.github.com/prototype/login. Dit is echter wel de finale versie.

Doel Het doel van de eerste digitale iteratie was om na te gaan of de gebruiker vlot met onze applicatie kan werken en snel begrijpt hoe de belangrijkste functies werken. Deze iteratie diende ook om te onderzoeken of de positieve resultaten van het papieren prototype ook bij het elektronische prototype aanwezig zijn. We hebben vooral gefocust op de meest belangrijke functionaliteit zoals de functie om een bericht uit te stellen en de mogelijkheid om berichten te archiveren of verwijderen. We hebben ook gekeken naar de mogelijkheid om labels toe te voegen en te filteren op labels. Deze functionaliteiten leken ons de belangrijkste van de applicatie.

Aanpak In vergelijking met papieren prototypes, zijn er iets meer mogelijkheden om een digitaal prototype te evalueren. Toch hebben we, net zoals bij het papieren prototype, gekozen om te werken met usability engineering. Deze methode geeft ons namelijk de grootste garantie op relevante informatie. Dit kan niet gezegd worden van bijvoorbeeld usage tracking, waarbij de applicatie ook degelijk gebruikt moet worden. Bovendien zou dit nog enig werk gekost hebben om dit te integreren in het prototype (opslag, registratie van elke klik, ...). Een standaard questionnaire leek ons ook niet geschikt omdat je hiermee enkel een algemeen beeld van de kwaliteit verkrijgt maar het moeilijker is om specifieke pijnpunten te vinden. Uit de analyse van Google+, die we met een questionnaire uitvoerden, is eveneens gebleken dat de opkomst voor questionnaires betrekkelijk laag is, tenzij je Mobile Vikings inschakelt... en dan nog. Think-aloud daarentegen geeft ons een beter zicht op waar de gebruiker problemen heeft dan een questionnaire. De testgebruiker kreeg enkele specifieke opdrachten en hij werd aangespoord om luidop te denken. Na het uitvoeren van deze acties werd er nog gepeild naar algemene opmerkingen over onze applicatie.

12


Praktisch Verloop Voor de evaluatie hebben we geprobeerd de applicatie met een gevarieerd publiek te testen. We hebben hiervoor mensen uit het departement gevraagd maar ook andere vrienden en kennissen. Op die manier creëerden we een mengeling aan mensen die het vak volgen, mensen die het vak niet volgen maar wel computerwetenschappen studeren en mensen die (helemaal) niet zo behendig zijn met computers. Zeven mensen hebben deelgenomen aan de test. We lieten de testgebruiker plaatsnemen aan een notebook waarop de applicatie te zien was. De tests werden afgenomen door twee personen: iemand om de taken te geven en iemand die zorgvuldig noties maakte. De opdrachten die de testgebruiker moest vervullen waren de volgende: een bericht 12 uur uitstellen, een bericht voor een week uitstellen, een bericht archiveren, een bericht verwijderen, alle uitgestelde berichten terug zoeken, een label toevoegen aan een bericht en de berichten filteren op dit label. Tijdens het evalueren van het prototype kwam de gebruiker soms nog onafgewerkte functies tegen. Zo waren bijvoorbeeld niet alle ‘Archive’-knoppen functioneel. Indien dit voorkwam tijdens een test hebben we de testgebruiker dit laten weten zodat de testgebruiker verder kon gaan met de test.

Resultaten In Appendix A zijn de ruwe resultaten van deze iteratie terug te vinden. Hier bespreken we de geaggregeerde resultaten aan de hand van de opdrachten die de gebruikers moesten vervullen. Een bericht met 12 uur uitstellen De helft van de gebruikers heeft het bericht naar ‘Read Later’ gesleept, de andere helft heeft de slider in de berichten zelf gebruikt. Drie van de zeven testpersonen hebben eerst foutief geprobeerd door op het ‘Read Later’ of ‘Archive’ label te klikken vooraleer ze de juiste methode vonden. Het was dus niet meteen voor alle gebruikers duidelijk hoe de vork in de steel zat. Daarnaast was het niet voor iedereen duidelijk dat de actie geslaagd was. Een bericht voor een week uitstellen Iedere testgebruiker heeft hiervoor dezelfde methode gebruikt als in de vorige opgave. Drie van hen hebben de kalender pop-up gebruikt om de juiste dag te kiezen, de anderen hebben gewoon gesleept tot zeven dagen. Een bericht archiveren Het merendeel van de gebruikers heeft de ‘Archive’-knop in de berichten gebruikt. De overige gebruikers hebben het bericht gesleept. Geen enkele gebruiker heeft het vinkje 13

Eindverslag Gebruikersinterfaces - Groep 地 gebruikt. Hier is dus wel degelijk iets mis mee. Een bericht verwijderen Om een bericht te verwijderen heeft slechts één testgebruiker het bericht gesleept naar het ‘Trash’ label, de anderen hebben de ‘Trash’-knop gebruikt. Uitgestelde berichten tonen Hierbij waren er geen problemen, alleen probeerde één testgebruiker te dubbelklikken op het label. Een label toevoegen aan een bericht Alle gebruikers hebben de ‘Add Label’-knop gebruikt om deze opdracht uit te voeren. Vooraleer hiertoe te komen, heeft één van de testpersonen eerst geprobeerd op labels te klikken. Een andere gebruiker merkte op dat, wanneer het dropdown menu geopend wordt, de knoppen ‘Add Label’ en ‘New Label’ verwarrend zijn. Berichten filteren op dit label De gebruikers zijn quasi gelijk verdeeld over de drie manieren om alle berichten van een label te openen: klikken op het label in het bericht, klikken op het label in de label-lijst en klikken op het label in de berichtenlijst. Algemene opmerkingen Tenslotte bespreken we nog de algemene reacties die we kregen aan het einde van de user tests. Testpersonen vonden dat deze applicatie een herkenbare interface heeft. Inderdaad, de interface heeft iets weg van de een traditionele mailclient. Dit speelt in hun voordeel omdat ze zo sneller vertrouwd geraken met de applicatie. De gebruikers zijn bij het gebruiken van een traditionele mail applicatie wel gewend aan een context-menu (rechter muisklik). Het zien van het context-menu van de browser was enigszins een teleurstelling. Er werd daarom geopperd om ofwel zelf een context-menu te voorzien of rechter muisklik uit te schakelen. Gebruikers kwamen ook met nieuwe methoden om bepaalde acties te voltooien. Zo wilde iemand een label toekennen aan een bericht door het bericht op het label in kwestie te slepen. Dit was nog niet geïmplementeerd en kan best geïmplementeerd worden in een volgende versie.

Pijnpunten en oplossingen Een belangrijk probleem met de interface is het uitstellen van berichten. De meeste gebruikers hadden moeilijkheden met het vinden van de slider. Deze wordt namelijk niet getoond (zie figuur) tenzij de gebruiker met zijn muis over een “read later”-balk bovenaan het bericht gaat (zie figuur). Een mogelijke oplossing voor dit probleem is het niet verbergen van de slider maar dit heeft dan weer tot gevolg dat er een aanzienlijke hoeveelheid nuttige ruimte verloren gaat. Deze kan beter gebruikt worden om het bericht in kwestie te tonen. Omdat de nadruk op het bericht moet blijven, hebben we

14

Eindverslag Gebruikersinterfaces - Groep 地 niet voor deze oplossing gekozen.

Een bericht met de slider verborgen

Een bericht met de slider zichtbaar Een alternatieve oplossing bestaat erin de slider te openen op het moment dat het bericht wordt geopend en dan na enkele seconden de slider te verbergen. Zo krijgt de gebruiker telkens een subtiele hint. Deze oplossing is echter ook niet ideaal omdat de tekst van het bericht dan verspringt wanneer de gebruiker deze aan het lezen is. Nog een andere mogelijkheid is het introduceren van een tutorial bij het eerste gebruik. Zoals te lezen in de Abstract zijn we geen fan van tutorials. De interface moet voor zichzelf spreken. Wij hebben daarom voor een subtielere oplossing gekozen. We hebben namelijk de tekst “read later” meer contrasterend gemaakt, aangezien de meeste gebruikers de slider wel vonden als ze de tekst hadden gezien. Indien dit na deze iteratie niet effectief blijkt, kunnen we een andere methode proberen. Een tweede probleem met het uitstellen van berichten is dat de gebruiker geen bevestiging krijgt na het uitstellen van een bericht. Het is dus niet duidelijk dat deze actie gelukt is. Een oplossing voor dit probleem is het geven van een kleine “flash message” die vanzelf verdwijnt en een bericht bevat om te bevestigen dat de actie geslaagd is. Een tweede pijnpunt is het gebrek aan consistentie. Zo gebruikt niemand het vinkje om berichten te archiveren. Een mogelijke reden hiervoor is dat de betekenis voor dit

15

Eindverslag Gebruikersinterfaces - Groep 地 vinkje onduidelijk is. Het is een doodgewone archive-knop maar heeft een ander icoon dan andere archive-knoppen (zie figuur). Dit is niet consistent en kan voor verwarring zorgen. Het icoontje kan dus beter vervangen worden door een archiefmap-icoontje.

Verschillende archive-methoden (slepen naar archive, klikken op het vinkje of klikken op de archive knop in het voorbeeld-venster) Een tweede inconsistentie is te vinden in de naamgeving voor het toevoegen van labels. De knop voor het toekennen van labels bestaat uit twee delen: een knop om een nieuw label te maken en een knop op bestaande labels toe te voegen. In de lijst van de bestaande labels wordt nogmaals de mogelijkheid gegeven om een nieuw label toe te voegen. De naamgeving is hier echter verschillend (“Add Label” versus “New Label”, zie figuur). Dit is niet consistent en zorgt voor verwarring bij de gebruikers.

Inconsistente naamgeving bij het toevoegen van labels Dit probleem kan op verschillende manieren opgelost worden. Men kan de naamgevingen gelijkstellen om de consistentie te verhogen of men kan een van de twee knoppen verwijderen. Er is gekozen om de knop niet in twee op te delen maar de knop altijd het dropdown menu te laten zien. Als de gebruiker een nieuw label wil toevoegen, moet hij dit van hieruit doen.

Digitaal Prototype v0.2 Doel Op het einde van de vorige iteratie hebben we voor de gevonden problemen een of meerdere oplossingen gesuggereerd. In deze iteratie hebben we de gekozen oplossing geïmplementeerd en willen we nagaan of deze oplossingen een soelaas bieden voor de gevonden problemen. Eén van de voorgestelde aanpassingen was het veranderen van het vinkje in het archiveicoontje en het toevoegen van een vuilbak-icoontje. Het vinkje werd in vorige iteraties amper gebruikt, dus het was belangrijk om na te gaan of de vernieuwde iconen meer consistentie brengen. Indien ze na deze iteratie nog steeds niet gebruikt worden, kunnen ze misschien beter verwijderd worden uit het ontwerp. Een tweede aanpassing is het duidelijker maken van de slider. Het is belangrijk dat de

16

Eindverslag Gebruikersinterfaces - Groep 地 gebruikers deze makkelijk kunnen terugvinden aangezien dit een belangrijke, zoniet de belangrijkste feature is van onze applicatie.

Aanpak Bij deze iteratie hebben we een gelijkaardige aanpak gehanteerd als bij de vorige iteratie. Op deze manier kunnen we makkelijk nagaan of er vorderingen zijn geboekt.

Praktisch verloop Deze iteratie verliep net zoals de vorige. De testgebruiker kreeg dezelfde opdrachten als in de vorige iteratie. Na afloop hebben we nog gevraagd aan de gebruiker of hij andere manieren kon bedenken om de verschillende taken uit te voeren en voor welke van deze methodes de gebruiker een voorkeur had. Bij deze iteratie hebben we ervoor gekozen om zowel testgebruikers die de eerste iteratie hebben meegedaan te gebruiken als nieuwe gebruikers te rekruteren. Ditmaal namen zes personen deel aan de evaluatie.

Resultaten Ook voor deze iteratie bespreken we de resultaten per opdracht. We bekijken nu echter enkel wat er veranderd is ten opzichte van de vorige iteratie. De ruwe resultaten zijn terug te vinden in appendix B. Een bericht uitstellen Een meerderheid van vier van de zes testgebruikers heeft nu de ‘Read Later’-slider in het bericht gebruikt. Eén gebruiker heeft het context menu gebruikt. De zesde gebruiker heeft gesleept naar “Read Later” in de labellijst. Hieruit kunnen we afleiden dat onze aanpassing van het contrast in de ‘Read Later’-slider in het bericht gewerkt heeft. Deze slider wordt nu vaker gebruikt. Een bericht archiveren of verwijderen Bij het archiveren of verwijderen van berichten worden de knoppen in de berichtenlijst nu wel gebruikt. Ook hier is het dus duidelijk dat de aanpassingen die we in deze iteratie gemaakt hebben daadwerkelijk resultaat leveren. Algemene commentaar De volgende algemene commentaren werden gegeven door de testgebruikers: Bij het openen van een bericht is niet direct zichtbaar of en hoe lang dat bericht is uitgesteld. Om dit te kunnen zien moet eerst de ‘Read Later’-slider getoond worden. Bij het tonen van de pop-up om een nieuw label te maken, zou het gemakkelijker zijn als het tekstvak automatisch focus krijgt, zodat je er niet meer in moet klikken vooraleer je de naam voor het nieuwe label kan intypen. Ook zou de entertoets induwen het zelfde effect moeten hebben als de “OK”-knop. Er is geen bevestiging wanneer een actie ondernomen wordt.

Pijnpunten en oplossingen Twee pijnpunten van vorige iteratie komen deze iteratie weer boven.

17

Eindverslag Gebruikersinterfaces - Groep 地 Het eerste probleem is dat de “Read Later”-balk slecht te zien is. Dit probleem is al voor een deel opgelost aan de hand van grotere letters en een donkerdere kleur, maar er zijn nog steeds gebruikers die deze balk niet direct vonden. We denken dat het niet echt meer een belangrijk pijnpunt is deze iteratie aangezien dat alle gebruikers deze balk wel hebben gevonden na even zoeken. Een tweede pijnpunt is dat er nog steeds geen bevestiging wordt gegeven bij het uitstellen van berichten. Dat dit pijnpunt terugkomt in deze iteratie is normaal aangezien we niets hebben gedaan om dit te verhelpen. Het kersverse context menu werd gebruikt, maar bleek incompleet. Er ontbraken enkele belangrijke opties om nieuwe labels toe te voegen en om een bericht uit te stellen. Deze iteratie maakte het ook mogelijk om berichten uit te stellen door ze naar het “read later”-label te slepen. Er verschijnt dan een pop-up waarin de gebruiker de tijd kan instellen. De knop om deze pop-up te sluiten draagt de tekst “Close”. Dit is enigszins verwarrend. Dit geeft namelijk de indruk dat de ingestelde tijd ongedaan wordt gemaakt. Dit is makkelijk op te lossen door “Close” te vervangen door “OK”.

Digitaal Prototype v0.3 Doel Het doel van deze iteratie is net zoals de vorige om de aanpassingen die gemaakt zijn valideren en om na te gaan of er geen nieuwe problemen opduiken. Er zijn in deze iteratie maar een paar aanpassingen gemaakt. Het context menu is uitgebreid en de “Close”-knop werd vervangen door een “OK”-knop

Aanpak We hebben dezelfde aanpak gebruikt als bij de vorige iteraties.

Praktisch verloop Het verloop van deze iteratie is ook weer gelijkaardig aan de vorige iteraties. Twee personen namen deel aan de test. Beide gebruikers zijn familie en hebben nog nooit met de applicatie gewerkt. De resultaten zijn hierdoor minder betrouwbaar.

Resultaten Ondanks het beperkte testpubliek, kunnen we toch een aantal resultaten formuleren. Een bericht uitstellen Beide test gebruikers hebben gebruik gemaakt van de nieuw toegevoegde optie in het context menu. Er waren verder geen problemen. Hieruit kunnen we besluiten dat het een goede keuze was om dit toe te voegen aan het context menu. Ook twijfelen de gebruikers niet meer als ze de pop-up gebruiken. De “OK”-knop werpt dus zijn vruchten af. Een bericht archiveren of verwijderen Beide gebruikers herkenden de vuilbak als icoon voor het verwijderen van een item en

18

Eindverslag Gebruikersinterfaces - Groep 地 hebben dit icoon daar ook voor gebruikt. Het icoon voor “Archive” was echter niet direct duidelijk. Eén van de gebruikers vond het tevens vreemd dat het bericht blijft openstaan in het voorbeeldvenster nadat het verwijderd is. Voorkeuren Eén van de gebruikers vond het handig dat er meerder manieren zijn om dezelfde actie uit te voeren. Deze gebruiker had verschillende voorkeuren afhankelijk van wat hij aan het doen was. Als hij net een bericht had gelezen en hij dit wilt archiveren zou hij de knop in de preview gebruiken maar als hij een paar gelezen berichten wilt archiveren is de knop op het bericht sneller en heeft dit dus de voorkeur. Indien het mogelijk zou zijn om meerdere berichten te selecteren in de berichten lijst zou de voorkeur gaan naar het het context menu.

Pijnpunten en oplossingen Het belangrijkste pijnpunt deze iteratie is dat een bericht blijft staan in de preview nadat het verwijderd is. Dit is verwarrend voor sommige gebruikers. Een oplossing hiervoor zou een optie scherm kunnen zijn waarin de gebruiker zijn voorkeur aangeeft.

Eindresultaat Het eindresultaat (zelf te uit te testen op http://mstaessen.github.com/prototype/login) vinden we best wel geslaagd. Dit is wellicht grotendeels te danken aan de tools die we gebruikt hebben voor de implementatie van het prototype. Bootstrap, een stijl-bibliotheek, voorziet elegante stijlen voor diverse interface elementen en een goed kleurenpalet. jQueryUI voorziet dan weer geavanceerde interface elementen en een veelheid aan animaties. Hogan.js, een templating engine voor JavaScript, en jQuery maken het programmeerwerk lichter en efficiënter. Veel groepen hebben na de presentatie opgemerkt dat onze applicatie (te)veel op een traditionele mail applicatie werkt. Op een bepaalde manier is dit ook de bedoeling. Omdat de applicatie net op een traditionele mail applicatie gelijkt, is het merendeel van de gebruikers er ook zeer snel mee weg. We begrijpen deze commentaar dus wel maar zijn niet zozeer overtuigd dat dit een “slechte zaak” is. We hebben heel bewust gekozen voor een minimalistische interface. Dit is gedaan onder het motto ‘less is more’. We wouden zeker vermijden dat we de gebruiker een overvolle, kleurrijke interface voorschotelden. Dit leidt namelijk de gebruiker af van wat hij of zij echt wil doen, en trekt te veel aandacht naar de interface zelf. Het is uiteraard niet de bedoeling dat de gebruiker elke vijf seconden stilstaat bij de animaties die ons programma voorziet. De gebruiker moet zich kunnen concentreren op de berichten, de informatiestroom waarmee ons programma hem of haar helpt omgaan.

Finale reflecties We zijn dit vak begonnen met de idee dat een interface maken redelijk eenvoudig is, dat de interface ondergeschikt is aan de rest van het programma. Als een programma goed is, wordt het toch sowieso gebruikt, niet? 19


Niet dus. Een applicatie staat of valt bij de interface. Het is het enige waar de gebruiker mee kan interageren om de applicatie te besturen. Als dat niet goed zit, geeft de gebruiker in de meeste gevallen op. Dat is het belangrijkste dat we uit deze opdracht geleerd hebben. Over een interface moet nagedacht worden. Een goede interface is belangrijk, anders gebruiken de gebruikers de verschillende features van je programma niet. Wat ons ook is opgevallen, is dat een interface nooit af is. Je kan blijven itereren met een prototype, en altijd kleine dingen aanpassen. Daar komt bij dat een interface nooit goed kan zijn voor iedereen. Er zijn namelijk verschillende profielen van gebruikers. Zo onderscheidden we tijdens onze tests de klikker, de sleper, de rechtsklikker, de dubbelklikker en de sneltoetsenmaniak. Het is geen eenvoudige zaak om elke gebruiker in zijn persoonlijk noden en gewoonten te voorzien. We hebben dit echter wel geprobeerd en denken dat het redelijk goed gelukt is. We hebben onze blog niet zo vaak geüpdatet als de meeste andere groepen. Dit heeft er toe geleid dat we minder feedback hebben kunnen krijgen van onze medestudenten of het didactisch team. Dit is iets wat we zeker beter hadden kunnen doen, meer feedback is namelijk altijd handig.

20


Tijdbesteding Tom

Bram

Michiel

Totaal

Google+ Evaluatie

7h06m

4h53m

8h52

20h51m

Scenario

3h

3h07m

1h30m

7h37m

Storyboard

3h35m

4h00m

3h19m

10h54m

Implementatie papieren prototype

1h

1h16m

1h

3h16m

Evaluatie papieren prototype

3h

3h00m

3h30

9h30m

Implementatie digitaal prototype v0.1

35h14

28h30

30h38

94h22m

Evaluatie digitaal prototype v0.1

4h30

3h21m

3h24

11h15m


7h33

5h28m

1h

14h01m


45m

45m

0h

1h30m


2h

0h25m

0h

2h25m


1h

0h

0h

1h

Les

27h30m

27h30m

27h30m

82h30m

Bloggen, blogs lezen & reageren

5h

8h05m

11h08m

24h13m

Presentatie

1h

1h45m

4h24m

7h09m

Verslag

8h08m

15h46m

14h06m

38h00m

2h06m

2h36m

5h42m

109h57m

112h57m

334h15m

Varia (twitter, evaluatie, vergaderingen, …) 1h Totaal

111h21m

Bij deze tijdsbesteding hoort wel een opmerking: er zitten soms (grote) verschillen in de tijdsbesteding voor eenzelfde taak omdat niet iedereen even goed de tijden heeft bijgehouden op toggl. Dit gaat dan om korte periodes, een half uur bvb., waarbij we dit een aantal keer vergeten zijn. We hebben bijvoorbeeld geen idee hoeveel tijd er op die manier in twitteren opgegaan is. Daarenboven heeft niet iedereen alles aangeduid bij hetzelfde onderwerp. Zo staat, in toggl, het storyboard bij Bram bij paper prototype, aangezien er nog geen onderwerp voor storyboard was op het moment dat we dat maakten. Dit is maar één van vele voorbeelden.

21


Appendix A - Ruwe resultaten evaluatie v0.1 een bericht met 12 uur uitstellen 4 gebruikers hebben gesleept naar het label Read Later en dan de slider in de pop-up gebruikt 3 gebruikers hebben de slider in de berichten preview gebruikt 3 gebruikers hebben voordat ze de juiste methode hebben gevonden eerst op het label Archive of Read Later geklikt veel gebruikers hadden moeilijkheden met dit te vinden. voor sommige gebruikers was het niet duidelijk dat de actie gelukt was een bericht voor een week uitstellen 3 gebruikers hebben de kalender pop-up gebruikt de andere hebben gewoon gesleept tot een week. iedereen heeft dezelfde methode gebruikt als in de vorige actie. een bericht archiveren 5 gebruikers hebben de Archive knop in de berichten preview gebruikt 2 gebruikers hebben het bericht gesleept naar het Archive label 1 gebruiker heeft getwijfeld aan het vinkje op het bericht een bericht verwijderen 6 gebruikers hebben de Trash knop in de berichten preview gebruikt 1 gebruiker heeft het bericht gesleept naar het Trash label alle uitgestelde berichten terug zoeken Hierbij had niemand problemen buiten 1 persoon die eerst probeerde te dubbelklikken een label toevoegen aan een bericht alle gebruikers hebben de “Add Label” knop gebruikt 1 gebruiker heeft het dropdown menu geopend en was verward door de twee mogelijkheden Add Label en New Label 1 gebruiker probeerde te klikken op de labels de berichten filteren op dit label 3 gebruikers hebben op het label in het bericht geklikt 2 gebruikers hebben op het label in de linker balk geklikt 2 gebruikers hebben op het label in de berichten lijst geklikt Algemene opmerkingen: herkenbare interface bij rechter klikken de opties van de browser verwijderen rechter klik functionaliteit toevoegen berichten op labels slepen om een label toe te voegen

22


Appendix B - Ruwe resultaten evaluatie v0.2 een bericht 12 uur uitstellen 4 gebruikers hebben de slider in de berichten preview gebruikt 1 gebruiker heeft de rechter muisklik gebruikt 1 gebruiker hebben gesleept naar het label Read Later en dan de slider in de pop-up gebruikt 1 gebruiker klikte eerst op archive 1 gebruiker wou na het slepen niet op close klikken omdat hij dacht dat de actie zo ongedaan gemaakt zou worden een bericht voor een week uitstellen 4 gebruikers hebben de slider in de berichten preview gebruikt 1 gebruiker heeft de rechter muisklik gebruikt 1 gebruiker hebben gesleept naar het label Read Later en dan de slider in de pop-up gebruikt een bericht archiveren 1 gebruiker heeft het logo op het bericht in de berichtenlijst gebruikt 4 gebruikers hebben de Archive knop in de berichten preview gebruikt 1 gebruiker heeft de rechter muisklik gebruikt een bericht verwijderen 1 gebruiker heeft het logo op het bericht in de berichtenlijst gebruikt 4 gebruikers hebben de Archive knop in de berichten preview gebruikt 1 gebruiker heeft de rechter muisklik gebruikt alle uitgestelde berichten terug zoeken iedereen vond dit snel en zonder problemen een label toevoegen aan een bericht 5 gebruikers vonden dit snel en zonder problemen 1 gebruiker wou de rechter muisklik gebruiken en heeft nadat hij vond dat dit niet ging de correcte methode gevonden de berichten filteren op dit label 2 gebruikers hebben op het label in het bericht geklikt 3 gebruikers hebben op het label in de linker balk geklikt 1 gebruiker heeft gedubbelklikt

23


Appendix C - Ruwe resultaten evaluatie v0.3 een bericht 12 uur uitstellen 2 gebruikers hebben het context menu gebruikt een bericht voor een week uitstellen 2 gebruikers hebben het context menu gebruikt een bericht archiveren 1 gebruikers heeft de Archive knop in de berichten preview gebruikt 1 gebruiker heeft de rechter muisklik gebruikt een bericht verwijderen 2 gebruikers hebben het logo op het bericht in de berichtenlijst gebruikt 1 gebruiker vond het raar dat het bericht bleef openstaan alle uitgestelde berichten terug zoeken iedereen vond dit snel en zonder problemen een label toevoegen aan een bericht 1 gebruiker heeft de de add label knop in de berichten preview gebruikt 1 gebruiker heeft de rechter muisklik gebruikt de berichten filteren op dit label 2 gebruikers hebben op het label in de linker balk geklikt

Algemene opmerkingen: uitvinken van labels is vreemd de bron van het bericht moet op het bericht staan als label.

24

Eindverslag Gebruikersinterfaces Groep 地

Recommend Documents