For jeg bruger i stigende grad Github Copilot i VS Code, som assistent. Github Copilot er ikke det samme som Microsoft’s Copilot, men en tjeneste, som kan hjælpe med at planlægge, skrive, forbedre og teste kode. Det betyder, at jeg skriver mindre og mindre kode selv og i højere grad designer systemet på et mere overordnet niveau.

Github Copilot er gratis for studerende og undervisere, og man kan vælge mellem forskellige sprogmodeller (GPT, Claude, Gemini, Grok m.m.). Der er desuden p.t. fire roller (modes), som man kan give assistenten i Copilot, nemlig Ask (Q&A), Planner, Agent og Custom. Jeg har mest erfaring med Agent-mode, som er en assistent, der både kan besvare spørgsmål, hjælpe med planlægning, ændre i min kode-base og åbne en browser. Hvis man dertil aktiverer “Bypass approvals”, kan assistenten også bruge andre værktøjer bl.a. selv køre kommandoer i terminalen. Dét er selvfølgelig på bekostning af visse sikkerhedsrisici.

Min fremgangsmåden er p.t.:

1. Afklare krav til systemet og formulere kravspecifikation (både funktionelle og ikke-funktionelle krav).
2. Afklare tekniske specifikationer. Hvilke teknologier og arkitekturer skal anvendes?
3. Tilføje overordnede ønsker til brugergrænseflade (UI).
4. Afklare projektplan -Hvad skal implementeres først? Hvornår er projektet færdigt?
5. Sæt agenten i gang med at udvikle og teste systemet ifølge kravspecifikation og projektplan.
6. Når første prototype er færdig, skal assistenten tjekke om alle krav er opfyldt (fx om koden er ren og lever op til principper for god kode) og om alle tests er godkendte. Dér bruger jeg en fast prompt i filen “tjek_projekt.md”.
7. Først her tester jeg selv systemet, og overvejer om interface og funktionaliteter er som jeg forventer. Hvis ikke skriver jeg med assistenten om evt. ændringer.
8. Jeg synkroniserer til Github og får systemet ud på en statisk webside (fx github-pages) eller deployer via host (Heroku).

Måske skal jeg have flere trin fx til at designe brugergrænseflade og funktionaliteter fx use-case diagram, user stories, bruger-rejse, skitser.

For at afklare krav til systemet burger jeg en fast prompt i filen “grillme_krav.md”, med følgende indhold:

• Opret filen documentation/kravspecifikation.md, hvis den ikke findes.
• Der skal udvikles et nyt projekt. Udspørg mig grundigt om formål, brugere, krav, platform, performance, sikkerhed, integration og andre relevante aspekter.
• Stil mig et spørgsmål ad gangen og stil uddybende spørgsmål, hvis svarene ikke er klare.
• Opdater kravspecifikation.md løbende undervejs ud fra svarene på spørgsmålene.
• Noter alle relevante oplysninger i kravspecifikation.md.
• Når vi er færdige, skal du tjekke, at alle aspekter er dækket, og at projektet er klart beskrevet.

Derefter har jeg en lignende prompt i filerne “grillme_tek.md”, grillme_ui.md” og “grillme_projektplan.md”, til at formulere teknikspecifikation, udseende og projektplan. Hvis der skal bruges kald til en sprogmodel i projektet, er det beskrevet i “LLM.md”.

Agenten kan selv oprette mapper og filer, skrive koden, initialisere afhængigheder og hente biblioteker. Den kan selv skrive tests, køre dem og fortolke resultaterne -også tests hvor assistenten åbner en browser og tester funktionalitet af knapper, tekstfelter og lignende interaktive elementer. Den kan formentligt også pushe til Github, deploye og kalde sub-agenter, men det ved jeg endnu ikke, hvordan man gør.

Alt i alt er langt det meste af min kodning ændret til systemdesign. Hvordan bliver man god til systemdesign? Gennem erfaringer med selv at implementere systemer, erfaringer med at designe systemer, kan man læse sig til det eller kan man ligefrem overtage andres (fx AI’s) tilgang?

Det er ikke uden en vis faglig sorg, at kodning lige så stille forsvinder ud af mit liv. Følelsen af at være en troldmand, der egenhændigt kan skabe (næsten) hvad som helst digitalt, forsvinder. Nu kan jeg til gengæld få en ide og se den materialiseret inden for et par timer. Jeg er stadig en troldmand, men måske den lidt ældre af slagsen, som nøjes med at lægge planer og lade andre (AI) udføre dem. Vil der stadig komme nye troldmænd i Verden, når de ældre troldmænd forsvinder?

