Indledning

Den lille bog om design af fysiske prototyper hedder sådan, fordi den kun berører et meget lille hjørne af et meget stort emne. Der er med andre ord truffet nogle valg. Det første valg er, hvem bogen henvender sig til? Her er svaret, at det er gymnasieelever med informatik på C-niveau, der ikke har lært at programmere endnu. Dette valg har indflydelse på, hvilken platform vi vil arbejde på. Her har vi valgt micro:bit, som er hurtig at gå til, og som ikke kræver meget i forhold til programmering. Man kunne godt have valgt noget andet, og det kan ikke udelukkes, at det der foreslås her kan anvendes med andre platforme.

Udgangspunktet er ikke programmering, men derimod design. Det er ikke det samme som, at der ikke optræder programmering. Det vil være sådan, at programmering er et værktøj til at få et design til at virke.

I forhold til design er der nogle ting, der mangler og som kunne tilføjes. Men bogen er tænkt som en indledning og ikke som et fuldstændigt katalog over designteknikker.

Licens

Denne bog er copyright (c) 2024-25 af Jens Chr. Larsen. Bogen er udgivet under en CC-BY-SA 4.0 licens. Hvilket giver ret til at anvende bogen i vid udstrækning. Bogens kildekode kan findes på github.

Prototyper

Design handler om at skabe objekter eller programmer, der kan hjælpe mennesker til at opnå noget bestemt. Vi vil i denne bog bruge en samlet betegnelse produkt om det, der skabes. Heri ligger det ikke, at det nødvendigvis er et kommercielt produkt, der skal ud på et marked og sælges. Det kan også være noget, som ikke skal tjene penge til nogen. Så ordet produkt betyder i følgende "bare" det, der skal designes.

Når vi designer et produkt til nogen, så kunne en tilgang være at skabe vores produkt, og så sende det ud til dem, der skal bruge det, nemlig brugerne. Det vil ikke være en god idé! For hvordan kan vi vide, at nogen faktisk er interesseret i vores produkt? Hvordan kan vi vide om nogen kan finde ud af at anvende vores produkt? Og hvordan sikrer vi, at produktet faktisk opfører sig som tænkt, når det kommer ud i den virkelige verden?

Svaret på disse spørgsmål er, at vi laver prototyper af produktet. En prototype kan defineres således:

Formålet med prototypen er at have noget, som vi kan vise en bruger, og som vi kan få feedback på. Vi behandler brugertest i det næste afsnit. Men først ser vi på forskellige typer af prototyper.

Lo-fi og hi-fi prototyper

Der eksisterer rigtig mange former for prototyper. Så derfor giver det mening at inddele dem alt efter, hvor tæt de er på det endelige produkt. Vi anvender betegnelserne lo-fi og hi-fi. Betegnelsen lo-fi kommer af det engelske "low fidelity", hvilket kan oversættes til "lav trofasthed". Det betyder i denne sammenhæng, at prototypen er langt fra det endelige produkt. For eksempel kan der være forskel i anvendelsen af materialer, eller at prototypen overhovedet ikke ligner, rent fysisk, det tænkte produkt.

Den anden betegnelse hi-fi kommer også fra engelsk og betyder "high fidelity", hvilket kan oversættes til "høj trofasthed". En hi-fi prototype vil være tæt på det endelige produkt, enten i udseende eller i funktionalitet (eller begge del).

Det vigtigt at holde sig for øje, at inddelingen lo-fi og hi-fi ikke er to kasser, men derimod et spænd. Det vil sige, at vi kan tale om, at prototyper kan være mere eller mindre lo-fi eller mere eller mindre hi-fi. Hvor skiftet mellem lo-fi og hi-fi, så ligger kan der ikke gives noget endegyldigt svar på. Men en tommelfingerregel kunne være, at vi er nærmere hi-fi end lo-fi, når enten prototypens udseende eller dens virkemåde er tæt på det endelige produkt.

Papirprototyper

Den første prototype, det giver mening at lave, vil i langt de fleste tilfælde være en papirprototype. Denne prototype laves ved at man tager et eller flere stykker papir/pap, og så tegner på det. Det kan være der tegnes omridset af en mobiltelefon, hvori der tegnes knapper og lignende, der udgør en apps brugergrænseflade. Hvis det er en fysisk ting, så tegner man den fysiske ting.

Formålet er, at hurtigt at få lavet en skites af det vi har tænkt, og som vi hurtigt kan afprøve. Hvis ideen bag prototypen viser sig at være dårlig, så skal vi smide prototypen ud og prøve med noget andet. Derfor er det vigtigt, når man laver en papirprototype, at man ikke bruger en masse tid på at lave pæne tegninger. Jo mere energi, der brugt på at lave en papirprototype, jo sværere er det at smide den ud bagefter. Faren ved pæne tegninger er, at man holder fast på en dårlig idé, fordi man har investeret for meget tid i prototypen.

Ideen med papirprototyper er at lave flere tegninger, der hver især viser forskellige billeder alt efter, hvad der er kan ske, når en bruger anvender det tænkte produkt. På den måde kan man indfange det dynamiske i anvendelse af ens produkt.

Et eksempel på en papirprototype, der er en elektronisk nøgle til en dør, kan ses herunder. Først har vi den elektroniske nøgle.

Og her har vi det døren skal vise. Der er tegnet piktogrammer over et dørhåndtag.

Det første billede viser et stykke pap, hvor der er indtegnet tre knapper. På hver knap er der tegnet symboler, der burde fortælle, hvad knappen gør. Ideen er, at hver knap svarer til hver af de tre ruder i billede to. Det har ikke taget undertegnet længere end 5-10 minutter at tegne de to ovenstående tegninger.

Så generelt:

• Papirprototyper er et første forsøg på at lave noget, der kan undersøges.
• Papirprototyper kan være ting, der ikke findes endnu.
• Papirprototyper skal kunne smides ud, hvis de ikke er gode.
• Papirprototyper skal derfor laves hurtigt og ikke alt for pænt.
• En papirprototype er altid en lo-fi prototype.

Fysiske prototyper

Efter papirprototypen, som ingenting kan, men som ligner, så kan det være nødvendigt at skabe en prototype, der kan noget, men som ikke ligner. Dette kan laves ved hjælp af en fysisk prototype. Der findes forskellige platforme (små computere), der kan programmeres til alt muligt. Netop fordi de kan programmeres, kan de anvendes til at undersøge om forskellige handlinger er mulige for brugeren. For eksempel kan vi få en dør til at åbne sig, hvis bestemt person kommer tæt nok på døren, men være lukket for alle andre?

Vi giver et eksempel på en fysisk prototype, der har til formål at få brugeren til gå i en bestemt hastighed.

Prototypen består af to micro:bit. På billede 1 kan den ene micro:bit ses i en plastikpose, der er spændt om benet. Den anden micro:bit (billede 1,2 og 3) fortæller brugeren vedkommende går for langsomt (billede 2), rammer hastigheden (billede 3) eller går for hurtigt (billede 4).

