YIKES :: a short blog for the masterclass in webapplications at AU '11 :: assignments

Opsummering af evalueringen

30.10.2011

Når man evaluerer sin første webapplikation kan det virke overvældende, hvor mange ændringer, der burde foretages, før en app bliver som ønsket. det beroliger dog lidt, når Jakob Nielsen og Loa Horanger ofte slår fast, at selv store, etablerede sites begår klassiske brølere. Det skal dog ikke være en sovepude, men jeg tager den tanke med mig, mens jer gennemgår evalueringsforløbet. Som indledning til min opsummerende evaluering bør jeg nævne den sidste test, der ikke nåede med i det tekniske review - og vel egentlig også ligger lidt uden for den del. For efter det tekniske review gennemfører jeg en endnu test. Det bliver ikke med en elev. Det er svært at fange brugere på 17.500 km afstand. Og det bliver så heller ikke over Skype. I stedet indfanger jeg den ældste af mine børn. Hun er selv gymnasieelev, dog ikke i Australien, men jeg forklarer princippet. Hun tester de dele, jeg har defineret i min evalueringsplan. Det går alt i alt meget fint. Der bliver bemærket både positive og negative forhold ved app'en - og de spiller en rolle for den endelige evaluering. Derfor herunder en kort gennemgang af testen:

Login viser sig at fungere ret godt. Jeg beder hende om at gå ind på elev.php. Hun får en melding om at logge ind først. Super. Det virker. Ved første forsøg går det imidlertid galt. Login er forkert. Men det viser heldigvis - om ikke andet - at sikkerheden i den del virker:

screenshot af fejl i login

Herefter går det fint. Hun indtaster data, men spørger, hvad der menes med at Alt er nu i vinkel. Det er rigtigt. Jeg ville gerne, hvis app'en signalerer en afslappet tilgang til en fælles evaluering af elevens evner og engagement, men det er farligt, hvis det på samme tid bliver misvisende. Jeg overvejer at ændre meldingen.

foto af alt er i vinlel melding

Hun prøver med vilje at lave en fejl i endnu en indtastning. Ups. Det afslører sjusk med koden, for her er fejlmeldeningen pludselig rykket helt ud af boksen:

screenshot af fejl i login

Herefter udfører hun handlingerne som foreskrevet, men hun spørger også til, om det ikke er lige lovlig naivt, at give alle brugere adgang til alle former for indsat af data. Og heri fanger hun nerven i login-problematikken: der burde være to adgange. Oprindeligt havde jeg i min wireframe netop tegnet en admin-del og en elev-del. desværre blev jeg af tidsnød tvunget til at lade alle brugere oprette sig på lige fod. Men det kræver, at alle opretter sine data korrekt. Og at man ikke forsøger at se andre brugeres resultater. det kunne dog undgås med en ekstern brugs-politik. Som fx at oprette brugere med navne plus en suffix som fx tre tal: Morten123.

Oprindelig tænkte jeg, at brugeren ikke behøvede at indtaste sit navn, men udelukkende vælge sig selv på en i forvejen oprettet liste. Det er stadig et ønske, der har høj prioritet, og det vil formentlig forhindre en del af forvirringen. Desuden var den meningen, at sammenligningen af data skulle foregå ad grafisk vej, altså som farvede streams, der med længden angiver graden af fx evner eller engagement. Det vil muligvis også medvirke til at forhindre forvirring og højne brugeroplevelsen.

Alt i alt giver de tre tests et samlet billede af en app, der ganske vist kan bruges, men som rummer følgende udfordringer:

  • - Navigation og formål skal fremgå tydeligere

  • - Tilgangen til app'ens dele skal fordeles på bruger-roller

  • - Kode skal gennemgås for redundans

  • - Databasen kan med fordel ændres, så den refererer til bruger-id i den MySQL-tabel, hvor brugeren oprettes: users

Brugerfladen mangler desuden stadig at tilrettes i forhold til medie-fladens to muligheder: Portrait og Horisontal. Uh, man bliver helt svedt ved alle de muligheder, der stadig ligger forude. Men så vidt jeg har forstået må app'ens kildekode ikke ændres, før efter eksamen - og i den forstand er det jo - med de forskellige tids-udfordringer - desværre gået hen og blevet lidt udvikling efter vandfaldsmodel. Meningen var klart en mere agil tilgang, og når det igen bliver muligt, er det tydeligt, at udfordringerne er konkrete som resultat af review og test. Og så har jeg slet ikke nævnt den helt igennem uregelmenterede css-kodning, hvor en del af formular-indholdet skubbes med hver deres div i stedet for at høre til en fælles klasse.

Arbejdet med app'en har ganske vist været sideløbende med læsning af pensum o.a. om brugervenlighed, Nielsens huske-regler, Krugs morsomme, løftede pegefingre og meget mere af samme skuffe ... men alligevel har evalueringen afsløret graverende mangler i app'en. Og på samme tid gjort dem mulige at løse. Når alt det er sagt, tyder både test og egen gennemgang trods alt på en i primitiv forstand brugbar app. Per Thykjær Nielsen beskriver generøst data-sammenligningen med ordene:

Sammenligner - og det er lidt af en øjenåbner for mig. Programmet kan bruges til en raffineret form for evaluering, hvor elevens og lærerens forventning over for karakterer og lignende kan sammenlignes.

- Det er jo lige præcis dét, jeg er ude efter. At brugeren oplever, at der muligvis er forskel på egen og andres evalueringer, og at det kan bruges som udgangspunkt for at nærme sig hinanden, frem for at det blive en generende faktor i lærings-forløbet. Og hvis brugeren har samme oplevelse, kan det måske lægge en dæmper på oplevelsen af andre genvordigheder. Hertil skriver Nielsen og Horanger i Prioritizing Web Usability:

People don't mind clicking through multiple pages as long as each click brings them closer to the desired result. In fact, people who have a good experience on web sites think their task takes less time than it actually does. (p. 329)

Jeg har ingen data fra mine evalueringer, der bekræfter det, men håbet kunne være, at det også vil gælde indtastning af data.


Opsummering af teknisk review - genaflevering

Som Peter Urbak bemærkede, var den seneste aflvering ikke et teknisk review af eget site. Da jeg var forhindret i at komme til dagen, havde jeg ingen reviews. Per Thykjær Nielsen har imidlertid været så venlig at underkaste app'en en grundig gennemgang. Desuden så en kammerat på koden med lidt mere erfarne øjne. Jeg havde, som nævnt i posten Evalueringsplan - Genaflevering, særligt bedt om at få set på, hvor koden måske var fyldt med redundans eller unøjagtigheder ... særligt i forbindelse med den side, data skal sammenlignes.

Resultatet af de to reviews kan sammenskrives således: Brugerfladen rummer en del mulihed for forvirring. det er langtfra sikkert, at man kan anvende app'en uden forudgående instruktion. Og det er uheldigt. Der mangler forklaringer på siderne. Logikken i knapperne er desuden heller ikke helt perfekt. Det bliver bemærket, at det er muligt at overse opret. Men med lidt umage får test-personen oprettet bruger korrekt, indtastet data for både elev og underviser. Og ved sammenligning af data mellem elev og underviser, giver app'en pludselig mening. Det er bestemt værd at tage med.

Bemærkingerne i reviewet peger på dels på, hvad jeg i forvejen frygtede og dels på en nogenlunde rimelig grad af succes. Først og fremmest handler det jo om, at man skal kunne bruge app'en selvstændigt. Det kan tilsyneladende lade sig gøre. Men jeg har ikke i tilstrækkelig grad haft brugeroplevelsen for øje. Det er ikke tydeligt i hvilken rækkefølge, at app'ens funktioner skal anvendes. Men lykkedes det at oprette brugere, indtaste og sammenligne data, tyder det på, at den giver mening. Og så er det jo altid rart med lidt positive bemærkninger om de funky knapper (det er css-sprites, som jeg ikke selv er ophavsmand til).

Hvad angår de tekniske bemærkninger bliver det straks mere speget. Her er beskeden klar og tydelig: Jo, det virker, men det er ikke kønt. To eksempler er værd at nævne: Hvorfor, bliver der spurgt, bruges der ikke include i større omfang? To dele går igen på næsten alle siderne: login-forespørgsler og selve head-delen af html-siden ... foruden øverste divs. Særligt når der anvendes en include-folder, der blandt andet indeholder en blank header.php-fil. Det er en helt igennem reel bemærkning. Jeg kunne helt sikkert have gjort de enkelte sider noget kønnere med flere filer, der kunne inkluderes med fx require_once.

Men der, hvor der bliver slået hårdt ned er i forespørgslen, hvor jeg vil sammenligne elever og undervisers data. Det ser således ud:

screenshot af kode

Jeg laver to forskellige forespørgsler og henter resultaterne ind nede i html-delen ved at sætte fire variabler, der ellers ville stå tomme, indtil man beder om at se en sammenligning. Så vidt jeg kan forstå på mailen, vil det være bedre, hvis man indtaster data i relation til brugeren, der oprettes indledningsvis. Og at man kan hente data ét sted i stedet for to. Det giver mening. Men det kræver, at jeg tænker databasen anderledes. Det bliver en senere iteration, for jeg går ud fra, at vi ikke skal ændre i koden før efter eksamen. Men det vil være blandt top-prioriteterne.

Her Pers bemærkninger:

