Pactum - en app til afklaring mellem lærer & elev

Transkript

1 Pactum - en app til afklaring mellem lærer & elev Hvert år tager et hold elever fra Teknisk Gymnasium Silkeborg til Australien. Dernede følger de undervisningen i et semester. Undervisningen foretages af de lokale undervisere fra Wide Bay TAFE, men der er undtagelser. Gennem snart ti år, hvor eleverne har gæstet det australske gymnasie, har en lærer fra Silkeborg været ansvarlig for undervisningen i dansk. Det er som på alle andre gymnasier undervisning på A-niveau, så det drejer sig om en hel del timer. Den undervisning er de seneste år foregået ved hjælp af et konference-system med bredskærm, mikrofon og højtalere, der skal hjælpe med at krydse de km mellem lærer og elever. Som underviser i faget Kommunikation og IT er dette semester særligt spændende for mig. For første gang har vi en studieretning med faget på A-niveau. Og den studieretning er netop den Internationale Studieretning, som 6. juli forlod Silkeborg for at bruge det næste halve år i Australien. Det betyder, at vi skal få faget Kommunikation og IT-A til at spille sammen med de lidt særlige, virtuelle omstændigheder. Det er afgørende, at forløbet bliver en succes. Forløbet skal både give de nuværende elever den bedst mulige faglige ballast - og sikre fremtidig søgning på studieretningen. At foretage virtuel undervisning er sjældent problemfrit. Det er ikke denne opgaves formål at analysere de mange muligheder for fiasko, eller beskrive metoder til succes. Men i den nærværende opgave vil jeg forsøge at skitsere en lille webapplikation, der måske kan bedre muligheden for succes i det virtuelle undervisningsforløb. Idéen til app en tager udgangspunkt i én af de mange udfordringer, man kan møde som underviser i virtuelle forløb: Fejlvurderingen. Det er ikke sjældent, at en elev fejlvurderer sin egen indsats og kunnen. Det er heller ikke ualmindeligt, at en underviser fejlvurder en elev i et virtuelt forløb. Særlig svært er det med de længere virtuelle forløb. Det skyldes tre forhold: Underviseren har i det begrænsede og konstruerede samvær sværere ved at danne sig et fyldestgørende indtryk af elevens evner og indsats. Eleven har sværere ved at finde ud af, hvordan underviseren vurderer den enkelte elev i forløbet. Og endelig er det sværere at samstemme underviserens og elevens indtryk af elevens evner og indsats. Det er her, denne opgaves app skal forsøge at ændre forholdet til det positive. Hvorfor i det hele taget interessere sig for, hvorvidt eleven er enig med underviseren i dennes vurdering? Det er der flere gode grunde til: 1. Det bør undgås, at eleven mister motivationen efter et forløb, hvor eleven har fejlvurderet sig selv og overraskes af lavere karakter end forventet. 2. Hvis underviseren ikke interesserer sig for, hvor eleven selv mener at befinde sig i ADRESSE (ARB.) POSTNUMMER (ARB.) BY (ARB.) URL (ARB.)

2 forhold til evner og kunnen, bliver det fælles resultat temmelig fattigt. 3. Skyder elev og lærer ved siden af hinanden over et helt semester, kan det efterfølgende give anledning til en hel del animositet. Det vil være en alvorlig hindring for fremtidig læring såvel som undervisning. Det er med andre ord ikke en detalje i undervisningen, men et centralt forhold, som en app muligvis kan medvirke til at bedre. Når det er sagt, bilder jeg mig ikke ind, at systemet her vil virke som en mirakel-kur. Men det er en idé, der virkelig tiltaler mig. Den er virkelighedsnær, beskæftiger sig med en daglig udfordring i mit arbejdsliv og kan umiddelbart tages i brug. Derudover lader det til, at den besvarer de krav, der stilles på: nt Opgavens ordlyd: I beskrivelsen af opgaven på CourseAdmin ønskes det, at nærværende opgave beskriver et system, der lever op til følgende: 1. solves a non-trivial task 2. is interactive 3. applies some form of persistence 4. allows users to add / modify / structure content 5. can be tested by others 6. is not broader than what you can manage to implement 7. is interesting enough that you can write a project work on it! I det følgende beskrives det system, der skal honorere opgavens krav såvel som opfylde mine personlige behov i den kommende undervisningssituation. Først en mere detaljeret beskrivelse af behov og løsning. Behovet er enkelt: Afstem vurderingen af en elevs evner og indsats mellem lærer og elev. Systemet skal hjælpe med at opstille enkelte parametre, som både lærer og elev skal udfylde og derefter se, om de stemmer overens. Stemmer de ikke overens, kan der være grund til at ændre undervisningen, samtale eller skifte materiale. I det følgende skitseres enkelte overvejelser bag systemet. Brugere: I systemet vil der være to bruger-grupper. Den ene gruppe består af den eller de undervisere, der kommer til at bruge app en. Den anden gruppe består af de elever, der skal modtage undervisningen. Den ene gruppe, der består af undervisere, skal have mulighed for at oprette den anden gruppe af brugere. Det kommer til at ske enkeltvis, en bruger ad gangen. Underviserne kan oprette nye parametre per bruger, fylde eksisterende parametre med værdier eller tjekke om eleven har udfyldt sin del. Eleverne kan det samme med den undtagelse, at de ikke kan oprette nye brugere. Indtil jeg finder på en bedre løsning vil underviseren være nødt til at sende eleven dennes adgangsoplysninger per mail. SIDE 2