Denne prototype er programmeret til at gøre noget bestemt. Det, prototypen kan anvendes til, er at undersøge, om det er muligt for folk at holde tempoet, men også at undersøge om det, der er programmeret, virker. Således er den fysiske prototype tættere på det endelige produkt, men vi skal nok ikke regne med, at brugeren vil sætte en plastikpose fast til benet. Så det er stadig en lo-fi prototype. Vi kan selvfølgelig nærme os en hi-fi prototype ved at se på indpakningen af udstyret.

Så generelt:

• Fysiske prototyper kan noget.
• Fysiske prototyper skal programmeres før de kan noget.
• Der er flere ting vi kan undersøge med en fysisk prototype.
• En fysisk prototype er mere hi-fi end en papirprototype, men er stadig en lo-fi prototype.

Afrunding

Vi har ovenover præsenteret prototypebegrebet og vist to eksempler på prototyper. Prototyperne skal dog anvendes til noget, nemlig til undersøge om brugeren af vores produkt kan anvende produktet. Vi ser derfor på brugerundersøgelser med prototyper.

Brugertest

Når vi designer produkter, så er vi nødt til at forholde os til, om brugeren kan anvende produktet på den måde, det var tiltænkt. Vi har en hjælp i prototyper, fordi de, på et tidligt stadie i processen med at designe, kan hjælpe os til at undgå problemer, der være vanskelige at løse senere.

Der findes utrolig mange måder at undersøge produkter på. Så vi nøjes med at præsentere én her, som har den fordel, at den er hurtig at udføre, og giver en del brugbar feedback.

Tænke-højt-test

En tænke-højt-test foregår ved, at vi beder en person om at bruge vores prototype, og tænke højt imens de gør det. Det lyder simpelt, men der er (mindst) to faldgrubber. Den første er, at fortæller testpersonen præcis, hvad vedkommende skal gøre. For eksempel, at man siger, først trykker du på den knap, så den knap og så... Det fratager testpersonen muligheden for at tænke og så får vi ikke undersøgt noget. Den anden faldgrubbe er, man spørger de forkerte. Det kan være, at man har lavet noget til pensionister, men tester det på ens klassekammerater.

Med disse betragtninger i baghovedet, kan vi opstille en fremgangsmåde for test af prototyper med tænke-højt-testen. Vi vil anvende papirprototypen fra sidste afsnit som eksempel.

1. Begynd med at finde den/de ting i ønsker at undersøge med prototypen (I kan for eksempel spørge: Kan brugeren låse døren op?).
2. Find en bruger som faktisk kunne tænkes at anvende produktet og få vedkommende til at være testperson.
3. Fortæl testpersonen overordnet, hvad produktet skal kunne (I kan for eksempel sige: Det er en elektronisk lås til en hoveddør).
4. Giv testpersonen en opgave som skal udføres med prototypen (I kan for eksempel give opgaven: Lås døren op).
5. Bed testpersonen om at tænke højt imens vedkommende udfører opgaven.
6. Skriv ned, hvad der sker, især er handlinger, der ikke er forventet interessante.

For at forstå hvordan tænke-højt-test virker giver vi et eksempel

Eksempel på tænke-højt-test

I dette eksempel vil vi anvende papirprototypen fra det sidste afsnit. For at papirprotypen kan anvendes klipper vi en ud i 3 dele, så testpersonen kun skal forholde dig til ét billede af gangen. Når der skal ske noget skifter vi billedet ud.

Eksemplet forgår som en tænkt samtale mellem testeren (den der har lavet prototypen) og testpersonen (den der skal tænke højt).

Tester: Vi har lavet et elektronisk låsesystem, som vi ønsker at teste. Så om lidt får du et stykke pap, der skal fungere som nøgle, og vi viser med et stykke papir, hvordan døren ser ud. Vi vil godt bede dig om at låse døren op. Imens du gør det vil vi gerne have, at du tænker højt. Det vil sige, at du giver os dit indtryk af nøglen og døren og fortæller os, hvad du mener, at du skal gøre. Og så skal lade som om, at gør det.

Testperson: Forstået.

Testeren giver følgende nøgle til testpersonen.

Testeren lægger følgende billede af døren på bordet foran testpersonen.

Testperson: Nøglen er godt nok grim. Det er svært at læse teksten. Men jeg tror, at jeg vil trykke på den store knap øverst for at låse op.

Testpersonen lader som om, der trykkes på den store knap i toppen.

Testeren skifter billedet af døren ud med følgende.

Testeren: Nu viser døren dette.

Testperson: Ok, nu er døren åben. Men hvorfor står, der 6 i højrehjørne.

Testeren skifter efter 6 sekunder billedet af døren ud med følgende.

Testperson: Hov nu er døren låst igen. Det gik hurtigt. Hvis jeg havde vidst det, havde jeg skyndt mig lidt. Måske skulle jeg bruge den lille lås-op-knap.

Testpersonen lader som, der trykkes på den lille knap nederst til venstre på nøglen.

Testeren skifter billedet af døren ud med følgende.

Testperson: Nu er døren åben og uden sekstal. Men hvorfor er der egentlig et kæmpe ikon, der fortæller om døren er låst? Jeg vil nok ikke ønske, at min dør fortalte uønskede gæster, at den ikke er låst.

Eksemplet er måske ikke helt realistisk, men illustrerer ideen bag tænke-højt-testen. Resultatet af denne test er, at designerne nu ved nogle ting om hvad der skal arbejdes med:

1. Overordnet, så kan brugerne godt anvende prototypen.
2. Vi bør overveje om 6 sekunder er nok, eller om det er nået brugeren hurtigt kan lære.
3. Der er et sikkerhedsaspekt i om døren visuelt skal fortælle om den er låst eller ej.

Afrunding

Oven for har vi præsenteret tænke-højt-testen og givet et eksempel med en papirprototype. Når vi tester fysiske prototyper, så gør vi det samme. Men der er en ekstra ting vi skal notere os. Nemlig, hvordan testpersonen opfører sig rent fysisk. For eksempel hvor ser vedkommende hen, hvordan bevæger vedkommende sig og så videre. Da den fysiske prototype i sidste afsnit blev testet, kiggede alle testpersonerne på displayet med lysdioder. I stedet for at se hvor de gik. Det kunne være en potentiel fare, at folk ikke er opmærksomme i trafikken, når udstyret anvendes. Det gav anledning til at undersøge om, der var andre metoder til at fortælle brugeren om vedkommende gik i det rigtige tempo.

Storyboard

Der findes rigtig mange måder beskrive, dokumentere, eller vise hvad en prototype kan. En forholdsvis hurtig metode er at indfange de(n) situationer, hvor prototypen anvendes er i et storyboard.

Et storyboard en række billeder, der til sammen fortæller en historie. Vi giver et eksempel.