Her er en tænkehøjt-tekst efter at jeg prøvede dit site. Ideen er rigtig god - og dine knapper ser godt ud. Testperson: Per T. Jensen Lektor på Multimediedesigneruddannelsen Logger ind - ingen problemer her; men hvad er det jeg logger ind til? Det ser ud til at være noget med elever, undervisere. Og noget med at sammenligne data. Fede knapper og ikoner. Det ser helt prof ud. Men jeg er ikke helt klar over, hvad programmet går ud på. Er der et link til en hjælpende tekst? Ser menupunkterne. Jeg kan vælge en funktion. Prøver den øverste. Der kommer en "ups". Måske skulle jeg lave en elev først? Opretter så en elev. Prøver et par gange; men har overset opret. Efter at ha klikket opret virker sagerne. Nu er der en elev.
Hvad er det lige eleven skal? Går ind i "Elevens vurdering" (tænker at denne knap kunne hedde "Vurder undervisningen på et særligt elevinterface). Laver en elev, der har høje meninger om sig selv. Læreren er ikke helt enig. Her er den kognitive gennemgang: Testperson: P. Jensen cand.mag. underviser i IT Logger ind - ingen problemer her; men hvad er det jeg logger ind til? Det ser ud til at være noget med elever, undervisere. Og noget med at sammenligne data. Fede knapper og ikoner. Det ser helt prof ud. Men jeg er ikke helt klar over, hvad programmet går ud på. Er der et link til en hjælpende tekst?
Ser menupunkterne. Jeg kan vælge en funktion. Prøver den øverste. Der kommer en "ups". Måske skulle jeg lave en elev først? Opretter så en elev. Prøver et par gange; men har overset opret. Efter at ha klikket opret virker sagerne. Nu er der en elev. Hvad er det lige eleven skal?
Går ind i "Elevens vurdering" (tænker at denne knap kunne hedde "Vurder undervisningen på et særligt elevinterface, måske kunne man have to indgange - en til lærer og en til elev). Laver en elev, der har høje meninger om sig selv. Læreren er ikke helt enig. Sammenligner - og det er lidt af en øjenåbner for mig. Programmet kan bruges til en raffineret form for evaluering, hvor elevens og lærerens forventning over for karakterer og lignende kan sammenlignes. Spændende instrument; måske kunne man udbygge med en overskrift, hvor det er klart hvad der præcist evalueres. Men systemet er godt tænkt. Jeg kunne godt finde på at bruge sådan et program i min undervisning.

Her er min kammersjuks bemærkninger:

Hey, fin lille ting. MEN! Har to ting, der nok skal laves om: a) Du gentager meget af koden. Hele din html-header er fyldt med gentagelser på alle siderne. Du ser egentlig heller ikke ud til at bruge javscripten til noget?
Og hvorfor ikke brge din include-mappe til noget fornuftigt?
b) Så skiver du, om jeg vil se på den fil, der hedder data-php. Det gør jeg. Og du ser ud til at have noget rod med din database. Hvorfor to querys? Burde de ikke forhol de sig til bruger-id'en? Altså den man opretter indledningvis? I stedet spørger du to foreskellige tabeller. Det virker, men ved store forespørgsler vil det jo trække noget ned. Værd at tænke over ;-)

Oprinddelig aflevering:

25.10.2011

Opsummering af teknisk review er blevet lidt af en udfordring. Som jeg nævner i forrige post, var jeg forhindret i at deltage i de to dages workshop og teknisk review, men til al held tilbød Per Thykjær Jensen sin assistance. Netop hjemvendt fra ophold hos sundhedsvæsen og en tur til London har jeg sendt Per link til min app, og han knokler formentlig som besat med evaluering, mens han i den anden hånd jonglerer med job og privat liv. Mens jeg afventer dommen, har jeg på min side evalueret Pers plugin til astmatikere. Som et nød-alternativ er min foreløbige besvarelse af opgaven til den 23.10 derfor mine noter til det analyse-arbejde:

Inspireret af "Data Collection - Importance and Options " af Avinash Kaushik og måske også lidt af Steve Krugs "Rocket Surgery Made Easy" kaster jeg mig ud i en heuristisk analyse af Per Thykjær Jensens plugin til Wordpress. Det betyder blandt andet en nådesløs testen af alle app'ens bruger-elementer. Ret beset ville det være mere korrekt at kalde analysen hermeneutisk, idet den skal forsøge at samle et forklarligt, betydningsfuldt hele ud fra en række detaljer, der i sig selv ikke nøedvendigvis synes at bære nogen større betydning. Anyway, udstyret med link og login-oplysninger logger jeg ind på sitet. Det fører mig til admin-delen af wordpress-sitet.

I admin-delen kan jeg udføre de vanlige WordPress-aktiviteter: Jeg kan poste indlæg, uploade medier eller skrive kommentarer. Jeg kan også tilgå profil, værktøjer og kontakt. Ellers er kontrolpanelet rimeligt renset for forstyrrende elementer. En "Asthma Diary" tillader mig at indtaste data. Først og fremmest kan jeg indtaste data i form af en note. Hvis jeg ikke markerer og fjerner eller erstatter teksten "note", der fra begyndelsen står i note-feltet, tilføjes den automatisk de indhentede data.

