Department of Computer Science

Transkript

1

2 Department of Computer Science Aalborg Universitet Titel: ReadAllAboutIT - Udarbejdelse af et artikelstyringssystem Tema: Udvikling af programmel Projektperiode: Informatik/Datalogi 3. semester 4. september 19. december 2002 Vejleder: Jan Karlsbjerg Projektgruppe: E1-204 Mikkel Lønvig Jensen Kristian Holme Hosbond Poulsen Rasmus Schjer Brink Hinrik Atlason Rasmus Jørgensen Jens Sigurdson Rasmus Jensen Synopsis: Denne rapport behandler analyse, design, implementering og test af et Content Management system til en nyhedsportal. Systemet har til formål at gøre det nemt for medarbejderne på en redaktion, at skabe og ændre indholdet af en nyhedsportal. Vi har benyttet OOA&D, som værktøj til udvikling og strukturering af projektrapporten. Rapporten indeholder bl.a. analyse- og designdokument, som har dannet grundlag for implementeringen af systemet. Vi fik implementeret størstedelen af systemet, desværre blev vi, af tidsmæssige årsager nødsaget til, at se bort fra enkelte elementer. Nyhedsportalen er fuldt ud implementeret. 2

3 3

4 Forord Dette projekt er udarbejdet af gruppe E1-204 på Aalborg Universitet for Computer Science i perioden fra 4. september til 20. december på DAT1/INF1. Det overordnede emne i projektrammerne for dette semester er udvikling af IT-system. Herigennem skal de studerende opnå kendskab til grundlæggende teknikker til udarbejdelse af et sådant system, samt analysere, designe og teknisk realisere et Edb-system. Projektet indeholder to dele: En projektrapport og en studierapport. Projektrapporten indeholder et analyse- og et designdokument samt afsnit om brugergrænseflader, implementering og test af kode. Analyse- og designdokumentet er struktureret udfra bogen Objekt Orienteret Analyse og Design (Mathiassen et al, 2001). I studierapporten beskrives de anvendte metoder, arbejdsprocessen samt de erfaringer, vi har opnået. Vi har anvendt programmeringssproget Java, da det er det programmeringssprog, vi har modtaget undervisning i gennem SE-kurset Objekt Orienteret Programmering. Til at implementere vores brugergrænseflader har vi benyttet Swing, da det er den mest udbredte Java-pakke til udvikling af grafiske brugergrænseflader. Generelt Oplagsantal: 9 Sideantal: 99 Appendiksantal: 3 Vedlæg: CD-ROM Afsluttet: 18 December

5 INDHOLDSFORTEGNELSE 1. Systemvalg Formål Systemdefinition BATOFF kriterier Systemdefinition Målgruppen Rigt billede Beskrivelse af problemområdet Beskrivelse af anvendelsesområdet Problemområdet Beskrivelse af klassediagram: Klasser og hændelser Klassedefinitioner Artikel Skribent Billede Tekst Anvendelsesområdet Brug Oversigt Aktørspecifikationer Brugsmønstre Funktioner Funktionernes sværhedsgrad & funktionalitet Brugergrænseflader Redaktørens og journalistens interaktion med systemet Dialogform Læserens interaktion med systemet Dialogform Designdokument Kvalitetsmål Teknisk platform Udstyr Basisprogrammel Designsprog Arkitektur Komponentarkitektur Procesarkitektur Komponenter Modelkomponent Brugergrænsefladerne Skribent Beskrivelse af brugergrænsefladen til skribenten Læser Systemgrænseflade Komponenter Elementer Databasen

6 5. Implementering Klienten Afgrænsning i systemet Beskrivelse af klasser Forbindelse med database Implementering af brugergrænseflade Server Afgrænsning i systemet Beskrivelse af klasser Hjemmesiden Afgrænsning i systemet Beskrivelse Test af systemet Mockup test Opsummering af Mockup test Test af kode Test af skribentens brugergrænseflade Opsummering af test Test af hjemmeside Spørgeskema resultater Opsummering af test Studierapport Analyse Systemvalg Analyse af problemområdet Analyse af anvendelsesområdet Designbetingelser Design af arkitektur og komponenter Brugergrænsefladen Implementering Implementering af brugergrænsefladen til kunden Projektorganisering Konklusion Perspektivering Litteraturhenvisninger Bøger Websider Bilag Testbilag Mockup test brugertest Spørgeskema til gruppen

7 Del I Analysedokument 7

8

9 1. Systemvalg 1.1. Formål I en verden der styres af informationer, og hvor informationer og dermed viden er magt og hvor alt og alle efterhånden forbindes i et globalt informationsnetværk, bliver administration af informationer på Internettet af vital betydning. Der findes mange typer Content Management systemer til administration af indhold, men et fælles udgangspunkt er, at det skal være nemt for brugeren at oprette, redigere eller slette indhold. Dette projekt omhandler udviklingen af et Content Management system til mindre redaktioner. Systemet giver medarbejderne på redaktionen mulighed for at skabe og ændre indholdet på en nyhedsportal på en effektiv og nem måde. Systemet sørger for at administrere artiklerne ved at arkivere dem efter en række kriterier fastsat af artiklens forfatter. Nyhedsportalens indhold består af aktuelle artikler fra arkivet, og er opbygget på en logisk og brugervenlig måde. Som forbillede har vi kontaktet Nordjydske og studeret deres journalistiske system, der har givet os inspiration til indholdet og virkemåden af vores eget system. Systemet Nordjydske anvender, er udviklet af AM Production. For at nå målet har vi anvendt forskellige teknikker fra kurserne på DAT1/INF1 semestret, blandt andet benyttet OOA&D, som værktøj til udvikling og strukturering af projektrapporten. Rapporten indeholder blandt andet analyse- og designdokument, som har dannet grundlag for implementeringen af systemet. Ved implementeringen har vi støttet os til den præsentation af JAVA vi fik i OOP og i øvrigt søgt hjælp og information andetsteds Systemdefinition BATOFF kriterier Betingelser:

10 Systemet tillader journalister og redaktører uden erfaring med html eller edb, at skabe og ændre indholdet på en nyhedsportal. Anvendelsesområder: Journalister og redaktører sørger for, at holde nyhedsportalen opdateret ved hjælp af systemet. Læseren kan interagere med systemet ved søgning efter artikler på nyhedsportalen. Teknologi: Systemet udvikles ved hjælp af flere programmeringssprog. Systemet til journalist og redaktør bliver programmeret i JAVA. Der benyttes en MySQL database til lagring af artikler. Nyhedsportalen bliver kodet i PHP. Objekter: Artikler, billeder, læsere, websider Funktioner: Systemet giver journalist og redaktøren mulighed for at skrive en artikel, samt formatere, prioritere, og kategorisere den. Redaktøren har mulighed for at godkende artikler og publicere dem på nyhedsportalen. Systemet skal administrere antallet af artikler, deres placering på nyhedsportalen, publiceringsdato og forfatternavn. Startsiden på nyhedsportalen giver læseren mulighed for at danne sig et overblik over de seneste nyheder fra eksempelvis kategorierne indland, udland og sport. Læseren kan vælge kun at se de seneste nyheder indenfor sit interesseområde ved at vælge en bestemt kategori. Portalen tillader også læseren, at søge efter nye eller arkiverede artikler. Filosofi: Primært at udvikle et system, der gør det nemt for medarbejderne på en redaktion at skabe og ændre indholdet på en nyhedsportal. Sekundært at opbygge en nyhedsportal, hvor søgning og navigering er nemt for læseren Systemdefinition Systemet er et arbejdsredskab for en redaktion, der ønsker at publicere nyheder på en portal. 2

11 Der kræves ikke at medarbejderne har erfaring med html, da der er indbygget et tekstbehandlingsprogram, som gør det nemt at formatere tekst og indsætte billeder. Systemet skal holde styr på de enkelte artikler, og placere dem efter en række attributter, som kan fastsættes af journalisten eller redaktøren. Sekundært fungerer systemet også som serviceredskab for læseren i form af en nyhedsportal. Nyhedsportalen gør det nemt for læseren, at få et samlet overblik over seneste nyheder inden for alle eller bestemte kategorier. Læseren har også mulighed for at søge efter artikler Målgruppen Udbuddet af Content Management systemer til at administrere indholdet af en netbaseret avis er stor, men oftest er løsningerne dyre og henvender sig til større virksomheder. Vores system er tiltænkt mindre aviser og lokalblade, som ønsker en simpel løsning til at publicere nyheder på nettet, og derfor ikke ser nogen fordel i at investere i dyrt software Rigt billede 3

12 Figur 1 - Rigt billede 1. Nyheder. Kan komme fra en ekstern kilde såsom et nyhedsbureau eller en anden avis. Men en nyhed kan også opsnuses af journalisten gennem eksempelvis interviews og observation. Alle disse nyhedsstrømme danner baggrund for udarbejdelsen af en artikel. 2. Billeder. Kommer fra billedarkiv, som består af fotos taget af egne eller udefrakommende fotografer. 3. Journalist. En aktør der arbejder med at researche og derefter skabe artikler. 4. Artikel. Et nyhedsdokument der indeholder tekst og eventuelt billede. 5. Redaktør. Kan godkende artikler og publicere dem på nyhedsportalen. Redaktøren kan redigere i alle artikler i systemet, eller bede artiklens forfatter om at rette eventuelle fejl og mangler i artiklen. 6. Arkiv. Indeholder alle artiklerne. Arkivet opdeler artiklerne efter hvilket kategori de tilhører. 7. Hjemmeside. Nyhederne kan blive publiceret ved dynamiske udtræk. 8. Læser. Kan læse nyheder på hjemmesiden via sin internetbrowser. 4

13 1.6. Beskrivelse af problemområdet Systemet skal administrere artikler, billeder, skribenter og deres rettigheder i forhold til systemet. En artikel er kendetegnede ved altid at tilhøre en kategori, som eksempelvis kunne være sport. Men ikke alle nyheder har samme værdi. Det er ikke uvæsentlig om forsidens overskrift er Danmark vinder EM i fodbold 2004 eller Viborg Oldboys vinder guld. Artiklen skal derfor tildeles en prioritering, som afgør om den indeholder nok nyhedsværdi til at komme på forsiden. Kendskab til kategori og prioritet er derfor nødvendige før at systemet kan behandle artiklen og tildele den en plads på nyhedsportalen. På en nyhedsportal vil der også være behov for at tilknytte billede til artiklerne. Et arkiv holder styr på billederne efter samme princip som artiklerne. Et billede tilhører en kategori og er tilknyttet en dato, så der er mulighed for at søge efter nyeste billede indenfor et bestemt emne. I projektrapporten betegner vi journalist og redaktør som tilhørende superklassen skribent. Når skribenten er logget ind på systemet tildeles han bestemte rettigheder alt efter om han/hun er journalist eller redaktør Beskrivelse af anvendelsesområdet I et content management system som vores er der flere forskellige aktører, hvis opgaver skal understøttes af programmet. Når skribenten logger ind på systemet er der mulighed for at skrive ny artikel eller arbejde videre med en ikke-færdiggjort artikel som hentes fra arkivet. Skribenterne kan dernæst vælge en række tilstande/attributter for artiklen. Disse tilstande/attributter holder styr på artiklens status. Journalisten varetager de opgaver som tidligere er beskrevet under skribenten, mens redaktøren varetager mere administrative opgaver i forbindelse med artiklen. Redaktørens opgave består først og fremmest i at godkende journalistens artikler, med henblik på det indholdsmæssige. Dog skal redaktøren have de samme muligheder som journalisten i forhold til arbejdet med artikler. Udover dette har redaktøren mulighed for at slette artikler helt fra arkivet. Arkivets opgave består i at håndtere artiklerne, ved hjælp af de attributter som er blevet tilknyttet artiklerne. Disse attributter pålægges delvist af skribenterne og delvist automatisk. Den automatiske del foregår ved at arkivet, efter et bestemt tidsforløb, nedprioriterer artiklernes nyhedsværdi. Dermed kommer attributterne til at styre artiklernes placering i arkivet, så de nyeste og vigtigste 5

14 nyheder bliver prioriteret højere. Arkivet holder løbende øje med om der er kommet nye artikler. Desuden skal arkivet fjerne gamle artikler og arkivere dem, så de stadig kan bruges som referencer til fremtidige artikler. De førnævnte attributter giver desuden arkivet information om, hvorvidt den pågældende artikel, er klar til publicering. Det vil være muligt for skribenterne, at benytte attributterne til at søge i arkivet efter specifikke artikler. Nyhedsportalen skal publicere disse nyheder, så læseren har adgang til sidste nyt. Det foregår ved at nyhedsportalen foretager dynamiske udtræk fra arkivet, hver gang læseren går ind på forsiden, eller klikker sig videre til de underliggende sider. 6

15 2. Problemområdet 2.1. Beskrivelse af klassediagram: Figur 2 - Klassediagram Klassen artikel er grundstenen i problemområdet, da den indeholder mest information. Samtidig er den forbundet til de andre klasser. Til klassen artikel er der aggregeret en tekst. En artikel kan bestå af en eller flere tekster. Med tekst menes der eksempelvis kildetekst, citat, tekst fra nyhedsbureau eller skribentens egne tekster. Klassen billede er desuden associeret til artikel, da billederne skal fungere som selvstændige objekter i modsætning til aggregeringen tekst. Det vil sige at en artikel kan fungere uden billede, men aldrig uden tekst. Et billede kan tilknyttes en eller mange artikler. Enhver artikel er associeret med superklassen skribent, som enten kan være en eller flere journalister eller redaktører Klasser og hændelser Nu kan Klasse og Hændelseskandidaterne sammenholdes og sættes op i en hændelsestabel hvor kun klasser og hændelser der ligger inden for systemdefinitionen og er relevante for modellen af problemområdet medtages. Klasser Artikel Skribent Billede Tekst 7

16 Hændelser Artikel oprettet X Artikel arkiveret X Artikel publiceret X Artikel redigeret X X Artikel godkendt X Artikel slettet X Inddato sat X Uddato sat X Artikel udløbet X Prioritet fastsat X Kategori fastsat X Tekst indsat X X Tekst slettet X Billede indsat X X Billede fjernet X Logget ind X Logget ud X Figur 3 - Hændelsestabel 2.2. Klassedefinitioner I det følgende beskrives klasserne enkeltvis ved hjælp af tilstandsdiagram, attributter, hændelser og beskrivelser. Dog har vi ikke skønnet det nødvendigt at udarbejde tilstandsdiagram for klasserne Billede og Tekst, da de er enkle Artikel Attributter: Titel Forfatter Status 8

17 Artikel godkendt Artikel afvist Kategori Prioritet Inddato Uddato Hændelser: Artikel oprettet Artikel arkiveret Artikel publiceret Artikel redigeret Artikel godkendt Artikel afvist Artikel fjernet Inddato sat Uddato sat Dato udløbet Artikel Prioriteret Artikel Kategoriseret Tekst indsat Billede indsat Beskrivelse: En Artikel er oprettet når skribenten begynder at skrive eller indsætter tekst i systemet. Når skribenten er tilfreds, kan artiklen tildeles status som Klar, og derefter arkiveres. Dette betyder at artiklen nu er klar til at blive valideret af redaktøren. Hvis skribenten ønsker at arbejde videre med sin artikel på et senere tidspunkt, kan den tildeles status Under udarbejdelse. Når skribenten er færdig med at udarbejde artiklen, skal den godkendes af en redaktør, som henter den fra arkivet. Før artiklen kan publiceres på nyhedsportalen, skal redaktøren have givet artiklen status som Godkendt. Hvis redaktøren ikke er tilfreds, kan der tilføjes en kommentar, hvis artiklen har fejl eller mangler. Artiklen bliver derefter lagt i arkivet med status Afvist. Journalisten kan derefter redigere sin artikel, og sende den til godkendelse igen. 9

18 Artiklens inddato og uddato bestemmer hvornår en artikel publiceres på nettet og hvornår artiklen fjernes fra nyhedsportalen Artikel fjernet. Artiklen vil dog stadig befinde sig i databasen. For at sikre at artiklen får den plads på nyhedsportalen, som nyheden er berettiget til, skal skribenten markere hvilken prioritet artiklen skal have. Figur 4 - Tilstandsdiagram for klassen Artikel Hvis en artikel på den ene eller anden måde indeholder fejl, er det vigtigt at en journalist eller redaktør kan trække en artikel tilbage og rette i den (Artikel redigeret). En artikel skal have grønt lys fra en redaktør for at komme videre i systemet, og ud af klassen artikel (Artikel godkendt og Artikel afvist). 10

19 Skribent Attributter: Brugernavn Kodeord Hændelser: Logget ind Logget ud Artikel oprettet Billede indsat Tekst indsat Artikel slettet * Artikel godkendt * Artikel redigeret * (* betyder at der er forskel på rettigheder, der ligger bag for henholdsvis journalist og redaktør) Beskrivelse: Superklassen Skribent er en associering til klassen Artikel, som abstraherer over de to subklasser journalist og redaktør. Til hver skribent er der tilknyttet et brugernavn og et kodeord til at logge sig ind og ud på systemet (Logget ind og Logget ud). En journalist kan både slette og redigere en artikel, som journalisten selv har oprettet(artikel slettet og Artikel redigeret). En redaktør har, i modsætning til journalisten, mulighed for at redigere og slette i journalisternes artikler, såvel som sine egne. Redaktøren godkender også det journalisterne har skrevet (Artikel godkendt), og hvis en artikel ikke bliver godkendt kan redaktøren vælge, at redigere artikel eller sende den til redigering hos journalisten (Artikel ikke godkendt). Redaktøren kan også godkende egen artikel. 11