Storyboardet oven for viser seks billeder, der alle har et lille tal i øverste venstre hjørne. I billede 1 er der en person, der trykker på en eller anden ting i hånden. Resultatet af det tryk kan ses i billede 2 og 2A (A for alternativ). Hvor døren bipper en eller tre gange. I billede 3, går personen ind af døren , hvilket leder til billede 4 og 4A. I billede 4 går der 6 sekunder, og så siger døren bip to gange. I det alternative billede 4A går personen igen, men der trykkes på noget i hånden. Døren bipper to gange. Du har nok regnet ud, at der er tale om en trådløs lås ligesom til biler.

Et storyboard indfanger med andre ord anvendelsen af en prototype. Særligt kan et storyboard beskrive en prototype, der ikke eksisterer endnu. Det er især evnen til at beskrive fremtiden, der gør prototyper interessante i en designsammenhæng.

Vi kan give nogle gode råd til, hvordan et storyboard med fordel kan skabes:

• En handling i en ramme.
• Giv rammerne et tal, så er det lettere at holde styr på rækkefølgen, især hvis du glemmer et billede, og skal tilføje det senere.
• Tegn rektangulære kroppe og ovale hoveder. En rektangulær krop kan lettere vise, hvor den er på vej hen. Et ovalt hovede, kan lettere vise, hvor det kigger hen.
• Spild ikke tid på at tegne for pænt.
• Skriv vink på tegningerne. For eksempel, lyde, tider, og så videre.
• Et storyboard behøver ikke vise en situation, hvor tingene går godt.
• Nogen gange kan det være nødvendigt med flere storyboards.

Designprincipper

Der findes godt og dårligt design (og en hel masse derimellem). Blandt andet derfor er det nødvendigt at have et fagsprog, der beskriver design. En anden grund er, at når vi designer, så kan det være praktisk med nogle principper, der fortæller os, hvad vi skal være opmærksomme på.

Der findes mange principper, men nogle af de mest berømte er Donald Normans principper. Principperne stammer fra en berømt bog The Design of Everyday Things. Som titlen indikerer handler det om design af ting. Derfor er principperne særligt anvendelige i forbindelse med fysiske prototyper, som jo netop er ting.

Principperne er

1. Visibility
2. Feedback
3. Constraints
4. Consistency
5. Mapping
6. Affordance

Den kvikke læser opdager hurtigt, at det alt sammen er engelske ord. Men det er desværre standard inden for designbranchen.

I de næste afsnit vil hvert princip blive beskrevet. Afsnittene vil være opbygget på samme måde. Først defineres princippet, og så gives der et dårligt og et godt eksempel på princippet (der kan i eksemplerne også være andre principper i spil). Af principperne er affordance nok det vigtigeste.

Visibility

Visibilityprincippet defineres til at være:

Med andre ord, kan vi se, hvad tingen gør nu eller kan nu? Kan vi se, hvad tingen vil have os til?

Et eksempel på dårlig visibility

I virkeligheden ville der være tale om dårlig visibility, hvis skiltet, om at døren er i stykker, ikke var der. Men det viser jo netop, at vi ikke kan se på en dør, og afgøre om den er i stykker. Typisk ville vi heller ikke kunne se, om en dør er låst. Så generelt er døre noget med begrænset visibility.

Et eksempel på god visibility

Gammeldags knapper i biler, der også har små lys, der viser, om de er trykket ind, har høj visibility. Her kan man umiddelbart ses status, og det er umiddelbart let at se, hvad der er af muligheder.

Feedback

Med andre ord, om vi kan afgøre, hvad der sker nu, og om den handling, vi har udført, faktisk er sket.

Et eksempel på dårlig feedback

Denne knap har faktisk feedback: Den fortæller, at den er blevet trykket ind - det kan vi mærke. Men det er knap, der springer ud igen, så feedback kommer for tidligt og forvirrer. Derfor har nogen sat et dymo-label på knappen.

Et eksempel på god feedback

Igen er knapper gode til at fortælle os, at vi har trykket på dem. Vi kan simpelthen mærke, at vi har haft succes med at trykke på en knap. Vi behøver ikke at se efter.

Constraints

Et eksempel på dårlig constraints

Billedet viser betjeningspanelet til en projektor. Der er præcis et kabel, der kan anvendes til at koble en computer til projektoren. Og der er præcis en knap, der sørger for at forbinde computer med projektor. Kan du gætte hvilken? PC1 og PC2 ville man umiddelbart prøve, og hvis ikke det er en af dem, så vil man nok prøve DVD. Så her har vi 2-3 knapper, der alle er kandidater til at være den rigtige. Men der er kun brug for en knap! (hvis du vil se hvilken knap, der er den rigtige, så se afsnittet om mapping )

Et eksempel på god constraints

En dørklokke skal kunne én ting, og har derfor én knap. Her er brugeren blevet godt begrænset!

Consistency

Et eksempel på dårlig consistency

I afsnittet om prototyper havde vi et eksempel på en fysisk prototype, der skulle få folk til at gå i et bestemt tempo. Ved afprøvning viste det sig, at de tre ikoner (pil frem, vandret streg, pil tilbage) ikke havde den ønskede effekt. I stedet for at blive opfattet som at skulle gå hurtigere (billede 2), holde hastigheder (billede 3) eller gå langsommere (billede 4), så blev de opfattet sådan, at hvis pilen pegede frem, så skulle man gå frem. Hvis blive pegede tilbage, så skulle man baglæns, og hvis der var en vandret streg, så skulle man stoppe. Med andre ord, så var de tre ikoner ikke konsistente med, hvordan de normalt bliver opfattet. Og brugerne kunne derfor ikke overfører deres viden fra tidligere til denne ting.

Et eksempel på god consistency

Denne bog har følgende tre ikoner øverst til venstre (lige efter oversigten). Det første ikon kaldes en "burgermenu" (eller "hamburgermenu"), og vi ved, at det en menu, der giver adgang til noget mere. Luppen ved vi også betyder, at vi kan søge. Penslen, kan vi gætte på, har noget med farver at gøre. Dermed kan vi netop overføre viden fra tidligere brug af hjemmesider til denne hjemmeside.

Mapping

Et eksempel på dårlig mapping

Dette er knapperne til at betjene en projektor. Der er præcis ét kabel, man kan sætte sin computer for at anvende projektoren. Men det "mute"-knappen, der skal trykkes på for at få forbundet computer og projektor! Hvilket nok er den sidste knap nogen ville trykke på.

Et eksempel på god mapping

Den store knap på denne brødrister har en fantastisk mapping. Når den trykkes ned, så kommer brødet også ned i brødristeren. Og når den kommer op, så kommer brødet også op.

Affordance

Et eksempel på dårlig affordance

Den dør har fået et brugsvejledning påklistret. Noget sådan er en indikation af, at døren ikke giver nogle vink til, hvordan den skal åbnes. Mange vil nok bare prøve at hive i døren.

Et eksempel på god affordance

Dørklokker har god affordance. Der er en ting man kan, og den ene ting er tydelig med en knap.

Programmer og computere

Moderne mennesker omgiver sig med computere. Ikke kun dem vi kan se, for eksempel bærbare, men også i utroligt meget udstyr som umiddelbart ikke forbindes med computere.

