Think aloud (thesis) … vervolg

Ter opfrisssing: de geteste applicatie tracht aan de hand van een frontale foto en een profielfoto van het menselijk gelaat een 3Dmodel op te stellen. De gebruiker wordt in de eerste plaats door middel van een wizard doorheen de detectiestappen geleid van de frontale en de profielkenmerken. Na deze stappen wordt een generisch hoofdmodel vervormd en vervolgens de textuurmap gemaakt.

De proefpersoon is hier een universiteitsstudente uit de eerste Master Biologie, met een gemiddelde PC-ervaring. Ze dubbelklikt op het pictogram en de applicatie start succesvol op. De resultaten van de think-aloudtest worden hier niet weergegeven om overzichtelijke redenen (zie link onderaan deze post voor meer details). De analyse is echter van groter belang. Positieve opmerkingen over de interface worden achterwege gelaten. Een paar conclusies en dus ook meteen doorgevoerde veranderingen zijn hieronder weergegeven.

• De proefpersoon dacht dat het programma vastgelopen was wanneer het eigenlijk een complex algoritme aan het uitvoeren was. Dit doet me denken aan de eerste heuristische usability regel http://www.useit.com/papers/heuristic/heuristic_list.html. De gebruiker moet altijd geinformeerd zijn over wat er aan het gebeuren is. Daarom werd een progress-balkje toegevoegd dat duidelijk maakt welke detectie op dat moment berekend wordt. Het balkje is tijdsongedetermineerd, aangezien onmogelijk op voorhand kan bepaald worden hoe lang het algoritme zal duren.
• “Een beeld zegt meer dan 1000 woorden.” Daarom werd de helptekst die bij iedere wizardstap verschijnt, ondersteund met een voorbeeldfotootje van hoe het gedetecteerde gezichtskenmerk er moet uitzien. Bij het eerste gebruik van de applicatie, zal het waarschijnlijk wel nog nodig zijn de hulptekstjes te lezen, maar bij een tweede gebruik zou de foto een geheugensteuntje moeten zijn voor wat er in de tekst gezegd wordt.
• De gebruiker wordt bij de manuele detectie gedwongen op ‘clear’ te drukken, zodat het gedetecteerde feature verdwijnt van het beeld. Dit is ongewenst wanneer bijvoorbeeld het reeds gedetecteerde feature helemaal juist is, maar enkel aangevuld dient te worden. De wijziging bestaat dus uit de mogelijkheid de automatisch gedetecteerde feature nu manueel aan te vullen.
• Het 3D-canvas waar het hoofdmodel in verschijnt, biedt standaard de mogelijkheid door middel van de muis allerlei transformaties uit te voeren op het hoofdmodel (transleren, roteren en zoomen). Deze muisbeweging is blijkbaar niet echt handig, zelfs oncontroleerbaar en het vraagt enige ervaring het model te draaien volgens de gewenste beweging. Daarom werden aan het canvas 4 pijl-buttons toegevoegd die het mogelijk maken het model puur te roteren rond de horizontale en de verticale as. Ook een button om het hoofdmodel in zijn oorspronkelijke positie terug te brengen blijkt handig.
• Bij de manuele detectie was het niet echt duidelijk dat de gebruiker eerst punten moet aanduiden op het beeld en dan op ‘Draw curve’ moet klikken om te bevestigen. Daarom werd een pencursor toegevoegd wanneer de gebruiker met de muis over het beeld navigeert, en werd de ‘Draw curve’-benaming door ‘Confirm’ veranderd. Dit laatste is zeker een hele verbetering bij de detectie van enkel punten, waar de ‘curve’-benaming helemaal irrelevant is. In hetzelfde kader werden ook zoombuttons aan het panel toegevoegd, zodat de gebruiker makkelijk bijvoorbeeld de relatief kleine ogen toch nauwkeurig kan aanduiden.
• De detectie van profielkenmerken verwacht een inputbeeld waarop een rechterzijaanzicht van het hoofd te zien is. Wanneer dit een linkerzijaanzicht is, werd de gebruiker aangespoord met een zelfgekozen programmatje de foto te spiegelen om de verticale as. Deze indirectie wordt nu opgelost door binnen deze applicatie zelf een simpele button te voorzien die de ingeladen foto spiegelt om zijn verticale as (tenminste als dit nodig zou zijn). In toekomstige iteraties zou dit ook automatisch kunnen gebeuren, zodat de gebruiker hier zelf geen rekening meer hoeft te houden.
• Als laatste (niet af te leiden uit de think-aloudtests) werden aan alle buttons mooie icoontjes toegevoegd om de functie van de knop nog duidelijker te maken. Ook de banner werd vervangen door een eigen (meer passende) creatie.