20 Billede Attributter: URL / dataværdi Størrelse Kategori Dato for billede Hændelser: Billede indsat Billede fjernet Beskrivelse: Klassen Billede er associeret til klassen Artikel. Dette skyldes, at det skal være muligt at anvende et billede flere gange i forskellige artikler. Typisk vil billedet tilhøre samme kategori som artiklen. Billederne i systemet er udover kategori også inddelt efter dato. Et billede kan blive fjernet fra en artikel, og byttet ud med et bedre (Billede fjernet og Billede indsat) Tekst Attributter: Tekstformatering Hændelser: Tekst redigeret Tekst slettet Tekst indsat Beskrivelse: Klassen Artikel er en aggregering af klassen Tekst. Tekst er en vigtig del af de fleste artikler(tekst indsat) derfor skal en tekst kunne tilpasses (Tekst redigeret), så den bliver mere læsevenlig, og resten kan så smides væk (Tekst slettet). 12

21 3. Anvendelsesområdet 3.1. Brug I det følgende vil systemets samspil med omgivelserne blive beskrevet i form af aktører og brugsmønstre Oversigt Aktører / Journalist Redaktør Læser Nyhedsbureau Brugsmønstre Oprettelse af artikel + + Nyhedslæsning + Korrektion + + Import af nyheder + Figur 5 Aktørtabel Aktørspecifikationer Journalist Formål: En person som er tilknyttet en redaktion. Journalistens basale behov er at kunne oprette, redigere og slette sin artikel i systemet. 13

22 Redaktør Formål: En person som er ansvarlig for en redaktion bestående af journalister. Redaktørens bestemmer om en artikel er klar til at komme på nettet. Redaktøren kan oprette en artikel, men til forskel fra journalisten kan redaktøren redigere og slette egen og andres artikel. Karakteristik: Typisk er det kun redaktøren der har ovenstående rettigheder. Redaktøren vil typisk have behov for at oprette dagens leder i systemet. Læser Formål: En person der besøger nyhedsportalen. Læserens vigtigste behov er at kunne søge og læse nyheder. Karakteristik: Aktører af denne type indeholder en bred skare af folk, med vidt forskellig erfaring med nyhedsportaler og IT generelt. Nyhedsbureau Formål: Denne aktør er ikke direkte tilknyttet redaktionen. Nyhedsbureauet sørger for, at levere rå og ubearbejdede nyheder til systemet. Karakteristik: De leverede nyheder giver journalisten overblik, og kan give basis for at udarbejde egen artikel. Eksempel: Der bliver generet en liste af de indgående nyheder i systemet efter en række prioriteringskrav. Derefter kan journalisten bruge nyhederne som informationskilder til egen artikel Brugsmønstre 14

23 Oprettelse af artikel Figur 6 - Tilstandsdiagram for brugermønstret Oprettelse af artikel. Brugsmønster: Når en journalist har skrevet sin artikel, opretter han/hun den på systemet. Artiklen er nu klar til godkendelse af redaktøren, som kan godkende eller afvise den. Når en artikel har fået det blå stempel af redaktøren bliver artiklen publiceret på nyhedsportalen. Hvis artiklen derimod bliver afvist kan redaktøren forlange den rettet, eller simpelthen lade være med at publicere den. Objekter: Artikel 15

24 Funktioner: Tilføj tekst, tilføj billede, rediger tekst, godkend artikel Nyhedslæsning Figur 7 - Tilstandsdiagram for brugermønstret Nyhedslæsning Brugsmønster: Når læseren går ind på nyhedsportalen, er der tre muligheder for nyhedslæsning. Læseren kan få sig et overblik på hovedsiden, hvor der findes aktuelle overskrifter fra kategorierne indland, udland, sport, økonomi/erhverv og lokal. Der er mulighed for at gå ind på en bestemt kategoriforside ved hjælp af en kategorimenu. Læseren kan også søge efter bestemte artikler ved at benytte søgefunktionen. Hvis læseren ikke finder interessante nyheder i oversigten kan han/hun vælge at gå ud af nyhedsportalen, og mønstret afsluttes. Hvis læseren finder beskrivelsen af artiklen interessant 16

25 kan der klikkes ind på hele artiklen. Når artiklen er læst, har læseren mulighed for enten at søge videre efter ny artikel eller gå ud af nyhedsportalen. Objekter: nyhedsoversigt, søgning, åbn/luk nyhedsportal Funktioner: vælg artikel, søg artikel Korrektion Figur 8 - Tilstandsdiagram for brugermønstret Korrektion Brugsmønster: Skribenten (journalist eller redaktør) henter en allerede publiceret artikel tilbage, for at udbedre fejl eller mangler i indholdet eller simpelthen slette artiklen helt. Når redaktøren er tilfreds med 17

26 resultatet, genpubliceres artiklen. Journalisten har dog kun mulighed for at ændre i egne artikler, hvorimod redaktøren har tilladelse til at ændre alle artikler i systemet. Objekter: ukorrigeret/korrigeret artikel Funktioner: Ret artikel, slet artikel Import af nyheder Figur 9 - Tilstandsdiagram for brugsmønstret Import af nyheder Brugsmønster: Systemet henter nyheder fra et nyhedsbureau, hvorefter de bliver sorteret efter kategori og prioritet. Journalisten kan så tage de rå nyheder, og benytte den under udarbejdelse af egen artikel. Objekter: Bearbejdet artikel, ubearbejdet artikel 18

27 3.2. Funktioner Funktionernes sværhedsgrad & funktionalitet Funktionerne er opdelt i sværhedsgrad for at skabe et overblik over hvor meget de forskellige programdele tager at implementere. Sværhedsgraden er bøjet i simpel, mellem og kompleks. Funktionerne er også blevet inddelt efter tre kendetegn, som følger. Kreation: Opdatering: Aflæsning: Funktioner med denne egenskab skaber nye genstande ud fra forvejen eksisterende data. Funktioner med denne egenskab påvirker objekter som findes i forvejen, og laver kun om på dens tilstand, for eksempel flytning eller redigering. Med Aflæsning mener vi at funktionen henter data fra en eller flere objekter i systemet. Klient Funktion Sværhedsgrad Funktionalitet Vælg billede Simpel Opdatering Tilføj inddato og uddato Simpel Opdatering Vælg udarbejdelsesstatus Simpel Opdatering Vælg artikelstatus Simpel Opdatering Vælg prioritet Simpel Opdatering Vælg kategori Simpel Opdatering Gem artikel Mellem Kreation Åbn artikel Mellem Aflæsning Formatering af tekst Simpel Opdatering Login Simpel Opdatering 19

28 Vælg billede: Skribenten har mulighed for udvælge et billede, og derefter benytte det som artikelbillede. Tilføj inddato og uddato: Bestemmer hvornår en artikel skal publiceres og fjernes fra nyhedsportalen. Vælg udarbejdelsesstatus: Skribenten vælger om artiklen stadig er under udarbejdelse, eller klar til at blive valideret. Vælg artikelstatus: Redaktøren kan bestemme om artiklen skal godkendes eller afvises. Vælg prioritet: Prioriteringssystem, der holder styr på vigtigheden af de forskellige nyheder. Vælg kategori: Artiklen skal tilhøre en bestemt kategori. Eksempelvis Udland. Gem artikel: Funktion til at gemme den nuværende artikel Åbn artikel: Funktion til at åbne en allerede eksisterende artikel og redigere i denne. Formater tekst: Formateringsmuligheder for teksten, eksempelvis fed, kursiv og understreget. Login: Login for skribenten så systemet ikke misbruges af uvedkommende. Webside Funktion Sværhedsgrad Funktionalitet Forespørgsel efter Webside Kompleks Aflæsning Søg i artikeldatabase Mellem Aflæsning Sorter efter kategori Mellem Aflæsning Vælg artikel Simpel Aflæsning Forespørgsel efter webside: Den forespørgsel der sendes, når en læser taster adressen ind på hjemmesiden eller klikker på et link på siden. Funktionen henter sideskabelonen og de relevante artikler og billeder i databasen. Søg i artikeldatabase: Søgefunktion der sætter læserne i stand til at søge efter nye og gamle artikler i databasen. Sorter efter kategori: Giver læserne mulighed for at sortere nyhederne efter kategori, så uønskede emner sorteres fra. 20

29 Database Funktion Sværhedsgrad Funktionalitet Åbn forbindelse Simpel Opdatering Opret post Simpel Kreation Slet post Simpel Opdatering Foretag søgning Kompleks Aflæsning Foretag søgning: Funktionen fortag søgning indeholder flere underfunktioner, og er derfor betegnet som kompleks. Den varetager de kald som kommer med en forespørgsel fra websiden, og finder de relevante informationer i databasen. Funktionerne er opdelt i sværhedsgrad, for at skabe et overblik over hvor megen tid de forskellige programdele muligvis tager. Vi har bestemt os for, at give hver funktion en sværhedsgrad, så vi får mere overblik over, hvordan vi bedst kan udnytte den tid, som vi giver os til kodning af vores system. Vi har også valgt at sortere alle funktionerne efter en overordnet funktionalitet Brugergrænseflader Systemet skal benyttes af tre forskellige aktører: journalist, redaktør og læser, som hver især har brug for deres egen brugergrænseflade. I forbindelse med OOA&D findes der to grundlæggende dialogformer for systemer, en funktionel og en objektorienteret. Disse to er hver for sig orienteret mod henholdsvis rutineprægede opgaver og varierede opgaver Redaktørens og journalistens interaktion med systemet Aktører af gruppen redaktør og journalist er karakteriseret ved, at de benytter systemet hver dag. Desuden er deres erfaringer med IT varierende. Vi har valgt at beskrive redaktørens og 21

30 journalistens brugergrænseflade under samme afsnit, da der kun er funktionelle forskelle på, hvorledes deres brugergrænseflade opbygges. Dette vil blive beskrevet nærmere i de følgende afsnit. Afhængigt af hvilke opgaver som skal løses, kan kravet til brugervenlighed ændre sig. Vi har valgt at definere vore krav med henblik på, at vægten ligges på effektivitet og pålidelighed: Let at bruge Systemet skal være nemt at bruge for både journalist og redaktør. Der må ikke opstå tvivl om hvordan en pågældende opgave skal løses Sikkert at benytte Systemet skal så vidt muligt begrænse antallet af fejl. Effektivt at bruge Systemet skal understøtte journalistens og redaktørens omgang med systemet, således at man opnår den mest effektive arbejdsgang med de rutineprægede opgaver Dialogform Når man skal designe en brugergrænseflade, er valget af dialogform og dialogmønstre meget vigtigt. Her skal man beslutte hvilke midler man vil benytte til at kommunikere med brugeren. Dette kunne eksempelvis ske igennem brugen af ikoner og menuer, og hvorledes brugeren giver kommando til systemet, eksempelvis igennem museklik og tastaturkommandoer. Valget afhænger meget af hvilken type bruger der er tale om, samt de opsatte krav til brugervenlighed. Under udviklingen af brugergrænsefladerne til henholdsvis redaktøren og journalisten vil det være fordelagtigt at benytte et menuvalgsmønster, for at understøtte de rutineprægede opgaver som er tilknyttet denne gruppe aktører. Et menuvalgsmønster er karakteriseret ved en liste af valgmuligheder. Disse valgmuligheder er grupperet i forskellige menupunkter, som brugeren har mulighed for at vælge ud fra. Ved brugen af et menuvalgsmønster sikrer man en forholdsvis kort indlæringstid, og desuden er det let at understøtte fejlhåndtering. Ulempen ved at benytte et menuvalgsmønster er, at der hurtigt kan opstå en række menuer, som kan virke uoverskuelige for brugeren. Dette er ikke et problem i forbindelse med systemet, da antallet af opgaver er forholdsvist lavt. 22

31 Manipulationsmønstret i programmet er baseret på Windows-standarder. Det er værd at overveje brugen af genvejstaster for at opnå en mere effektiv brug af systemet. Genvejstaster er tiltænkt de lidt mere erfarne brugere, da det vil forvirre de uerfarne brugere mere end det vil gavne. Ved at bruge velkendte Windows-standarder sikres det, at en uerfaren bruger vil føle sig mere sikker ved at benytte systemet, og dermed overordnet opnå en større effektivitet. Dette er endnu et af de opsatte mål for brugervenlighed i denne brugergrænseflade. Figur 10 Navigationsdiagram for skribenten Figur 10 Navigationsdiagrammet viser hvordan navigationen foregår for redaktør og journalist. Som udgangspunkt er der et enkelt vindue åbent, som viser en login skærm. Her logger redaktøren eller journalisten på systemet. Når der er blevet indtastet et korrekt navn og kodeord, føres der videre til vinduet Editor. Her er der mulighed for flere forskellige funktioner. Skribenten kan vælge at oprette en ny artikel. Men der kan også søges efter allerede arkiverede artikler, Søg artikel. Skribenten føres til et nyt vindue, hvor der er mulighed for at få vist en oversigt over artikler ved hjælp af søgning. Hvis skribenten eventuelt ønsker at arbejde videre med en artikel kan han hente en artikel tilbage til vinduet Editor, og har herefter mulighed for at redigere artiklen. 23

32 Hvis skribenten vælger at søge efter et artikelbillede, åbnes vinduet Billedsøgning, der giver mulighed for at søge på billeder, og derefter få vist oversigt over forekomster. Når skribenten har valgt et passende artikelbillede bliver vinduet Editor vist igen. Skribenten har nu mulighed for at sende sin artikel til arkivet. Skribenten kan også vælge at logge ud af systemet. Denne mulighed har han i alle vinduer. Når skribenten logger ud bliver han ført til vinduet Login Læserens interaktion med systemet Aktører af gruppen læser er som nævnt i aktørbeskrivelsen, karakteriseret ved at have en stor aldersspredning og et varierende kendskab til IT. Den opgave en læser skal have løst ved hjælp af systemet, er at kunne læse og søge efter nyheder. Denne opgave kan ses som en rutineopgave, man da man ikke kan være sikker på læseren har benyttet systemet før, er det derfor vigtigt at opgaverne er faste og velstrukturerede. Ud fra dette kan vi definere nogle krav til brugervenlighed: Let at bruge - Systemet skal være nemt at bruge for læseren. Der må ikke opstå tvivl om hvorvidt en pågældende opgave skal løses Let at lære Systemet skal tage hensyn til den uerfarne bruger. Sikkert at bruge - Systemet skal så vidt muligt begrænse antallet af fejl. Høj subjektiv tilfredshed En tilfreds bruger vil sandsynligvis benytte systemet igen Dialogform Vi har valgt at benytte et direkte manipulationsmønster. Denne form for mønster tilgodeser brugere af systemet, hvilket specielt er tilfældet for netop denne gruppe aktører. Et direkte manipulationsmønster er kendetegnet ved, at brugeren har mulighed for at vælge nogle objekter, identificeret ved for eksempel ikoner. Efterfølgende vil brugeren have direkte 24

33 mulighed for at udføre funktioner på disse med øjeblikkelig synlig effekt. Fordelen ved dette er, at systemet bliver let at lære og fejl undgås. Ydermere giver brugen af direkte manipulation en høj subjektiv tilfredshed hos brugeren. Figur 11 - Navigationsdiagram for læseren Figur 11 viser hvordan læseren navigerer. Når læseren åbner nyhedsportalen er der fire muligheder til rådighed. Læseren kan læse nyheder fra diverse kategorier fra hovedsiden eller foretage en artikelsøgning. Hvis læseren vælger en specifik kategori, henviser nyhedsportalen til en kategoriforside, hvor den samme funktionalitet som hovedforsiden er tilgængelig, men der kan blot læses nyheder fra den valgte kategori. Læseren kan Forlade Nyhedsportalen, hvorved navigationen afsluttes. 25

34 Del II Designdokument 26

35 4. Designdokument Formålet med dette projekt er at udvikle et system til administration og publicering af artikler på en nyhedsportal. På baggrund af de opstillede kriterier i analysedokumentet, vil vi i det følgende specificere systemets design Kvalitetsmål For bedre at kunne administrere designaktiviteten, er der opstillet et prioriteringsskema over designkriterierne. Dette giver en fælles forståelse af de krav vi stiller til edb-systemet. Brugbart Sikkert Effektivt Korrekt Pålideligt Testbart Fleksibelt Forståeligt Genbrugbart Flytbart Integrerbart Meget Vigtigt X X Vigtig X X X X X Mindre Vigtigt X Irrelevant X X Trivielt opfyldt X På baggrund af den tid vi har til rådighed har vi prioriteret designkriterierne efter vigtighed. Vi har prioriteret kriterierne brugbarhed og pålidelighed højt i brugergrænsefladerne for henholdsvis journalist og redaktør. Nøgleordene for disse har været brugervenlighed. For at gøre et system brugbart, skal det tilpasses de omgivelser og arbejdsgange som det skal indgå i. Derfor forudsætter systemet heller ikke, at skribenten kender til HTML. Brugbarhed og pålidelighed er også et væsentlig aspekt på nyhedsportalen. Her tænkes specielt på læserens brug, da denne skal have en problemfri oplevelse, så man sikrer læserens fortsatte interesse for nyhedsportalen. Kriteriet Forståeligt er prioriteret som vigtigt, da det er essentielt, at brugerne forstår systemet, og dermed er klar over konsekvenserne for en given handling i forhold til systemet. 27