3 Admin: Da det formentlig vil være for omfattende i forhold til efterårssemesterets opgaver tillige at udforme en egentlig back-end, tænkes det, at den ene brugergruppe, underviserne, oprettes via phpmyadmin - med alt hvad dertil hører af brugernavne og passwords. Til at begynde med, er der kun én underviser til at teste systemet. Tilføjes for mange undervisere, bør det overvejes at lave en superbruger, der kan invitere flere undervisere til gruppen. I nærværende opgave skitseres den løsning ikke. Platform: Det er ikke planen at udforme et system, der kan bruges af flest mulige. Snarere drejer det sig i denne opgave om at løse en helt specifikt udfordring. Og i denne sammenhæng er platformen allerede givet, idet eleverne forventes næste år at medbringe ipads indkøbt af skolen. Man kunne løse opgaven ved at forberede et system til forskellige browsere, måske endda til forskellige mobile enheder. Men eftersom vi med sikkerhed kan sige, at eleverne i det kommende vil bruge en ipad og den tilhørende browser Safari, bliver opgaven på det punkt langt mere entydig. Og en hel del lettere. Kodning: Safari er en af mest html5- og css3-forberedte browsere på markedet. Med det forhold in mente, vil det være naturligt, at designet kommer til at ligge på en flade af html5 med css3 som design-sproget. Det giver blandt andet mulighed for enkelte animationer og selektorer såvel som en semantisk struktur, der vil gøre hele affæren let-overskuelig (her tænkes på overgangen fra div-suppen til de nye tags som fx header, nav og footer). Selve den dynamiske del af systemet vil skrives på php. Back-end delen vil være standard MySql, som tilgåes via phpmyadmin. Brugerfladen: Da systemet bygger på en fortolkning af en enkelt browser på en enkelt mobil enhed, bliver overvejelserne omkring brugerfladen heldigvis noget enklere - og lægger måske endda op til at forfølge den simplicitet, der kendetegner mange Apple-produkter. Det er samtidig min erfaring, at elever, der opholder sig kilometer fra deres underviser, ikke kan tvinges til at bruge unødigt tid på opgaver, der synes at være mere til fordel for deres underviser, end for dem selv. Brugerfladen skal altså være ualmindelig simpel, hurtig og kunne anvendes med minimal forudgående instruktion. Elevens muligheder: I et af opgavens krav lyder det: allows users to add / modify / structure content. Eleven kan, foruden at udfylde parametrerne med værdier, selv tilføje parametre. Næste gang underviseren tjekker den pågældende elev, vil de af eleven tilføjede parametrer være tilgængelige - og skal udfyldes. SIDE 3

