Design og funktionel prototype 2.1) Minus scenarie Der bliver sendt nye billeder til rammen og Hans ønsker at se billederne, men billederne rotere for langsomt så Hans går op og bruger touch funktionen til at rotere til næste billede og går tilbage til sofaen. Næste billede roterer også for langsomt så Hans bliver irriteret, da han skal op og skifte til næste billede igen. Så han vælger at blive stående tæt på skærmen for at se billederne, hvilket resulterer i, at han får ondt i hovedet/øjnene fordi det er nødvendigt at stå tæt på en stor ramme og se billedet Plus scenarie Arne er på ferie ved en strand og tager et billede og sender det til rammen. Hans forældre sidder foran rammen og ser det nye billede der bliver sendt. De observerer at Arne har tabt sin pung og at den ligger i sandet på billedet. De skynder sig at ringe til Arne og han slipper for at bruge timevis på at lede efter pungen på stranden. 2.2) Konceptuel model Hovedmetaforen/analogien er, at designet skulle repræsentere det familiære ved et almindeligt fotoalbum, hvori delingen af billeder med andre er en relativ smal sag. Analogien ved at bladre på touch skærmen bringer associationer til at man vha. touch screen funktionen bladrer i fotoalbummet for at se det næste billede. En interface-metafor kunne (igen) være tanken om enten en fysisk eller digitalt fotoalbum. På den ene side er en fin beskrivelse af, hvordan interfacet var tiltænkt at det skulle virke. Men på den anden side kunne det virke restriktivt og mindske lysten for en del brugere, da det kunne skabe associationer med det bøvlede ved at oprette et online/digitalt fotoalbum. De centrale begreber i vores konceptuelle model er Interaktionstyper, Interfacetyper og metaforer/analogier. Metaforerne og analogierne bruges til bedre at kunne formidle hvordan designeren (vores) idé/mentale model skal opfattes og bearbejdes af brugeren. Interaktionstyperne og interfacetyperne, som nævnes senere i afleveringen, er andre måder for designeren til at kunne udforme sin konceptuelle model efter. I forbindelse med den konceptuelle model sammensatte vi en low fidelity prototype, afbilledet af vores mentale model af, hvordan vi opfattede designet. Prototypen blev fremvist for andre fra holdet for først og fremmest at få synkroniseret vores mentale model af designet med potentielle brugeres model og opfattelse. Samt bare generelt respons og evt. muligheder som vi eventuelt havde overset (f.eks. grundet i forbindelse med valget af 2 interviews vs. et spørgeskema).
De aktiviteter som rammen understøtter er, at se et slideshow af billederne på rammen, modtage nye billeder fra en ekstern kilde, manipulér billederne med mulighed for f.eks. at kunne rotere og stoppe billede slideshowet samt se et overblik af alle/mange billeder på en gang. Interaktionstyper Fra bogen opstilles der 4 overordnede interaktionstyper: Instruktion, konversation, manipulation exploration. Af de 4 interaktionstyper vurderede vi, at den der passede bedst til vores Design er manipulation. Grunden til dette er, at man først og fremmest vha. vores touch screen styrer slagets gang ved at manipulere med skærmen. Selve fremgangsmåden ved touch skærmen vil, efter en kort introduktion, være ligetil for stort set alle brugere. Også dem der normalt ikke er IT-kyndig. Dette hænger ganske glimrende sammen med vores tidligere etablerede Usability goal: Learnability. Da associationer mellem rammen og et fysisk fotoalbum forekommer, ville fremgangsmåden også virke yderst logisk efter de indledende knæbøjninger. Derved opnås det andet Usability goal: Memorability. Grunden til at vi ikke har valgt instruktion interaktionstypen er, at jo flere kommandoer og knapper der er for at kunne navigere rundt i systemet ville det højest sandsynligt komme i konflikt med nogle af vores user experience goals samt usability goal et: Learnability. De user experience goals vi har valgt, som ikke stemmer overens med den (mulige) indlæringskurve det kunne kræve at sætte sig ind i system, er User friendly & Simplicity. Kort sagt, så kan det virke afskræmmende og nedsætte lysten til at bruge systemet. Grunden til at vi heller ikke har valgt interaktionstypen konversation bliver også forklaret i næste afsnit omkring interfacetyper, hvor vi har opsat fordele og ulemper omkring brugen af samtale/stemmeaktivering. Et andet problem i forbindelse med konversation er, at de input muligheder man har, kan være yderst begrænset alt efter hvordan det er implementeret. Til sidst har vi interaktionstypen exploration. Den blev heller ikke valgt fordi, at vi vurderede at det ikke som sådan havde nogen positiv indflydelse på vores Design. Under interfacetyper har vi også vurderet fordele og ulemper i forbindelse med brugen af noget gesture/motion control til at styre systemet/rammen. 2.3) Interfacetyper Vi har kigget på lidt forskellige valgmuligheder af interfaces til vores ramme heriblandt bevægelse, lyd, fjernbetjening, knapper under skærmen og touch. Bevægelse Rammen kan finde finde på at reagere på tilfældige bevægelser i rummet. Tager lidt plads at sætte sensorer op på.
Man behøver ikke bevæge sig for at skifte billede. Lyd Rammen kan finde finde på at reagere på tilfældige lyde i rummet. Hvis man inverterede funktionen, så rammen skiftede billede når der ikke var noget lyd i rummet. Ville det virke mærkelig, hvis man skulle få alle i rummet til at stoppe med at sige noget for at få billedet til at skifte. Man behøver ikke bevæge sig for at skifte billede. Fjernbetjening Hvis rammen selv skifter billede automatisk, så vil det forhåbentlig sjældent være nødvendigt manuelt at skifte billede og herved bliver fjernbetjeningen måske lidt overflødig Det ville være irriterende at have endnu en fjernbetjening at holde styr. Man ønsker måske ikke at have den til at ligge frit fremme Knapper under skærmen Det kan virke afskrækkende hvis der er en masse knapper. Vores erfaringer siger at mange aldrig for lært at bruge knapperne. Det gør skærmen større der skal bruges mere plads Det virker intuitivt at bruge, hvis det er designet rigtigt. Det fylder ikke ret meget mere end bare skærmen Touch Skærmen kan blive lidt fedtet.
Af bl.a. overstående grunde kom vi frem til at Touch ville være det bedst valg. Mere specifict: så touch den ting som hænger bedst sammen med vores User experience goals. Fx er touch user friendly, da det generelt er meget intuitivt hvad med skal gøre ved brugen af touch. Fx hvis man se billeder slide fra højre mod venstre. Så giver det god mening at tage ens finger og prøve at bladre til højre for at komme til forrige billede. Touch kan gøre interfacet meget simpelt da det nærmest gør interfacet usynligt (Simplicity goal). 2.4) Storyboard Storyboard illustration af Designet.
Low fidelity protoype Uddrag fra vores kortbaserede prototype. Skanningskvaliteten er lidt tvivlsom på de første 2-3 billeder, men forhåbentlig er mening ikke helt forsvundet.
Evaluering I forbindelse med evalueringen af vores kortbaserede prototype med de andre grupper nåede vi frem til følgende punkter/faldgruber/? Flere af ideerne er slået sammen under fælles punkter og derefter forklaret. 1) Mulig video og højtalere. Der var et ønske om en mulighed for at kunne afspille og dele videoer vha. rammen. I forbindelse med videomuligheden blev der, logisk nok, foreslået integreringen af højtalere. 2) Billedmanipulation. En glimrende idé omkring muligheden for at kunne manipulere med billederne. Vi havde selv tænkt på idéerne såsom multi-touch samt muligheden for at stoppe billede cyklussen ved at tappe på skærmen. De andre idéer var muligheden for at kunne zoome ind på det givne billede og dreje det. 3) Sikkerhed. En vinkel vi ikke selv havde kigget så meget på var sikkerheden omkring billeddelingen og rammen. Ville det være muligt for andre at kunne sende og derved uploade uønskede billeder? Skulle man kunne låse sin ramme med et login eller måske en bekræftelsesmenu hvor man godkender hvilke billeder der skal vises/gemmes i rammen. Hvad ville der ske, hvis et billede uploadet fra f.eks. en computer blev slettet? Ville det stadigvæk eksistere i rammen eller ville det også blive slettet? Flash prototype Vi vil bruge touch skærm, men af arbejdsmæssige grunde har vi sat pinke knapper ind for at teste funktionaliteten. Disse vil så blive erstattet med usynlige knapper senere evt. med slide. På nuværende stadie vil det være muligt at trykke i toppen af skærmen for at få et overview frem hvor der kan bladres igennem thumpnails af billederne. Findes et ønsket billede kan det trykkes og brugeren vil blive ledt til det pågældende billede. På nuværende tidspunkt vil programmet ikke gå videre fra andre end "isbjørn" billedet (frame 1). Billedskiftning virker nu med hardcoded billeder, og formår at "wrappe" rundt når den når til enden af billedrækken. Modtaget billede er defineret som en knap, men har endnu ingen funktion. Alle knapper styres pt. via musen.