Op die manier werd voor elke opmerking van deze ene proefpersoon een oplossing gezocht en de aanpassing doorgevoerd. Toegegeven, 1 thinkaloudtest in 1 iteratie zou niet mogen volstaan om deze interface als afgewerkt te beschouwen (wat ik dan ook niet beweer). Toch kan het bereikte niveau voorlopig als voldoende gebruiksvriendelijk beschouwd worden (de nadruk van deze masterproef ligt namelijk eerder op de onderliggende algoritmes dan op de interface). Verdere iteraties (in thinkalouds en gui-aanpassingen) zullen daarom niet meer uitgevoerd worden. Meer details (en screenshots!) over deze hele thinkaloud en de GUI van mijn applicatie, kan teruggevonden worden in het GUI-hoofdstuk van mijn verslag … http://users.vtk.be/~s0161408/Kul/Thesis/Tekst/gui.pdf

 

Prioriteit van UI-problemen

Wanneer je user interface nu door een eindgebruiker wordt geevalueerd, welke problemen zijn voor die eindgebruiker nu het meest hinderlijk?

In een artikel van de SAP Design Guid worden de vier meest hinderlijke problemen voor een gebruiker opgesomd, meest hinderlijke eerst:

1. Wachten op de applicatie
2. Applicatie crashes
3. Ontbrekende functionaliteit
4. De rest…

Kort maak ik enkele bedenkingen bij nummer 1. Persoonlijk vind ik de wachttijden ook het meest hinderlijke. Waarom? Neem nu het laden van een webpagina. Het is de variabiliteit die stoort, soms duurt het ‘maar’ enkele seconden, soms een halve minuut en in het slechtste geval krijg je na een tijdje een time-out. De variabiliteit maakt dat je niet weet hoelang het zal duren, en dus staar je maar naar de laadbalk in de hoop dat deze opeens van 3% naar 99% springt. In de tussentijd doe je niets nuttig want voor hetzelfde geld ben je naar een andere applicatie geswitched terwijl de pagina wel meteen geladen was. Vervelende overhead dus.

Stel nu dat je een computationeel intensieve test runt, waarvan je weet dat ze minstens 10 minuten zal innemen. Je zet het programma aan, wandelt weg voor een koffietje. Je vermeldt aan je pauzerende collega terloops dat je computer ondertussen heftig werk aan het leveren is. Dat is een pak cooler dan te melden dat je computer het afgelopen kwartier een webpagina van 20 Kb aan het binnenhalen is…

De hulp functie, alleen maar voor expert-gebruikers?

In de office user interface blog van Jensen Harris wordt gesteld dat de hulpfunctie, zoals deze aanwezig is in bijvoorbeeld Microsoft office, vooral door expert gebruikers wordt geraadpleegd en weinig door nieuwe gebruikers.

De observatie volgt uit een reeks van usability tests. In plaats van de help functie te raadplegen, leren nieuwe gebruikers bij door rond de klikken, de programma-opties te activeren en te verkennen in het algemeen. In zijn blog haalt Jensen Harris een aantal mogelijke redenen aan die dit fenomeen mogelijks verklaren. Een van de meest plausibele redenen is dat expert gebruikers weten welke terminologie ze moeten hanteren om een probleem via de help-functie op te lossen. De help functie, zeker in Microsoft Office, focust bovendien voornamelijk op het oplossen van specifieke problemen en niet op het aanleren van een algemeen gebruik van de applicatie. Voor dit laatste zijn er een hoop boeken beschikbaar, dewelke waarschijnlijk voor een nieuwe gebruiker een aangenamer formaat hebben dan een help-dialoog. Misschien schrikt ook de grote hoeveelheid aan tekst in een help-functie een nieuwe gebruiker af…?

Tot slot stelt Jensen Harris:

But it’s worth noting that if you’re authoring your help system for newcomers, you might be designing for the wrong kind of person. 

Een mogelijke oplossing om een gebruiker te applicatie te laten leren, is het aanbrengen van “Learn more…” items rechtstreeks in de gebruikersinterface. Deze kunnen dan bijvoorbeeld een dialoog met een korte verklarende tekst openen. Zo kan een gebruiker met mondjesmaat bijleren.

 

