Her er en link til vores video scenarie:

http://www.daimi.au.dk/~u070087/video.html

Ventesalen er, både visuelt og fysisk, ret afskåret fra både den nære og den fjernereliggende omverden.

Vision:

Visuel opløsning af de massive grænser mellem ventesal og perron/destination.

Koncept:

Dette forestiller vi os realiseret ved hjælp af information/billeder på skærme (‘vinduer til verden’) i ventesalen.

* Kunne man sætte et kamera i toget, så man indefra kan se hvor toget befinder sig?

* Vil der stå for mange folk omkring skærmen til Kbh en fredag eftermiddag? Hvor langt væk fra skærmene er det muligt at læse teksten?

* Videoscenariet kunne slutte af med at vise, at X er ankommet til Kbh og rent faktisk er taget til den koncert, som hun har set under kulturelle events.

* Vi må nu vurdere hvor mange bolde vi kan have i luften på én gang. Hvor mange forskellige services vi med rette kan hive ud af skærmene?

* Hvor spændende er det at se billeder fra Skjern? Kunne man evt. vise noget andet i stedet?

* Alt i alt mangler vi lige et par iterationer…

2. X orienterer sig i rummet. Det er første gang hun er her.

3. Hun ser en del skærme, 14 i alt, som er fordelt parvis og i øjenhøjde på tre af rummets vægge.

4. Hun ræsonnerer hurtigt, at hun må kigge på en af de 2 skærme som er placeret yderst i hver side af rummet. De ligner afgangstavler. Hver togperron repræsenteres af en “skærm-ø” bestående af to skærme. X kan på afgangstavlen læse, at der er yderligere information at hente på “skærm-ø” 2 idet hendes tog afgår fra perron 2.

5. Hun går derfor hen til “skærm-ø” 2 for at orientere sig. Den ene skærm transmitterer direkte fra perron 2 gennem et farverigt filter. Hun kan tydeligt se mennesker i bevægelse, men det er ikke muligt at identificere hvem disse mennesker er. Ligeledes bemærker hun, at det vil være tydeligt at se hvornår hendes tog kommer ind på perronen. Det synes hun er rart, eftersom at der ikke er noget direkte udsyn til perronerne fra ventesalen. Hun ser desuden, at der, udover forventet afgang, også vises den reelle afgangstid, eventuelle forsinkelser taget i betragtning. Nu kan X altså sætte sig i ventesalen og holde sig orienteret omkring togets ankomst og reelle afgang.

6. X kan dog straks se, at hendes tog er forsinket og nu først afgår kl. 16:10.

7. Derfor kigger hun på den skærm, som er opsat ved siden af den hun lige har kigget på. Her kan hun se et billede af Operahuset i Kbh., som er taget kl. 15:45 samme dag. I det samme skiftes der til et billede af Dronning Louises Bro og lidt af søerne, taget kl. 15:50.

8. Skærmen skifter endnu engang udtryk. Nu vises der en oversigt over kulturelle events i Kbh. den pågældende dag. Hun ser, at det er muligt at interagere med denne skærm via ‘blue tooth’ og kobler sig derfor på ’netværket’ med sin mobil tlf.

9. Hun får nu tilsendt oversigten fra skærmen til sin mobil tlf., så hun kan sidde i toget og overveje, om hun samme aften skal invitere sin kæreste med til koncert på Vega eller til ballet på Det Kongelige.

10. Nu kan hun roligt sætte sig på en af ventesalens bænke og ud af øjenkrogen holde øje med skærmen, som viser togperronen live, og dermed vide hvornår hendes tog ankommer.

11. Hun kigger lidt rundt, og hendes blik stopper ved “skærm-øen” til Berlin. Her ser hun, at der ligesom på “skærm-ø” 2, igennem et filter vises en live optagelse af den pågældende perron, samt et billede, som angiveligt er taget et sted i Berlin. Hun kigger interesseret på dette billede og tænker, at hun snart vil tage en uge til Berlin.

12. Hun ser at informationsskærmen på “skærm-ø” 2 igen skifter tilbage til billedesiden, og hun er allerede i sine drømme i Kbh.!!

Problem: Vi vil gerne have 4 forskellige skærme som man kan interagere med via bluetooth, men hvordan fortæller vi mobilen at det lige er den skærm man kikker på man vil interagere med, og ikke de 3 andre skærme som alle er i samme rum.

