Teknisk kravspesifikasjon for ny publiseringsløsning til Foreldreutvalget for grunnopplæringen.

Transkript

1 Teknisk kravspesifikasjon for ny publiseringsløsning til Foreldreutvalget for grunnopplæringen. Vedlegg: 1. Wireframes 2. Menystruktur 3. Tilbudsskjema med skal krav/bør krav 1

2 Innholdsfortegnelse 1 Innledning Dagens løsninger Krav til leverandør av ny publiseringsløsning Grunnfunksjonalitet og tilleggsfunksjonalitet Artikkelredigering Malredigering Menyredigering Filer og arkiv Annen grunnfunksjonalitet eller tilleggsfunksjonalitet Multimedia Relatert informasjon Artikkelkommentar Diskusjonsforum - opsjon Språkmodul Formulareditor/elektronisk skjema Internsøk Nyhetsbrev Tips-en-venn Datering av innholdssider Automatisk generering Statistikk Systemkrav Brukeradministrasjon og tilgang Dokumentasjon og hjelpetekster Privilegiekategorier Design og layout Migrering Hosting/drifting Opplæring Testing og akseptanse Kravliste for søkemotoroptimalisering

3 1 Innledning Foreldreutvalget for grunnopplæringen (FUG) er et nasjonalt utvalg for foreldre med barn i grunnopplæringen. Vi er et rådgivende organ for Kunnskapsdepartementet i saker som angår samarbeidet mellom hjem og skole. FUG driver utadrettet virksomhet overfor foreldre med barn i grunnopplæringen og ivaretar foreldrenes interesser i skolesammenheng. FUG ønsker bl.a å være hovedinformasjonskanal for foreldre, skole og myndigheter om alt som gjelder hjem/skole-samarbeidet. I den forbindelse blir nettsidene en stadig viktigere kanal for FUGs informasjonsformidling. FUG har i dag to nettsider: fug.no og foreldrenettet.no. Disse skal slås sammen til ett nettsted på URL fug.no. URL fra foreldrenettet.no skal beholdes, og rutes til fug.no med redirect 301. I den forbindelse skal FUG anskaffe ny publiseringsløsning. Løsningen ønskes hostet og driftet hos leverandør. Det er ønske om å starte utvikling av nettstedet så snart som mulig etter at leverandør er valgt, og lansering av nytt nettsted ønskes gjort i uke 1, Den nye nettløsningen skal ha lang levetid og det er viktig at løsningen er fleksibel med hensyn til videreutvikling. Løsningen bør ikke utelukke utviklingen av et diskusjonsforum i nær fremtid. Det ønskes oppgitt en pris og leverandørs anbefalte måte å løse føringer og krav på, samt tidsestimat for oppstart og gjennomføringsperiode for leveransen. Det ønskes også spesifisert hvordan løsningen prises. Det ønskes en beskrivelse av lisensstruktur og/eller prisstruktur. Vil det for eksempel være en lisenspris, eller pris per admin-bruker? Prisen ønskes oppgitt for anskaffelsesåret og det kommende år. Samtidig med anbudsbesvarelse ønsker FUG mulighet til å se en demoversjon av publiseringsløsningen. Det kan gjøres ved å tilgjengeliggjøre brukernavn og passord slik at FUG kan logge seg inn og se admin-grensesnittet og gjerne også prøve ut funksjonalitet i løsningen. Overordnede mål for nettsatsningen hos FUG er å være et rådgivende organ både for myndigheter og foreldre, samt arbeide for et godt samarbeid mellom hjem og skole. De nye nettsidene vil i hovedsak rette seg mot disse brukergruppene: Foreldre og foresatte Alle foreldre som har barn fra 1-10 trinn samt første året i videregående skole Tillitsvalgte foreldre Foreldre som er valgt som klassekontakter, ulike utvalg både på skolen og i kommunen osv 3