Think aloud vs heuristische evaluatie

Inleiding

Tijdens de les werd het think aloud protocol besproken als manier om de bruikbaarheid van een gebruikersinterface te onderzoeken. Buiten het think aloud protocol zijn er nog andere manieren om een gebruikersinterface te evalueren. Het leek me dan ook interessant om een van deze manier te bespreken en te vergelijken met het think aloud protocol. De methodiek die besproken wordt betreft deze van  heuristische evaluatie.

Heuristische evaluatie [1]

De heuristische evaluatie wordt uitgevoerd door een aantal verschillende testpersonen. Deze personen dienen expert te zijn op het vlak van gebruiksvriendelijkheid, of toch minstens vertrouwd te zijn met de concepten binnen dit domein. Concreet wordt aan deze personen de interface gegeven ter evaluatie, eventueel in papieren vorm. Elk van de personen zal individueel de interface bekijken en evalueren. Zeer belangrijk is dat deze evaluatie individueel gebeurt teneinde een onafhankelijk resultaat te bekomen ten opzichte van de overige evaluators. Na evaluatie wordt een rapport afgeleverd met de gedetecteerd mankementen van de interface.

De methode dankt zijn naam aan de manier waarop de evaluatie dient te gebeuren. Deze is namelijk gebaseerd op enkele algemene geldende principes betreffende de goede bruikbaarheid van een systeem, de heuristieken. Eventueel kunnen deze heuristieken aangevuld worden met enkele specifieke principes die gelden in een bepaald domein van applicaties. Een lijst van algemeen geldende heuristieken wordt hieronder gegeven[2].

• Zichtbaarheid van systeem status

Het systeem dient feedback te geven aan de gebruiker betreffende zijn huidige status en voortgang.

• Overeenkomst tussen systeem en echte wereld

Een systeem moet verstaanbaar zijn voor de gebruiker. Maak gebruik van natuurlijke taal die de gebruiker begrijpt. Maak acties zoals ze uitgevoerd zouden worden via logische handleingen.

• Gebruikerscontrole en vrijheid

Biedt een simpele uitweg wanneer een gebruiker zichzelf in problemen heeft gebracht. Geef de gebruiker de mogelijkheid om foutieve handelingen ongedaan te maken of handelingen opnieuw uit te voeren.

• Consistentie & standaarden

Ga uit van behoud van consistentie binnen de applicatie. Gebruik standaarden.

• Error preventie

Vermijd het maken van fouten door preventieve controles en/of bevestigingdialogen.

• Herkennen vs herinneren

Maak dingen herkenbaar. Voorkom dat de gebruiker zelf dingen moet onthouden. Bied eerder gebruikte informatie aan waar ze nodig is.

• Flexibiliteit & gebruiksefficiëntie

Maak veel gebruikte acties doeltreffend en makkelijk beschikbaar. Laat toe dat gebruikers zelf shortcuts definiëren voor bepaalde acties.

• Estetisch en minimalistisch design

Ga uit van een minimalistisch design. Vermijd screen clutter.

• Help bij het oplossen van problemen

Maak foutmeldingen begrijpbaar voor de gebruiker. Vermijd weergave van errorcodes. Biedt hulp aan ter oplossing van het probleem.

• Documentatie

Indien nodig, biedt voldoende informatie aan. Maak deze makkelijk beschikbaar voor de gebruiker.

Vergelijking

Zowel het think aloud protocol als de heuristische evaluatie methode worden aangewend ter evaluatie van de bruikbaarheid van een gebruikersinterface. Beiden bieden de mogelijkheid om uitgevoerd te worden aan de hand van een paper prototype, wat de ontwikkelingskost van een applicatie sterk kan drukken.

Beide methodieken berusten op de input van een onafhankelijk testpersoon. Bij een think aloud echter gebeurt de evaluatie door een onervaren persoon, terwijl die bij de heuristische evaluatie door een expert gedaan wordt. Een vaak voorkomend probleem bij een think aloud is dat de proefpersoon denkt dat hijzelf geëvalueerd wordt, waardoor deze geremd wordt in zijn handelingen uit schrik iets fout te doen. Dit probleem stelt zich niet bij de heuristische evaluatie, daar de proefpersoon slechts een objectief rapport dient af te leveren van zijn bemerkingen.