Fordelen ved Bluetooth er, at det kan overføre data forholdsvis hurtigt og med et lavt strømforbrug. Specielt er hvilestrømforbruget meget lavt (når der ventes på data). De fleste mobiltelefoner indeholder en klasse 2-enhed der har en rækkevidde på ca. 10 m. Nogle Bluetooth-dongler indeholder en klasse 1-enhed, som har en rækkevidde på ca. 100 m.

Måske vil nogle mennesker sidde for langt væk til at det vil virke på deres telefon.

Pairing: Man kan danne par mellem to apparater, f.eks. mellem en mobil og en computer. Så spørgsmålet er om man kan have 4 bluetooth “netværk”, et fra hver skærm, som man kan koble sig på via sin mobil. Det ville være smart hvis man på mobilen under bluetooth netværk have de 4 skærme man kunne vælge imellem.

Salling Clicker: Er software der skal installeres på mobil telefonen (vi kan vidst ikke komme udenom at man bliver nødt til at gøre dette!) der gør det muligt at interagere med en computer.

“Salling Clicker is our award-winning remote control software. It lets you control popular applications from a mobile phone or handheld computer through a user interface similar to a portable media player. “

Dette skal udforskes nærmere.

Litteratur:
http://en.wikipedia.org/wiki/Blue_tooth#_note-8

http://www.salling.com/Clicker/mac/

Hvorfor Mock-ups?
Mock-ups er gode til at visualisere noget tidligt i design stadiet, og fremmer aktiv involvering af brugerne. Men hvorfor virker de når de er så low tech? De fremmer brugerinvolvering, de er forståelige der er ingen misforståelser mellem den og den rigtige ting, de er billige og sjove at arbejde med.

Vi opfandt det ikke.
Mock-ups er blevet brugt i mange sammenhænge før. Børn har været gode at at lege med mock-ups. De har været brugt i udstillinger hvor produktet ikke er færdigt endnu. Industrielle designere har brugt mock-ups i mange år, specielt til ergonomisk design.
Vores vision er at lave design lege til at forestille sig hvordan arbejds processen kunne være. Vi fokuserer på hardware og software funktionalitet.
Men er mock-ups rigtige design artefakter? Ja det er de, det vil vi argumentere for.

Sprog lege
Vi er ledet af konceptet; hvad et billede beskriver er fastlagt af dets brug. Dette er en holdning af Ludwig Wittgenstein’s Philisophical Investigations (1953). – vi er rådet til at tænke på de sproglege mennesker laver, hvordan vi kan medvirke i menneskelige aktiviteter fordi vi har lært at opføre os i henhold til ikke nedskrevne regler.
Det sværeste med at lege og lave scenarier med en mock-up er at udforme et design sprog som giver mening for alle de involverede. designeren iscenesætter ved at finde og understøtte måder for samarbejde. Fremtids workshops, metaforisk design og organisatoriske design lege er eksempler på hvordan man kan iscenesætte og skabe et fælles sprog. I disse workshops spiller en mock-up en vigtig rolle da man har noget at referere til.

Praktisk erfaring og ready-to-hand brug
Der er mere til mock-ups og sprog lege end bare sprog. Den gør også parktisk erfaring mulig.
Der var et stort breakdown mellem designere og brugere i UTOPIA projektet. Designerne have lavet system beskrivelser men brugerne kunne ikke forstå dem. De mindede ikke brugerne om kendte arbejdssituationer. Derfor lavede de mock-ups af funktionaliteten. Brugerne kunne nu ved hjælp af mock-ups deltage i designet. I starten af en design ide går man ud fra at; i begyndelsen alt had du kan forstå er hvad du allerede har forstået. I dette design paradoks har vi været inspireret af Heidegger, Winograd & Flores, og Dreyfus & Dreyfus. Der bliver snakket om ready-to-hand og present-to-hand da en af typograferne skal afprøve mock-uppen. Den frembrød ingen breakdown i brugerens forståelse, den var ready-to-hand i hans aktivitet. Men da den ikke var det samme som hans traditionelle typografiske værktøjer skete der breakdown i hans readiness-to-hand til at bruge mock-uppen. Han skulle f-eks. bruge en mus i stedet for en kniv.
Praktisk erfaring i bruger involveret design er nødvendigt for at understøtte brugernes ready-to-hand brug af deres fremtidige værktøjer. Altså mock-up er god når brugeren skal være fokuseret på at gøre arbejdet, i stedet for at analysere objekter og relationer.
En design-by-doing sprog leg.

