Dagen startede ud med introduktion ved Marc, Rasmus og Freja. Andrea var også kort forbi og hilse på (han er på barsel pt). Der blev serveret pizza og sodavand.

Vi faldt hurtigt i snak i gruppen og fik også planlagt fremtidige møder:

• 7. oktober 2025 kl. 11.30
• 21. oktober 2025 (Semester 1. – projekt 1 pitch, formiddag)
• 17. november 2025 kl. 11.30 (online)
• 21. november 2025 (Semester 1 – projekt 2 – udstilling)
• Projekt 3 møde – dato aftales nærmere når eksamensdatoer er kendt)
• Juleafslutning på Storms – dato aftales når vi nærmer os.

Mødeprotokol:

https://365ucl.sharepoint.com/:x:/r/sites/multimediedesign-aug/_layouts/15/Doc.aspx?sourcedoc=%7B589548C3-39DD-4E39-A603-235D09E046D3%7D&file=Studiemakker%20grupper%20og%20deltagelse%20-%20E25-E24.xlsx&action=default&mobileredirect=true

Jamie i gruppen havde godt styr på Discord, så han oprettede vores rum på discord: https://discord.gg/takzXcKu

Projektleder er Nicoline.

1. semester spurgte nysgerrigt ind til uddannelsen, lektiemængde, projekterne og vores oplevelser og vi havde en god snak om det. Vi snakkede også om metoder for, hvordan man får læst op til eksamen, hvad der er vigtigt at have styr på fra starten (ens procesportfolio) m.m.

Der blev også snakket om at vi på 3. semester skal lave en opgave, som 1. semester skal teste for os. Vi skal individuelt lave en bot og det bliver så interessant, hvordan jeg kommer i gang med det, så det vil jeg i gang med at undersøge.

Møder i oktober (7/10, 21/10, 30/10 )

7/10: Vi mødtes på skolen, hvor vi på 3. semester skulle give feedback på 1. semesters projekt.

21/10: Vi skulle høre 1. semesters Pitch1. Glemte at tage billeder af dagen. Vi fra 3. semester var med til at give feedback. De fleste havde gjort et godt stykke arbejde og tænkt over de valg de havde truffet i.f.t. design og content.

30/10: Test af BOT – Kagemysteriet (3. semester opgave). Testen gik fint, og ligesom jeg selv syntes 1. semester også at det var ærgerligt at billederne ikke kunne komme frem på Botten – det havde gjort meget visuelt ved spillet, da billederne spiller en central rolle i spillet.

Opgaven omkring at lave en Bot var faktisk rigtig sjov og er sandsynligvis noget jeg gerne vil arbejde meget mere med i fremtiden.

4/11: Fremlagde Botten på 3. semester.

Møder i november (17/11, 19/11 og 21/11)

17/11: Vi mødtes online, hvor vi til en start lige havde en snak rundt om bordet om hvordan det går, hvad har vi hver i sær gang i, de faglige udfordringer og ikke mindst hvordan det går med 1. semesters projekt 2.

19/11: Vi mødtes på Storms Pakhus for lige at snakke lidt om hvordan det går med projekt 2 og hvordan de trives på studiet. Vi havde et par hyggelige timer sammen.

21/11: 1. Semester havde udstilling af deres projekt 2- Installationsprojekt. Deres klient var Word Festivallen. Der var mange forskellige og spændende idéer.

Møder i december – juleafslutning

Datoen er ej fastlagt endnu, men bliver aftalt når vi alle kender vores datoer for eksamen. Vi har aftalt at vi skal ud at spise på Storms Pakhus.

Refleksion

Det har været lidt sjovt at være 3. semester og den “erfarne”. Det føltes jo ikke som om det er særligt lang tid siden man egentligt startede på uddannelsen. Så tiden er fløjet af sted.

Vores studiemakker-gruppe har fungeret rigtig godt. Vi har kunne tale om rigtig mange ting og har haft en åben og ærlig dialog om alt lige fra hvordan det går på studiet, privat og hvilke udfordringer livet nogle gange bringer til bordet.

/wp-content/themes/astra-child/

/*
Theme Name: Astra Child
Template: astra
*/

<?php
function astra_child_enqueue_styles() {
    wp_enqueue_style('astra-parent-style', get_template_directory_uri() . '/style.css');
}
add_action('wp_enqueue_scripts', 'astra_child_enqueue_styles');

Modern Javascript Development

SASS

Der er mange mulighederne med SASS og SCSS, hvilket er relevant, hvis man arbejder med stylesheets i multimediedesign-arbejde og vil effektivisere og strukturere CSS-koden bedre. Ved brug af Sass opnår man et mere effektivt og ensartet webdesign.

Selvom CSS og Sass teoretisk set har de samme funktioner, kan Sass udføre det samme arbejde med mindre kode. 

Sass tillader variabler og kodestykker, der kan genbruges igen og igen, hvilket sparer en masse tid og reducerer risikoen for kodefejl, men gør det også nemmere og hurtigere at ændre stilarter flere steder i koden, f.eks. rammestørrelser, kantstilarter, farver osv.

Sass er et præprocessorsprog, der fortolkes til CSS. Et præprocessorsprog tager inputdata og konverterer det til output, der bruges som input af et andet program. Det betyder, at når du kører Sass-kode, konverterer du faktisk din kode til CSS. Den CSS-kode, der genereres, bruges derefter direkte af en browser. Hvorfor dette ekstra trin med at konvertere fra Sass til CSS? Fordi browsere kun kan læse CSS-kode.

SASS (Syntactically Awesome Stylesheets) er en CSS preprocessor – altså et værktøj, der udvider CSS med funktioner som variabler, funktioner, nesting, mixins m.m.

SCSS er den mest brugte syntaks for SASS – den ligner almindelig CSS, men med ekstra funktionalitet.
Den anden syntaks (klassisk SASS) er mere “kortfattet”, men sjældnere brugt i dag.

SASS vs SCSS	Forklaring

.sass

Indrykningsbaseret (uden {} og ;)

.scss

CSS-lignende syntaks (med {} og ;) – mest brugt

FORDELE MED SASS/SCSS

• Gør det nemt at genbruge værdier (fx farver, skrifttyper, afstande). (Variabler)
• Skriv CSS mere struktureret, så det følger HTML-strukturen. (Nesting)
• Split din CSS op i mindre filer med _nav.scss, _footer.scss osv. (Modulopdeling/Partials)
• Genbrug af kode med mulighed for parametre – lidt som funktioner i JS. (Mixins)
• Del fælles CSS-styles mellem elementer. (Inheritance)
• Regn på værdier og lav egne funktioner. (Funktioner/operationer)

Vi vil bruge SCSS.

Variabler er genbrugelige værdier. De gør det nemt at sikre ensartede værdier. Variabler starter med dollartegnet: $ Variabler kan bruges alle steder i koden efter de er sat, men bør altid være først i dokumentet.

• Eks: $navFontSize: 16px;

Nesting er en god måde at samle kode der har en forbindelse med hinanden.

Partials inkluderer delvise filer, der tilsammen definerer hele projektet. Når en partial starter med underscore _
vil filen ikke blive processeret til en CSSfil, men kun inkluderet i filen der inkluderer den. Use er smart til at yderligere splitte koden op.

Mixins er små bidder af kode der kan genbruges. Mixins kan holde værdier, der senere kan inkluderes gentagne gange i koden.

Brug kun mixinssammen med argumenter/parametre

Farvemanipulation darken (regnes i procent), lighten (regnes i procent) og rgba (regnes ligesom i CSS som
kommaværdi) I stedet for at skrive farve, kan du bruge hex, rgb eller variabel.

Andre måder at manipulere: saturate, desaturate, adjust-hue, tint, shade

Opgaver:

GDPR

Almindelige vs. Følsomme personoplysninger