Jeg kan tilføje data om i felterne: Cough, Wheeze, Sleep, og Activity. De er alle radio-button felter. Jeg kan desuden tilføje information i feltet Peakflow. Jeg prøver mig frem og indtaster en tekst i feltet Peakflow. Det giver et resultat i feltet nedenfor under Peakflow Indications: "Your Current peakflow: 0 It is a Red Peakflow Value - Indicates a medical emergency." Uha. Heldigvis viser det sig, at jeg har misforstået den datatype, der skal indtastes i feltet. Når jeg indtaster tal, giver den til at begynde med samme resultat. Men indtaster jeg høje tal, som fx 1200, får jeg følgende resultat: "Your Current peakflow: 1200 It is a Green Peakflow Value".

Scroller jeg længere ned ad siden, får jeg nogle meget fine grafiske fremstillinger af data i gråt, hvidt og grønt. Der er data langs y-aksen i form af tal-værdier, men ikke langs x-aksen. Jeg går ud fra, at data viser negativ eller positiv udvikling på y-aksen, mens x-aksen angiver et tidsligt forløb. Men jeg er ikke sikker. Det er muligt, at en astmatiker uden problemer forstår brugen af Pers plugin. Tallene, datatyperne og data-fremstillingerne lader til at høre til en vanlig information-kontekst for astmatikere, mens ikke-astmatikere muligvis - ligesom jeg - vil studse lidt over brugen af plugin'et.

Hvad angår placeringen af plugin'et giver det helt sikkert mening, at tilføje data via kontrolpanel-delen af WordPress. Men jeg er ikke sikker på, at jeg helt forstår, hvorfor data-fremstillingen foregår bag gardinerne. Hvis man efter indlog til kontrolpanelet klikker videre på Bloggens navn, for at se front-end delen, kan man klikke sig videre til http://multimusen.dk/your-asthma-diary:

Her finder man også en historik, der beskriver med de tidligere nævnte noter, hvordan helbredstilstanden har udviklet sig over et længere forløb. Måske der kunne ligge en fordel i at begge dele, datafremstillingen, historikken og formularen til at indføje ny data lå sammen på front-end delen? Stadig med indlog måske? Alt i alt en nem og let-tilgængelig applikation, der henvender sig til en specifik målgruppe og løser denne målgruppes behov på enkel vis. Som plugin er den desuden et venligt bidrag til andre brugere, der kunne ønske sig at holde et vågent øje med deres peakflow. Eneste forudsætning synes at være WordPress, men med et par millioner brugere burde det ikke være noget problem. Da teksten ligeledes er på engelsk, er sproget i alle fald ingen forhindring.

Evalueringsplan - genaflevering

30.10.2011

Efter kort mail-korrespondance med instruktør Peter Urbak kommer her endnu en omgang med evaluering. Som man kan se nedenfor beskrev jeg tidligere i fire punkter, hvordan jeg tænkte, at evalueringsforløb kunne tage sig ud. Men som Peter gjorde opmærksom på, tog jeg for givet, at de enkelte, der skulle evaluere, selv vidste, hvad jeg ville bede dem om at se efter i sømmene. Jeg har derfor valgt i stedet at lade evalueringen foregå i tre forløb: 1. Per Thykjær Jensen foretager et teknisk review. Det er ham helt frit, hvad han vil se på. 2. En kammerat ser på min kode. Her vil jeg særligt bede ham se på redundans og den side, der skal sammenligne data. Denne del drejer sig alene om at få afklaret om min mistillid til egen konstruktion af forespørgsler i to while-loops og om man ikke kunne have skåret siderne ud i flere dele. 3. Endelig vil jeg bede en elev bruge app'en. Her vil jeg vil følge Steve Krugs anbefalinger til billige brugertests, samt - inspireret af Jakob Nielsen og Hoa Loranger (Prioritizing Web Usability) - stille en bruger meget simple opgaver, der skal løses, mens jeg følgeer med på Skype og en elev tænker højt. 4. Til slut vil jeg som sidste besvarelse (evaluering 30.10) se på, om min app opfylder de behov, jeg har skitseret, på en under omstændigheder rimelig facon. Jeg vil i den del samle op på egne overvejelser, opsummering af teknisk review og de erfaringer, jeg har gjort mig undervejs. Her følger i lidt større detajle en plan for evalueringen:

1. Per fortæller mig, at han vil gribe opgaven heuristisk an. Det lyder spændende, og jeg forestiller mig, at han som både kritisk net-bruger, underviser i medie-faget og erfaren programmør kan afdække faldgruber uden vejledning her fra. Denne del af det tekniske review foregår altså alene på de betingelser, at jeg i en mail forklarer formålet med app'en (parentetisk) og meget kort om, hvad han kan stille op, når han er logget ind. resten står ham frit for.

2. Teknisk review med præsentation af koden. Forleden faldt jeg over en artikel i SmashingMagazine med overskriften Lessons From A Review Of JavaScript Code. Artiklen kan findes her: Smashing Mag. Pudsigt, for selv om artiklen handler om review af JavaScript-produktioner, er den i bund og grund orienteret om det samme projekt som jeg: At blive klogere på de svage led i koden. Der skulle for mit vedkommende være nok at tage fat på. Ikke alene er jeg en lallende amatør, det er også gået stærkt. Jeg er lykkelig for at princippet i app'en fungerer, men jeg er særlig opmærksom på, at jeg med fordel kunne have skåret koden ned - og undgået gentagelser. Det beder jeg en kammerat se på. Det kunne gøre det meget nemmere, når jeg vil færdigudvikle app'en at koncentrere sig om de dele, der er forudsætning for en brugbar app.

