GenPod. Et generisk podcastingsystem. Dato: 16. december 2008 Gruppe: b301c

Transkript

1 GenPod Et generisk podcastingsystem Dato: 16. december 2008 Gruppe: b301c

2

3 Titel: GenPod Institut for Datalogi ved Aalborg Universitet Selma Lagerlöfs Vej 300 Telefon: Telefax: Tema: It-systemer: Behov, krav og design Projektperiode: P3 Projektgruppe: b301c Deltagere: Elisa Møller Synopsis: Vi beskriver udviklingen af et generisk podcasting system. Dette gør vi gennem systemanalyse og -design, med det primære fokus på brugerinddragelsen. Dette inkorporeres gennem interviews, usability testing samt et indblik i User Innovation Management, dvs. innovation gennem brugerinddragelse. Kim Sø Pedersen Klement Baastrup Johansen Casper Nicolaj Sparre Kaj Richard Nielsen Hovedvejleder Tem Frank Andersen Oplagstal: 2 Sidetal: 64 sider Afsluttet den: 16. december 2008 Rapportens indhold er frit tilgængeligt, men offentliggørelse (med kildeangivelse) må kun ske efter aftale med forfatterne.

4

5 Indhold Kapitel 1 Indledning 7 Kapitel 2 Analysedokument Opgaven Formål Systemdefinition Omgivelser Problemområde Anvendelsesområde Problemområde Klynger Struktur Klasser i Windows applikationen Klasser i web applikationen Hændelser Anvendelsesområde Brug Funktioner Brugergrænsefladen Den tekniske platform Anbefalinger Systemets nytte og realiserbarhed Strategi Udviklingsøkonomi 25 Kapitel 3 Designdokument Opgaven Formål Rettelser til analyse Kvalitetsmål Teknisk platform Udstyr & basisprogrammel Systemgrænseflade Designsprog 30 3

6 3.3 Arkitektur Designkriterier og arkitektoniske krav Generiske design beslutninger Komponentarkitektur i Windows applikationen Komponentarkitektur i Web applikationen Eksemplarisk design Komponenter Windows applikation Brugergrænsefladekomponent Funktionskomponenter Modelkomponenter Persistenskomponenter Komponenter web applikation Brugergrænsefladekomponent Funktionskomponenter Modelkomponenter Persistenskomponenter Evalueringsplan Introduktion til tænke-højt test Formål og forståelse Hovedspørgsmål Brugerprofil Deltagere og roller Evalueringsmetode Opgaveliste Lokalitet og udstyr Dataopsamling Indholdsfortegnelse Heuristisk inspektion 38 Kapitel 4 Evaluering Usability rapport Usability metode Testens forløb og betingelser Resultater Fund og anbefalinger 43 Kapitel 5 Akademisk Del Indledning Reflektion Generisk Økonomiske fordele Juridiske og etiske aspekter Oplevelsesøkonomi 48

7 5.2.5 Case vs. generisk Brugergrænseflade Problemer og behov Vurdering af metoder og teori Unified Modeling Language User Innovation Management De fem gyldne regler Processen Afslutning 55 Kapitel 6 Kildeangivelser Litteratur Kurser Online kilder 57 Kapitel 7 Bilag Interviewguides Interviewguide fjernundervisning Interviewguide universitets undervisning Interviewguide lukket møde Usability 62 5

8

9 KAPITEL 1 Indledning Dette semesters overordnede emne er brugerinddragelse i systemudvikling. Derfor har vi skrevet en rapport hvor vi udvikler et system, med tanke på at inddrage brugeren i udviklingsprocessen,i det endelige system og hvordan dette gøres bedst muligt. Rapportens opbygning afspejler vores proces. Først udvikling af idéen, derefter udvikling af systemets struktur vha. systemanalyse og -design. Derefter implementering af en prototype og usabilitytesting på denne. Endeligt afsluttes der med refleksion og perspektivering over emnet og processen. Vi har fundet frem til en problemstilling som vi mener der er potentielt spændende løsninger på indenfor IT. Hvordan kan et AV-system designes, hvis det skal kunne løse generiske kommunikations- og vidensdelingsmæssige problemer?. Herfra har vi valgt at udvikle et podcastingsystem fordi vi mener at podcasting vil kunne løse en lang række opgaver i forhold til vores problemstilling. Dette kunne f.eks. være hjemmebrugeren der vil vise sig selv frem på nettet eller en virksomhed der vil have et mere visuelt kommunikationsværktøj. I idéfasen besluttede vi, at opstille en række cases for at afgrænse vores område, til en mere håndterbar størrelse. Vi har udvalgt 3 cases til dette formål, det værende podcasting af universitetsforelæsninger, dokumentering/podcasting af møder f.eks. i virksomheder, samt fjernundervisning. Med baggrund i disse cases udviklede vi en række interviewguides, kan ses i bilag 7.1, hvorefter vi foretog interviews af relevante personer. Efter at have foretaget disse interviews foretog vi endnu en begrænsning, ved at udvælge den case vi mente vi havde fået de bedste og mest relevante interviewsvar, og dermed kunne opstilles mest præcist. Dette blev casen omhandlende podcasting af universitetsforelæsninger. Case: Podcasting af universitetsforelæsninger Formål Formålet med podcasting af forelæsninger på universitetet, er så studerende kan se eller gense forelæsninger online eller via et intranet. Dette kan være et hjælpeværktøj både i forbindelse med oplæsning til eksamen, samt hvis en studerende bliver forhindret i at møde op til en forelæsning. Yderligere kan der stilles spørgsmål via internettet til forelæseren, hvis der skulle være tvivlsspørgsmål omkring dele af forelæsningen, såfremt at universitetet kan afsætte ressourcer til dette. Interviewpersoner og fremgangsmåde Vi har foretaget interviews med en institutleder, samt en lektor ved Aalborg Universitet og derudover bygger vi på vores egne erfaringer som studerende. Interviewene er foretaget med en interviewguide(se 7

10 bilag 7.1.2) der, ud over små differentieringer i forhold til disses stillinger, har været ens. Fund Tidligere forsøg med videooptagelse og udgivelse af forelæsninger, har været forbundet med store økonomiske belastninger i forhold til den anvendte metode. Der er blevet brugt professionelt optageudstyr, samt der har været tilknyttet en tekniker både under optagelsen, og til efterredigering, før dette er blevet udgivet. Der er bekymringer omkring manglen på den tovejskommunikation, der normalt er i en undervisningssituation. Desuden vil det være et stort minus hvis de studerende begynder at fravælge forelæsningerne til fordel for at se podcasts. Forelæsere kan også have en tendens til at agere anderledes end normalt, når der kommer kamera på, og hvis der skal tages hensyn til at en undervisningssituation også podcastes, kan det medføre ekstra besvær. Der er også visse juridiske og etiske hensyn at tage, f.eks. hvem har rettighederne til denne podcast, og kan en der forestår en forelæsning holdes ansvarlig for hvad alt hvad der bliver sagt. Desuden kan der være bekymringer omkring at forelæseren kan føle sig overvåget, da denne person ikke ved om ledelsen eventuelt også følger med i podcasten. Der kan være en fordel i at tilbyde podcasts som et hjælpeværktøj, f.eks. til eksamensforberedelse, og generelt at gøre viden tilgængelig udenfor de normale undervisningstidspunkter. Desuden kan forelæseren eventuelt bruge podcasts til personlig udvikling og forbedring af sin undervisning, ved at se eller hører sig selv på podcast. Fra universitetets synspunkt ser man også en mulighed i at bruge det som et markedsføringsredskab overfor potentielt nye studerende. Sammendrag Et system der skal kunne opfylde universitetets behov skal være billigt at implementere, da de sandsynligvis vil fravælge det hvis det er forbundet med en stor investering, samt efterfølgende høje omkostninger. Generelt er der en positiv stemning overfor muligheden for podcasting, men systemet skal leve op til nogle høje kvalitetskrav, samtidigt med at det ikke må medføre ekstra bevær i dagligdagen. Desuden skal der sandsynligvis opstilles et regelsæt for brugen af podcast mellem ledelsen og forelæserne, for at komme eventuelt juridiske og etiske problemstillinger til livs. 8

11 KAPITEL 2 Analysedokument 2.1 Opgaven Formål Vores formål er at udvikle et system der skal gøre podcasting 1 mere tilgængeligt for en bredere målgruppe. Dette vil vi gøre fordi vi mener at det er muligt at udvikle et system der kan implementeres i flere brugskontekster og dermed også sælges til flere Systemdefinition For at komme frem til en systemdefinition er vi startet med at opstille systemets kriterier, altså Betingelser, Anvendelsesområde, Teknologi, Objekter, Funktioner og Filosofi, op på en overskuelig måde. Derefter er kriterierne skrevet sammen til en kortfattet og forståelig systemdefinition. B: Overskueligt, intuitivt, brugbart for uerfarne computerbrugere A: Så mange steder som muligt T: Kamera, computer, mikrofon, databaser og webserver O: Video og lyd F: Håndtering af optagelse, distribution af video/lyd F: Gøre podcasting mere tilgængeligt for folket Systemdefinition Systemet skal anvendes til optagelse og distribution af video- og lydpodcasts. Systemets anvendelse er målrettet mod det brede publikum, det være sig enkelte brugere eller institutioner. Systemets funktionalitet er udviklet på baggrund af de forudgående interviews. Systemet skal have en brugergrænseflade der er let for brugeren at gå til, altså skal den være intuitiv Omgivelser Systemet skal kunne bruges i mange omgivelser, da vi har sagt det skal være generisk. Vi har valgt at lave et rigt billede for universitetsundervisning som eksempel på en brugssituation hvor GenPod kan gøre podcasting mere anvendeligt. Det rige billede kan også tolkes som en virksomhed der skal have beskeder ud til f.eks. medarbejderne. På før billedet, se figur 2.1, er en forelæser i gang med en forelæsning og til højre for ham er en gruppe studerende som er mødt op. De studerende har det problem når de skal læse 1 En metode til udgivelse af lyd- eller videofiler på et netværk til afspilning på bærbare medieafspillere samt computere 9

12 2.1. OPGAVEN op til eksamen, at de ikke kan huske hvad det er underviseren har fortalt. Et andet problem er en elev som er sovet over sig og dermed ikke kan deltage. Samtidig ligger der også et problem i at det kan være dyrt at investere i optageudstyr. Figur 2.1: Rigt billede - før På det rige billede efter systemet er i brug, se figur 2.2, har de studerende som følger undervisningen, nu mulighed for at gense denne når de skal læse op. Den studerende som sov over sig, kan se hvad der er blevet fortalt til forelæsningen. Samtidig er der gennem websiden faciliteret en mulighed for at stille underviseren spørgsmål, både af dem der var der og af dem som sov over sig. Der ligger stadig et problem i at flere kunne få lyst til ikke at møde op fordi de nu bare kan følge undervisningen gennem GenPod Figur 2.2: Rigt billede - efter Problemområde Systemet skal gøre det lettere at optage og dele podcasts med andre. Derfor skal systemet kunne håndtere optagelse, encoding, lagring, tilføjelse af beskrivelse, samt udgivelse af lyd og video til en webside. På websiden skal det være muligt at begrænse adgangen til podcasts, til en afgrænset gruppe mennesker. Desuden skal det være muligt for de besøgende på websiden at kommunikere med hinanden, for f.eks. at kunne stille spørgsmål til podcasts. 10