Het think aloud protocol gaat uit van een actie gedreven evaluatie, terwijl het bij de heuristische evaluatie eerder een objectieve analyse betreft. Het voordeel bij de actie gedreven aanpak is dat problemen gedetecteerd worden die rechtstreeks van toepassing zijn op de bruikbaarheid van de specifieke applicatie. Bij de analytische aanpak worden algemene problemen gedetecteerd, ook deze die mogelijks geen invloed hebben op de goede bruikbaarheid van de applicatie.

Een ander verschil betreft de hoeveelheid aan informatie die vrijgegeven wordt door de afnemer van een test. Zoals gezegd is bij een think aloud het hoofddoel fouten te detecteren door de gebruiker al doende met de applicatie te laten interageren. Aangezien hier ook gepeild wordt of de interface hem in staat stel bepaalde doelstelingen te bereiken, dient de observator terughouden te zijn wat betreft het vrijgeven van informatie. Daar dit argument niet opgaat voor de heuristische evaluatie kan de proefpersoon tijdig bijgestuurd worden indien deze niet weet hoe een bepaalde actie uit te voeren. Hierdoor wordt bij de afname van de test geen kostbare tijd verloren.

Tot slot wordt nog even het taakverschil van de observator aangehaald. Tijdens een think aloud test neemt deze een interpreterend houding in. Hij moet de redenen achter bepaalde handelingen zelf nog mappen op problemen in de gebruikersinterface. Dit met het gevaar dat deze verkeerd geïnterpreteerd worden of toegeschreven aan foutieve items in de interface. Dit in tegenstelling tot een heuristische evaluatie waarbij de observator slechts een rapport in ontvangst dient te nemen van de proefpersoon. Hierop worden de door hem gevonden mankementen duidelijk aangehaald, refererend naar de heuristieken waartegen deze zondigen. Uiteraard betreft dit ook alleen maar de identificatie van het probleem, niet de mogelijke oplossingen.

Conclusie

Het evalueren van een gebruikersinterface is niet altijd even simpel. Hierboven werden twee methodieken vergeleken en geconludeerd kan worden dat geen van beiden optimaal is. Beiden beschikken ze over voor- en nadelen.

Positief aan een think aloud is dat deze wijst op problemen specifiek voor de werking van de applicatie. Nadelig is dat berust wordt op de input van een gebruiker die vaak weerhoudend is om te zeggen wat hij denkt. Tevens kunnen de handelingen van de gebruiker verkeerdelijk geïnterpreteerd worden.

Bij de heuristische evaluatie is positef dat de evaluatie door een expert gebeurt die een objectieve analyse levert op basis van heuristieken. Een negatieve eigenschap is dat heuristieken slechts heuristieken blijven en niet altijd de werkelijkheid aan hun kant hebben. Bovendien zijn deze niet altijd getarget op de specifieke applicatie.

Niets staat een applicatie ontwikkelaar uiteraard in de weg te berusten op beide methodieken teneinde de vruchten van beiden te plukken.

Bronnen

[1] http://www.useit.com/papers/heuristic/heuristic_evaluation.html

[2] http://www.useit.com/papers/heuristic/heuristic_list.html 

Conclusie facebook applicaties

De facebook applicatie die ikzelf het best geslaagd vind, is de applicatie Hello Kitty Fightclub. Wat ik als geslaagd ervaar is de simplistische en duidelijke gebruikerinterface. In een enkele oogopslag is duidelijk wat de mogelijk opties zijn en hoe deze uitgevoerd kunnen worden. Bovendien sprak de grafische kant van de applicatie mij aan.. De grafische variëteit tussen de Kitties onderling en de scratches & bruises tijdens de gevechten zijn zeker geslaagd. Het vlak waarop nog enige verbetering mogelijk is, is de gebruiker meer invloed geven in de gevechten. Ook de mogelijkheid om enkel gevechten te houden tussen vrienden, vind ik enigsinds limiterend.

Wat mij opviel bij de presentaties is dat iteratief te werk gaan bij de ontwikkeling van een applicatie zeker zijn voordelen biedt. In een aantal de applicaties was zeker een significante vooruitgang qua usability te merken ten opzichte van de vorige presentatie. Hierbij komt vooral de applicatie Planetary Conquest in mijn gedachten op. De belangrijkste vaststelling bij dit iteratief proces is dat zulk een iteratie zeker niet altijd omvangrijk dient te zijn om een beduidende meerwaarde te bieden.

History of CHI

Geschiedenis van gebruikersinterfaces