3. Brugertest. Tiden løber ud - og arbejdet (den del, jeg får penge for) tager al min tid. Jeg beslutter mig derfor for at lave en decideret overvåget brugertest. I indledningen til Prioritizing Web Usability beskriver Nielsen og Loranger arbejdet med brugertests - og den måde, de har samlet empiri til udgivelsen på. Jeg har hverken adgang til samme mængde brugere - eller ressourcer, så i stedet får jeg hjælp af en deltager, der vil arbejde sig gennem brug af programmet. Brugeren får tre opgaver: Log ind, finde selvevaluering, indtaste selvevaluering, gå til sammenligning af data, sammenligne sin selvevaluering med undervisers og til slut logge ud. Jeg har på forhånd beskrevet app'ens formål og struktur. Det ærgrer mig lidt, for et af succeskriterierne ved app'en er, at elever skal kunne betjene den uden egentlig forudgående instruktion. Og det får jeg så ikke testet her.

Den samlede evaluering skal afleveres den 30.10 (i skrivende stund: i dag!). Her ser jeg tilbage på forløbet, herunder de tre evalueringsforsøg. Evalueringen her skulle gerne give en idé om, hvad jeg får mest ud af at ændre. Som Steve Krug bemærker, kan det betale sig somme tider at være lidt doven: Men skærer ind til benet, og finder den eller de dele, man kan ændre med et minimum af indsats og et maksimum udbytte. Om det lykkedes? Tja, det kan jeg i sagens natur ikke vide endnu. Men hvis du har læst den seneste post her foroven, ved du, hvordan evalueringen tog sig ud.

Herunder oprindelig uploadet besvarelse:

25.10.2011

A. A. Milne, fader til den honning-glade Peter Plys, sagde engang: Organizing is what you do before you do something, so that when you do it, it is not all mixed up. Jep, det er lige præcis, hvad planer hjælper med. Men somme tider har verden omkring dig sine egne planer, og så er man som regel lidt på den. I mit tilfælde greb nogle ydre omstændigheder forstyrrende ind i forløbet. Det betød blandt andet, at jeg ikke kunne deltage i det tekniske review den 14. oktober. Af den grund måtte jeg ty til andre evaluerings-mulígheder. Her er en kort beskrivelse af nødplanen:

1. Teknisk evaluering: Per Thykjær Jensen var så flink at tilbyde sin hjælp. I skrivende stund tænker jeg, at han gennemgår app'en minutiøst. Jeg har al mulig tiltro til Pers evner, men de mange forskellige input, som de to arbejdsdage den 13. og 14. oktober lagde op til, må jeg under alle omstændigheder undvære. Fordelen ved de reviews ville i særdeleshed bestå i de mange kompetente medkursisters datalogiske baggrunde, som jeg selv er aldeles foruden. Altså hviler min app i Pers hænder - og som supplement forfølger jeg en kollega med programmeringsbaggrund på arbejdet for at indhente kommentarer om fx kodens overskuelighed.

2. Bruger-test: Hvad angår bruger-testen er jeg heldigvis nogenlunde klædt på. Som supplement til pensum faldt jeg over Steve Krugs Rocket Surgery Made Easy fra 2010. Krug advokerer for en så nem tilgang til bruger-test som muligt. Og i det tilfælde, at man ikke har råd til at få tests udført af tredjepart, foreslår Krug to værktøjer: Nærmeste kollega/ven eller dig selv. I mit tilfælde har jeg en sidste samtale med mine første slut-brugere på onsdag den 26. oktober. Vi har ved den lejlighed temmelig meget, der skal nås, men en del af deres lektie til næstkommende mandag er et første forsøg med prototypen af min app. Jeg er ikke helt glad ved tanken, for jeg nåede meget lidt af alle de fede ting, den app skulle kunne, men på den anden side vil jeg her få hardcore, ind-til-benet bruger-tests. At de i sidste ende og skal være slut-brugere, må jeg se bort fra. Brugerne vil ikke få nogen hjælp, men vil blive bedt om at gøre sig nogle tanker efterfølgende og beskrive deres oplevelse. Bemærkninger om evt. mangler, forslag til forbedringer og oplevelser af brugen vil være en nødvendig del af evalueringen.

3. Overvåget bruger-test: Somme tider kan man fange en kollega i ikke at lave så forfærdelig meget. Ved en sådan lejlighed vil jeg i løbet af ugens sidste dage bede dem prøve app'en, mens jeg står ved siden af og forsøger diskret at notere, hvordan de bruger app'en. Krug mere end antyder, at den slags bruger-test burde udføres løbende under udviklingen og ikke som i vandfaldsmodellen efter endt programmering. I mit tilfælde har jeg afleveret app'en. Men hvis den nogensinde skal komme til at fungere efter forventningerne, er jeg nødt til at teste den grundigt - og kode videre efter eksamen. Den er på ingen måder komplet. Til al held vil kolleger, der medvirker til at teste den, stensikkert komme med klokkeklar kritik.