Der er flere grunde til at træne eleverne i samarbejde. Meget professionelt arbejde foregår i grupper eller teams, både blandt studerende på uni og blandt undervisere, forskere, softwareudviklere og sikkert mange andre steder. Outsourcing af vidensarbejde til chatbots og agenter kan desuden medføre, at samarbejdskompetencer bliver endnu mere efterspurgte i en nær fremtid.

Mine erfaringer fra mine børns folkeskole er, at træning i samarbejde ofte foregår ved, at eleverne selv danner grupper og fordeler opgaverne, så få motiverede/stærke elever påtager sig det faglige arbejde, mens mange elever mere eller mindre velvilligt ikke deltager i arbejdet. Dvs. ingen reel stilladsering af eller træning i samarbejde.

Det mønster ser jeg gå igen blandt eleverne i gymnasiet. Når jeg generaliserer, ser jeg mange elever, som er usikre og tilbageholdende, og de ved ikke, hvordan de skal komme på banen i en gruppe. Mange elever er ufokuserede, og deres hovedmål er at blive hurtigt færdige/undgå arbejde. Nogle elever er mere præstations-orienterede og vil typisk overtage det meste af arbejdet i en gruppe.

Få elever er interesserede i at få gruppen til at fungere. Der opstår en kultur blandt mange elever, hvor de opfatter gruppearbejde som “læreren er væk, vi kan gøre hvad vi vil” dvs. hyggetid, hvor de kan snakke privat, gå i kantinen og surfe rundt på nettet.

Så jeg har brugt lidt tid på at undersøge, hvad træning i godt samarbejde kan indebære*, og jeg sidder med en lille ad hoc arbejdsgruppe om emnet. Her er nogle pointer:

• Elever må selvfølgelig ikke vælge deres egen gruppe, det giver både alt for homogene grupper og enkelt-elever, som står uden gruppe.
• Gruppen bør være heterogen uden at være alt for blandet. At sætte en fagligt stærk elev til at trække en gruppe af fagligt svage elever går ikke -det træner ikke samarbejde.
• Der skal være tryghed til at udtrykke sig, og der bliver talt i en ordentlig tone til hinanden.
• Alle bliver hørt og bidrager til gruppens arbejde. De sikre/ekstroverte deltagere har et ansvar for at holde sig lidt tilbage, og de usikre/introverte har et ansvar for at komme mere frem. De bedste resultater opnås ved, at alle bidrager til gruppens arbejde.
• Der er ikke nogen i gruppen, som må overtage produktet og på den måde løse opgaven selv.
• Der er fokus på opgaven og ikke alt muligt andet.
• Opgaverne bør være åbne og give mulighed for diskussion. Lukkede opgaver kan nemmere løses individuelt.
• Gruppen arbejder hen imod et sted, hvor ideer kan udfordres, og der er en kritisk og undersøgende samtale om argumenter og vurderinger.

Jeg har tidligere eksperimenteret med en “social ansvarlig” i gruppearbejde blandt 3.g’ere, men det blev tydeligt, at det havde de svært ved, og rollen blev hurtigt ignoreret. Derfor tog jeg fat i 1.g’erne og har forsøgt at stilladsere arbejdet med roller mere. Jeg er kommet frem til følgende fire roller:

Referent: Skriver for gruppen (computeren eller papir). Det er ikke din pligt at løse opgaven alene, blot at deltage og skrive referat. Tal sammen i gruppen om opgaverne -lad være med at fordele dem mellem jer. Del dokumentet med hinanden, når arbejdet er slut.

Fokus-holder: Sørger for, at gruppen bliver på opgaven og ikke mister fokus. Tal sammen i gruppen om opgaverne -lad være med at fordele dem mellem jer.

Ordstyrer: Sørger for, at alle kommer til orde i gruppen, så alle taler cirka lige meget. Tal sammen i gruppen om opgaverne -lad være med at fordele dem mellem jer.

Spørge-Jørgen: Det er din rolle at stille spørgsmål til de andre mindst tre gange. Eksempler: ”Hvorfor det?”, ”Hvad betyder det?”, ”Hvordan vil du forklare det?”, ”Hvordan kan man se det fra en anden vinkel?”. Tal sammen i gruppen om opgaverne -lad være med at fordele dem mellem jer.

