DiBK migrerte fra et gammelt CMS til Enonic

Direktoratet for byggkvalitet (DiBK) er et nasjonalt kompetansesenter på bygningsområdet. Direktoratets hovedoppgaver er å 1) sikre trygge, miljøvennlige og tilgjengelige boliger og bygg, og 2) bidra til å etablere forutsigbare regler for effektiv ressursbruk i byggeprosessen.

DiBK hadde vært Optimizely-kunde i mange år, og kjørte på en gammel, utdatert og snart usupportert versjon av publiseringsløsningen. Med fare for å sitte fast med en løsning uten teknisk støtte, bestemte DiBK seg for å anskaffe en ny.

En offentlig anskaffelsesprosess ble igangsatt og en offentlig anbudskonkurranse ble utlyst i mars 2022. Etter å ha evaluert de mange tilbudene, ble det norske systemintegratorbyrået 99x valgt i juni 2022, med et tilbud som inkluderte implementering av Enonic-plattformen.

Planlegging og arbeid startet i løpet av sommeren og tidlig høst 2022 før det nye, migrerte nettstedet for Direktoratet for byggkvalitet ble lansert i februar 2023.

Utfordring

DiBKs kjerneoppgaver i sin digitale plattform er å digitalisere byggesaker og gi veiledning om bygningstekniske forskrifter. Forskriftene må derfor være digitalt tilgjengelige og kunne integreres med andre systemer.

DiBK ønsket seg et fremtidssikret CMS som sømløst kunne integreres med egenutviklede løsninger og eksterne API-er. Dette markerte starten på et migreringsprosjekt ledet av 99x.

Migreringsmål

1. Effektiv publisering av digitale veiledere
2. Mulighet til fleksibel testing av brukersentrerte konsepter
3. Enkel justering av innhold og design av interne brukere
4. Generelt enklere og mer effektiv drift

Utfordringer med eksisterende CMS

• Slutt på støtte: DiBKs CMS-versjon nærmet seg slutten av sin levetid. Dette krevde en endring for å sikre fortsatt teknisk støtte og systemsikkerhet.
• Krevende innholdsprosess: Innholdsforvaltningen var utfordrende. Mange maler gjorde det ineffektivt og overveldende for nye redaktører.
• Kompleks strukturell løsning: Den eksisterende CMS-løsningen var strukturelt tungvint, noe som førte til utfordringer med navigasjon og innholdsforvaltning.
• Omfattende og uoversiktlig innholdstre: DiBK møtte vanskeligheter med et overdrevent omfattende og lite intuitivt innholdstre, noe som kompliserte organiseringen og hentingen av innhold.
• Treg søkefunksjonalitet for innhold: Søkefunksjonaliteten i CMS-et var tregere enn optimalt, noe som påvirket effektiviteten av å finne og administrere innhold.
• Blandet teknologi: DiBKs digitale infrastruktur var bygget på en blanding av teknologier, noe som førte til kompatibilitetsproblemer med de nyere versjonene av Optimizely.
• Lange lastetider: Den eldre versjonen av CMS-et opplevde lengre lastetider, noe som påvirket opplevelsen av innholdsforvaltningen.
• Høye kostnader for malutvikling: Utvikling og vedlikehold av tilpassede maler på den utdaterte plattformen var både kostbart og tidkrevende.
• Manglende fremtidsretting: Det eksisterende oppsettet manglet fleksibilitet for fremtidige utvidelser, spesielt når det gjaldt å integrere og administrere nye systemer eller komponenter.

Løsning

Redaksjonen i DiBK var ivrige etter endringer. De var på jakt etter et CMS som tilbød brukervennlighet og effektivitet i publisering av retningslinjer og administrasjon av innhold, samt fleksibilitet i byggingen av tilpassede sider.

Samtidig måtte den nye løsningen overholde en headless-arkitektur for fremtidige krav. For DiBK virket Enonic-løsningen fra Seeds forslag fleksibel og intuitiv, samt kostnadseffektiv.

Migrering: Steg for steg

99x sto overfor oppgaven med å migrere den gamle løsningen i et 1:1-forhold til en ny løsning, en prosess som involverte manuell kartlegging av parts, makroer, mixins og innholdstyper. Denne grundige tilnærmingen ble hjulpet av opprettelsen av Excel-ark for alle nødvendige felt. 99x utviklet også plugins som muliggjorde uttrekk av innhold fra Optimizely for import til Enonic.