• Almindelige oplysninger: Navn, e-mail, adresse, telefonnummer, IP-adresse osv.
• Følsomme oplysninger (kræver ekstra beskyttelse):
  • Helbredsoplysninger
  • Politisk, religiøs eller seksuel orientering
  • Etnicitet
  • Fagforeningsforhold
  • Biometriske data (ansigtsgenkendelse, fingeraftryk)

Design-implication: Overvej hvilke oplysninger der indsamles via formularer, cookies eller login.

Strukturerede vs. Ustrukturerede data

• Strukturerede data: Data lagret i systemer/databaser (fx formularindsendelser, CMS-brugerdata).
• Ustrukturerede data: Data i dokumenter, e-mails, noter, billeder med metadata osv.

Design-implication: Noter, beskeder eller gemte billeder med personoplysninger tæller som data under GDPR.

Databehandling

Databehandling er alt, du gør med persondata, fx:

• Indsamling
• Opbevaring
• Analyse
• Deling
• Sletning

Design-implication: Hvis man bygger en kontaktformular, laver brugerlogin eller tracker brugere med cookies, behandles data og reglerne skal følges.

God databehandlingsskik

• Indsaml kun det nødvendige (dataminimering)
• Gør formålet klart (hvorfor indsamles data?)
• Giv brugeren indsigt og kontrol (samtykke, indsigtsret, ret til sletning)
• Beskyt data (brug SSL, kryptering, adgangskontrol)

Design-implication: Tænk privacy by design – brugervenlige løsninger, der informerer og respekterer brugerens rettigheder.

Hjemmel (lovligt grundlag) for databehandling

Du må kun behandle persondata, hvis du har en gyldig hjemmel. De mest relevante for dig som designer:

• Samtykke: Brugeren har givet aktivt og informeret ja (fx til nyhedsbrev eller cookies).
• Kontrakt: Data er nødvendige for at opfylde en aftale (fx køb i webshop).
• Lovkrav: Du er lovmæssigt forpligtet (fx opbevaring af fakturaer).

Design-implication: Samtykke skal være frivilligt, tydeligt og nemt at trække tilbage

Husk som multimediedesigner:

• Design gennemsigtige løsninger (informer brugerne)
• Indhent gyldigt samtykke, hvor nødvendigt
• Behandl kun data, der er relevante og nødvendige
• Sørg for sikkerhed i dine løsninger
• Dokumentér, hvad der sker med persondata

Som multimediedesigner er man ikke nødvendigvis ansvarlig for hele datasikkerheden alene – men man har ansvar for, at ens design og ens løsninger ikke udsætter brugernes persondata for risiko.

• Brug HTTPS (SSL-kryptering): Vælg en hostingløsning med SSL-certifikat (ofte gratis via Let’s Encrypt) eller tving HTTPS via .htaccess eller serveropsætning.
• Indsaml ikke mere data end nødvendigt.
• Valider input og beskyt formularer. Brug type="email" og required i HTML, alternativt brug server-side validering i PHP, JS eller frameworks eller brug CAPTCHA ved behov (men pas på UX)
• Adgangsstyring ved at bruge adgangsroller (fx “bruger”, “admin”)
• Håndtering af brugerdata ved at lave tydelige muligheder i dit design f.eks. “Rediger profil”, “Slet konto” m.fl.
• Cookies og tracking – informer og indhent samtykke ved hjælp af værktøjer som Cookiebot eller Klaro.
• Beskyt brugeradgang og login ved at lave nogle sikre password-politikker (min. længde, tegnkrav) eller 2-faktor-login.
• Sletning og opbevaring af data ved at planlæg hvornår og hvordan data slettes, hvis brugeren fx ikke er aktiv.
• Brug automatiske sletninger eller arkivering, hvor det er muligt.

Det er ligeledes værd at nævne: EU Digital Wallet, som blev godkendt i efteråret 2023. Det er en digital identitetsapp, der gør det muligt for borgere i EU at identificere sig sikkert online og få adgang til offentlige og private tjenester i hele EU. App’en kan indeholde kørekort, uddannelsesbeviser, sundhedsdata, bankoplysninger m.m. EU planlægger fuld udrulning i 2026. Danmark deltager gennem initiativer som MitID og Digitalt Kørekort, som på sigt skal integreres.

Værditilbud:

Calling Nature skaber håndlavet, naturlig og vegansk vingummi og lakrids uden kunstige tilsætningsstoffer. Vores produkter er gluten- og laktosefri og fremstillet i små batches for at sikre høj kvalitet og autentisk smag. Med rene ingredienser og omtanke for både mennesker og naturen tilbyder vi et sundere, mere ærligt alternativ til konventionelt slik – uden at gå på kompromis med smagsoplevelsen.

2. VALUE PROPOSITION CANVAS – selvstændig multimediedesigner – (fokus: frontend / web)

Jeg hjælper små og mellemstore virksomheder med at få moderne, tilgængelige og brugervenlige hjemmesider.
Uanset om du skal starte fra bunden, opdatere din nuværende side eller sikre, at din hjemmeside overholder tilgængelighedskrav, tilbyder jeg teknisk ekspertise og personlig rådgivning.
Jeg gør det let for dig at få en professionel og effektiv online tilstedeværelse.

Advanced Interface Design Techniques

Tilgængelighed, Mikro-interaktioner, Progressive Disclosure, Adaptive User Interface

Forskellige typer af funktionsnedsættelse:

• Visuelt
• Motorisk
• Kognitivt
• Audiotivt

Autistiske er gode til at teste en hjemmeside, da de tænker logisk og struktur.

EAA – European Accessibility Act – WCAG 2.1 – POUR-principperne

• Perceivable
• Operable
• Understandable
• Robust

.Brug test-platforme: Lighthouse, Wawe, se evt. digitaliseringsstyrelsens hjemmeside. Ligeledes: NVDS (gratis), JAWS(betalingsprogram med flere features) og VoiceOver – programmet gennemgår hjemmesiden med en skærmlæser.

OBS – Fokusindikator på en hjemmeside /eksamensprojekt vil vise, at det har man styr på.En slider er ikke altid en god idé på en hjemmeside, da det kan være svært for folk der ryster på hånden at ramme den korrekt, det er nemmere at lave en boks hvor folk selv indtaster hvad der skal stå i boksen fremfor slideren.

PDF’er er ofte ikke tilgængelige – den skal opmærkes korrekt i Adobe, der er mange virksomheder der ikke er up-to-date på dette.

TIP: A11Y-kurser – online kurser (koster penge, men Freja vil undersøge om vi kan få tilskud).

Indhold på en side: Visualisering, grafik og kort tekst – læselighed som en 8. klasse .

Se Laws of UX: Visuelt design: Farver, typografi, Tap targets (Fitt’s law), Interactive states (fokusknapper), ergonomic layouts (det skal være tilgængeligt ift eksempelvis skærmlæsere).

Mikro-interaktioner – f.eks. at man har valgt flere varer i en kurv, så vil der komme systemrespons med at man har valgt xx antal varer. Andet eksempel er sign up- siden for mail-chimp. Den kommer med advarsler når f.eks. password ikke opfylder kravene. Det kan også være et ikon der bevæger sig. Se Remembear og Duolingo.

• Systemrespons
• Bruger interaktion
• Nem brugeroplevelse
• Forebygger fejl
• Brandpersonlighed/engagement

Nyhedsbrev: NNgroup

Komponenterne af mikro-interaktioner: The Trigger, The Rules, Feedback og Loops & Modes.

Progressive Disclosure – et designprincip, hvor komplekse brugergrænseflader håndteres ved at informationerne/funktionaliteterne præsenteres gradvis f.eks. ved en “proceslinjen” for håndtering af afgivelse af en ordre

• Fokus på kernefunktioner
• Human-Centered Design
• Gradvis afsløring
• Kontekstbasereret

Brug google analytics, brugerundersøgelser som argumentation for hvorfor progressiv disclosure er en god idé.