4. Brug det til noget: Steve Krug slår fast, at det ikke nytter noget med fine og somme tider dyre bruger-tests, hvis det ikke fører til nogen forbedring. Men Krug er på den anden side heller ikke urealistisk. Det kan være svært og koste ressourcer at følge alle en bruger-tests forbedrings-forslag til dørs. Men som regel, hævder Krug, vil en bruger-test pege på nogle alvorlige og mindre alvorlige sprækker i designet. Prioritering er the name of the game. I mit tilfælde gælder det først og fremmest om, at brugerne skal have lyst til at bruge app'en, når det er muligt - og at de og og underviseren (i dette tilfælde mig) nemmere kan finde ud af, hvor eleven befinder sig fagligt og derudfra finde den optimale mulighed for forbedring.

Overordnet arkitektur, implementationsvalg, datamodel

09.10.2011

I artiklen "A personal statement" beskriver Joan Greenbaum fra City University of New York de problemer, der opstår, fordi udviklere og brugere lever hver ders liv og har hver deres arbejdsgange. Med et citat fra Wittgenstein minder Greenbaum om "At selv hvis en løve kunne tale, villle vi ikke være i stand til at forså den." Det samme kan man muligvis sige om undervisere og deres elever. I alle fald i dette tilfælde, hvor webapplikationen udvikles af en underviser med en hverdag på jobbet i Silkeborg, mens brugerne er 18-21 studerende i Hervey Bay, Australien, 17.500 km væk og med en hverdag, som må forventes at være radikalt anderledes. Det bør tænkes med i blandt andet implementationen og til en vis grad også i arkitekturen.

Hvad angår selve arkitekturen beskrev jeg i sidste uge, hvordan jeg tænkte mig, at den ville komme til at se ud. Herunder kan man også finde et lidt sløret foto, der fungere som wireframe til hele sitet. Som det måske kan ses på billedet foregår datahåndteringen således, at data høstes via html-formularer på php-sider. De formidler så data til en server, hvor de lagres. Endelig kan de hentes frem eller redigeres på ny efter CRUD-modellen via MySQL-forespørgsler. I en hvidbog for statslig it-forvaltning fra 2003 beskrives it-arkitektur således: "IT-arkitektur beskriver den grundlæggende organisering af et eller flere IT-systemer, herunder principper for systemernes design og udvikling og for deres indbyrdes sammenhæng.". Hvidbogen kan findes ved at klikke her. I forhold til min webapp kan det udlægges således, at arkitekturen dels er de specifikationer, jeg har beskrevet flere gange tidligere her på bloggen, organsieringen er den wireframe, man kan finde længere nede på siden her, mens designet er den iPad-safari-css3-baserede brugerflade, som skal tilgodese både en undervisers og en elevs behov i et længerevarende virtuelt undervisningsforløb. Som førstegangs-webdesigner forsøger jeg at holde mig strengt til mine egne kravsspecifikationer. Altså ikke noget med at tilføje smarte bruger billeder, når det er unødvendigt ... og ikke noget med at lave dataforespørgsler, der ikke giver mining i forhold til det specifikke behov.

For at gøre brug af Participatory design (PD herefter), er jeg nødt til at se, om brugerne kan medvirke til at bedre prototypen. Det betyder blandt andet, at de gerne skulle have mulighed for at prøvekøre app'en inden det tekniske projekt er færdigt. Det kommer til at knibe af en lang række praktiske grunde, men det er stadig en høj prioritet. Der er ingen af brugerne, der har modtaget egentlig undervisning i web-design ud over det helt basale html og css, men et par stykker er som regel udrustet med detaljeret om end meget specifik viden, som de har høstet i dere fritid. Som sådan kunne de godt tænkes at kunne tage del i udviklingen på specifikke områder.

Datamodelen er uhyre simpel. Brugere og admin (admin vil være underviseren) tilføjer data. Data hentes frem og danner grundlag for en afstemning mellem bruger og admin om brugerens status i undervisningsforløbet. Herefter må forventes en række samtaler, der ikke foregår over app'en. Herefter må forventes endnu en eller flere gennemløb, hvor bruger og admin tilføjer data og meget gerne skulle nærme sig hinanden i stigende grad. Hvis det på samme tid medvirker til at brugeren løfter sit faglige niveau ud over det, der var forventet uden brug af app'en, vil det absolut være en fordel, men ikke nødvendigvis et succes-kriterie i sig selv. Hvis app'en alene medvirker til at forholdet mellem brugerdata og admindata i stigende grad udlignes, vil det også være et succes-kriterie, idet undervisningen må forventes at glide nemmere i al almindelighed efterfølgende. Det kunne se således ud:


datamodel

Dagbogsnotat #4

02.10.2011