Anden generations mock-ups
Kunne involvere overhætte, slide projekter, båndafspiller, og video.
I den ande mock-up i UTOPIA projektet brugte vi en slide projekter og en skærm til bag skærmsprojektering. Den lignede nu meget mere det endelige produkt. Display interaktionen var simuleret med et slide show og input devices med et rigtigt touch. Denne mockup var specielt god til personer som kun brugte den i kort tid af gangen de og nemt forstille sig hvordan den virkede. Det negative er det dette er dyrere at lave og svære at ændre igen.
Enkle mock-ups: fordele og ulemper
Den er billig og kan hjælpe med at generere nye visioner.
Der er ingen forvirring mellem simulationen og virkelige ting.
Disse mock-ups fører genre til kollaborative modifikationer.
Men de har sine begrænsninger, det kan tage tid at ændre en mock-up, men det betyder også at man skal have en god computer forståelse for at kunne eksperimentere med teknologien.

Computere i mock-ups: overkomme ulemperne
Det samme gælder, kan man visualisere hvad der skal ske. Denne type kaldes storyboard prototyping. Når man går fra mock-ups og storyboards prototypes til rigtige prototypes bliver det muligt at vise rigtige computer funktionaliteter.

Effektive værktøjer
Et eksempel på et computerbaseret hypermedie design miljø kaldet DesignSupport.

At lave passende rigtige begrænsninger
Man skal have et højt kendskab til computere i design gruppen når man arbejder med mock-ups. Ellers kan man ikke komme med passende forslag, hvis ikke må man udforske funktionaliteter på computeren.

Mere funktionalitet
Computere kan bruges til at overkomme mock-uppens utilstrækkelighed. Men prisen er dyr, f.eks. i reduceret brugerinvolvering. Den bedste mock-up er en mellemting mellem pap og computer.

Whats the purpose?
Successfuld evaluering af mock-uppen kræver planlægning og handling, men også forpligtelse fra brugerne. Næsten hver en afvigelse fra det færdige system i en mock-up kræver aktivt arbejde fra brugerne.

Mock-ups; prototype the real thing or both or?
Grunden til at pap mock-ups er så effektive er af igen forveksler dem med det virkelige produkt. Ved brugen af computere er det anderledes. Det kan være svært ikke at mixe computer og mock-up.

Når man designer computersystemer er det viktig med en aktiv og direkte involvering av brukere. For å finne ut hvordan computerapplikasjonen fungerer i en brukssituasjon, så må brukerne ha mulighet til å prøve det ut (experience it). Dette kalles envisionment.

Prototyper er meget nyttig for å finne uuttalte aspekter i brukeres arbeide, og for å få brukerne til å bidra til design av verktøy. I envisionment, er breakdowns noe som kan lede til endring av prototypen, og dermed muligens endre den fremtidige applikasjonen.

Different approaches to prototyping

Tre kategorier innenfor prototyping:

• The prototype becomes the system approaches. –> supplerer en tradisjonell kravspesifikasjon med en prototype av brukerinterface aspekter, før implementasjonen starter. Primært for å få brukere til å justere detaljer i systemet. brukt primært til å demonstrere features, og ikke å la brukere prøve dem ut aktivt.

• Executable specification approaches. –> oppnå en full, formel spesifikasjon av hva det fremtidige system skal inneholde. Skrevet på et formelt språk som brukerne ikke forstår.

• Exploratory approaches. –> mock-ups, simuleringer og ”trow away” prototype utvikles. Målet er å lage “quick-and-dirty” sketsjer, for å klargjøre krav til det nye systemet. Men her er det ikke ofte brukerne blir involvert.

Cooperative prototyping to simulate user participation and creativity