4 Ansatte i skolen Lærere, rektorer, skoleledere m.m Skolepolitikere Presse/opinionsledere: Det er et ønske at pressen og påvirkere/opinionsledere som kan sette FUG på dagsordenen raskt skal kunne orientere seg og finne frem til nyttig informasjon på nettsidene Med bakgrunn i brukerbehov, målsettinger og brukerscenarier er det utviklet skisser til menystruktur og wireframes som underlag til utvikling av nytt nettsted for fug.no. Se vedlegg 1 og 2. Skal krav 1: Oppstart prosjekt, tidlig høsten 2009 og lansering januar Skal krav 2: Spesifisering av hvordan publiseringsløsningen prises. Det ønskes en beskrivelse av lisensstruktur og/eller prisstruktur for nettredaktører i anskaffelsesåret og det kommende år. Skal krav 3: Tilgang til demoversjon av CMS-løsningen ved anbudsbesvarelse. 1.1 Dagens løsninger Dagens nettsider er drevet på publiseringsløsningen Imaker Site Server 3.3. Imaker i seg selv er bygget i C++. Løsningen kjører på en Linux server med Apache webserver og mysql database. Både fug.no og foreldrenettet.no har en page rank på 6 av 10. Det er avgjørende at denne rangeringen overføres til den nye løsningen. Skal krav 4: Nettstedet skal beholde dagens page rank i ny webløsning. 1.2 Krav til leverandør av ny publiseringsløsning Det er et krav at leverandør kan inngå supportavtale i forbindelse med ny publiseringsløsning. Det er viktig at leverandør er dedikert til FUG som kunde, og at det er lett å komme i kontakt med kontaktperson hos leverandør når det måtte være behov. Det ønskes beskrevet innhold og pris i en slik supportavtale. Det er viktig at det er enkelt å få utført nødvendige rettelser innen kort tid etter innrapportering fra FUG til leverandør. Det er ønsket at mest mulig av etterspurt funksjonalitet allerede eksisterer i grunnløsningen og i allerede utviklede moduler eller tilsvarende, av den publiseringsløsningen som velges. 4

5 Det må i tillegg være mulig å kunne videreutvikle allerede eksisterende funksjonalitet eller å utvikle ny funksjonalitet dersom FUG ønsker dette. En slik endring eller nyutvikling skal ikke måtte avgjøres via leverandørs komiteer/utviklermiljø eller måtte avvente tilsvarende gjennomføring hos andre av leverandørs kunder. Det bør også kunne engasjeres andre leverandører eller nettdesignere til å jobbe videre med nettstedet ved behov. Det bør også være mulig å dra nytte av leverandørs andre kunders utviklede funksjonalitet. Skal krav 5: Supportavtale ønskes, og det ønskes beskrevet innhold og pris på en slik supportavtale Bør krav 1: Smårettelser/- endringer kan utføres kort tid etter innrapportering Bør krav 2: Mest mulig av etterspurt funksjonalitet allerede eksisterer i grunnløsningen eller i allerede utviklede moduler tilpasset løsningen Bør krav 3: Det bør være mulig å kunne videreutvikle allerede eksisterende funksjonalitet eller å utvikle ny funksjonalitet dersom FUG ønsker Bør krav 4: Det bør kunne engasjeres andre leverandører eller nettdesignere til å jobbe videre med nettstedet ved behov. 2 Grunnfunksjonalitet og tilleggsfunksjonalitet 2.1 Artikkelredigering Den nye løsningen skal ha artikkelredigering med WYSIWYG-funksjon for enkelt å opprette, endre og slette artikler med tekst, tabeller, bilder, multimediefiler, dokumenter og funksjonalitetsfelt. Artikkelredigering skal være intuitivt og enkelt å bruke, uten for mange transaksjoner som må gjennomføres før publisering kan utføres. Det skal for webmaster og eventuelt nettredaktører med visse privilegier gis tilgang til HTMLversjon for å kunne overstyre oppsettet. Det bør også være mulig å redigere og legge inn både tekst, bilder, tabeller og fonter på sidene direkte i HTML. Det er viktig at teksten føyer seg riktig rundt bilder, tabeller og grafiske elementer slik at resultatet tilfredsstiller visuelt. Det skal være enkelt å opprette lenker mellom artikler og til dokumenter internt i nettjenesten og eksterne linker til andre websider, og til eksterne nettsider og dokumenter Bruker med redaktørprivilegier skal enkelt kunne flytte en artikkel i strukturen. Det bør være mulighet for krysspublisering slik at en artikkel publisert på en del av nettløsningen enkelt også kan publiseres på andre deler innen nettløsningen. 5