Adaptive UI – brugergrænsefladen er dynamisk og tilpasser sig og reagerer på brugerens adfærd og kontekstuelle faktorer, altså data fra bruger bliver brugt af systemet. Adapterbart UI er hvor brugeren laver ændringerne selv.

Advanced Graphic Design

Opsummering af EAA – European Accessibility Act – WCAG 2.1 – POUR-principperne

• Perceivable
• Operable
• Understandable
• Robust

Perceivable – Eksempelvis skal der være alternativer til tekst til indhold der ikke indeholder tekst f.eks. billeder, det skal være muligt for brugeren at se indholdet trods skærmrotation og der skal anvendes korrekt kontrast (ratio 4:5:1).

Operable – Eksempelvis skal alle funktioner være tilgængelige via keyboard, navigationen skal indeholde overskrifter og fokusindikatorer og man skal have defineret størrelsen på knapperne.

Understandable – Eksempelvis sørg for at teksten er læsevenlig, lav klare instruktioner, fejlmeddelelser og sørg for at interaktionsmønstret er det samme på alle sider, så det er forudsigeligt for brugeren.

Robust – Eksempelvis gælder dette især brugere der anvender skærmlæsere. Det er vigtigt at der i koden er angivet tekst for komponenterne og statusbeskeder skal også være sat op i koden.

7 elements of design

Behavioural Economics

Behavioural Economics (adfærdsøkonomi) beskæftiger sig med, hvordan menneskelig adfærd påvirkes af psykologiske, sociale, emotionelle og kognitive faktorer – og hvordan disse ofte strider mod klassisk økonomisk teori, hvor man antager, at mennesker handler rationelt.

I konteksten af digitalt design handler det om at forstå, hvordan brugere træffer beslutninger online – og hvordan design kan støtte, påvirke eller ændre disse beslutninger.

Fra slides i undervisningen d. 25/9-25:

En praktisk model til at forstå og påvirke adfærd er COM-B-modellen, som siger, at adfærd (Behaviour) er et resultat af tre faktorer:

Capability (Kompetence) – Handler om brugerens evne til at gennemføre en opgave.

• Handler om brugerens evne til at gennemføre en opgave.
• Fysisk kompetence: Har brugeren de fysiske evner? (Fx: kan de bruge en mus, læse teksten, se farverne?)
• Psykologisk kompetence: Har brugeren den nødvendige viden eller forståelse?

Designværktøjer til at styrke Capability:

• Chunking: Opdel information i mindre bidder.
• Storytelling: Skab mening og sammenhæng gennem historier.

Opportunity (Mulighed) – Handler om de ydre forhold, der gør adfærd mulig.

• Fysisk mulighed: Er det praktisk muligt? (Fx: virker knappen, loader siden hurtigt?)
• Social mulighed: Er det socialt accepteret eller opfordret? (Fx: sociale normer, trends)

Designværktøjer til at styrke Opportunity:

• Skab et “space of opportunity” – et miljø hvor det er let at handle.
• Brug Scarcity (mangel), Social Proof (andre gør det også) og Anchoring (førsteindtryk).

Motivation – Handler om lysten eller drivkraften bag adfærden.

• Reflekteret motivation: Bevidste overvejelser og valg.
• Automatisk motivation: Ubevidste vaner og følelser.

Designværktøjer til at styrke Motivation:

• Brug Social Proof: Vis at andre allerede har gjort det.
• Brug Proximity: Gør det relevant og nærværende.

Her er en række psykologiske fænomener, der påvirker brugeradfærd – og som kan bruges strategisk i digitalt design:

• Confirmation Bias: Tendensen til at processere, lede efter eller fortolke information så det stemmer overens med det, man i forvejen tror på.
• Post Purchase Rationalization: Vi har en tendens til at fralægge os ansvar for alt, der KAN gå galt.50% af os har tendens til ofte at fortryde køb.
• Retrievability Bias: Retrievability eller Availability Bias er et udtryk for vores tendens til at agere på prompts ud fra vores hukommelse. Informationer, der er nemt tilgængelige, bliver overvurderet.
• Anchoring Bias: De første informationer vi får præsenteret, er ofte dem, vi sammenligner med. Nye informationer er ikke nødvendigvis et nyt udgangspunkt. Første pris, første tilbud, første indtryk = vigtigt i designet.
• Barnum Effekten: Tendens til at tro, at generelle udsagn (fx horoskoper) passer specifikt på os. Personligt prægede beskeder kan øge engagement.
• Ben Franklin Effekten: Folk kan lide os bedre, hvis de allerede har gjort os en tjeneste. Få brugeren til at investere tid → større engagement.
• Loss Aversion: Kognitiv bias der beskriver, at smerten ved at miste er dobbelt så høj som glæden ved at få. Design, der fremhæver risikoen ved ikke at handle, kan være mere effektivt end at fokusere på fordelene.
• Endowment Effekt: Teorien om at mennesker værdsætter det, dehar, højere end det, de ikke har. “Prøv gratis” eller “Dine indstillinger” gør det sværere for brugeren at give slip.

Persuasion i Digitalt Design

Persuasion (overtalelse) handler om at designe brugeroplevelser, der:

• Persuasion er at nudge – eller påvirke – brugerne til at gøre det,de gerne vil have gjort.
• At nudge eller påvirke brugerne til at gøre noget, de ikke vil have gjort.

Eksempler på Nudging og Bias i Design

AI-Workshop

Case: Sikker digital adfærd

Udvikl en kampagne rettet mod at øge bevidstheden om sikker onlineadfærd. Målgruppen er børn og unge under15år. Opgaven går ud på at vi IKKE må tage stilling til noget selv og at vi skal lade AI generere ALT for os.

Konklusion: Noget output var noget værre vrøvl og nogle ting gav slet ikke mening og ville ikke ramme målgruppen. I gruppen (Mads, Sofie og jeg) talte vi om, hvorvidt det ville have været bedre at prompte på engelsk end på dansk i.f.t. outputtet. AI-drevet kampagne om sikker online adfærd for børn og unge

Casebeskrivelse: Du skal udvikle en digital kampagne, der øger bevidstheden om sikker online adfærd blandt børn og unge under 15 år. Kampagnen skal være visuelt tiltalende, pædagogisk og letforståelig for målgruppen, og alle dele skal skabes med AI-værktøjer.

Opgaver:

1. Målgruppeanalyse med AI
   
   • Brug AI til at analysere målgruppen: deres online vaner, udfordringer og adfærd (ChatGPT, Google Bard).
   • Skab AI-genererede personas og brugerrejser, der illustrerer typiske digitale situationer for børn og unge.
     
2. Kampagnekoncept & Budskaber
   
   • Udarbejd et kreativt kampagnekoncept med stærke nøglebudskaber, der taler til børn og unge (ChatGPT, Jasper)
   • Generér forslag til catchy slogans og hashtags.
     
3. Visuel identitet
   
   • Design kampagnens visuelle elementer (logo, farvepalet, illustrationer) med AI (DALL·E, Midjourney, Canva AI).
   • Lav animationer eller korte videoer, der formidler budskabet på en engagerende måde (Runway, Lumen5).
     
4. Kampagnemateriale
   
   • Udarbejd plakater, SoMe opslag, og korte videoannoncer, som appellerer til den unge målgruppe.
   • Brug AI til at skabe en prototype af en interaktiv mini-webside med tips og gode råd (Uizard, Figma AI).

5. Kommunikation & Tonalitet
   
   • Skriv al tekst i kampagnen – fra overskrifter til korte tekster – med AI, så det passer til børn og unges sprogbrug (ChatGPT).
     
6. Pitch og præsentation
   
   • Lav en fængende præsentation af kampagnen ved hjælp af AI-værktøjer (Beautiful.ai, Tome).
   • Skab en AI-genereret voice-over eller video-pitch, der kan præsenteres for kommunen eller skolemyndigheder (Synthesia, ElevenLabs).
     

Krav:

• Alt materiale skal udvikles udelukkende med AI-værktøjer.
• Dokumentér hvilke AI-værktøjer, der er brugt til hvad.
• Afslut med en refleksion over muligheder og udfordringer ved at lave en sådan kampagne 100 % med AI.
  

---

Læringsmål:

• Forståelse for målgruppeanalyse og brugercentreret kommunikation.
• Kreativ anvendelse af AI i kampagneudvikling.
• Evne til at tilpasse sprog og visuelle elementer til børn og unge.
• Kritisk refleksion over AI’s rolle i samfundsrelevante kommunikationsopgaver.
  

Vil du have, at jeg hjælper med at lave et konkret undervisningsforløb ud fra denne case?

Målgruppeanalyse med AI

Online vaner, udfordringer og adfærd – AI-analyse (baseret på danske data + AI-syntese):

Vaner:

• 2-3 timer dagligt på sociale medier og digitale spil.
• Foretrukne platforme: TikTok, YouTube, Snapchat, Instagram (dog under 15 år ikke officielt på Instagram).
• Brug af digitale devices starter typisk omkring 10-årsalderen.
  

Udfordringer:

• Digital mobning, eksklusion fra grupper på sociale medier.
• Følelse af ansvar for at undgå ubehag, men manglende redskaber til at tackle det.
• Risiko for afhængighedssymptomer og dårlig trivsel især blandt piger og børn med lav selvkontrol.
  

Adfærd:

• Mange er aktive skabere af indhold (videoer, memes).
• Søger fællesskab og social anerkendelse online.
• Undgår ofte at involvere voksne ved problemer, hvilket øger risiko for ubehag.
  

AI-genererede personas og brugerrejser

Persona 1: Emma, 13 årAktiv på TikTok og Snapchat, elsker at lave videoer. Oplever pres for at være “perfekt” og få mange likes. Er ofte usikker på, hvordan hun skal håndtere negative kommentarer. Tør ikke altid tale med forældrene om det.

Persona 2: Oscar, 11 årSpiller meget online og chatter med venner i spillet. Føler sig tit udenfor, fordi han ikke er med i klassens WhatsApp-gruppe. Vil gerne have mere mod til at sige fra, når andre er slemme online. Bruger YouTube til at lære nye ting og få inspiration.

Typisk brugerrejse for Emma:

1. Morgen: Tjekker TikTok og Instagram efter likes og kommentarer.
2. Skole: Snakker med venner, føler pres for at “være som de andre”.
3. Efter skole: Spiller online, oplever en negativ kommentar i en chat.
4. Aften: Føler sig usikker, men tøver med at fortælle en voksen.
5. Løsning: Ser en kampagnevideo om, hvordan hun kan sige fra og søge hjælp.
   

Kampagnekoncept: “Stærk Online – Stærk I Dig”

• Fokus: Selvtillid, mod og støtte i digitale udfordringer.
• Empower børn til at tage kontrol over deres online liv med mod og venskab.
  

Nøglebudskaber:

• “Du er stærk, også når du er online.”
• “Sig fra, når noget føles forkert.”
• “Fællesskab gør os stærkere.”
• “Det er okay at bede om hjælp.”
  

Sloganforslag:

• #StærkOnline
• #MinStemmeMinStyrke
• #SigFraStyrkDig
• #FællesskabErKraft
  

Visuel identitet

• Logo: En stiliseret megafon, der samtidig former et hjerte — symbol på at blive hørt med omsorg.

• Farvepalet: Energi og tryghed i kombination — varme orange, rolige blå og grønne nuancer.
  

• Illustrationer: Børn i forskellige digitale og sociale situationer, med fokus på smil og empowerment.

Kampagnemateriale

• Plakater: Med slogans og illustrationer i skolernes fællesområder.
• SoMe opslag: Engagerende videoer med personas, tips til at sige fra og mod til at bede om hjælp.
• Prototype mini-webside: Interaktive tips, persona-historier, quizzer og videoer – kan bygges i Uizard eller Figma AI.
  

Kommunikation & Tonalitet

• Sproget er enkelt, nærværende og opmuntrende.
• Brug af direkte tiltale: “Du kan…”, “Husk, det er okay at…”.
• Fokus på empowerment fremfor frygt: vi styrker børn, ikke skræmmer dem.
  

Eksempel på overskrift:
“Styrk dig selv online – det er din verden!”
Eksempel på tekst:
“Det er ikke altid nemt at være online. Nogle gange kan det føles svært at sige fra. Men du er ikke alene – og du er stærkere, end du tror.”

Pitch og præsentation

• Powerpoint eller AI-præsentation via Beautiful.ai med overskuelige slides, grafik og korte videoer.
  
• AI-genereret voice-over pitch til kommunen/skolemyndigheder via Synthesia eller ElevenLabs, der præsenterer kampagnen klart og engagerende.
  

Kampagne hjemmeside:

https://v0.app/chat/online-safety-campaign-l3DZiiO435L

Kampagne sang:

https://suno.com/s/yldqGSAGHXlYEkcG

Opgaven lød på at vi skulle finde en reallife-klient, som vi kunne lave en løsning for. Da vi kun er frontender, var opgaven at finde en klient, hvor vi kunne lave en digital løsning baseret på deres udfordringer/problem. 

I.f.t eksamensform valgte vi Novel, som er en ny eksamensform her på UCL. Ved novel skal man ikke skrive en akademisk rapport, men derimod en klientrapport samt lave nogle flere produktioner.

Efter kick-off foretog vi en brainstorm og gik i gang med at lave research på forskellige virksomheder. Vi skrev til 16 forskellige virksomheder, men fik desværre ikke mange svar tilbage og dem der svarede skrev at de ikke havde tid eller ressourcer til det. Det lykkedes dog lige inden pitch 1 at få en klient, som var ODEON i Odense. Vi havde et rigtig godt møde med dem ang. deres udfordringer i.f.t. at få unge til at komme ind til arrangementer og bruge huset generelt.

Projektstyring

Projektet er drevet gennem en tilpasset Scrum-proces med fokus på gennemsigtighed, fleksibilitet og effektiv fremdrift, understøttet af Trello, automatiseringer og løbende kommunikation via Messenger og Discord.

Justine var Scrum Master i Trello, det vil sige at hun havde ansvar for at holde styr på processer og sikre, at vi arbejdede efter en agil struktur. Jeg var projektleder, og var den der skulle have det overordnet overblik og tage kontakt til potentielle klienter.

For at håndtere vores travle hverdag lavede Justine delte vi vores Google‑kalendere med hinanden, så vi hurtigt kunne se, hvornår vi begge havde tid. Det gjorde planlægningen af møder langt mere effektiv.

Vi havde valgt at sige at vi havde 3 sprint – 1 for hver måned, da projektet skulle strække sig over flere måneder. Set i bakspejlet skulle der have været flere sprint.

Til 1. pitch havde vi ikke så meget at fremvise, da vi først lige havde fået klienten, men vi havde en idé om arbejdsproces, struktur og problemformulering.

Efter pitch fik vi tildelt et nyt gruppemedlem, som vi hurtigt forsøgte at indarbejde i vores arbejdsproces, og vi lavede ligeledes en forventningsafstemning med ham i.f.t. hvordan vi arbejder men også hvad vi forventede af ham.

Proces

Til at starte med lavede vi en primær og sekundær research, herunder også forretningsanalyse og konkurrentanalyse. Vi var ude i byen og lave interviews med folk omkring ODEON og vi udsendte vi spørgeskemaer. Research er altid meget omfattende og tidskrævende, men nødvendig.

Efter at have have lavet brugerundersøgelse, stod resultateterne klart – Mange kendte Odeon, men opfattede det som eksklusivt og dyrt sted, hvilket betød, at unge ofte fravalgte stedet. Vi valgte at have fokus på målgruppen unge voksne i alderen 25–35‑årige, bosat i Odense, da de har økonomi til events og samtidig repræsenterer en yngre målgruppe, som Odeon gerne ville tiltrække.

Herefter udviklede vi idéen om en kampagneside: Ung i ODEON med et dertilhørende “medlemsskab af Ung i ODEON”.

• Kampagnesiden skulle bevare Odeons visuelle udtryk, men justeres i.f.t. målgruppen.
• Et medlemskab, hvor unge kunne få tilbud og blive en del af et fællesskab.
• En eventkalender der viser events målrettet unge, både ud fra tilbud og popularitet.

Vi lo‑fi wireframes, mocckups og prototyper i programmet Figma, som vi testede. Feedbacken var positiv og gav os gode idéer til forbedringer.

Efter positiv feedback på prototypen gik vi i gang med at kode.

Justine sørgede for at sætte repository op på GitHub og forbandt det med Firebase realtime database og hosting.

Projektet blev lavet i programmet Visual Studio Code og blev lavet som et Vue (Vite)-projekt.

Vi fik hurtigt fordelt kode-opgaverne mellem os:

• Jeg skulle lave eventfeedet med kalenderfunktion, filter, mine favoritter – diverse komponeneter og views
• Justine skulle lave medlemsregistreringsdelen
• Vithulan skulle arbejde med de basale kodeelementer så som footer, header og hero – indtil han skulle lave hans reminder-funktion, hvilket han ikke kunne lave førend jeg var færdig med min del i.f.t events, da hans reminder skulle linkes til mit eventfeed.

Da vi havde brugertestdag på skolen viste det sig at deadlines ikke var blevet overholdt, da hverken footer, header eller hero var blevet lavet. Det var kun Justine og jeg der havde vores kodedel klar. Det var pinligt og ikke tilfredsstillende når vi havde lavet aftaler med folk “udefra” som skulle komme og teste vores side. Vi valgte at gennemgå vores Figma med testpersonerne, og så måtte vi vise og fortælle hvordan vi havde tænkt os at funktionerne skulle være. Det rykkede tidsplanen, og vi måtte overtage det meste af kode-arbejdet, da Vithulan ikke formåede at forstå alvoren af at få tingene lavet til tiden.

I de sidste to uger inden aflevering af projektet , arbejdede Justine og jeg ofte til langt ud på natten for at blive færdige. Den sidste uge op til aflevering valgte vi at fordele de sidste opgaver, således at jeg tog ansvar for klientrapporten, mens Justine tog ansvar for koden. – Vi havde mange natlige møder på discord fordi vi hele tiden sparrede med hinanden. Vithulan kæmpede vidst med sin ene kodedel – Reminderen, af hvad vi ved af, for der var ikke noget kommunikation fra hans side af. Desværre kunne jeg også se at den målgruppeanalyse og analyse i.f.t. SoMe vs. målgruppen ikke var fyldestgørende og brugbar i.f.t. klientrapporten, så den måtte jeg også lave i den sidste uge inden aflevering (på trods af jeg gentagne gange de sidste to måneder havde rykket vores sidst ankomne medlem for det, men hans undskyldning var …jeg er næsten færdig med det, mangler bare lige lidt”… men der blev bare aldrig leveret.

Kodning produkt 1 – kampagneside og produkt 2 – Produktmanual/admin.dashboard – lavet i Vue med komponenter og forskellige views. Projektet blev hostet via Firebase og delt via GitHub.

Jeg sørgede hele tiden for at teste koden i.f.t tilgængelighed (med lighthouse) og ikke mindst validering af koden.

Siden kan tilgås: https://sem-eksamen-adb47.web.app/

Content

Der har ikke været så meget fokus på content, da vores løsning er en digital løsning.

Da der fra start ikke var blevet lavet deskresearch i.f.t. tendenser indenfor SoMe fra vores 3. medlem af gruppen (selvom det var hans opgave), måtte jeg i gang med at lave en analyse af tendenserne omkring SoMe og på baggrund heraf udarbejde content og forslag til indholdsplan inden aflevering af projektet.

Klientrapport

Klientrapporten viser produkterne som vi har arbejdet med.

Afslutning

Som produkt leverede vi en funktionel kampagneside Ung i ODEON med medlemsregistrering, eventliste med filter- og kalenderfunktion, samt local storage i.f.t “mine favoritter”. Vi fokuserede ligeledes på strategierne bag content, og lavede ganske få forslag til opslag på facebook/instagram.

Derudover kodede vi en admin login‑side med faner til eventstyring, medlemsstyring, statistik og produktmanual.

Kampagnesiden er designet til at skabe en inkluderende oplevelse for unge samtidig med at vi skulle bevare ODEONs professionelle udtryk. Medlemskabsfunktionen og kalenderen var centrale elementer, der skulle gøre det lettere for unge at opdage og deltage i events.

Refleksion:

Det har været et meget udfordrende projekt på mange måder, dels havde vi også to andre projekter undervejs, som skulle planlægges ind, det tog lang tid at finde en klient, og dels fordi et gruppemedlem hverken overholdt deadlines og ikke leverede som aftalt på trods af vi gentagne gange forsøgte at kommunikere det med ham, men lige meget hjalp det. Vores ambitionsniveau og faglighed matchede bare ikke!

De sidste 2 uger af projektet var stressende og meget presset, da vi havde mange ting der skulle nås, og vi kunne ikke regne med at vores 3. medlem ville lave noget, han hverken bød ind på opgaver, spurgte ind til opgaver og havde stadig ikke leveret de ting, som vi havde rykket for, så det virkede som utopi at tildele ham flere opgaver, hvilket betød, at Justine og jeg måtte overtage det meste af arbejdet for at kunne nå at levere vores produkter.

Projektet i sig selv har været meget sjovt, jeg har lært meget om Vue, Firebase, hosting og databaser.

Jeg er blevet mere bevidst om at jeg bør lade være med at have så meget tålmodighed i.f.t. andre mennesker og skulle have talt med vores undervisere om gruppearbejdet allerede da det begyndt at skride i.f.t. vores 3. gruppemedlem, men vi håbede jo ved at sige til ham at det dur ikke og at den ikke var gået ude på arbejdsmarkedet, troede vi faktisk at han ville tage sig sammen, men nej. Vi må bare sige, at det bliver hans problem i.f.t. eksamen, ikke vores.

Det er ikke tilfredsstillende (eller skal jeg nærmere sige fair), at man “skal” tage et medlem ind, når projektet har været i gang i næsten 1 måned. Der bør skolen måske allerede ved 2. semester afslutning sige til de studerende, at de SKAL have fundet en gruppe INDEN 3. semester-start, at det er et krav der stilles for at gå på 3. semester.

Men bortset fra det, så er jeg stolt af at vi nåede de ting vi havde planlagt og at vi leverede produkterne til tiden. Vi håber, at ODEON har tid og kan nå at give os feedback på projektet inden den mundtlige eksamen.

Krav: 

• Produktet skulle være en datadreven front-end løsning.
• Der skulle anvendes API-kald.
• Der skulle bruge andre relevante teknologier (enten nogle som vi har kigget på sammen, som f.eks. Vue.js, eller nogle som vi ikke har kigget på).

Dette projekt var sideløbende med vores eksamensprojekt, så Justine og jeg så det som en oplagt mulighed at lave noget, der også kunne bruges i eksamensprojektet.

Frontend-projektet er et individuelt projekt, så vi talte om hvilke muligheder vi havde for en løsning, som kunne bruges senere i eksamensprojektet. Justine lavede en tilmeldingsformular og jeg lavede et eventfeed med filtreringsmuligheder. Vithulan skulle lave en reminder.

Introduktion

Et datadrevet eventfeed, hvor brugerne kan interagere med dette feed ved at tilføje, opdatere, prioritere eller slette events på en favoritliste.

Det tekniske setup:

Projektmappe/Vue med Vite i VSC og GitHub

Projektet er opbygget i Vue.js, så arbejdede arbejdede med komponenter og views, som gør, at man ikke arbejder med én template og én CSS, men at man kan style de forskellige komponenter og views individuelt med <style scoped>

Json-server (localhost) og testede API i Postman – lokal udvikling.

Vue.js – oprettelse af komponenter (der kan anvendes igen og igen) og vite.js (som er ”værktøjet” der skal sørge for at f.eks. opdatering af siden og reagerer med det samme hvis der er fejl).

Vue-app (App.vue og komponenter) henter data fra JSON-serveren via fetch  (altså det der står inde i scriptet på den enkelte fil) og viser det i browseren. Det er Read i CRUD.

Backend – Express Server (server.js), som fungerer som mellemled mellem frontend og Firebase. Denne server håndterer API-kald for CRUD-operationer.

• GET: Henter alle favoritter fra Firebase.
  • POST: Tilføjer et nyt favorit-event til listen.
  • PUT: Opdaterer et eksisterende event (f.eks. ændrer prioritet).
  • DELETE: Sletter et event fra favoritlisten.

Backend’en kan kaldes via fetch() i frontend, og er testet med Postman til at sikre, at API-kald fungerer korrekt.

Vue Router, som gør det muligt at have flere sider i én enkeltapplikation. Jeg har to hovedruter:

• Forsiden, som viser en kalender med events (EventKalender).
• Mine favoritter, som viser de events, brugeren har gemt som favoritter (Favorit).

Hver af disse sider er komponenter, der vises dynamisk afhængigt af, hvilken URL brugeren er på.

LocalStorage

• Bruges til at gemme brugerens valg eller favoritter også selvom browseren lukkes: Create: Når brugeren klikker på -ikonet for at tilføje et event som favorit, bliver eventets ID gemt i localStorage.
• localStorage.setItem(“favorites”, JSON.stringify(favorites));

CSS-styling

Start af udviklingsserver

Under udviklingen blev projektet startet med: “npm run dev“, hvilket åbnede en lokal udviklingsserver med live-opdatering, så ændringer i koden kunne ses med det samme uden manuel genindlæsning.

Firebase Realtime Database – For at gøre dataene tilgængelige online har jeg skiftet til Firebase bruges til cloud-database → så data kan ses online

• I komponenten Favorit.vue gemmes ændringer i favoritlisten via: await set(dbRef(db, ‘favorites/simpleAuto’), favorites.value)

Build af produktionsklar version

Da jeg var færdig med at kode projektet genererede jeg en build med: npm run build og herefter var den klar til at blive deployed til Firebase Hosting: firebase deploy

Mit projekt bruger Vue.js til frontend, hvor brugeren kan interagere med et eventfeed, tilføje favoritter og prioritere dem. Data gemmes både i localStorage og i Firebase, hvilket gør det muligt at opdatere og vise favoritlisten i realtid.

Kør live-demo: https://frontend-eventfeedodeon.web.app/

CRUD operationerne er implementeret:

GitHub

Jeg brugte GitHub som versionsstyring, så jeg var sikker på, at have en back-up af koden og således at vi ville kunne dele koden senere i.f.m. eksamensprojektet.

Refleksion:

Det var et meget intenst forløb, da vi først fik undervisning i firebase m.m. efter præsentation af projektet, hvilket gjorde at projektet var udfordrende på mange måder, men dog lærerigt. Der var tale om et “nyt” kodesprog, som vi skulle lære på kort tid, hvilket nogle dage kunne virke vældig frustrerende. Til gengæld har jeg så lavet min egen research og prøvet mig frem og ChatGpt blev en stor hjælp for at forstå de forskellige kodestykker og jeg nåede frem til et produkt som jeg er stolt af. Det eneste der drillede rigtig meget var det med at få billederne vist efter deploy, hvilket jeg fik feedback på ved præsentationen. Jeg ville gerne have forklaret mere om koden i.f.m. præsentationen, men nervøsiteten tog desværre over, og jeg fik ikke sagt de ting jeg ville, men øvelse gør mester.

I.f.m. præsentationen fik jeg feedback omkring billedernes placering i mappestrukturen og for at billedrne ville blive vist online skal de ligge i mappen public.

Gruppe 22: Nicoline, Christoffer, Justine og jeg.

Teamkontrakt:

Foruden en digital brugergrænseflade og indholdselementer, skulle der udarbejdes en akademisk rapport, klientrapport samt individuel JS-video, opslag til sociale medier og markedsføringsvideo for UCL.

Der er anvendt projektplan og SCRUM i Trello i.f.t. projektstyring. Projektplan og SCRUM er løbende blevet opdateret og evalueret i.f.t. opgaveløsningen. Projektplan findes her:

Kick-off og Uge 1

Oversigt over ugens vigtigste opgaver:

• Brainstorm af idéer
• Problemformulering og afgrænsning
• Research – primær og sekundær
• Oprette og begynde at beskrive metodeafsnit til den akademiske rapport
• Risikoanalyse, interessentanalyse, teamkontrakt
• Oprettet adgange til fælles drev, filer, systemer.

Møder:

2 fysiske møder på skolen og 3 onlinemøder på discord.

Uge 2

Oversigt over ugens vigtigste opgaver:

• Besøg hos LIWIRA m.h.p. foto-/videoshoot.
• Fortsætte primær research, da spørgeskema stadig var online.
• Midtvejspitch
• Interviews af målgruppe (potentielle kunder)
• Udarbejdelse af wireframes og content
• Arbejde med den akademiske rapport

Midtvejspitchvejspitch (1)Download

Møder:

2 fysiske møder på skolen og 3 onlinemøder på discord.

Uge 3

Oversigt over ugens vigtigste opgaver:

• Lave målgruppeanalyse og forretningsanalyse færdig.
• Arbejde med den akademiske rapport
• Samarbejde om udarbejdelse af mockups -> Prototype i Figma
• Færdiggørelse af content til website og SoMe.
• Opstart af kode i Visual Studio Code

Møder:

2 fysiske møder på skolen og 3 online

Uge 4

Oversigt over ugens vigtigste opgaver:

• Arbejde med den akademiske rapport og klientrapport
• Brugertest af prototype
• Kode i Visual Studio Code – jeg stod for kode af en responsiv navigation / hamburgermenu.
• Opdatere procesportfolio
• Lave video af JS-kode

Møder:

2 fysiske møder på skolen og 3 online

Klientrapport:

• Akademisk rapport

REFLEKSION

Vi var startet ud med at lave en projektplan samt oprette opgaver i SCRUM i programmet notion i.f.t. projektstyring, men allerede efter 1 uge måtte vi finde et andet system, da notion havde nogle begrænsninger i.f.t. den gratis version. Derfor blev der brugt tid på at opsætte Trello. Det kostede os tid, som vi sagtens kunne have brugt i den anden ende af projektet.

Måske skulle fokus ikke have været lagt så meget på den akademiske rapport til at starte med, da vi følte at vi ikke var kommet særligt langt i.f.t. de andre gruppe, da vi var til midtvejspitch. Vi følte bare at det var vigtigt at få styr på de metoder som vi havde tænkt os at bruge i løsning af projektet inden vi kastede os ud i opgaveløsningen.

Egentligt har vi arbejdet meget godt sammen, både når vi har mødtes fysisk og online. Der har været en forholdsvis god kommunikation mellem os i.f.t hvis der er noget man har været i tvivl om.

I uge 21 blev jeg udfordret på det personlige plan, da min far havde været alvorligt syg siden medio april og han sov ind d. 18/5, så jeg blev ramt psykisk men også med alle de praktiske opgaver der kommer i.f.m. et dødsfald. Jeg har løbende været i dialog med mit team i.f.t. opgaveløsningen, men har kunne mærke at det har været svært at holde fokus og holde overblikket nogle dage.

Der har været mange opgaver og rigtig meget skrivearbejde i dette projekt, og jeg har følt at selvom jeg var under pres personligt, så har jeg alligevel formået at holde fokus og få fulgt op på skrivearbejdet både i f.t. den akademiske rapport og klientrapporten.

Jeg ville gerne have haft at opgaverne omkring skriveprocessen havde været mere ligeligt fordelt, men det var meget Justine og jeg der måtte stå for den del, selvom vi begge også havde andre opgaver, som vi også skulle tage os af. Selvom vi forsøgte at fordele opgaverne og sige fra og opmuntre andre gruppemedlemmer til at tage ansvar lykkedes det os ikke helt.

Strammere projektstyring og være bedre til at kommunikere mere tydeligt i.f.t. deadlines, når de ikke bliver overholdt og synliggøre konsekvenserne heraf. Jeg er måske lidt for blød/konfliktsky, men jeg synes ikke det har været sjovt og være SÅ presset den sidste uge som vi var.

Fordelene ved at have været så meget igennem i.f.t. pensum omkring metoder er at jeg føler, at jeg har ret godt styr på de mange modeller og begreber efterhånden. Jeg synes, at vi er kommet frem til et godt produkt i sidste ende, som vi kan være stolte af.

Gruppe

Helena, Jakob, Sandra, Justine og mig. Gruppekontrakt fremgår af nedenstående:

Opgaven

Opstart og midtvejspitch

Efter Kick-off til Projekt 4 blev gruppen samlet og vi fik lavet gruppekontrakt, skema for møder, brainstorm, herunder valg af organisation, hvilke problemstillinger kunne der være, og hvordan kunne de løses. Valget faldt på organisationen Dyrenes Beskyttelse.

I vores brainstorm-fase påbegyndte vi af lave et KANBAN-board med opgaver, som senere blevet lavet om til SCRUM og projektplan efter midtvejspitch. Vi lavede en ansvarsfordeling af de overordnede emner og tildeling af de første opgaver. Derefter gik tiden med at udarbejde lave research, spørgeskema til brug for kvantitative/kvalitative målgruppeundersøgelser og jeg gennemgik vores pensum og satte det ind i et dokument, så vi havde overblik over pensum i.f.t. hvilke metoder og emner vi skulle arbejde ud fra. Jeg påbegyndte at beskrive metoderne/analyse omkring præattentive attributter, WCAG, adfærdsdesign.

Vi skulle også forberede materiale til midtvejspitch, hvor vi kunne få feedback fra resten af klassen/holdet samt en underviser. Udfordringen på dette tidspunkt var problemformuleringen og om vores idéer til content og produktet var gode nok eller der skulle arbejdes videre med nogle andre ideér.

Vi fik konstruktiv feedback bl.a. omformulering af problemformulering, undersøge sms i.f.t. GDPR (udsende sms hver fredag til dem der har doneret) – men har de ressourcer til at tage billederne? Undersøge hvad andre gør i.f.t. at fastholde donorerne. Undersøge BMC og kan vi lave noget der minder om Spotify-wrapped 1 gang årligt. 

Mere end midtvejs

Vi valgte at gå videre med idéen om en ny kampagneside, som skulle være mere involverende i.f.t. målgruppen og på baggrund heraf blev der udviklet wireframes i Figma, der skulle forestille en kampagne for “Fredagsslik til dyrene”.

Efter midtvejspitch blev vi klogere på at bruge et andet projektstyringsværktøj fremfor KANBAN.

SCRUM-board i Notion blev oprettet, og så skulle alle opgaver fra KANBAN/projektplan oprettes og fordeles herefter. Der blev lavet 4 sprint.

Vi arbejdede meget individuelt på opgaverne. Content-delen stod 2 af gruppemedlemmerne for og vi andre 3 arbejdede med henholdsvis Figma, brugerundersøgelser samt HTML/CSS. Her er nogle eksempler på de opgaver der blev lavet:

Jeg gik i gang med opstart af HTML/CSS og samt lavede et par interviews (brugerundersøgelse) og skrev videre på testplan, testscript til en evt. brugertest af vores nye produkt “en kampagneside – Fredagsslik til dyrene”, samt skrevet lidt videre på metode/analyse i.f.t. bl.a. tilgængelighed, præattentive attributter og adfærdsdesign. Det var bevidst at vi ikke brugte JQuery i.f.m. kodningen, da vi fandt det lidt besværligt at bruge i.f.m. Javascript-projektet.

I forbindelse med at analysere og komme med løsningsforslag på Dyrenes Beskyttelses hjemmeside (landingpage) blev jeg fan af brugen af udviklerværktøjet “lighthouse”, som er et godt værktøj, når man skal arbejde med tilgængelighed, SEO-optimering og ikke mindst fejlfinding og forbedringer af en hjemmeside:

Afslutning – det sidste sprint

Der blev brainstormet på hvilke javascript-kodestykker vi kunne bruge på vores kampagneside og vi fik fordelt det således, at alle have et script der ville opfylde pensum. Jeg skulle stå for kodning af en karrusel (slideshow med billeder) med dertilhørende video, der forklarede koden. Jeg er ikke tilfreds med visningen af slideshowet ved mobilvisning, da meningen var at der skulle slideshowet kun vise et billede af gangen, men nu viser den 4 billeder af gangen. Det er en ting jeg vil være opmærksom på næste gang jeg skal kode et slideshow, der skal jeg huske at arbejde ud fra “mobile-first”-princippet med mediaqueries i VSC. Videoen kan ses her: https://youtu.be/On6amqbM5co

Der var lidt udfordringer i.f.t. at få hele kampagnesiden færdig før påske, så vi nåede ikke at udføre brugertest på den. Jeg havde dog udarbejdet testplan og testscript til brug for sådan en test, hvor der skulle have været 5 testpersoner til en think-aloud-test. Efter testen kunne vi have analyseret resultaterne/besvarelserne og på baggrund heraf kommet med eventuelle forbedringer til siden.

Kampagnesiden kan ses her: https://jakobmediaportfolio.dk/projekt4/

Content-video og UCL markedsføringsvideo blev udfærdiget af andre gruppemedlemmer, men fremgår nedenfor:

Vi mødtes dagen før afleveringen, hvor der lige blev vendt hvad der manglede at blive gjort og nogle i gruppen sørgede for at få ryddet op i vores Visual Studio Code mappe samt på vores fællesdrev, så der blev overblik over hvad der evt. manglede.

Den akademiske rapport blev udfærdiget i InDesign, og det færdige resultat blev således:

Præsentation af projekt

Præsentationen af projektet vil foregå 2 dage efter afleveringen. Her vil vi præsentere vores løsning med faglig argumentation for valg. Vi har d. 22/4 holdet onlinemøde på Discord, hvor vi har aftalt hvem der præsenterer de forskellige emner i projektet.

Ved præsentationen, vil jeg, hvis det er muligt at foretage brugertest af kampagnesiden inden, præsentere testresultater og herigennem validere konceptet og komme med eventuelle forbedringsforslag.

Refleksion

Det startede egentligt godt ud, og så skete der et eller andet der gjorde, at kommunikationen og “teamfølelsen/fællesskabsfølelsen” forsvandt, og det blev svært at nå ind til hinanden.

Alle arbejdede hver for sig med hvert sit, og der var ikke meget kommunikation eller involvering/feedback mellem os. De fysiske møder blev hurtigt “afskaffet”, da vi ikke samarbejdede omkring opgaveløsningen, men man arbejdede stort set individuelt eller 2 og 2. Der blev også kun afholdt gangske få online møder. Den manglende kommunikation gav ekko, når vi endelig mødtes fysisk på skolen, da det virkede som om ingen havde lyst til at sige noget. Set i bagspejlet burde der i hvert fald have været 3 onlinemøder ugentligt for lige at se hinanden i øjnene og hver isæt skulle have haft taletid for lige at orientere resten af gruppen i.f.t. hvad man arbejdede på.

Jeg ville have ønsket at jeg havde haft mulighed for at lære mere omkring brugen af Figma, og ligeledes kunne opgaven omkring Content have været sjov at lave sammen som gruppe. Opgaven kunne sagtens have været fordelt således, at 1 kunne lave indholdsstrategi, 1 kunne lave storyboard til video, 1 kunne lave reels, 2 kunne filme og redigere.

I de sidste to uger af projektet blev jeg ramt af nogle personlige problemer;

Min far blev indlagt med hjertestop og har svævet mellem liv og død siden, han har fået pacemaker men nu er der stødt et par hjerneblødninger til, som lægerne ikke helt kan få styr på grundet pacemakeren, medicin og påske, samtidig måtte vi sige akut farvel til vores 9-årige hund, som døde inden vi nåede ind til dyrlægen. Dertil kommer at jeg er værge for min syge moster i Sønderborg, som er hjerneskadet og som jeg lige har fået installeret på plejehjem, men det er hun ikke helt tilfreds med, så hun/personalet ringer konstant om dit og dat, plus jeg lige har min datters konfirmation d. 4/5 der skal være styr på, så jeg er er lidt mere end træt, nærmest udkørt og vældig frustreret.

Jeg orienterede min gruppe om min situation, som udviste forståelse for min situation. Jeg har forsøgt at fokuserer, men har ikke haft overskud til ret meget siden den 10/4. Det fremgår af log-bogen, hvad jeg har arbejdet med.

Jeg tror at vores forskelligheder/alder/kemi og den måde vi hver især arbejder på ikke var et godt match. Jeg tænker ikke, at jeg er den eneste der sidder tilbage med den følelse, men vi er alle den erfaring rigere.

Vi arbejdede med indholdsproduktioner, hvor vi skulle igennem tre iterationer af processen.

Gruppe: Lucas, Christoffer, Justine og jeg.

Vi valgte casen omkring UCL, nærmere betegnet Medialab.

Research

• Hvilke sociale medier anvendes der?

Facebook, Instagram (UCL, ikke medialab), Tiktok (UCL, er død/inaktiv)

• Hvilken type indhold anvendes nu?

Tekst, billeder, (+ videoer på ucls Tiktok, + videoer på Instagram af privatpersoner)

• Er der nogle trends der er oplagte at følge?

TikTok er et meget populært medie, hvis ikke det mest brugte kommercielle medie til small businesses. Facebook bliver brugt mest i Danmark og er godt til at give potentielle nye studerende et indblik.

Konkrete video trends: Hurtig gennemgang, ikke for meget interview, timelapse, voiceover, journey and goal (vise process og resultatet)

Konkrete billed trends: Billeder af ting i brug (monkey see, monkey do)

• Målgruppe?

Studerende, lærer, potentielle nye studerende (udefrakommende)

• Hvordan anvendes identiteten?

Fælles design i ting, ikke så meget fælles identitet

Proces, produkt og refleksion

Vi fik ret hurtigt brainstormet vores idéer og vi var alle enige om at det skulle være en video der ville vise hele Medialabs faciliteter, og at det kunne være fedt, hvis det var et one-shot, således at det ville være som at man selv går ind i Medialab.

Vi brugte god tid på at få sat hele Medialab op og finde ud af et storyboard/timeline i.f.t. hvordan vi skulle gøre det, da vi hver især fik flere roller i.f.m. optagelsen. Vi lavede flere prøver i.f.t. filmning og timing og små ting der skulle rettes/justeres og iscenesættes på anden vis. Ved at vi brugte tiden på at sætte rigtigt op, og teste om vores idéer kunne lade sig at gøre, gjorde at vi kunne lave et one-take, som vi var tilfredse med.

Bagefter skulle vi præsentere vores video for de andre teams og have silent feedback, som vi så kunne tage med hjem, hvor vi skulle redigere videoen færdig.

Da der var tale om et one-take, så har jeg ikke redigeret i videoens længde, men fokuseret på tekst og musik. Videoen er tiltænkt UCL’s website, og kan ses her:

Det var nok en af de sjoveste og fedeste opgaver vi længe har haft, dels fordi vi havde “fri leg” indenfor et felt, så fantasien kunne få frit spil.

Der var en rigtig god gruppedynamik og vi havde det sjovt.

Det vi alle måtte konstatere var, at det var rigtig svært at få videoen redigeret i Adobe Premiere Pro / After effects. Personligt kan jeg godt mærke at det er nogle programmer jeg har brug for at lege mere med for at få forståelsen af brugen, og hvordan de fungerer. Jeg endte med at anvende programmet Clipchamp til at redigere videoen, ellers var det ikke lykkedes at aflevere opgaven rettidigt.

Det kunne have været fint hvis vi havde vidst lidt på forhånd at vi skulle bruge Premiere Pro/AfterEffect, eller havde haft lidt undervisning/repetition af brugen af programmerne inden denne workshop.

Vores oplæg:

Gruppen bestod af: Justine, Helena, Sandra og jeg.

Vi valgte hjemmesiden: https://pandaplanner.com/?srsltid=AfmBOorsW2Q_LphSMVroYePhi4fz_1PKAlWZrh4jQbVFlbfnTwHPIzHr

Begrundelse for valget af netop denne side

• Der var flere elementer på siden som krævede javascript.

Vi har arbejdet med følgende Javascript:

• Helena: Back-to-top-button
• Sandra: Pop-up
• Justine: Navigation
• Anja: Slideshow

Link til prototypen: https://jkayser.dk/Java/

Link til Github: https://github.com/JinxitNow/Javascript.git

Link til youtube-video: https://youtu.be/h0EYxz-DLC4

Refleksion:

Ej lidt sjov opgave, da vi på baggrund af sidste uges undervisning i Javascript selv skulle kode en allerede eksisterende side med Javascript. I forbindelse med undervisningen kunne jeg ikke få et slideshow til at virke, så det tog jeg i.f.m. projektet, og det lykkedes meget godt.

Ved at arbejde med et konkret kodestykke, som jeg kunne gå i dybden med, gjorde at jeg fik en bedre forståelse af hvad Javascript er og kan sammen med HTML og CSS.

Vi mødtes i gruppen stort set hver formiddag, hvor vi så kunne arbejde videre hjemme. Vi brugte hinanden til sparring, og hvor langt vi var hver i sær.

Gruppen var lidt ramt af forskellige udfordringer, en havde været syg hele ugen hvor der var undervisning, en anden havde en meget syg far og det betød, at Justine og jeg var lidt alene omkring beslutningerne, da vi fik udleveret projektet.

Dernæst var dialogen ikke ret meget til stede, selvom vi havde aftalt at mødes på Discord.

Udfordringen i gruppen kom rigtigt da der skulle laves en video der skulle forklare et kodestykke, da ingen egentligt havde lyst til at lave den, så vi brugte lang tid på at ikke snakke om hvem der så skulle tage den.

Så jeg valgte at tage opgaven på mig, selvom jeg vidste at det ville være svært, især at forklare en andens kode fremfor min egen. Jeg gav det et skud i.f.t. at forklare Helenas kodestykke omkring Back-to-top-button, men jeg kunne ikke fylde tiden ud, så videoen blev for kort. De andre bød ikke ind med at de ville prøve, så det endte med at vi gik hver til sit, og jeg lavede videoen hjemme med udgangspunkt i det kodestykke som jeg havde stået for – slideshowet.

At jeg påtog mig opgaven med at lave videoen var grænseoverskridende, men faktisk meget godt for mig alligevel, da det jo gav mig øvelse i at forklare dels en andens kode og dernæst min egen kode.