De tradisjonelle metodene (beskrevet over) tar lite hensyn til brukerinvolvering. Derfor introduseres en annerledes metode: cooperative prototyping. Den har røtter i de nevnte metoder, men her vil de demonstrere at prototyping kan være en samarbeidsaktivitet mellom brukere og designere. Cooperative prototyping har som mål å etablere en designprosess hvor både brukere og designere deltar aktivt og kreativt ut ifra dere forskjellige kvalifikasjoner. Brukernes ferdigheter må bringes i kontakt med nye tekniske muligheter. Dette kan gjøres i en simulert fremtidig arbeidsituasjon eller i en virkelig brukssituasjon. Når breakdows forkommer, kan brukere og designere analysere situasjonen, for å finne ut om grunnen er en dårlig/ufullstendig designløsning, eller om det er andre grunner. For at brukerne skal kunne få full erfaring med prototypen, er det viktig at de får utprøve den over et stykke tid.

Examples of Cooperative Prototyping

Det presenteres to eksempler med bruk av cooperative prototyping:

Prototyping of graphic user interfaces

Her brukte de HyperCard på en Macintosh.

Dette eksempel går ut på å utvikle en prototype for pasientsystem på en tannlegeklinikk.

Før prototype-session ble det designet en initial prototype. Session startet med en demonstrasjon av denne for tannlegeassistentene. Deretter ble tannlegeassistentene delt inn i grupper på 2-4 personer. De fikk beskjed om at dette var en fleksibel prototype som kunne endres som man ville. Designeren holdt seg litt i bakgrunnen for å la tannlegeassistentene utforske prototypen og prøve den ut mens de så for seg at de utførte sine daglige oppgaver. Designer brøt kun inn ved breakdown situasjoner.

De fikk flere systemforbedringer ut av denne session, som ble gjort underveis i session. det var også noen forbedringer som krevde litt programmering, da merket de at tannlegeassistentene ble utålmodig fordi de ikke forsto hva som foregikk. Det var også noen forbedringsforslag som ikke kunne gjøres undervei i session, fordi det var store endringer/ tok for lang tid.

Det var en utfordring å skulle bryte inn i session for å endre prototypen underveis, og deretter fortsette evalueringsprosessen.

Dette eksempel viser at, hvis man gir dem en sjanse, er det mulig for en gruppe arbeidere, å komme opp med konstruktiv og kreative bidrag til designet av deres computerapplikasjoner.

Videre viser også eksempelet at det ikke er nødvendig å ha en ferdig utviklet prototype før den skal brukes, man kan endre den underveis.

Prototyping in an organizational setting

Her ble 4. generasjonssystemet ORACLE brukt.

Det arbeides med administrasjonen på en dansk trade school, og dette eksempel tar for seg en del av dette, en prosjektgruppe som arbeider med lagring (gemming) og gjenfinning. Deres oppgaver var å organisere skolens filer så det ble mer effektivt, og til sist i form av en computerapplikasjon.

Konsulentene/spesialistene starter med å intervjue deltagerne og observere deres arbeid. Deretter samles gruppen, og etter innledende diskusjoner, ble tre alternativer til måter å arkivere filene på, foreslått. Det ble laget scenarioer for hvert alternativ. De fikk inspirasjon ved å besøke andre arbeidsplasser.

Etter dette, ble en innledende papir-basert sekvens av skjermbildesimuleringer, diskutert i gruppen. Denne mock-up’en illustrerte én av de tre alternativene.

På basis av disse diskusjoner, bygget konsulentene/spesialistene den første prototypen. Etter hvert som man fikk en mer stabil versjon av prototypen, ble den også brukt i den virkelige arbeidssettingen. Men dette kunne ikke programmeres direkte i ORACLE, de ble nødt å bruke Pascal til å programmere i. I neste steg, når prototypen skulle utvides, ble man nødt å omstrukturere hele databasen, og kaste vekk hele den tidligere prototypen. (Styrelsen forsto ikke poenget med dette, og insisterte på å bruke den prototypen som var. Det fungerte selvfølgelig ikke.)

I noen uker ble (den nye) prototypen brukt daglig, under oppsyn av konsulentene/spesialistene. De hjalp til når det forekom breakdowns.

Ved å integrere prototypene inn i organisasjonens setting, ble det mulig å fokusere både på individuell bruk og på samarbeid mellom folk. Dette eksempel viste at samarbeids issues og det å kjøre prototyper direkte i organisasjonen, var viktig i forhold til en cooperative designprosess.

How to get going with cooperative prototyping