Wat we het opmerkelijkst vinden …

Het onderwerp dat ons het meest opvalt in de hele geschiedenis van gebruikersinterfaces is de uitvinding en ontwikkeling van de muis. Niemand staat er nu bij stil dat zoiets vanzelfsprekend en schijnbaar simpel als de muis ook wel degelijk een enorme evolutie heeft gekend. We merkten dit vooral aan het heel beperkt ergonomisch design van de eerste muis, waaruit niet eens de functie van het ‘ding’ duidelijk blijkt. Daarenboven is het hoogst merkwaardig dat deze eerste muis dateert uit de jaren ’60, terwijl de eerste grafische gebruikersinterface pas 20 jaar later functioneel wordt. Het opmerkelijke hieraan is dat men zou verwachten dat de muis is uitgevonden met het doel de iconen te kunnen aanklikken in een grafische interface, en niet omgekeerd.

 Toekomst van gebruikersinterfaces

Wat ons het meest aanspreekt…

De toepassing van interfaces die ons het meest aanspreekt, is de controle van het pointing device op basis van hersensignalen. De interesse in dit domein is vooral te wijten aan het nut van deze toepassing voor mensen met een fysieke handicap. We stonden er niet eerder bij stil dat een gesofisticeerdere interface ook een noodzakelijk middel kan zijn voor handelingen uit het alledaagse leven (zoals van TV-kanaal veranderen), die voordien voor deze mensen niet mogelijk waren.

 Wat we het minst leuk vinden…

 Bij het zien van de futuristische gebruikersinterfaces, stellen we ons vooral de vraag over de steeds groeiende complexiteit van de interfaces. Het zoomen met beide vingers bij een multi-touch-interface lijkt bijvoorbeeld wel voor de hand liggend, maar geen enkele gemiddelde burger die daaraan zou denken wanneer je de interface ziet. Het begint er op die manier meer op te lijken dat de gebruiker een hele tutorial moet doornemen of een hele cursus moet gevolgd hebben, vooraleer hij de interface kan gebruiken. Dit gaat juist het doel van een goede interface voorbij. Een interface op zich zou geen uitleg mogen nodig hebben. Een complexe interface beperkt in die mate ook de doelgroep voor het gebruik van het achterliggend programma. De complexiteit schrikt de gemiddelde burger zelfs af dergelijke interface of programma te hanteren.

 Wat ons het meest beangstigt…

 Als de controle op basis van hersensignalen wel degelijk de toekomst is, vinden we het beangstigend dat niemand problemen heeft omtrent bescherming van de persoonlijke levenssfeer. De nevengebruiker kan gewoon zien wat je denkt (ook de oncontroleerbare gedachten) en kan in een oogopslag je hele verleden achterhalen. Het is gewoon een belachelijke gedachte dat 2 studenten elkaar ‘leren kennen’ zonder ook maar één woord tegen elkaar gezegd te hebben, terwijl ze wel naast elkaar staan. Dit wekt vooral het gevoel op van teloorgang van de communicatie tussen mensen onderling en de angst dat elk individu in zijn eigen leefwereldje zou terecht komen. De gebruikersinterface bepaalt op die manier de leefwereld, terwijl het de leefwereld moet zijn die een goede interface bepaalt door middel van intuïtieve semaforen etc.

 Toegepast op onze facebookapplicatie

In onze facebookapplicatie proberen we de complexiteit van de interface zo laag mogelijk te houden, vooral voor een grote toegankelijkheid te vrijwaren. De focus ligt vooral op het gebruik van de muis (wat ons het eenvoudigst hulpmiddel lijkt bij het gebruik van een programma). Zo worden er sliders gebruikt om aan te geven hoeveel aandelen de gebruiker wil kopen of verkopen, in plaats van tekstveldjes waar je zelf een waarde moet ingeven. Enkel het zoeken naar een zelfgekozen woord op de stockmarkt, vraagt als vanzelfsprekend interactie door middel van het toetsenbord. De gebruiker moet op die manier zo weinig mogelijk switchen tussen verschillende inputdevices.

Presentatie WordStock

De WordStock-presentatie (in pdf)

De PowerPoint dreiging

De huidige tijd wordt gedomineerd door een op hol geslagen gebruik van Microsoft’s PowerPoint. Elk jaar worden er meer dan 12 miljard powerpoint documenten gecreëerd met PP. In de bedrijfswereld vervult PP steeds vaker een rapporteerfunctie die voorheen was toegeschreven aan voluit geschreven technische papers. Ook op hogescholen en universiteiten worden cursussen vervangen door deze presentatiedocumenten.

