|
22.09.2006
Kurs/workshop hos e-vita, Oslo, 20.09-22.09.2006 + huskeliste til informasjonsarkitektur-jobben
Møtested/tid
E-Vitas lokaler, Oslo, onsdag 20.09 til fredag 22.09.2006
Til stede
Fra UiTø: Jimmy Thomsen, Espen Jensen, Bent Svinnung. Fra E-vita: Jens Foshaug, Ole Petter Remman. Fra ErgoGroup: Jonas Olsson
Referent
Bent Svinnung
ErgoGroup v/Jonas Olsson har forfattet referatet fra dag 1 og 2 av workshopen. Han var nødt til å forlate oss torsdag, og fikk følgelig ikke med seg den forløsende fredagen - da begrepene endelig falt på plass. Referatet bærer derfor preg av dette.
Ole-Petter Remman, e-vita har imidlertid laget en stikkord- og momentoversikt som prøver å trekke linjer for prosessen framover. Bla gjerne igjennom den og få en første føling med de strukturene og begrepene som vi skal tumle med de nærmeste månedene.
Dette UiTø/Hitos-spesifikke referatet omtaler et par av fokuspunktene jeg tror at portalgruppene må ha i bakhodet i den videre prosessen - knyttet til informasjonsarkitekturen.
Informasjonstyper / informasjonsobjekter
Løsningens store forse - metadata-strukturen - er i følge leverandøren avhengig av at vi strukturerer ut fra en del hoved"noder" - søylene i informasjonsmodellen - informasjonstyper.
En informasjonstype benyttes på øverste nivå for å definere de ulike typene av innhold som skal legges i løsningen. Mao. utgangspunktet for å kategorisere innhold, med krav om tilknytning til dimensjoner og egenskaper / attributter. En "grovstruktur" som inneholder et gitt antall attributter, men som i tillegg kan tilordnes et varierende antall andre. (På global-nivå) - I motsetning til f.eks. mapper i WebSIM - som kun har ett, fast sett egenskaper.
I dagens nettsider gjenspeiles "informasjonstyper" til en viss grad i den mappestrukturen som er gjennomført på faktultets- og institutt/avdelingssidene:- Organisasjon (om fakultetet, om instituttet osv.)
- Studier
- Forskning
- Ansatte
- Nyheter (eventuelt en attributt?)
- Tjenester (eventuelt en attributt?)
Når prosessen er sluttført har vi garantert kommet fram til andre/en del flere, for eksempel:- Personkort (knyttet til brukerkonto, med alt av tilleggsinfo - type adresse, epost, bilde, telefon, arbeidsoppgaver, cv, artikkeloversikt, alumni... All info om en student/ansatt/tilknyttet som er ønskelig å gjenbruke/synliggjøre i løsningen. Skal synkroniseres med lønn/personal)
- Organisasjonskort (Ds. for fakultetet/instituttet/avdelingen. Ledelse, adresse, telefoner, styrer osv. Skal synkroniseres med lønn/personal)
- Kvalitetssikring
- Alumni
- Lover og regler?
Til disse informasjonstypene knyttes det en rekke subtyper - innholdsmaler som inneholder gitte attributter plukket fra informasjonstypens totalutbud - for eksempel:- Publikasjon
- Artikkel
- Avtale
- Brev
- Presentasjon
- Skjema
- Referat
- Studieplan
- Notat
Attributter / egenskaper
En attributt kan til en viss grad sammenliknes med et "felt" i WebSIM - og er en egenskap eller kjennetegn ved et objekt – som for eksempel et dokument. Men i motsetning til WebSIM-feltene er ikke attributtene bundet til en fast mal eller mappestruktur.
Det settet av attributter som assosieres med et spesielt objekt omtales som objektets metadata. Metadata er med andre ord data om data, dette omfatter alle grunndata som defineres for en løsning, og kan ses på som en spesifikasjon av innhold og struktur.
Attributter brukes for kategorisering og gjenfinning av innhold. (Er bare synlig ved publisering og ved avansert søk) Mao. definerte "knagger" som skal følge en gitt informasjonstype.
Egenskapene /attributtene kan være enkeltverdier (se verdiliste under) eller en trestruktur hvor en egenskap som eksempelvis er satt til "ansatt --> administrativt ansatt --> saksbehandler" har verdiene i alle nivåer dersom egenskapen settes til saksbehandler.
Verdiliste
En verdiliste benyttes til å lage lister av lovlige verdier som en bruker kan velge mellom ved kategorisering eller søk etter innhold. En verdiliste benyttes i forbindelse med definering av egenskaper / attributter (navnet på verdilista er synlig som valg i datatype-feltet)
Dimensjoner
Dimensjoner danner informasjonsarkitekturen i Virksomhetsportalen, er virksomhetens kunnskapstre (KnowledgeMap) og gjenspeiler de viktigste informasjonsområdene virksomheten er opptatt av.
En dimensjon vil typisk være bygget opp gjennom en hierarkisk folder/"mappe"-trestruktur - og er en alternativ måte å organisere innholdet i løsningen. Men i motsetning til i WebSIM er ikke strukturen endimensjonal. Samme innhold kan ligge i flere dimensjonstrær samtidig.
Eksempel: Fagområder - i tilknytning til emneporteføljen, kvalitetssikring, styrer/råd/utvalg, målgrupper, samarbeidspartnere, interne/eksterne relasjoner osv.
Begrepet granularitet dreier seg om hvor mange nivåer er det hensiktsmessig å lage i dimensjonstreet og som brukeren skal velge fra for en gitt egenskap. For egenskapen målgruppe - eksempelvis - er det nok med å si at vedkommende er ansatt, eller er det viktig å skille på vitenskapelig ansatte og adm. ansatte, osv.
Informasjonsanalyse - bakgrunn
Til alle som sliter med begrepene, kan jeg anbefale Informasjonsanalyse iKnowBase - Attributter, dimensjoner, informasjonsobjekter og roller
Dette er en pedagogisk framstilling av informasjonsarkitekturen - og inneholder blant annet en stikkordliste for den prosessen som vi skal ta fatt på:
Helhetlighet
Det er viktig å se helhetlig når man definerer metadata- Alle informasjonsområder bør dekkes av en informasjonsobjekt-type og en dimensjon (f.eks kunde med tilhørende kundeinformasjon)
- Alle informasjonsobjekt-typer bør følges av en verdiliste med subtyper (f.eks brev, presentasjon, mail, referat etc)
Informasjonsobjekter (IO-typer)- Benyttes for klassifikasjon og inndeling av innholdet i ulike informasjonsgrupper/typer
- Bør som hovedregel alltid kreve at en IO-type alltid har en påkrevet atributt, helst en dimensjon. Dette for enklere gjenfinning
- Husk også at ulike mapper er egne IO_typer (for eksempel Person, Prosjekt, Kunde etc)
Dimensjoner- Benyttes for å gi en strukturert fremstilling av bedriftens informasjonsarkitektur – verdensbilde. Benyttes ofte ved navigasjon og søk etter innhold
- Dimensjoner benyttes for å gi mening til innhold (Kontekst)
- Dimensjon eller verdiliste? Benytter verdiliste når:
- Dersom få forekomster, uten behov for struktur/nivåer (f.eks språk, status etc)
- Det ikke er en naturlig del av ”verdensbildet”
Verdiliste- Det bør lages en felles verdiliste for alle ”subtyper”. Man velger ut hvilke subtyper som skal være lovlig for en gitt IO-type i Forms og Search komponentene. Dette for å gi større fleksibilitet i selve protalsidene. Et eksempel her er at man velger f.eks kun ”Referat” og ”Brev” som lovlige subtyper for IO-typen ”Kundeinfo”
Presisjonsnivå – granularitet- Volum og viktighet avgjør hvor fint (detaljert) man skal legge seg på i fht f.eks dimensjoner
Informasjonseier – hvorfor skal vi alltid ha med dette atributtet?- Benyttes for å tildele eierskap til informasjonen. Dette er ofte andre personer enn de som publiserer/legger inn innholdet.
Spesielle behov i fbm visning og presentasjon i portalsider- Spesielle tagger for å vise f.eks kun et dokument på en side:
- Bruk direkte link til dokumentet via dokumentId = nnnn i uttreksportlet
- Dersom mange ”enkle sider” krever slik direkteaksessering, hvorfor da tagge med andre atributter?
- Bruk grov klassifikasjon for å gi mening til dokumentet, disse vil det trolig være behov for å kunne finne frem til ved f.eks søk og annen navigering (dvs det er alltid viktig å gi noe tagging, selv om dokumentet i utgangspunktet hentes frem via direkte adressering)
Og - til slutt:
Et fersk eksempel på en e-vita løsning: Statens landbruksforvaltning
|
