Gutenberg uten kaos: Bygg en trygg publiseringsflyt for bedriften

Kategori: WordPress og publisering

Gutenberg gjør det mulig å bygge og redigere sider uten å involvere en utvikler i hver eneste endring. Den friheten er nyttig, men kan også føre til ujevne sider, tilfeldige designvalg og tungvinte publiseringsprosesser.

Løsningen er ikke å fjerne all fleksibilitet. Bedriften trenger en publiseringsmodell som avklarer hva redaktørene kan endre, hvilke byggeklosser de skal bruke, og hvilke endringer som må kvalitetssikres før publisering.

En god Gutenberg-løsning handler derfor like mye om arbeidsflyt og ansvar som om blokker og maler.

Start med å definere graden av frihet

Ikke alle sider bør kunne redigeres på samme måte. En viktig tjenesteside trenger ofte strammere kontroll enn en enkel nyhetsartikkel. Kampanjesider kan kreve større fleksibilitet, men også grundigere kontroll før publisering.

Del gjerne sidene inn i tre nivåer:

• Faste sider: Sider med stabil struktur, som kontakt, personvern og sentrale tjenestesider. Her bør oppsettet i stor grad være låst, mens redaktøren kan endre tekst, bilder og enkelte handlingsknapper.
• Strukturerte redaksjonelle sider: Artikler, kundehistorier og faginnhold som følger en definert mal, men hvor redaktøren kan velge mellom godkjente innholdsblokker.
• Fleksible sider: Kampanjer og landingssider som trenger større variasjon. Disse bør bygges med ferdige mønstre og ha en tydelig godkjenningsprosess.

Denne inndelingen reduserer risikoen for at en liten tekstendring utvikler seg til en uplanlagt redesign. Den gjør det også enklere å avgjøre hvilke endringer redaksjonen kan håndtere selv.

Lag en blokkpolicy før dere lager flere sider

WordPress tilbyr mange blokker, og tillegg kan legge til enda flere. Det betyr ikke at alle bør være tilgjengelige. Et stort og uoversiktlig blokkvalg gjør det vanskeligere å arbeide konsekvent.

Lag en enkel blokkpolicy som beskriver:

• hvilke blokker som er godkjent
• hva hver blokk skal brukes til
• hvilke varianter og stiler som er tillatt
• hvilke blokker som ikke skal brukes
• hvem som kan bestille eller godkjenne nye blokker

En vanlig redaktør trenger sjelden tilgang til alle tekniske og visuelle alternativer. Fjern eller skjul funksjoner som ikke inngår i nettstedets faktiske publiseringsbehov. Færre valg gir som regel raskere arbeid og færre feil.

Begrens også frie valg av farger, skriftstørrelser og avstander. Redaktøren bør kunne velge mellom gjennomtenkte alternativer, ikke konstruere nye uttrykk på hver side.

Bruk mønstre til gjentakende innhold

Blokkmønstre er ferdige kombinasjoner av blokker. De kan for eksempel inneholde en overskrift, en kort introduksjon, et bilde og en handlingsknapp. Redaktøren setter inn mønsteret og erstatter eksempelinnholdet.

Gode mønstre passer til oppgaver bedriften utfører ofte:

• presentasjon av en tjeneste
• kundeeksempel med resultat og kontaktpunkt
• ansattprofil
• spørsmål og svar
• kontaktseksjon
• relaterte artikler eller tjenester

Ikke lag et mønster for enhver tenkelig kombinasjon. Start med de gjentakende behovene som allerede er synlige i innholdet. Hvis redaktørene stadig kopierer en seksjon fra en gammel side, er det ofte et tegn på at dere trenger et definert mønster.

Skill mellom kopier og sentralt innhold

Et vanlig mønster gir redaktøren en kopi som kan tilpasses på den enkelte siden. Et synkronisert mønster brukes når samme innhold skal vedlikeholdes sentralt og oppdateres flere steder.

Dette skillet er viktig. En generell kontaktseksjon kan egne seg for sentral oppdatering, mens en introduksjon til en bestemt tjeneste normalt bør kunne redigeres lokalt. Hvis for mye innhold synkroniseres, kan én endring få uventede konsekvenser på mange sider.

Lås det som ikke skal flyttes

Blokklåsing kan hindre at viktige elementer slettes eller flyttes. Det er særlig nyttig i maler der rekkefølgen har betydning for forståelse, konvertering eller visuell sammenheng.

En tjenesteside kan for eksempel ha en fast struktur med introduksjon, kundebehov, leveranse, dokumentasjon og neste steg. Redaktøren bør kunne oppdatere innholdet uten å fjerne sentrale deler ved et uhell.

Låsing bør likevel brukes med omtanke. Hvis alt er låst, ender redaktørene med å be om hjelp til små endringer. Målet er å beskytte strukturen, ikke å gjøre nettstedet upraktisk å vedlikeholde.

Fordel ansvar etter type endring

Tradisjonelle WordPress-roller er et utgangspunkt, men de sier ikke alene hvordan bedriften skal arbeide. Lag derfor en praktisk ansvarsfordeling basert på hva som faktisk endres.

• Fagansvarlig: Kontrollerer at innholdet er korrekt, oppdatert og i tråd med bedriftens leveranse.
• Redaktør: Bearbeider språk, struktur, bilder, metadata og interne koblinger mellom innhold.
• Design- eller merkevareansvarlig: Godkjenner nye visuelle mønstre og større avvik fra etablerte maler.
• Teknisk ansvarlig: Håndterer nye blokktyper, integrasjoner, malendringer og funksjonalitet som kan påvirke drift eller ytelse.

En tekstendring skal ikke trenge samme prosess som en ny sidemal. Ved å klassifisere endringer unngår dere både unødvendig byråkrati og risikofylt direktepublisering.

Bruk en fast flyt fra utkast til publisering

En enkel publiseringsflyt kan bestå av fem trinn:

1. Avklar formålet. Definer målgruppe, ønsket handling og hvem som eier innholdet etter publisering.
2. Velg riktig mal. Bruk eksisterende sidetype og godkjente mønstre før dere vurderer nye løsninger.
3. Kontroller innholdet. Sjekk overskriftsstruktur, språk, bilder, handlingsknapper og hvordan siden fungerer på liten skjerm.
4. Godkjenn etter risiko. Vanlige artikler kan følge en enkel redaksjonell kontroll. Nye maler og tekniske funksjoner bør testes utenfor det publiserte nettstedet.
5. Følg opp. Kontroller den publiserte siden, og avtal hvem som skal oppdatere eller avpublisere innholdet senere.

Forhåndsvisning er nyttig, men bør ikke være eneste kontroll. Redigeringsvisningen og den publiserte siden kan oppføre seg forskjellig, særlig når nettstedet bruker egendefinerte blokker, skjemaer eller dynamisk innhold.

Gjør ytelse til en del av redaktørjobben

God teknisk ytelse kan svekkes av redaksjonelle valg. Store bilder, mange innbyggede medier, unødvendige seksjoner og tredjepartsfunksjoner kan gjøre en ellers godt bygget side treg.

Gi redaktørene konkrete regler:

• last opp bilder i passende størrelse og format
• unngå video som starter automatisk
• bruk innbygging bare når det gir tydelig verdi
• ikke kopier komplekse blokkoppsett mellom tilfeldige sider
• vurder om lange sider bør forenkles eller deles opp

Det er heller ikke gitt at en blokk er lett bare fordi den finnes i redigeringsverktøyet. Egendefinerte blokker og tillegg kan laste inn skript, stilark eller eksternt innhold. Nye blokktyper bør derfor vurderes teknisk før de blir en del av standardverktøyet.

Vedlikehold selve publiseringssystemet

Gutenberg-oppsettet må forvaltes etter lansering. Maler, mønstre og blokker som var riktige ved oppstart, kan bli utdaterte når tjenester, organisasjon eller merkevare endres.

Legg inn en regelmessig gjennomgang av:

• blokker som ikke lenger brukes
• mønstre med gammelt innhold eller utdatert design
• sider som bryter med gjeldende mal
• tillegg som overlapper med funksjoner dere allerede har
• redaktørtilganger og publiseringsansvar
• feil og advarsler som oppstår etter oppdateringer

Når WordPress, temaet eller tillegg skal oppdateres, bør sentrale sidetyper testes. Kontroller ikke bare forsiden. Se også på artikler, tjenestesider, skjemaer og sider med spesielle blokker.

En praktisk start for bedriften

Dere trenger ikke bygge om hele nettstedet for å få kontroll. Begynn med et representativt utvalg sider og noter hvilke blokker, mønstre og spesialløsninger som faktisk brukes.

Velg deretter noen få standarder:

1. Definer de viktigste sidetypene.
2. Begrens blokkene til et relevant utvalg.
3. Lag mønstre for de vanligste innholdsseksjonene.
4. Lås strukturer der feil kan få store konsekvenser.
5. Dokumenter hvem som kan endre innhold, design og funksjonalitet.
6. Innfør en kort kontrolliste før publisering.

Den beste Gutenberg-løsningen er ikke den som gir flest muligheter. Det er den som lar redaktørene løse vanlige oppgaver raskt, samtidig som nettstedets struktur, uttrykk og tekniske kvalitet blir bevart.