Den formelle migreringsprosessen ble organisert som følger:

1. Gå gjennom løsningen og kartlegg alle felt og innholdstyper.
2. Gå gjennom de øverste nodene i Optimizelys innholds-API, og bestem hvilke sider som skal inkluderes og hvilke som ikke skal det.
3. Opprett tjenester: a) Hent ressurser, b) hent gammelt innhold
4. Importer alle bilder og filer (innholds-API-et inkluderte unike ID-er som koblet media med objekter)

Innholdsmodell

I stedet for å opprette en ny blokk for hver nye retningslinje eller redaksjonelle behov, kan DiBK nå ha én blokk med flere redigeringsmuligheter. For DiBK gir Enonics konsepter om makroer og parts større fleksibilitet til å bygge sider slik de ønsker med forskjellige elementer, i stedet for å jobbe i en fast mal. Migreringen gjorde det dermed mulig for DiBK å redusere antall maler med halvparten.

I tillegg til å ha mange innholdstyper, ble innholdstreet grunnere – spesielt når det gjelder TEK17-innhold. Nå er det lettere for redaktører å sette inn nytt innhold.

Ved import mente 99x at det var unødvendig å ha separate innholdstyper på laveste nivå av retningslinjer – som avsnitt og klausul. Disse ble derfor kombinert i den endelige innholdsstrukturen.

Alt som ble importert fra innholds-API-et ble lagret i et x-data-felt, som ID og ID-er for underobjekter. Disse dataene ble brukt til å slå sammen innholdselementer i den første importen.

Innholdstyper

En av de vanligste innholdstypene for DiBK er «veileder», som spesifiserer forskrifter, råd og prosesser for byggeprosjekter.

En av de vanligste innholdstypene for DiBK er "veileder," som spesifiserer forskrifter, råd og prosesser for byggeprosjekter.

Innholdstypen "veileder" har flere felt, hvorav et er "item set" for å lage én til flere veiledningstekster. Disse kan deretter settes inn i hovedfeltet. Dette skjer via en makro som lister opp veiledningstekstene som er opprettet inne i den spesifikke veiledningen.

Innholdstypen "best bet" er en del av en søkefunksjonalitet som måtte gjenskapes i Enonic. Her gis visse nøkkelord prioritet og fremmes i nettstedets søkefunksjon. For eksempel er "best bet" satt opp til alltid å prioritere innhold fra TEK17-standarden i søkeforespørsler.

Innholdstypen "høringer" kombinerer visning i front-end med lenking til eksterne nettsteder for å kunne svare på en høring.

“Smartere oppussing” er en tjeneste med informasjon om oppussing. I denne innholdstypen kan DiBK fastslå koordinater hvor komponenter skal plasseres på et hus i front-end.

Komponenter

En sentral komponent på det nye DiBK-nettstedet er en integrasjon med service-deskløsningen Pureservice. Redaktører kan opprette skjemaer i Pureservice gjennom deres avanserte skjemadefinisjoner, mens et API publiserer spesifikasjonene til skjemaene.

Utforming og logikk kommer fra Pureservices egen skjemabygger, der kundeservice setter opp logikk og flyt. I Enonic kan redaktørene berike skjemaet før det gjengis i front-end.

Høringer fra Hoering.no er integrert gjennom et API fra Utdanningsdirektoratet (UDIR). Når en DiBK-redaktør oppretter en høring, er det en flyt i Enonic der man kan se status, svar osv. i frontend. Denne komponenten er også brukt andre steder.

«Boligdugnaden» er en søketjeneste for boliger til flyktninger. Den ble raskt opprettet av 99x, og suksessen ble til og med nevnt av mainstream media.

Admin-verktøy og widgets

DiBK har benyttet seg av appen Nynorskoversetteren fra 99x. I Norge er det et krav om at offentlige nettsteder må ha minst 25 % av språket på nynorsk, noe denne appen gjorde enklere.

Appen og widgeten drives av Totaltekst gjennom et API, og kan oversette manuelt eller automatisk direkte i Content Studio. Redaktører kan oversette en innholdsnode, inkludert tekst brukt i layouter og deler med ett klikk.