2 Gjenfinning

For å gjenfinne elektronisk lagret informasjon finnes det to hovedinnfallsvinkler:

1. Navigasjon gjennom ferdigdefinerte menyer og stier gjennom portalen.
2. Søking hvor brukeren er mer aktiv og prøver å lage en snarvei til informasjonen.

Det hjelper lite å ha all verdens informasjon inne i portalen hvis det er vanskelig for brukerne å finne den. Det er viktig at metodene for gjenfinning er tilrettelagt på brukernes premisser i e-servicetorget.

Navigasjon henger tett sammen med design, særlig det man kan kalle "strukturelt design" på et websted. Navigasjon gjøres mulig gjennom bruk av lenker (i form av tekst, ikoner, knapper, faner etc.) og ved at informasjonsstrukturer (taksonomier) gjøres tilgjengelig i form av menyer som kan presenteres på ulike måter.

Det er tre momenter som er relevant i forhold til menybasert navigasjon:

1. Bruk av taksonomier, som definerer menyelementene.
2. At selve menyen presenteres på ulike måter (faste, ekspandérbare, nedtrekkbare, osv) og med ulike fonter, farger etc.
3. Plassering av menyen i skjermbildet eller portalen. Noen menyer kan også gjøres "globale" dvs. at den kan nås uansett hvor man er på nettstedet, mens andre kanskje bare er tilgjengelig fra for eksempel hovedsiden.

Ofte har brukeren et sammensatt informasjonsbehov og trenger flere "biter" som kan befinne seg i forskjellige deler av portalen. Hvis brukeren velger å benytte en meny er det en særlig utfordring for kommunen hvis det bare tilbys én hovedstruktur i portalen og de forskjellige "informasjonsbitene" eller informasjonselementene henger på ulike greiner i denne strukturen. Det stiller store krav til oppbyggingen. Den skal være logisk, begrepene må være meningsbærende og fyndig formulert, slik at man forstår av overordnede menyvalg hva slags informasjon som befinner seg under menyvalgene osv.

Derfor hadde det vært bedre om det fantes flere likeverdige strukturer å velge mellom for å finne informasjonen slik at den enkelte kan benytte den som virker mest logisk. Allikevel må man sannsynligvis lete opp relevant informasjon på ulike steder i portalen, dvs. i ulike informasjonsstrukturer eller på ulike grener i det samme treet. Aller helst burde det ha vært slik at all den nødvendige informasjonen man trenger henger på samme gren eller kvist i informasjonstreet. Men det er ikke så enkelt fordi brukeres behov er så ulike og det kan være vanskelig å forhåndsdefinere alle slike behov. Hvis det ikke er fullt ut mulig bør det i tillegg til gode overordnede menysystemer også tilbys snarveier i form av linker fra den informasjonen brukeren er på til andre informasjonselementer som også kan være aktuelle uten at man behøver å begynne forfra igjen. Dette stiller store krav til intuitivitet og oppbygging av meningsfylte, brukerrettede menysystemer og smarte veier gjennom informasjonen. I tillegg bør det selvfølgelig tilbys gode søkemuligheter.

Den veien brukeren faktisk beveger seg igjennom portalen på kan man kalle en "sti". Dette kan vises i skjermbildet i form av det man kaller en "brødsmulesti". Det kan gjøres på to måter, enten at den viser denne reelle veien brukeren har navigert i portalen på – fra den siden vedkommende entrer portalen fra og gjennom sidene han har vært – til det stedet brukeren befinner seg. Den andre måten er at man kommer inn på en ferdigdefinert sti som gjenspeiler en fast menystruktur. Uansett hvordan brukeren kommer inn på en bestemt side så er den representert med en fast brødsmulesti som gjenspeiler en bestemt menystruktur. Det er fordeler og ulemper med begge metodene og hvilken som tilbys kan være avhengig av den teknologiske portalløsningen. En mer avansert variant er at brukeren på hver informasjonsside tilbys en liste over mange brødsmulestier som viser alle faste veier man kan nå den bestemte siden på og som man kan velge fra for å gå til en annen del av portalen.