Det er avgjørende for arbeidsgruppen å etablere en felles forståelse for prosessens mål, status til produkter utviklet underveis i prosessen, og rollen til prototyping overordnet i designprosessen. Videre, må man nødvendigvis håndtere noen organisasjonsproblemer, for å etablere en basis for å utføre cooperativ prototyping i et spesifikt prosjekt.

Establishing project groups: making a workable group versus involving a large user group.

Det er mye man skal tenke på når man skal etablere en kompetent gruppe med brukere I design/prototype aktiviteter. Man vil gjerne ha mange ulike typer brukere, men det skal heller ikke være for mange. Det viktigste er å etablere en arbeidsgruppe sammen med kompetente brukerrepresentanter. Det er også viktig et designerne og brukerne blir godt kjent men hverandre for at de skal kunne samarbeide godt, og alle skal ha mulighet til å bidra. Samarbeide er viktig for å vedlikeholde den kontinuerlige læringsprosessen mellom brukere og systemutviklere.

Prototyping er en læringsprosess, og generelt er prototyper en god måte å opplære fremtidige brukere på.

En god ide dersom det er en stor organisasjon er å starte i en del av organisasjonen, deretter bringe denne prototype videre til en annen del som bidrar på den, og så til en neste del etc.

Setting up prototyping sessions: designers as conductors versus users being in charge

Brukerne bør ha mulighet til å utprøve prototypen over lenger tid, og designerne kan så bidra dersom breakdows oppstår. Det er designerne som vet hvordan prosessen bør settes opp, men det er viktig at prosessen tilrettelegges i forhold til brukernes behov og ønsker.

Providing prototypes: showing fantasy versus being limited by the tools

Dersom dårlige prototyper presenters for brukerne, er det selvfølgelig en fare for å miste poenget, men man kan si at et dårlig eksempel er bedre enn ingen eksempel, hvis prototypens status blir gjort klar. Manglene med en prototype kan kompenseres med en god forklaring av dem.

Det finnes en rekke verktøy man kan bruke i forbindelse med cooperativ prototyping. F.eks. Smalltalk, LISP verktøy, HyperCard.

Alternativer kan være gode å ha, de kan stimulere til brukernes fantasi og dermed oppfordre gruppen til å diskutere forskjellige måter å organisere arbeidet. En måte å få brukerne til å foreslå alternativer, er å illustrere hvor enkelt man kan endre på prototypen.

Maintaining communication: describing requirements versus experiencing work

Designere bør måske studere brukernes arbeide mer nøye og diskutere med dem videre, før forslag kan forstås. Det er viktig å huske at brukerne er nøkkelen til design av et brukbart system og designerne er nøkkelen til å fremme brukernes krav i det tekniske designet av systemet. Det utfordrende ved design av en applikasjon, kan være å finne balansen mellom at den skal være nyttig for brukerne og ha en høy teknisk kvalitet sett fra et teknisk synspunkt.

Users perception of the process: realistic prototypes versus unrealistic expectations

Prototypene skal være realistisk og stabile nok for at brukerne kan styre evalueringen. Men det er også viktig å fra starten av, gjøre oppmerksom på at prototypene bare er grove skisser. Prototyper kan skape blindhet omkring at det kan være andre måter å løse problemene på.

Maintaining focus: A technical versus a work-oriented focus

Kunnskap om domenet er avgjørende!

Diskusjon i en prototypesession foregår ofte rundt interaksjonen med computeren, og ikke om hvordan arbeidet i organisasjonen rundt computeren er. Det er viktig å ikke få for teknisk fokus.

Getting resouces: adding more resources to early activities versus lowering development costs

Det som muligens krever mest resurser er deltagelse fra flere brukere. De dyreste feil eller mangler i et system er de som gjøres i de tidlige fasene, hvor fokus er på analyse og design. Cooperative prototyping kan hjelpe til å forutse noen av de dyre feiltrinnene, og mest sannsynlig redusere utviklingskostnadene.

Design as an ongoing process

Cooperativ prototyping kan brukes for å bedre kvaliteten til computersystemer sett fra brukeren synspunkt, dvs brukerne kan få et system som er mer tilpasset deres behov og kan bedre kvaliteten på deres arbeide. Design er en løpende prosess. Cooperativ prototyping skal ikke ses på som en tilgang til å produsere det ultimate computersystem for et applikasjonsdomene. Det bør heller ses på som en av de første stegene i den løpende utviklingsprosessen.