Kapitel 1. Indledning
1.1 Hvad er informatik B
Informatik er et ret nyt fag. De første elver startede i august 2017. Baggrunden er, at vi efterhånden er storforbrugere af IT. Vi bruger IT, men IT bruger også os. Vi er nødt til at være klogere på IT i bred forstand for at forstå meget af det, der foregår omkring os.
I forhold til informatik C er der nogenlunde tale om de samme emner. Forskellen er, at i informatik B går man meget mere i dybden med f.eks. programmering og databaser.0
Link til toppen af siden.
Kapitel 2. Det grafiske puslespil
Der er mange elementer, som du skal få til at spille sammen, når du skal lave et layout eller en prototype. Kend reglerne og respekter reglerne, men være heller ikke bange for at bryde dem.
Tænk på dit layout som en god film. En opskrift på en god film kan være:
DEN GODE FILM HAR … | DET GODE LAYOUT HAR DERFOR … |
---|---|
– En eller få hovedroller | – Overskriften og/eller få elementer overstråler alt andet |
– Birollerne i et film skal være synlige. Mere synlige end statisterne, men ikke så dominerende som hovedrollen | – Under-overskrifter eller ikke-så-vigtige billeder/grafik skal være mindre end hovedoverskriften, men ikke så synlige som brødteksten |
- En god film har en eller 2 hovedpersoner. Derfor: Overskriften og/eller et dominerende billede overstråler alt andet
- Birollerne i et film skal være synlige. Mere synlige end statisterne, men ikke så dominerende som hovedrollen. Derfor: Under-overskrifter eller ikke-så-vigtige billeder/grafik skal være mindre end hovedoverskriften, men ikke så synlige som brødteksten
- Statisterne giver filmen fylde, men de er anonyme. Derfor: Brødtekst er vigtig, men må ikke overstråle overskrifterne
- I en god film er der en klar handling. Derfor: Hjælp din læser. Skru op for billeder og grafik, ned for unødvendig tekst
- En god film har orden og hiraki. Vis brugeren, hvad “hovedrolen” er, så brugeren ikke er i tvivl. Dvs. sørg for, at det vigtige træder frem. Baggrunden skal fremhæve forgrunden
I de næste 3 afsnit gennemgår jeg kort forskellige elementer inden for grafik: Typografier, farver og gestaltlove.
Link til toppen af siden
2.1 Typografier
Typografier er det samme som skrifttyper. Man kan dele alle skrifttyper ind i 2 slags skrift: Serif og sans-serif. Serif betyder “fod”. Nogle typer skrift har en lille fod på bogstaverne, andre har det ikke.
Hvis vi sætter en lille fod på bogstaverne, så danner bogstaverne en kunstig linje. Den linje hjælper os især, hvis vi laver lange tekster. Til korte tekster er det bedre med skrifttyper uden fødder. På nettet finder vi mest sans-serif skrifttyper.
Skrifttyper kan understrege vores budskab. Den her skrifttype er f.eks. meget brugt i det vilde vest i USA.
Hos www.dafont.com kan du finde en guldgrube af sjove skrifttyper, grænsende til det vanvittige.
Hvis emnet interesserer dig, så kik på artiklen her, som har undersøgt brugen af typografier på hjemmesider generelt: https://www.smashingmagazine.com/2009/08/typographic-design-survey-best-practices-from-the-best-blogs/
Link til toppen af siden
2.2 Farvelære
Vi bruger farver mere end vi tror. Farver kan hjælpe os med at understrege budskabet. Kik f.eks. på http://play.barbie.com/da-dk, hjemmeside for barbiedukken. Et orgie i bløde pastelfarver, men siden henvender sig også til små piger, ikke til voksne. Ikke overraskende er hjemmesiden for Rammstein, tysk heavyrock-gruppe, noget mere “maskulin” i sit udtryk. https://www.rammstein.de/de/. Politiet bruger kølige, alvorlige farver for at understrege autoritet, mens en klovn i cirkus er et orgie af varme og stærke farver.
Farvelære handler om at forstå farver. Start med Goethes farvecirkel. Ud fra 3 grundfarver: Rød, blå og gul dannede han alle mulige andre farver.
Farvecirklen fortæller os en masse. 2 farver på hver sin side af cirklen vil fremhæve hinanden. En orange farve fungerer godt med blå baggrund og omvendt. Dette kalder man for “kontrastfarver”. Der er dog en vigtig undtagelse: Brug aldrig kontrastfarverne rød-grøn sammen, for farveblinde kan ikke se forskel.
BEGREB | FORKLARING |
Kontrastfarver | Farver, der står overfor hinanden i farvecirklen. Kontrastfarver fremhæver hinanden |
Varme og kolde farver | Varme farver træder frem og er gode forgrundsfarver. Kolde træder tilbage og er gode baggrundsfarver. Varme og kolde farver står overfor hinanden i farvecirklen. Verdens bedste baggrundsfarve er … grå. Kik på grå beton, al grafitti træder tydeligt frem. |
Farvefamilier | F.eks. pastelfarver, jordfarver, pangfarver. Man kan skabe en god sammenhæng ved at bruge farver fra samme farvefamilie. |
Sådan ser farvevælgeren ud i Microsoft Office.
I de næste videoer kan du lære om både teoretisk farvelære og om farvelære i praksis.
Link til toppen af siden
2.3 Gestaltlovene
Når vi ser på ting, har vi nogle ubevidste måder at opfatte (eller “perceptionere) tingene på. Vi ser “skikkelser” eller på tysk “gestalter”, “hvad der er stillet i orden. Hjernen forsøger at skabe sammenhænge i, hvad den ser. Disse måder er formuleret i gestaltlovene.
Faktaboks: Hvad er en gestalt? En gestalt er tysk for “skikkelse”. Et eksempel: Vrede Viggo går i terapi, fordi han er rasende på sin far. Tereapeuten beder Viggo forestille sig, at hans far sidder i en stol overfor ham, og så får Viggo ellers lov til at fortælle hans far et par borgerlige ord. Faderen er selvfølgelig ikke til stede fysisk. Den form for terapi kaldes “gestaltterapi” |
Gestaltlovene har enorm betydning, når man laver grafisk design. Hvis man f.eks. (som på denne hjemmeside) lukker navigationen inde i en ramme, anbringer dem tæt ved hinanden og giver dem samme typografi, så opfatter hjernen alle menupunkter som hørende sammen. Det er pga. loven om lukkethed, lighed, nærhed og måske loven om symmetri. Kik selv efter.
Her er en oversigt over de 5 måske 6 gestaltlove. De 3 første, dvs. loven om nærhed (og afstand), loven om lighed og loven om lukkethed er klart de vigtigste og mest brugte.
Link til toppen af siden.
1. gestaltlov. Loven om nærhed (afstand)
“Objekter anbragt tæt ved hinanden opfattes som hørende sammen”.
Man kan udlede af loven, at ting, der er anbragt fjernt fra hinanden, opfatter vi omvendt ikke som hørende sammen.
De blå og røde cirkler opfatter vi som hørende sammen i 3 grupper. Dels står de tæt, dels er der afstand mellem de 3 grupper
Link til toppen af siden.
2. gestaltlov. Loven om lighed
“Objekter der ligner hinanden, opfattes som hørende sammen”.
Vi opfatter de røde objekter som hørende sammen og de blå som hørende sammen. Både pga. farven, men også fordi de røde har firkantede hjørner mens de blå har runde hjørner.
Link til toppen af siden.
3. gestaltlov. Loven om lukkethed
“Objekter, som er lukket inde, opfattes som hørende sammen”.
De røde cirkler til højre er lukket inde af en blå baggrund, så dem opfatter vi som hørende sammen
Link til toppen af siden.
4. gestaltlov. Loven om forbundethed
“Objekter, der er forbundet, opfattes som hørende sammen”.
De røde cirkler, som er forbundne, opfatter vi som hørende sammen. To mennesker, der holder hinanden i hånden, vil vi også opfatte som hørende sammen.
Link til toppen af siden.
5. gestaltlov. Loven om figur og baggrund
“Den mindste, afgrænsede figur på arealet vil først blive opfattet som figuren”.
Hvad ser du først? Vasen eller de 2 ansigter vendt mod hinanden? Den sorte farve er afgrænset, så på det første billede ser du ansigterne først, på det andet billede ser du vasen først.
Link til toppen af siden.
6. gestaltlov. Loven om symmetri
“To figurer, anbragt symmetrisk omkring en linje, opfattes som hørende sammen”.
Vi opfatter de 2 cirkler som hørende sammen, fordi de er anbragt symmetrisk omkring linjen.
Link til toppen af siden.
2.4 Gode råd til din grafiske produktion
Her er et par gode råd.
- Sørg for, at alt tekst er nemt at læse. Mørk tekstfarve på mørk baggrund er sjældent en god idé
- Brug kølige farver til baggrund og varme til forgrund
- Tænk på målgruppen og design efter det
- Overhold gestaltlovene
- Skab symmetri og sæt de grafiske elementer på linje
- Skab orden. Det vigtigste skal være tydeligt
- Skab genkendelighed. Genbrug farver, grafik og skrifttyper. Det gør brugeren tryg
- KISS (Keep It Simple and Stupid)
Eksempel 1. Baggrund- og forgrundsfarve
Den første er rædselsfuld. Lys tekst på en skriggul baggrund. Jeg får næsten ondt i øjnene. Nr 2 er bedre. Der er en god kontrast, men den gule baggrundsfarve dominerer teksten. Nr. 3 er god. Diskret baggrundsfarve, god kontrast og teksten får hovedrollen.
Eksempel 2. Symmetri
Ove Schneiders løbesidet. Der er INGEN symmetri. Siden er så rodet, så det nærmest er kult.
Gucci har selvfølgelig en helt anderledes orden og symmetri. Der er tænkt over hver en lille stump grafik her, og tingene er millimeter symetriske.
Skab orden og symmetri og hiraki
Her er et forslag til en AGF fanside. Det er svært at se, hvad der er vigtigst da alle skrifttyper er lige store. Navigationen er virkelig rodet. Men ok, det er en side for fanfraktionen “Tossehjørnet”, så de er tilgivet. Der er i øvrigt ingen hjørner på Aarhus Station :-).
Nu er der skabt noget orden. Overskrifterne har et hiraki, der er orden på navigationen, og der er symmetri. Dvs. at tingene er på linje eller centrerede.
Alt i alt. Kend reglerne. Du må gerne bryde reglerne, men du skal kunne argumentere for det. Et eksempel: Fodboldholdet Liverpool er et af verdens mest populære hold. De spiller i rødt. Rød er en meget varm farve, og duer som udgangspunkt ikke som baggrundsfarve. Jeg har alligevel set et fornuftigt forslag til en hjemmeside for Liverpool med rød baggrund.
Link til toppen af siden.
Kapitel 3. Forberedelser til en app
Når man skal udvikle en app, en hjemmeside eller lignende, så er der forskellige måder at indkredse det færdige resultat på. I kapitlet her skal du se et par metoder.
Link til toppen af siden.
3.1 Målgrupper
Det gælder ikke kun i IT-verdenen, at man skal tænke over, hvem modtageren er. Hvis vi vil overbringe folk et budskab, så skal vi gøre os klart, hvem målgruppen er. En af de mest brugte modeller er Minerva-modellen.
Minerva deler målgrupperne ind efter 2 akser. Moderne kontra traditionel og idealistisk kontra materialistisk. Det giver 4 områder:
- De blå: Typisk højreorienterede, vellønnede, ledere. Prestige, tro på sig selv, resultatorienteret. Måske er det ikke tilfældigt, at f.eks. Venstre har en blå partifarve.
- De violette: Typisk faglærte, men mere orienteret mod traditionelle værdier. Praktikere, orienteret mod spænding. De elsker Olsen-Banden og de traditionelle kan finde på at stemme på Dansk Folkeparti
- De rosa: Politisk midten, en del kvinder, idealister frem for materialister. Tradition, det nære miljø, familie
- De grønne: Idealister og moderne. Her har vi “økoflipperen” og folk, der typisk stemmer på alternativet eller lignende moderne og idealistiske partier . Engagement, fællesskabsorienteret, principmennesker
En sidste gruppe, du ikke finder i modellen, er de grå. De er gruppen i midten, som kan være svære at placere. De kan have kendetegn fra flere kategorier på en gang.
Link til toppen af siden.
3.2 Persona
En “persona” er en opfundet person, som gerne skulle repræsentere en typisk bruger. Man prøver på at gøre beskrivelsen så levende som muligt. Vi kan sagtens finde på at finde et billede og sætte den på personbeskrivelsen. Idéen er, at vi bedre kan gøre en side brugervenlig, når vi prøver på at gøre brugerne mere levende. Det er ikke helt forkert at beskrive en persona som en slags skuespiller.
Store hjemmesider/apps kan sagtens bruge flere persona’er. Her er 2 eksempler på tænkte persona’er, som DSB kunne bruge til deres billet app.
Persona 1. Fru Olsen
Fru Olsen er 75 år. Hendes mand døde for et par år siden. Fru Olsen er ikke så høj, men hun er ret aktiv i hverdagen. Hun bor i Kolding. Fru Olsen går til bridge og besøger veninder, og til det bruger hun sin bil. Men hendes børn og børnebørn bor i Aarhus og København, og når hun skal besøge dem, foretrækker hun at køre i tog. Bilkørsel i storbyerne er lidt for stor en mundfuld for hende.
Persona 2. Gert Gymnasieelev
Gert bor i Middelfart hos hans mor, far og hans lillesøster. Gert går i 3.g på Fredericia Gymnasium. I fritiden gamer Gert og spiller fodbold med hans venner fra folkeskolen. Gert pendler med tog. Gert er meget glad for dels Pepsi Max, dels festivaller. Når det er sommer, skal han som minimum på Skanderborg og Jelling festival.
Når man har sine personaer på plads, kan de bruges til udviklingsarbejdet. F.eks. ser fru Olsen ikke så godt, så bogstaverne i DSB’s app skal være store. Gert vil sætte pris på at vide, når Pepsi Max er på tilbud hos 7-11 på stationerne, og han vil gerne have tilbud om togbilletter i forbindelse med festivallerne.
Link til toppen af siden.
3.3 Kravspecifikation
Hvis man skal bygge et hus, så starter man med en plantegning. Det forstår både dem, der skal have et hus, og dem, der skal bygge det. Så kan man tage på ferie og når man kommer hjem, står huset præcist som aftalt. En tegning er nem at gennemskue for alle, også ikke-fagfolk.
Man formulerer de krav, som man har til en hjemmeside/app i en kravspecifiktion. Det kan både være et kort afsnit om, hvad hjemmesiden skal kunne, men det kan suppleres af prototyper, strukturdiagrammer, user stories mv. Du møder prototyper, strukturdiagrammer og user stories i de næste afsnit.
Sådan er det langt fra med apps. Her er vi nødt til at kunne snakke sammen undervejs og justere undervejs. Vi er på forhånd slet ikke så sikre på det færdige produkt, som vi er med et hus eller en madopskrift. Derfor har vi brug for, at vi kan snakke sammen undervejs og korrigere projektet om nødvendigt. Meget mere om det i næste kapitel.
Link til toppen af siden.
3.4 Strukturdiagrammer
En nem og effektiv måde at skaffe sig overblik på, er at lave en oversigt i punktform. Det gælder både, hvis man producere en ny app/hjemmeside, men det gælder også i forhold til eksisterende apps/hjemmesider. Punktopstillinger har den fordel, at det er super nemt at bytte rundt på tingene.
For hjemmesiden her kunne en punktopstilling se sådan ud: Bemærk at søgefunktionen er anbragt lidt for sig selv, for den er ikke som sådan en del af menuen.
- Forside
- Informatik C
- Lærebog til informatik C
- Emne 1. Udvikling
- Modul 1. Introduktion
- … osv
- Informatik B
- …osv.
- Søg
Indtil nu har vi fokuseret på layout. Vi vil nu kikke på funktion. Hvem skal bruge appen, og hvad skal brugergruppen kunne gøre med appen. Til det brug har vi use-case eller på dansk “brugstilfælde”.
Link til toppen af siden.
3.5 Prototyper
En vigtig brik i app udvikling er modeller eller prototyper. Prototyper er ikke et færdigt produkt. Det ligner bare det færdige produkt så meget, at både udvikler og kunde kan forstå hinanden og komme videre i projektet. Det er langt billigere at lave en prototype end at lave et færdigt produkt.
Der er frit spil i forhold til at vælge, hvordan en prototype skal laves. Det kan være en tegning, noget i PhotoShop eller endda en PowerPoint. Her er en model for boligindretning. Du har allerede prøvet at lave en prototype i PowerPoint den første gang, du havde informatik.
Link til toppen af siden.
3.6 User stories
En user story er en kort sætning, som indeholder et kundeønske til en hjemmeside. Det er meget simpelt. Man skriver en kort sætning med et udsagn. Hver sætning indeholder
- HVEM er brugeren
- HVAD skal brugeren kunne
- HVORFOR skal kunden kunne det
Lad os igen tage DSB’s hjemmeside. Her er 3 user stories, som kunne være lavet til DSB’s hjemmeside:
- User story 1. Som bruger skal jeg kunne finde en togafgang fra en valgfri station. Så kan jeg bedre planlægge min rejse
- User story 2. Som bruger skal jeg kunne se rejsens pris, så jeg ved, hvad rejsen koster
- User story 3. Som administrator skal jeg kunne redigere sidens indhold, så der altid står det rigtige
Med andre ord:
- Som … bruger (HVEM) … skal jeg kunne … finde en togafgang (HVAD) … så jeg bedre … kan planlægge min rejse (HVORFOR).
Nogle kan godt lide at lave user stories som gule sedler, der hænger på en væg:
Her er det sat op i et lille skema, så det er nemmere at overskue. Jeg har understreget HVEM, HVAD og HVORFOR
User case nr | HVEM er brugeren | HVAD skal brugeren kunne | HVORFOR skal brugeren kunne det |
1 | Som bruger… | … skal jeg kunne finde en togafgang fra en valgfri station. … | … så jeg bedre kan planlægge min rejse |
2 | Som bruger … | … skal jeg kunne se rejsens pris, … | … så jeg ved, hvad rejsen koster |
3 | Som administrator … | … skal jeg kunne redigere hjemmesiden, … | … så brugerne altid har de nyeste informationer |
På denne måde ender man med måske 10, 20 eller 100 user stories. Tilsammen udgør user stories den app, vi skal udvikle. Der må ikke være nogle funktioner på appen/hjemmesiden, som ikke findes under user stories.
Link til toppen af siden.
User stories giver dig brugergrupperne
Hvis vi er grundige nok i vores arbejde med user stories, så får vi vores brugergrupper foræret. Se i tabellen lige ovenover teksten her: Vi kan tælle 2 brugergrupper. Brugere (dvs. vores kunder) og administratorer.
Link til toppen af siden.
3.7 Sammenhæng mellem prototype, strukturdiagram og user stories
De 3 værktøjer har en god indbyrdes sammenhæng:
- I prototypen skal alle hovedmenupunterne fra strukturdiagrammet være der
- Strukturdiagrammet og user stories skal passe sammen: Alle user stories skal nemt kunne placeres ind i strukturdiagrammet
- Vigtigst af alt: Alle typer værktøjer skal være
- Nemme at forstå for både kunde og udvikler
- Nemme at producere i
- Give et godt udgangspunkt for en snak om det færdige produkts
Eksempel: I forrige afsnit var der 3 user stories:
- Som bruger skal jeg kunne finde en togafgang fra en valgfri station. Så kan jeg bedre planlægge min rejse
- Som bruger skal jeg kunne se rejsens pris, så jeg ved, hvad rejsen koster
- Som administrator skal jeg kunne redigere sidens indhold, så der altid står det rigtige
Den første er opfyldt midt på forsiden. Her kan man søge en togafgang. Nr. 2 er opfyldt, fordi man kan få en pris på rejsen, når man først har fundet den. Den sidste er ikke noget, som brugeren skal se, så lige netop her giver det mening at skjule adgangen. Ellers giver det ikke mening!
Link til toppen af siden.
3.8 Enabler stories
Enabler stories har ikke et format. De går ud på at beskrive, hvilke værktøjer der vil sætte os i stand til (= ”enable”) os til at lave produktet. Et eksempel
Eksempler:
- “Vi skal finde ud af, om vi skal bruge Wix eller WordPress til at lave hjemmesiden i”.
- ”Vi skal undersøge, om vi har adgang til PhotoShop eller om vi skal bruge gratis GIMP i stedet for til billedbehandling”.
Fordelen er, at der så kan bryde dette op i tasks. Programmøren kan sætte sig ind i biblioteker, grafikeren kan se på integration til Blender osv.
3.9 Kort overblik over værktøjer
Ud over de nævnte værktøjer findes der masser af andre værktøjer. Hvis man ser bort fra kravspecifikationen, så vil det afhænge fra projekt og fra udvikler til udvikler, hvilke værktøjer man bruger.
Her er et overblik over de værktøjer, som er omtalt i kapitlet her.
Her er et overblik over de værktøjer, som er omtalt i kapitlet her.
VÆRKTØJ | FORKLARING |
Kravspecifikation | Fortæller hvilke krav vi har til det færdige produkt. Hvis det færdige produkt er en lommeregner, er det f.eks. et karv, at den skal kunne pluser, minusse , gange og dividere osv |
Personas | En tænkt person, vi beskriver så levende som overhovedet muligt. Personen skal repræsentere en typisk bruger |
Strukturdiagrammer | En punktopstilling, som ligner en menu. Den fortæller, hvordan menustrukturen skal se ud. F.eks. forside, en side med produkter. Alle menupunkter inklusive alle underpunkter er med |
Prototyper | En skabelon af det færdige resultat. F.eks. en PowerPoint skabelon |
User stories | Man laver en lang række små historier, gerne på små gule Post-IT sedler. På hver seddel står der: HVEM skal bruge systemet, HVAD skal de bruge det til og HVORFOR skal de bruge det. Prøv så vidt muligt at se det fra brugerens synsvinkel |
Enabler stories | Har ikke et format. De handler om, hvilke værktøjer vi skal overveje /vælge, for at vi er i stand til at lave (“enable”) vores produkt. |
Link til toppen af siden.
Kapitel 4. Udviklingsmodeller
4.1 Vandfaldsmodellen
Hr. og fru MangePenge har købt en udsigtsgrund til et hus, hvor de skal bygge og bo. De hyrer en arkitektfirma, de bliver enige om hvordan huset skal se ud plus en pris. Så går byggeriet i gang. Først rydder man grunden, støber fundamentet, bygger murene, holder rejsegilde osv. osv., og til sidst får hr. og fru MangePenge nøglerne i hånden. Huset ser ud som aftalt, og alt er dejligt.
Kendetegnende for huset som projekt er, at når man først har tegningerne, så er både kunden og bygherren en rigtig god og fælles idé om det færdige resultat. Det er også kendetegnende, at man tager en ting af gangen. Man siger, at man arbejder i faser. Når først en fase er afsluttet, f.eks. hvis murene er opført, så går man ikke tilbage og ændrer på fundamentet eller tegningerne. Man går heller ikke i gang med taget, mens man støber fundamentet.
Udviklingsmetoden kaldes for “vandfaldsmodellen”. Den er kendetegnet ved, at at vi lukker en fase helt, før vi starter den næste.
Link til toppen af siden.
4.2 Agile metoder
Vandfaldsmodellen er en traditionel metode til at lede projekter. Den metode brugte man også til IT-projekter, men man stødte hurtigt ind i nogle problemer:
- Det var svært at lave udspecificeret kravspecifikation, for vi ved ikke helt, hvordan det færdige produkt skal se ud
- Udviklerne kunne støde ind i ting undervejs, der ændrede projektet. F.eks. at noget udvikling viser sig at være uforholdsmæssigt dyrt
- Det samme for kunden. Kundens behov kunne sagtens ændre sig undervejs.
- Alt i alt kunne både kunde og producent stå med en fornemmelse af, at kravspecifikationen var en klods om benet, snarere end en hjælp
Derfor begyndte man at bruge helt andre projektmodeller til IT-projekter. De kaldes “agile” metoder. “Agil” betyder “bevægelig” eller “adræt”. Kongstanken ved agile (bevægelige) metoder er, at vi skal kunne tilpasse projektet undervejs, fordi vi bliver klogere hen ad vejen. Modsat byggeri så har vi ikke fuld viden om det færdige resultat i starten af projektet, til gengæld gør det ikke noget, hvis vi laver lidt om her og der.
Måden vi gør det på, er ved at blive enige om en ramme for projektet. Typisk en kerne, som skal være i orden. Rundt om kernen nogle ting, som kunne være rare at få, men som kan ændres undervejs.
Så holder vi et startmøde med kunden og bliver enige om de første skridt, kaldet et “scrum”. Vi designer, implementerer og afprøver ligesom i vandfaldsmodellen. Det nye er, at vi allerede efter typisk 2 – 4 uger holder et nyt møde med kunden. Så tager man resultaterne op til vurdering og planlægger de næste 2 – 4 ugers udvikling.
Perioderne fra et kundemøde til det næste kalder man et “sprint” eller en “iteration”, vist med en cirkel i figuren nedenfor. Sådan bliver man ved, indtil projektet er i hus. Den tætte kontakt mellem kunde og udvikler sikrer, at projektet hele tiden justeres efter både kundens behov og de ressourcer, der er til rådighed. “Fail often, fail early”: Jo tidligere vi fanger fejlene, jo nemmere og billigere er det at rette dem.
4.2.1 Scrum
Scrum er en agil metode til projektledelse. Man kan sige, at agil udvikling er et overordnet princip for udviklingsprojekter, scrum er så en af mange metoder, hvor den agile metode gøres mere specifik. Scrum har dog status som en af de meste udbredte agile metoder.
Scrum har 4 adskildte faser: Analyse, Design, Implementering og Test. Scrum derimod fastsætter ikke nogen retningslinjer for i hvilken rækkefølge aktiviteterne skal implementeres. Et projekt kan derfor starte med en hvilken som helst aktivitet, og skifte til en anden aktivitet på ethvert tidspunkt. Dette øger projektets fleksibilitet og produktivitet. Andre punkter der kendetegner Scrum er:
- Fleksible tidsplaner
- Fleksible deadlines
- Små udviklingshold
- Hyppig gennemgang
- Objektorientering
- Samarbejde mellem udviklingshold
Model for srcum:
Ordet scrum er en term fra rugby og en forkortelse for scrummage, som har samme rod som ordet skærmydsel.
4.3 Fordele og ulemper ved vandfaldsmodeller kontra agile metoder
Fordele og ulemper ved agile hhv. vandfaldsmodeller.
VANDFALDSMODELLEN | AGILE METODER | |
FORDELE | – Velegnet til projekter, hvor vi er helt sikre på slutproduktet – Revisoren bliver glad: Det er nemt at dokumentere – Det er også nemt at placere ansvaret | – God til at fange fejl undervejs og få dem rettet .Virker meget mere fleksibel end vandfaldsmodeller – Tæt kontakt med kunden hele tiden, kunden får et medansvar – Vigtigt: Agile metoder gør det nemmere at skalere et projekts omfang. Hvis vi har svært ved at nå i mål, kan vi nemmere prioritere noget fra grundet de jævnlige kundemøder |
ULEMPER | – Kan virke stiv og gammeldags – Svært at gå tilbage og rette fejl | – Kræver mere af projektlederen, fordi man ikke har en helt så fast køreplan – Kræver høj grad af tillid mellem udvikler og kunde – Ved uenigheder kan det være sværere at placere ansvaret |
Link til toppen af siden.
4.4 Hvad ender vi så med for et produkt
Næsten alle virksomheder har et ERP system. ERP står for “Enterprise Resource Planning”. Kernen i systemet er bogholderiet eller regnskabet, men ERP systemer kan og bliver udvidet til at kunne styre næsten alt i en virksomhed. Løn, lager, produktion, fakturering, snart sagt alt. I faget virksomhedsøkonomi vil du helt sikkert støde på ERP systemer.
Vi siger nu, at en virksomheds ERP system er blevet forældet, eller at virksomheden f.eks. har købt en anden virksomhed, og at de 2 ERP systemer nu skal kobles sammen. En kæmpe opgave med et kæmpe ansvar.
Deres projekt ser sådan ud:
Hvis man styrer projektet ud fra traditionel projektledelse, dvs. vandfaldsmodellen, vil man typisk få det her resultat.
Hvis vi i stedet havde styret efter agile metoder (agil = “bevægelig”, “forandringsparat”), så havde vi fået det her resultat:
Vandfaldsmodellen er forudsigelig, men svær at tilpasse. Agile metoder er mere uforudsigelige, men nemmere at tilpasse. Agile metoder passer bedst til it-projekter, fordi både udviklere og kunde vil ønske tilpasninger undervejs. Samtidig er det forholdsvis nemt at rette i et it-projekt modsat f.eks. hvis man bygger et hus.
4.5 Agil udvikling og user stories
Den agile udviklingsmodel og user stories går rigtigt godt i spænd sammen. Lad os sige, at DSB skulle udvikle den hjemmeside, som jeg tidligere har nævnt: www.dsb.dk.
I afsnit 3.5 User stories forestillede vi os, at vi skulle udvikle en hjemmeside til DSB. Det kom der et par user stories på gule Post-it sedler ud af:
- User story 1. Som kunde skal jeg kunne finde en togafgang fra en valgfri station. Så kan jeg bedre planlægge min rejse
- User story 2. Som kunde skal jeg kunne se rejsens pris, så jeg ved, hvad rejsen koster
- User story 3. Som administrator skal jeg kunne redigere sidens indhold, så der altid står det rigtige
- User story 4 …
- User story 5 …
I virkelighedens verden vil der selvfølgelig komme måske 30, 40 eller flere user stories ud af det. Nu forestiller vi os så, at vi skal holde det første møde med DSB, og at vi arbejder efter den agile udviklingsmodel. Vores user stories er vores kravspecifikation, så vi er nået til det første runde med Design. Dvs. vi holder møde med kunden, det første af mange kundemøder i den cirkulære del af modellen.
Her aftaler man sammen, hvilke user stories man vil prioritere. Det er f.eks. user story 1, 3, 4 og 7.
Ved næste designmøde kikker man på implementeringen og diskuterer igen user stories. Det kan sagtens være, at DSB så er kommet i tanke om, at de har et par krav mere. Så laver man flere user stories, der svarer til kravene, f.eks. user story 55, 56 og 57. Af disse 3 er user story 56 og 57 meget vigtige, så de kommer forrest i køen og bliver udviklet inden næste møde.
Hver gang, man mødes til et designmøde, så gennemgår man user stories og priorieter. På et tidspunkt stopper man og udgiver produktet. Det kan sagtens være, at man ikke har implementeret alle user stories, men det kan måske ikke betale sig.
Link til toppen af siden.
Kapitel 5. Brugervenlighed og test
Kapitel 5 handler om, hvordan vi kan lave et brugevenligt design og teste vores apps af.
5.1 Interaktionsdesign er vigtigt
Interaktionsdesign handler om, hvordan du “inter-agerer” eller samarbejder med et produkt. Jeg tænker her ikke på en ny køkkenkniv, men et produkt, hvor 2-vejs kommunikation er mulig. Jeg gør noget og får et svar fra produktet. Næsten alle digitale produkter kan lave 2-vejs kommunikation.
Du ved allerede en del om interaktionsdesign fra kapitel 3. Din viden om typografier, farvelære og ikke mindst gestaltlovene gælder stadigvæk.
Der er mange penge i godt interaktionsdesign. Tænk på, hvor meget personale det f.eks. sparer, at flypassagerer efterhånden kan tjekke ind selv uden hjælp.
Nødvendigheden af godt interaktionsdesign kan opsummeres sådan:
- Web sider, apps og andre digitale produkter bliver skabt for at blive brugt og for at skabe en mer-værdi
- Derfor er fokus på brugeren og brugen rigtig vigtig
- Et website, app eller lignende er et stykke værktøj der kan hjælpe med at løse en opgave
- Hvis værktøjet ikke kan løse opgaven, er det et dårligt stykke værktøj
- Et dårligt stykke værktøj giver utilfredse kunder
- Utilfredse kunder finder et nyt stykke værktøj
Link til toppen af siden.
5.2 Brugervenlighed ud fra Normans 6 designprincipper
Der er rigtigt mange tilgange til, hvad brugervenlighed er. Donald Normans grundide er, at et produkt både skal være indbydende, fungere korrekt og være nemme at bruge. Norman har udarbejdet 6 principper for brugervenlighed.
- Visibility/synlighed
- Constraints/begrænsninger
- Affordance/indbydende
- Mapping/overblik
- Consistency/overénsstemmelse
- Feedback/tilbagemeldinger
KIlde: Norman, A. D (1988): The Design of Every Day Things. Basic Books
5.3 Jacob Nielsens 5 principper for brugervenlighed
Norman er langt fra den eneste, som har udarbejdet anerkendte principper for brugervenlighed. Mange andre har gjort ham kunsten efter, f.eks. danskeren Jacob Nielsen, som har 5 principper:
- Nem at lære
- Effektivt at bruge
- Nemt at huske
- Feedback på fejl
- Tilfredsstillende at bruge
Jeg anbefaler dog, at du som udgangspunkt bruger Normans principper. Jacob Nielsens principper er dog et fint supplement til Normans principper.
Link til toppen af siden.
5.4 Gestaltlovene
Du spørger måske, hvor gestaltlovene er henne i forhold til principper for brugervenlighed. Svaret er, at gestaltlove er love for, hvordan vi opfatter vores omverden. Hvis du overholder gestaltlovene i dit design, så kan man sige, at det kommer ind under både princip nr. 1 om visibility/synlighed, princip nr. 3 om affordance/indbydende og princip nr. 4 om mapping.
Link til toppen af siden.
5.5 Flere love om design og brugervenlighed
Her er et par love, som du med fordel kan anvende, når du designer. Lovene kommer igen alle ind under Normans principper, men lovene er mere specifikke og derfor nemmere at følge:
Fitts lov
Fitts lov siger, at
- Jo større et mål er, jo hurtigere/nemmere er det at ramme
- Jo tættere målene er på hinanden, jo hurtigere/nemmere er de at ramme
Hvis vi vil øge brugervenligheden på et produkt, skal vi derfor lave knapperne store og placere dem tæt. Det kommer ind under Normans princip nr. 1 visibility/synlighed og nr. 4 om mapping/overblik.
Link til toppen af siden.
Hicks lov
Hicks lov siger, at jo flere valgmuligheder vi har, jo længere tid/sværere er det at tage en beslutning.
Hvis vil øge brugbarheden på et produkt, skal vi derfor begrænse valgmulighederne og evt. lave et hiraki. Det sidste svarer til, at vi i stedet for 15 punkter i hovedmenuen måske kun har 5, mens resten bliver til underpunkter. Det svarer til Normans princip nr. 2 constraints/begrænsninger og nr 4 om mapping/overblik.
KISS
KISS står for Keep IT Simple and Stupid. Gør det nemt for brugeren. Eller som forfatteren Steve Krug udtrykte det i en bog “Don’t make me think”.
Gør det nemt for brugeren. Jo mindre brugeren skal tænke, jo hurtigere og jo bedre. Hos Norman kommer det ind under princip nr. 2 constraints/begrænsninger og nr 4 om mapping/overblik.
Link til toppen af siden.
FTF
FTF står for “putting First Things First”. Læg det, som brugeren har mest brug for, forrest i menuen. Kommer ind under Normans princip nr. 1 visibility/synlighed og nr. nr 4 om mapping/overblik.
Link til toppen af siden.
5.6 Tips til at gøre din app/hjemmeside mere brugervenlig
Her er en lille styleguide med tips til brugervenlighed, som du med fordel kan anvende i dit daglige arbejde når du designer en app/hjemmeside. Alle tips kommer dog ind under Normans principper.
- Placer altid menuen og overskriften det samme sted på siden
- Overskriften på siden skal altid hedde det samme som menupunktet. Klikke du på menupunktet “Kontakt”, så skal den side, du lander på, have overskriften “Kontakt” og intet andet
- med forsiden som en mulig undtagelse
- Overskriften skal have de største og mest synlige skrift på hele siden
- Overskriften skal stå højt på siden og det samme sted hver gang
- Du skal kunne navigere videre fra alle sider til alle sider
- Alle link er understreget eller på anden måde markeret som link, så de skiller sig tydeligt ud fra resten af teksten
- Kontaktoplysninger kan med fordel stå nederst
- Tydelige og forståelige fejlmeddelelser
Link til toppen af siden.
5.7 Involver brugerne
“Operationen lykkedes, men patienten døde”
Ovenstående citat er skrækscenariet. Vi laver en god løsning, men den er ubrugelig.
Som designere mister vi meget hurtigt vores “jomfrulighed” over for det, vi designer. Vi bliver til eksperter frem for brugere. Det gælder for interaktionsdesign som for skriftlige opgaver: Man bliver blind på det, man selv laver.
Samtidig har brugerne har enorm magt inden for den digitale produkter, og de vælger os fra, hvis vi skaber bøvl for dem. Ved webshops er konkurrenterne f.eks. kun et klik væk. Så der er alt mulig grund til at involvere brugerne fra start. Det har vi forskellige måder til.
I kapitel 4 Udviklingsmodeller lærte du om, at vi inden for IT foretrækker agil udvikling frem for den traditionelle vandfaldsmodel.
Fordelen ved den agile model er, at den giver bedre mulighed for at korrigere projektet undervejs. Den giver også bedre muligheder for at involvere brugerne. Afprøvning kan fint finde sted med brugerne. En gren af agil udvikling kaldet “extreme programming” kræver direkte, at udviklerne sidder i samme lokale som brugerne.
Vigtigt: User stories er en rigtig god måde at involvere brugerne på. Især hvis det er brugerne selv, som skriver user stories.
Link til toppen af siden.
5.8 Brugertest og systemtest
Vi bruger mange metoder for at nå og forstå både kunder og brugerne. Gentagne møder med brugere og kunder som i den agile udviklingsmodel er kun en af flere muligheder, vi har
- Prototyper. Protyper er mini-udgaver af det færdige resultat. En god prototype kan give en god dialog med brugerne
- Teste undervejs
Der findes forskellige brugertest. Du skal kende disse typer test.
- Eksperttest eller heuristisk test
- Tænke-højt test
- Kvantitative test
Der er forskel på brugertest og systemtest I en systemtest tester vi for, om et system virker som aftalt Hvis vi tester, om vores knapper og links virker, så er det en systemtest På DSB’s hjemmeside www.dsb.dk kunne vi f.eks. tjekke, om der er muligt at købe en billet fra Kolding til Odense. I en brugertest involverer vi brugerne. En brugertest på DSB’s hjemmeside kunne være, om brugerne kan finde ud af at købe en billet fra Kolding til Odense |
Eksperttest
En eksperttest eller heuristisk test er såre simpelt. Det er, når du tester dit eget arbejde. Det er nemt, billigt og effektivt, men det kan ikke stå alene.
Tænke-højt test
Tænke-højt test er en test, hvor man stiller brugere forskellige opgaver. Lad os tage DSB som eksempel. Brugeren får til opgave, at de skal være i Nykøbing Falster i morgen kl. 12. Hvilket tog skal de tage og hvad koster billetten.
Brugeren tænker så højt, f.eks. “Hm, først vil jeg åbne DSBs hjemmeside”. “Mon der er en billetknap, næeh, jeg klikker her i stedet …”. Designerne er så bag brugeren og lytter med. På den måde lærer de, hvordan brugeren opfatter programmet.
Tænke-højt test er helt fantastiske til at gøre os klogere på brugernes adfærd, og f.eks. Microsoft har dyre lokaler indrettet specielt til tænke-højt tests. Men de kan være dyre at gennemføre. Især hvis man ønsker et bredt udsnit af brugerne.
Tænke-højt test og user stories
Når man laver tænke-højt test, er det super oplagt at tage udgangspunkt i user stories. Fra afsnit 3.5 User stories har vi et antal user stories
- User story 1. Som kunde skal jeg kunne finde en togafgang fra en valgfri station. Så kan jeg bedre planlægge min rejse
- User story 2. Som kunde skal jeg kunne se rejsens pris, så jeg ved, hvad rejsen koster
- User story 3. Som administrator skal jeg kunne redigere sidens indhold, så der altid står det rigtige
- User story 4 …
- User story 5 …
Vi vil så typisk tage udgangspunkt i de højest prioriterede user stories og bruge dem til en tænke-højt test. På den måde sikrer vi os, at vi får lavet et produkt, som brugerne kan anvende.
Link til toppen af siden.
Kvantitative og kvalitative test
Kvantitative test er hårde fakta, f.eks. tal. Man indsamler ofte data gennem et spørgeskema uden direkte kontakt til kunderne. Vi forsøger på at MÅLE tingene.
Kvantitative test er spørgsmål til følelser, fornemmelser o.lign. Vi forsøger at BESKRIVE tingene snarere end at måle og beskrive tingene statistisk.
Forskellen på kvantitativt og kvalitativtKvantitative data er data, er kan måles, vejes og efterprøves. Dvs noget objektivt. Modsat er kvalitativt er en personlig oplevelse, dvs. noget subjektivt. Et eksempel. HviiiViggo og Finn Fakta er AGF fans og til fodbold og ser DeHviiii spille. – HviiiViggo: “Add, gult er bare SÅ grimt” – Finn Fakta: “Ja, gult kan godt skære i øjnene, når det er en forgrundsfarve” – HviiiViggo: “Kæft hvor ham BUNDBYtræneren er grim og dum” – Finn Fakta: “Han ser lidt ubarberet ud” HviiiViggo er selvfølgelig den subjektive/kvalitative, mens Finn Fakta er den objektive/kvantitative |
Link til toppen af siden.
A-B test eller splittest
A-B test eller splittest er en meget anvendt måde at teste på. Det går ud på, at man deler (= “splitter”) sin gruppe op i 2 normalt cirka lige store dele. Den ene del udfører man testen på. Det kunne være, om de køber mere af en bestemt vare på en webshop efter en kampagne. Den anden del af gruppen er kontrolgruppe.
Når testen er ovre, sammenligner man resultaterne for de 2 grupper.
Link til toppen af siden.
5.9 Opsummering. Tjekliste til app udvikling
Brug agil udvikling
- Agil udvikling giver mulighed for at ændre produktet undervejs, og det får vi brug for
Kort beskrivelse af din idé
- Hvad er ideen med app’en/hjemmeside
- Hvordan skal den gøre en forskel
- Hvilken målgruppe sigter vi efter
Design
- Involver brugerne om muligt
- Brug din viden om det grafiske puslespil inklusive gestaltlovene, når du designer
- Tag udgangspunkt Normans designprinciper
- Anvend love for brugervenlighed f.eks.
- Hicks lov: Store knapper er nemmere for brugeren at ramme end s,
- Fitts lov: Få valgmuligheder er bedre end mange
- KISS: Keep it Simple and Stupid
- Måske den vigtigste: FTF, putting First Things First
- Hvis relevant: Lav et strukturdiagram
- Hvis relevant: Lav en prototype
Link til toppen af siden.
User stories
- User stories er altid relevante, og bør være i centrum for al udvikling
- Lav user stories, og lav gerne mange af dem
- I hver user story skal der stå:
- HVEM er brugeren
- HVAD skal brugeren kunne
- HVORFOR skal kunden kunne det
Agil udvikling med user stories
- Sammen med kunden prioriter user stories. Hvilke er de vigtigste
- Involver brugerne om muligt
- Udvikl de vigtigste og udvikl dem
- For hver gang, man kører en “runde” i den agil udvikling, mødes man og prioriterer, hvilke user stories som skal udvikles først
- Kunden må gerne medbringe nye user stories til næste møde. Vi er der for brugernes skyld!
Link til toppen af siden.
Test din produkt af
- Anvend både system- og brugertest
- Involver brugerne om muligt
- Brug gerne både kvantitative og kvalitative test
- Tænke-højt test er den mest besværlige. Men den er også den bedste måde at teste produktet på
Link til toppen af siden.