Det leddet i brødsmulestien som er lengst til høyre viser hvor brukeren befinner seg. Leddet som befinner seg rett til venstre er den forrige siden brukeren var på og leddet aller lengst til venstre peker til førstesiden i portalen eller til hovedsiden for en spesiell tjeneste i portalen. Det betyr at man kan gå direkte tilbake til en bestemt side ved å klikke på riktig ledd i brødsmulestien.

Metadata og tilknyttede informasjonsstrukturer er svært viktig for god gjenfinning. Selv om man kan ha "håndlagede" menysystemer (da ofte i form av faner eller knapperader), så er det bedre at navigasjonsmenyer bygges opp dynamisk fra informasjonsstrukturene og at hvert menyvalg blir til et "view" eller ferdigdefinert søk mot metadata som igjen genererer en peker til en liste over informasjonselementer eller til ett bestemt informasjonselement.

Et eksempel kan være: "Nyheter" som gir en oversikt over alle nyhetene, enten fra en egen nyhetsdatabase eller en fra mer generell informasjonsbase med dokumenttype = "Nyheter" (som skiller det fra andre typer som: "skjema", "lover" osv.), og ved at poster for eksempel bare for siste uke hentes ut og presenteres omvendt kronologisk i portalen.

Søking er en metode hvor brukeren kan omgå ferdigdefinerte navigasjonsmenyer og mer aktivt finne fram til relevant informasjon selv. Det bør være mulig for brukeren å velge mellom enkelt søk og avansert søk. Det enkle søket er ofte bare en liten søkerute – helst på førstesiden – man skriver ett ord inn i, mens avansert søk ofte er et større og mer komplisert skjermbilde hvor det finnes flere felt man kan fylle ut, hvor man kan velge mellom ulike operatorer som ELLER, OG og IKKE, og hvor man kan velge mellom trunkert og ikke-trunkert søk og det gjerne er menyvalg i tillegg for å avgrense søket på ulike måter.

En treffliste som framkommer på bakgrunn av et søk, enten det er ferdigdefinert eller brukerdefinert, vil inneholde noen overskrifter som for eksempel "tittel", type informasjon, informasjonseier, dato e.l. og som er klikkbare for å komme til det enkelte informasjonselementet. Det innebærer at hvis man ønsker trefflister må man registrere metadata.

Søkefunksjonen bør kunne benytte eventuelle metadata i portalløsningen for å sikre "skarpe søk" for å unngå støy og for å lette gjenfinningen fordi brukeren lett kan se hvilke kategorier som er aktuelle.

Det kan gjøres ved at det for eksempel i søkebildet gis ulike nedtrekksmenyer i ett eller flere nivåer og som brukerne kan velge fra vha. pek og slipp. Fritekst og metadata kan også kombineres ved at brukeren skriver inn et søkeord og avgrenser søket vha. et valg i en nedtrekksmeny.

Søking vha. søkemotor kan være fritekst (vanligst) eller basert på bruk av metatagger i nettsidene eller en kombinasjon. Hvis nettstedet benytter metatagger inne i dokumentene kan alle søkemotorer på nettet benytte disse for å foreta skarpe søk på ulike måter. Best resultat får en hvis metataggsettet er kjent av søkemotoren og hvis alle som la ut metatagger i dokumentene sine benyttet en felles standard for metatagging. I en del land benyttes Dublin Core til dette. Når det gjelder fritekstsøk virker søkemotorene som tilbys i marked ofte litt forskjellig.

Dette området er ikke gjenstand for lovgivning.

Det ser ikke ut til å være noen internasjonale eller norske standarder for hvordan navigasjon gjennom en nettportal best kan tilbys for brukeren. Snarere finnes og praktiseres det et utall måter dette kan gjøres på, ikke minst på kommunale nettsteder. Dette gir frihet for systemleverandører og offentlige virksomheter på området, men det gjør det også vanskeligere for brukere av offentlig informasjon på nettet å finne fram til informasjon fordi praksis er så sprikende.

Når det gjelder søking finnes det standardiseringsinitiativ basert på bruk av Dublin Core (Se 5.3.2 i kapitell 5 om Metadata.)

Det synes ikke å være noen sentrale standardiseringstiltak for å definere best practice i forhold til presentasjon av menysystemer eller plassering i skjermbildet for offentlige eller kommunale nettesteder, men det finnes noen initiativ for å standardisere taksonomier som menyene er bygget opp fra, for eksempel LivsIT.