4 Sikkerhed: Da systemet vil rumme personfølsomme oplysninger, er det bedst om systemet kun tillader et en-til-en forhold. Det er ikke sikkert, at en elev ville bryde sig om, at en anden elev kunne tilgå hans eller hendes oplysninger. Kun login-siden er tilgængelig for brugerne indtil bruger-navn og password matcher databasens oplysninger. Systemet i sig selv bør tillige rumme forskellige sikkerhedsanordninger. Det gælder både mulige tegn i formularene, en.htaccess-fil og en robot.txt til at sikre sig mod typiske angreb. Der er helt sikkert flere i den sorte ende af php-verdenen, men min erfaring er også på det område meget begrænset. Udvidelser: Man kan tænke sig et væld af udvidelser. Fx kunne oplysningerne bruges i et andet databasesæt. Heri kunne man fx forestille, at undervisningen sigtede ikke kun mod gennemgået materiale, men mod overensstemmelse mellem lærer og elev på et vist niveau. På den måde ville et undervisningsforløb ende på det tidspunkt, hvor systemet viser, at lærer og elev er enige om, at eleven er nået til, lad os sige mindst 7 ud af ti på en skala for kunnen i et vist stof. Og ikke når læreren havde gennemgået et undervisningsmateriale, som det typisk er tilfældet. Det burde ikke være værre end at indføre end if-sætning til at afgøre, om begge har nået samme høje værdi - for herefter at tillade en særlig farve, tekst eller url-adgang. I så fald vil det i forbindelse med differentieret undervisning, gøre det sikkert for underviseren at tillade den enkelte elev at tage hul på et andet forløb. Test: Ingen app kan tænkes at ramme helt rigtigt i forhold til forventningerne uden test. Som førstegangs-producent af en selvstændig webapplikation kan det derimod snildt forestilles, at systemet indeholder op til flere fejl. Det gælder ikke mindst de fejl, der har at gøre med bruger-interaktionen. Til alt held er der i skrivende stund et helt hold elever fra Teknisk Gymnasium Silkeborg i Australien. De har dog ikke ipads med (pga lidt tekniske forhindringer), men kan til fulde anvende og kritisere systemet fra de medbragte maskiner. Hvad angår test af usability kunne det være en fordel at afprøve nogle af de omkostningsfrie tiltag som de skitseres af Steve Krug (forfatteren til blandt andet Rocket Surgery Made Easy ) på dennes hjemmeside: Da en af det omtalte australiens-holds elever af forskellige forhold er tvunget til at blive i Danmark, vil det desuden være muligt at lave test, hvor man kan iagttage brugerens aktiviteter undervejs. SIDE 4

5 Konstruktion: Hele webapp en kommer til at køre over et domæne. Her skal app en hostes og url en kunne tænkes at minde om det site, jeg i år har lavet til eleverne ovenpå en WordPress-kerne: Backend-delen kunne med fordel benytte samme phpmyadmin-adgang. Her kunne man konstruere en database-del, der blandt andet rummer den ene brugeregruppes - undervisernes - passwords. En anden del af databasen skal kunne rumme parametre og værdier. Hele systemet kan bedst beskrives ved følgende struktur, hvor hver af de følgende lommer rummer en tilstand: Eksempler på brugerfladen: De følgende skitser har til formål at beskrive funktionaliteten. De er ikke ment som retvisende og endeligt design. Enkelte af funktionaliteterne kunne også skifte placering i det endelige produkt. Eksempelvis kunne det tænkes at give mere mening, hvis brugeroprettelsen sker på menu-siden og ikke - som her - på siden med parametrer og værdier. Det vil en iterativ test-design-proces kunne give det bedste svar på. Indtil da ser skitsen ud som følger: SIDE 5

6 Underviser og elev logger ind (på samme side): Undervisers menu tillader derefter tre handlinger: Vælg elev, opret ny eller log ud (hvorved brugeren returnerer til log-ind) SIDE 6

7 Elevens menu vil om muligt se endnu mere simpel ud, hvor farven på knappen til oversigten kunne angive, om alle parametre var udfyldt af begge: Medmindre brugeren logger ud vil, underviseren blive ført til dette billede, hvor han eller hun kan oprette ny bruger og indtaste parametre og værdier: SIDE 7

8 For eleven vil det således ud: Fælles for dem begge er plustegnet, der skal angive mulighed for at tilføje parametrer. Fluebenet angiver udført arbejde og vil returnere begge brugertyper til menu. Logud fra menu vil ligeledes føre begge brugertyper til login-siden. Til slut bør det bemærkes, at selve navnet Pactum peger på den bærende funktion i applikationen: Enighed. App en kunne tænkes at indgå i et netværk af data-brug til fx planlægning, oversigter over hvordan en hel klasse udvikler sig eller grafer til illustration af pædagogiske pointer. App en kunne endda tænkes anvendt med eleven som afsender. Men da et af kravene til opgaven lyder not broader than what you can manage to implement, tillader jeg mig at lade de muligheder stå til et senere virke. Endelig vil det også være på sin plads, at henvise til dette kurset i webapplikationers indledende materiale, der blandt andet dækkede Vannevar Bush s tankevækkende artikel As We May Think. I denne og i de følgende artikler opridses en forestilling om fremtiden, som et rum for et forstærket brug af menneskets evner gennem relationer. Lykkes denne lillebitte webapplikation, vil det for mig være netop det: En forbedring af elevers udviklingsmuligheder gennem relationer medieret af et digitalt produkt. Det bliver en kæmpe udfordring for en ikke-programmør, men også vanvittigt spændende. Michael Hanson // juli 2011 // Masterkursus i Webapplikationer SIDE 8