MULTIMEDIADESIGN OG KOMMUNIKATION MULA 2016 / 3. SEMESTER / MODUL 1 / GRUPPE 5 UDARBEJDET AF:

DATAMATEN 18. SEPT. 1932 CPHBusiness 2016 MULTIMEDIADESIGN OG KOMMUNIKATION MULA 2016 / 3. SEMESTER / MODUL 1 / GRUPPE 5 UDARBEJDET AF: ANDERS CRAMER NIELSEN HTTP://ANDERSCRAMERNIELSEN.DK/INDEX. PHP?PAGE=SINGLE&PROID=0 BJARKE HANDSDAL HANDSDAL.COM CASPER RAGN HTTP://PORTFOLIO.CASPERRAGN.COM/VIDEO_OG_ DATABASER.HTML LASSE SKYTT HTTP://LASSEJS.COM/PROJECTS/VIDEODATABASE. HTML NIELS OTTO ANDERSEN HTTP://OTTOUCH.COM/DATABASE.HTML 1

DATAMATEN 18. SEPT. 1932 Databaser forklaret som telefoni af JOURNALIST SØRENSEN D atabaser forklaret som telefoni er en kortfilm som forklarer hvordan en SQL database fungerer. Vi forklare to måder at bruge en database på, først hvordan man henter data og derefter hvordan man opdatere en database og det hele bliver forklaret, som en stumfilm fra 1930 erene hvor vi møder en journalist som skal vide det præcise tal for hvor mange svin der er i Nordjylland. Han ringer til omstillingen som fungerede som en server gør i dag, omstilleren stiller ham igennem til kommunen i Nordjylland som har alle tal på hvor mange svin der befinder sig i Nordjylland, Kommunen er i dette tilfælde SQL databasen. Det var hvordan man henter data. Når vi viser hvordan man opdaterer en database ser man en bondemand som står på sin mark, han ser en ny gris blive født og skynder sig at ringe til kommunen for at informere om det nye tal. Bondemanden ringer omstillingen op, som er serveren og kommer igennem til kommunen som er databasen. Kommunen får de nye tal og notere det, og databasen er blevet opdateret. Til sidst viser vi et overblik over hvad der var databasen og serveren i filmen. Hele filmen er i sort/hvid og har ingen lyd, men der er speak og musik igennem filmen som fortæller hvad der sker, da det er en info video som kunne have været sendt på Danmarks Radio i 1932 hvor DR sendte de første tv programmer. CINEMATISK TECHNIQUES/ FILMISKE VIRKEMIDLER Da vi startede med at brainstorme idéer kom både idéen om et vlogging-format og 80'er børne tv, men for at få mest ud af vores tid tog vinen løsning med knap så høje krav til lydproduktionen og et format der effektivt kunne lære folk noget uden st blive en instruksvideo. Vi valgte derfor at gå med et stumfilmsformat, selvom stumfilm normalt kun har musik valgte vi at ligge speak over for at spare seeren for en masse tekst og derfor gøre formatet mere dynamisk og interessant for publikum. FORMAT Vi valgte 4:3 format til filmen for at holde publikum i stemningen af en stumfilm, vi vurderede ikke at vi ville miste nogen funktionalitet. Den eneste grund til vi skulle vælge 16:9 ville være hvis vi havde store flotte wideshots, men det meste af produktionen er filmet indenfor og i close ups. 2

DATAMATEN 18. SEPT. 1932 BILLEDEKOMPOSITION Et eksempel på hvor vi lagde meget vægt på kompositionen er i 2. Akt med Bondemand Morten. Da vi lavede research på stumfilm/slapstick comedy faldt vi nemlig ofte over den samme billedkomposition i løbe/ jagtscener. Kameraet placeret ved siden af karakteren, så de løber fra venstre til højre side i frame. Vi valgte at imitere denne billedekomposition som en intertekstuel reference til hele slap stick konceptet. introduceret til en ny lokation. Udover establishing blev en panorering brugt til at fremvise askebægeret i scenen med omstilleren. Vi går fra et super close up askebægeret for at vise der bliver røget en del cigaretter og ikke arbejdet så meget på omstillingen. Der bliver panoreret til omstilleren som sidder og stirrer meget uentusiastisk på askebægeret. Dette er igen for at sætte en fed streg under det er en stille dag på job for omstilleren og han ikke ligefrem nyder at være der. BILLEDSTIL Tydeligvis en så realistisk gengivelse af 1920-1940s filmkvalitet. Vi filmede i 1080p 50fps i farve. Vi lagde i post produktionen et filter af skader af gammelt film over, konverterede til sort/hvid, skruede for hvid balancen og kontrasten. Vi skruede desuden ned på 24fps og satte i nogle klip farten op format give den klassisk spolede effekt mange ældre film har (se Charlie Chaplin og Buster Keaton). LYS I starten af produktionen havde vi planlagt at bruge spots til alle vores shots, men da vi kom til lokationen var lyset så flot og stemningsfyldt at vi vurderede, efter et par optagelser, at den belysning var rigelig. Vi havde nemlig delt vores optagelser op efter karakterer. Mængden af shots var ikke så stor og vi var derfor ikke infame for at få flere forskellige slags belysning på en lokation/karakter. BRUGER TEST/ FEEDBACK Vi begyndte inden vi har helt færdige med produktionen at vise filmen frem til nogle forskellige segmenter, både folk der kender til databaser og folk der ikke nogen kendskab har til emnet. Det vi fik flest kommentarer på var at lyset og kontrasten ikke var det samme i alle shots. Det forvirrede seererne og gjorde også billederne mere ubehagelige at se på. Vi gik derfor ind og tilpassede alle shots så der ikke KAMERABEVÆGELSER Vi brugte i denne film meget få panoreringer eller tilt. Vi brugte det meget selektivt til at lave establishing shots eller for at sætte fokus på en specifik prop i scenen. I establishing shots fungerede tilt shots godt til at sætte scenen, så seeren fik en følelse for miljøet og skabte en stemning, samtidig med at fungere som en god overgang/fade. Det blev derfor blot brugt første gang publikum blev 3

DATAMATEN 18. SEPT. 1932 var en stor forskel i lys og kontrast. Et andet punkt vi fik af vide var at løbescenen med bondemand Morten var forvirrende. Før vi rettede den løb bondemanden mere skiftevis imellem venstre til højre og højre til venstre. Det desorienterede publikum meget og gjorde at kronologien i løbeturen var ukomisk forvirrende. Vi spejlede derfor nogle af scenerne så han kun løber venstre til højre udenfor gården og højre til venstre inde i gården, for at opdele lokationens mere skematisk og give mere struktur. forhold til framing og vinkel når vi var på location. Vores location var en gammel gård i Dragør og da flere af medlemmerne af gruppen havde været på location utallige gange, mente vi ikke det var nødvendigt at besøge location inden vi skulle optage. Vi arrangerede derfor mange shots inden og efter at have udarbejdet storyboardet delte vi scenerne op i karaktererne. Ved at filme alle scener med en karakter var vi mere effektive og sørgede derfor at både skuespilleren og lyset ikke varierede for meget. Havde vi skudt scenerne kronologisk, ville lyset have været tydelig forskellige på vores første scener med journalisten og de sidste. PROJEKTPLANLÆGNING PBS Se bilag 1. LYD WBS Se bilag 2. MUSIK Musik er med til at gøre hvordan filmen fremtræder. Derfor ville vi finde noget musik som var tidstilsvarende til stumfilm. Vi fandt noget klavermusik som vi mener passer helt perfekt til vores film, det er med til at skabe noget tempo, samt stemning. Grunden til vi valgte dette klaverstykke var at vores videoside er meget stilstående, og gennem lyden skabes der mere liv og stemning. I løbet af filmen klipper vi over til en bondegårds-scene hvor musikken skifter til Edvard Greig s Morning Mood. Denne sang valgte vi for at få en mere idylisk stemning i filmen. BURNDOWN CHART OVER DATABASE FORLØB Se bilag 3. BURNDOWN CHART OVER VIDEO FORLØB Se bilag 4. STORYBOARD (Bilag 5) I dette projekt brugte vi vores storyboard som en måde at få struktur i vores scener og få taget beslutninger inden vi var på location. Det var derfor mere end måde at få overblik over antallet af scener, da vi hellere ville tage specifikke beslutninger i LYDEFFEKTER Vi har valgt at benytte os af 4

DATAMATEN 18. SEPT. 1932 en enkel lydeffekt. Når man er hos journalist Sørensen har vi lagt en skrivemaskine i baggrunden så man får fornemmelsen af at der er travlt på kontoret. var tilbage på hver opgave, ind til opgaven var færdig og ramte 0 timer. Databasen delen var færdig efter 2 dage og her var vi godt med ifølge vores Burndown chart. (Se bilag 3) Video delen tog længere tid og selvom vi ikke ligger under den røde linje hele vejen igennem blev vi færdig til tiden. (se bilag 4). SPEAK Vi har brugt speak for at forklare og kommentere det der foregår på billedsiden. Speak passer også godt til formater der har i sinde at lære publikum noget. Det giver afsenderen frit lejde for at putte ekstra information ind, frem for hvis der blev real-lyd eller dub på skuespillerne. Grundet tidsbegrænsningen gjorde valget af speak processen lettere og vi var ikke lige så afhængige af at skulle efter-dubbe eller fange god lyd på lokation. DATABASE DESIGN (Bilag 6 & 7) Ud fra den konceptuelle model vi har fået udleveret i opgaven har vi sat EER diagram op med i alt 6 tabeller, vi har derefter taget stilling til hvilke relationer der skal være imellem disse og om der er behov for at en tabel er udfyldt for at en anden tabel kan eksistere. Tabellerne i den overordnede database vi har kaldt web_developers lyder således, clients, der har til formål at gemme informationer om vores kunder. Såsom kundens navn, adresse og postnr, et kontakt navn og et kontakt telefon nr. zip_code er en tabel der gemmer alle bynavnene ud fra et bestemt postnr. det gør at zip_code i tabellen clients er en foreignkey der referere til zip_id i tabellen zip_code. Relationen imellem clients og zip_ code er 1:mange forhold og med en registrering om at der godt kan oprettes postnumre uden at der eksistere en kunde. Grunden til at det er et 1:mange forhold er fordi det samme postnr kan gå igen hos flere kunder. Projects tabellen har til formål REFLEKSION AF PROJEKTSTYRRING Vi startede ud med af finde alle arbejdsopgaver til projektet og skrive dem ned, først lavede vi en PBS så vi havde et klart overblik over hvad vores produkt skulle indeholde. Efter det lavede vi en WPS så vi havde alle arbejdsopgaver til produktet. Vi har arbejdet ud fra SCRUM. Vi skulle derefter sætte timer på alle arbejdsopgaverne og gjorde det på den måde at tre personer hver skulle sige hvor mange timer hver opgave ville tage, også finde gennemsnittet af det tal. Vi fik udleveret et Excel ark som kunne udregne dette. Løbende i arbejdsprocessen skulle vi hver dag skrive hvor mange timer der 5

DATAMATEN 18. SEPT. 1932 at gemme informationer omkring en kundes projekt, ved projektets navn, beskrivelse start- og slutdato på et projekt. Imellem clients og projects er der også et 1:mange forhold, en kunde kan have flere projekter registreret ud fra sit client_id i tabellen clients. Tabellen resources indeholder resursens navn og beskrivelse. Imellem projects og resources er der registreret et mange:mange forhold. Da den relation ikke definere hvilken af de tabeller der kan indeholde den samlede information fra de tabeller, skal der oprettes en ny tabel projects_has_resources, det eneste formål denne tabel har er et forene projects og resources. Udover at være en samletabel for de 2 skal vi også registrere hvor lang tid en given resurse er blevet brugt, så i samletabellen har vi også en start tid og en slut tid. For at kunne udregne en timebaseret brug, som også registreres i tabellen projects_has_resources. I den sidste tabel vi har i vores diagram har vi resource_type som skal fortælle os hvilken slags resurse der er blevet brugt. Ligesom med vores zip_code er der igen tale om et 1:mange forhold. Fordi en resursetype kan fremgå flere steder i resources tabellen. Vi er på denne måde gået fra en konceptuel model som vi har fået udleveret til en 3 grads normal form. Grunden til at dette er vigtigt når man arbejder med database design er for at sætte sin database så logisk op som muligt så man ikke får repeterende informationer der står i flere tabeller og stadig holder sin database fleksibel nok til at kunne blive udviklet videre på. FORRETNINGSREGLER Når man snakker om hvorvidt der skal være mulighed for at en tabels række kan eksistere uden at der er udfyldt noget i en anden tabel er der tale om et begreb man kalder for sine forretningsregler. Det Ikke forretningsregler i hvordan forretningen skal fungere men hvordan forretningens backend systems logik skal forståes. Et klart eksempel i vores tilfælde, er en kunde ikke skal kunne oprette sig med et andet postnummer end et af de numre vi har stående i tabellen der hedder zip_code. Et andet meget tydeligt eksempel ses på relationen imellem clients og projects. en kunde kan godt oprette sig uden at der er knyttet et projekt til kunden. men det er obligatorisk for et projekt at have en kunde tilknyttet for at kunne blive oprettet. Grunden til at forretningsregler er vigtige når man blueprinter sin databases design er for at tilføje et lag af styring og logik til databasen. Istedet for at have en masse tabeller som kan blive filtret ind hver for sig, kan det være nemmere at forstå opsætningen når man ser på det med forretningsreglerne i tankerne. 6

PBS Database Video Rapport Tilføj atributter Lyd Visuel Tekst Dokumentation af process (Scrum) ERD Musik Speak effekter reallyd Foto Animation Grafik video undertekster persontitler infotekst Datamodel on 3. NF Kort beskrivelse af ide og koncept Storyboard cinematic techniques

WBS Database Video Rapport Opret atributtabel Ide udvikling PBS Mysql Workbench - struktur af database finde locations WBS generer samletabel Storyboard SCRUM planlæg lydside Product backlog optag lyd/musik burndown chart producere grafisk materiale Datamodel manuskript beskrivelse af koncept Filme videomateriale beskrivelse af dramatogi Redigering/sammenklipning storyboard Masterere lyd/video mediefaglige teknikker

Data Attribut Tabel Clients Navn Value Notes Datatype Length Collation Client_id Auto Increment PrimaryKey(AI) Integer Client_name All char Clients name Varchar 350 utf8_unicode_cs Client_address All char Clients address Varchar 350 utf8_unicode_cs Client_contact_name All char Clients contact person Varchar 100 utf8_unicode_cs Client_contact_phone Number Clients contact phone Integer Zip_code_zip_id Number ForeignKey(zip_code) Integer 4 Tabel Zip_code Navn Value Notes Datatype Length Collation Zip_id Number PrimaryKey Integer 4 City_name All char City name Varchar 250 utf8_unicode_cs

Tabel Projects Navn Value Notes Datatype Length Collation Project_id Auto Increment PrimaryKey(AI) Integer Project_name All char Project name Varchar 100 utf8_unicode_cs Project_description All char Project description Mediumtext utf8_unicode_cs Project_start_date Date Timestamp Datetime Project_end_date Date Timestamp Datetime Other_project_details All char Other project details Mexiumtext utf8_unicode_cs Client_id Number ForeignKey(clients) Integer Tabel Projects_has_resources Navn Value Notes Datatype Length Collation Project_id Number ForeignKey(Projects) Integer Resource_id Number ForeignKey(Resource) Integer From_date_time Date Timestamp Timestamp To_date_time Date Timestamp Timestamp Hourly_usage_rate Number Usage of resource Dec 1,2

Tabel Resources Navn Value Notes Datatype Length Collation Resource_id Auto Increment Primarykey(AI) Integer Other_resource_details All char Other resource details Mediumtext utf8_unicode_cs Resource_type_code Number Code that defines resource ForeignKey (resource_type) Integer Tabel Resource_type Navn Value Notes Datatype Length Collation Resource_type_code Number PrimaryKey Integer Resource_name All char Resource name Varchar 45 utf8_unicode_cs