Kommunen bør forsikre seg at systemleverandøren har gode kunnskaper om prinsipper for dette og kjennskap til gode brukergrensesnitt, anbefalt praksis osv.

Kommunen bør undersøke om alle menysystemer inklusive knapperader og fanerekker kan oppdateres basert på verdier i CMS, eller om noen må oppdateres manuelt. Videre bør man unngå at grafiske elementer brukes som menysystem hvis taksonomien oppdateres i CMS. Det kan gi stivhet og mangelfull oppdatering av menyen.

Det er kommunen som har ansvaret for å utarbeide/gjenbruke informasjonsstrukturer og systemleverandørens oppgave å representere dem i portalens CMS på en god måte. Ofte brukes store ressurser på å lage slike informasjonsstrukturer. Det er få standarder på dette området. En slik standard som er utviklet for å gi tilgang til informasjonen i portalen vha. av livssituasjoner, er utviklet av LivsIT-prosjektet.

En god måte å anlegge førstesiden på kan være å representere ulike perspektiv (som kan være ulike informasjonsstrukturer eller ulike typer informasjon) vha av en knapperad eller faner, for eksempel oppe, horisontalt i skjermbildet, mens aktuelt perspektiv (det man klikker på) kan vises i venstre vertikale meny eller som en nedtrekksmeny e.l. med alle valgene innenfor det perspektivet listet opp. Knapperaden kan for eksempel bestå av: "Min kommune", "livssituasjoner", "tjenester", "nyheter", "politikk" osv. Hvis "livssituasjoner" er valgt vil alle temaene komme fram som aktuell meny, eventuelt med tilhørende livssituasjoner. Tilsvarende for de andre knappene.

Systemleverandøren bør gi rede for om de tilbyr reell eller fast brødsmulesti i portalen eller om kommunen kan velge dette.

Kommunene anbefales å kreve av systemleverandørene at portalverktøyet automatisk legger inn metatagger på kommunens html-sider i overensstemmelse med metoden som er beskrevet i vedlegg X.

Kommunen bør vurdere om man skal tilby portalbrukeren fritekstsøking i kommunens egen informasjon. Dette kan gjøres ved å ha en egen søkemotor på webserveren. Man bør også sjekke om for eksempel norge.no eller andre aktører tilbyr søkemotorfunksjonalitet for brukerne med fullgod indeksering av kommunens nettsider og vurdere om det kan erstatte egen søkemotor.

Hvis e-servicetorget inneholder url’er til informasjonssider utenfor portalen selv, dvs. til andre offentlige nettsider, kan disse gjøres om til en "kolleksjon" som er en input-liste for søkemotorer som indekserer sider som brukerne kan søke i informasjon fra. Hvis kommunen selv har en søkemotor som brukeren kan søke i kan man dermed tilby fritekstsøking også i relevant informasjon i sider man peker til utenfor egen portal. Et eksempel er LivsIT, hvor det leveres linker til statlige sider som en del av metadatasettet som lastes ned fra en sentral webservice. Hvis disse sidene også indekseres kan brukeren dermed søke i fritekst i alle de sidene som er relevante for bestemte livssituasjoner, både kommunens egne og de statlige.

En metode for nedlasting og/eller utveksling av data med andre aktører, for eksempel andre offentlige virksomheter og som er i ferd med å bli utbredt, er "webservices". Dette er en enkel metode som gjør det mulig å benytte xml-ressurser som andre tilbyr på nettet vha. et program på egen maskin (basert på felles nøkler) for å bygge opp funksjonalitet i egen portal som bl.a. henter deler av datagrunnlaget fra andre og tilbyr brukeren sammen med kommunens egen informasjon. Dette kan sees på som et utvidet og avansert søk mot et større virtuelt datagrunnlag enn det som befinner seg på CSM’en til kommuneportalen selv. Hver kommune bør vurdere å legge ut deler av egne data til avnyttelse av andre, slik at for eksempel sentrale, landsdekkende tjenester kan bygges opp hvor også kommunal informasjon er med. Kommunen bør stille krav til systemleverandørens xml- og webservice-kompetanse.