Jeg er ikke helt tilfreds med ordlyden. Fx. skal “Spørge-Jørgen” på sigt ikke bare være en der spørger, men være ansvarlig for at sætte gang i den faglige og kritiske diskussion. Rollen skal nok også have et nyt navn.

Målet er i første omgang, at eleverne bliver opmærksomme på, at rollerne findes i samarbejde. Opmærksomheden får de ved at påtage sig rollerne og gennem evaluering og meta-refleksioner. Derfor skal rollerne også skifte ofte. Derefter er målet, at eleverne bliver bedre eller ligefrem gode til at udfylde hver rolle. Endemålet er, at de alle påtager sig alle rollerne i gruppearbejde.

Nogle spørgsmål, som kan vække elevernes tanker kan være:

• Hvad er et godt gruppearbejde?
• Hvad er dårligt gruppearbejde?
• Hvilken rolle er den sværeste? Hvorfor?
• Hvilken rolle er den vigtigste? Hvorfor?
• Hvad lykkedes du med i rollen?
• Hvornår fungerede rollen ikke så godt?
• Hvad kunne du overveje at gøre anderledes i næste gruppearbejde?

Er rollerne udtømmende for et godt samarbejde? Nej, men de sætter nogle hjørnesten, som der kan arbejdes videre ud fra. Derefter kan vi fx arbejde med samtale-runder (evt. på tid), differentierede grupper efter niveau, individuel forberedelse i klassen/hjemme og andre tiltag, som kan støtte den svære “ordstyrer”-rolle.

* Agergaard m.fl. “Gruppearbejde”; Duch, Henriette (red.) “Gruppearbejde på ungdoms- og videregående uddannelser”, Frydenlund 2023; “Tea for Teachers”, Podcast episode “Make Team Project Work”. https://teambuildingprocess.com/making-team-projects-work/

Skoleåret 2025-26 kommer til at byde på:

• Mere formidling om og med genAI. Både i bioteknologi, informatik, øvrige fag og med kolleger.
• Hvad gør vi med afleveringer og genAI?
• Podcast med informatik-kolleger om udfordringer i faget –Lidt om Læring.
• Et lille projekt om samarbejde mellem elever.
• Mere flipped learning for at imødegå AI?
• Måske en workshop om vibe-coding?

Jeg var på sommerskole 2025 i Bork -Herligt. Jeg fik ikke så mange nye ideer med hjem. Dog:

• Man kan opsætte sin egen server med YunoHost. Målet kan være at blive mere uafhængig af serverløsninger som onedrive og AWS. YunoHost kræver noget fiflen med netværk, port-forwarding, DNS-omregistrering m.v., som jeg ikke tør gøre p.t.
• Jeg har installeret Linux Debian OS på en gammel laptop. Har valgt Debian, fordi YunoHost kan installeres ovenpå senere.
• Byggepladen er et website for brugergenereret lego-content.
• OpenFoodFacts en åben database med fødevare data og egen åben API løsning.
• Der ligger et computerspils-museum i Berlin.
• SkoleGPT er/bliver opdateret med en version der bygger på Gemini frem for Mistral. Det skulle forbedre performance betragteligt.
• Materiom er en samling om materialer

1. Simple problemer: Enhver kan se løsningen, som ligger ligefor. Der er entydig en enkel sammenhæng mellem årsagen til problemet og løsningen. Det er muligt at opstille en best practice, fordi der er en indlysende og gennemprøvet måde at løse problemet.
2. Kaotisk: Der er ingen sammenhæng mellem årsager og virkninger. Derfor er det tilfældigt hvad der virker og ikke virker. Bedste bud på en løsning er, at en ledelsesperson tager en beslutning for alle involverede, som kan bringe systemet til et af de andre domæner.
3. Komplicerede problemer: Her er en sammenhæng mellem problemet og løsninger tilstede, men den er svær at finde. Derfor skal problemet analyseres af en (eller flere) kompetente eksperter, som kan analysere problemet og udpege løsninger. Det kan være nødvendigt at indsamle data før analysen. Problemet er så kompliceret, at det er umuligt at opstille én entydig best practice. I stedet kan der opstilles en good practice, som et katalog over handlinger, som kan bidrage til at løse situationen.
4. Komplekse problemer: Her er så mange aktører og sammenhænge, at problemerne ikke lader sig dele op i isolerede problemer. Desuden skifter forudsætningerne ofte, så noget der har virket, måske ikke virker igen. Derfor er det ikke muligt for en ekspertgruppe at analysere (deducere) og udpege løsninger. Det er hverken muligt at opstille best eller good practice. I stedet skal der anvendes metoder fra det Agile rammeværktøj: En divers gruppe med forskellige kompetencer skal afprøve forskellige handlinger, på vej mod en løsning. Gruppen skal forstærke de handlinger, som viser tegn på at løse situationen, og formindske de handlinger, som viser tegn på at forøge problemerne.
5. Uorden (disorder/forvirring): Ligger midt i modellen. Her placeres situationen, hvis man ikke ved hvilket af de andre domæner, den kan placeres i.