En computer består typisk af en samling microchips, der ligger på et printkort. Det er det vi kalder hardware. For at få en computer til at gøre noget bestemt, er der nødt til at være nogle instruktioner til computeren om, hvad den skal gøre det er det vi kalder software. Software skal skrives, hvilket vi kalder at programmere.

I en designsammenhæng er udfordringen, at computere og mennesker er meget forskellige. Vi har noget, vi som mennesker er gode til, og computere har noget de er gode til. Vi kan forsøge at stille det op i en tabel.

Listen kan gøres længere, men burde illustrere, hvad udfordringen med at skrive computerprogrammer, der skal bruges af mennesker er. Vi vil i de næste to afsnit give nogle værktøjer til at modellere computere. Nemlig tilstandsdiagrammer og rutediagrammer. Men først et eksempel som vi vil analysere.

Et eksempel

Da denne lille bog handler om fysiske prototyper giver vi nu et eksempel på et fysisk system.

Billedet viser en vandautomat. Øverst er der to knapper. Knappen til venstre med et snefnugikon får vandautomaten til udlevere koldt vand. Den anden knap får automaten til at levere almindelig vand lige som en vandhane. For begge knapper gælder det, at de skal holdes inde sålænge vandet skal flyde. Lige så snart man slipper knappen, så stopper vandet (dog med en smule forsinkelse).

Vi forestiller os, at en lille computer åbner og lukker for vandet, når en af knapperne bliver trykket. Vi vil gerne oversætte det til noget, der nærmer sig det computeren skal gøre. Det første trin er et tilstandsdiagram.

Tilstandsdiagrammer

Tilstandsdiagrammer er en måde at grafisk repræsentere det en computer gør eller viser os brugere. I eksemplet med vandautomaten kan vi identificere tre ting automaten gør. Den første er, at den ingenting gør -- den venter bare. Hvis man trykker på knappen til koldt vand, så sker der noget, nemlig at der kommer koldt vand ud af automaten. Her er tilstanden nu, at der kommer koldt vand ud. Hvis vi trykker på den anden knap, så kommer der almindelig vand ud. Så den sidste tilstand er, at automaten at der kommer almindelig vand ud.

Så vi har tre tilstande

1. Venter på tryk på en knap
2. Sender koldt vand ud
3. Sender almindelig vand ud

Det interessante er så, hvordan vi kommer fra en tilstand til en anden. Svaret er at vi enten trykker på en knap (og holder den nede), eller vi slipper knappen.

Vi kan indfange det ovenstående i et tilstandsdiagram. Et (simpelt) tilstandsdiagram består af to grafiske elementer

1. Cirkler angiver tilstande og inde i cirklen skriver man, hvilken tilstand systemet er i.
2. Pile angiver skift i tilstande. Pilen viser hvilken tilstand, der startes i, og hvilken tilstand der sluttes i. Pilene udstyres med en tekst, der fortæller, hvad der får tilstanden til at skrifte.
3. Vi skal også angive, hvor systemet starter.

Et tilstandsdiagram for vandautomaten ses her.

Tilstandsdiagrammet giver os et overblik over, hvad systemet gør, og hvordan ændringer sker i systemet. Men vi er stadig på et overordnet niveau, vi skal tættere på computeren. Til det formål har vi rutediagrammer.

Rutediagrammer

Vandautomaten er rimelig simpel, hvis der bliver trykker på en knap skal der komme vand ud og hvis knappen slippes, skal vandet stoppes. En måde, at beskrive hvad en computer gør er ved et rutediagram. Et (simpelt) rutediagram består af to symboler en rektangel og en diamant. Disse figurer forbindes med pile. Et rektangel bliver kaldt en proces og en diamant blive kaldt en forgrening. Figurerne kan ses her under.

Proces: En proces angives med et rektangel. Der er præcis én pil fra rektangelen sat i dens bund. En proces beskriver en handling programmet skal gøre.	Forgrening: En forgrening angives med en diamant. Der er præcis to pile fra diamanten. En der peger ned og en der peger til højre. Forgreninger beskriver et valg programmet skal tage.

Så en proces er én handling, også videre til den næste ting. Handlingen skrives inde i rektanglet. En forgrening angiver et valg. Man skriver et ja/nej spørgsmål inde i diamanten, og man skriver ja eller nej ved den tilsvarende pil væk fra diamanten. Der må kun spørges om en simpel ting.

Vi viser nu et rutediagram for vandautomaten. Vi begynder med det symbol, der er øverst til venstre, og så følger vi pilene rundt.

Vi kan indfange de tre tilstand ved at se på, hvad programmet gør.

1. Der ventes. Det vil sige, at der ikke er trykket på nogen knapper. Hvis vi begynder øverst til venstre, vil vi støde på spørgsmålet "Trykket på koldt vand?". Det kan vi svare nej til, og følger pilen videre, så når vi til spørgsmålet "Trykket på alm. vand?", hvilket vi også siger nej til. Hvis følger nej-pilen ender vi tilbage til start.
2. Der er en der trykker på knappen til koldt vand. Hvis vi begynder øverst til venstre, vil vi støde på spørgsmålet "Trykket på koldt vand?". Det svarer vi ja til og følger pilen ned. Nu kommer vi til processen "Åben for koldt vand", som bliver udført og vi kommer til en ny forgrening: "Trykket på koldt vand?". Hvis der stadig bliver trykket på knappen til koldt vand, så kommer processen "Hold åben" og vi kommer tilbage til forgreningen. Det vil vi gøre indtil knappen slippes. Hvorefter vi følger nej-pilen, udfører processen "Luk for vandet" og følger pilen tilbage til start.
3. Der er en der trykker på knappen til almindelig vand. Lige som til koldt vand, bortset fra, at det er alm. vand, der åbnes for.

Fra tilstandsdiagram til rutediagram

For at komme fra tilstandsdiagrammet for vandautomaten har vi set på hvilke tilstande, der er, og hvordan der skiftes imellem dem. Således er et skift i tilstand givet ved en forgrening, hvor der undersøges om betingelsen for skift af tilstand er tilstede, og hvis ja så skiftes der tilstand. Tilstandene er så kode, der udføres givet en bestemt tilstand. For eksempel at åbne for koldt vand, når vi er den tilstand. Denne oversættelse kan selvfølgelig vendes om.

Det vil sige, at vi generelt har:

1. Skifte mellem tilstande oversættes til forgreninger.
2. En tilstand beskrives med processer og forgreninger, der passer til netop en tilstand.

Vi er nu klar til at skabe noget kode.

Introduktion til micro:bit

Vi vil nu vende os mod micro:bit, og hvordan de programmeres. Dette er ikke tænkt til at være en fuldstændig udtømmende guide til alt, hvad en micro:bit kan, men derimod en kort gennemgang af de vigtigste elementer. Selve micro:bit-enheden kan man læse om her. Der er mange egenskaber, og alt for mange til at det giver mening at beskrive dem her.

Vi vil benytte makecode som platform for vores programmer. Når man kommer ind på makecode er det første man skal gøre at logge på.