36 Kriteriet fleksibel har en vigtigt prioritering med henblik på nyhedsportalen. Med få omkostninger kan man ændre udseende og indhold, alt efter typen af portal. Testbart og korrekt vurderes som vigtigt, i forhold til de krav vi har opsat for systemet og deres overholdelse, for at sikre systemet grundlag. Sikkerhed er prioriteret som vigtig, da alle data ligger på den centraliserede database. Dette kan udgøre en fare, hvis der opstår uønsket adgang til systemets faciliteter og data. Det er kun muligt at sikre systemet mod ulovlig indtrængen i form af brugernavn og password for den enkelte skribent. Vi har ikke kompetence, eller tid til at sikre os mod indtrængen udefra. Effektivitet er prioriteret mindre vigtig, da vi ikke regner med at der vil opstå flaskehalse mellem klient og server. Hvis systemet skulle implementeres på en større nyhedsportal med meget trafik, ville dette kriterium have større betydning. Genbrugbart er prioriteret som mindre vigtig. Dette skyldes, at delene i edb-systemet ikke skal genbruges i andre beslægtede edb-systemer. Kriteriet flytbart har fået prioriteringen trivielt opfyldt, hvilket skyldes, at systemet bliver udviklet ved hjælp af platformuafhængige sprog. Hvis systemet skulle flyttes til en anden platform, ville det kræve mindre modifikationer Teknisk platform I det følgende afsnit vil vi gøre rede for hvilke platforme, der kan benyttes i forbindelse med kørsel af edb-systemet. Begrundelsen for denne redegørelse ligger i, at afdække hvilke muligheder og svagheder den tekniske platform besidder Udstyr Systemet udvikles til brug af en redaktion med et antal computere (fungerende som klienter), der er tilknyttet en server. Derudover kan Internetbrugere få adgang til en hjemmeside, hvor det udvalgte publicerede materiale kan læses. Klienten udarbejdes som en Java-applet, som kan tilgås via en browser. Den fordel vi ønsker at opnå, er at få serveren til at løse nogle af de opgaver, der er i forbindelse med arbejde med artikeldatabasen, frem for at vores klientprogram skulle gøre det. En anden fordel er også at der ikke er så meget trafik mellem klienter, andre klienter og databasen. Alle forbindelser går mellem klienterne til serveren, som derefter udfører opgaverne fra klienterne, efter som de bliver modtaget af serveren. Grunden til at vi har valgt at klienten skal programmeres i Java, er at det kan køre på de fleste styringssystemer. Man behøver kun at have Javas virtuelle maskine installeret. Serverdelen programmeres også i Java, og skal køres på en stabil og pålidelig computer 28

37 for at sikre data. Det samlede systemet kan i princippet afvikles på alle platforme, da det bliver udviklet ved hjælp af de tekniske værktøjer: Java, PHP og MySQL Basisprogrammel Applet og serverdel skal implementeres ved hjælp af programmeringssproget Java 2. For at kunne køre appletten er det et krav at Java Virtual Machine og en browser er installeret. Java er et objektorienteret programmeringssprog. Derfor vil der være en direkte afspejling af analyse og designfasen i selve Java implementeringen Designsprog Analyse og designdokumentet er baseret på Unified Modeling Language (UML), som bruges i forbindelse med kurset i OOA&D. 29

38 4.3. Arkitektur Komponentarkitektur Figur 12: Komponentarkitektur for systemet 30

39 Beskrivelse af komponentarkitektur: I et system som vores, er det mest hensigtsmæssigt, at bygge det op over en klient-server-arkitektur. Den væsentligste fordel er den centraliserede datalagring, som sørger for at gøre systemet pålideligt og let at vedligeholde. En anden fordel er, at serveren er i stand til at håndtere flere klienter på samme tid. Komponentarkitekturen i vores system er åben-streng, det vil sige, at operationer i et af lagene kun kan tilgå operationer i et af de underliggende lag. Systemet er delt op i fire lag: Grænseflader, funktioner, model og den tekniske platform. Grænsefladerne er delt op i to brugergrænseflader. En brugergrænseflade til læseren og en delt til journalisten og redaktøren. Læserens brugergrænseflade har ikke nogen systemgrænseflade at kommunikere med, da læseren ikke har mulighed for direkte at påvirke systemet. Derimod har brugergrænsefladen for skribenterne (journalist og redaktøren) en systemgrænseflade, så de kan tilføje, redigere og slette data. Her skal det nævnes at redaktøren har den samme brugergrænseflade som journalisten, bortset fra at redaktøren har ekstra funktioner, som gøre det muligt at godkende artikler eller afvise dem. Disse systemgrænseflader kommunikerer med funktionskomponenten, der også er opdelt i flere dele. Overordnet er funktionskomponenten opdelt i to dele: en del til læseren og en del til skribenterne. Delen til læserne sørger for at hente de forespurgte data. Skribentdelen giver mulighed for at lagre en artikel med et tilknyttet billede. Derudover giver den også mulighed for redigering af allerede lagrede artikler. Skribentens systemgrænseflade kommunikerer direkte med databasen, når skribenten ønsker at hente en artikel til klienten. Modelkomponenten skal ved hjælp af funktionskomponenten, holde styr på de objekter, der repræsenterer problemområdet. Dette løses teknisk med en klientserver baseret på Java, der kan kommunikere med MySQL databasen. Desuden er der også en web-server, som er repræsenteret i den tekniske komponent ved hjælp af PHP og MySQL. 31

40 Procesarkitektur Figur 13: fordelingsdiagram for det centraliserede system Fordelingsdiagrammet for systemet beskriver et centraliseret klient-server mønster. Systemet består af klientserver, web-server og tre klienter. Der en klient for redaktøren og journalisten, samt læseren i form af en browser. Klientserveren stiller en række funktioner til rådighed for klienterne til journalist og redaktør, hvorimod webserveren kan udføre en række oprationer for læseren. De to klienter henvender sig til serverens systemgrænseflade, som derefter returnerer eventuelle uddata til klienten. En brugergrænseflade til klientserveren var også tiltænkt, men på grund af tidsrammen udelader vi at implementere denne. Klienterne kan tænkes på som 32

41 simple terminaler, da model og hovedparten af funktionaliteten ligger på serveren. Skribentens brugergrænseflade, begrænser sig kun til indsættelse og formatering af tekst Komponenter Udarbejdelsen af komponenterne er foregået som en iterativ proces i forlængelse af analysedokumentet. Ideelt set burde komponenterne have været endeligt færdige, inden implementeringen begyndte, således at implementeringen kunne foregå ud fra specifikationerne af komponenterne. Manglende erfaring har dog gjort, at vi under implementeringen har måttet tage komponentopbygningen op til revurdering og foretage de nødvendige ændringer. Det er de endelige reviderede komponenter, der vil blive redegjort for her Modelkomponent Under udarbejdelsen af modelkomponenten har vi ikke fundet nye klasser. Dette skyldes at klassediagrammet er blevet grundigt gennemarbejdet, i forbindelse med analysedokumentet. Figur 14: Revideret klassediagram Klasser I de efterfølgende afsnit vil klasserne i modellen blive beskrevet, og deres attributter og operationer gennemgås. 33

42 Klassen Artikel For klassen Artikel er der forholdsvis mange attributter og operationer. Hændelserne er blevet operationer. Attributten status er blevet delt i to dele, en attribut og operationen web status. Den nye operation kigger i databasen og sætter status for om artiklerne er klar til at komme på nettet. Der er tilføjet en ny attribut til klassen artikel: Artikelnummer. Artikelnummer er et unikt nummer som bruges til at identificere den enkelte artikel. Da hændelserne ikke har ændret sig i forhold til analysedokumentet forbliver tilstandsdiagrammet for klassen Artikel det samme. Tilstandsdiagrammet kan ses på figur 4. Navn Kategori Formål Inddata Betingelser Effekt Placering Involverede objekter Udløsende hændelse Opret artikel Passiv, opdatering At oprette en artikel Tekst og billede At skribenten er logget ind En ny artikel er oprettet i databasen og inddata er tilføjet deri. Artikel Artikel, Skribent, Billede og Tekst (Ingen udløsende hændelse) Figur 15 - Operationsspecifikation for "Opret artikel". Operationsspecifikationen for Artikel blev skabt ud fra det grundlag, at det er en nødvendighed med nye artikler. 34

43 Artikelens indhold Indland Kilde Udland Atributter: Forfatter Sport Kategori Billede Værdi: prioriteret Prioritet Hovedforside Udarbejdelses status Kategoriforside Inddato Normal Uddato Artikelstatus Værdi: Udarbejdelses status Webstatus Under udarbejdelse Artikelnummer Klar Opret artikel Funktioner Gem artikel Værdi: Artikelstatus Slet artikel Godkendt Rediger artikel Afvist Værdi: Webstatus Online Offline. Figur 16 - Revideret klassebeskrivelse for Artikel Klassen Skribent Klassen Skribent er en superklasse til klasserne Journalist og Redaktør. Hændelserne logget ind og logget ud er blevet til operationerne log ind og log ud. Navn Kategori Formål Inddata Betingelser Effekt Placering Involverede objekter Udløsende hændelse Log ind Passiv, opdatering At logge skribenten ind på klientsystemet Brugernavn, kodeord At de kan huske deres brugernavn og kodeord Skribenten får adgang til systemet Skribent Skribent (Ingen udløsende hændelse) Figur 17 - Operatørspecifikationen for "Log ind" 35

44 Denne operationsspecifikation blev lavet for at sikre mod uønskede artikler fra anden hånd, der kunne sætte spørgsmål ved nyhedsportalens seriøsitet. Brugernavn Atributter Kodeord Logget ind Værdi: Log ind Ja Funktioner Log ud Nej Opret artikel Hent artikel Figur 18 - Revideret klassebeskrivelse for Skribent Klassen Billede Klassen Billede har foruden de førnævnte attributter fået en ny attribut der hedder Billede ID. Billede ID er et unikt identifikationsnummer til billederne. Atributter Funktioner Filnavn Placering/sti Billede ID Billedbeskrivelse Fotograf Indsæt billede Slet billede Figur 19 - Revideret klassebeskrivelse for Billede Der er ingen operationsspecifikation for klassen Billede Klassen Tekst Klassen Tekst har fået udspecificeret attributten tekstformatering. De nye underattributter er fed, kursiv, og understreget. Navn Tekst 36

45 Kategori Formål Inddata Betingelser Effekt Placering Involverede objekter Udløsende hændelse Passiv, opdatering At redigere skreven tekst Tekst, tekstformatering At skribenten er logget ind, at skribenten har rettigheder til at rette i teksten Indholdet af Tekst objektet ændret Tekst Tekst, Artikel Rediger artikel valgt Figur 20 - Operatørspecifikation for "Tekst" Atributter Tekstformatering Værdi: Tekstformatering Størrelse (antal ord) Fed Rediger tekst Kursiv Funktioner Indsæt tekst Understreget Slet tekst Figur 21 - Revideret klassebeskrivelse for Tekst 4.5. Brugergrænsefladerne I dette kapitel gennemgås de tre brugergrænseflader som indgår i systemet. Beskrivelsen af brugergrænsefladen for henholdsvis journalist og redaktør bliver beskrevet under samme afsnit, da de to brugergrænseflader ligger tæt op af hinanden med hensyn til funktionalitet og udseende. Fokus i dette projekt ligger på klientdelen. Der er derfor også lagt vægt på udformningen af brugergrænsefladen til skribenten. De brugergrænseflader, der bliver beskrevet i det følgende, er resultatet af en lang arbejdsproces, og der kan derfor være forskelle fra de brugergrænseflader, der er blevet beskrevet i analysedokumentet. Disse har vi brugt som retningslinjer i arbejdsprocessen, men ikke som et bindende design Skribent 37

46 Som nævnt i analysedokumentet har det været vigtigt at udvikle et system, som med få omkostninger kan indgå som led til publicering af nyheder på nettet. Med få omkostninger menes der, at skribenten kan benytte systemet sikkert efter lidt eller ingen instruktion, og samtidig udføre opgaven på en effektiv måde. For at imødekomme kravet om et brugervenligt system, er det vigtigt at kende brugerne og inddrage dem i udviklingsprocessen. Gennem interviews med journalister fra Nordjyske Stiftstidende har vi fået indblik i deres arbejdsgange og miljø, og ud fra dette er der basis for at kunne designe brugergrænsefladen til skribenten. Målgruppen for systemet er bred. Systemet var fra start tiltænkt at skulle indgå som værktøj til mindre redaktioner til publicering af artikler på en nem og hurtig måde. Men systemets design forhindrer ikke i, at organisationer, interessegrupper eller lokalaviser med hver deres emner og indhold kan benytte systemet. Det skal nævnes at vi har døbt systemet med navnet ReadAllAboutIt, som henleder tankerne på de højtråbende avisdrenge i New Yorks gader Beskrivelse af brugergrænsefladen til skribenten Vi har valgt at benytte systemstandarden som kendes fra Microsoft Windows. Vi vil i vid udstrækning forsøge at bruge de samme ikoner som kendes fra Microsoft Word, da der er stor sandsynlighed for, at man som skribent har kendskab til dette eller et lignende tekstbehandlingsprogram. Ved at benytte standarder som er velkendte, vil skribenten kunne benytte systemet mere sikkert og fejlfrit. Vi har forsøgt at minimere antallet af skærmbilleder, som skribenten skal navigere igennem. Dette er for at gøre brugergrænsefladen mere overskuelig og effektiv. Brugergrænsefladen for skribenten består af tre forskellige skærme. Login Editor Artikeloversigt 38

47 Figur 22: Diagram over skribentens navigation mellem skærmbilleder I det følgende fremviser vi skærmbilleder fra skribentens brugergrænseflade. Skærmbillederne er alle lavet i billedbehandlingsprogrammet Adobe Illustrator, og må ikke forveksles med det aktuelle system. Billederne er et kompositionsmæssigt udtryk for det endelige system. 39

48 Figur 23: Skærmbillede af Login Skærmbilledet Login er det første skribenten møder før han kan logge sig ind på systemet. Hvis brugernavn og/eller kodeord er indtastet forkert melder systemet fejl. Lykkedes login føres skribenten videre til skærmbilledet Editor. For overblikkets skyld har vi valgt at dele skærmbilledet Editor op i rammer. Når de enkelte elementer bliver beskrevet vil oversigtsbilledet illustrere deres tilhørsforhold. Figur 24: Oversigtsbillede for Skærmbilledet Editor 40

49 Figur 25 Skærmbillede af Editor Her ses det skærmbillede redaktøren eller journalisten møder, når denne er logget på. Forskellen mellem redaktørens editor og journalistens, er at redaktøren her har mulighed for at godkende en artikel eller afvise den. På figur 25 ses de ekstra funktioner redaktøren har til rådighed nede i venstre hjørne under Artikelstatus. Skribentens editor er en WYSIWYG 1 html-editor, med de mest anvendte formateringsmuligheder, såsom fed, kursiv eller understreget tekst. Det er dog ikke muligt at ændre på farve eller skrifttypen, da nyhedsportalen gerne skulle bevare en hvis form for konsistens. Derudover er der også mulighed 1 WYSIWYG = What You See Is What You Get; Du får, hvad du ser ; I denne sammenhæng betyder, det at skribenten slipper for at se html kode på skærmen, men i stedet ser formateringen direkte, som det vil tage sig ud på nyhedsportalen. 41

50 for at lave hyperlinks med knappen og link med knappen. Desuden kan redaktøren også tilknytte en kommentar til journalistens artikel i tilfælde af fejl eller mangler i artiklens indhold. Dette gøres med knappen. Journalisten har også mulighed for at tilknytte en kommentar til artiklen. Tekst der er markeret med knappen, vil ikke være synligt på nyhedsportalen. Før ovenstående knapper kan bruges til noget, er det nødvendigt at markere det tekststykke, man ønsker skal laves til eksempelvis en kommentar eller et link. Disse har vi valgt at karakterisere som ikke vigtige. Deres implementering er ikke afgørende for editorens brugbarhed. De vil kun blive implementeret i tilfælde af, at vi har den fornødne tid dertil. Før en artikel kan sendes til databasen skal skribenten sørge for at tildele den en række attributter. De tildelte attributter bestemmer hvor og hvornår siden skal vises på nyhedsportalen. I venstre side af editoren, har skribenten mulighed for at vælge hvilken kategori artiklen tilhører ved hjælp af en dropdown menu. Kategorierne er: Indland, Udland, Lokal, Erhverv/Økonomi og Sport. Ikke alle artikler indeholder samme nyhedsværdi til at komme på hovedforsiden. Under dropdown menuen prioritering er der tre valgmuligheder. Hovedforside, Kategoriforside og Normal. Når en artikel har prioriteringen Hovedforside bliver artiklen vist på hovedforsiden, men også på kategoriforsiden. En artikel med prioriteringen Kategoriforside, bliver kun vist på kategoriforsiden. Normal vil placere artiklen i en oversigt over artikler med den pågældende kategori. Skribenten kan også vælge hvornår en artikel publiceres på nyhedsportalen, og hvornår den skal fjernes igen. Dette gøres ved at sætte artiklens inddato og uddato. Det hænder eksempelvis, at journalisten, efter færdiggørelse af artiklen, først ønsker at publicere den et par dage efter. Hvis skribenten ikke udfylder felterne for inddato og uddato, vil artiklen være klar til publicering med det samme. 42

51 Figur 26: Udsnit af skærmbilledet Editor Før redaktøren kan kende forskel på om en artikel er klar til validering eller stadig er under udarbejdelse, skal skribenten sætte status for udarbejdelsen. Hvis skribenten ønsker at arbejde videre med sin artikel på et senere tidspunkt, skal han trykke på Under udarbejdelse. Er skribenten derimod tilfreds med sin artikel, skal udarbejdelsesstatus sættes til Klar. Artiklen er nu klar til at blive valideret af redaktøren, som enten kan godkende eller afvise den. Hvis skribenten ønsker at tilknytte et billede til artiklen kan det gøres ved hjælp af knappen Søg efter artikelbillede i skærmbilledet Editor. Et nyt vindue vil poppe op og skribenten har mulighed for at indtaste et søgeord som både kan være et ord, som indgår i beskrivelsen der er tilknyttet ethvert billede eller navnet på fotografen. Forekomsterne på ordet vil efter søgning blive vist som små miniaturebilleder, så skribenten bevarer overblikket. Når skribenten mener at have fundet et passende billede til artiklen, klikkes der på billedet eller på navnet. Herefter popper et nyt vindue op med den fulde størrelse af det valgte billede, dog uden at lukke oversigten af miniaturebilleder. Skribenten kan derefter klikke på knappen Benyt som artikelbillede, eller kigge videre i billedoversigten. Begge popup-vinduer vil herefter blive lukket automatisk, og billedets ID nummer vil efterfølgende blive vist i tekstfeltet Billede ID, som vist på skærmbilledet Editor. 43