Mange forhold i undervisning udgør heldigvis simple problemer med simple løsninger, som er nemme at gennemskue. Meget af den traditionelle undervisning ligger også her. Hvis problemet er, at eleverne mangler viden og kompetencer om emnet, så gennemgår læreren det eller eleverne læser det, så løses der opgaver osv. Det er som regel undervisningen i velfungerende stx-klasser, som ligger her.

Noget undervisning indeholder situationer, som er sværere at gennemskue. Det er de komplicerede problemer. Fx hvad skal der ske med skærmene i skolen? Vi skal både bruge dem, og de tager en masse ufaglig opmærksomhed. Der er blevet lavet en række ekspert-undersøgelser på området og udgivet en good practice i skærmbrug, som de fleste følger.

Simple og komplicerede situationer kan som regel løses ved at lægge en plan og følge den. Det kan kaldes at følge en vandfaldsmodel, hvor hver aktivitet er fastlagt i en bestemt rækkefølge og resultater forudsigeligt. Meget undervisning foregår på den måde, når læreren gentager det, som blev gjort sidste år. Metoden virker heldigvis i mange undervisnings-situationer.

Nogle undervisnings-situationer placerer sig i det kaotiske domæne: Her er meget frustration blandt underviserne (og eleverne), og intet ser ud til at virke. Derfor kan man ønske, at nogen bestemmer, at nu skal undervisningen køre på en bestemt måde, som kan bringe situationen hen til et af de andre domæner. Det kan være klassen opløses eller deles i to halvdele, eleverne får faste pladser eller alle produkter skal afleveres. Eleverne kan ønske, at læreren udøver høj grad af autoritet.

Nogle lærings-situationer påvirker så mange forhold, at de ligger i det komplekse domæne. Der er nogle årsag-virkning sammenhænge, men de er filtrede sammen. For eksempel undervisning i HF, som jeg placerer i det komplekse domæne, fordi elevgruppen er ofte meget blandet med stor faglig spredning, diverse diagnoser og meget forskellige sociale kompetencer. Desuden kan eleverne skifte meget gennem forløbet, da deres sociale-, familie- og sundhedsmæssige forhold kan skifte.

Situationer i det komplekse domæne, som undervisning i HF, skal udføres med metoder, som ligger inden for det Agile rammeværktøj. Underviseren skal afprøve forskellige lærings-designs/aktiviteter, og undersøge effekten, for derefter at udbygge de dele, der virker lige nu, og nedtone de dele, som ikke virker. Hvad der virker, kan ændre sig gennem forløbet eller fra hold til hold, fordi eleverne og læreren ændrer sig. I dén situation, er det en fordel at være en erfaren underviser, fordi man har en række af lærings-designs liggende, og kan prøve dem af på et nyt hold.

Målet med hver aktivitet er læring, og det kan være svært af måle. Et bud kan være en formativ evaluering fx i form af:

• en grundig evaluering med spørgeskema
• samtale med enkelte elever
• underviserens indtryk af effekten
• gruppe- og/eller klassedialog
• lyn-evaluering hvor eleverne med tommelfinger markerer up, mellem eller ned.

De hurtige metoder (sidst på listen) er nok at foretrække, fordi det er bedre at bruge tiden på at teste flere aktiviteter af, end at gennem-teste få aktiviteter. En evaluering på elevernes viden og kompetencer skal der også til. Ikke for at vurdere eleverne, men for at vurdere, om en aktivitet virker. Har der været flere aktiviteter i spil, bliver det selvfølgelig sværere at klarlægge en entydig årsag-virkning sammenhæng.