Man skal vælge, hvad man vil logge på med. Google er et godt bud. Man kan også bede om at blive husket.

Fordelen ved at logge på er ens projekter bliver gemt. Og de kan findes igen. Man også begynde et nyt projekt.

Hvis vi vælger et nyt projekt, kan vi også give det et navn. Her er det vigtigt, at vi kalder projektet noget meningsfuldt, så vi kan finde det igen senere.

Når vi kommer ind på vores projekt bliver vi præsenteret for følgende.

Øverst til venstre har en virtuel micro:bit, der kan anvendes til at afprøve vores kode. I midten har vi en menu med de blokke, vi kan anvende til at programmere med. De kan placeres til højre, hvor der er to kodeblokke, alle micro:bit-programmer er født med. Nederst har vi en stor blå knap, hvor der står "hent". Den kan vi trykke på for at overføre vores program til en micro:bit-enhed. Vi har som det sidste også mulig for at gemme vores projekt.

Løkker og forgreninger

Micro:bit har en løkke, der kører indtil micro:bitten bliver slukket. Blokken ser således ud:

Alt hvad der inden for denne blok vil blive kørt igen og igen, indtil der ikke er mere strøm. Vi kan få dioder på en micro:bit til at blinke ved først at vise noget, så ryde "skærmen" også vente.

Kodedelene til dette findes alle under "Grundlæggende" (eng: basic). Dette er ikke særligt interessant, men det viser hvordan "for altid"-løkken virker.

Vandautomaten

Vi vil nu prøve at programmere vandautomaten. Dog vil selve det at åbne og lukke for vandet være noget som vi ikke har mulighed for. Så i stedet vil vi vise med micro:bittens dioder, at der er tændt for koldt eller almindeligt vand.

En micro:bit har to knapper A og B, som vi vil anvende. Knap A vil være koldt vand, og knap B vil være almindelig vand. Vi skal så omforme rutediagrammet for vandautomaten til kode.

Vi begynder med en uendelig løkke.

Det første vi skal have er en forgrening. De ligger under logik. Der er to slags. vi benytter nummer to.

Den indsætter vi i vores "for altid" løkke. Forgreningen kan forkortes og forlænges ved at anvende plus og minus på blokken.

Vi trykker en gang på plus og en gang på minus, så det kommer til at se sådan ud.

Vi har nu samlet de to øverst forgreninger i vores rutediagram, men vi mangler at spørge om knapperne er trykket. Det kan vi finde under input.

Det sætter vi på de to pladser i vores forgrening. I den hvor der står "ellers hvis" retter vi A til B.

Så skal der sættes kode ind under hver gren. Vi skal have have vandet til åbne og lukke. Vi vælger to ikoner til varmt vand og koldt vand og når vandet skal slukkes, så rydder vi dioderne.

Dog er dette ikke godt nok. Programmet vil hele tiden tænde og slukke for vandet og det dur ikke vi må gøre noget andet. I rutediagrammet havde vi også en to forgreninger, der undersøgte om knappen var trykket ned og derfor holdte vandet åbent eller lukkede for vandet.

Denne type forgrening, der hele tiden vender tilbage til sig selv er et eksempel på en løkke. De finder under løkker. Vi skal have fat i den der hedder "mens ... udfør"

Men hvad skal, der så ske i løkken. Svaret er der skal ske ingenting. For der er åbnet for vandet og det giver ikke mening at åbne igen. Så vi indsætter de to løkker i vores kode, og tilføjer de to tjek af knapperne A og B henholdsvis.

Dette færdiggør vores program til vandautomaten.

Sensorer og variable

En micro:bit har mange sensorer, der kan måle for eksempel acceleration, temperatur, lysniveau, lydniveau og en del andet.

De fleste sensorer kan vi få adgang til under input. Vi vil interesserer os for lydniveauet. Det kræver en micro:bit version 2. Hvis man ikke en sådan så kan meget af koden laves med lysniveau i stedet.

Lydniveau findes under input helt i bunden.

Hvis vi sætter denne blok ind i vores kode, vil vi se, at det ikke går godt. Det skyldes, at lydniveau er en talværdi, og vi er nødt til aflæse den og gemme den i en beholder. En sådan beholder kaldes en variabel. Variable laves under menupunktet med samme navn. Vi vælger opret.

Vi vælger navnet lyd, så ved vi, hvad variablen indeholde.

Når vi oprettet vores variabel "lyd", så kan vi sætte den til værdien af lydniveauet.

Så nu har vi en variabel -- "lyd" -- der indeholder lydniveauet og som bliver opdateret, hver gang løkken begynder forfra. Men vi ved ikke, hvad lydniveauet er.

Det første, vi kan spørge os selv om, er, hvilke værdier, vi kan få ud af lydniveau. Ved at holde musen over lydniveau i menuen, kommer følgende frem.

Så vi får en værdi mellem 0 og 255 (svarende til en byte). Men hvor meget larmes der? Vi kan få micro:bitten til at sende data tilbage til vores computer, og så kan vi få en graf og data, der viser lydniveauet.

Vi skal ned under Avanceret og Seriel. Der findes blokken vi skal anvende.

Vi bruger næsten altid "Serie skriv værdi", fordi den tillader, at vi giver målingen et navn. Det er især praktisk, når vi har flere sensorer i gang. Vores kode ser nu således ud:

Vi kan så se grafer for lydniveauet ved at se efter "show data ..." Enten kan man simulere data, eller hvis man har en micro:bit tilkoblet se de rigtige målinger.

Målingerne kan gemmes som csv-fil.

Kort om computere

For at kunne skrive fornuftige computerprogrammer, er man nødt til at vide noget om, hvordan en computer fungerer. Dog er et et forholdsvis stort emne, hvor der er mange detaljer. Vi giver derfor et meget overordnet overblik.

Opbygning af en micro:bit

Vi har set, at en micro:bit har nogle knapper og nogle sensorer. Hvilket ikke er hele historien. Alle computere har det der kaldes en CPU (central processing unit). Det er den chip, der sørger for at programmer bliver udført. En CPU er snotdum. Den udfører instruktioner en efter en uden at forholde sig til indholdet af instruktionerne. Den er heller ikke i stand til at huske (i hvert fald ikke særligt meget). Så derfor er der også noget hukommelse, kaldet RAM (random access memory), på en micro:bit, som anvendes til at opbevare programmer og de variable programmerne opretter.

Diagrammet oven for viser de fire overordnede bestand dele af en micro:bit.

1. CPU, som den enheden, der udfører programmet.
2. RAM, som er hukommelse, hvor program og programmet variable ligger.
3. Sensorer, som anvendes til at aflæse fx temperatur.
4. Knapper som vi anvender til at give vores program beskeder.

Der er også tre pile. De viser vejen for den første kommunikation mellem delene. Det skal forståes således, hvis fx der skal anvendes RAM/hukommelse, så skal CPU'en først henvende sig til hukommelsen, for at få gemt eller hentet noget fra hukommelsen. Det er aldrig hukommelsen der indleder kommunikation med CPU'en.