13 KAPITEL 2. ANALYSEDOKUMENT Anvendelsesområde Systemet skal kunne bruges af et bredt publikum. Alt fra en privatperson der skal bruge et intuitivt system til optagelse og distribution af podcasts, til et firma hvor møder eller vigtige beskeder kan optages og deles med f.eks. medarbejdere, eller et universitet der skal bruge et system der kan optage forelæsninger og samtidigt have en side hvor disse kan udgives på, med plads til spørgsmål og svar vedrørende podcastene. 2.2 Problemområde Klynger Klassediagrammet for vores Windows applikation er opdelt i klynger, dette er valgt pga. behovet for at adskille dele af applikationen fra hinanden. Der er klyngerne Optage og Udgive. I klassediagrammet for vores web applikation er der ikke brugt klynger Struktur GenPod systemet skal kunne optage og udgive podcasts, dette sker gennem to applikationer. De to applikationers klasser ses i hvert deres klassediagram, hhv. figur 2.3 for Windows applikationen og figur 2.4 for web applikationen. Figur 2.3 viser klassediagrammet for Windows applikationen. Det skal være muligt at bruge Windows applikationen til at optage video og lyd uden nødvendigvis at ville udgive det. Derfor er klassediagrammet delt op i to klynger, en for Optage og en for Udgive. Der en associering mellem klasserne Bruger og Gruppe, her er kardinaliteterne sat så en bruger ikke nødvendigvis behøver at tilhøre en gruppe, men en gruppe skal have mindst én bruger knyttet til sig. Klassen Medie har associeringer til klasserne Bruger og Info Figur 2.3: Klassediagram for Windows applikationen Figur 2.4 viser klassediagrammet for web applikationen. Klassen Medie har associeringer til klasserne Gruppe, Info og Kommentarer. Kardinaliteterne mellem Gruppe og Medie er sat så et medie skal tilhøre mindst en gruppe, mens en gruppe ikke behøver at 11

14 2.2. PROBLEMOMRÅDE have noget medie knyttet til sig, f.eks. hvis en gruppe lige er oprettet. Kardinaliteterne mellem Medie og Gruppe er sat så et medie altid kun har en infoklasse knyttet til sig, og så Info altid kun har en medieklasse knyttet til sig. Medie behøver nødvendigvis ikke at have en Kommentar knyttet til sig, men kan have så mange kommentarer som der er brug for. Figur 2.4: Klassediagram for web applikationen Klasser i Windows applikationen Gruppe Klassen gruppe knytter sig til klassen Bruger, den indeholde data vedrørende en gruppes navn og beskrivelse. Således at en udgiver af podcasts kan se en oversigt og de grupper der er muligt at udgive til. Gruppeobjektet bliver skabt når objektet af klassen Bruger har behov for at indhente yderligere informationer om de grupper der kan udgives til. Attributter Gruppe-Navn, Gruppe-Beskrivelse. Info Klassen Info indeholder data omkring en podcasts titel og beskrivelse. Infoobjektet bliver skabt når en podcast er færdig optaget. Brugeren vil da få muligheden for at indtaste titel og beskrivelse af podcasten før den optage session er færdig. Den eneste form for bruger interaktion der vil være mulig, vil være knappen gem, hvorved objektet så vil dø og dataene fra objektet gemt i en fysisk Extensible Markup 12

15 KAPITEL 2. ANALYSEDOKUMENT Language (Herefter: XML) fil. Et objekt af klassen Info er altid knyttet til et objekt af klassen Medie. Attributter Titel, Beskrivelse. Medie Klassen Medie indeholder informationer omkring podcastens fysiske data. Medieobjektet bliver skabt når der gennem Windows applikationen bliver startet en podcast optagelse. Medieobjektet kan dø på en af to følgende måder, optagelsen kan blive annulleret ved bruger interaktion, hvorved objektet vil få en øjeblikkelig død. Den anden mulighed er at optagelsen kan blive stoppet igennem bruger interaktion, Windows applikationen vil stoppe optagelse af podcasten, for herefter at afslutte encodingen og gemme podcasten. Klassen Info vil derpå blive knyttet til Medie. Attributter Fil-Navn, Fil-Størrelse, Optage Tidspunkt, Fil Type. Figur 2.5: Tilstandsdiagram for klassen Medie Bruger Klassen Bruger indeholder data om en, i web applikationen, oprettet bruger. Brugerobjektet bliver skabt når en bruger har valgt at udgive en podcast til web applikationen, ved at bruge funktionen udgiv i Windows applikationen. Objektet vil hente data fra det tilknyttede datalager, for at se om, og i så fald hvor, den givne bruger har rettigheder til at udgive og lagre podcasten. Objektet kan dø på to forskellige måder, enten vælger brugeren at gennemføre udgivelsen af podcasten, hvorfor at objektet vil dø, når dette mål er nået, eller objektet kan dø hvis brugeren vælger at annullere udgivelsen af podcasten. Attributter Brugernavn, Udgivelses-Tidspunkt, Ejer-Tilknyttede-Grupper. Figur 2.6: Tilstandsdiagram for klassen Bruger Klasser i web applikationen Gruppe Klassen Gruppe indeholder data om hver enkelt gruppe i web applikationen, samt om hvilke brugere der er tilknyttet den enkelte gruppe. Et objekt af klassen Gruppe kan blive skabt på flere måder, enten når en gruppe bliver oprettet, når en gruppe bliver slettet eller når en gruppe får redigeret sin medlemsliste. Et objekt af klassen Gruppe kan dø på 3 måder, enten når en bruger fjerner sig fra gruppe oversigten, 13

16 2.2. PROBLEMOMRÅDE når en gruppe bliver slettet eller når web browseren bliver lukket. Attributter Gruppe-Navn, Gruppe-Beskrivelse, Gruppe-Ejer, Gruppe-Medlemmer. Info Klassen Info inderholder data vedrørende et udgivet medie. Objektet opstår og dør sammen med klassen Medie. Attributter Titel, Beskrivelse Medie Klassen Medie indeholder, ligesom Medie i Windows applikationen, data omkring podcastens fysiske data. Objektet bliver skabt når en bruger af web applikationen beder om information vedrørende en given podcast. Til klassen Medie knytter sig klasserne Info og Kommentarer. Medieobjektet opstår når en bruger vælger en podcast i web applikationen, de vil blive præsenteret for de data der kommer fra klassen Medie samt de to tilknyttede klasser Info og Kommentarer. Objektet Medie kan dø på 3 måder, en bruger kan lukke web siden, en bruger kan gå væk fra podcasten, eller podcasten kan blive slettet. Attributter Fil-Navn, Fil-Størrelse, Optage-Tidspunkt, Fil-Type. Bruger Klassen Bruger indeholder data om alle de brugere der er oprettet i web applikationen. Brugerobjektet vil kunne opstå i flere situationer. Det vil opstå når en bruger opretter sig i systemet. Det vil opstå når en bruger logger ind i systemet, således at systemet kan kontrollere hvor brugeren har adgang til. Det vil opstå når en bruger bliver givet adgang til en gruppe af gruppens ejer. Objektet bruger kan dø på 4 måder, brugeren kan vælge at logge ud af systemet. Brugeren kan være færdig med at oprette sig, for så at lade objektet dø, indtil brugeren logger ind. Brugeren kan lukke sin browser, hvorfor objektet så vil dø efter en given tid. Objektet kan dø ved at en gruppe ejer er færdig med at tilføje en bruger til en gruppe. Attributter Bruger-Navn, Ejer-Gruppe-Tilknytninger, Grupper-Tilknytninger. Kommentarer Klassen Kommentarer indeholder data der tilknytter sig til klassen Medie, objektet til klassen vil ligesom klassen Info opstå og dø sammen med klassen Medie. Forskellen er at det er muligt at manipulere med de data objektet indeholder, dvs. at en bruger i en gruppe har mulighed for at tilføje data til Kommentarer objektet, mens ejeren af en gruppe har mulighed for at tilføje og fjerne data fra objektet. Attributter Tilføjelses-Bruger-Navn, Tilføjelses-Dato Hændelser Tabel 2.1 viser hvordan hændelserne knytter sig til klasserne i Windows applikationen. Som eksempel på en hændelse er Optage podcast, denne hændelse involverer klasserne Info og Medie. Medie objektet skabes når en optagelse begyndes. Hændelser / Klasser Gruppe Info Medie Bruger Optage podcast Udgive podcast Tabel 2.1: Hændelsestabel 14

17 KAPITEL 2. ANALYSEDOKUMENT 2.3 Anvendelsesområde Brug I det efterfølgende afsnit vil vi, vha. begreber som aktører og brugsmønstre, beskrive de omgivelser som systemet skal bruges i. Aktører Der er her beskrevet tre aktører hhv. en afsender, en modtager og systemet selv. Afsenderen skal forstås som en aktør der bruger systemet til at optage og publicere podcast. Modtageren er den der bruger web applikationen til at hente, se og kommentere en podcast. Disse beskrives uddybende i det følgende med en forelæsning som eksempel. Forelæser (Afsender) Formål: En forelæser, på et givent universitet, der anvender systemet til at optage og publicere podcasts af undervisningen. Karakteristik: Forelæseren sætter kamera og lyd til ved at koble disse sammen med sin egen computer. Efter undervisningen er slut, skriver han en hurtig kommentar om emnet og hvad forelæsningen handler om. Derefter publicere han podcasten. Studerende (Modtager) Formål: En studerende der henter en publiceret forelæsning og kommentere på denne. Karakteristik: Modtageren har mulighed for at debattere forelæsningen i web applikationen. Denne skal ikke have nogen forudgående erfaring med at hente video eller lyd fra internettet og kommenterer på disse. Systemet Formål: Systemet kontrollere om en podcast tidligere har fået indtastet information. Systemet validerer også afsenderens login. Karakteristik: Systemet bearbejder interaktionen på baggrund af de indtastede data. Eksempler på aktører beskrevet vha. persona Forelæseren, Hans, repræsenterer den del af målgruppen som anvender både web og Windows applikationen. Kasper repræsenterer den del af målgruppen der kun anvender Windows applikationen, og Sara repræsenterer den del af målgruppen som kun anvender web applikationen. Herved er alle dele i systemet repræsenteret. Persona 1: Hans Hans er 55 år gammel og arbejder på Aalborg Universitet som underviser i hverdagene. Derudover forsker han i informationsteknologi, der er hans store passion. Når han er hjemme, går han tur i skoven, sammen med sin kone, Inge og sin schæferhund Fido. Familiens hus befinder sig i periferien af Aalborg. Hans og sin kone har to børn, Henrik på 29 og Maria på 25. Henrik er blevet færdig på universitetet og er fulgt i sin fars fodspor. De deler samme interesse, og taler tit om dette når han er på besøg derhjemme. Hans datter er på 3. semester på psykologistudiet, og er på vej til at flytte hjemmefra. Hans elsker sin familie, og kan godt lide at bruge sin tid sammen 15

18 2.3. ANVENDELSESOMRÅDE med dem, derfor er han ikke interesseret i en tidsrøver af et system, som både giver ham mindre tid til familien og hans store passion. Persona 2: Kasper Kasper er 29 år gammel. Han arbejder i en IT-virksomhed, elsker elektronik og alt hvad der rimer på computer. Han er single og fri, hvilket han udnytter i sin fritid, hvor han går meget i byen. Nogle gange får han og sine venner lidt for meget at drikke, og lige pludseligt er selv det mest kedelige sjovt. Dette skal selvfølgeligt foreviges på YouTube. Her anvender Kasper GenPod til at optage de mindeværdige stunder og ligger dem hurtigt og let op på YouTube til resten af verden. Persona 3: Sara Sara er 21 år gammel. Hun er studerende og anvender podcasting når hun er forhindret i at møde op til forelæsningerne eller vil læse til eksamen. Hun anser podcastingen som et tilbud og et supplement, men ikke en erstatning af almindelige undervisning. Hun vil desuden ikke miste det sociale aspekt ved at gå på universitetet. Sara læser medicin, og er meget engageret i mennesker. Sara læser i København, og med en husleje der er lige så stor som hendes SU, er hun nødt til at arbejde i fritiden. Hun arbejder på sygehuset, hvor hun ofte får 16 timers nattevagter. Hvis hun så har en forelæsning næste morgen, er det rart at kunne flytte undervisningen så den passer ind i hendes hverdag. Scenarier Scenarier lægger, sammen med en persona, op til hvilke aktører der interagerer med systemet, samt i hvilke brugsmønstre de interagerer, og fungerer som den indledende manøvre til udarbejdelsen af disse. I det følgende har vi beskrevet, hvilke scenarier der udspiller sig i vores personas daglige brug med systemet. Hans Hans er lige mødt på universitetet, 15 min. før forelæsningen starter. Denne tid skal han bruge til at gøre podcastingsystemet klar til brug. Han tænder for kameraet, som allerede er til rådighed i forelæsningslokalet. Efter forelæsningen bliver han i undervisningslokalet og ligger let og bekvemt podcastingen op på web applikationen. Hans er en travl mand, der bruger meget tid på undervisningen, sine interesser, sin hund og sidst men ikke mindst sin kone og børn. Han vil ikke bruge for meget tid på podcasting, da han ellers vil have mindre tid til sine interesser. Kasper Kasper har arrangeret en fest for alle hans venner og veninder. Kasper elsker fest og glade dage. Han vil ikke binde sig til en pige, da han elsker friheden og ingen forpligtigelser. Han fester igennem, og efter lidt for meget at drikke, beslutter de sig for at lave en video, til at forevige deres minder og denne fantastiske aften. Her anvender de podcastingsystemets Windows applikation. De danser, griner, råber og synger med i kor til musikken. Herefter ligger han filmen på YouTube 2, som han har gjort det så mange gange før

19 KAPITEL 2. ANALYSEDOKUMENT Podcastingsystemet skal være let håndterbart, da de er fulde og ikke gider eller er i stand til at tænke over hvordan de anvender systemet. Sara Sara har lige været på natarbejde i 16 timer. Dette er hun nødt til at gøre for at få råd til a bo i København. Hun har forelæsning om morgenen, og hun ved at hvis hun tager derhen, får hun ikke meget ud af undervisningen alligevel. Derfor tager hun hjem, for at sove, så hun kan være mere oplagt til at se forelæsningen senere på dagen. Efter hun igen er vågnet, sætter hun sig ind foran computeren, for at se den forelæsning hun gik glip af. Der er allerede kommet kommentarer på undervisningen, og forelæseren har tilføjet et svar på et spørgsmål der er blevet stillet inde på web applikationen. Brugsmønstre - Windows applikation Optage podcast For at en podcast kan optages skal følgende være opfyldt: Brugeren skal have podcastingsystemet installeret. Brugeren skal have tilsluttet gyldigt optageudstyr. Når brugeren vil oprette en podcast starter han med at optage den. Når optagelsen er færdig bliver brugeren medt om at give podcasten en titel og en beskrivelse. Herefter bliver brugeren spurgt om den optagne podcast skal udgives nu eller senere. Udgiv podcast For at en podcast kan udgives skal følgende være opfyldt: Brugeren skal have podcastingsystemet installeret. Brugeren skal have tilsluttet gyldigt optageudstyr. Brugeren skal have optaget en podcast. Brugeren skal være ejer af mindst én gruppe på hjemmesiden. Når brugeren vil udgive en podcast bliver brugeren spurgt om at angive, hvem der skal have adgang til podcasten efter denne er udgivet. Vælger brugeren en gruppe der ikke er offentlig og som vedkomenne er ejer af, bliver han spurgt efter brugernavn og password. Brugsmønsterdiagram for Udgiv podcast kan ses i figur 2.7. Brugsmønstre - web applikation Opret bruger Når en bruger vil oprettes på websiden, vælges Opret bruger og ønsket brugernavn, password, , samt navn indtastes. Hvis brugernavnet ikke er optaget bliver brugerkontoen oprettet og brugeren får tilsendt en , der indeholder informationer om hvordan brugeren aktivere sin konto. Brugsmønsterdiagram for Opret bruger kan ses i figur

20 2.3. ANVENDELSESOMRÅDE Figur 2.7: Brugsmønster for Udgiv Podcast Blive medlem af en gruppe For at blive medlem af en gruppe skal følgende være opfyldt: Brugeren skal have oprettet en konto på websiden. Brugeren vælger menupunktet Alle grupper og vælger den ønskede gruppe. Er gruppen offentlig eller kender brugeren gruppens kodeord, er det muligt at blive medlem med det samme. Er gruppen derimod lukket og brugeren ikke kender gruppens kodeord, kan brugeren sende en forespørgsel om medlemskab til gruppens ejer. Når ejeren har accepteret forespørgslen er brugeren medlem af gruppen. Brugsmønsterdiagram for Blive medlem af en gruppe kan ses i figur

21 KAPITEL 2. ANALYSEDOKUMENT Figur 2.8: Brugsmønster for Opret bruger Finde podcast For at finde en podcast skal følgende være opfyldt: Brugeren skal have oprettet en konto på websiden. Brugeren skal være medlem af en gruppe der indeholder podcasts. Hvis brugeren vil finde en podcast, starter vedkommende med at klikke på menupunktet Mine Grupper og vælger herefter den ønskede gruppe, for så at vælge den ønskede podcast. Når podcasten er valgt har brugeren to muligheder. Brugeren kan enten vælge at afspille podcasten på websiden eller downloade podcasten til sin computer. Brugsmønsterdiagram for Finde podcast kan ses i figur

22 2.3. ANVENDELSESOMRÅDE Figur 2.9: Brugsmønster for Blive medlem af en gruppe Figur 2.10: Brugsmønster for Finde podcast Funktioner Komplet Funktionsliste Systemet understøtter en række funktioner, hvor nogle af disse er identificeret vha. vores brugsmønstre. I tabel 2.2 og 2.3 er der defineret hvilke dele af programmet der aktiverer funktionen, samt dens kompleksitet. 20

23 KAPITEL 2. ANALYSEDOKUMENT Funktion Aktivering Kompleksitet Type Optag podcast GUI Kompleks Opdatering Udgiv podcast GUI Kompleks Opdatering Tabel 2.2: Funktionsliste for Windows applikation Funktion Aktivering Kompleksitet Type Opret bruger GUI Simpel Opdatering Log ind GUI Simpel Opdatering Ret brugerinfo GUI Simpel Opdatering Følg gruppe GUI Simpel Opdatering Forlad gruppe GUI Simpel Opdatering Opret gruppe GUI Simpel Opdatering Rediger gruppe GUI Simpel Opdatering Slet gruppe GUI Simpel Opdatering Se podcast GUI Simpel Opdatering Download podcast GUI Simpel Opdatering Rediger podcast info GUI Simpel Opdatering Slet podcast GUI Simpel Opdatering Opret kommentar GUI Simpel Opdatering Rediger kommentar GUI Simpel Opdatering Slet kommentar GUI Simpel Opdatering Tabel 2.3: Funktionsliste for web applikation Specifikation af funktioner Funktionerne i systemet, i Windows applikationen såvel som web applikationen, bliver alle aktiveret af brugergrænsefladen Brugergrænsefladen Brugergrænsefladen præsenterer systemets øverste lag, det lag som brugeren interagerer med. Herunder har vi både en brugergrænseflade for web applikationen og Windows applikationen. Det fundamentale for brugergrænsefladen er, at denne lever op til brugerens behov og forventninger. For at dette kan lade sig gøre, skal brugergrænsefladen udvikles ud fra en række prioriteringer og brugerens behov, således denne kan arbejde uden hindringer, og uden der opstår irritationsmomenter. Man kan derudover få inspiration af de systemer som brugeren anvender i sin hverdag. Det er ofte lettere at påpege fejl, end at sætte sin finger på det, der får en brugergrænseflade til at fungere, da der ofte er mange elementer, der er med til at skabe et godt helhedsindtryk. På samme tid er det vigtigt, at der er konsistens og at systemet giver en god helhedsoplevelse. Hvis der eksempelvis er flere interaktionsrum i det samme system, kan det virke meget forvirrende, hvis der er inkonsistens mellem knappernes navne eller menuerne. Ensartethed giver sammenhæng mellem systemets delelementer. Til slut, efter en prototype er udviklet, skal denne testes og rettes, da det er umuligt at forudse alle fejl inden systemet er færdigudviklet. Det videre designarbejde med brugergrænsefladen er bestemt ud fra hvilke resultater, der bliver udledt af testen. For at spare tid og penge, er der lavet nogle enkle designregler, der forebygger usability problemer. Vi har brugt disse, til at tage højde for design af brugergrænsefladen. Det gælder om at støtte brugerens behov først. Hvis flertallet af systemets brugere anvender en funktion mere end en anden, skal denne 21

24 2.3. ANVENDELSESOMRÅDE tydeliggøres. Udover det er det også vigtigt at tale et sprog, som brugeren forstår, da IT-fagsprog ikke nødvendigvis er forståeligt for brugeren. Brugerens muligheder i systemet skal være synliggjort og forståelige. Brugeren har en begrænset hukommelse, hvilket bevirker, at systemet skal støtte brugerens hukommelse. Dette kan gøres med hjælpetekster eller lign. og her er enkelthed nøgleordet, både designmæssigt og når brugeren af systemet får en opgave. Til slut er det vigtigt at give feedback til brugeren, specielt hvis systemet bruger lang tid på at behandle en given handling. Derudover er det vigtigt, at systemet hjælper brugeren, når der opstår fejl. Specielt fejlmeddelelser skal være konstruktive, forståelige, præcise, synlige og høflige. Brugergrænsefladen skal endvidere afspejle vore brugsmønstre. Mål for brug Meget vigtigt Vigtigt Mindre vigtigt Irrelevant Usability Effectiveness Efficiency Safety Utility Learnability Memorability Experience Satisfying Enjoyable Fun Entertainment Helpful Motivating Aesthetically pleasing Supportive of creativity Rewarding Tabel 2.4: Prioriteringsskema med mål De engelske ord i prioriteringsskemaet for brugbarhed og brugeroplevelse er svære at oversætte direkte til dansk og få samme mening ud af. Derfor kan en kort ordforklaring ses i tabel 2.5. Vi benytter dem stadig på engelsk fordi det er svært at finde tilsvarende danske ord. Som det ses på vores prioriteringsskema, se tabel 2.4, har vi skulle prioritere hvilke egenskaber vi ser, som vigtige i forhold til vores system. Effectiveness er prioriteret som meget vigtige, da vi tidligere har beskrevet, at vores system skal være tidsbesparende i eksempelvis undervisningssituationer. Efficiency er også priorieret som meget vigtig, da vores system ofte vil blive benyttet af personer, som ikke er øvede IT-brugere har vi derudover valgt, at systemet skal være let at lære, således brugeren kan opretholde et højt niveau af produktivitet. Safety er prioriteret som vigtig, da vi f.eks. ikke ønsker at brugeren risikere at miste sin optagelse pga. utilsigtet nedlukning af programmet. Ikke alle kriterier kan stå som meget vigtigt, da vi har måtte indse en prioritering er nødvendig, idet vi gerne vil have realistiske mål for systemet. Derudover skal systemet kun stille det til rådighed, som brugeren har behov for, hverken mere eller mindre, derfor er Utility prioriteret som meget vigtig. 22

25 KAPITEL 2. ANALYSEDOKUMENT Kriterium Effectiveness Efficiency Safety Utility Learnability Memorability Satisfying Enjoyable Fun Entertainment Helpful Motivating Aesthetically pleasing Supportive of creativity Rewarding Forklaring Brugeren skal kunne lære og udføre opgaver effektivt. Opgaver er hurtige at lære og brugeren kan opretholde et højt niveau af produktivitet. At beskytte brugeren mod farlige tilstande og uhensigtsmæssige situationer At de værktøjer kunden skal bruge bliver stillet til rådighed. At programmet er let at lære at bruge. At det er til at huske hvordan man gør ting i programmet, fra gang til gang. At man bliver tilfredsstillet af at bruge programmet. Programmet skal være fornøjeligt at bruge. At man føler det er sjovt at bruge programmet. Programmet underholder brugeren. Programmet er behjælpelig, med henblik på programmets brug. At det er motiverende at bruge programmet. At man bliver tilfredsstillet ud fra programmets udseende. At bruge programmet fremmer kreativiteten. At programmet skal give brugeren en følelse af udbytte. Tabel 2.5: Ordforklaring for usability mål Systemet skal derudover være let at lære, således brugeren nemmere kommer i gang anvendelsen af systemet, hvorfor Learnability er sat til meget vigtig. Memorability er prioriteret til mindre vigtig pga. den forholdsvis flade indlæringskurve. Satisfying er prioriteret som vigtig, fordi vi ønsker at brugeren skal føle sig tilfreds med sin brugsoplevelse af systemet. Vi har prioriteret Helpful som mindre vigtig, da vi har allerede bestemt at systemet skal være intuitivt forståeligt. Dette bevirker at der ikke er brug for den samme mængde hjælpetekster m.m. Motivating er prioriteret som vigtigt, da vi ønsker motiverede brugere til at skabe indhold. De resterende mål er irrelevante, da der ikke er lagt vægt på disse elementer i systemet. Begrebsmæssig model Den valgte begrebsmæssige model for Windows og web applikationen er navigering og manipulering. Brugeren navigerer vha. menuer og knapper. Når en podcast skal udgives vælges en video- eller lydfil, herefter kan brugeren manipulere den tilhørende information. Interaktionsform Ud fra den begrebsmæssige model bestemmes interaktionsformen. Det samme system kan operere med flere interaktionsformer på samme tid og i samme brugergrænseflade. Der findes følgende interaktionsformer til systemer: Kommando, menu, dialog, skemaudfyldelse, WIMP 3. Ud fra de to applikationer vil vi udvikle, med henvisning til den begrebsmæssige model, valger vi at anvende interaktionsformerne skemaudfyldelse og WIMP. 3 Står for windows, icons, menus, og pointers 23

26 2.3. ANVENDELSESOMRÅDE Skemaudfyldelsen i Web applikationen kommer til udtryk når brugeren skal oprette sig en brugerprofil på siden, udfylder tekstfelter og ændre podcast-info. Skemaudfyldelsen i Windows applikationen finder sted når der er optaget en podcast og der skal indtastes information til denne. WIMP, er ligeledes anvendt til begge dele af systemet, dette er baggrunden for en grafisk brugergrænseflade. Generel interaktionsmodel Der er tre interaktionsrum i Windows applikationen, hhv. optagelse, udgivelse og en menubar. Optagelse skal håndtere optag, pause og stop af en podcast. Derudover skal den indeholde en gengivelse af den video, som der optages. Udgivelse skal håndtere udgivelsen af en podcast. Dette indebærer den skal kunne udgive en tidligere optaget podcast. Menubaren skal håndtere standardfunktioner som Afslut og Åben, men skal også indeholde muligheden for at starte optagelsen af ny podcast eller starte af udgivelsen af en tidligere optaget podcast. Opbygningen af brugergrænsefladen Figur 2.11 er en tidlig model af vores brugergrænseflade med vore tre tidligere beskrevne interaktionsrum. Figur 2.11: Tidlig brugergrænseflade Den tekniske platform Den del af systemet der skal håndtere optagelsen af podcasten bliver udviklet til at køre på en bærbar og en almindelig PC. Programmet vil blive udviklet til Windows, i programmeringssproget C#. Programmet vil derfor kræve at Microsoft s.net Framework 3.5 er installeret for at det kan køre. 24

27 KAPITEL 2. ANALYSEDOKUMENT Web applikationen vil blive udviklet i PHP og vil anvende MySQL som database. Web applikationen vil derfor kræve en webserver der kan afvikle PHP-scripts, samt en MySQL server. 2.4 Anbefalinger Efter analysearbejdet virker udviklingen af systemet som helhed realistisk. Den største udfordring bliver først og fremmest rent teknisk at udvikle den del af systemet, der står for at optage lyd og video, samt at konvertere det til et podcasting egnet format. Desuden er der mange overvejelser, for at gøre systemet generisk og dermed ramme alle de tænkte målgrupper Systemets nytte og realiserbarhed At opfylde systemets mål for generisk podcasting, og dermed gøre podcasting mere tilgængeligt er fuldt ud realiserbart. En teknisk udfordring vil dog bestå i at sørge for at systemet er kompatibelt med forskelligt hardware, altså at sikre at systemet vil fungere med alle standard webcams. 2.5 Strategi Funktionaliteten og kravene er udspecificeret i dette analysedokument. For Windows applikationen er det vigtigt at fokusere på at systemet understøtter en bred vifte af hardware, således at systemet vil være brugbart i en lang række situationer. For web applikationen, er det vigtigt at få brugersystemet, kombineret med gruppe, til at fungere optimalt. Dette for at det er let og intuitivt for en bruger at komme ind og finde en specifik podcast, se og eller downloade denne, og eventuelt diskutere denne med andre medlemmer af den samme gruppe. 2.6 Udviklingsøkonomi De omkostninger der umiddelbart er forbundet med udviklingen af dette system, er de timer udviklerne har lagt i det. 25

28

29 KAPITEL 3 Designdokument 3.1 Opgaven Formål Vores formål er at udvikle et system der skal gøre podcasting 1 mere tilgængeligt for en bredere målgruppe. Dette vil vi gøre fordi vi mener at det er muligt at udvikle et system der kan implementeres i flere brugskontekster og dermed også sælges til flere Rettelser til analyse Vi havde indledningsvis valgt at web applikationen til at skulle have klasser, ligesom vores Windows applikation. Disse klasser har vi fjernet for i stedet at programmere det imperativt da vores web applikation er nemmere og hurtigere at programmere på denne måde. Ellers er det ingen rettelser til analysedokumentet Kvalitetsmål I analysen af betingelserne til systemets arkitektur, skal disse defineres ud fra systemdefinitionen. Denne liste vil give nogle konkrete svar på, om systemet kan dekomponeres, eller om systemet fungerer ligeså godt i sin helhed. Den overordnede definition og formål med systemet er, at systemet skal være effektivt, let og overskueligt for brugeren. I forhold til dette skal systemets kriterier bestemmes og herefter prioriteres sammen med de generelle kriterier. Herunder er beskrevet hvorfor prioriteringen er foretaget som den er, og uddybet de valg vi har taget vedrørende prioriteringen. Brugbarhed og forståelighed Definition: Tilpasning til de organisatoriske, arbejdsmæssige og tekniske omgivelser. Brugbarheden ses generelt på systemet som helhed. Det er afgørende for systemet, at brugbarheden er tilfredsstillende for brugeren, ellers har systemet ikke nogen relevans. Vores forventninger til brugbarheden er baseret på vores intention om at opbygge systemet intuitivt. Både web og Windows applikationen skal kunne benyttes af flertallet, hvilket bevirker en spredt målgruppe når vi taler om IT-kompetencer. Derfor er der høje krav til brugbarhed samt forståelighed. Systemet må fra brugerens synspunkt ikke indeholde nogen fejl eller irritationsmomenter. Da vores system, skal kunne bruges af både engangsbrugere og flergangsbrugere, med mere eller mindre 1 En metode til udgivelse af lyd- eller videofiler på et netværk til afspilning på bærbare medieafspillere samt computere 27

30 3.1. OPGAVEN Kriterium Meget vigtigt Vigtigt Mindre vigtigt Irrelevant Trivielt opfyldt Brugbart Sikkert Effektivt Korrekt Pålideligt Vedligeholdbart Testbart Fleksibelt Forståeligt Genbrugbart Flytbart Integrerbart Tabel 3.1: Checkliste for prioritering af designkriterier forstand på IT, og vi derudover ligger vægt på et effektivt system, skal forståelsen af systemet prioriteres som meget vigtigt. Sikkerhed Definition: Sikring mod uønsket adgang til systemets faciliteter og data. Dette har vi valgt som essentielt for GenPod, både i web og i Windows applikationen. Dette er fordi der skal kunne laves private podcasts. Det skal altså være muligt at lave en podcast til en bestemt målgruppe, og sikre at disse data kun bliver tilgængelige for disse. Effektivitet Definition: Økonomisk udnyttelse af den tekniske platforms faciliteter. Den økonomiske effektivitet i systemet har vi sat til vigtig i begge dele af systemet. Dette er grundet vi ikke ønsker der skal være spildtid ved brug af systemet Korrekthed Definition: Opfyldelse af formulerede kriterier. Korrektheden i systemet er prioriteret som meget vigtigt, på den baggrund, at hvis systemet ikke er korrekt i alle faser, er det ubrugeligt. Pålideligt Definition: Opfyldelse af krævet præcision i udførelse af funktioner. Pålideligheden er trivielt opfyldt. Hvis de andre kriterier er opfyldt, vil systemet også være pålideligt. Vedligeholdbart Definition: Omkostninger ved at finde fejl i systemet. Vedligeholdbart er placeret som irrelevant, da vi ikke understøtter fejlfindning i GenPod. Vi går ud fra vores system er fejlfrit, grundet prioriteringen af systemets testbarhed, som er beskrevet nedenfor. Testbart Definition: Omkostninger ved at sikre, at systemet opfylder kravene. Vi prioriterer testbart vigtig, da vi mener, at ved at bruge en række økonomiske ressourcer på praktiske 28

31 KAPITEL 3. DESIGNDOKUMENT tests, vil vi finde mange af de fejl, som ellers ville forekomme, og samtidig skulle undgå vedligeholdelse. Vi søger at teste systemet med stor præcision, og derefter tilpasse systemet inden det frigives. Eftersom vi har sat datasikkerheden som meget vigtig, skal vi også kunne teste dette. Fleksibelt Definition: Omkostninger ved at ændre systemet, når det er taget i brug. Vi prioriterer genbrugbart som irrelevant, da vi ikke ønsker at understøtte dette. Flytbart Definition: Omkostninger ved at flytte systemet til en anden teknisk platform. Vi prioriterer flytbart som irrelevant, og dette bliver derfor ikke understøttet af systemet. Genbrugbart Definition: Mulighed for at genbruge dele af systemet i andre beslægtede systemer. Vi prioriterer genbrugbart som irrelevant, da vi ikke ønsker at understøtte dette. Integrerbart Definition: Omkostninger ved at koble systemet til andre systemer. Integrerbarheden er ikke noget vi understøtter, derfor er det ikke idéen at det skal integreres med andre systemer. 3.2 Teknisk platform Udstyr & basisprogrammel Windows applikation Denne del af systemet bliver udviklet til at kører på bærbare computere og på almindelige stationære PC er. Derudover kræves at der til computeren, er tilsluttet optageudstyr i form af kamera, som f.eks. et indbygget webcam, og eller mikrofon. Ønskes kun optagelse af lyd, kan der ses bort fra kameraet. Denne del af systemet bliver programmeret til Microsoft.NET 3.5 understøttede platforme i programmeringssproget C# og anvender MySQL som database. Vi har opstillet nogle anbefalede krav til computeren der skal kører softwaren. Disse kan ses nedenfor. Anbefalet systemspecifikationer: Processer (CPU): 1,8 GHz Dual Core el. tilsvarende Hukommelse (RAM): 2GB Harddisk plads: 500 MB (svarende til ca. 5 timers video) Web applikation Denne del af systemet bliver udviklet så den er kompatibel med de fleste nyere styresystemer og webbrowsere. Web applikationen bliver udviklet i programmeringssproget PHP 2 og anvender ligesom Windows applikationen MySQL som database. 2 PHP står for Hypertext Preprocessor 29

32 3.3. ARKITEKTUR Systemgrænseflade Ved optagelse af podcasts vil systemet kræve en bærbar eller almindelig stationær PC med tilsluttet optageudstyr, i form af kamera og eller mikrofon. Ved brug af websiden kræves en computer med kompatibel browser Designsprog Designdokumentet er baseret på UML Arkitektur Designkriterier og arkitektoniske krav Da hverken kriterierne sikkert, vedligeholdbart, genbrugbart, flytbart ellers integrerbart er prioriteret om irrelevante designkriterier, behøver vi ikke stille særlige krav til den arkitektoniske struktur af systemet Generiske design beslutninger Vi har ikke foretaget nogen generisk designbeslutninger Komponentarkitektur i Windows applikationen Vi har valgt en traditionel lagdelt arkitektur med fire komponenter. Det første er et brugergrænsefladelag, herunder er et funktionslag, modellag og til sidst et persistenslag. Der er valgt en åben-streng arkitektur, bl.a. fordi vi har prioriteret genbrugbart, flytbart og vedligeholdbart som irrelevant i prioriteringsskema for designkriterier, se tabel Komponentarkitektur i Web applikationen Vi har ikke inddelt web applikationen i nogle komponenter fordi vi ikke har programmeret det objekt orienteret men i stedet imperativt Eksemplarisk design Brugsmønsteret for udgivelse af podcast er brugt som eksempel til at beskrive tidsrækkefølgen af meddelelser mellem objekterne. Eksemplet dækker kun over det at udgive en podcast med Windows applikationen. Vi forudsætter at aktøren ikke allerede er logget ind. Brugsmønsteret er beskrevet vha. et sekvensdiagram figur 3.2 som kan ses på side 32. Når aktøren starter GenPod mødes denne først af en dialog box hvor der kan vælges mellem optagelse eller udgivelse af en podcast. Her vælges udgivelse, samt den ønskede fil. Herefter mødes aktøren af et log ind vindue hvor der indtastes brugernavn og password, når aktøren trykker udfør sendes disse videre til PublishCtrl, som beder MySql om at hente dataene i MySQL databasen. Disse sendes tilbage til PublishCtrl som validerer om det indtastede brugernavn og password eksisterer. Hvis de er rigtige vil aktøren sendes videre til mainform, som indeholder informationer om podcasten. 3 UML står for Unified Modeling Language 30

33 KAPITEL 3. DESIGNDOKUMENT Figur 3.1: Klassediagram med Windows applikationens komponentarkitektur Aktøren indtaster den relevante information, vælger hvilken gruppe podcasten skal udgives i og trykker Udgiv. Herefter bliver podcast informationerne sendt til databasen gennem MySql og podcasten bliver sendt til filserveren med hjælp fra Ftp. 3.4 Komponenter Windows applikation Brugergrænsefladekomponent Windows applikationens brugergrænsefladekomponent indeholder udelukkende vores brugergrænseflade. Det er svært at snakke om de primære stakeholders, da det kan være hvem som helst der har lyst, tid og intellekt til at sætte sig ind i den brugen af GenPod. Præsentationsmodel Brugergrænsefladekomponentens funktionalitet, passer med de funktionaliteter der er listet i tabel 2.2 i analysedokumentet. Når vi sammenligner prioriteringsskemaet med prototypen, vil det kunne ses at disse ikke stemmer helt overens, hvilket dog ville blive rettet i en endelig udgave. Centralt i prottypen af Windows applikationen er der vores hovedvindue. I hovedvinduet, er der de to reelle muligheder der hedder Optag og Udgiv, disse to muligheder er de centrale bestanddele af hele systemet. Hovedvinduet skifter tildels udseende afhængig af hvad der bliver valgt, vinduets centrale interaktionsrum bliver transformeret til at passe til behovet for den ønskede funktion. 31

34 3.4. KOMPONENTER WINDOWS APPLIKATION Figur 3.2: Sekvensdiagram for udgivelse 32

35 KAPITEL 3. DESIGNDOKUMENT Funktionskomponenter Struktur Funktionslaget i Windows applikationen indeholder tre funktionskomponenter, PublishCtrl, Ftp og MySql. Disse tre klasser styrer alt hvad der sker i forhold til data der manipuleres internt eller eksternt, dvs. de data der bliver sendt til databasen eller filserveren. Klasser Herunder vil klasserne blive beskrevet: Navn: PublishCtrl Ansvar og Formål: Klassen har to primære opgaver, den første er at opsamle login informationer og sende dem videre til MySql klassen for at få adgang til databasen og filserveren, med det formål at kunne udgive podcasts. Den anden opgave er at styre selve udgivelsen, at sørge for at de rigtige data bliver sendt de rigtige steder hen. Attributter: Ingen Metoder: Login(UserName, UserPassword), Publish(Media, Group, Owner, File). Navn: Ftp. Ansvar og Formål: At sende filer til filserveren, som det bliver defineret af PublishCtrl. Attributter: Ingen Metoder: Upload(Media, File). Navn: MySql. Ansvar og Formål: At kontrollere om en given bruger har adgang til websiden, hvilke grupper brugeren er ejer af med henblik på upload. Attributter: Ingen Metoder: User(UserName), Group(GroupID), AddPodcast(Media, Group, Owner, File) Modelkomponenter Struktur Ligesom i funktionslaget, er der i modellaget to separate dele, den ene del tilhører Medie klassen i modellaget. I modellaget har vi de to klasser Media og Info, Media repræsenterer selve den fysiske fil der bliver lagret på computeren under og efter optagelsen, mens Info er repræsenteret ved oplysninger om optagelsen, disse bliver efter indtastning gemt i en lokal XML fil, med henblik på at blive udgivet senere. Klasser Navn: Media. Ansvar og Formål: At tilknytte de korrekte informationer til podcastne under udgivelsesfasen. Attributter: FileName, FileDate, FileSize, FileType, FileInfo. 33

36 3.5. KOMPONENTER WEB APPLIKATION Navn: Info. Ansvar og Formål: Info klassen indeholder titel og beskrivelse til en podcast, som den bliver indtastet efter optagelse. Attributter: Title, Description. Navn: User. Ansvar og Formål: User klassen indeholder et bruger ID, bruger navn, bruger password og hvilke grupper brugeren er ejer af, disse informationer får den gennem MySql klassen i funktionslaget ved login. Attributter: UserID, UserName, UserPassword, UserGroups. Navn: Group. Ansvar og Formål: Klassen Group indeholder alle informationer om de klasser en bruger ejer, henholdsvis gruppe ID, gruppe navn, gruppe beskrivelse og hvem der er ejer af gruppen, disse informationer bliver ligesom i klassen User tilgået gennem klassen MySql i funktionslaget. Attributter: GroupID, GroupName, GroupDescription, GroupOwner Persistenskomponenter Persistenlaget indeholder to typer lagerskrivning, skrivning af en video- eller lydfil til filserveren, samt de tilhørende informationer til databasen. 3.5 Komponenter web applikation Brugergrænsefladekomponent Brugergrænsefladen i web applikationen, indeholder ikke klasser, men er baseret på HTML fremstilling i en browser. Præsentationsmodel Interaktionsrummene i web applikation er illustreret med en præsentationsmodel, se figur 3.4. Her kan det bemærkes at menuen optræder i alle interaktionsrummene, indholdet af denne menu vil dog være afhængig af om man er logget ind eller ej, da de fleste områder på webstedet ikke er tilgængeligt, før man er logget ind med en gyldig bruger. Dette illustreres også ved at navigationen til størstedelen af interaktionsrummene foregår gennem Login. Det eneste andet tilgængelige område fra Forsiden, er Opret bruger. Efter at være blevet logget ind, for man adgang til 3 nye interaktionsrum, det værende Rediger bruger, Alle grupper og Mine grupper. Hver af disse leder videre til et nyt interaktionsrum, svarende til hvor man befinder sig på webstedet. Der skal knyttes en kommentar til opbygningen af præsentationsmodellen. Fra alle interaktionsrum, når man er logget ind, er det muligt at springe direkte til Forsiden, Rediger bruger, Alle grupper og Mine grupper via menuen, som altid optræder, uanset hvor man befinder sig på websiden. Disse navigationslinjer er udeladt af interaktionsmodellen for at fremme overblikket. 34

37 KAPITEL 3. DESIGNDOKUMENT Funktionskomponenter Struktur Funktionslaget består af php-filer der hver indeholder en gruppe funktioner, relateret til deres respektive områder. Hver komponent modtager eller sender data til henholdsvis brugergrænsefladen eller persistenslaget, samt behandler disse data, i det fald det er nødvendigt. Klasser Da funktionslaget er programmeret i PHP, indeholder det ikke egentlige klasser, men består blot af samlinger af funktioner i php-filer, grupperet efter deres tilhørsforhold Modelkomponenter Der eksistere ikke noget reelt modellag for web applikationen, da funktionskomponenterne går direkte til persistenslaget og henter de data der er nødvendige Persistenskomponenter Persistenslaget består af en MySQL database, som funktionslaget kommunikerer direkte med, gennem SQL-queries Evalueringsplan Introduktion til tænke-højt test Følgende er testplanen for udførelsen af assessment testen for GenPod systemet. Planen dækker følgende områder: Formål Hovedspørgsmål Brugerprofiler Deltagere og roller Evalueringsmetode Opgaveliste Lokalitet og udstyr Dataopsamling Formål og forståelse I en usability test får en bruger stillet nogle realistiske opgaver af en testleder. Mens brugeren løser opgaverne, skal denne tænke højt, dvs. testpersonen skal sige, hvad der tænkes på, hvad der kan være tvivl omkring, hvad der forventes at systemet gør nu, hvordan en fejlmeddelelse/hjælpemeddelelse fortolkers osv. 4 SQL står for Structured Query Language 35

38 3.6. EVALUERINGSPLAN Hovedspørgsmål Er systemet intuitivt forståeligt? Er der fejl i systemet? Er systemet let forståeligt målt på tid? Brugerprofil Der vil blive brugt 8-10 testpersoner til at gennemføre usability testen. Den første test vil være en pilot test, hvor formålet er at finde ud af om testen virker som den skal. De yderligere testpersoner der ikke deltager i pilot testen, er udvalgt på følgende grundlag: Under uddannelse Computererfaring Ingen erfaring med usabiliy testing Rådighed Kriterierne er opstillet ud fra den case hvormed systemet har sin grundudvikling, dette er gjort grundet at det ej er muligt at ramme en bred nok målgruppe når man tænker generisk, når man skal lave en valid usability test og have en chance for at få testen gennemført Deltagere og roller Testens skala foregår i et usability laboratorium. Her er det hensigten at de omgivelser testen bliver udført i minder så meget som muligt om de omgivelser hvori systemet til dagligt anvendes. De roller der skal udfyldes, for at lave en usability test, er følgende: Testleder: At præsentere hver testperson for testen. Få testpersonen til at åbne sig op og slappe af og få testpersonen til at forstå at det er systemet der testes på og ikke personens egen kunnen. Kameramand: At sørge for at kameraet samt den nødvendige software på test-computeren kører korrekt. Notar: At tage notater af brugerens kommentarer og opførsel under testen Evalueringsmetode Der vil blive opsamlet information om og evalueret på følgende: Tiden for gennemførsel af hver enkelt test. Hvor mange, der gennemfører hver enkelt test. Hvor mange usability fejl, der opleves af den enkelte bruger. 36

39 KAPITEL 3. DESIGNDOKUMENT Opgaveliste Der er ikke fastlagt tider til opgaverne, der skal definere hvor lang tid en opgave højst må tage, før den er løst tilfredsstillende. Dog vil der der i usability rapporten blive udarbejdet et skema for tider. Tiderne fra denne test, vil blive brugt som reference tider i efterfølgende tests, når produktet nærmer sig sin afslutning. Opgaverne er struktureret så alle testpersonerne kommer til at bruge både Windows og web applikationen. 1. Du har tidligere oprettet dig som bruger med brugernavnet Peter og password Gå ind på hjemmesiden og log ind med denne bruger. 2. Du er ikke medlem af nogen gruppe endnu. Find gruppen med navnet Gruppe 1 og bliv medlem af denne. 3. Vælg en af deres podcasts og se den. Opret en kort kommentar med din mening om videoen. 4. Du har nu fået lyst til at oprette din egen gruppe hvor du kan ligge nogle videoer ud, en som du optager nu og en som du tidligere har optaget. Start med at oprette en ny gruppe. 5. Skift til programmet GenPod og optag en video af dig selv hvor du klapper fem gange i hænderne. Udfyld felterne titel, gruppe, beskrivelse og udgiv. 6. Du har en anden Podcast liggende på dit skrivebord, med navnet ***** 5. - denne vil du gerne udgive i samme gruppe. 7. Du finder ud af at i sidste beskrivelse under din allerede udgivne podcast, er der en del stavefejl. Derfor vil du gerne redigere i teksten Lokalitet og udstyr Vi foretager testen i Cassiopeias usability laboratorium. Størstedelen af målgruppen, vil anvende systemet i omgivelser lignende dette. Usability laboratoriet skal fremstå som en almindelig arbejdsplads, med en computer til udførelsen af opgaverne Dataopsamling Dataopsamlingen vil foregå gennem videofilm, af både skærm og testperson. Derudover vil lyden blive optaget, og der vil blive taget notater løbende under testen Indholdsfortegnelse Rapporten vil indeholde følgende elementer: Testplan (som den blev udført) Resultater af testen (en umiddelbar tabel over alle resultaterne, en komplet liste vil blive tilføjet som bilag) Fund og anbefalinger 5 Angiver et tilfældigt filnavn, ikke vigtig i forhold til opgaven 37

40 3.6. EVALUERINGSPLAN Heuristisk inspektion En heuristisk inspektion af et system, udarbejdes således, at en række usability eksperter vurderer systemet ud fra en almindelig sund fornuft, ud fra kendskab til målgruppe og kontekst, og ud fra en række retningslinjer og principper indenfor konstruktion af gode brugergrænseflader. Herunder kan eksempelvis nævnes gestaltlovene, som vi beskæftiger os med senere i rapporten, samt Rolf Molichs 5 gyldne regler for design 6. En heuristisk inspektion er god at anvende på systemer, hvor man ikke har ressourcerne til at udføre mere omfattende praktiske tests. Denne metode menes at finde helt op til 70% af alle usabilityfejl. Endvidere er denne form for teoretisk test ideel at anvende inden en praktisk afprøvning af systemet, da det teoretiske udgangspunkt for fejlfinding gør, at man kan fokusere på mere praktisk relaterede fejl i systemet, i stedet for de fejl som hurtigt vil blive fundet i en heuristisk inspektion. Man skal dog være meget påpasselig med denne form for tests, da man kan risikere at finde falske fejl. Med dette menes der, at den teoretiske test finder nogle fejl og mangler i systemet, som enten ikke ville forekomme i den praktiske test, eller som er ikke har betydning for brugeren. Den heuristiske inspektion kan bruges under hele processen i udviklingen af et system. Den kan både bruges på tidlige prototyper af et system, og på det færdige system. Begge steder, vil denne metode være meget anvendelig. Vi har dog valgt at vurdere det færdige system. Heuristikker Jakob Nielsen kom for et par år siden med ti nye heuristikker 7. Disse ti heuristikker blev hurtigt anerkendt som basis grundlag for at vuderer et website. De ti er ikke et endeligt måleværktøj for et website, men en god guide der hjælper med at holde en rød tråd i udviklingen. 1. Dårlige læsbarhed af teksten (font og kontrast) 2. Mærkelige links (inkonsistens) 3. For meget flash 4. Lang og uklare tekster 5. Dårlige søgemuligheder 6. Virker ikke i Mozilla, Firefox, Safari eller Opera 7. Besværlige formularer 8. Manglende afsenderinformationer 9. Stramt og fastlåst layout 10. Dårlig fotoforstørrelse (forstørrelsen er dårlig kvalitet eller kun minimal større) Disse heuristikker er en række punkter, der skal ligges vægt på under en heuristisk inspektion. De skal forstås som en tjekliste usabilityeksperterne kan gå ud fra

41 KAPITEL 3. DESIGNDOKUMENT Figur 3.3: Designklassediagram for Windows applikationen 39

42 3.6. EVALUERINGSPLAN Figur 3.4: Præsentationsmodel for web applikationen 40

43 KAPITEL 4 Evaluering 4.1 Usability rapport Usability metode Der var nogle få ændringer i forhold til den originale plan, disse ændringer kom grundet det tidspres der var på henholdsvis usability laboratoriet og på de mulige deltagere til usability testen der var inviteret. Den første ændring blev lokationen for udførselen af testen. Denne blev ændret fra usability laboratoriet til lokale på Institut for Datalogi. Anden ændring blev antallet af testpersoner, der grundet rådighed, ikke blev til mere end 4 fra de ønskede 8-10 personer. Den tredje ændring, manifesterer sig ved at der ikke er lavet en heuristisk inspektion. Denne er fravalgt grundet manglen på usability eksperter udover udviklerne selv, hvorfor det blev vurderet at være knap så relevant i forhold til udviklingstiden. Vi fravlagte at bruge det tredje hovedspørgsmål (se afsnit 3.6.3), pga. opgavernes korte udførselstid. Til optagelse af skærmbillede blev Camtasia benyttet Testens forløb og betingelser Som tidligere nævnt er tænke-højt testen udført som en assessment test på prototypen. Dette er valgt, da vi gerne vil vurdere det generelle design på nuværende tidspunkt, for at få nye idéer til forbedringer eller ændringer til det endelige design. Prototypen er funktionelt tæt på det færdige system, men da vi gerne vil have det skal være så brugervenligt som muligt, så brugerne har lyst til at anvende systemet, er det vigtigt at få fjernet alvorlige fejl og tilføjet manglende funktionalitet. Samtidigt er brugeren blevet indraget i det endelige design. Forholdene i testen kontra forholdene hvor systemet skal bruges er tæt på optimale. Testen er foregået i et roligt miljø uden forstyrrelser og vi forudser at det skal bruges under nogenlunde samme forhold. Da systemet er delt op i to dele, hhv. en web og en Windows applikation, er testen struktureret således at vi får testpersonerne gennem brugsmønstre for alle delene. På denne måde får vi set på hvordan hver applikation fungerer for sig, og hvor godt de fungerer sammen Resultater Tabel 4.1 viser hvilke fejl der blev fundet, hvor mange af testpersonerne der blev berørt af fejlen, samt hvor ofte denne opstod. Ved evaluering af dette system, er testpersonerne ikke blevet evalueret på den tid de brugte på at gennemføre de stillede opgaver, dette er valgt grundet den korte gennemførselstid for de

44 4.1. USABILITY RAPPORT enkelte opgaver. Det er vores vurdering at med de korte gennemførselstider der blev registreret, vil det være praktisk umuligt at skelne testpersonernes skrivehastighed, fra deres udførselshastighed, hvorfor en sådan sammenligning bliver irrelevant. F.eks. i første opgave, hvor de fleste testpersoner gennemførte på under 2 sekunder. Måden hvorpå de fejl der blev fundet i usabilitytestene vurderes, er følgende: 1. Alle fejl der opstår i testene bliver listet 2. De enkelte fejls hyppighed bliver talt 3. Det antal testbrugere der oplevede fejlen bliver talt 4. Fejlene bliver af udviklerene vurderet i forhold til skema 7.1 i bilagene, hvorefter alle fejltyperne har fået en indledende usabilityscore 5. Nogle af de tal der er fremkommet bliver sat ind i formel 7.1 i bilagene. Her bliver fejlenes hyppighed udregnet, dette tal bliver sat ind i skama 7.1 for at få aflæst sin score, denne bliver lagt sammen med den score en fejl har fået igennem udviklernes vudering, for så at blive indsat i skama Den endelige usabilityscore afgører hvilken kategori et usabilityproblem bliver tilknyttet. Fejlene i tabel 4.1 er ikke opstillet i forhold til hvilken rækkefølge de bør bearbejdes, men i den fundne rækkefølge i forhold til de tests der er blevet udført. Fejl nr. Fejltype Antal Personer Udvikler vurdering Usability kategori 1 Medlem af gruppe 2 2 Moderat Alvorlig 2 Program bug 3 3 Moderat Alvorlig 3 Valg af videoudstyr 3 3 Irriterende Alvorlig 4 Gem Som -delen 2 2 Irriterende Mindre alvorlig 5 Medlem af gruppe 1 1 Irriterende Mindre alvorlig 6 Udgivelse af tidligere podcast 2 2 Moderat Alvorlig 7 Podcast og grupper 1 1 Irriterende Mindre alvorlig 8 Redigering af podcast 3 3 Moderat Alvorlig 9 Velkomstformularen 1 1 Irriterende Mindre alvorlig Tabel 4.1: Fejlliste 1. Websiden bekræfter ikke at man nu er blevet medlem af en gruppe, når man bliver en del af den. 2. Bug i programmet, hvor gruppen står som valgt når man udgiver video nummer 2, selvom den fra systemets side ikke er valgt. 3. Videoudstyr skal vælges manuelt, hvilket testpersonen først bliver opmærksom på når der kommer en messagebox derom. 4. Testpersonen er i tvivl om brugen af Gem Som -delen i forbindelse med optagelse af podcast. 5. Testpersonen anvender Tilføj Gruppe i stedet for Bliv medlem af gruppe. 6. Forvirring omkring udgivelse af tidligere optaget podcast. 7. Kan ikke skelne mellem podcast og grupper, der er ingen synlig forskel på disse på websiden. 42

45 KAPITEL 4. EVALUERING 8. Man bliver sendt retur til gruppeoversigten, efter redigering af en podcast, fremfor tilbage til gruppen hvor podcasten befinder sig. 9. Velkomst formularen vælger meget få at læse igennem, hvilket kan give problemer og forvirring Fund og anbefalinger Validitet Validiteten af denne usability test er rimelig god i forhold til de fejl der blev fundet. De fleste af fejlene gentog sig ved de testpersoner der blev benyttet. Dette giver et billede af at fejlene ikke var enkeltstående. Grundet det lave antal af testpersoner, kan vi ikke læne os op af anerkendt teori når vi behandler resultaterne, der skal være minimum 6 personer igennem. Dette inklusiv en til gennemførsel af pilottesten, til at rette spørgsmålene, udstyret eller andet til, således at alt er gennemprøvet med en udenforstående. Igen er problemet rådighed, derfor blev en studerende med kendskab til usability brugt til formålet. Det optimale antal af personer til at teste et produkt som GenPod, der breder sig til en målgruppe som vores, er urimelig stor i forhold til de data der skal behandles, dette er grunden til at vi har valgt at støtte os til teori fra Jeffrey Rubins Handbook of Usability testing, der fortæller os at såfremt der benyttes 6-10 testpersoner i den ønskede målgruppe, vil de hyppigste fejl blive fundet. Vi valgte derfor at tage de testpersoner der var til rådighed for os i forhold til den case vi havde valgt og arbejde ud fra. Observationer Den primære observation fra assessment testen må være, at specielt web applikationen, funktionelt virker som den skal. De fejl der er opdaget under testen var udelukkende kommunikationsfejl, mellem system og bruger, primært baseret på misforståelser. Dette omhandler fejl nr. 1, 5 og 7. Der blev af udviklerne selv efter testene var afsluttet, fundet en funtionel fejl i web applikationen. Dette være sig fejl nr. 8. Ingen af testpersonerne blev synlig berørt af dette, fordi testpersonernes opgaver sluttede, således at fejlen ikke var aktuel at skulle tage stilling til. Fejl nr. 2 er en funktionel fejl, der giver brugeren et indtryk af at systemet har hjulpet brugeren med at finde en genvej, til et tidligere valg i Windows applikationen. Kommunikationen omkring dette er korrekt, det var fra udviklernes side mening at hjælpe. Fejl nr. 3 kan let kædes sammen med fejl nr. 9, da alle vores testpersoner valgte ikke at læse den velkomstformular, der ligger i Windows applikationen når denne startes op. Dette medfølger at testpersonerne ikke fik informationen vedrørende, at de manuelt skulle vælge videoudstyr, hvorfor fejl nr. 3 på listen opstår. Dog kunne alle testpersonerne herefter, med hjælp fra den i systemet indbyggede kontrol og besked, komme igennem opgaven. Fejl nr. 4 er en forståelsesmæssig fejl, da det ikke var tydeligt for brugerne hvad der var krævet af dem. Dette skabte en kort forvirring. Fejl nr. 6 er en kosmetisk fejl, der påvirker to af test brugerne. Disse fandt det ikke intuitivt at vælge Udgiv podcast fra menupunktet Filer. Anbefalinger Ud fra de givne observationer der er foretaget, vil vi give følgende anbefalinger til forbedring af web og Windows applikationen. 43

46 4.1. USABILITY RAPPORT 1. Websiden bekræfter ikke at man nu er blevet medlem af en gruppe, når man bliver en del af den. Ved indmeldelse / accept i en gruppe, vil en given bruger få en meget eksplicit besked om at funktionen nu er udført, dvs. fortælle at der er ansøgt om gruppemedlemskab. At gøre en bruger opmærksom på at denne nu er medlem af en given gruppe. 2. Bug i programmet, hvor gruppen står som valgt når man udgiver video nummer 2, selvom den fra systemets side ikke er valgt. Buggen der er listet som fejl nr. 2, skal naturligvis løses, således at genvejen virker som ønsket. 3. Videoudstyr skal vælges manuelt, hvilket testpersonen først bliver opmærksom på når der kommer en messagebox derom. Fejlen opstår som en eskalering af manglende brugerindsigt og bruger interesse i at læse den indbyggede velkomstformular. Vi kan konstatere at den indbyggede hjælp virker som den skal. En løsning kunne være at lade systemet vælge tilsluttet videoudstyr automatisk. Såfremt der bliver fundet to eller flere videoenheder skal systemet da gøre brugeren opmærksom på dette. 4. Testpersonen er i tvivl om brugen af Gem Som -delen i forbindelse med optagelse af podcast. Det skal gøres mere intuitivt for brugeren, hvorledes stien til filen skal udfyldes, dvs. at der skal laves et check på filnavnet når der trykkes optag, evt. med et default navn. 5. Testpersonen anvender Tilføj Gruppe i stedet for Bliv medlem af gruppe. En løsning til dette problem, vil være at adskille de to funktioner fra hinanden, således at øjet lettere kan skelne de to funktioner. En anden måde at løse problemet på ville være ved at ændre funktionernes navne så det er nemmere at skelne mellem de to. 6. Forvirring omkring udgivelse af tidligere optaget podcast. Funktionen Udgiv Podcast skal synliggøres på en anden måde for brugeren, således at denne ikke vælger at forlade Windows applikationen for at finde den fil der skal udgives, dette kan gøres ved at tilføje den mere end et sted, f.eks. lave en separat menu til at udgive med. 7. Kan ikke skelne mellem podcast og grupper, der er ingen synlig forskel på disse på websiden. Igen er løsningen, grafisk at differentiere, denne gang mellem gruppe og podcast oversigterne. 8. Man bliver sendt retur til gruppeoversigten, efter redigering af en podcast, fremfor tilbage til gruppen hvor podcasten befinder sig. Dette er en simpel kodetilrettelse, der er glippet i forhold til det planlagte. 9. Velkomst formularen vælger meget få at læse igennem, hvilket kan give problemer og forvirring. Efter en del evaluering, er konsensussen at det vil være formålstjeneligt at omskrive velkomst formularen, således at det vil være lettere for brugerne af systemet at overskue en læsning af disse vigtige informationer. 44

47 KAPITEL 5 Akademisk Del 5.1 Indledning Vi har valgt at kalde vores system for GenPod fordi vi gerne ville skabe et generisk podcastingsystem. Generisk definere vi ud fra en enkelt sætning; Ned ad trappe frem for op. Dette er en udtryksmåde, et holdepunkt og et mentalt billede vi har brugt i udviklingsfasen, for at hjælpe os selv, og som vi nu vil forklare. Verden omkring os bliver dagligt mere og mere kompliceret, og derfor også mere og mere specialiseret, dette påvirker at ting bliver opdelt. F.eks. matematik, kunne for ca. 100 år siden betegnes som et enkelt felt, hvor de dygtigste matematikere kunne være med over det hele. Efterhånden som videnskaben og matematikken har udviklet sig, vil ingen enkeltperson være i stand til at forstå den fulde dybde af ret mange emner, derfor er matematik blevet opdelt i specialiseringer, ligesom disse yderligere er blevet opdelt. Dette er hvad vi ønsker at sige med vores lille sætning, bare modsat, vi ønsker ikke at opdele og specialisere, men derimod at samle og forenkle. Med GenPod samler vi forskellige behov til et enkelt produkt, der er lige og enkelt at gå til. Med andre ord vil vi med GenPod tage et skridt ned af trappen frem for op ved at gøre det generisk. 5.2 Reflektion Generisk I dette afsnit vil vi forsøge at beskrive hvordan vi skulle have udviklet vores system for at gøre det platformuafhængig. Vi valgte at programmere vores Windows applikation i programmeringssproget C#, hvilket betyder at denne del af systemet kun kan kører på en computer med Microsofts.NET 3.5 framework installeret. Siden 86% 1 af verdens webbrugere anvender et Windows styresystem, der understøtter.net 3.5, kan det diskuteres om GenPod ikke allerede er generisk. Hvis systemet derudover stadig skulle være platformuafhæning skulle denne del have været udviklet i et programmeringssprog der kan køre på flere styresystemer. Dette kunne f.eks. være C++ 2 eller Java 3. Grunden til at vi valgte at programmere i C#

48 5.2. REFLEKTION er at vi har modtaget undervisning i det programmeringssprog. For at køre Java programmer kræves også et framework installeret, men dette kan køre på flere platforme. Kigger vi på de andre dele af systemet har vi allerede opfyldt ønsket om at det skulle være generisk. Webdelen kræver en webserver der understøtter PHP og MySQL, som begge er platformuafhængige. Det samme er den filserver der anvendes til at opbevare de udgivne podcasts Økonomiske fordele Når vi skal sammenligne GenPod med andre lignende systemer, står det os klart at vi har visse fordele frem for flere af de konkurrenter der tilbyder de samme funktioner som vi på sigt vil have. En af disse fordele har vi identificeret som økonomi, altså den samlede kostpris for produktet samt en bagvedliggende infrastruktur. Den vurdering der ligger bag dette udsagn er baseret på kameraudstyr der har en professionel kvalitet, der dog ikke nødvendigvis ligger i den kostbareste ende. Det vil ikke være et problem at gøre systemet billigere, da alle moderne kameraer kan bruges, grundet de universelle tilslutningsmuligheder der er blevet en standard på dette marked. Kravene til den fulde implementation af GenPod er en server med MySQL og webserver med PHP installeret, tilknyttet et netværk, dette kan være såvel et Wide Area Network 4 eller et Local Area Network 5, samt et webcamera monteret til en computer med Microsoft Windows XP eller Vista, disse kræver at have.net 3.5 frameworket installeret, en gratis opdatering fra Microsoft. Der behøves i realiteten ikke adgang til serverens netværk, der hvor man optager, da der er mulighed for at gemme optagelsen og først udgive denne, når man så senere kobler sig på netværket. Hvis man dernæst vender opmærksomheden mod vores case omkring universitets podcasting, træder de økonomiske fordele for alvor frem i lyset. I forbindelse med vores indledende interviews, blev vi blandt andet gjort opmærksom på den dyre metode der tidligere var blevet eksperimenteret med på Aalborg Universitet, og her blev økonomi helt klart en af de afgørende faktorer, for hvorfor projektet ikke blev videreført, så man i dag ville være i stand til at se podcasts fra alle sine forelæsninger, eller bare et bredt udsnit af dem. Metoden, der blev eksperimenteret med, bestod i at forelæsningerne blev optaget med professionelt optageudstyr, heriblandt op til flere kameraer, betjent af en tekniker, som herefter redigerede lyd- og videokilder sammen til et færdigt produkt. Det står klart at det er en alt for bekostelig affære hvis det skulle udbredes til alle forelæsningslokaler. Til sammenligning vil vores system levere en økonomisk ansvarlig løsning. Med udgangspunkt i Aalborg Universitet vil den eneste nødvendige investering, udover køb af selve systemet, være investeringer i optageudstyr til optagelsen. Her vil være tale om optageudstyr til hvert undervisningslokale, inkl. auditorier, som således blev fastmonteret på et punkt hvor det kan opfange alt hver der foregår i det område hvor forelæseren normalvis bevæger sig rundt. Servere er der allerede til rådighed på Aalborg Universitets netværk, og langt de fleste forelæsere har en bærbar computer med sig, som kunne stå for selve optagelsen ned på harddisken, via vores system. Naturligvis vil dette kræve optageudstyr af en hvis kvalitet, desuden kunne man eventuelt overveje at opstille en dedikeret computer i hvert lokale, til præcis det formål at podcaste forelæsninger. Sammenlignet med det tidligere omtalte og afprøvede alternativ, er der ingen tvivl om, at set fra en økonomisk synsvinkel er GenPod en langt bedre løsning, bl.a. fordi vores system er gjort generisk ville universitetet også kunne bruge det til andre opgaver, som f.eks. fjernundervisning

49 KAPITEL 5. AKADEMISK DEL Juridiske og etiske aspekter I forbindelse med vores indledende interviews blev vi klar over der også var andre hensyn at tage i betragtning i forbindelse med podcasting, andre end de rent tekniske og kvalitetsmæssige hensyn. De juridiske og etiske aspekter omkring udgivelsen og brugen af podcast, blev nævnt under interviewene, en vinkel vi ikke umiddelbart havde forudset. I forbindelse med vores universitets-case, er der det rent juridiske spørgsmål, hvem har rettighederne til de podcasts der bliver optaget og udgivet af forelæseninger. Er det personen der udfører undervisningen eller holder et foredrag, eller er det arbejdsgiveren, i dette tilfælde universitetet. I en mere generisk sammenhæng kan denne problematik også opstå, da det er muligt at udgive andet materiale end det man selv optager. Video- eller lydfilen behøver blot at være i et bestemt format, for at den kan udgives via vores system, og dermed er det også muligt at udgive copyright beskyttet materiale, blot man har adgang til dette. Dette er ikke noget vi påtænker at ligge restriktioner på, men bør være op til den administrerende part, altså hvem der end måtte være vores kunder, og som dermed bliver ansvarlig for hvordan de bruger systemet. Dette kan dog være en problematik man skal gøre kunden opmærksom på. Etik kommer også ind og spiller en rolle, igen i forbindelse med interviewene og efterfølgende opstillede case, blev der rejst nogle problemstillinger, som falder i denne kategori. For det første kan underviseren der udgiver en podcast, ikke nødvendigvis være sikker på hvem der egentlig bliver modtageren af det podcastede materiale. Vores system understøtter at man kan begrænse sit publikum gennem lukkede grupper, som udgiveren selv skal give andre personer adgang til, men hvis det er en offentlig gruppe, kan modtageren være hvem som helst. En bekymring der har fanget vores opmærksomhed, kunne være at det ikke blot var elever der så podcastene, men også ledelsen på universitet, med andre ord ens chef. Dette kan være mindre heldigt, da dette meget nemt kan føre til en form for kontrol eller performance rating af de ansatte, som ikke er det ønskede mål. Dog kan dette værktøj også bruges til det formål, men det er klart at de ansatte i så fald skal gøres opmærksom på at denne praksis udøves, og det kan derfor være nødvendigt med en klar politik på dette område. Men selv med en politik der ikke tillader dette, kan mistanken stadig være der, og det kunne derfor være en idé med større gennemskuelighed omkring hvem der faktisk ser podcastene. Dette kunne gøres ved at indføre en log i systemet, hvilket ville være forholdsvis simpelt. Alle der ønsker at tilgå materiale i podcast databasen, skal have oprettet en bruger i systemet, og være logget ind med denne bruger, rent teknisk vil det være nemt at logge alle brugernavnene der tilgår en specifik podcast. For det andet er der det faktum at når der er kamera på vil de fleste mennesker opføre sig anderledes end normalt, dette vil også gøres sig gældende for en der podcaster sin undervisning. Der er visse hensyn at tage, eksempelvis kan det være svært at bruge humor, især mere diskrete former som ironi og sarkasme. I en normal situation står man ansigt til ansigt med modtageren og kan aflæse om denne har forstået budskabet korrekt. Dette er ikke tilfældet i en podcast, og derfor er der en risiko for at disse bliver misforstået, hvilket kan være uheldigt. Man kan måske også risikere at underviseren føler sig låst til situationen og tager hensyn til videooptagelsen, som måske ikke er optimalt i forhold til de der rent faktisk er tilstede i lokalet. I en bredere kontekst kan det også blive nødvendigt med kontrol over hvilket indhold der udgives via vores system. Udover den tidligere nævnte problematik med copyright beskyttet materiale, kan det også være nødvendigt at administrere andet indhold. Det er som sagt muligt for enhver at udgive materiale, så fremt kunden har sat systemet således op, og gjort adgangen offentlig. Det kan føre til at der bliver 47

50 5.2. REFLEKTION udgivet podcast på ens portal, med indhold man ikke ønsker at blive associeret med. Det kan være alt, f.eks. racisme eller sexuelt indhold Oplevelsesøkonomi Generelt er oplevelsesøkonomi en kategori indenfor erhversøkonomi, der beskæftiger sig med salg af oplevelser. Dette er indenfor oplevelseserhverv betegnet som bl.a. turisme, kunst, by- og regionaludvikling samt IT. Indenfor IT kaldes det en IT-baseret oplevelse og er knyttet langt tættere på selve produktionen af produktet, hvor andre oplevelser typisk ligger i markedførings- eller salgsfasen. For at sikre økonomisk succes for vores system, skal forbrugeren have en oplevelse med det. Vi skaber oplevelser ved at kombinerer det sociale, det at kommunikere med andre brugere, med det kreative, det at lave egne videoer. Dette skaber en følelsesmæssig værdi for brugeren, der derved bliver en del af et kreativt fællesskab. Samtidig er systemet delt op i to applikationer som sammen er med til at skabe en helhed, en synergi, der ikke findes ved andre systemer og derfor også er en oplevelse, fordi det er nyt, i forhold til normen. Det at vi netop har disse oplevelser er med til at differentiere vores system fra andres, hvilket kan være det der får vores system solgt. Hvis systemet skal bruges på et universitet som f.eks. Aalborg Universitet, hvor det at optage forelæsninger aldrig rigtig har været brugt, vil der også blive skabt en nye oplevelser for de studerende, der nu kan se eller gense forelæsninger når de har lyst. De ovenstående argumenter ville kunne bruges i markedsførings øjemed Case vs. generisk Systemet GenPod er bygget op omkring idéen, at det hele skal være så generisk som muligt. Dette er allerede beskrevet i afsnittet Her vil vi forklare hvordan vi har valgt at bruge en Case til at udvikle efter, for så stadig at holde systemet så generisk anvendeligt som muligt. Da systemet blev planlagt var det et krav at det var generisk, men da generisk vil sige alle muligheder, stod det os klart at det ville være for stor en mundfuld at gabe over. Derfor blev der lavet en lang liste med cases vi kunne arbejde ud fra, teste og virkeliggøre i systemet. Grundet tidspres blev tre af disse cases udvalgt, der blev lavet interviewguides til alle tre cases, så den med mest kød på kunne blive valgt. Vi kontaktede en bank, en IT-virksomhed og dele af universitets personale. Banken ønskede desværre ikke at deltage i projektet. Af de to tilbageværende cases, blev de informationer der var kommet ud af de forløbne interviews grundigt vuderet, hvor vi i forhold til IT virksomheden havde afholdt to interviews, var de informationer der var kommet til veje på dette grundlag, ikke den type informationer vi umiddelbart kunne bruge i forhold til den relaterede case. Det var forholdsvis lettere at bruge de informationer vi havde fået fra de interviews, der var blevet udført med universitets personalet. Disse interviews dækkede over bl.a. en institut leder og to undervisere, interviewene afslørede en del spændende detaljer der kunne bruges i det videre projektarbejde. Som valgt case var det os naturligt at denne skulle bruges hver gang det i projektet ikke kunne undgås at skulle være specifik, f.eks. i programmeringsfasen eller i usability fasen, hvor det grundet tidspresset ikke var muligt at lave yderligere arbejde. Vi mener dog at det er lykkedes os at trække os selv ud fra denne specifikke case hver gang vi havde arbejdet med denne, for at prøve at holde overblikket i et generisk perspektiv. 48

51 KAPITEL 5. AKADEMISK DEL Brugergrænseflade Som tidligere beskrevet i rapporten, har vi gennem udviklingen af systemet, og herunder brugergrænsefladerne for både Windows og web applikationen, taget højde for gestaltlovene. Gestaltlovene 6 forsøger at give bud på, hvordan den menneskelige hjerne opfatter sammenhænge i omverdenen. Det vi har forsøgt på, gennem gestaltlovene, er at design og funktionalitet går hånd i hånd i stedet for at modarbejde hinanden. I det følgende vil der være indsat nogle screenshots, til at illustrere eksempler på hvorledes vi har anvendt gestaltovene. Ofte vil der være anvendt flere gestaltlove i et enkelt screenshot. Gestaltlovene er som følger: Loven om nærhed Elementer der er ens eller ligner hinanden opfattes som sammenhørende. Loven om lukkethed Elementer som er lukket inde i samme ramme opfattes som sammenhørende. Loven om lighed Elementer der er ens eller ligner hinanden opfattes som sammenhørende. Loven om forbundethed og loven om linjer. Elementer der står på række eller er forbundet med linjer opfattes som sammenhørende. Der er flere gestalt love, dog er ovenstående de mest anerkendte. Loven om nærhed kommer til udtryk i figur 5.1, gennem eksempelvis overskriften og sammenhørende tekst herunder. Det er underforstået for brugeren, at overskriften ikke hører til den ovenstående tekst, da overskriften er tættest placeret på teksten under. I figur 5.2, ses eksempler på loven om lukkethed. Alle de enkelte funktioner i systemet, er lukket inde i en kasse med et tilhørende navn. Loven om lighed er også anvendt, hvilket ses på knapperne. Knapperne ligner hinanden, derfor forventer man også de agerer som en knap. Derudover skal det nævnes at en knap er et symbol som brugeren kender fra den fysiske knap udenfor den virtuelle verden. Loven om forbundethed/linjer er også anvendt på figur 5.2. Etiketten Titel og den til højre stående tekstboks, hører sammen. Dette er man ikke i tvivl om, da disse er forbundet med hinanden. De står på en vandret linje overfor hinanden, hvilket gør brugeren ved de er sammenhørende. Figur 5.3 er et klassisk eksempel på loven om lukkethed. Brugeren kan tydeligt se hvad der hører sammen pga. de sorte kasser rund om de enkelte kommentarer. Udover gestaltlovene, har vi desuden anvendt andre retningslinjer, for at opnå den bedst mulige kommunikation med brugeren. En af de første ting vi har draget fordel af, er at få systemerne til at ligne systemer, som brugeren allerede

52 5.2. REFLEKTION Figur 5.1: Screenshot af web applikation Figur 5.2: Screenshot af Windows applikation føler sig trygge i, når vi taler navigering, troværdighed og bare det simple at kunne få overblik over en given brugergrænseflade. 50