Egentlig burde underviserne i en HF klasse tale meget mere sammen, fordi en divers gruppe af undervisere kan få mange flere ideer og kan afprøve mange flere aktiviteter end en enkelt underviser.

Dog er det ikke givet, at ét lærings-design, som virker hos én underviser, vil virke ligesådan hos en anden underviser. Underviseren er en anden, relationen mellem underviser og elever er en anden, og eleverne er et andet sted både fysisk og mentalt. Men underviseren kan prøve at forstærke designs, som virker her og nu.

Dertil må underviseren tage hensyn til læreplaner og forskellige elevtyper i vurderingen af hvad der skal forstærkes og svækkes. Nogle elever kan trives med én type af aktiviteter, mens andre elever ikke har udbytte af den.

Det kan være fristende at placere undervisning i HF i det kaotiske domæne. Løsningen kunne i givet fald være, at nogen vedtog en plan for fast curriculum, opgaver, aktiviteter og øvelser. Dét ville ikke udnytte underviserens kompetencer ret godt, og man kunne derfor sætte en underviser med lavere uddannelse til at undervise. Det ville desværre også gå ud over eleverne: de fagligt dygtige ville ikke blive udfordret, og de fagligt svage ville risikere at blive hægtet af.

Hver tjeneste har sine fordele og ulemper. Quizlet Live er godt til at få eleverne til at tale sammen, mens de quizzer. Kahoot er meget larmende, men læreren kan komme med faglige pointer mellem hvert spørgsmål, og på den måde bruge Kahoot som et interaktivt tavleoplæg. LearningApps er meget grafisk fx placer begreberne korrekt på figuren, sæt figurer i rigtig rækkefølge eller fordel begreber i kategorier.

Hvor Kahoot er en quiz, er Blooket gamificeret begrebstræning. Læreren vælger og hoster et Blooket-spil, og eleverne joiner ligesom i Kahoot.

Læreren vælger hvilket sæt af begreber-definitioner, der skal anvendes, den tid/point man spiller til og spil-genren. Der 14 forskellige og de klassiske spilgenrer er repræsenteret: tower-defense, platform, tycoons, maze, battle royal m.m. Begreber og definition kan importeres fra Quizlet eller fra word/excel.

Fælles for alle spil er, at eleverne jævnligt skal svare rigtigt på spørgsmål (MC med fire svarmuligheder) for at tjene point og klare sig godt. Eleverne spiller individuelt, men deltager i det samme spil.

I modsætning til Kahoot er der meget mere grafisk interaktivitet end blot at trykke på en farve. I nogle spil skal man styre en figur, i andre skal man blot træffe valg fx hvilken af tre kister vil du åbne? I nogle spil er der en høj grad af interaktion mellem spillerne, fx er der flere spil, hvor man kan angribe hinanden -kamp afgøres af hvem der svarer korrekt på spørgsmål. I nogle spil kan man prøve at stjæle point fra hinanden -om det lykkes afgøres af om der bliver svaret korrekt på spørgsmål. I andre spil er tilfældigt hvem man stjæler fra.

De fleste spil indeholder en høj grad af tilfældighed fx det loot man får kan være meget varierende. På tavlen kan man hele tiden følge med i hvem der fører -hvilket ofte skifter ret hurtigt, givet den høje grad af tilfældighed, som er indbygget i de fleste spil.

Blooket anvender mange af de klassiske tricks inden for adfærds-design: gentagne grafiske cues når der kommer en belønning eller en straf, ingen ende på spørgsmålene, super enkel valg-arkitektur (som regel kun 2-3 valgmuligheder), tilfældighed i belønning både mht. hvad man får ud af at svare korrekt og hvornår der pludselig kommer en uventet bonus, ambient kommunikation i form af samme naive grafiske udtryk som Kahoot, så eleverne allerede er sporet ind på spil, top6-leaderboard, der anerkender dem, som klarer sig godt.

Største udfordring er nok, at Blooket forlader sig (ligesom quizlet) på at eleven genkender det korrekte svar, og ikke selv aktivt genkalder sig svaret før det vises. En tjeneste som cram.com er derfor mere velegnet til at lære begreber effektivt.

Alligevel har jeg valgt at bruge Blooket. Og eleverne elsker det tilsyneladende. De synes, at det er sjovt, men lærer de noget? På sigt får Blooket sikkert sin plads på hylden ligesom Kahoot, og kan tages frem en gang imellem.