Som man vil bemærke er der i denne uge to dagbogsnotater på samme side. Det var egentlig ikke meningen, men tiden løb fra mig, og sådan blev det. I dette dagbogsnotat skal jeg besvare opgave #4: "Tre dagbogsnotater om vigtige udfordringer." Ok, here goes:


Notat 1: Tid i forhold til læring

Lad mig skære lige til benet med det samme: Jeg har tidligere beskrevet mine vanskeligheder med at lære php. Det skal jeg ikke uddybe igen. Men min helt overskyggende udfordring er uden tvivl tiden i forhold til at få styr på php og MySQL. Det er ingen hemmelighed, at vi alle på kurset har en del at se til i vores daglige arbejde. Og som alenefar med to teenage-unger bliver tiden lidt hurtigere brugt. Der er grænser for, hvor meget nattesøvn man vil give afkald på i min alder, så jeg har i stedet valgt at korte applikationen ned til lige præcis det, den skal bruges til. Og hvis jeg så når mere i sidste ende, vil jeg fylde funktioner på efterhånden som jeg lærer mere. Det tager sig derfor indtil videre omtrent sådan her ud med applikationen:

foto af mine post-its viser wireframe

Billedet viser en super-enkel wireframe med alle applikationens fire dele: Databasen med de to tabeller, Includes med funktioner, konstanter og lignende, Admin-websiderne som vil være synlige for admin, og endelig Bruger-websiderne som vil være synlige for den enkelte bruger. Jeg begyndte noget mere ambitiøst. Først med post-its, der skulle forestille brugeraktiviteter, så med post-its der skulle forestille muligheder og relle sider/database-tabeller. Billedet ovenfor viser applikationen i dens absolut mest minimalistiske form. Fx havde jeg til at begynde med html-sider med formularer, der så førte til en php-side hvor data blev anvendt eller reageret på. De blev hurtigt til én php-side. Og på samme måde blev bruger-aktiviteter skåret helt ned til sokkeholderne. Ikke den store interaktion her, men det kan der komme, hvis jeg når at lære nok i tide.


Notat 2: Mediets brugerflade

Det er muligvis ikke den store udfordring for en css-haj, men det er værd at bemærke, at mediet, iPad'en, tillader to fremvisningsmuligheder: Horisontalt:

ipad lodret

... og vertikalt:

ipad lodret

Som den opmærksomme læser har bemærket har jeg endda været for doven i photoshop til at vende Safari korrekt, men ud over at afsløre mig som sløset understreger det fint min pointe: Brugerfladen skal tænkes responsivt. Heldigvis er jeg ud over de helt vilde skærmstørrelse-overvejelser, men jeg har bemærket, at enkelte brugere gerne anvender fx Opera i stedet for Safari, så det må også med. Opera har ikke scoret helt vildt godt i forhold til css3-mulighederne, så også her forestiler jeg mig at skære ned til laveste fælles-nævner. Det forhindrer dog ikke, at sådan noget som fx antal af forespørgsler pr side må granskes nøje i forhold til de to fremvisningsmuligheder. Har jeg fx fem forespørgsler på samme side, vil det blive lidt presset i horisontal fremvisning, og brugeren får måske desuden problemer med at læse overskriften på de forskellige parametre. Hvis brugeren skal til at zoome for at forstå siden, er den dødsdømt fra starten.


Notat 3: Reviews

Den 13. og 14. er jeg forhindret i at møde op til blandt andet teknisk review. Ud over at det ærgrer mig usigeligt, fordi det også betyder, at jeg går glip af en række forelæsninger, betyder det, at jeg kommer til at mangle feedback fra de øvrige kursusdeltagere. Og det var måske det, jeg ville få mest ud af. De fleste af mine medkursister lader til at spise den her slags applikationer til morgenmad, og ud over at høre hvordan det smager, ville jeg naturligvis gerne vide, hvor jeg nemmest og hurtigst kunne ændre min applikation til noget, der var mere virksomt, nemmere og måske sikrere.

Jeg forestiller mig to løsninger, men ingen af dem er optimale: Først og fremmest vil jeg forsøge at trygle mig til lidt kritisk feedback, hvis en eller flere medkursister kan finde tid uden for selve de to workshop-dage. Det vil være helt igennem super. Dernæst har jeg for tiden et hold elever i Australien. Man finder ikke et mere kritisk publikum, end små 30 teenagere på den anden side af verden som alle vil føle det som et urimeligt overgreb på ders fritid, hvis de skulle reviewe en undervisers hjemmelavede app. Det kan ikke andet end være sundt for mig, hvis de kan overtales, for jeg er helt sikker på, at de vil være hudløst ærlige. For en sikkerheds skyld kunne jeg lade nogle som jeg ikke har prøve kræfter med prototypen. Det vil formentlig fjerne evt. bias.