Variable og hukommelse

En variabel et navn for et område af hukommelsen. Vi anvender variable, når vi ønsker at gemme en oplysning til senere brug. Så når vi "sætter" en variabel i vores kode. Så fortæller vi CPU'en: "Fortæl RAM/hukommelsen, at den skal opbevare følgende, som jeg kalder ...". Når vi bruger en variabel i vores kode i fx en forgrening (hvis-blok), så fortæller vi CPU'en: "hent den ting jeg har kaldt ... og sammenlign den med ...".

Det væsentlige er, at variablens navn henviser til hukommelsen, så det eneste vi skal vide, når vi skriver kode er navnet.

En detalje er variable kan have forskellige typer. Der er fire overordnede typer, der findes i alle programmeringssprog.

• Boolske variable: Variable, der kun kan indholde værdierne sand og falsk.
• Heltalsvariable: Variable, der kun kan indholde hele tal fx 1,2, eller 3...
• Decimaltalsvariable: Variable, der kun kan indeholde kommatal fx 1,3434
• Tekstvariable: Variable, der kun indeholder tekst fx "Tallet pi er lig med 3,14"

Sensorer

Ligesom med hukommelsen, skal CPU'en først spørge en sensor om værdier, før den får noget tilbage. Dermed er ikke sådan, at sensorerne sender noget til CPU'en uden først at være blevet spurgt.

Det forklarer, hvorfor de blokke, der har med sensorers værdier at gøre, ofte optræder som variable. Det betyder også, at den normale arbejdsgang i et program er at aflæse en værdi fra en sensor, og placere den i en variabel. Derefter kan variablen, så undersøges med fx forgreninger.

Den sidste pil på diagrammet går fra diagrammet til CPU'en. Det vil sige, det omvendte af de to andre pile det kræver en forklaring, som bliver givet i næste afsnit.

Knapper og begivenheder

I det foregående afsnit. Så vi på hvordan en micro:bit er opbygget med CPU, sensorer, og hukommelse. Men vi mangler at behandle knapper. Hvad sker der, når der trykkes på en knap? Der er to muligheder.

1. CPU'en "spørger" knappen om den er trykket ned. Denne mulighed er måske meget fin, hvis der én knap, men er et problem, hvis der er ca. 100 knapper, som et computer keyboard godt kan have (hvis vi regner shift/alt/ctrl-kombinationer som separate knapper).
2. Når knappen bliver trykket på, så fortæller knappen CPU'en, at den er blevet trykket. CPU'en kan så afbryde det den har gang i og gøre noget, hvis programmet har fortalt CPU'en hvad den skal gøre.

Det er løsning 2 computere anvender.

Eventhandler

Når der trykkes på en knap, så sender knappen en besked til CPU'en (eng: Interrupt). CPU'en ser så om programmet har "registeret" en noget kode, der skal udføres, hvis knappen er blevet trykket.

Denne kode kaldes en "eventhandler" og er kendetegnet ved, at det er kode, der kun gøres, når en begivenhed sker.

I makecode er der eventhandlers for tryk på knapper, modtagelse af radiosignaler og nogle få andre begivenheder. En eventhandler ser sådan ud som en blok:

Her vælges den begivenhed, der skal håndteres og inde i blokken kan der skrives den kode, der skal udføres. Bemærk, at der ikke er tale om en løkke.

Radio

Den sidste egenskab ved micro:bit vi vil præsentere i denne bog er radiokommunikation mellem to (eller flere) micro:bit. Vi vil tage vores lydmåler fra sidste afsnit og lave den om, så der er en måler, der sender lydniveauet til en modtager. På den måde kan man måle lydniveauet på afstand.

For at kunne bruge radio skal man have mindst to micro:bit. Vi skal skrive kode til begge micro:bit. Noget af koden er ens. Men noget af koden er forskellig. Der er en sender og en modtager i dette eksempel. Senderen sender konstant lydniveauet til modtageren, som sender det videre til computeren.

Sender

Det første man skal gøre at bestemme hvilken kanal micro:bittene skal sende på. Det henter man i radiomenuen og indsætter i "når programmet starter"

Når man har valgt et tal i gruppen, så kan vi sende lydniveauerne.

Det er hele programmet for senderen.

Modtager

Modtageren skal også indstilles til den samme gruppe som senderen. Når det er sket, så er den nødt til at vente på, at den modtager data. Til formål anvender man en anden type blok (en eventhandler).

Her kan man så læse tallet, der er modtaget, og sende det videre til computeren.

Funktioner

Alle programmeringssprog har en konstruktion, der kaldes funktioner.

Denne definition lyder måske mærkelig, men man vil uværgelig komme anvende funktioner, når man skriver kode. For langt de fleste programmeringssprog har indbyggede funktioner. Et eksempel fra makecode kunne være:

Her beder vi om at, der vises et tal på micro:bittens dioder. Men der er faktisk sket en hel del andet som vi ikke kan se. Først skal alle dioder slukkes, så skal tallet oversættes til, at nogle bestemte dioder er tændte, så skal de dioder tændes. Så i virkeligheden sker der en hel masse andet omme bagved foregår et andet sted.

Funktioner bruges ofte til at genbruge kode, så når vi en gang har fundet ud af, hvordan vi viser tal på dioderne, så skal vi ikke gøre det igen.

Funktioner vi selv skaber

Der nogle tilfælde, hvor det giver mening at selv skabe funktioner.

1. Når vi har nogle blokke som vi bruger flere steder. Og hvor vi hele tiden skal rette koden flere steder.
2. Når vores kode er meget uoverskuelig. Fx hvis vores "for altid" løkke er meget lang.

Vi kan oprette en funktion, ved at gå ned i avanceret og vælge funktioner.

Det bringer os videre til en menu, hvor der er nogle muligheder. Blandt andet, at navngive ens funktion. Som altid giver det mening, at vælge et meningsfuldt navn.

Når funktionen er oprettet kan den trækkes ud og fyldes med blokke.

Der er kan kun være én funktionsblok med et bestemt navn.

For at anvende en funktion skal den kaldes. Det gøres ved at trække en blok ud, der hvor funktionen skal kaldes fra.

Det kræver lidt tilvænning at anvende funktioner, men det er et kraftfuldt værktøj til at undgå gentagelser og genbruge kode.

Fagbegreber

Vi vil her forklare nogle fagbegreber i forbindelse med programmering.

Sekvens

Ordet sekvens dækker over flere kodelinjer, hvor der sker handlinger. For eksempel

De tre linjer inden i for-altid-løkken er en sekvens.

Forgrening

En forgrening er et sted i koden, hvor der skal træffes et valg. En forgrening har en eller flere betingelser, der skal have værdien sand eller falsk. Der er (som regel) to grene. En hvor betingelsen er opfyldt, og en hvor betingelsen ikke er opfyldt. Et eksempel er inde i for-altid-løkken:

Her er der to grene og gren nummer to bliver kun kørt hvis dens betingelse er sand, og den første betingelse til den første gren er falsk.

Forgreninger anvendes til at skifte mellem tilstande. Og de har følgende symbol i et rutediagram

Løkke

En løkke er en konstruktion, der får noget kode til at gentage sig selv. Der findes over ordnet to slags. Den første er en løkke, der bare kører til uendelig tid

Den anden er der den løkke, der afhænger af en betingelse.

Løkker er nemme at få øje på i rutediagrammer. Idet de laver en tja... en løkke.

Variabel

En variabel er et navn for noget data, som ligger i hukommelsen. Variable kan have forskellige typer.

1. Boolske udsagn: Har værdierne sandt/falsk.
2. Heltal.
3. Decimaltal.
4. Tekst.

Før variable kan anvendes skal de have en værdi. Et eksempel hvor en variabel får en værdi er:

Variable kan fx anvendes i forgreninger.

Introduktion

I dette kapitel vil vi se på en teknik, der knytter ideen om en prototype til den kode, der skal få prototypen til at gøre det, vi gerne vil have den til. Metoden vi vil beskrive kaldes "storycoding". Den har til formål at tage den idé, vi har om en prototype igennem fire trin. Så vi ender med en fysisk prototype, der kan anvendes til for eksempel brugertest.

De fire trin er.

1. Lav et storyboard, der beskriver den interaktion prototypen optræder i.
2. Ud fra storyboardet, lav et tilstandsdiagram.
3. Ud fra tilstandsdiagrammet, lav et rutediagram.
4. Ud fra tilstands- og rutediagram. Skriv kode.

Nu ligner det meget en kageopskrift, men i den virkelige verden, vil man bevæge sig op og ned i rækkefølgen. Det kan være, at når tilstandsdiagrammet bliver lavet, så opdager man, at der mangler noget i storyboardet, og så må man gå tilbage. Det kan være, at når man skriver koden, at man opdager, at der mangler en tilstand eller en forgrening. Og så må man tilbage og rette til i tilstands- eller rutediagram.

På samme måde kan det være nødvendigt at gentage de fire trin i storycoding, flere gange, når man opdager, at brugeren ønsker sig flere egenskaber eller andre egenskaber til ens prototype.

Det kan være meget fint at have en metode til at omsætte ideer til kode, hvis man ingen ideer har! Derfor vender vi os kort mod, hvordan vi kan generere nogle ideer.

Idégenerering

For at kunne komme på ideer forudsættes der et element af kreativitet. Og her er det vigtig at sige, at man ikke kan være kreativ på kommando. Ligesom man ikke kan hygge sig på kommando. En beskrivelse, af hvad der skal til for at være kreativ, kan findes her i en noget gammel udgave (og med et utal af "hvor mange ... skal der til for at skifte en pære?" vittigheder). Den gode nyhed er, at kreativitet ikke er et medfødt talent, men noget vi alle kan.

Lad os antage, at vi er i en situation, hvor vi er i stand til at være kreative. Hvordan får vi skabt nogle ideer? Ofte vil man ty til en brainstorm. Dog har fysiske prototyper, som vi behandler her, det indbygget i sig, at der er nogen, der gør noget med et eller flere objekter. Så et alternativ til brainstormen er bodystorming.

Bodystorming

Udgangspunktet er, at vi har en problemstilling, vi ønsker at udforske. Bodystorming kan minde om improviseret teater, uden dog helt at være det. Tanken er, at deltagerne spiller rollerne af personer, computere og andet, der optræder i den problemstilling, der er fokus. Efter hver gennemspilning diskuterer deltagerne, hvad der gik godt, og hvad der kunne ændres?

Hvis vi nu undersøger problemstillingen om, hvordan vi husker at låse døren? Så kan vi eventuelt begynde med at udspille en almindelig situation, hvorefter vi forholder os til, hvad der kan gå galt? En får måske en idé om en alarm. Vi kan så spille situationen, hvor der er en alarm, der hyler, hvis man glemmer at låse døren efter sig. Så en person er alarmen, og en er den der skal låse op og i. Så kan det være, at vi blive enige om, at det er irriterende med en alarm... kan døren ikke bare låse sig selv? Så udspilles det som situation.

Nu er der en, der får den idé, at det kunne være rart, at døren opfører sig ligesom en bildør, hvor man "bare" trykker på en knap. Så udspilles denne idé. Der er en, der kommer til at tænke på, at man nogen gange har brug for at komme meget ind og ud, med for eksempel indkøb eller andet. Det giver anledning til en ekstra alternativ måde at åbne døren på.

Det ovenstående er et tænkt eksempel. Men ofte skal der flere forsøg til, før vi ender med noget brugbart.

Der nogle råd i forbindelse med bodystorming.

• Sig ikke nej, det ødelægger udførelsen.
• Hvis du får en god idé undervejs, så gem den og prøv at gennemspille den bagefter.
• Vær opmærksom på om noget føles godt eller dumt. Det kan være en indikation af, at noget virker eller ikke virker. Men sig det først efter situationen er gennemspillet
• Det kan også senere være nødvendigt med en nye gennemspilninger af situationer.

Et eksempel

Vi vil nu vise et eksempel på en anvendelse af storycoding. Udgangspunktet er det, som det tidligere afsnit om idégenerering sluttede med, nemlig et nyt låsesystem til døre. Systemet virker ligesom til biler, hvor der trykkes på en knap på en nøgle, og døren låser op. Her er det også sådan, at døren selv låser efter noget tid. Derudover er der en ekstra funktion, hvor døren bliver ved med at være oplåst, indtil vi låser den igen. Det kan bruges, hvis vi mange gange skal ind og ud af døren inden for kort tid.

Vi går nu igennem trinene.

1. Lav et storyboard, der beskriver den interaktion prototypen optræder i.
2. Ud fra storyboardet, lav et tilstandsdiagram.
3. Ud fra tilstandsdiagrammet, lav et rutediagram.
4. Ud fra tilstands- og rutediagram. Skriv kode.

Vi begynder med et storyboard.

Storyboard

Vi har nu en situation omhandlende døre. Et storyboard på baggrund af situationen kan se sådan ud:

I billede 1 er vi på vej hen til døren, og trykker på vores nøgle for at få døren til at låse op. Der er to muligheder 2 og 2A (A for alternativ). I situation 2 låser døren op, og den er låst op i 6 sekunder (se billede 4). I Situation 2A, har låst op så døren forbliver oplåst. I billede 3 går vi ind ad døren. I billede 4 er der gået 6 sekunder, og døren låser. I billede 4A går vi fra døren, men husker at låse den.

På denne måde har vi indfanget situationen. Vi kan nu lave et tilstandsdiagram. Der er to ting som umiddelbart kan ses ud af storyboardet, nemlig at vi skal anvende to enheder, en som nøgle og en som lås. Og de skal kunne kommunikere over radio.

Vi vil derfor bruge ordet "nøgle", om den micro:bit brugeren har i hånden og ordet "lås" om den micro:bit, der spiller rollen som lås.