Wat is nu het probleem? In het verleden werd een rapport, een voorstelling, een observatie gemaakt aan de hand van een geschreven rapport, dat gekenmerkt werd door een continue tekst van voluit geschreven zinnen. Met PP veranderen de zaken; telegramstijl, afkortingen, bulletpoints en een eindeloze sequentie van slides moeten dezelfde taken vervullen.

Het probleem zit in het perspectief, Powerpoint is presentator-georiënteerd, niet inhoud-georiënteerd en ZEKER niet publiek-georiënteerd. Het publiek krijgt een slide te zien met bijzonder lage informatie-densiteit waarvan alleen de presentator de volledige inhoud beheersd. Het publiek wordt gedwongen de informatie te verwerken aan het tempo waarmee de PRESENTATOR dit vrijgeeft. Dit staat haaks op het lezen van een voluit geschreven rapport, waar de LEZER het tempo bepaalt en variable aandacht kan geven aan bepaalde onderdelen.

Het verwerken van informatie gaat ook vele malen trager in een PP presentatie dan in een geschreven tekst. PP presentaties hebben een informatie densiteit tussen 1 en 3 characters/in^2 terwijl een tekst tussen de 20 en 150 characters/in^2 bevat. Daarnaast gebeurt parallele informatieverwerking in het brein sneller dan sequentiële verwerking van een hoop slides.

In het werk van Edward R. Tufte, ‘The Cognitive Style of PowerPoint: Pitching Out Corrupts Within’ wordt een uitgebreide analyse gemaakt van dit probleem. In diens werk wordt besloten dat PowerPoint ALLERMINST geschikt is voor technische inhoud. Een interessante paper die het lezen zeker waard is en zijn gewicht in de schaal gooit bij de keuze van een geschikte rapporteringstool.

Thesisblog

In het begin van ’t jaar werd ons voor onze thesis gevraagd een blog bij te houden. Een op het eerste zicht bijkomende last! Blijkt toch al snel dat het wel degelijk heel nuttig is dit te doen. Het lijkt misschien overbodig per week het geleverde werk te bloggen, en men vraagt zich snel af wat men daar zelf aan heeft. Het is niet alleen een makkelijke informatiestroom naar thesisbegeleiders en promotor, maar het is wel degelijk voor jezelf ook van belang. Na een paar maanden vraagt het immers heel wat opfriswerk nog te weten wat je een paar maand geleden gedaan hebt, welke problemen je had, hoe je ze hebt opgelost etc ..

Mijn thesisblog is te vinden op http://thesis514.blogspot.com en geeft per week een overzicht van het geleverde werk. Aan de GUI van deze blog is als vanzelfsprekend niet veel tijd gespendeerd, hoewel een kleine variatie met kleurtjes, een kadertje hier, een andere font daar, al veel kan doen. De standaard blogpagina http://www.blogger.com ziet er immers veel kaler en saaier uit. Nu, niet dat ik fier ben op de GUI van deze blog, ik wou hier gewoon eerder het gebruik zelf van een blog aanprijzen. En bij deze is een thesis dus een mooie toepassing…

Think aloud (thesis)

Nu het nut van de think-aloud tests wel stilaan bewezen is voor dit vak, is het nu ook duidelijk dit op het programma van mijn thesis toe te passen. Toegegeven, een think-aloud gebeurt best zo snel mogelijk, en nog voor de GUI zelf wordt geschreven, maar het kan volgens mij ook achteraf gebruikt worden om de GUI te finetunen. Ik ben niet van plan nog fundamentele GUI-wijzigingen aan te brengen (dat is ook niet het hoofddoel van mijn thesis), maar een 5-tal think-alouds zouden mij moeten kunnen duidelijk maken of de woordkeuze voldoende verklarend is, de buttons op de juiste plaats staan en doen wat ze verwacht worden te doen etc…

Er zijn al enkele GUI-iteraties aan vooraf gegaan, maar een screenshot van mijn applicatie is voorlopig http://users.vtk.be/~s0161408/Kul/Thesis/previewGUI.png … Het basisconcept is een wizard, waarin de gebruiker doorheen het proces geleid wordt. De think-alouds zullen moeten uitwijzen of dit een goed idee was … Resultaten vind je in mijn volgende post…