52 ReadAllAboutIt Udvikling af et artikelstyringssystem nn Figur 27: Pop-up vinduer ved billedsøgning Hovedmenuen er altid synlig når skribenten er logget ind. Dette gælder både når skribenten befinder sig i skærmbilledet Editor og skærmbilledet artikeloversigt. Knappen Skriv ny artikel henviser til editoren, som nulstiller hver gang der trykkes. Knappen Log ud henviser til Skærmbilledet Login. Figur 28: Hovedmenu Klikker man på Søg efter artikel vil man blive henvist til skærmbilledet Artikeloversigt hvor man har mulighed for at finde en artikel ved at sortere databasen efter en række kriterier. 44

53 Figur 29 Artikel oversigt En del af redaktørens arbejde er at godkende artikler som kvalificerer sig til at blive vist på nyhedsportalen. Redaktøren kan hurtigt få en oversigt over de artikler, der ligger klar til at blive valideret, ved at vælge Ikke-godkendt i rullemenuen. Forekomsterne ved denne søgning er alle de artikler, som ikke er blevet godkendt af redaktøren endnu. Ikke-godkendte artikler kan have status som Klar, Under udarbejdelse eller Afvist. Alle artikler der er klar til validering vil blive vist i blåt. Redaktøren kan markere den artikel, der skal til godkendelse, trykke på en knap, og derefter bliver artiklen hentet ind i editoren. Så længe en artikel befinder sig i editoren, er det ikke muligt for eksempelvis forfatteren, at hente sin artikel fra artikeloversigten. Journalisten har rettigheder til hente artikler fra artikeloversigten ind i editoren, men kan ikke ændre på andet end sine egne artikler. 45

54 Når redaktøren skal godkende en artikel foregår det via editorvinduet. Her kan redaktøren vælge at godkende eller afvise en artikel. Figur 30: Udsnit af skærmbilledet Editor (Redaktørens klient) Læser Et fælles træk for mange netaviser og nyhedsportaler er valget af layout og struktur, som stort set ikke afviger fra hinanden. I stedet for at opbygge en ny struktur, har vi kigget en række danske netaviser 2 over skulderen. At vores nyhedsportal ikke afviger fra standarden, støtter yderligere læseren, da viden om navigationen kan overføres fra en lignende nyhedsportal til et andet. Brugervenlighedseksperten Rolf Molich skriver i sin bog Brugervenlige Edb-systemer, at anvendelsen af standard medfører kortere indlæringstid, færre fejl, øget selvtillid og mindre behov for hjælp hos brugeren. (Molich 1999: 136) Nyhedsportalen bliver holdt i ganske få afdæmpede farver, så læseren ikke distraheres i sin nyhedslæsning. Baggrunden er holdt i hvidt med en sort sans serif skrifttype til tekst, så artiklerne fremstår tydelige og læsevenlige. Nyhedsportalens hovedside består af de seneste nyhedsoverskrifter indenfor en række emnekategorier. Hvis læseren finder en overskrift interessant kan hele artiklen læses ved at klikke på overskriften eller læs mere, hvorefter hele artiklen vises. Til en artikel er ofte tilknyttet et billede, som af pladshensyn skaleres ned til en fastsat størrelse, men kan ses i sin fulde størrelse ved at klikke på det. I venstre side henviser en menu til de forskellige kategoriforsider. 2 Vi har hentet inspiration fra og 46

55 Figur 31: Skærmbillede af hovedsiden En kategoriforside ligner hovedsiden blot med den undtagelse, at alle nyhederne kun tilhører den valgte kategori. For at sikre at læseren hele tiden er bevidst om sin position på nyhedsportalen bliver den valgte kategori vist i en anden baggrundsfarve, end resten af kategorierne. Ved enten at trykke på Forside øverst i menuen eller på nyhedsportalens log, kan læseren komme tilbage til hovedsiden/forsiden. Læseren har også mulighed for at foretage en søgning. Når læseren har indtastet et ord, søges der både i nye og arkiverede artikler. Læseren har mulighed for at vælge en specifik kategorisøgning og kan søge på ord i tekst eller titel. De fleste nyhedsportaler har spaltedelt layout ligesom den trykte udgave. En undtagelse er Berlingske Tidendes internetavis ( hvor hver enkelt nyhed står på hver sin række. Valget er faldet på denne type layout, da informationerne ikke virker sammenpressede eller uoverskuelige, som det kan have tendens til på netaviser med spaltedelt layout. I henhold til analysedokumentet er det hensigten at opbygge en enkel og overskuelig side. 47

56 4.6. Systemgrænseflade Vores system består af fire komponenter, disse komponenter er database, server, klientprogram og webside. Hvordan disse komponenter interagerer med hinanden viser vi under afsnittet om komponentarkitektur. I det følgende afsnit vil der blive gennemgået, hvordan strukturen for komponenter og elementer er opbygget Komponenter Figur 32: Komponentoversigt Databasen: Kan kommunikere med serveren, nyhedsportalen og med klienten på databasesproget MySQL. Serveren: Denne del er programmeret i Java og har ved hjælp af det indbyggede SQL bibliotek (java.sql) mulighed for at kommunikere med vores MySQL database. Al kommunikation med klienten forgår via Java sproget. Klientprogram: Vores klient er en Java applet som kommunikerer med serveren og siger hvilke poster den vil hente, gemme eller redigere. 48

57 Websiden: Nyhedsportalen kodes i det dynamiske scriptsprog PHP. Nyhedsportalen er bygget op som en skabelon, hvor kun indholdet ændrer sig. Det har den fordel at nyhedsportalen er nem at opdatere, og gør det nemt at holde et konsistent layout. Nyhedsportalen henter artiklerne i databasen. Nyhedsportalen indeholder også en søgefunktion, der ud fra nogle søgekriterier kan vise en liste over de artikler, søgningen passer til. Figur 33 - Oversigt over dataveje På ovenstående figur er systemgrænsefladekomponenterne for klienten, serveren og databasen med alle nødvendige klasser og hændelser illustreret. I klienten kan der oprettes en ny artikel eller indlæses en eksisterende artikel med tilhørende tekst, attributter og eventuelt et billede. Når skribenten vil lægge en post i arkivet, går det igennem serveren, der betragter tekst, billeder som en tabel, hvor hver række i tabellen indeholder en værdi, der er knyttet til artiklen. Tabellen tilhører nu klassen Artikel med tilhørende attributter og hændelser. Når skribenterne henter en artikel fra databasen, kan der redigeres i den eller laves om på dens tilstand. 49

58 Elementer I det følgende beskrives de enkelte funktioners objekter og algoritmer for klientens og serverens systemgrænseflade. 3 Klient Funktion Objekt Algoritme forklaring Login Funktion bestembruger Hvis brugeren er redaktør og har indtastet korrekt brugernavn og kodeord, åbnes redaktørens klient. Hvis brugeren er journalist og brugernavn og kodeord er korrekt, åbnes journalistens klient. Brugernavn og kodeord tjekkes i en tabel i databasen Søg efter artikel Åbn artikel (knappen: Søg efter artikel) + Artikel oversigt (nyt vindue, Figur 29 Artikel oversigt) Ud fra brugernes input kriterier, bliver der genereret en liste fra databasen over de artikler som kriterierne passer med. Efter visning af artiklerne, bliver den enkelte post/artikel ved et dobbeltklik, læst ind i klientprogrammet, som så fordeler de forskellige attributter og data til klientens GUI Server Funktion Objekt Algoritme Send artikel Funktion sendartikel + Funktion svarklientsend + web status Sender og gemmer tabellen som indeholder artiklens data og attributter i arkivet og sender en bekræftelse eller fejlmelding til klienten. Hvis det er gået godt køres funktion: Webstatus for at finde ud af om artiklen skal på nettet. (beskrives længere nede) 3 Vi har generaliseret og kaldt tekst og billeder for data. Dette gælder kun de to nedenstående tabeller. 50

59 Lås/ lås op for artiklens redigering Lås, Lås op Hvis klienten har sendt en anmodning om få lov til at redigere i artiklen, tjekkes først om det er journalisten egen artikel eller en andens artikel. Hvis det ikke er artiklens forfatter, sendes der svar tilbage om, at det ikke kan lade sig gøre. Kun hvis pågældende var redaktøren eller forfatteren til artiklen gås der videre til næste trin. (Tjekket foregår ved at sammenligne artiklens ID og brugeren med forfatteren). Dernæst tjekkes der i en tabel, om der er andre, som har åbnet den pågældende artikel. Er der en anden skribent, der har åbnet artiklen, gives der besked om, at den er under behandling, og derfor ikke kan åbnes. Hvis der ikke er andre brugere, som har åbnet for redigering af artiklen, oprettes der, i en tabel, en post, hvori der er inkluderet, at en artikel med det ID er låst op og hvem, som har låst op for redigering. Når der så sendes en besked fra klienten om at artiklen igen skal låses, fjernes posten i tabellen, hvor der står at artikel er låst op. Tjek artiklens web status web-status En gang i døgnet efterses artiklernes inddato og uddato, for derefter at publicere nye artikler og sortere gamle fra. Dette foregår ved, at man først sætter alle artiklers web-status, hvor den nuværende dato ikke er lig med artiklens publiceringsdato og udløbsdato, til offline,. Derefter sættes web-status til online hvor den nuværende dato er mellem artiklens inddato og uddato. Derefter sættes web-status til offline 51

60 for de artikler hvor artikelstatus ikke er godkendt Databasen Vores database er opbygget af tre tabeller. Den ene benyttes til at holde styr på artiklerne og de tildelte attributter. Den anden til at holde styr på billederne og den tredje til at holde styr på brugerne. Tabellen artikler indeholder følgende kolonner: Attributter Datatype Handling Indhold tekst text Hovedteksten til artiklen ind date Inddato (Publiceringsdato) ud date Uddato (Udløbsdato) Forfatter varchar(30) Forfatternavn titel varchar(30) Titel kilde varchar(20) Kilde billede int(6) Billede associeret til artikel prioritet varchar(15) Prioritet (Hovedforside, kategoriforside) webstatus tinyint(1) Online/Offline id int(11) Auto nummerering Artiklens ID interntilstand Kategori Klar varchar(17) varchar(30) int(1) Om artiklen er godkendt eller afvist. Indland, Udland, Lokal, Sport, Erhverv og økonomi, Sport. Om artiklen er under udarbejdelse eller klar Her er det id, som er primærnøgle Datatypen, som står ud for hver attribut, er valgt for at optimere databasen, men også for at undgå fejl. Datatypen text er valgt for de attributter som indeholder større mængde tekst, hvilket vores indhold af artiklen gør. Datatypen date er valgt da den indeholder en standard datoformat, som man kan bruge til at beregne ud fra. 52

61 Datatypen varchar, er valgt for de datatyper som ikke indeholder ret mange tegn. Således er forfatter og titel sat til højst at fylde 30 tegn. Datatypen int, er brugt i datatypen id, da den kun arbejder med tal. Den er også brugt under billede, fordi det tal der er indsat som attribut til artiklen er en reference til det billede, som ligeledes har en ID, som er int. Datatypen tinyint er brugt for webstatus, da denne kun veksler mellem 1 og 0. 1 for at være online og 0 for at være offline Tabellen billeder ser således ud: Attributter Datatype Handling Indhold id int(6) Auto nummerering Billedes unikke ID sti Tinytext Stien til billedes placering beskrivelse Tinytext En beskrivelse af billedet Fotograf Varchar(30) Billedets fotograf Her er det id, som er primærnøgle Her er der igen valgt attributter på samme begrundelse som ovenstående Datatypen tinytext er valgt for de attributter som ikke er en længere tekst, men som alligevel kan være forholdsvis lang. Tabellen for brugerne af klientprogrammet: Attributter Datatype Handling Indhold id int(4) auto_increment Brugernes ID brugernavn varchar(10) Brugernavnet til journalisten/redaktøren kodeord varchar(8) Deres adgangskode niveau forfatternavn int(1) varchar(30) Hvilket niveau de har. Niveau 0 er journalist og niveau 1 er redaktør. Det fulde navn på forfatteren. Igen er det attributten ID der er primærnøgle Brugernavnet er sat til max at fylde 10 tegn. Dette kan dog ændres men er ikke anset for at være nødvendigt. 53

62 Del III Implementering 54

63 5. Implementering I dette afsnit af rapporten vil vi beskrive hvilke dele af designet, der er blevet implementeret. Systemet er som tidligere nævnt implementeret i Java. Vi har fra starten af implementeringen, koncentreret os om hvordan vi kan få sendt og hentet information fra et sted til et andet, samt at lave en editor, som kan formater noget tekst. Alt data skal lagres i en database. Det følgende afsnit er delt op i tre. En beskrivelse af klienten, en af serveren og en af nyhedsportalen. Selve implementeringsdelen har haft stor betydning for designet og det endelige system, da vi i implementeringsfasen fandt ændringer og tilføjelser i system, som dette afsnit blandt anden vil være med til at belyse Klienten Afgrænsning i systemet Under implementeringen var vi nødt til at realisere, at der var ting, som vi ikke ville nå at implementere i systemet. For klienten gælder der, at vi kun nåede at lave tre formaterings muligheder: Fed, kursiv, og understregning. Vi fik således ikke implementeret link-funktionen og kommentar-funktionen. Der er blevet tilføjet funktioner til redigering af teksten: klip, kopier og sæt ind. Det lykkes os ikke at få appletten til at kommunikere med et andet netværk. Det skyldes muligvis at de fleste systemer, som standard er sat op til, ikke at give appletter lov til at kommunikere ud over deres lokale netværk og kun ved at ændre rettighederne på disse maskiner, kan man give appletter lov til at kommunikere med et eksternt netværk. En anden funktion, der skulle vise et vindue indeholdende en oversigt over billeder, man ville vedlægge sin artikel, blev heller ikke implementeret på grund af tidsmangel Beskrivelse af klasser I dette afsnit vil der blive forklaret hvilke klasser, der er i systemet, inden for klientdelen, samt eksempler på Figur 34 - Screenshot from udviklingsværktøjet BlueJ 55

64 hvordan vi har implementeret nogle vigtige dele af systemet. I klienten har vi implementeret fire klasser: logind : Bruges i forbindelse med at logge skribenter ind i systemet soeg : Bruges i forbindelse med at søge efter en artikel i databasen og sende artiklen til skribenteditoren img : Bruges i forbindelse med at søge gennem billederne i databasen og tilføje dem som attribut til artiklen klient : Selve skribenteditoren, som varierer efter hvem man er logget ind som (journalist eller redaktør), og som indeholder de funktioner, der kan kommunikerer med serveren og databasen Forbindelse med database Det første vi vil beskrive, er hvordan vi har lavet en forbindelse til vores MySQL database. Det er opbygget som følgende: Connection con; Statement st; Class.forName("org.gjt.mm.mysql.Driver"); con = DriverManager.getConnection("jdbc:mysql://fyr.cs.auc.dk/test?user=grp204&passwor d=gogogo"); st = con.createstatement(); Her bruger vi en MySQL driver, som giver mulighed for at kommunikere med en database. Derefter forbinder vi til databasen via JDBC. I dette tilfælde til en server på fyr.cs.auc.dk, med brugernavnet grp204 og kodeordet gogogo Log ind funktion Vores login funktion henter information fra inputtekstfelterne, og tjekker om deres indhold stemmer overens med de brugere, der er lagt i databasen. ResultSet rs = st.executequery("select * FROM brugere WHERE brugernavn = '"+ verifybruger +"'"); while (rs.next()){ String verifypasscheck = new String(rs.getString("kodeord")); Collator col = Collator.getInstance(Locale.US); if (col.compare(verifypass, verifypasscheck) == 0){ feedback.settext("fundet..."); klient.forfatternavn = (rs.getstring("forfatternavn")); niv = rs.getint("niveau"); JApplet klientappl = new klient(); JFrame frameklient = new JFrame("ReadAllAboutIt - "+ rs.getstring("forfatternavn") +""); 56

65 frameklient.getcontentpane().add(klientappl); frameklient.setsize(900, 500); klientappl.init(); klientappl.start(); frameklient.setvisible(true); if(rs.getint("niveau") == 1){ klient.rbr1.setvisible(true); klient.rbr2.setvisible(true); }else{ klient.rbr1.setvisible(false); klient.rbr2.setvisible(false); } }else{ feedback.settext("brugernavn eller kodeord er forkert!!"); }} Er Brugernavnet og kodeordet ens, skrives der fundet og et nyt vindue indeholdende skribentens editor bliver åbnet. Hvis de ikke er ens skrives der "Brugernavn eller kodeord er forkert!!" Derudover hentes rettighedsniveau også på brugeren. Er de 1, vises der nogle flere funktioner (til redaktøren) og er de 0, bliver disse ekstra funktioner ikke vist: setvisible(false) (til journalisten). Søgefunktion Vores søgefunktion er lavet således, at der er oprettet en tabel, hvori resultatet fra søgning bliver hentet ind. Derefter kan man, ved først at klikke på en række og derefter på knappen Åben valgte, få sendt den valgte artikels ID videre til editoren, som indsætter resultaterne i de forskellige felter i editoren. Her er et mindre eksempel, på hvordan vi har implementeret dette: Object[][] data ={ {new String(), new String()},}; String [] columnames = {"Id", "Kategori",}; JTable table = new JTable(data, columnames); JLabel label = new JLabel(); public void init(){ kategoriopen.additem("vælg kategori"); kategoriopen.additem("indland"); kategoriopen.additem("udland"); ActionListener al1 = new ActionListener() { public void actionperformed(actionevent e1) { Collator col = Collator.getInstance(Locale.US); String kategori_str = new String(); 57

66 if (col.compare(kategoriopen.getselecteditem(), "Vælg kategori") == 0){ kategori_str = " ";} if (col.compare(kategoriopen.getselecteditem(), "Indland") == 0){ kategori_str = " AND kategori = 'indland' ";} if (col.compare(kategoriopen.getselecteditem(), "Udland") == 0){ kategori_str = " AND kategori = 'udland' ";} //Database forbindelse.. ResultSet rs = st.executequery("select * FROM temp_artikel WHERE id <> 0 "+ kategori_str +" "); for (row = 0; row <= 14; row++){ if (rs.next()) { table.setvalueat(rs.getstring("id"), row, colum); colum++; table.setvalueat(rs.getstring("kategori"), row, colum); colum++; String s = new String(rs.getString("id")); klient.artikelid = rs.getstring("id"); colum = 0; //Database forbindelse.. ResultSet rs2 = st2.executequery("select * FROM temp_artikel WHERE id ="+ id +""); Collator col2 = Collator.getInstance(Locale.US); if (rs2.next()){ if (col2.compare(rs2.getstring("kategori"), "indland") == 0){ klient.kategori.select("indland");} if (col2.compare(rs2.getstring("kategori"), "udland") == 0){ klient.kategori.select("udland");} rs2.close(); con2.close(); Først bliver der lavet en tabel, med to kolonner. Derefter er lavet de søgekriterier der er mulighed for at benytte. Så laves der en if sætning, der skal vise de artikler, hvis if sætninger bliver opfyldt inden for den pågældende kategori. Derefter vises alle de artikler, hvis ID ikke er lig med nul + eventuelle kriterier. Grunden til at vi har valgt kriteriet WHERE id <> 0, er fordi det der kommer efter, er noget som kan tilføjes som kriterium, og med WHERE id <> 0, får vi vist alle artikler, hvortil der kan tilføjes nogle kriterier til SQL-kaldet. Det er således samme kald man bruger, når man tilføjer et billede til en artikel Forbindelse med anden applikation Når en artikel skal sendes til databasen, sendes informationerne gennem en server som så sørger for at få det gemt. Her er et eksempel: try{ InetAddress addr = InetAddress.getByName(null); System.out.println("addr = " + addr); Socket socket = new Socket(addr, 8001); System.out.println("socket = " + socket); PrintWriter out = new PrintWriter( new BufferedWriter( 58

67 new OutputStreamWriter( socket.getoutputstream())), true); ObjectOutputStream oos = new ObjectOutputStream(socket.getOutputStream()); oos.writeobject(h); Der oprettes først en åben socket forbindelse, i dette tilfælde til Localhost, på socket Klienten er ligeledes sat op til at modtage information fra serveren, hvis der skulle opstå fejl. Disse meddelelser få brugeren som popup beskeder, som det også er kendt fra Word. Hvis der ikke sker noget, er det en fejl med at få forbindelse til serveren. Dette har vi lavet på følgende måde: String str = in.readline(); if (true) { if (str.equals("gemt")){ JFrame frame = new JFrame("System melding!"); JOptionPane op1 = new JOptionPane(); op1.showmessagedialog(frame,"artiklen er gemt"); } if (str.equals("ikkegemtclass")) { JFrame frame = new JFrame("System melding!"); JOptionPane op2 = new JOptionPane(); op2.showmessagedialog(frame,"der opstod fejl vedrørende driveren"); } if (str.equals("ikkegemtsql")) { JFrame frame = new JFrame("System melding!"); JOptionPane op3 = new JOptionPane(); op3.showmessagedialog(frame,"der opstod fejl vedrørende databasen"); }} }catch(ioexception e){ JFrame frame = new JFrame("System melding!"); JOptionPane op4 = new JOptionPane(); op4.showmessagedialog(frame,"kan ikke få forbindelse med serveren"); } Sende informationen til serveren Når dataen skal gemmes, bliver de først gemt i en hashtabel, der så sendes videre som et objekt videre til serveren. Hashtable h = new Hashtable(); h.put("kategori", kategori.getselecteditem()); h.put("kilde", kildefield.gettext()); 59

68 Først oprettes der en hashtabel, hvorefter de enkelte værdier, som er hentet i de forskellige felter i, klienten lægges ned i hashtabellen, med hver deres nøgle. Det gør det nemmere at benytte informationerne senere, frem for hvis det havde været et array eller en stack, vi havde sendt af sted Implementering af brugergrænseflade I det følgende vil der blive beskrevet, hvordan brugergrænsefladen til klienten er lavet. Teknologi og Udviklingsværktøjer Vi har valgt at bruge JFS swing til at udvikle brugergrænsefladerne. Det er en meget udbredt Javapakke til udvikling af grafiske brugergrænseflader. Swing stiller nogle muligheder til rådighed, som gør at man kan lave grænseflader, der kan interagere med brugere via mus og keyboard. Som udviklingsværktøj har vi valgt BlueJ, som det program hvor vi har samlet stumperne fra de forskellige komponenter, der er lavet. Nogle komponenter blev udviklet i værktøjet JBuilder. Brugergrænsefladen til hjemmesiden vil blive beskrevet senere. Til at styre layoutet har vi valgt at bruge boxlayout til at opbygge vores brugergrænseflade. Et eksempel på hvordan vi har gjort dette kan ses her: Box bh1 = Box.createHorizontalBox(); bh1.add(browsearkiv); bh1.add(logud); bh1.add(box.createrigidarea( new Dimension(45,0))); bh1.add(boldbutton); bh1.add(italicbutton); bh1.add(underlinebutton); Box bh2 = Box.createHorizontalBox(); bh2.add(box.createrigidarea( new Dimension(670,30))); bh2.add(okbutton); Box bv1 = Box.createVerticalBox(); bv1.add(editor); bv1.add(new JScrollPane(editor)); Box bv2 = Box.createVerticalBox(); Container cpklient = getcontentpane(); cpklient.add(borderlayout.north, bh1); cpklient.add(borderlayout.south, bh2); cpklient.add(borderlayout.center, bv1); cpklient.add(borderlayout.west, bv2); cpklient.add(borderlayout.east, bv3); 60

69 Som det ses er layoutet bygget op i fem afsnit: North, South, West, Eeast, Center, og det er inde for disse områder, at de grafiske funktioner og knapper bliver sat ind. Som tidligere fortalt er forskellen mellem redaktørens og journalistens loginskærm, at der med redaktørens login er to funktioner mere end journalisten. Dette er lavet ved at sætte setvisible(true/false), for de knapper det omhandler Server Afgrænsning i systemet Her måtte vi afgrænse lidt med henblik på at få en timer funktion til at virke. Den funktion, der skulle få serveren til at udføre et tjek på, om artiklerne stadig skulle have samme status på hjemmesiden og udføre det hver dag kl. 00:00. Tilsvarende har der været et par problemer med klient programmet. Søgefunktionerne fungerer fint på nær søgning på webstatus. Det andet problem har været med reload af programmet, hvilket heller ikke har kunne lade sig gøre idenfor tidsrammen. I det kommende afsnit vil vi kun beskæftige os med at beskrive nogle af de funktioner, som vi nåede at implementere, og som kan være interessant at forklare Beskrivelse af klasser Serveren er bygget op omkring en klasse, som indeholder alt information om hvad den kan, og hvordan den gør det. Modtagelse af information fra applet For at få serveren til at modtage information, er den sat til at lytte efter, om der er nogen der kontakter den. Derefter laves der en socket forbindelse til den applet, hvor dataen modtages, som en hashtabel, og så bliver pakket ud: //socket forbindelse try{ ObjectInputStream ois = new ObjectInputStream(socket.getInputStream()); Hashtable hash = (Hashtable)ois.readObject(); String titel = (String)hash.get("titel"); String tekst = (String)hash.get("tekst"); String kilde = (String)hash.get("kilde"); String indstr = (String)hash.get("ind"); 61

70 String udstr = (String)hash.get("ud"); String kategori = (String)hash.get("kategori"); String prioritet = (String)hash.get("prioritet"); String interntilstand = (String)hash.get("interntilstand"); String klar= (String)hash.get("klar"); String forfatter = (String)hash.get("skribent"); String id = (String)hash.get("id"); java.util.date nydato_ind = new java.util.date(dateformat.short); java.util.date nydato_ud = new java.util.date(dateformat.short); Her var vi nødt til at konvertere datoformatet til SimpleDateFormat("yyyy-MM-dd"), for at kunne sende ind og ud videre til MySQL databasen: try{ SimpleDateFormat dformat = new SimpleDateFormat("yyyy-MM-dd"); dformat.setlenient(false); nydato_ind = dformat.parse(indstr); nydato_ud = dformat.parse(udstr); }catch(parseexception p){ System.out.println("error p"); } java.sql.date ind = new java.sql.date(nydato_ind.gettime()); java.sql.date ud = new java.sql.date(nydato_ud.gettime()); Der efter bliver dataene sendt videre til MySQL databasen: //databaseforbindelse. String string = new String(); int li = id.length(); int ls = string.length(); if (li == ls){ int i = st.executeupdate("insert INTO temp_artikel(forfatter, titel, ) VALUES ('"+ forfatter +"','" + titel + "'. +"')"); }else{ int i1 = st.executeupdate("update temp_artikel SET titel ='"+ titel +"' WHERE id = '"+ id +"'"); int i2 = st.executeupdate("update temp_artikel SET tekst ='"+ tekst +"' WHERE id = '"+ id +"'"); int i9 = st.executeupdate("update temp_artikel SET klar ='"+ klar +"' WHERE id = '"+ id +"'");.. Her bliver der lavet en ny artikel i databasen med de nye data, forudsat at den ikke har noget ID. Hvis artiklen har en ID, bliver der kørt en opdatering på felterne. Afhængig af hvordan det går, bliver der sendt en statusrapport tilbage til appletten. Opdater webstatus Da artiklerne også kan bliver for gamle og skal af nettet, og ned i arkivet er der lavet en funktion til at opdatere artiklernes webstatus: st.executequery("update temp_artikel SET webstatus = 0 where curdate() NOT BETWEEN ind AND ud"); 62

71 st.executequery("update temp_artikel SET webstatus = 1 where curdate() BETWEEN ind AND ud "); st.executequery("update temp_artikel SET webstatus = 0 where interntilstand <> 'godkendt' "); Ideen med den funktion er, at den første sætter alle artiklers webstatus til 0 (offline) hvor den nuværende dato på serveren ikke er imellem ind og ud dato. Derefter sættes webstatus til 1 (online), for de artikler hvor den nuværende dato er mellem ind og ud dato. Det sidste tilfælde skal dække den mulighed, at der er nogle artikler som ikke er godkendt. Her sættes webstatus nemlig til 0, for de artikler der ikke der har værdien godkendt i attributten interntilstand Hjemmesiden I denne del vil vi beskrive nyhedsportalen og hvordan den er blevet implementeret. Nyhedsportalen skal kunne hente de gemte artikler fra vores database og præsentere dem på nettet. Strukturen på siden er lavet med HTML, den dynamiske udtrækning af data fra databasen er skrevet med PHP og selve udseendet af siden er lavet ved hjælp af Cascading Style Sheet (CSS) Afgrænsning i systemet På grund af tidsrammen er der forskellige funktioner som ikke er nået med på nyhedsportalen. De funktioner som ikke er med har ikke noget at sige for den basale brug af siden. Det er ting som at tillade brugerne at sortere søgeresultaterne der ikke er blevet inkluderet. Andre ting som kan bygges ind i modellen er dynamisk valg af reklamer så reklameblokkende bliver roteret eller det kunne være et kommentarsystem så brugerne kunne tilknytte kommentarer til artiklerne hvis man havde en mere community baseret nyhedsportal Beskrivelse PHP er et serverside script sprog og er valgt fordi det er skrevet til webdesign. At det er serverside vil sige at det bliver fortolket på serveren inden det sender outputtet ud til den maskine der forespurgte om det. PHP er et open source produkt, så det er muligt at anskaffe sig kildekoden og en compiler og selv optimere produktet til sine egne specifikke behov. Som resultat af dette og det faktum at PHP allerede er implementeret på mange populære platforme, gør at PHP er en meget fleksibel løsning. 63

72 Implementeringen Hjemmesiden er skrevet i moduler, hvilket gør det nemmere at foretage større opdateringer af siden end hvis man skulle opdatere alt på hver eneste side. I vores specifikke tilfælde er det måske ikke så interessant da webportalen kun består af cirka ni separate sider, men havde siden været til en stor avis eller et stort firma kunne det sagtens tænkes at der var behov for langt flere sider. Modellen er derfor at godt udgangspunkt for senere udvidelser. At siden er lavet I moduler vil sige at ting som menu, overskrift og tekstboks er adskilt. Da menuen og overskriften ikke skal ændres når man klikker sig rundt på siden kan de med fordel oprettes i filer for sig og så inkluderes efter behov ved hjælp af PHP funktionen require(). Alle de generelle filer der kræves på hver side er samlet i en enkelt fil for at gøre det overskueligt hvilke filer der altid skal bruges til at opbygge sider med. Dvs. disse filer inkluderes nemt ved at tilføje require( required.php ); for eksempel i starten af en fil. Ved hjælp af require() kan man altså flytte gentagen kode ud fra hovedsiderne og ned i undermoduler. Som et kort eksempel kan man tage getshortstory.php. <?php while ($row = mysql_fetch_array($result)){ $date = $row["ind"]; list ($year, $month, $day) = explode ("-", $date); echo "<table width=\"100%\" cellpadding=\"0\" cellspacing=\"0\"> <tr> <th class=\"news\">".$day. "-".$month."-".$year." <a class=\"menu\" href=\"artikel.php?id=".$row["id"]."\">".$row["titel"]. "</a></th> </tr> <tr valign=\"top\"> <td class=\"news\">"; $var = $row["billede"]; $result_billede = mysql_query("select * from billeder where id = '$var'"); $figur = mysql_fetch_array($result_billede); if ($figur["sti"]!= ""){ echo "<a href=\"".$figur["sti"]."\"><img src=\"".$figur["sti"]. "\" border=\"0\" width=\"125\" align=\"right\"></a>"; } 64

73 $tekst = $row["tekst"]; echo substr ($tekst, 0, 150)."..."; $id = $row["id"]; $kategori = $row["kategori"]; }?> echo "<a href=\"artikel.php?id=$id\">læs mere</a> </td> </tr> </table> <br><br>"; I sig selv gør kodestumpen ikke noget. Den består af betingende sætninger som kun viser resultater hvis en forudgående MySQL kommando har hentet oplysninger ud af databasen. Da dette korte stykke kode bruges på hver eneste kategoriforside og på selve hovedsiden, er det oplagt at fjerne det fra hoveddokumentet og i stedet hente det gennem require(). Derved er det også betydeligt nemmere at ændre på layoutet, hvis man eksempelvis bestemmer sig for at man vil vise den fulde artikel på hovedsiderne. Grunden til at MySQL kommandoen ikke er inkluderet i filen er at den skal eksekveres med forskellige kriterier afhængigt at hvilke historier man ønsker vist på den pågældende side. Den egenskab der gør PHP effektiv som en dynamisk måde at fremstille data på er kontrol strukturer som if og while der også er kendt i så mange andre programmeringssprog. Disse elementer giver muligheder for at lave betingende sætninger som man ellers ikke kan implementere i HTML. Som et godt eksempel på dette kan man tage søgefunktionen fra siden... if ($search_kategori =="alle"){ if (($titel == "titel") && ($tekst == "tekst")){ $query = "SELECT * from temp_artikel WHERE interntilstand = 'godkendt' AND (tekst LIKE '%$search%' OR titel LIKE '%$search%') ORDER BY 'ind' DESC"; }elseif (($titel == "titel") && ($tekst == "tom")) { $query = "SELECT * from temp_artikel WHERE interntilstand = 'godkendt' AND titel LIKE '%$search%' ORDER BY 'ind' DESC"; }elseif (($titel =="tom") && ($tekst == "tekst")) { 65

74 }else{. $query = "SELECT * from temp_artikel WHERE interntilstand = 'godkendt' AND tekst LIKE '%$search%' ORDER BY 'ind' DESC"; }elseif (($titel =="tom") && ($tekst == "tom")) { echo "Vælg venligst enten tekst eller titel som søgekriterie."; } Dette udpluk viser en del af den sortering der foregår når søgekriterierne modtages af søgefunktionen. Der bruges if sætninger til at teste hvilke variable der er sendt videre. De variable der er tilgængelige vil så blivet indkluderet i den SQL statement som henter de ønskede oplysninger fra databasen. Variable $query, indeholdende SQL kode, sættes ind i funktionen mysql_query() som sender statementen videre til databasen. Ved hjælp af en while løkke hentes dataene ind i et array og kan nu hentes ud efter behov. $limitquery = mysql_query($query); while ($result = mysql_fetch_array($limitquery)){ echo $result[ titel ]; } Dette stykke kode henter og viser titlerne på de artikler som er blevet hentet med SQL kommandoen tidligere. Søgefunktionen bruger en lidt mere fyldestgørende løkke, med flere data hentet fra databasen samt output som bruges til formatering af hjemmesiden. 66

75 6. Test af systemet I dette kapitel vil vi beskæftige os med de tre brugertests vi har foretaget i projektforløbet og derudover beskrive testen af koden. Hensigten med disse tests har været at skabe et design af vores brugergrænseflade, der giver brugerne et overskueligt og tilgængeligt system. Vi har valgt at lave tænke-højt tests, med en journalist og to brugere som tilhører læserne. Personerne der har været villige til at hjælpe os, er journalist Karin Pedersen (50), som arbejder for Nordjysk Stiftstidende, og to middelaldrene testpersoner som ønsker at være anonyme. Vi fandt det nærliggende at teste systemet til skribenten på en journalist, da hun repræsenterede den specificerede målgruppe. Det var ikke muligt for os, at få andre fra målgruppen til at medvirke. Journalisten medvirker også i test af nyhedsportalen, sammen med to andre testpersoner. Udvælgelsen af testpersonerne til tænke-højt test på nyhedsportalens har været mere eller mindre vilkårlig, da nyhedsportalens målgruppe spænder vidt. Dog besøger alle tre ofte lignende nyhedssider. Testene skal ved hjælp af spørgsmål og samtale, give os yderligere information om hvorledes en bruger reagerer overfor systemet, dette gælder for klientdelen for skribenten såvel som nyhedsportalen for læseren. Den første test var en papirtest, hvor brugeren blev stillet overfor de forskellige funktioner ved hjælp af mockup billeder. Denne test fokuserede kun på klientdelen til skribenten, da den havde højeste prioritet. De næste to tænkehøjt tests blev afviklet i forlængelse af hinanden. Disse tests blev baseret på det rigtige system og indeholdte spørgsmål, der skulle afsløre om hvorvidt journalisten kunne sende en artikel med de rigtige attributter til databasen, og om læserne kunne navigere og søge på hjemmesiden. For at sikre os mod misforståelser havde forsøgspersonerne fra starten fået at vide at det ikke var dem, men derimod systemet vi testede, og at forsøgslederen ville forsøge at hjælpe dem, hvis de gik i stå med en opgave. Til at afsløre eventuelle fejl og defekter i systemet, anvendte vi programtest i udviklingsprocessen. Disse programtests havde til hensigt at sikre intentionerne bag systemet også bliver korrekt udført i programmet. Til sidst vil vi samle op på de ændringer vi har måttet foretage i designet på baggrund af testene Mockup test 67

76 Vi har gennem vores arbejde med analysen udviklet en prototype af brugergrænsefladen til skribenten, som vi har udformet i Adobe Illustrator. Denne prototype har vi valgt at få testet af en person, med erfaring og ekspertise inden for det redaktionelle område. Dette blev gjort for at få en kvalificeret vurdering samt gode forslag til designet. Formålet med forundersøgelsen var at fastslå: Om brugergrænsefladens opbygning virkede logisk Om navigeringsstrukturen virkede logisk Om sproget var utvetydigt og letforståeligt Den efterfølgende vurdering foregik ved samtale over de fremviste skærmbilleder, som vi havde udarbejdet. Dette ville hjælpe os med at få den umiddelbare reaktion og eventuelle ændring nedfældet på det viste papir. Til samtalen/vurderingen var der udover Karin Pedersen, to personer fra udviklingsgruppen tilstede, hvoraf den ene fungerede som logger og den anden som testleder Opsummering af Mockup test Karin Pedersen løste alle opgaverne med uden de store problemer, og gav os derudover forslag til følgende designmæssige ændringer: 1. Valget af knappernes placering skulle gøres mere ensartet for ikke at forvirre brugeren. 2. Informationerne skal gøres mere primitive, i den forstand at brugeren ikke skal tænke over den tekst der fremkommer, men intuitivt vide hvad der skal trykkes på. 3. For at øge affordance de steder i klienten, hvor der skrives/udfyldes, skal der være eksempler i tekstboksene, på hvad man skal skrive i dem. Disse tre forslag var relevante for vores videre design, og der blev derefter fokuseret på at imødekomme dem således at brugeren ikke stødte på dem ved den næste test. I denne mock up havde skribenten mulighed for at låse eller låse en artikel op i form af låseikoner. Grunden til at 68

77 funktionen var medtaget, var for at sikre sig, at flere skribenter ikke kunne redigere i den samme artikel. Ikonerne forvirrede journalisten mere end de gavnede. Derfor blev det besluttet at denne funktion lå skjult i programmet, således at når der blev redigeret i en artikel var den automatisk låst for andre Test af kode Ved test af koden i vores system, har vi gennemgået nogle af de mest fremtrædende teorier på området. Denne test kan foretages på forskellige måder. Der kan testes, før man starter med at kode, der kan testes undervejs i programmeringsforløbet, eller der kan testes når systemet er færdigkodet. Der ligger tre forskellige filosofier bag de tre indgangsvinkler til testen, men det er ikke noget vi vil komme yderligere ind på, da det ikke er formålet med dette afsnit. Der er grundlæggende to forskellige strategier til at teste testenheder med. En testenhed kan være alt fra en enkel kontrolstruktur over en klasse, til en samling af klasser i en hel applet. Den ene er topdown integrationsstrategien, som tager udgangspunkt i at systemet bygges op over et skelet, der kan teste kommunikationen mellem de enkelte dele. Skelettet fyldes derefter ud med reel programkode, efterhånden som flere og flere dele bliver færdige. Den anden integrationsstrategi bottom-up er, som man kan gætte ud fra navnet lige omvendt. Bottom-up koder først de enkelte dele og gennemtester dem, for derefter at sætte dem sammen i en applet eller applikation. Derudover eksisterer der teknikker, der tager udgangspunkt i hvilket indblik testpersonen har i den foreliggende testenhed. En teknik er white box, der tager udgangspunkt i kendskab til de interne kontrolstrukturer, og som udgangspunkt skal alle kommandoer i testenheden udføres mindst en gang. Der er mere specifikke krav til en white box test, men dem ønsker vi ikke at kommentere yderligere. Derimod fokuserer vi på black box teknikken, da det er den teknik vi har brugt. Her er udgangspunktet, at man ikke har nogen forudanelse om, hvad der sker inde i testenheden under testen. Det der her fokuseres på er, at der kommer korrekte output ud af de korrekte input man giver systemet og omvendt, at der kommer ukorrekte output ud af ukorrekte input. Vi vil i det efterfølgende redegøre for hvilken indgangsvinkel, strategi og teknik vi valgte at gennemføre test i vores system med. I en autentisk udviklingssituation vil der naturligvis blive sat god tid af til at teste systemet grundigt igennem. Således at man kunne få bearbejdet data og brugt dem til efterfølgende fejlretning inden systemet bliver taget i brug. På grund af tidspres måtte vi klare os med de tests, der blev udført undervejs i udviklingsforløbet, da systemet er under stadig udbedring. Dette svarer til at udføre en black box test, og derfor udfører man i og for sig en bottom-up integrationstest, af black box typen, der afprøver hver enkelt klasse for sig, og ser om den giver de resultater tilbage, man forventer. 69

78 Gennemgangen af testene viste os hvilken kode der var rigtigt implementeret, og hvilken der skulle ændres Test af skribentens brugergrænseflade Denne test blev foretaget, for at undersøge, hvorvidt de ændringer, vi havde lavet i programmet, på baggrund af mockup testen, var tilstrækkelige. På forhånd havde vi ikke regnet med at der skulle være de store problemer. Vi fik igen journalisten til at gennemgå en række opgaver. Opgaverne mindede meget om opgaverne i mockup testen. Årsagen til dette var, at vi ville sikre os at testpersonen beskæftigede sig med de områder, hvor vi havde foretaget ændringer. Dog drejede de to sidste spørgsmål sig om, de ekstra funktioner som redaktøren har til rådighed i programmet. Til sidst bad vi journalisten om at kommenteret programmet som helhed. Den første opgave bestod i at lave en artikel, der omhandlede Danmarks sejr under EM-turneringen i kvindehåndbold. Indholdet af artiklen var valgfri, da det ikke var testpersonens evne til at skrive en artikel vi testede. Journalisten havde ikke problemer med at indsætte de rigtige værdier i artiklen. Dernæst bad vi testpersonen om at vælge prioriteringen af artiklen. Heller ikke her var det noget problem for testpersonen at fuldføre opgave korrekt. Til sidst skulle journalisten gøre artiklen klar til at komme på nettet. Det blev også klaret uden problemer. De to sidste spørgsmål drejede sig om at benytte de to ekstra funktioner, der er til rådighed når man logger ind som redaktør. Formålet var her, at se om testpersonen kunne finde ud af, at hente en artikel fra databasen til programmet, ændre i artiklens attributter, således at artiklen blev godkendt af redaktøren. Testpersonen havde ikke noget problem med at få tilgang til database oversigten. Dog opstod der et mindre problem. Testpersonen var ikke klar over om man skulle dobbeltklikke eller benytte en anden knap til at få artiklen over i editordelen af programmet. 70

79 Opsummering af test Grunden til at der næsten ikke opstod nogle problemer i denne test, skyldes først og fremmest at vi sørgede for at inddrage brugeren tidligt i designet af programmet. Ved at benytte mockup tests tidligt sikrede vi, at brugeren ikke havde navigationsmæssige problemer. Det sidstnævnte problem, om hvorvidt man skulle dobbeltklikke eller bruge en anden knap til at overføre en artikel, vurderede vi skyldtes dominating design. Det vil sige hvad man i forvejen er vant til som bruger. Vi vurderede derfor, at det bedste ville være at lave en knap som overførte artiklen til editordelen af programmet Test af hjemmeside Til denne del af testen havde vi 3 testpersoner. Disse fik udleveret et spørgeskema 4, som de skulle besvare bedst muligt. Vi havde bedt forsøgspersonerne om at tænke højt, så vi bedre kunne forstå den tænkegang, som lå bag deres forskellige valg. Spørgsmålene er udformet med henblik på at undersøge navigeringen samt søgefunktionen på hjemmesiden. Vi har vurderet at spørgsmålene var af en sådan sværhedsgrad, at kunne testpersonerne ikke svare på dem, betragtede vi det som yderst kritisk. Testpersonerne er journalisten Karin Pedersen, samt to anonyme deltagere, som vi kalder Lars og Lone. Testen vil blive gennemgået således: Alle spørgsmålene gennemgås hvorefter testpersonernes kommentarer bliver tilknyttet. Slutteligt vil vi foretage en overordnet opsamling, og kommentere på den samlede undersøgelse Spørgeskema resultater Det første spørgsmål, som testpersonerne blev stillet, drejede sig om at finde den nyeste artikel på hjemmesiden. Her var der ingen problemer for testpersonerne. De fandt den korrekte artikel, ved at benytte oversigten i den midterste del af skærmbilledet 5. 4 Se bilag side 5 Markeret med en sort firkant 71

80 Figur 35: Skærmbillede af nyhedsportalen Spørgsmål nummer to mindede om spørgsmål et. Nu drejede det sig blot om at finde den nyeste sportsartikel. Lars brugte først den midterste del af skærmbilledet til at se efter artiklen. Lars fandt nederst en sportsartikel fra 11/ Lars var dog stadig ikke sikker på, at det var den rigtige artikel. Lars benyttede dernæst sektionsoversigten til venstre i skærmbilledet, for at finde flere artikler omhandlende sport. Ved sportssektionen lykkedes det Lone at finde en anden sportsartikel. Denne artikel var dateret Slutteligt benyttede Lars sig af artikeloversigten til venstre i skærmbilledet. Denne oversigt viser de fire nyeste artikler fra hver sektion. Her fandt Lars den nyeste artikel. Lone oplevede de samme problemer som Lars. Lone troede også at oversigten, i midten af skærmbilledet, viste de nyeste artikler. Efter at have ledt efter den nyeste artikel i omkring ti minutter, bad vi Lone om, at vælge den artikel som hun mente var den nyeste. Lone valgte ikke den korrekte artikel, og løste dermed ikke opgaven. Karin Pedersen oplevede præcis de samme problemer, som de to foregående testpersoner. Midteroversigten blev forstået som en oversigt over nyeste artikler. Som tidligere beskrevet, er midteroversigten artikler placeret der, ud fra en prioritering af artiklens nyhedsværdi. På grundlag af testpersonernes besvær med opgave to, vurderede vi, at denne placering at artiklerne baseret på deres nyhedsværdi, ikke var den bedste måde at gøre det på. Vi vil komme nærmere ind på dette under opsamlingen af testen. Spørgsmål nummer tre lød således: Find artiklen Liverpool ude af Champions League. Hensigten med denne opgave var, at se om testpersonerne kunne finde en 72

81 bestem artikel på hjemmesiden. Helst ved brug af søgefunktionen til at lede efter en artikel titel. Lars valgte dog at benytte sportssektionen til at lede efter artiklen. Han fandt den uden problemer. Da vi spurgte ham, om han havde tænkt på at benytte søgefunktionen, svarede han, at det kun ville være som sidste udvej, hvis han ikke kunne finde artiklen på anden måde. Lone valgte i modsætning til Lars at benytte søgefunktionen. Hun var dog i tvivl om hvorvidt hun skulle vælge Tekst eller Titel som søgekriterie 6. Lone valgte at søge på artikel. Figur 36: Skærmbillede af nyhedsportalens søgefunktion Hun spurgte efterfølgende, om det var muligt at omgå valget af søgekriterie, således at man automatisk søgte på både tekst og titel. Karin Pedersen benyttede så søgefunktionen. Hun fandt det dog ikke besværligt at vælge mellem Tekst og Titel. Både Lone og Karin Pedersen fandt artiklen uden problemer. Det sidste spørgsmål var udformet således, at testpersonerne skulle benytte søgefunktionen til at søge efter Tekst med ordet Bush. Alle testpersonerne havde overhovedet ingen problemer med at løse denne opgave Opsummering af test Efter testpersonernes gennemgang af hjemmesiden fandt vi flere problemer, hvor vi kategoriserede to af dem som værende at større betydning. Det ene problem drejede sig om søgefunktionen. Da Lone gav udtryk for sin manglende forståelse for de to kriterier Titel og Tekst, tænkte vi på, hvorvidt det var muligt, at tage disse to valgmuligheder og gøre det lettere for brugeren at benytte søgefunktionen. Vi var dog enige om at valgmulighederne ikke skulle fjernes, da det ville skabe en række komplikationer. Disse komplikationer kunne opstå, når man opnåede et større antal artikler i 6 Markeret med en sort firkant 73

82 databasen. Der ville det helt klart være favorabelt at kunne begrænse sin søgning, ved hjælp af Tekst eller Titel. Derfor blev vi enige om, at sætte Tekst og Titel som valgte. Dermed sikrede man, at mere uerfarne brugere kunne søge nemt, samtidigt med at der var sikret mulighed for en lidt mere avanceret søgning. Det største problem som blev klarlagt i testen, var placeringen af nye artikler. Alle testpersoner troede som udgangspunkt at disse var placeret i den midterste del af skærmbilledet. Dette kan til dels skyldes datoen på den øverste artikel, og at de underlæggende artikler følger i kronologisk orden. Desuden gav testpersonerne udtryk for, at det mest naturlige var, at de nyeste artikler lå øverst i navigeringsstrukturen. Som tidligere beskrevet afgøres artiklernes placerings ved hjælp af deres prioritering. Som det ses på figur 35, findes artikler med prioriteringen Hovedforside i den midterste del af skærmbilledet. Artikler med prioriteringen Kategori forside forefindes under de forskellige sektioner, mens artikler med prioriteringen Normal befinder sig under de forskellige menuer til højre i skærmbilledet. Figur 37 - Hjemmesidestruktur Grundet testpersonernes store besvær med at finde den nyeste artikel, blev vi nødt til at revurdere denne opsætning. Der var to ting vi kunne gøre. Det første var at fjerne alt det der havde noget med prioritering at gøre. Det vil sige, at når en artikel kom op på hjemmesiden, ville den blive sat øverst i rækken af artikler. Vi blev i gruppen hurtigt enige om, at det var en dårlig idé, da det gjorde vores design af hjemmeside yderst overflødigt. Desuden havde testpersonerne givet udtryk for, at de syntes det var en udmærket funktion, at artikler kunne være placeret under forskellige kategorier. Derfor valgte vi at bibeholde den daværende opbygning i forhold til prioritering. 74

83 For at undgå at gamle artikler med prioriteringen Hovedforside blev liggende på forsiden, og gav et falsk billede af hvad de nyeste artikler var, besluttede vi, at en artikel maksimalt kunne befinde sig på forsiden af hjemmesiden, i 24 timer efter den var blevet lagt ud på hjemmesiden. Der var dog både fordele og ulemper ved at benytte denne fremgangsmåde. Da vi i hele projektperioden ikke har produceret et overvældende antal artikler til hjemmesiden, ville denne, med implementeringen af 24 timers reglen, hurtigt blive tømt for artikler. Det ville resultere i en yderst tom hjemmeside. Vi blev så nødt til at vurdere hvorvidt, vi ville have en hjemmeside, som umiddelbart virkede tom, men hvis forside gav mere udtryk, af at være opdateret. Med henblik på at denne hjemmeside er fremstillet til en avis, hvis artikelproduktion, som er noget kun større end vores, ville problemet med manglende artikler på forsiden ikke blive aktuel. Derfor valgte vi at implementere 24 timers reglen på hjemmesiden. Testen af hjemmesiden, gav os et meget bedre indblik i, hvilke problemer almindelige brugere kunne have. Dermed sikrede vi os, at både uerfarne brugere og erfarne brugere ville opnå en større tilfredshed ved at benytte hjemmesiden 75

84 Del IV Studierapport 76

85 7. Studierapport Denne studierapport bearbejder de erfaringer vi har gjort os, i forbindelse med udviklingen af systemet. I det følgende vil vi forholde os kritisk til valg af metoder og værktøjer, samt egen arbejdsgang. Dette gøres dels for at få indblik i de konsekvenser udviklingsprojektet har haft, men også for at klarlægge alternative måder at gribe projektet an på. Vores hovedfokus har i denne studierapport været på brugergrænseflader, som vi mener, er nøglen til et velfungerende system Analyse Systemvalg Tidligt i forløbet faldt valget på at lave et simpelt artikelstyringssystem, til publicering af nyheder på nettet. Alle i gruppen var enige om at det ville være interessant at samarbejde med en ekstern partner, der havde et reelt behov for at få udviklet systemet, i stedet for at tage udgangspunkt i et tænkt system. Vi tog kontakt til den ålborgensiske gratisavis 10 Minutter, som ikke fandt det rentabelt at implementere systemet i redaktionens arbejdsgang. Vi besluttede derfor selv at definere systemets formål. Gennem interviews med journalister fra NordJyske Stiftstidende og ITvirksomheden AM Production, som har udviklet NordJyske.dk fik vi kendskab til potentielle brugere, og fik idéer til hvordan vores system kunne designes. Efterfølgende fik vi diskuteret hvilken situation systemet skulle indgå i, og på baggrund af diskussionen blev der udarbejdet et rigt billede. Herefter lavede vi udkast til systemdefinitionen og senere BATOFF-kriterier, som vi rettede systemdefinitionen til efter. Denne arbejdsproces blev gentaget nogle gange. Vurdering af arbejdet med systemvalg Før valget af det endelige system, havde vi en del diskussioner angående systemets formål, også med tilbagevendende problemstillinger vi havde drøftet og derefter glemt igen. Generelt har vi ikke været gode til, at skrive ned hver gang vi er kommet til konsensus omkring dele af systemet. Dette har besværliggjort udarbejdelsen af især systemdefinitionen, men også i andre sammenhænge. Vi har fra start heller ikke været specifikke nok med hensyn til systemets målgruppe, hvilket indebar at 77

86 målgruppen var alt for bred. Dette bevirkede at gruppen havde delte meninger, om eksempelvis hvilke arbejdsopgaver systemet skulle løse. En erfaring vi har gjort os er, at det er meget vigtigt at være helt enige om systemets formål, samt skabe klarhed omkring de omgivelser hvori de skal fungere, inden man går i gang med det videre arbejde. Ellers risikerer man at lave meget arbejde om flere gange. Situationen ville højst sandsynlig have set anderledes ud, hvis vi havde indgået samarbejde med en ekstern partner. Dermed ville problemet med systemets formål være lettere at løse, og vi ville undgå indbyrdes interessekonflikter i gruppen Analyse af problemområdet Analyse af problem og anvendelsesområde blev udarbejdet på samme tid, da en deadline skulle overholdes. Manglende erfaring med metoderne i OOA&D bogen (Mathiassen et al: 2001) samt ringe kommunikation under udarbejdelsen, bevirkede at de to analyser ikke hang sammen. Derfor har arbejdet med de to områder været stærkt iterative. I forbindelse med problemområdet udarbejdede vi relevante klasser og hændelser ved hjælp af brainstorm, hvorefter vi konstruerede et foreløbigt klassediagram og hændelsestabel. Gennem det videre udviklingsforløb har både klasser og hændelser ændret sig. Klassediagrammet bestod i første omgang af klassen Database, hvor alle artiklerne var associeret til. Klassen viste sig at være al for teknisk og præcis og derfor ikke i overensstemmelse med OOA&Ds krav om abstraktion. Klassen blev derefter omdøbt til Arkiv. Denne klasse endte vi dog med at fravælge, da den dækkede over en større teknisk beskrivelse, og derfor ikke kunne kvalificere sig som klasse. Klassen Video er fravalgt, da den i forhold til systemets målgruppe virker overflødig. Skribenten har højst sandsynlig ikke det store behov, for at kunne vise video på nyhedsportalen. Det ville desuden også være tidskrævende at implementere. Da klassediagrammet er tilpas simpelt, er klasserne blevet fjernet uden at, vi skulle omstrukturere det eller lave større ændringer i rapporten. Hændelsestabellen måtte også til revision, da der under første udarbejdelse stadig herskede tvivl, om hvad en hændelse var og gjorde. Vurdering af arbejdet med problemområdet 78

87 En erfaring vi har gjort ud fra de problemer vi har haft, er at det er vigtigt at alle har overblik og fælles forståelse, over hele analysen inden man går i gang med den enkelte opgave. Ved at have læst nærmere på teorien i OOA&D, ville vi have fået bedre forståelse for problemområdet, og hvordan det hang sammen med resten af analysedokumentet. Vi erfarede også, at hvis man fjerner en klasse eller hændelse, har det indflydelse i både analyse- og designdokument. Dette resulterede flere gange i manglende konsistens gennem vores projektrapport. For at løse problemet med inkonsistens, har vi flere gange måttet omskrive dele i problemområdet. Hvis man skabte et overblik over analysen, inden man gik i gang, ville tingene blive sat i forbindelse med hinanden, hvorved det ville være nemmere at se relevansen i de enkelte metoder Analyse af anvendelsesområdet Udarbejdelsen af anvendelsesområdet forløb lidt mere planmæssigt end problemområdet. I gruppen fik vi ved brainstorming fundet aktører og brugsmønstre. Dernæst opstillede vi en aktørtabel, for at få overblik over hvilke brugsmønstre, de enkelte aktører skulle beskæftige sig med. Hver aktør og deres rolle, i forhold til systemet blev beskrevet. Efter dette var grundlaget lagt, for at kunne udarbejde et tilstandsdiagram for alle brugsmønstrene. Uafhængigt af udarbejdelsen af aktører og brugsmønstre, blev der opstillet en funktionsliste, samt en beskrivelse af hver funktion. Hver funktion blev opdelt efter hvor svært den ville være at implementere, men det viste sig at være vanskeligt at bedømme, da vi endnu ikke havde den fornødne erfaring med programmering, heriblandt Java. Da udarbejdelsen af aktører og brugsmønstre havde kørt sideløbende, men uafhængigt af udarbejdelsen af en funktionsliste, skulle funktionerne tilpasses beskrivelsen af brugsmønstrene. Til sidst gik vi i gang med dialogformen, ved at beskrive de enkelte brugergrænseflader nærmere. Herunder beskrev vi også, hvad der var vigtigt at lægge vægt på i forbindelse med de enkelte brugergrænseflader. Vurdering af arbejdet med anvendelsesområdet. Funktionslisten skulle have været udarbejdet i forlængelse af brugsmønstrene. Hvis vi havde studeret brugsmønstrene ville det have været lettere at udarbejde en komplet funktionsliste, i stedet for at tilpasse det til hinanden. Det må igen konstateres at mange problemer kunne være undgået, 79

88 hvis vi havde haft overblikket, men dette kommer kun gennem erfaring. Dette gælder også vurderingen af kompleksiteten af funktioner Designbetingelser Ved udarbejdelsen af designdokumentet startede vi med at udarbejde et prioriteringsskema, over kvalitetsmålene i vores designforløb. Dette blev gjort for at sætte mål og rammer for hvad vores system skulle kunne opnå. Ved siden af blev den tekniske platform beskrevet, i form af hvilke programmer og systemer vi ville tage i brug for at opnå vores mål. Vurdering af arbejdet med designbetingelser Med OOA&D-bogens (Mathiassen et al, 2001) gode oversigt og beskrivelse af principperne indenfor design, blev designkriterierne overskueliggjort og dermed nemmere for os at arbejde med Design af arkitektur og komponenter Det største problem indenfor arbejdet med arkitektur og komponenter, var vores manglende kendskab til det at arbejde med objektorienteret programmering, hvilket medførte en manglende forståelse af stoffet. For at opbygge en struktur i vores system, gik vi i gang med at designe arkitekturen. Procesarkitekturen blev endvidere beskrevet ved hjælp af fordelingsdiagrammer. Vores arbejde med komponenterne foregik som en iterativ proces og blev afviklet over en længere periode. Modelkomponenten blev udarbejdet forholdsvist hurtigt ud fra klasserne og hændelserne i problemområdet. Dette skyldtes vores store arbejde med analysedelen, der sammen med den iterative proces vores system blev udarbejdet i, var grunden til det uændrede klassediagram. Arbejdet med klassediagrammet i analysedelen, havde givet os nogle store klasser der eventuelt skulle deles op i en funktionskomponent, men ved en nærmere gennemgang blev de emner vi stillede op, vejet og fundet for lette til at kunne lave en ordentlig funktionskomponent. Vurdering af arbejdet med design af arkitektur og komponenter 80

89 Design af arkitektur og komponenter gav os generelt store problemer. Vi havde fra starten skabt os et billede om, hvordan hovedtrækkene i arkitekturen skulle se ud, men netop designet af arkitekturen og komponenterne var sværere end forventet at beskrive. Problemet for os var at overskue hvordan det hele hang sammen. Dette resulterede i en masse løse tekst- og diagramstykker, som vi ikke vidste hvordan vi skulle sætte sammen. Førnævnte gav så udslag i længere udsættelse af arbejdet. Problemerne blev ikke mindre i komponentafsnittet. Her følte vi at bogen OOA&D (Mathiassen et al, 2001) var for vag til at understøtte os i at overskue de forskellige komponenter. Modelkomponenten fik vi dog hurtigst styr på, da den lægger sig meget op af klasserne vi beskrev i problemområdet. Til gengæld var der en stor usikkerhed omkring funktionskomponenten, og hvilke elementer og opgaver en sådan kunne indeholde. Det primære problem var at lave en, da bogen ikke giver os den mulighed, at et system kan være en funktionskomponent foruden. Et gennemgående problem har - efter vores mening været, at bogen ikke er behjælpelig nok til nybegynderne indenfor objektorienteret programmering. Der skulle simpelthen være en bedre gennemgang af de forskellige kriterier, for at de uerfarne programmører også kan skabe sig et hurtigere overblik over situationen. Dette var noget vi syntes bogen manglede, da det for os virkede, som om den henvendte sig til programmører med en større erfaring, og et større overblik, og det var der ikke nogen i gruppen der har haft Brugergrænsefladen De første tanker, vi gjorde os omkring brugergrænsefladerne til systemet, var i forbindelse med udarbejdelsen af analysedokumentet, hvor vi lavede navigationsdiagrammer til grænsefladerne. De store træk og idéer har ikke ændret sig synderligt, men brugergrænsefladernes udseende og navigationsmønstrene har ændret sig en del gange i løbet af udviklingen. Foruden vores egne tilføjelser er disse ændringer for brugergrænsefladen til skribenten/læseren sket på baggrund af en test af en papirudgave af skribentens brugergrænseflade, og et tænke-højt-forsøg udført på læserens og skribentens brugergrænseflade. Disse test havde til formål at lokalisere eventuelle navigationsmæssige og strukturelle fejl. Desuden ville vi sikre os at journalistens brugergrænseflade, og dertil hørende funktioner, gav mening. Vi har efterfølgende fundet ud af, at det optimale ville have været at gennemføre en antal flere test. Hver test skulle have et specifikt formål. De første test kunne have været heuristiske inspektioner af 81

90 papirsprototyper, hvor formålet var at teste hvorvidt brugergrænsefladen kunne implementeres. Disse test kunne have hjulpet os til, at holde en mere konsistens i designet. Vurdering af arbejdet med brugergrænsefladerne Som tidligere nævnt har arbejdet med brugergrænsefladerne været præget af mange forandringer undervejs. Vi fandt ud af, at når man ikke har et stort kendskab til udvikling af brugergrænseflader, er det svært allerede i forbindelse med analysen at fastlægge designet. Derfor er det endelige design af brugergrænsefladerne ikke helt i overensstemmelse med de beskrivelser, der findes i analysedokumentet. En anden grund til dette er, at vi i nogle tilfælde har været for dårlige til at bruge de skitser, vi lavede i analysedokumentet. Disse skitser var lavet efter nogle kriterier, som vi havde baseret på Rolf Molichs (Molich et al. 2000) definition af brugervenlighed: Let at lære, let at huske, effektivt at bruge, forståeligt og tilfredsstillende at bruge. Her kan for eksempel nævnes vores intention om at bruge ikoner fra Microsoft Word. Generelt var vores indstilling fra starten af, at mange at funktioner skulle være symboliseret med ikoner, da vi mente, at det ville gøre det lette for brugeren at huske de forskellige funktioner og samtidigt øge effektiviteten. Vi fandt senere ud af, at der lå en række begrænsninger i implementeringen af disse ikoner, og vi så os derfor nødsaget til at kassere disse. Som vi kommer ind på senere, kunne vi måske have undgået dette, ved at sikre os, at vi har foretaget nogle tests af brugergrænsefladen, hvor formålet var at teste, hvorvidt det var muligt at implementere en sådan. Vi har desuden haft svært ved at fokusere på de relevante emner i forbindelse med brugergrænsefladerne. Dette fordi vi ikke har været objektive nok i vores diskussioner, og derfor har disse ofte udviklet sig til ligegyldige og tidskrævende. En anden erfaring har været at de design, som vi har forsøgt at analysere os frem til, ikke altid fungerer, når udenforstående skal afprøve dem. Ydermere kan vores møde med AM Prduction have haft en større indflydelse på udvikling af vores brugergrænseflade end vi umiddelbart have forestillet os. Det program AM Production foreviste os, minder utroligt meget, både funktionelt og strukturelt, om vores system. Vi har mere eller mindre ubevidst taget AM productions grundlæggende opbygning af brugergrænsefladen til os, og forsøgt at lave noget tilsvarende. Dertil kan der naturligvis siges, at inspiration ikke nødvendigvis er en ulempe. Hos os kan det have virket mere hæmmende end fremmende, da vi havde skabt os et billede, af hvorledes brugergrænsefladen skulle se ud. Vi lavede forskellige layouts til designet, og de var alle utroligt ens. Derfor følte vi, at vi hver især, var ret sikre på hvilke elementer brugergrænsefladen skulle indeholde. Det resulterede i at vi faktisk havde forskellige forestillinger 82

91 om, hvordan de elementer skulle fungere i brugergrænsefladens layout. Dette kunne vi have undgået, ved at benytte en mere HCI 7 præget fremgangsmåde. Dermed havde vi forebygget de problemer, som opstod under programmeringsdelen, da vi gennem den iterative udvikling 8 af brugergrænsefladen, havde fastlagt klare rammer for brugergrænsefladens elementer Implementering Et af de problemer vi stødte på i forbindelse med implementeringen var bogen Thinking in Java (Eckel, 2000), som blev brugt i forbindelse med forelæsningerne i Objekt Orienteret Programmering. Bøgerne er ikke så praktisk anlagte, som man har brug for, hvis man er en uerfaren programmør. Vores manglende erfaring medførte, at vi implementerede funktionaliteten i systemet i brugergrænsefladerne, og ikke i modellen. Da vi fandt implementeringen uoverskuelig, forsøgte vi at strukturere vores arbejde ved først at implementere små forholdsvist let overskuelige dele, og herefter samle dem til større dele, og igen større dele. Til sidst kunne vi bygge systemet færdigt ud fra de forskellige dele. Til sidst i projektperioden kunne vi samtidigt se værdien af, at have et tæt samarbejde med brugerne af systemet. Selvom man sagtens selv kan føle sig som en bruger, der kan vurdere en brugergrænseflade objektivt, opstår der problemer med dominating design. Vi var, som tidligere skrevet, meget præget af andre design i forbindelse med designet af hjemmesiden, og vi opfattede derfor designet af vores brugergrænseflade som værende forståeligt. Men da vi gennemførte vores første test fandt vi, til vores store overraskelse, ud af, at den måde som læserne opfattede hjemmesidens opbygning på, var forskellig fra vores egen. Den affordance som læserne tillagde den midterste del af brugergrænsefladen overraskede os. Vi var overbeviste om, at læserne var mest interesseret i nyheder med størst læserværdi. Denne læseværdi baserede vi udelukkende på en subjektiv vurdering fra journalisten side. Læserne vurderer derimod artiklens tidsmæssige relevans som den vigtigste. Derfor opstod der problemer med navigering på hjemmesidens brugergrænseflade. Under implementering af klientdelen havde vi et meget tættere samarbejde med brugerne (journalisterne). Dette kom også til udtryk i vores test af klientdelen. Her var antallet af fejl få, og ikke tilnærmelsesvis så store som fejlene i brugergrænsefladen til websiden. 7 Human-Computer-Interaction 8 Knyttet til HCI 83

92 Vurdering af arbejdet med implementering Igen ville et overblik over emnet have hjulpet os. Da vi begyndte at implementere, erfarede vi nemlig, at der var mange ting, vi havde overset i de foregående faser i processen. Vi har yderligere erfaret, at problemer med områder, der som udgangspunkt virker svært tilgængelig og uoverskuelige, bedst løses ved en iterativ gennemarbejdelse. Vores specialisering ligger indenfor brugergrænseflader, og derfor er problemet, med at vi har kodet selve funktionaliteten i brugergrænsefladerne, ikke afgørende for formålet med vores projekt. Det ville dog ikke have været hensigtsmæssigt, hvis systemet skulle bruges i en virkelig sammenhæng. Generelt vil mange af de problemer, vi har oplevet i forbindelse med implementeringen, vil blive nemmere at løse, jo mere erfarne vi bliver Implementering af brugergrænsefladen til kunden Som skrevet i afsnittet om implementering af brugergrænsefladen til kunden, valgte vi at bruge JBuilder som udviklingsmiljø, da vores kompetence indenfor Java-programmering ikke rakte til hurtigt at få en brugergrænseflade stablet på benene. Her viste JBuilder sig at være en fordel, da man nemt og hurtigt ved hjælp af drag-and-dropprincipper kan skaber en grafisk baseret applikation uden at have de store forkundskaber til Java. JBuilder kræver dog en lille smule indlæring. En stor fordel ved JBuilder er, at hvor man ved normal tekstbaseret kodning hele tiden skal skrive i koden, med risiko for at stave forkert, hver gang man ændrer en komponent, så holder JBuilder styr på ændringer som f.eks. størrelse, farve og border, og disse ændres automatisk i koden. På den måde skal man ikke tænke på koden bag de enkelte komponenter og kommandoer til disse. En anden ting, som Jbuilder gør godt, er at give mulighed for at vise en liste over de mulige kommandoer, man kunne tænkes at skulle bruge på et givent tidspunkt. Det gør, at man ikke nødvendigvis skal huske alle de metoder, der er for et givent objekt. Hvis man skriver navnet på objektet, vil der efter kort tid dukke en række mulige metoder op, i form at autocomplete 9, hvor man så kan vælge mellem dem. Dette letter programmeringsprocessen, da man ikke hele tiden skal slå op i en API eller lærebog for at huske ting, men man har hjælpen lige ved hånden hele tiden. 9 JBuilder skriver den pågældende linie kode færdig. 84

93 Dog skal det siges, at efterhånden, som man opnår mere programmeringserfaring, opstår der nogle uhensigtsmæssige omstændigheder i JBuilder. JBuilder fungere udmærket som program til at opbygge den grafiske del, men da vil vi ville til at arbejde med implementeringen af klasser, opstod der en række problemer. Jbuilder var for det første ikke velegnet til at samarbejde med BlueJ, hvilket var et andet program vi benyttede. De klasser vi lavede i BlueJ kunne vi ikke benytte disse i Jbuilder. Det gjorde det yderst kompliceret, at være flere på opgaven med programmering, da vi kun kunne være en person som arbejde på programmet i Jbuilder. Derfor valgte vi mere eller mindre, at lave programmet udelukkende i BlueJ. Vurdering af implementering af brugergrænsefladen til kunden En kort konklusion på vores valg af JBuilder som grundlæggende programmeringsmiljø må være, at det til udvikling af brugergrænseflader for uerfarne programmører må anses som værende godt, og vi var da også meget positive overfor JBuilder i starten. Ved JBuilder er det forholdsvis hurtigt og nemt at få skabt et visuelt design, som kan bruges til noget. Men efterhånden, som vi gerne selv ville have fingrene ned i koden, stillede JBuilder blot forhindringer op, og vi valgte derfor at gå over til en Java-orienteret tekstbehandler i stedet for et helt udviklingsmiljø. Slutteligt skal det dog siges, at det havde taget meget længere tid, at lave et tilsvarende layoutmæssig brugergrænseflade i en Java-orienteret teksteditor Projektorganisering Ved projektets afslutning udarbejdede gruppen et evalueringsskema for projektet 10. Dette blev gjort inden vi begyndte at diskutere projektforløbet i gruppen, således at man ikke lod sig påvirke af de mere højtråbende meninger. Spørgsmålene gik blandt andet på at vurdere hvordan projektet var organiseret med hensyn til gruppearbejde i projektets forskellige faser. De fleste gruppemedlemmer erkendte at fordelingen af arbejdsopgaver ikke har været jævnt fordelt. Tendensen har været at ikke alle medlemmer har været lige engagerede når der var opgaveregning i PE-kurserne eller gruppearbejde. Det har medført at der har manglet en fælles forståelse af hvor projektet skulle bære hen, hvorefter folk har arbejdet i hver sin retning. Konsekvenserne har været at dele af projektrapporten skulle laves om, da de enten ikke fulgte teorien i OOA&D eller de opsatte krav til systemet. 10 Se bilag 99 85

94 I starten lavede vi projektarbejde når alle i gruppen var til stede, så alle var indforståede. Senere i forløbet blev mindre opgaver dog delt ud på enkelt- eller tomands-grupper, i håb om at effektivisere arbejdet. Arbejdet blev også hurtigere færdigt, men opsplitningen betød til gengæld, at der manglede konsistens i de enkelte gruppers arbejdsresultater i mellem. Derudover blev der brugt mange ressourcer på at samle de enkelte dele, og udarbejde en rød tråd i dokumenterne. I gruppen har vi dog haft nogle gode diskussioner, men når vi endelig kom til enighed blev det ikke skrevet ned, og det blev hurtigt glemt igen, hvilket betød at uddebatterede emner blev taget op igen og igen. Med hensyn til projektarbejdet skal det nævnes, at alle har berørt de forskellige faser med hensyn til analyse, design, programmering og test. Dog i højere eller mindre grad. Vurdering af projektorganisering Udgangspunktet for projektet var godt, da alle ved første gruppemøde udtrykte holdning om at arbejde effektivt og målrettet med projektet. Dette skulle ske gennem tilrettelæggelse, planlægning og gennemførelse af arbejdet. Der er flere grunde til at de velmenende udsagn ikke blev opfyldt. Den væsentligste grund, er at en del store og tunge opgaver, som egentlig burde være drøftet i gruppen, blev uddelegeret. Hvis vi havde bearbejdet dem i gruppen havde vi mulighed for at hjælpe hinanden fagligt. Det ville også give en grundigere og dybere forståelse af problemet, samt forhindre misforståelser. En erfaring vi har gjort os er derfor, at helheden er mere end summen af delene. Det er i orden at fordele arbejdet ud i mindre grupper, men ikke før alle er enige og har en fælles forståelse af den opgave der skal løses. Derfor skal de tunge beslutninger vedtages samlet som en gruppe. Hvis et eller flere gruppemedlemmer ikke er indforstået med at arbejde som en gruppe, skal gruppen ikke være blege for at konfrontere vedkommende. Der er ikke noget mere ødelæggende for en gruppes arbejdsmoral end hvis en eller flere gruppemedlemmer laver al mulig andet under gruppearbejdet. En anden grund til at projektorganiseringen ikke var helt så effektiv var at arbejdet med OOA&D og Java var nyt for os alle, og derfor svært at komme i gang med. Vi har ikke haft overblik over hvor krævende de enkelte arbejdsopgaver har været og hvilke konsekvenser de har for resten af projektet. Nu da vi har fået bedre kendskab til metoderne og programmering skulle der ved næste projekt være chance for at organisere arbejdet lidt bedre. 86

95 8. Konklusion Der vil i dette afsnit blive konkluderet på det færdige system ved at sammenstille det, med de opsatte kriterier i analysedokumentet. I starten af dette udviklingsprojekt udarbejdede vi en systemdefinition, som tog udgangspunkt i BATOFF-kriterierne. Efterfølgende blev der lavet designkriterier til systemet. I det følgende vil vi gøre rede for, om de forskellige kriterier er blevet opfyldt. Betingelser: Det har været vigtigt at udarbejde et system, som alle kan benytte uden at have den store erfaring med IT generelt. Det er dog svært at bedømme om systemet lever op til betingelse, da journalister generelt har god erfaring inden for IT, da en stor del af arbejdsdagen foregår foran skærmen. Dog kan skribenten oprette en webside, uden at have erfaring med html. Anvendelsesområder: Som vores system ser ud, er det muligt for fiktive skribenter (journalist eller redaktør) at benytte systemet i forskellige situationer. Hvordan systemet vil fungere hvis det blev taget i brug på en faktisk redaktion, er derimod et andet spørgsmål. Hvis tiden havde tilladt det, ville det have været hensigtsmæssigt at simulere arbejdsgangen med systemet, for dermed at få kendskab til systemets begrænsninger. Man kunne eksempelvis forestille sig, at systemet havde sine naturlige begrænsninger for hvor mange skribenter, der kunne logge ind eller hvor meget trafik mellem klient, server og database systemet kunne klare. Teknologi: Generelt har der været tilfredshed omkring valget af udviklingsværktøjer til implementeringen af systemet, og de muligheder de har givet os. Her tænkes på Java, MySQL og PHP. Implementering med Java har dog været tidskrævende og voldt store problemer. Dette skyldes at man skal have et bredt kendskab til Javas klasser og metoder, før det er muligt at programmere et specifikt system. Da vi igennem semesteret har fået undervisning i Java, har det været naturligt benytte sproget under implementeringen af klientdelen. Fra et studiemæssigt synspunkt har det været lærerigt at arbejde med Java, men da klientdelen er forholdsvis simpel kunne vi med fordel have implementeret den, 87

96 udelukkende ved hjælp af html og PHP over en meget kortere periode. Havde vores system haft en større grad af kompleksitet ville Java være mest nærliggende at benytte. Funktioner: Af de funktioner, vi havde planlagt systemet skulle indeholde, er størstedelen blevet implementeret. Dog har vi på grund af tidspres måttet droppe nogle funktioner, eller kun implementeret dem delvist. I analysedokumentet opstillede vi muligheden for, at systemet kun importere nyheder fra eksempelvis nyhedsbureauer eller andre aviser, som skribenten kunne benytte under udarbejdelse af egen artikel. Denne ide er blevet droppet helt. Dels fordi det ville tage for lang tid at implementere, men også fordi den ikke er en nødvendig betingelse for vores systemfilosofi. Vi havde dog planlagt at implementere en funktion til billedsøgning, men har måttet droppet det. I stedet er der mulighed for at udvælge et billede ud fra en række forudbestemte billeder, og benytte det som artikelbillede. Filosofi: Vores betingelse var at udvikle et system, der gør det nemt at skabe og ændre indholdet på en nyhedsportal. Hvorvidt systemet lever op til sin filosofi, kan kun systemets målgruppe udtale sig om. Til at teste denne del af systemet har vi kun gjort brug af en testperson, som ikke havde nævneværdige problemer med at oprette eller ændre en artikel. Konklusionen må være at systemet lever op til sin filosofi, om end den hviler på et lidt tyndt grundlag. Sekundært var betingelsen at opbygge en nyhedsportal, hvor søgning og navigering er nemt for læseren. I første prototype havde testpersonerne problemer, med at forstå betydningen af de enkelte søgekriterier. Dette problem er dog blevet løst i den endelige nyhedsportal. En grund til at testpersonerne ikke har haft nævneværdige problemer med navigeringen kan skyldes, at strukturen overholder den standard, som det også kendes fra andre internetaviser/nyhedsportaler. Det kan altså konkluderes at de mål, det har været muligt for os at realisere, stort set er blevet opfyldt. Det kunne dog ønskes, at vi havde haft et mere indgående samarbejde med potentielle brugere. I det følgende vil systemet blive sat i perspektiv. Der vil blive reflekteret over valg af metoder. 88

97 9. Perspektivering I dette afsnit vil der hovedsageligt blive reflekteret over nogle af de metodevalg, der tilsammen har formet dette projekt. For at få nogle nye perspektiver og sammenhænge på baggrund af projektet reflekteres over eventuelle konsekvenser af alternative valg. Udviklingsmetode I denne studierapport har vi været kritiske overfor bogen OOA&D (Mathiassen et al, 2001). Dette betyder ikke, at vi er negativt stemt overfor bogen. Grunden ligger i at bogen henvender sig til personer med en vis erfaring inden for systemudvikling. Gennem denne projektperiode har vi opnået en grad af denne erfaring, så næste gang vi står overfor de samme problemer, vil vi kunne finde bedre støtte i bogen. På trods af de manglende erfaringer, er det alligevel lykkedes, at anvende de omtalte metoder til at gennemføre en systemudviklingsproces. Testmetode På baggrund af gode erfaringer fra tidligere projekter, faldt valget på tænke-højt-metoden til testning af prototypen. Da metoden skulle applikeres viste det sig, at programmet ikke var tilstrækkelig kompliceret til at et tilfredsstillende antal opgaver kunne stilles. Dette resulterede i at opgaverne endte med at blive meget specifikke, og enkelte opgaver guidede næsten testpersonen. Dette kan have haft betydning for testresultatet. I stedet burde vi have kogt opgaverne ned til det halve, og opstille nogle overordnede scenarier. Til at teste mockuptest, og 1. prototype har vi benyttet samme testperson, som har fået stillet næsten samme opgaver i begge udgaver af prototypen. Dette uheldigt, da testpersonen allerede ved første gennemgang har erhvervet sig viden om opgavernes løsning. Man får ikke meget nyt ud af tænke-højt-testen, da testpersonen ikke handler per intuition, men snarere per automatik. Ideelt set ville vi være fremkommet med mere overbevisende testresultater, hvis vi havde benyttet tre forskellige testpersoner for hver udgave af prototypen for skribenten. Det er kun lykkedes os at teste systemet til skribenten på en potentiel slutbruger. Men da systemet er tilpas simpelt kunne vi også med fordel have testet systemet på personer, som ikke er journalister. Valget er faldet på tænke-højt-metoden, da den har vist sig at give brugbare resultater med et minimalt forbrug af ressourcer. En ulempe ved tænke-højt-metoden er, at den ikke tager direkte udgangspunkt i brugerens virkelighed. Der er en unaturligt opstillet situation, og det kan ikke 89

98 undgås, at selve testformen og testlederen har indflydelse på resultatet, da det er umuligt at være en flue på væggen. Et alternativ til tænke-højt-testen, der med fordel kunne være benyttet, er konstruktiv interaktion. I denne metode arbejder to brugere sammen om at løse opgaverne til systemet. Problemerne vil så fremgå af deres samtale. Med denne metode fjernes noget af det unaturlige i at tænke højt, da samtale mellem to mennesker er mere naturligt. I denne type test er det vigtigt at finde to testpersoner som har samme erfaring inden for IT, som kan arbejde sammen. Hermed bliver noget af fokus også fjernet fra testlederen, og det er muligt at koncentrere sig om systemet. En umiddelbar ulempe ved denne metode, er den er mere krævende da den indbefatter dobbelt så mange testpersoner. Hvis den nødvendige tid havde været til rådighed, ville denne variant af tænke-højt-testen med al sandsynlighed været mere applikabel. (Molich Rolf (1999): 118f) Det endelige system Når man udvikler et system som vores er det vigtigt at have det kontekstuelle perspektiv for øje. Content management systemer får stadig større betydning efterhånden som informationssamfundet kommer over os og informationsmængderne dermed stiger eksplosivt. Mulighederne for at producere og lagre store mængder data har aldrig været større, men problemet med at strukturere de store mængder informationer bliver samtidigt vanskeligere. Derfor får CM systemer der søger at samle, strukturere og håndtere de store informationsmængder af stadig større betydning. Ved at undersøge andre lignende Content Management systemer på markedet, og ved at inddrage brugeren i udviklingen undgår man at fremkomme med et resultat, som ikke har sin berettigelse hos målgruppen. Det er svært at vurdere om projektets tiltænkte målgruppe, det vil sige mindre redaktioner, ville kunne drage fordel af vores system. I dette projekt har der været tendens til manglende brugerinddragelse, og der er derfor ikke basis for at udtale os om skribentens behov er blevet opfyldt. Det skal dog nævnes, at hvis vi havde haft ekstern samarbejdspartner eller kunde, der ønskede denne type CM system, havde udarbejdelsen af systemet formodentlig været nemmere, da der arbejdes indenfor nogle rammer. 90

99 10. Litteraturhenvisninger Bøger Bruce Eckel Thinking in Java Prentice Hall 2 nd ed., ISBN , June Jeffrey Rubin Handbook of Usability Testing - How to Plan, Design, and Conduct Effective Tests. John Wiley & Sons, Ilse Haugaard Java programmering Systime a/s (2001) Rogers Cadenhead Java2 bogen IDG Danmark (2001) Jerry Ablan Developing Intranet Applications with Java Sams.net Publishing (1996) Ellioette Rusty Harold Java network programming O Reilly (2000) Mathiasen, Lars, Andreas Munk-Madsen, Peter Axel Nielsen, Jan Stage Objekt Orienteret Analyse & Design 3. udgave, ISBN , (2001) Lemay, Laura, Rogers Cadenhead Sams Teach yourself Java 2 in 21 Days ISBN , (2000) Cadenhead, Rogers Java 2 bogen ISBN , (2000) Luke Welling, Laura Thomson PHP and MySQL Web Development Sams, 1st edition (March 30, 2001) Molich, Rolf Brugervenlige Edb-systemer 2.udgave. ISBN , Teknisk Forlag. (1999) Molic, Rolf 91

100 Brugervenligt Webdesign 1. udgave. ISBN , Teknisk Forlag. (2001) Websider Diverse artikler. IDG står som paraplyorganisation for sitet. Besøgt sidst d. 18 dec Sun Microsystems, Inc., "Java 2 Platform SE v1.4.0 API og "The Java Tutorial med mere. Besøgt sidst d. 18 dec Open Journal Project, Department of Electronics & Computer Science, University of Southampton Besøgt sidst d. 18 dec Dokumentation til MySQL med mere. Besøgt sidst d. 18 dec Manual til PHP med mere. Besøgt sidst d. 18 dec

101 11. Bilag Testbilag Mockup test 1) Log dig ind. Brug navnet: Redaktør og kodeordet: Informatik 2) Der er sket noget spændende i Poul Nyrup sagaen. Opret en ny artikel med en dertil passende titel og kilde. 3) Til den nyoprettede artikel skal der skrives brødtekst. Gør det! 4) Til artiklerne skal der findes et passende billede af Poul Nyrup. Billedet har ID-nummer ) Din artikel er nu næsten færdig. Vælg hvilken kategori den tilhører. 6) Vurder denne artikels nyhedsværdi, og sæt prioriteringen derefter. 7) Artiklen skal publiceres i morgen og fjernes i overmorgen. Sæt datoerne i overensstemmelse hermed. 8) Du vil nu sende artiklen videre til arkivet(databasen). Sæt status for artiklen, således at artiklen kan publiceres i morgen. 9) Du keder dig og har ikke noget at lave, så derfor vil du se om der findes nogle spændende artikler i arkivet, som kan inspirere dig til at genoptage dit arbejde. Søg efter en artikel under indland, skrevet af forfatter 2. 93

102 10) Åben artiklen så du har tilgang til den i redigeringsvinduet. 94

103 brugertest Spørgsmål til brugertest af hjemmeside: 1. Find den nyeste artikel 2. Find den nyeste sportsartikel 3. Find artiklen: Liverpool ude af Champions League 4. Hvor mange artikler med kategorien Udland, indeholder tekst om Amerikas Præsident Georg Bush Jr.? Spørgsmål til brugertest af applet: 1. Opret en ny artikel 2. Brug overskriften: Danmark vinder håndbold-em og sæt kilden til at være dit eget navn. 3. Skriv som brødtekst: Danmark vinder EM igen igen 4. Sæt datoen for publicering således at artiklen er tilgængelig på websiden imorgen 5. Sæt datoen for artiklens udløb til 2 dage fra nu 6. Indsæt et passende billede til artiklen 7. Vælg kategori for artiklen således at den passer til artiklens indhold 8. Gør artiklen klar til at komme på websiden 9. Prioriter artiklen således at den kommer på forsiden af websiden 10. Send artiklen til databasen 11. Log på som redaktør. 12. Find de artikel du netop har lavet, og giv den de endelige attributter, således at artiklen kan publiceres på hjemmesiden. 95

104 Spørgeskema til gruppen Spørgeskema til brug i studierapport. Spørgsmålene bedes besvaret med tallene 1-5, hvor 5 er meget godt, mens 1 er meget skidt. Desuden vil det være dejligt, hvis i kunne knytte en kommentar til hvert spørgsmål. TAK! 1. Hvordan synes du analysedelen af projektperioden har forløbet? 2. Hvad var godt? 3. Hvad var ikke så godt? 4. Hvad kunne vi have gjort anderledes? 5. Hvordan synes du designdelen af projektperioden har forløbet? 6. Hvad var godt? 7. Hvad var ikke så godt? 8. Hvad kunne vi have gjort anderledes? 96

105 9. Hvordan synes du programmeringsdelen af projektperioden har forløbet? 10. Hvad var godt? 11. Hvad var ikke så godt? 12. Hvad kunne vi have gjort anderledes? 13. Hvordan vil du vurdere projektperioden som helhed? 14. Hvorfor? 97