6 Det skal være mulighet til å kunne mellomlagre innhold uten at siden automatisk blir publisert. Nettredaktørene skal selv måtte gi aktiv beskjed i systemet for at en artikkel publiseres. Løsningen bør ha mulighet for tidsstyrt publisering av artikler, sider og seksjoner, og tidsstyrt deaktivering av artikler. Det skal være mulighet for forhåndsvisning av side før publisering. Prioriteringsalgoritmen ønskes satt som siste-sak-først prinsipp, men med mulighet for å overstyre dette manuelt avhengig av viktighet. Ved kopiering av tekst fra andre programmer, f.eks Word, bør formatering fjernes automatisk. Det bør finnes stavekontroll i løsningen. Stavekontrollens ordbok bør finnes på norsk, nynorsk, samisk og engelsk, og må kunne redigeres av nettredaktør/webmaster. Skal krav 6: Publiseringsløsningen skal ha artikkelredigering med WYSIWYG-funksjon. Bør krav 5: Systemet bør gi mulighet til redigering direkte i HTML. Skal krav 7: Det skal være enkelt å opprette lenker mellom artikler og til dokumenter internt i nettjenesten og eksterne linker til andre websider, og til eksterne nettsider og dokumenter Skal krav 8: Bruker med redaktørprivilegier skal enkelt kunne flytte en artikkel i strukturen. Skal krav 9: Det skal være mulighet for mellomlagring av innhold, samt at nettredaktør aktivt må publisere det gjeldende innholdet. Skal krav 10: Det skal være mulighet for krysspublisering Bør krav 6: Tidsstyrt publisering og deaktivering av artikler, sider og seksjoner. Skal krav 11: Mulighet for forhåndsvisning av artikkel før publisering. Skal krav 12: Prioriteringsalgoritmen ønskes satt som siste-sak-først prinsipp, med mulighet til å overstyre. Bør krav 7: Automatisk fjerning av formatering ved kopiering av tekst fra andre programmer. Bør krav 8: Det skal finnes redigerbar stavekontroll i løsningen på norsk, nynorsk, samisk og engelsk. 2.2 Malredigering Maler bør være basert på ikke-leverandørspesifikke standarder, for eksempel XHTML. 6

7 Det er ønskelig at webmaster skal kunne opprette, endre og slette maler, samt gjøre enkel redigering av stilsettet (CSS-filen). Det ønskes å benytte forskjellige maler på forskjellige sider i strukturen. Redaktør skal selv kunne velge om artikkel, teaser, eller annet innhold skal inneholde overskrift, ingress, tekst, eller om enkelte av disse ikke ønskes benyttet i det enkelte tilfellet. Krysspublisering av artikler og innhold kan gjøres i separate malverk, slik at den samme artikkelen eller innholdet kan vises i flere maler, avhengig av i hvilken del av publiseringsløsningen artikkelen ønskes publisert. Det ønskes lagt opp til å kunne veksle mellom å benytte flere ulike, dynamiske forsidemaler. Det skal også være enkelt for redaktør å gjøre endringer i forsidemalen. Bør krav 9: Maler skal være basert på ikke-leverandørspesifikke standarder Bør krav 10: Enkel redigering av stilsettet (CSS) for webmaster Skal krav 13: Det skal kunne benyttes forskjellige maler på forskjellige sider i strukturen Bør krav 11: Redaktør skal kunne bestemme om det skal være overskrift, ingress, tekst osv. på ulike innholdstyper. Bør krav 12: Krysspublisering av artikler og innhold kan gjøres i separate malverk. Bør krav 13: Det er ønske om å kunne veksle mellom å benytte flere ulike forsidemaler. Det skal også være enkelt for redaktør å gjøre endringer i forsidemalen. 2.3 Menyredigering Navigasjon skal være tekstbaserte linker, ikke utvikles i Java/Flash eller som grafikk. Det ønskes mulighet for enkel oppretting, endring, sletting og flytting av menypunkter for nettredaktørene. Det bør kunne opprettes det antall nivåer i menystrukturen som FUG selv ønsker uten begrensninger i systemet. Skal krav 14: Navigasjonen skal være tekstbaserte linker, ikke utviklet i Java/Flash Skal krav 15: Det skal være mulig å opprette, slette, flytte og endre menypunkter Skal krav 16: FUG skal selv kunne bestemme antall nivåer i menystrukturen 7

8 2.4 Filer og arkiv Det skal finnes en dokument- og bildearkivløsning i systemet. Det er et ønske om enkelt å kunne publisere rapporter og publikasjoner som nedlastbare dokumenter. Disse skal vises som et ikon på nettstedet, og indikere type dokument (PDF, doc, Excel osv.) samt filens størrelse. Bildearkivet viser minibilder (thumbnails) av de opplastede bildene. Nettredaktørene skal ha en enkel prosess i forbindelse med opplasting av nye bilder, og enkel plassering av bilder til ønsket artikkel/nettside. Om det er en automatisk skalering på bilder er det en fordel, slik at bildene som lastes inn automatisk vil lagres i de forhåndsdefinerte størrelsene. Det er også ønskelig å kunne velge plassering av bilder uten å bli låst av systemet med hensyn til plassering og skalering av bildet. Alle bilder og dokumenter skal være tilgjengelig for alle nettstedene tilknyttet nettløsningen. Skal krav 17: Bilde- og dokumentarkiv med god oversikt og enkel publisering. Bør krav 14: Automatisk skalering av bilder ihht fastsatte størrelser Skal krav 18: Bilder og dokumenter skal være tilgjengelig i en felles database i løsningen 3 Annen grunnfunksjonalitet eller tilleggsfunksjonalitet 3.1 Multimedia Man skal kunne integrere eller spille av video/tv direkte på valgte undersider/artikkelsider som supplement til aktuelle saker. Det er ønske om statistikk over antall som spiller filmene/ ser TV-innslagene. Skal krav 19: Mulighet til å integrere/spille av video/tv-overføringer på valgte sider Bør krav 15: Generering av statistikk over antall som spiller filmer/ser TV-innslag. 3.2 Relatert informasjon Nye fug.no vil ha forholdsvis mye informasjon, og vil ha en del informasjon om ulike temaer der de ulike temaene i stor grad er relatert til hverandre. Det er viktig for FUG å kunne informere om relatert informasjon innen hvert tema. Det er behov for å vise relaterte artikler og relatert innhold på tvers i systemet. Visning av relatert innhold ønskes plassert på valgfritt område på websiden; mest sannsynlig i midtfelt og/eller til høyre på siden. 8

9 Det ønskes at leverandør anbefaler og beskriver hvordan systematisering og håndtering av relaterte temaer best vil tenkes å fungere for nye fug.no. Det vil vektlegges både hvordan informasjonen blir håndtert ut mot nettstedets brukere, samt hvordan arbeidet forventes å foregå for back-end-brukere av systemet (nettredaktørene). De ulike temaene som vil måtte knyttes sammen i ulik grad på undersider er; Rettigheter og lover (opplæringsloven, kunnskapsløftet) Klageadgang Ofte stilte spørsmål Materiell De gode historiene, forslag til bøker og relevant forskning Relevante lenker Skal krav 20: Mulighet for å vise relasjoner mellom ulike temaer og aktuell informasjon Skal krav 21: Fri eller forhåndsdefinert visning av relatert informasjon i midtfelt og felter til høyre på siden 3.3 Artikkelkommentar På enkelte artikler er det et ønske at brukere skal kunne kommentere på artikkelen og å legge inn spørsmål og å svare på andres kommentarer og spørsmål. Det er ønske om at nettredaktører skal kunne overstyre/slette kommentarer fra brukerne, en moderatorfunksjon. Det må også være mulig å kunne forhindre spam, for eksempel ved at brukerne må taste inn et kodeord før kommentaren publiseres. Nettredaktør må selv kunne velge eller velge bort mulighet om kommentarer på artikler. Bør krav 16: Kommentarmulighet på artikler Bør krav 17: Innlagte kommentarer kan slettes av nettredaktør, moderatorfunksjon. Bør krav 18: Funksjonalitet for forhindring av spam i forbindelse med artikkelkommentarer Bør krav 19: Nettredaktør kan selv velge hvilke artikler kommentarmulighet gjøres tilgjengelig 9

10 3.4 Diskusjonsforum - opsjon Opsjon: et enkelt diskusjonsforum er et ønske, og vi ber om pris og beskrivelse på dette som opsjon. Dersom vi ikke velger denne funksjonen i første omgang er det et ønske at det vil være mulig å legge til diskusjonsforum senere. Det er viktig at systemet har en moderatorfunksjon og mulighet for spamhinder, svartelisting av uønskede brukere. Bør krav 20: Mulighet for utvikling av diskusjonsforum i eller tilknyttet løsningen. Det ønskes oppgitt pris og funksjonalitet på et diskusjonsforum som en opsjon. Bør krav 21: Diskusjonsforumet bør ha en moderatorfunksjon med mulighet til å hindre spam og uønskede brukere 3.5 Språkmodul Enkelte undersider skal være både på norsk, nynorsk, samisk og engelsk. Det vurderes derfor å benytte en språkmodul med mulighet for å bytte mellom flere språkversjoner. Dersom det synes mer hensiktsmessig å løse dette på annen måte står leverandøren fritt til å foreslå en annen løsning. De ulike språkversjonene skal holdes atskilt i administrasjonsverktøyet, men allikevel skal det være enkelt å skifte mellom språkversjonene i editoren slik at sidene kan redigeres samtidig. Fra brukers side skal det være et tydelig skille mellom språkversjonene. Bør krav 22: Det bør være ulike språkversjoner av ulike sider i flere deler av nettløsningen, som er atskilt fra hverandre både i administrasjonsverktøy og for brukerne. 3.6 Formulareditor/elektronisk skjema Nettredaktørene skal selv ha mulighet til enkelt å opprette, endre og slette elektroniske skjemaer i forbindelse med bestilling av publikasjoner, påmelding til kurs, lage enkle spørreskjema og lignende. Skjemaene skal kunne ha de ønskede variabler og felter; nedtrekksmeny, avkrysningsbokser, felter til navn/adresse, med mer. Skjemaet skal kunne generere e-post til den som fyller ut skjemaet ( autoresponder ), samtidig som det lagres/arkiveres i et adresse og e-post register. Det skal være mulig å trekke ut responsfiler via administrasjonsgrensesnittet per elektroniske skjema via eksempelvis regnearkprogrammet MS Excel. Skal krav 22: Løsningen skal ha mulighet for opprettelse av elektroniske skjema med ulike variabler og felter. Skal krav 23: Autoresponder og lagring av e-postadresser fra henvendelser via elektronisk skjema Skal krav 24: Uttrekk av responsfiler fra elektronisk skjema 10

11 3.7 Internsøk Internsøk med prioritering ønskes tilgjengelig på alle sider på nettstedene. Søkemotoren bør også kunne anbefale alternative søkeord ved feilsøk. Fritekst internsøk ønskes tilgjengelig fra alle sider på fug.no. Det er ønsket at prioriteringsalgoritmen sorterer og presenterer forekomster av ord slik: 1. i overskrift 2. i ingress 3. i brødtekst 4. evt. tekst i tabeller 5. evt. tekst i opplastede dokumenter 6. evt. bildetekst (alt.tag) Skal krav 25: Fritekstsøk med egendefinert prioritering, tilgjengelig fra alle nettsidene med ulike prioriteringer per nettsted. Bør krav 23: Søkemotoren må anbefale alternative søkeord ved feilsøk. 3.8 Nyhetsbrev Det ønskes nyhetsbrevfunksjonalitet. Det bør være mulig å lagre en oversikt over abonnentene, samt informasjon om disse hvem de er, bosted, osv. Det bør være mulig å få statistikkoversikt over bl.a åpnerate og klikkrate fra nyhetsbrevene. Dersom leverandør ikke har denne funksjonaliteten selv, kan gjerne også tredjepartsløsning benyttes. Bør krav 24: Løsningen bør ha nyhetsbrevfunksjon, og denne ønskes beskrevet Bør krav 25: Det skal være mulig å få statistikkoversikt over åpnerate og klikkrate på nyhetsbrevene 3.9 Tips-en-venn Løsningen bør ha en tips-en-venn funksjonalitet. Det må kunne tipses om den aktuelle forside eller underside fra hvert av nettstedene. Det ønskes statistikk over hvor mange som bruker tips-en-venn-funksjonen. Bør krav 26: Tips en venn om en side fra hvert av nettstedene og deres undersider. Bør krav 27: Det bør genereres statistikk over hvor mange som bruker tips-en-vennfunksjonen. 11

12 3.10 Datering av innholdssider Det skal være mulig å vise både når en artikkel er publisert og når den sist ble oppdatert. Det skal også være mulig å fjerne datoen manuelt fra enkeltsider og artikler dersom dette er ønskelig. Skal krav 26: Det skal være mulig å vise, eller velge ikke å vise, dato for publisering og oppdatering Automatisk generering Det ønskes automatisk generering av navigasjonssti ( brødsmuler ) som viser hvor i strukturen brukeren befinner seg, og ikke den veien brukeren har gått for å komme til den gjeldende siden. Det ønskes automatisk generering av nettstedskart for de ulike nettsidene. Det skal automatisk genereres logiske nettadresser (aliasing) i henhold til navnet på den opprettede siden. Overskriften som legges inn på den enkelte nettsiden på nettstedet skal automatisk benyttes som title-tag for den gjeldende nettsiden. Brukeren skal kunne skrive ut nettsiden eller midtfeltet som en utskriftsvennlig side. Løsningen bør ha en lenkesamling eller visning av hvilke sider en artikkelside linker til. Det bør også finnes en funksjon som varsler brudd i interne eller eksterne lenker samt en automatisk lenkesjekk. Skal krav 27: Automatisk navigasjonssti over hvor brukeren befinner seg i strukturen Bør krav 28: Automatisk generering av nettstedskart Skal krav 28: Logiske nettadresser (aliasing) Skal krav 29: Overskrifter benyttes automatisk som title-tag for den gjeldende nettsiden Skal krav 30: Utskriftsvennlig side funksjon Bør krav 29: Løsningen bør ha en lenkesamling eller visning av hvilke sider en artikkelside linker til. Bør krav 30: Det bør finnes en funksjon som varsler brudd i interne eller eksterne lenker 12

13 4 Statistikk Det er ønske om integrert statistikk i løsningen hvor nettredaktører/webmaster selv enkelt kan hente ut oppdatert statistikk fra hvert nettsted. Statistikken bør minimum inneholde oversikt over: antall unike brukere/besøk totalt antall brukere/besøk oversikt over hvilke sider som besøkes valg av statistikkperiode etter eget ønske; daglig, ukentlig, månedlig, årlig osv. henvisningskilde (hvor trafikken kommer fra) varighet på besøk konkret besøkstid, men intervaller er også mulig. Det laveste intervallet bør helst være 0-5 sekunder Nedlastede dokumenter Antall klikk på linker, artikler og felter som er viktig å måle trafikk på Hvilken nettleser brukeren har Det ønskes også mulighet til å se statistikk over filmer/tv som blir vist, hvilke sider som sendes som tips en venn. Hvor mange som leser nyhetsbrev og dets åpnerater. Dersom ikke leverandøren selv har statistikkverktøy i sin løsning kan løsning eventuelt leveres via tredjepart. I tilbudet ønskes forklart hvordan leverandør genererer det statistiske materialet. Bør krav 31: Detaljert statistikkmulighet i løsningen. Bør krav 32: Informasjon om hvordan statistikk genereres. 5 Systemkrav Det er ønskelig at løsningen er både plattformuavhengig for visning og administrasjon, og kompatibel med PC og Mac. Websidene som løsningen genererer/malverk skal validere til HTML 4.01 eller senere eller XHTML 1.0 eller senere, samt så langt det er formålstjenlig følge WCAG 1.0 eller senere. Websiden ønskes søkemotoroptimalisert se punkt 12. Brukergrensesnittet i publiseringsløsningen skal lages ut ifra en skjermoppløsning på 1024X768 piksler. Dette skal kunne endres ved behov. Nettsiden skal ha en responstid på maksimum 1,0 sekund. 13

14 Bør krav 33: Plattformuavhengig for visning og administrasjon Skal krav 31: Kompatibel med Mac og PC Skal krav 32: Nettsidene skal søkemotoroptimaliseres (se pkt. 12) Skal krav 33: Nettsidene må følge krav om tilgjengelighet og universell utforming Skal krav 34: Skjermoppløsning på 1024x768 piksler, som skal kunne endres ved behov Skal krav 35: Nettsiden skal ha en responstid på maksimum 1,0 sekund. 6 Brukeradministrasjon og tilgang 6.1 Dokumentasjon og hjelpetekster Det er svært viktig at den nye publiseringsløsningen har et brukervennlig redaktørgrensesnitt. Systemet skal kunne tilby et svært enkelt og intuitivt grensesnitt for å publisere, redigere, og administrere informasjon på nettsidene. Det bør være så enkelt at opplæring av nettredaktører kan gjøres på maks et par timer. Det er ønskelig med dokumentasjon i form av elektronisk brukermanual og integrerte hjelpetekster. Det er viktig at slike hjelpetekster er på norsk og at de vil dekke alle nødvendige områder i administrasjonsgrensesnittet. I de integrerte hjelpetekstene skal være enkelt å endre ordlyd, dersom det er ønskelig. Skal krav 36: Publiseringsverktøyet må være oversiktlig og ha et grensesnitt som intuitivt forstås av nettredaktørene uten spesiell opplæring. Bør krav 34: Elektronisk brukermanual og integrerte hjelpetekster 6.2 Privilegiekategorier Det ønskes egendefinerte differensierte privilegiekategorier som webmaster selv kan opprette og endre. Ulike privilegiekategorier gjelder for tilgang, redigering og publisering i webløsningen. Det være seg journalistbrukere, redaktørbrukere og administrative brukere (back-end-brukere), som har tilgang til hele webløsningen eller kun tilgang til enkelte av nettstedene, enkelte seksjoner, sider, felter og/eller dokumenter i løsningen. Skal krav 37: Egendefinerte differensierte privilegiekategorier som webmaster administrerer. 14

15 7 Design og layout Det ønskes pris på implementering av eksternt levert design. Det er per i dag ikke avklart alle behov rundt maler, men det antas at minimumsbehov for maler er: Forsidemal Seksjonsforsider Utlistingsmal som viser opplisting av søketreff Artikkelmal som tillater frihet i utforming av innhold Nyhetsmal Diskusjonsforum (opsjon) Leverandør kan ta utgangspunkt i føringene i denne kravspesifikasjonen, samt i vedlegg 1, Wireframes for å prise implementering av design for nye fug.no. Skal krav 38: Estimert pris for implementering av design 8 Migrering FUG ønsker å gjøre en del endringer i innholdet ved overgang til ny nettløsning, men noe av innholdet ønskes flyttet automatisk. Følgende innhold skal overføres til nye fug.no: Publikasjoner i PDF-format el.l ønskes overført og lagret i dokumentbase.: ca 200 (inkl alle språkversjonene) Bakgrunnsinformasjon og statiske sider, gamle artikler og innhold som ønskes å overføres slik det der per i dag: ca 150 sider. Bør krav 36: Estimert pris for migrering av oppgitt innhold; 200 dokumenter til dokumentarkiv, innhold på ca 150 sider i dagens webløsning. 9 Hosting/drifting Løsningene ønskes hostet/driftet hos leverandør eller leverandørs samarbeidspartner. Nye fug.no skal tilrettelegges for om lag unike brukere per måned. Det vil være ca 15 administrative brukere av fug.no. Det ønskes oppetid på minst 99%. Vi ber om spesifisering av hvorvidt produktoppgraderinger vil inngå i prisen eller om dette eventuelt vil måtte kjøpes separat, og i så fall til hvilken pris. 15

16 Vi ber også om en spesifisering av årlig vedlikeholdsavgift og eventuelle andre månedlige kostnader som kan påregnes første år, samt kommende år deretter. Skal krav 39: Hosting og drifting hos leverandør eller leverandørs samarbeidspartner Skal krav 40: Tilrettelagt for unike brukere per måned og 15 admin-brukere av systemet Skal krav 41: Minimum 99% oppetid. Bør krav 37: Oppgi prisstruktur for admin-brukere, hosting og drifting av løsningen 10 Opplæring Det ønskes opplæring av hovednettredaktør(er). Til hvilken pris og hvilket omfang kan leverandør gi nødvendig opplæring? Skal krav 42: Opplæring av hovednettredaktør(er), hvilket omfang og til hvilken pris. 11 Testing og akseptanse Det ønskes leverandørbistand i oppsetting, testing og i akseptanseperioden. FUG ønsker også å prøve ut løsningen i redaksjonell bruk før akseptanse signeres. Det ønskes mulighet for support fra leverandøren ved feilretting og justering i etterkant. Vi ber om en presisering av hvorvidt dette er inkludert i prisen, eller vil komme i tillegg. Bør krav 38: Oppgi evt. priser og muligheten for utprøving av løsning før akseptanse og support fra leverandør i akseptanseperioden 12 Kravliste for søkemotoroptimalisering Malverket skal validere (xhtml og css). og Sidene skal være tilgjengelige for funksjonshemmede (følge WAI-retningslinjene) så langt det lar seg gjøre: Retningslinjene for html-kompatibilitet skal følges: Sidene skal være 100% kompatible med Internet Explorer 6 (og senere), Opera 9 (og senere), Mozilla Firefox 3 (og senere), Safari (siste versjon) og Google Chrome. Det skal benyttes menyer som søkemotorene kan lese. Disse skal være tekstbaserte. Rammer (frames) skal ikke benyttes. Viktig tekst skal ikke legges i grafikk, men være tekst (synlig som tekst i koden). Hovedoverskrifter skal ha H1-kode. Andre overskrifter skal kunne kodes med H2, H3 osv. 16

17 Det skal ikke være sesjons-id-er i URL-en. Det skal maks være 2 parametre i URL-ene helst ingen. Det skal være mulig å lage spesifikk tittel for hver enkelt side (title tag). Alternativt kan dette gjøres automatisk ved at overskriften fra hver side hentes inn i title-taggen for denne siden. Det skal være mulig å legge inn META description og keywords for hver enkelt side. Alternativt kan dette gjøres automatisk ved at teksten fra ingressen hentes inn i meta description. (I så fall vil meta keywords ofte være statiske enkeltord som beskriver virksomheten.) Det skal være mulig å utestenge spidere fra bestemte områder (ved at man kan legge ut en robots.txt-fil på rotnivå og ved at man kan legge inn en Robots META-tag). Det bør være mulig å legge ut en sitemap.xml-fil på rotnivå (og oppdatere denne med jevnlige mellomrom). Bruk charset=utf-8. Landsspesifikke spesialtegn skal kodes slik at de vises riktig i alle nettlesere. Det skal ikke forekomme brutte lenker. Det er ønskelig med en automatikk i at ALT-attributt alltid settes inn ved bilder. Dersom ikke brukeren skriver inn tekst som beskriver bildet, skal ALT-attributtet være tomt. Det skal lages et nettstedkart med tekstlinker til alle sidene. Skal krav 43: Etterfølge krav for søkemotorsynlighet så langt det lar seg gjøre. 17