• No results found

Interface en afleiding 27-03-2014 13:

Rond sub-deelvraag 4.1 (Welke behoefte heeft de gebruiker?) is het nodig om voor de doelgroep proefpersoon te onderzoeken wat afleiding voor effect heeft. Met focus op de vraag in hoeverre het prototype applicatie zichtbaar mag zijn tijdens het uitvoeren van tests. Op basis van de al reeds

verzamelde informatie voor dit project heb ik een gebruiksscenario opgesteld dat overeenkomt met die van een testpersoon.

Gebruiksscenario:De prototype applicatie instrueert de testpersoon aan het begin van de test. Zodra de taakomschrijving bij de testpersoon bekend is kan de test worden begonnen. Het prototype verdwijnt naar de achtergrond en de testpersoon start de te testen applicatie. Gedurende de test wil de testpersoon nog een keer de taakomschrijving inzien. Zodra de taak is volbracht geeft de testpersoon dit aan. Er wordt aan het einde van de test naar de gedachten en ervaringen over de test gevraagd.

Dit scenario geeft diverse hints over de manier van interactie die met het prototype kan gaan plaatsvinden. Hieruit zijn twee posturen op te maken waarin de applicatie zich kan begeven:

1. Een sovereign postuur voor en na de test 2. En daemonic postuur tijdens de test

(Zie het hoofdstuk over application posture in Cooper 161-199)

Voor de interactie die plaatsvindt op de momenten dat de app een sovereign postuur heeft kan normaal Android design worden gebruikt

Het tweede gedeelte tijdens de test is waar het interessant wordt. De deamonic houding houdt in dat hij niet of nauwelijks zichtbaar is voor de gebruiker. Dit houdt in dat er maar enkele design patterns

bruikbaar zijn bij het ontwerpen van dit gedeelte van de app.

Floating view

Een view die zich boven alle andere lagen van het systeem begeeft. Deze pattern komt in toenemende mate voor in Android. Veelal bij apps die zich lenen voor gebruik in combinatie met andere apps.

Het voorbeeld is een calculator applicatie die wordt gebruikt in samenwerking met de email client Gmail.

De posture die hieraan valt toe te kennen hangt af van de afmeting van de view. Zoals zichtbaar in de afbeelding valt type Transient posture hieraan toe te kennen. Deze manier is niet bruikbaar omdat het een te groot deel van het scherm overlapt. Tenzij

de afmeting minimaal is, dan is de afleiding en afdekking ook minimaal. Misschien is het dan toch bruikbaar in het prototype.

Control notification

Notificaties in Android kunnen worden gebruikt om de gebruiker in te lichten. Denk hierbij aan het binnenkomen van nieuwe berichten als email, sms, sociale updates en gemiste telefoongesprekken. Ook worden notificaties gebruikt om zaken te kunnen bedienen vanuit het notificatie scherm. Dit scherm kan ten allen tijden worden geopend door de vinger van de bovenkant van het scherm naar beneden te schuiven. Bij deze typen notificatie kan een custom view worden ingebracht die content en of bediening bevat.

In het voorbeeld kunnen twee verschillende notificaties worden gezien. De bovenste notificatie bevat een melding van een gemaakte screenshot. Tevens wordt hier een

deel van de content getoond. Notificatie twee toont informatie over een background service: de mediaspeler. Er zijn controle mogelijkheden voor de muziek en het kan worden afgesloten door het kruisje.

Als het notificatie venster is gesloten zijn de nog actieve notificaties zichtbaar middels een klein wit icoontje. Deze pattern valt onder het daemonic postuur.

Voice recognition

Stemherkenning is iets wat we bij alle smartphones terugzien. iphone heeft Siri, Androiid heeft Google Now. De stemherkenning kan worden gebruikt om zoekopdrachten te doen en systeemonderdelen te bedienen.

Het voorbeeld toont het stem zoek invoerscherm van Google Now. Er kan door middel van de term “OK Google” direct worden begonnen met het spreken van de zoekterm. Nadat de stem is vastgelegd wordt deze geanalyseerd en gebruikt als zoekterm. Sinds api 8 is er voor ontwikkelaars de mogelijkheid deze functie ook te gebruiken. Nadat de stem is opgenomen wordt deze geanalyseerd. Er komt vervolgens een array

aan data terug met de mogelijke matches voor de ingesproken tekst. De array volgorde loopt van meest overeenkomend tot minst.

Stemherkenning kan worden gebruikt om opdrachten te geven aan het prototype applicatie die in de achtergrond draait. Zo is er geen fysieke interactie nodig, iets wat bij het testen goed kan worden gebruikt.

Gesprek met het design team (8-4-2014)

Met de bovengenoemde kennis ben ik in gesprek gegaan met het design team. Door met echte

voorbeelden te werken konden ze een goede indruk krijgen van het gebruik van de patterns in combinatie met andere apps. Hieruit kwam naar voren dat de stemherkenning een zeer goede methode is voor het aansturen van het prototype applicatie die in de achtergrond draait. Ook werd het gebruik van een notificatie tijdens de loop van de test als belangrijk beschouwd. Een kleine indicatie dat de test actief is vinden zij een belangrijk punt van feedback.

Met deze informatie heb ik een simpele protyotype van de werking gemaakt van stemherkenning in combinatie met het gebruik van een notificatie. Het is mogelijk drie commando’s te geven tijdens het uitvoeren van de test. Hierop reageert de applicatie door de tekst via een kort systeemberichtje (een toast) te tonen. Hier kan in de toekomst de werking aan worden gekoppeld.

De leden van het design team vonden de werking zeer positief. Er waren alleen wat moeilijkheden met het zeggen van de juiste commando’s. Ik heb hieruit opgemaakt dat ik goed moet testen wat voor commando’s goed werken. Mogelijk moet er ook een errormarge worden verwerkt om het herkennen te verbeteren.

Toevoegingen later in het project (22-4-2014)

Stembesturing is een zeer interessante mogelijkheid, maar het belang van audio opnamen woog zwaarder. De technische uitwerking van stembesturing bleek niet heel moeilijk. Door Google ’s stemherkenning middels een service uit te voeren kon dit in een continue loop worden uitgevoerd. In vroege prototypen werkte dit ook redelijk goed in rustige omgevingen. Verder onderzoek bleek aan te tonen dat het alleen niet mogelijk was de audio stream die de stem herkenning gebruikt ook op te slaan op de telefoon. Een combinatie van het gebruik van de stem herkenning samen met het opnemen van de audio van de microfoon werkte ook niet, het resulteerde er in dat beide geen audio ontvingen. Er moet daarom een keuze gemaakt worden voor een van de twee en omdat audio opname zwaarder weegt door de inzichten die het verschaft, valt stembesturing af. Als fallback ga ik toch proberen met de floating view te werken. Al moet het wel in een zeer klein profiel zodat het minimaal opvalt.

Hallway testing experiment: Thinking aloud