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