Tilstandsdiagram

På baggrund af vores storyboard kan vi nu lave et tilstandsdiagram. Men først bemærker vi, at det ikke er nøglen, der skal laves et tilstandsdiagram for. Den sender "bare" tre beskeder: Lås op i 6 sekunder, lås op på ubestemt tid, og lås døren.

Derfor ser vi på låsen. Umiddelbart er der to situationer, enten åbnes døren i 6 sekunder, eller også er den bare åben (billede 2 og 2A). Derfra er der forskellige veje.

Et tilstandsdiagram, hvor tallene i tilstandene er henviser til billederne i storyboardet, kan se sådan ud:

Vi forestiller os, prototypen skal laves med micro:bit, så der er også angivet hvilke tryk på micro:bitten, der giver hvilket resultat. Det giver os 4 tilstande.

1. En grundtilstand, hvor døren er låst. (tilstand 1)
2. En tilstand, hvor døren er åben i 6 sekunder. (tilstand 2,3)
3. En tilstand, hvor døren er åben indtil den bliver låst. (tilstand 2A,3)
4. En tilstand, hvor døren låser. (tilstand 4,4A)

Disse fire numre (1-4) fra punktopstillingen vil vi anvende i koden og i rutediagrammerne.

Rutediagram

Vi kan nu lave et rutediagram for låsen. Udgangspunktet er, at vi har en enkelt variabel, der kaldes "pstate" (program state). Den sættes til 1, når programmet begynder. Dermed vil et overordnet rutediagram for den uendelige løkke se sådan ud:

Her er processerne under hver forgrening en funktion, der udfører det som skal ske i hver tilstand.

Vi mangler dog at forklare, hvordan vi kan skifte tilstand. Det afhænger faktisk af, hvad vi får tilsendt fra nøglen. Vi forestiller os, at den kan sende "A", hvis døren skal være åben i 6 sekunder, og der skiftes til tilstand 2. Den kan sende "B", hvis det er åben for altid og der skiftes til tilstand 3. Og den kan sende "AB", hvis døren skal låses, og der skiftes til tilstand 4. Dermed er skal der også at være et rutediagram for modtagelsen af beskeder fra radioen. Det ser sådan ud:

Vi skal så huske, at funktionerne "åben i 6 sekunder" og "luk" skal skifte til tilstand 1.

Kode

Vi kan nu skrive noget kode. Fordi det er en prototype, vil vi ignorere den faktiske "lås og lås op" mekanisme, og i stedet anvende micro:bittens lyd til at vise om døren er låst eller ej. På samme måde vil vi ignorere alle mulige problemer med sikkerhed i vores setup. Vi er ude på at teste om en interaktion, som ikke er i nærheden af et endeligt produkt.

Da nøglen er den letteste at programmere, så begynder vi med den.

Nøglen

Nøglen skal sætte en radiogruppe, som svarer til den låsen har. I dette eksempel vælger vi gruppen 17.

Når dette er gjort, så skal vi "bare" sende "A", "B" eller "AB" alt efter om, der er trykket på knap A, knap B eller begge knapper. Vi viser koden for alle tilfælde:

Vi har nu koden for nøglen. Nu mangler vi låsen.

Låsen

Vi begynder med at sætte radiogruppen og variablen "pstate" (program state) til 1 (låst), når programmet starter.

Når det er gjort, giver det mening, at se på modtagelsen af beskeder fra nøglen, da det er her tilstandene bliver ændret af brugeren. Vores rutedigram ser således ud:

Det sættes ind i en "når radio modtog..." blok.

Nu kan vi ændre tilstand alt efter, hvad brugeren har trykket på nøglen.

Nu mangler vi bare, at der sker noget. Vi har et rutediagram for den uendelige løkke, der er hoveddelen af vores program.

De tre processer "åben i 6 sekunder", "åben" og "luk". Vil vi lave som funktioner. Det vil sige, at vi finder på nogle navne, der henviser til noget kode et andet sted. På den måde bliver den uendelige løkke ikke overproppet med kode, og vi kan lettere se, hvad vi skal gøre.

Vi opretter funktionerne "åben6", "åben" og "luk". Navnene burde være selvforklarende. Funktionerne kan så kaldes fra den uendelige løkke.

Bemærk, at vi sætter "pstate" til 1, hvis ingen af de andre tilstande bliver valgt, på den måde er vi nogenlunde sikker på altid at være i en gyldig tilstand.

Nu kan vi lave de enkelte funktioner. Vi begynder med tilstanden, hvor døren er åben i 6 sekunder. Her skal der lyde et bip, vi skal vente i 6 sekunder, og så skifte til tilstand 4, hvor der lukkes. Det ser sådan ud:

Eftersom koden går videre til tilstand 4, så tager vi den tilstand nu. Her skal der bippes to gange og skiftes til tilstand 1 (låst). Måden vi får micro:bitten til at bippe to gange, er ved at lave en lille løkke, hvor der kommer et bip og så en pause. Og det gør vi så to gange. Til sidst sætter vi "pstate" til 1 for at vende tilbage til tilstand 1 (låst).

Nu mangler vi "bare" den sidste tilstand (3), hvor døren er åben. Vi skal bippe tre gange, også skal der bare ventes på, at der bliver låst. Vi laver tre bip, på samme måde som 2 bip, men med én ekstra gentagelse.

Hurra vi har begået en fejl!

Hvis man forsøger at bruge den kode vi har lavet. Så vil man støde ind i et problem. Nemlig, at hvis man trykker åben på nøglen, så bliver låsen ved med at bippe indtil, man låser igen. Det var ikke helt det, det skulle ske. Vi skal kun bippe 3 gange. Problemet er, at vi har overset en tilstand. Nemlig, at bippe tre gange og vente ikke er det samme. Så vi er nødt til at lave en ventetilstand. Vi har brugt tallene 1, 2, 3, og 4, så den nye tilstand bliver nr. 5. Vi ændrer åbnefunktionen, så den skifter til tilstand 5 og vi ændrer den uendelige løkke til at have en tilstand 5, hvor der ikke sker noget.

Åbenfunktionen vil så se sådan ud:

Og den uendelige løkke vil se sådan ud:

Dette afslutter eksemplet på anvendelse af storycoding.

Afslutning

I denne lille bog har vi gennemgået en del af det at arbejde med fysiske prototyper. Særligt har vi præsenteret metoden storycoding. Formålet med denne metode er at få virkeliggjort, de ideer man har i en fysisk prototype. Metoder er dog aldrig perfekte, for eksempel, så "glemte" vi en tilstand, da vi lavede vores nøgle. Dette peger om ikke andet på, at metoden storycoding kan anvendes, men at test er nødvendige.

Når nu vi har en fysisk prototype, så er vi ikke færdige. Det er nu, at brugertest kommer i spil. Så prototypen må afprøves og tilrettes efter det feedback vi får. Faktisk er designprocessen kun lige begyndt, og der vil være meget arbejde, der skal laves, før der er et endeligt produkt -- hvis man overhovedet når så langt.