Det første kursus har givet mig en række metoder inden for interaktionsdesign og inspiration til at arbejde videre. Særligt tre områder tænder mig: grafisk facilitering, embodiment og design thinking.

Grafisk facilitering er sjovt. Jeg har altid tegnet meget, og det ville være rart at få tilbage, som en del af min praksis. Jeg bilder mig ind, at tegning formidler og fokuserer indholdet på en anden måde end ren tekst, men jeg har endnu ikke fundet en undersøgelse, der efterviser det.

Embodiment handler om at have kroppen med i undervisningen. Hjernen er ikke et isoleret organ, og skolen har nok en tendens til at overfokusere på de intellektuelle forhold og glemme kroppen. Kroppen sanser miljøet og kan interagere med det. Kroppen kan bruges som et kognitivt stillads til læring, og nogle anbefaler at undervisning skifter mellem refleksion og “mindful action” (1).

Mindful action kan ske på mange måder. Rollespil er en udbredt måde. Tværfaglighed og fremmede objekter eller lokationer kan inspirere til nye måder, at inddrage kroppen.

Design thinking (engineering?) betragter jeg som en del af computatioal thinking (CT), som handler om at overveje hvordan digital teknologi kan bruges (herunder hvordan det virker) og hvad det gør ved os og samfundet. CT konkretiseres i bl.a. mønstergenkendelse og abstraktion. En vej dertil kan være ved at arbejde undersøgelses-baseret på komplekse problemer (wicked problems) i en iterativ tilgang, som kendes fra design. Alle digitale produkter er frembragt gennem design thinking.

Design thinking ligner på nogle punkter naturvidenskabelig metode -begge er iterative. I design thinking er det designeren (og andre interessenter), der skal co-designe en løsning. I naturvidenskab er det forskeren, som skal tolke data ud fra logik. Design thinking evaluerer, mens naturvidenskaben af- eller bekræfter en hypotese. Det er der lavet mange flotte diagrammer af fx dobbelt-diamanten. Design thinking kan bruges i design af forsøg.

Nogle sekvenser, som kunne udvikle grafisk facilitering, embodiement og/eller design thinking kunne være:

• Forsøggange som storyboard eller rutediagram. Særligt velegnet ved gentagelser eller forgreninger
• Design-metoder i elevernes udvikling af forsøg. Trinvis forbedring.
• Brikker til rutediagrammer
• Udklippede kodebrikker
• Objekt-teater/bodygramming: Lad eleverne udspille projekter og programmer
• Mere krop i undervisningen fx gennem tværfaglighed, nye objekter eller lokationer
• Netlogo til use-modify-create
• Kode som brætspil
• Line Have Mussaeus, som bl.a. arbejder med Netlogo
• Scenarie- eller spilbaseret didaktik

Den overordnede pointe, som jeg har mødt, er at teknologiforståelse og informatik ikke skal være et programmeringskursus, men anvende give eleverne meta-strategier ifht. at anvende og analysere digitale produkter.

1. Larson, D. J. (2015). Don’t Forget About the Body: Exploring the Curricular possibilities of embodied pedagogy . Innov High Educ(40), pp. 331–344.

Sammen med nogle elever og kolleger planlagde og lavede vi opgaverne til et escape room. Vi talte om et tema, og blev enige om jul, da det var midt i december. Og vi havde fået lov at låne et skummelt og rodet depotrum i kælderen, som blev døbt “Julemandens Gravkammer“.

En stort plus er, at hele konceptet kan tilpasses præcis til designernes niveau. Disse skal selvfølgelig også tænke på deltagernes, altså dem der skal prøve rummet, niveau, og tilpasse opgaverne herefter. Fagene kan være mange forskellige, da gåderne kan være både sproglige, matematiske m.m.

Udfordring: Deltagerne, som skulle spærres inde, fik at vide, at for at komme ud, skulle de finde fem stykker lego, som skulle samles til en bestemt figur. De fik kort vist hvordan figuren så ud, og blev derefter låst inde (døren var ikke rigtig låst).

Vi arbejdede med at opgaverne så vidt muligt skulle løses i rækkefølge, for at fremme en sekventiel tankegang inspireret af computational thinking. Hver opgave udløste et stykke lego til den store figur.

Opgaver:

1: Flette et julehjerte, som, når det blev flettet korrekt, viste tre ligninger med tre ubekendte. De tre ubekendte var koden til et skrin. I skrinet lå ledningen et et UV lysstofrør. Med kinin-opløsning havde vi skrevet en usynlig besked på et skilt. En af beskederne var at tænde en OH projektor.

2: Projektoren viste (når alt andet lys blev slukket) et digt, hvor ordet gul var understreget. Med et par flere hints, blev de ledt til en LEGO robot, som kunne give dem en gul nøgle, når det rigtige program blev aktiveret.

3: Nøglen åbner et skrin, som indeholder en Arduino, der blinker i morsekode. De valgte at lade en grøn LED blinke bogstaver og lade en gul LED signalere “nyt bogstav”. Der ligger også en oversættelsesnøgle. Beskeden sender deltagerne til en papkasse, hvor man skal stikke hånden ind og føle på nogle legoklodser. De skriver ordet: Piano.

Arduino som blinker i morsekode. Den gule LED blinker når et nyt ord begynder, og den grønne LED blinker bogstaverne.

4: Ved klaveret skal der løses en matematisk gåde, som sender deltagerne til en kasse med fire legoknapper. Når de tre trykkes samtidig siger kassen (en Lego Mindstorms) 666.

5: 666 er koden til en hængelås, som åbner et skrin, hvori den sidste lego-klods ligger.

Vi valgte, at deltagerne så vidt muligt skulle klare opgaverne i rækkefølge, for at få eleverne til at tænke over sekvenseringen i planlægningen -hvordan skulle deltagerne komme fra den ene opgave til den næste.

Vi prøvede med tre grupper af deltagere, som klarede sig meget forskelligt -lærergruppen klarede sig nok dårligst, men var også første prøvekanin. Der skal ret tydelige hints til at få deltagerne gennem opgaverne i den tænkte rækkefølge. Alternativt skal de tilbydes hjælp undervejs fx med tre livliner. Der må ikke være for mange opgaver, hvis deltagerne skal have en chance.

Det er rigtig sjovt, at være med til at finde på tema og opgaver -formentlig meget sjovere end at være en deltager der spærres inde. Opgaverne kan tilpasses alle fag (sprog, matematik, naturvidenskab, programmering, elektronik, m.v.) og niveauer.

Er et escape room bare pjat eller er der noget læring i det? Selv om det ikke passer ind i de almindelige fag, er der masser af læring i struktureringen af hele rummet, designe opgaver med logiske løsninger og formidlingen overfor deltagerne, som spærres inde. Disse læringspotentialer er svære at opstille som mål -så meget for synlig læring.

• Arbejde med Mindset og blive mere erfaren mht. innovation og projektarbejde. Det fik jeg ikke gjort meget ved. Jeg var med i et At-forløb med innovation. Det var godt, men svært at få indpasset i stx’s læreplaner. Mindset ligger mere som en tanke i mig, end som en metode jeg bruger aktivt.
• Undersøge om Coding Pirates giver mening for mig (os). Deltage som frivillig i Odense ihvertfald i en periode. Jeg besøgte coding pirates een gang, hvilket var meget inspirerende. Turen til Odense er dog ikke praktisk muligt på ugentlig basis. Til gengæld har vi lavet noget om robotter og micro:bit for børn i Svendborg af to omgange (vist 8 torsdage i alt).
• Opsøge legekammerater i ML, CP og MS. Det er svært både for mig og andre, at få tid til at lege.
• Bruge mindre tid på styresystemer og platforme -det er kedeligt legetøj. Det er lykkedes nogenlunde.
• Kost og motion. Floorball i Ollerup? Kostomlægning? Det fik jeg ikke gjort.
• Bruge passende tid på sociale medier, og lidt mere tid på at kigge ud i luften. I perioder. Men telefonen er svær at lægge væk.

Mål for 2017-18:

• Arbejde videre med machine learning og kunstig intelligens.
• Arbejde hen i mod at supplere til uv kompetence i informatik. Begynde kurser sommer 2018.
• Lave flere forløb om robotter, programmering og ML.
• Lave motion 30 minutter på ugentlig basis. Alene eller med andre.
• Holde øje med mit timetal, så arbejde ikke fylder for meget.
• Blive bedre til 3d printing.
• Lave mere for børn om robotter, hvis der er overskud.
• Kunne være sjovt, at prøve at lave et podcast.