Jeg er helt på det rene med, at man ikke kan læse sig til test af applikationers brugervenlighed. Ikke desto mindre har jeg lagt Steve Krugs "Rocket Surgery Made Easy" lige ved hovedpuden. Jeg forestiller mig, at der vil sive lidt visdom til mig om usability ligeså smertefrit om natten. Hvis det ikke lykkes, må jeg nåk knokle mig videre gennem en ellers på mange måder underholdende bog. Det burde være tørt, men er det ikke. Desværre er lette og billige bruger-tests kun den ene halvdel af problemet. Det andet, og noget mere alvorlige, er min manglende erfaring. Så lad os sige, at jeg kommer til at stå med klokkeklar viden om, hvorfor applikationen ikke virker optimalt ... det er ikke sikkert, at jeg ved nok til at rette fejlene eller kunne tænke mig en bedre løsning. Og så er vi tilbage ved de oprindelige reviews. Nå, men jeg er fortrøstningsfuld og glæder mig efterhånden til at slæbe mig gennem lidt kode.


Dagbogsnotat #3

02.10.2011

Somme tider går livet andre retninger end hen til arbejdsbordet. Og her, en uge senere end jeg burde, kommer jeg i tanke om dagbogsnotat #3. Det er lidt ærgeligt, men over de næste par linier vil jeg under alle omstændigheder forsøge at besvare opgaven "teknologier der ligner, hvor kommer inspirationen fra?". Det er ikke nogen nem opgave, for indtil jeg rent faktisk får kodet siden sammen, er det altsammen et spørgsmål om kreativ produktion - og hvor kommer det kreative incitament fra? Tidligere på ugen sad jeg og så en helt igennem fed film om amerikanske reklamers giganter og reklamens væsen. Art & Copy hed den, og jeg kan anbefale den på det varmeste. Findes på Amazon, forhåbentlig kommer den også snart på iTunes. Ikke mindst da et helt afsnit omhandler "1984"-reklamen fra ... 1984. Nå, men for at gøre en lang historie lidt kortere, åbner filmen med at forklare, hvor skræmmende det er at skulle overleve i kraft det kreative arbejde ... for hvor kommer alle idéerne fra? Og endnu værre: Kommer de også i morgen? Og dagen efter?

I denne opgave er jeg dog så heldig, at min idé udspringer af eget behov frem for en akademisk stillet opgave. Som tidligere beskrevet handler det om nemmere at kunne finde en fælles forsteålse for, hvor eleven er nået til i sin faglige udvikling. Jeg kender egentlig ikke nogen apps, der beskræftiger sig med det samme, men der er jo en lang række app's, der beskæftiger sig med evaluering. De er ikke alle lige kønne, men de fleste opfylder deres formål: At producere brugbar data ud fra brugeroplysninger. En af de mere kendte af slagsen er Survey Monkey. Den er hammer-grim, og egentlig undrer det mig, at den nyder så stor opmærksomhed. Særligt når den ikke er så nem at integrere med andre applikationer. En anden og langt mere interessant mulighed er Google Docs. Den har en ultra-let brugerflade, ingen manual-håndtering er nødvendig, og integrationen med andre applikationer er i top. Selv de lidt mere konservative Excel-entusiaster må overgive, når man viser dem, hvor enkelt data kan hentes ind live fra et spreadsheet i googleDocs til et Excel-ark.

Der er dog en forskel i forhold til det lille produkt, jeg forsøger mig med. Og det er, at app'en skal medvirke til at øge fornemmelsen af, at lærer og elev er i kontakt og kan forstå hinanden. Det skal ikke opleves som mere eller mindre bevidstløs uploading af data. Både brugerflade og brugeroplevelse skal på en eller anden måde slå det forhold fast samtidig med, at data bliver udvekslet på en hensigtsmæssig facon. Her lader jeg mig som så ofte før inspirere af sider som fx Smashing Magazine, hvor jeg blandt andet også fandt udgivelsen "The Smashing Book", hvor et glimrende kapitel omhandler grundlæggende principper for usability.

Når det kommer til system-ligheder, som jeg kan lade mig inspirere af, er jeg bange for at min egen app er alt for lille til at kunne sammenlignes med de app's man typisk ser i forbindelse med e-læring. Men jeg har da taget en rundtur på Apples iPad til Undervisning-sider. Og i forbindelse med mit arbejde bruger jeg da også gerne min egen iPad med et måske lidt mere kritisk blik, nu hvor jeg ved, at min egen app skal skæres til netop det medie.

Endelig er det tanken, at hvis min lille app kommer til at virke efter hensigten, vil jeg med tiden gerne udbygge den, så den kan indgå i undervisningen. Det kræver, at de data der tilføres via applikationen kan hentes og bruges i andre sammenhænge. Måske til løbende samtaler/evalueringer med videre. Og til det formål kunne det være fantastisk, hvis man kunne læne sig lidt op ad den senere tids gennembrud i inforgrafiske arbejde som hos fx New York Times eller som her hos GOOD.IS:

Eller som i de mange enkle og dog informative oversigter i noget, der efterhånden har udviklet sig til en typografisk sportsgren hos Vimeo:

JESS3™ / The State of The Internet from JESS3 on Vimeo.



Post en kommentar

navn:  
email: