Universitetet i Bergen Styringsgruppen for webprosjektet Bergen 17.6.2011 Sak 22/11 Kravdokument for pilotering av ny web 1 Innledning... 2 2 Gjennomføring av prosjektet... 3 2.1 Prosess... 3 2.2 Tidsplan/milepæler... 3 2.3 Områder som skal testes i piloten... 3 2.4 Dokumentasjon av resultater fra pilot... 4 3 Kontakt med interne og eksterne ressurser... 4 3.1 Teknisk referansegruppe... 4 3.2 Eksterne konsulentbidrag... 4 3.3 DrupalCon (konferanse)... 5 3.4 Dra inn ekstern Drupal kompetanse... 5 3.5 Test med pilotbrukere... 5 4 Webarkitektur... 6 5 Brukeradministrasjon og rollestyring... 7 6 CMS (publiseringsgrensesnitt)... 8 6.1 Funksjonskrav (CMS)... 8 6.2 Oppgaver (pilotcase)... 9 6.2.1 Innholdskontroll og arbeidsflyt... 9 6.2.2 FS-data... 9 6.2.3 Videofiler... 9 6.2.4 Varsling... 9 6.2.5 Andre medier... 9 7 Integrasjon... 9 7.1 Konvertere innhold... 10 8 Søk... 10 8.1 Funksjonskrav... 11 9 Intranett/ekstranett... 11 10 Saker fra Backlog... 12 10.1 Informasjon fra Felles studentsystem... 12 10.2 Informasjon fra Cristin... 12 11 Appendiks... 13 11.1 Elementer som må på plass i CMSet for at oppgavene kan gjennomføres... 13 11.2 Oppgaver CMS (pilotcase)... 14 11.3 Oppgaver søk... 17 12 Vedlegg... 18 1
1 Innledning Etter at universitetsstyret ble orientert om driftsproblemer og tekniske utfordringer med nåværende teknologi for UiBs nettsider (sak 28/10) ble det i november 2010 oppnevnt en styringsgruppe med ansvar for arbeidet med å implementere en ny og fremtidsrettet teknologi for universitetets nettsider. Styringsgruppen for webprosjektet nedsatte i mai 2011 en prosjektgruppe med ansvar for å utvikle en pilot som grunnlag for valg av ny webarkitektur for UiB. Prosjektgruppen ble gitt følgende mandat: 1. Utvikle en pilot som demonstrerer både muligheter og avgrensninger. a. Ett viktig prinsipp i ny webarkitektur er å minimere spesialutvikling til et minimum og bruke standard funksjonalitet i komponenter som f.eks CMS 1. Konsekvensene av dette må være tydelige og synlige i piloten. b. Piloten må være så utfordrende at den gir et svar på om anbefalt webarkitektur vil fungere både i en utviklings- og driftsfase av ny www.uib.no. 2. Utarbeide og levere et detaljert kravdokument som inkluderer både omfang, funksjonalitet i pilot og tidsplan for gjennomføring av piloten. a. Kravdokumentet leveres til styringsgruppen for godkjenning senest fredag 17. juni 2011. b. Styringsgruppen må på bakgrunn av kravdokumentet ha en forståelse for omfang av piloten og hvordan denne vil bli testet (hvem skal teste, hva skal testes, hvordan skal det testes osv). I det påfølgende kravdokumentet vil prosjektgruppen beskrive funksjonalitet som skal inngå i piloten, omfang av piloten og gjennomføring av piloten. All funksjonalitet kan ikke inngå i piloten og prosjektgruppen må foreta prioritering ut fra representativitet og relevans. Piloten skal gi svar på muligheter og begrensninger ut fra prinsipp om minimum av spesialutvikling og mest mulig velprøvd, standard funksjonalitet. Piloten skal være utfordrende og gi svar på om (hvordan) anbefalt webarkitektur vil fungere i utviklingsfase og driftsfase. Styringsgruppen har valgt å bruke Drupal som CMS-komponent i piloten. Resultater av piloten skal dokumenteres. Etter piloten vil det bli evaluering av de erfaringer som er som er dokumentert gjennom piloten. Prosjektgruppen har et selvstendig ansvar for å implementere piloten, men styringsgruppen kan bistå med nødvendig beslutninger som går utover prosjektgruppens ansvar. Det skal være månedlig rapportering til styringsgruppen mot leveranser dokumentert i godkjent kravspesifikasjon. Pilotperioden varer fram til 31.12.2011. 1 CMS er et publiseringssystem eller publiseringsverktøy (eng: Content Management System (CMS)) 2
2 Gjennomføring av prosjektet 2.1 Prosess Arbeidet med piloten vil bli gjennomført i ulike tidsbolker (faser) som avsluttes i forkant av det månedlige møte i styringsgruppen, som vil bli orientert om arbeidet og forelagt eventuelle problemstilinger m.m. Det vil bli gjennomført et gitt antall tester innenfor hver tidsbolk, og resultat fra testene kan gi justeringer og nytenking i forhold til påfølgende faser i piloten. Derfor vil ikke nødvendigvis alle oppgaver utover i piloten være planlagt i detalj. Dessuten vil det kunne bli lagt til nye oppgaver underveis i piloten. Det kan bli behov for samlokalisering i deler av pilotperioden. 2.2 Tidsplan/milepæler Arbeidet i tidsbolkene følger oppsatt møteplan for styringsgruppen. (Foreløpige datoer) 19. august 16. september 21. oktober 18. november 16. desember Til hver tidsbolk er det definert ulike funksjoner og oppgaver innenfor områder som skal testes i piloten. Funksjoner som skal testes og oppgaver som skal gjennomføres er registrert som sak i prosjektstyreverktøyet Redmine (prosjekt.uib.no). Hver sak viser eventuell relasjon til andre saker, hvem som er ansvarlig for saken, estimert tidsbrukt samt start og sluttdato. (Se appendiks/vedlagt Gannt-diagram for oversikt over saker) Tidsbruk til hver sak er estimert i tidsblokker på 5 timer, som tilsvarer ett dagsverk for en person (25 timer = en uke). Flere enn en person kan arbeide med en sak. For eksempel vil hele arbeidsgruppen være involvert i saken Utforske Drupal og tilgjengelige moduler [Sak #596], som er estimert til 100 timer/fire uker. Estimert tidsbruk er grove estimater som i tillegg til omfang også indiker hvor viktig saken er for piloten og hvor lenge man skal arbeide med en sak. Saker skal i prinsippet ikke overskride tidsestimatet med mindre det foreligger særskilt gode grunner for det. 2.3 Områder som skal testes i piloten Fem hovedområder som skal inngå i piloten 1. Webarkitektur 2. Brukeradministrasjon og rollestyring 3. CMS (publiseringsgrensesnitt) 4. Integrasjon 5. Søk 3
Til hvert område vil det være et definert antall funksjoner som skal inngå i piloten. Til hver funksjon vil det blir knyttet en eller flere kontrete, representative oppgaver (pilotcase) som testes i piloten. Hvert område blir omtalt i kapitel 4-8. 2.4 Dokumentasjon av resultater fra pilot Til hver sak som er registret i prosjektverktøyet vil det bli gitt en skriftlig vurdering av resultatet, bl.a. vurdering av behov for egenutvikling og vurdering av modulerer 2 som eventuelt må benyttes. Det skal dessuten rapporteres om eventuelle funn som krever justeringer og nytenking i forhold til påfølgende faser i piloten (j.fr punkt 2.1) 3 Kontakt med interne og eksterne ressurser I oppnevningsbrevet for styringsgruppe for webprosjektet blir behovet for kontakt og bidrag fra både interne og eksterne resurser særlig fremhevet. Det er viktig at gruppen sikrer kontakt med viktige aktører i organisasjonen (fagmiljøer, driftsansvarlige og andre) om konkrete problemstillinger relatert til teknologi og innhold. Styringsgruppen skal hente inn erfaringer fra andre universiteter og institusjoner det er nærliggende å sammenligne seg med og vurdere om det er grunnlag for konkret prosjektsamarbeid. Prosjektgruppen vil ha kontakt med ulike aktører gjennom hele pilotperioden. Og systemet som settes opp for piloten vil i utgangspunktet være observerbart for alle interessert gjennom hele perioden. 3.1 Teknisk referansegruppe Teknisk referansegruppe vil få innsyn med arbeidet underveis i piloten og inviteres til å teste systemet når systemet er klargjort for pilotbrukere (se nedenfor). Et endelig opplegg vil bli drøftet i neste møte i referansegruppen. 3.2 Eksterne konsulentbidrag Arbeidet med pilot vil bli gjenstand for ekstern evaluering og prosjektgruppen vil innhente eksternt konsulentbidrag i september og i avslutningsfasen av pilot. Formålet med ekstern evaluering er å få innspill både på gjennomføring av piloten og på problemstillinger relatert til teknologi. [Sak #614] og [Sak #615] For å sjekke at CMS validerer mot universell utforming, etablerte webstandarder og offentlige forskrifter for kode foreslår prosjektgruppen å bruke ekstern kompetanse. [Sak #618] I notat Pilotering av ny web er det i tillegg lagt opp til ekstern vurdering av webarkitektur etter at piloten er gjennomført. 2 Contributed modules are add-ons for Drupal, allowing you to extend, build, and customize Drupal s core functionality. These modules are not part of the core files and may not have optimized code/functionality for your purposes. If there isn t a module to solve your needs, you can create one for the rest of the community to use, or consider joining forces and helping the maintainer. (10. juni 2011 var det registrert 10 098 moduler i Drupal.) 4
3.3 DrupalCon (konferanse) Drupal er basert på åpen kildekode og utvikles og vedlikeholdes av brukere og utviklere over hele verden. Systemet er (mest) designet for programmerere og krever intern faglig kompetanse, noe som blir påpekt av teknisk referansegruppe (26/5/2011) og i notat om anbefaling av ny web (punkt 3.1.1.). Selv om Drupal ikke er valgt som CMS, vil kunnskap om systemet være svært god hjelp i pilotfasen. For å få bedre kunnskap om systemet; bli kjent med og knytte kontakter med utviklermiljøer og institusjoner som bruker Drupal, samt få innsikt i organisering, dokumentasjon og videreutvikling av programvaren og tilbakeføring av kode, anbefaler vi at personer som skal arbeide med piloten deltar på europeisk kongress for Drupal i London, 22-26. august. DrupalCon er en årlig kongress som samler både utviklere, brukere og administratorer av Drupal. Sak [#611] 3.4 Dra inn ekstern Drupal kompetanse Erfaringer underveis i piloten kan føre til behov for referansebesøk hos en eller flere institusjoner som bruker Drupal. Dette innebærer kartlegging av aktuelle miljøer Det er også interessant å invitere eventuelle ressurspersoner på Drupal i Norge og Norden, gjerne med erfaring fra UH-sektoren, til en felles samling i Bergen der vi kan få råd og tips om hvordan de ville gjort det vi har gjort i piloten og arbeidet som gjenstår. [Sak #597] 3.5 Test med pilotbrukere I siste fase av piloten, når systemet er satt opp og prosjektgruppen har gjennomført en grunnleggende test av webarkitektur og CMS, vil kompetente brukere av nåværende system og andre faglige ressurspersoner i organisasjonen, inkludert studenter, vil bli invitert til å teste systemet. Det vil også være aktuelt å invitere et institutt til å teste systemet, bl.a. for å sikre at vi får et sammensatt, representativt utvalg av pilotbrukere fra alle deler av virksomheten til UiB. Testen vil primært være av publiseringsgrensesnittet i CMSet. Konkretisering og planlegging av testen vil bygge på erfaringer som er gjort av prosjektgruppen tidligere i pilotfasen. Pilotbrukere vil bl.a. kunne gi verdifulle tilbakemeldinger på brukeropplevelse av publiseringsløsningen og ny UiB web. [Sak #603] 5
4 Webarkitektur Ny anbefalt webarkitektur er sammensatt av moduler og komponenter som er funksjonelt gode innefor sitt område. Informasjonen som presenteres på web settes sammen av et lag på toppen av komponentene i webarkitekturen. Målet er å raskt sette opp et live system som representerer et subsett av funksjonaliteten i www.uib.no basert på prinsippene for ny webarkitektur og med Drupal som CMS komponenten. (j.fr. punkt 2 i Pilotering av ny web) I første fase vil vi rigge opp et enkelt system som kan realiseres i løpet av kort tid, med Nginx/Apache som frontend og Drupal som det kommer "out-of-the-box" som backend Første måneden vil vi bruke til å bli kjent med Drupal og tilgjengelige moduler og konkret prøve å sette opp: LDAP innlogging på Drupal finne ut hvilke Drupal konsept vi vil bruke for å representere område ("taxonomy", "node" eller noe annet?) etablere område for minst ett fakultet med 2 3 institutter, f.eks: http://www.uib.no/matnat, http://www.uib.no/ii og http://www.uib.no/geo etablere område for noen forskingsgrupper/forskerskoler etablere område for utdanning 6
presentasjon av /personer/<navn> sidene. Forenklet versjon, men i hvert fall noe å lenke til som forfatter av artikler og lignende. definere UiB-theme (utseende) Neste fase er å introdusere andre komponenter. Skrive "FS-Pres" applikasjonen 3 (som skal gjenskape sidene /emne/<emnekode> og /studieprogram/<programkode>). Til å begynne med kan denne applikasjonen være en midlertidig løsning som genererer statiske sider som så plasseres inn i navnerommet via regler i frontend. Problemer som må avklares: etablere konvensjoner rundt stiler og maler (css, assets) hvordan lenke på kryss (emner linker til ansvarlig område, CMS artikler linker til emnekoder og studieprogram) bilder i studieprogrampresentasjonen (hvor kommer bildene fra) Etter at dette er etablert, kan "FS-Pres" forbedres til å virkelig hente data fra FS og eventuelt bli en fullverdig applikasjon dersom tiden tillater det. En forbedring av "FS-Pres" kan skje skrittvis utover i prosjektperioden. [Sak # 599], [Sak # 601] og [Sak # 602] 5 Brukeradministrasjon og rollestyring Rollene i eksternweb styres fra Sebra og knytter sammen personer og områder. Det er 3 roller i bruk idag; redaktør, skribent og ansatt. I dagens løsning blir områder og roller hentet inn via XML-baserte webtjenester. Vi ønsker å eksperimentere med bruk av LDAP som protokol istedenfor, p.g.a lavere overhead ved online spørring og generell overgang til LDAP som standard for spørring etter denne type informasjon. Sebra vil opprette test-ldap tilpasset piloten som også kan betjene vanlig innlogging av alle med UiB-id. Denne LDAPen er tilgjengelig allerede nå. Oppgaver: Sette opp innlogging på CMSet via LDAP Er konseptet webdesk og "current" område noe å ta med seg videre? Medfører behov for å genere liste over alle områdene denne brukeren har tilgang til. Skrivetilgang til artikler basert på rollene definert i LDAP Generere ansattlister basert tilsvarende rolle Tillate redigering av personsiden (uavhengig av rolle) [Sak # 583], [Sak # 585] og [Sak # 624] 3 FS-Pres er arbeidsnavn for applikasjoner som skal presentere FS-data 7
6 CMS (publiseringsgrensesnitt) Notatet "System- og funksjonalitetskrav til teknologisk plattform for UiBs nettsider" (se vedlegg) gir innspill til funksjonalitetskrav til det nye CMSet som skal inngå som en del av UiBs webarkitektur. Det er ikke formålstjenlig å lage pilotcaser for alle disse kravene. De fleste av funksjonskravene er slike vi forventer å finne i et moderne CMS og bør bare sjekkes av i løpet av pilotfasen. Ulike CMSer vil ivareta slike funksjoner på ulike måter, men vi bør lengst mulig unngå diskusjoner om dette, så lenge funksjonaliteten finnes. Noen funksjonskrav har vi likevel behov for å lage pilotcaser på. Dette gjelder krav som har særlig betydning for to områder der vi går ut fra at vår organisasjon har særskilte behov; arbeidsflyt og innholdsdeling. I tillegg har vi valgt ut noen enkeltkrav til funksjonalitet det har vært særlig fokus på i utviklingen av nåværende webplattform. 6.1 Funksjonskrav (CMS) Funksjonskrav er hentet fra, og har samme nummerering som i notatet System- og funksjonalitetskrav til teknologisk plattform for UiBs nettsider (se vedlegg) Nedenfor følger liste over funksjoner som skal testes (hver funksjon er merket med saksnummer den er tilknyttet i piloten) 1 d Versjonshåndtering [#588] [Sak #605] 1 e Artikkelstatus [Sak #605] 2 a Automatisk oppflyt av innhold [Sak #605] 2 b Kontroll av "andres" innhold [Sak #605] 2 c Kontroll av"eget" innhold [Sak #605] 2 d Områdehierarki + sidehierarki (særlig pkt. iv) (dette dreier seg om integrasjon) 2 h Krysspublisering av artikler [Sak #605] 2 i Krysspublisering av sider [Sak #605] 2 j Krysspublisering: Push og Pull [Sak #605] 2 l Obligatorisk utfylling av innhold [Sak #605] 2 m Automatisk pen URL [Sak #605] 2 r Kobling mellom innhold [Sak #605] 2 s Koblinger mot integrerte data [Sak #605] 2 t Behandling av integrerte data [Sak #600] 4 c UiB-ontologi som metadata [Sak #605] 5 b Strukturering av menyer [Sak #605] 5c Eget innhold til arvete menyer [Sak #605] 6 e Multimediearkiv Mediehåndtering [Sak #609] 7 d Videokonvertering (særlig pkt ii) [Sak #609] 7 h Mediehåndtering: filtyper [Sak #605] 8 g Varsling [#588] [Sak #605] 9 b Andre medier [Sak #589] 10 h Godkjenningsmuligheter [Sak #605] 12 b Filter [Sak #605] 8
6.2 Oppgaver (pilotcase) (Se appendiks for detaljert oversikt og beskrivelse av oppgaver) 6.2.1 Innholdskontroll og arbeidsflyt Dette caset tester arbeidsflyten mellom innholdsprodusent og redaktør; tester deling av innhold basert både på innebygd logikk og brukerkontrollert dytting/henting; tester redaktørkontroll av delt innhold (inkl. overstyring av automatikk); tester ulike nivåer av eierskap til innhold; tester url-logikk; tester obligatoriske felt; tester bruk av "offisielle temaord"; tester kobling mellom ulike typer innhold, både CMS-generert og integrert; tester menylogikk (inkl. deling), tester begrensning av filtyper. 6.2.2 FS-data Dette caset tester visning av et studieprogram, der det meste av informasjonen hentes fra FS. Det tester også muligheten for å legge til innholdselementer i visningen samt gjøre koblinger til annet innhold. Caset tar utgangspunkt i dagens visning av studieprogram på uib.no, med foreslåtte endringer fra Studieadministrativ avdeling. Det er lagt til en kobling mot forskergrupper, for å teste et behov for utvikling av "studiemuligheter" som en framtidig, ny innholdstype. (J.fr. omtale av FS-pres under kap. 4) 6.2.3 Videofiler Dette caset tester opplasting av videoer, konvertering av format og etablering av en felles web-tv -side for alle videoer. 6.2.4 Varsling Dette caset tester varsling av at innhold nærmer seg utgått dato, samt fornyelse av innhold. 6.2.5 Andre medier Dette caset tester moduler for tilpassing av innhold mot småskjermenheter. 7 Integrasjon Det er ikke hensiktsmessig å integrere alle data i CMSet før det presenters på web. Til piloten vil vi integrere med Sebra for å definere opp roller, og ta med FS-data for å vise hvordan et stort system kan integreres som ekstern modul og hvilke følger det får. Andre integrasjoner, for eksempel data fra JobbNorge (RSS) og DBH oppfattes som trivielle og vi vil ikke bruke tid i piloten til å demonstrere dem. [Sak #583], [Sak #584], [Sak #599], [Sak #600] og [Sak #608] Angående integrasjon av data fra Cristin 4 til personsider, vil vi rigge om slik at personsideinformasjon autoritativt ligger hos Cristin. Det er to måter å gjøre dette på; at CMSet enten henter alle dataene fra Cristin eller lenker til eller integrerer personsiden 4 Current Research Information System In Norway. Systemet er et verktøy for forskere og forskningsmiljøer i Norge for å registrere og profilere publikasjonsdata, prosjekter, enheter og kompetanseprofiler. Systemet brukes også til innrapportering av publikasjonspoeng. 9
generert av Cristin. Dette er en oppgave fra backlog som skal følges opp i pilot. (Se omtale av Saker fra backlog nedenfor) [Sak #595] 7.1 Konvertere innhold Formålet er å demonstrere hvordan man kan overføre innhold fra eksternweb til nytt CMS ved å overføre data fra et institutt / område. Dette involverer å sette opp views på ZTM 5 siden som eksporterer data og noe på Drupal siden som tar imot. Det bør spesielt beskrives hvordan fil-vedlegg og bilder behandles. Hvilke felt må settes på innholdstypene i Drupal for å fange opp relasjonene som finnes i ZTM dataene. [Sak #591] 8 Søk Punkt 11 Ekstern søk i notatet System- og funksjonalitetskrav til teknologisk plattform for UiBs nettsider (av 15.04, se vedlegg) beskriver spesifikke krav til søk i en ny løsning. Søk er en sentral inngang til informasjon på vår web, ifølge statistikk blir det utført ca 2600 unike søk daglig. Derfor er det viktig at søkefunksjonaliteten holder et høyt nivå. 3 viktige momenter knyttet til søk er: Søket skal omfatte all informasjon som blir presentert i vår løsning, dette inkluderer blant annet FS-data Søket skal kunne avgrenses i forhold til ulike filtre/kategorier, for eksempel studieprogram og person Søket skal kunne gi utvidet resultat etter innlogging Dagens web benytter Google Site Search som søkemotor, og dette søket fungerer nøyaktig som et vanlig googlesøk begrenset til uib.no-domenet. I forhold til kravspesifikasjonen er det hensiktsmessig å utforske andre løsninger på, mulige løsninger: Drupals innebygde søk Drupal har et innebygd søk, dette må testes i de spesifiserte casene. Dette søket tar utgangspunkt i data som ligger direkte i CMSet, derfor blir det en utfordringer hvordan er kan ta med data som ligger eksternt(fs-data). Googlesøk Googlesøket tar utgangspunkt i indeks bygget opp av Google, så alle nettsider som er som finnes i et vanlig googlesøk vil finnes i dette søket. Dette er problematisk fordi det finnes et ønske om kunne finne data som krever innlogging. 5 ZTM er CMS som er brukt på UiBs nettsider (eksternweb) 10
Drupals innebygde søk kombinert med googlesøk Det som kan vise å fungere er å kombinere Drupals innebygde søk og google sitt søk. Slik at innloggede brukere utfører et søk, vil de i tillegg søke ved hjelp av det innebygde søket. Kommersielle aktører Det kan være interessant å få en demonstrasjon av hvordan eksterne tilbydere kan løse søket vårt. Av interessante tilbydere finnes blant annet texturgy semantic search, FAST og Google Search Appliance [Sak # 602] og [Sak # 617] 8.1 Funksjonskrav Funksjonskrav som skal testes 11.a Sortering av søkeresultatet 11.b Synonymer 11.c Manipulasjon av søkeresultatet 11.d Flerspråklig 11.e Kategorier/Filter 11.f Auto Complete Nye krav 11.x Finne innhold basert på rolle. (Se appendiks for detaljert oversikt og beskrivelse av oppgaver) 9 Intranett/ekstranett UiBs nettsider vil ha innhold spesielt rettet mot avgrensede grupper, både egne ansatte og ekstern grupper. Det må være mulig å skjule/skjerme slikt innhold for andre brukere gjennom pålogging. På kort sikt skal det opprettes en Ressursside for ansatte på et eget område på UiBs nettsider som overtar de viktigste funksjonene til UiBs intranett. Test av løsninger for pålogging for å få tilgang til innhold, inngår derfor i piloten, herunder pålogging for eksterne brukere. [Sak #625] Det langsiktige målet er å etablere en personifisert løsning der ansatte selv tilpasser visning av nyheter, tjenester og verktøy ut fra eget behov, inkludert mulighet for sømløs overgang /single sign-on til utenforliggende tjenester som for eksempel PAGA 6 Det forligger foreløpig ingen spesifikasjon for personlige, men det vil bli gjort et forsøk på hvordan PAGA kan integreres i en personlig side. [Sak #626] 6 PAGA er personal- og lønnssystemet ved Universitetet i Bergen der ansatte har tilgang til personlige opplysninger, lønnsslipper m.m. 11
10 Saker fra Backlog Prosjektgruppen er bedt om å vurdere fem saker fra backlogen som caser i piloten. Fire dreier seg om visning av informasjon fra Felles studentsystem (FS), en om visning av informasjon fra Cristin. Piloten bør avgrenses mest mulig i antall caser, for å sikre gjennomførbarheten. I tillegg er det interessant at resultatene av pilotcasene er mest mulig sammenliknbare med det som vises i nåværende webløsning. Samtidig må casene være utfordrende nok til at webarkitekturen blir testet godt nok. Piloten vil kun teste muligheter for gode løsninger uten tanke på produksjonssetting. Eventuell klargjøring for produksjon må gjøres etter at piloten er avsluttet. Dette kan bli ressurskrevende og må derfor vurderes grundig før endelig beslutning tas. 10.1 Informasjon fra Felles studentsystem Foreliggende forslag er derfor at sak 113 fra backlogen (Revisjon av studietilbudsmalene) blir et pilotcase, med følgende presiseringer: Revisjonen begrenses ut fra hva som foreligger av enkle endringsforslag, og det legges til et element fra sak 101 (Studiemuligheter) til caset, fordi det vil gi en mer utfordrende test av den skisserte webarkitekturen. De andre nevnte sakene fra backlogen (sak 106 Phd-kurs, sak 103 Utvekslingsavtaler - og sak 101 Studiemuligheter), vil da være lettere å implementere i den nye webarkitekturen i etterkant av piloten, gitt at resultatet er tilfredsstillende. [Sak #600] 10.2 Informasjon fra Cristin Et pilotcase på Sak 122 (Vise data fra Cristin) i backlogen vil ikke nødvendigvis gi utfyllende kunnskap om CMSet eller webarkitekturen enn de vi får fra de andre casene. Det kan likevel være av verdi å få testet Cristins webtjenester i seg selv. Derfor lages pilotcase for denne saken, med forbehold om at det er tid til å teste dette i løpet av piloten. Her lager vi ett enkelt case for piloten (hente lister fra Cristin inn på personside) og ett avansert (hente hele personsiden fra Cristin). [Sak #595] 12
11 Appendiks 11.1 Elementer som må på plass i CMSet for at oppgavene kan gjennomføres [2d] Områdehierarki + sidehierarki i) Opprett to områder av typen "fakultet" i Sebra: 1. Det matematisk-naturvitenskapelige fakultet 2. Det samfunnsvitenskapelige fakultet ii) Opprett fire områder av typen "institutt" i Sebra: 1. Institutt for biologi * 2. Geofysisk institutt ** 3. Institutt for sosialantropologi ** 4. Sosiologisk institutt ** * Gis tilhørighet til Det matematisk-naturvitenskapelige fakultet ** Gis tilhørighet til Det samfunnsvitenskapelige fakultet iii) iv) Endre tilhørigheten til Geofysisk institutt til Det matematisk-naturvitenskapelige fakultet Slett området Institutt for sosialantropologi i Sebra v) Opprett området "Global" av typen "tema" i Sebra (UiB Global?) vi) vii) viii) ix) Opprett området "Marin utviklingsbiologi" av typen "forskningsgruppe" i Sebra Lag visning av studieprogrammet Bachelorprogram i biologi (hentet fra FS) Lag visning av studieemnet BIO100 (hentet fra FS) Etabler innholdstypene "Områdeforside", "Infoside", "Nyhet", "Arrangement", "Personside", "Studieprogram", "Forskergruppe", "Web-tv", "Video". x) Etabler toppmenyer på alle områder med punktene "Forskning" og "Kontakt" xi) Sett "tittel" som obligatorisk felt på innholdstypene "Infoside", "Nyhet" og "Arrangement". xii) Det må settes opp en e-postvarsling for innhold som nærmer seg utgått dato. xiii) Det må finnes fram til en eller flere plugins i Drupal som har til hensikt å tilpasse innholdet for visning på småskjermenheter. 13
xiv) Opprett brukerne Arne Admin (AA), Reidar Red (RR), Hanne Hybrid (HH) og Pia Prod (PP) AA er redaktør på MN-fak og SV-fak RR skal være redaktør for Institutt for biologi og Geofysisk institutt HH skal være redaktør for Institutt for biologi og innholdsprodusent for Geofysisk institutt PP skal være redaktør for Sosiologisk institutt og UiB Global 11.2 Oppgaver CMS (pilotcase) A Innholdskontroll og arbeidsflyt Dette caset tester arbeidsflyten mellom innholdsprodusent og redaktør; tester deling av innhold basert både på innebygd logikk og brukerkontrollert dytting/henting; tester redaktørkontroll av delt innhold (inkl. overstyring av automatikk); tester ulike nivåer av eierskap til innhold; tester url-logikk; tester obligatoriske felt; tester bruk av "offisielle temaord"; tester kobling mellom ulike typer innhold, både cms-generert og integrert; tester menylogikk (inkl. deling), tester begrensning av filtyper. 1) [1e, 2c, 2j, 10h] 1. HH kladder en nyhet for Geofysisk institutt 2. HH legger bilde 1 til nyheten, merker det med at det bare skal kunne brukes av henne 3. HH legger bilde 2 til nyheten, merker det med at det bare skal kunne brukes av Geofysisk institutt 4. HH merker at nyhet skal vises på Sosiologisk institutt 5. RR forsøker å finne kladden til HH (skal mislykkes) 6. HH åpner kladden, redigerer og sender den til godkjenning 7. RR får varsel om godkjenning, åpner saken, redigerer den og godkjenner/publiserer 8. PP får varsel om at saken kan vises på Sosiologisk institutt, og godkjenner 2) alt i) alt ii) [2a, 2b] AA fjerner saken fra visning på SV-fak (eks. i forsideliste) AA får varsel om at saken kan vises på SV-fak, og godkjenner 3) [1d, 1e, 2j, 8g] 1. RR trekker saken tilbake 2. AA får varsel om at den er trukket tilbake (PP får ikke varsel) 3. HH finner saken, henter fram en eldre versjon, redigerer, sender den til godkjenning 4. RR får varsel om godkjenning, godkjenner/publiserer 5. PP får varsel om at saken kan vises på Sos, avviser 14
4) alt i) alt ii) [2a, 2b] AA fjerner saken fra visning på MN-fak (eks. i forsideliste) AA får varsel om at saken kan vises på MN-fak, og godkjenner 5) [2c, 2h, 2i, 2l, 2m, 7h] 6) [2j, 5b, 5c] 1. RR lager en infoside for Geofysisk institutt 2. RR lager ikke tittel på siden (obligatorisk felt: tittel) 3. RR forsøker å legge til bilde 1 fra HH (skal mislykkes) 4. RR legger til bilde 2 fra HH 5. RR forsøker å laste opp et word-dokument som vedlegg til saken (skal mislykkes) 6. RR merker av at saken skal vises på følgende steder i Geofysisk institutts meny: Kontakt og Forskning/Planer 7. RR publiserer saken (skal mislykkes pga manglende obl. felt) 8. RR legger til tittel og publiserer saken 9. PP sjekker at saken vises med unik url for hvert av menypunktene, med sakens tittel som siste ledd av url-en 1. PP henter saken inn under en meny på Sosiologisk institutt 2. PP henter menypunktet "Planer" fra Geofysisk institutt inn i Sosiologisk institutts meny og ser at saken blir med som underside 3. PP lager en infoside og legger til som underside til "Planer" 7) [2r, 2s, 4c, 12b] 1. RR redigerer infosiden, lager en kobling til personen AA (personside) og Institutt for biologi, lager kobling til Bachelorprogram i biologi, og merker saken "Global" (fra liste over faste temaord). 2. AA søker etter infosiden fra Geofysisk institutt, finner den både når han filtrerer på forfatter RR), kategori (infoside), tag (Global), område (Geofysisk institutt, Sosiologisk institutt, Global) og status (publisert). B FS-data Dette caset tester visning av et studieprogram, der det meste av informasjonen hentes fra FS. Det tester også muligheten for å legge til innholdselementer i visningen samt gjøre koblinger til annet innhold. Caset tar utgangspunkt i dagens visning av studieprogram på uib.no, med foreslåtte endringer fra Studieadministrativ avdeling. Det er lagt til en kobling mot forskergrupper, for å teste et behov for utvikling av "studiemuligheter" som en framtidig, ny innholdstype. 15