Slik bygger dere en trygg publiseringsflyt i WordPress

Kategori: WordPress og innholdsforvaltning

Når flere ansatte arbeider i WordPress, er det sjelden selve publiseringsknappen som skaper problemer. Utfordringen er å vite hvem som kan endre hva, hvordan endringer skal kontrolleres, og hvor arbeidet skal foregå. Uten en avtalt publiseringsflyt kan uferdige sider bli synlige, gamle budskap bli liggende og tekniske endringer kollidere med redaksjonelt arbeid.

En god arbeidsflyt trenger ikke være tung. Den skal gjøre det lett å utføre vanlige oppgaver riktig, samtidig som større endringer får den kontrollen de krever. Her er en praktisk modell som kan tilpasses både små markedsavdelinger og større organisasjoner.

Skill mellom redaksjonelle og tekniske endringer

Det første grepet er å skille tydelig mellom innhold som redaktører skal håndtere, og endringer som krever utvikling eller teknisk kvalitetssikring.

Redaksjonelle endringer kan typisk være:

• oppdatering av tekst, kontaktinformasjon og åpningstider
• bytte av bilder innenfor etablerte formater
• publisering av artikler og arrangementer
• justering av lenker og handlingsknapper
• oppretting av sider etter godkjente mønstre

Tekniske eller strukturelle endringer kan være:

• nye sidemaler og blokkvarianter
• endringer i navigasjon eller informasjonsstruktur
• nye skjemaer og integrasjoner
• endringer i sporing, samtykke eller databehandling
• installasjon og konfigurasjon av utvidelser
• større visuelle endringer som påvirker mange sider

Dette skillet avgjør både hvem som skal gjøre jobben, og hvor endringen skal testes. En tekstjustering kan ofte gjøres direkte som kladd i produksjonsmiljøet. En ny mal bør normalt bygges og kontrolleres i et separat testmiljø før den settes i drift.

Gi roller etter oppgave, ikke stillingstittel

Tilganger bør følge faktiske arbeidsoppgaver. En leder trenger ikke administratorrettigheter bare fordi vedkommende har det overordnede ansvaret for nettstedet. Tilsvarende kan en innholdsansvarlig ha behov for å publisere sider uten å kunne installere utvidelser eller endre tekniske innstillinger.

Definer minst disse ansvarsområdene:

• Innholdsprodusent: skriver og redigerer innhold, men sender det til kontroll før publisering.
• Redaktør: kvalitetssikrer, prioriterer og publiserer redaksjonelle endringer.
• Nettstedseier: bestemmer mål, innholdsansvar og overordnede prioriteringer.
• Teknisk ansvarlig: håndterer kode, utvidelser, maler, integrasjoner og drift.

I små bedrifter kan én person ha flere av rollene. Poenget er likevel å avklare hvilken hatt personen har på seg i hver oppgave. Det reduserer risikoen for at tekniske valg tas som en rask del av vanlig innholdsarbeid.

Bruk Gutenberg som ramme, ikke som blankt lerret

Gutenberg gir redaktører stor frihet. Ubegrenset frihet fører imidlertid ofte til sider med ulike avstander, tilfeldige farger og varierende oppbygning. En publiseringsflyt fungerer best når redaktøren kan velge mellom et begrenset sett med gode løsninger.

Lag mønstre for tilbakevendende innhold, for eksempel:

• toppseksjon med overskrift, ingress og handlingsknapp
• presentasjon av tjeneste med fordeler og neste steg
• kontaktseksjon med riktig kontaktperson
• kundehistorie med sitat, resultat og tilhørende tjeneste
• faktaboks eller praktisk informasjon

Mønstrene bør bruke definerte typografier, farger og avstander. Blokker som ikke har en reell redaksjonell funksjon, kan skjules eller begrenses. På sentrale sidetyper kan dere låse strukturen slik at innhold kan redigeres uten at selve oppbygningen blir ødelagt.

Målet er ikke å fjerne fleksibilitet, men å flytte viktige designvalg fra hver enkelt publisering til et kontrollert system.

Innfør en enkel flyt fra bestilling til publisering

En konkret publiseringsflyt kan bestå av seks trinn:

1. Bestill endringen. Beskriv hvilken side som skal endres, hvem innholdet er for, hva brukeren skal gjøre, og hvem som godkjenner.
2. Lag innholdet som kladd. Bruk riktig sidetype eller mønster. Unngå å bygge en ny variant dersom en eksisterende løsning dekker behovet.
3. Utfør egenkontroll. Kontroller overskrift, språk, lenker, bilder, mobilvisning og tydelig neste steg.
4. Send til faglig godkjenning. Den som eier budskapet, kontrollerer fakta, priser, vilkår og eventuelle frister.
5. Gjør redaksjonell sluttkontroll. Redaktøren vurderer helheten, finner siden i navigasjonen og kontrollerer hvordan den fremstår for besøkende.
6. Publiser og etterkontroller. Åpne den publiserte siden i et vanlig nettleservindu og test de viktigste handlingene.

For små tekstendringer kan flere trinn utføres av samme person. Nye landingssider, juridisk innhold og kampanjer bør få en tydeligere godkjenning. Kontrollnivået skal stå i forhold til konsekvensen av feil.

Avklar hva som skal gjøres i produksjon og testmiljø

Et testmiljø er nyttig, men det bør ikke bli et parallelt nettsted der redaksjonen publiserer innhold over lang tid. Når både testmiljøet og produksjonsmiljøet inneholder nyere endringer, blir det vanskelig å vite hvilken versjon som er riktig.

Bruk normalt produksjonsmiljøet som hovedkilde for løpende innhold. Kladd, forhåndsvisning og planlagt publisering kan håndtere mye av det daglige arbeidet der.

Bruk testmiljøet til endringer som påvirker funksjon, utforming eller flere sider samtidig. Det kan være en ny innholdstype, en justert toppmeny eller en ny skjemaløsning. Før lansering må dere avklare hvordan endringen flyttes uten å overskrive bestillinger, skjemainnsendinger eller innhold som er publisert i mellomtiden.

Unngå å kopiere hele testdatabasen over produksjon som en rutinemessig måte å lansere en liten designendring på. Flytt heller de nødvendige tekniske endringene kontrollert, og opprett redaksjonelt innhold i riktig miljø.

Gjør forhåndsvisning til en reell kontroll

Forhåndsvisning er mer enn å lese korrektur. Siden må vurderes slik en besøkende møter den.

Kontroller blant annet:

• om hovedbudskapet er forståelig uten intern forkunnskap
• om overskriftsnivåene gir en logisk struktur
• om knapper og tekstlenker beskriver hva som skjer
• om viktige elementer fungerer på smal skjerm
• om bilder er relevante, beskåret riktig og har nødvendig alternativ tekst
• om skjemaer kan sendes inn og mottas av riktig person
• om siden har riktig tittel og beskrivelse for søkeresultater
• om informasjonen er plassert på riktig side, i stedet for å duplisere eksisterende innhold

Sett gjerne et fast tidspunkt for redaksjonell kontroll av større publiseringer. Da slipper godkjenneren å bli kontaktet tilfeldig gjennom dagen, og innholdsprodusenten vet når tilbakemeldingen kommer.

Behandle planlagt publisering som en avtale

Planlagt publisering er nyttig for kampanjer, stillingsannonser og tidsstyrte kunngjøringer. Funksjonen bør likevel inngå i en tydelig rutine.

Før en side planlegges, bør innholdet være ferdig godkjent. Noter hvem som følger opp etter publisering, og hva som skal skje når informasjonen ikke lenger er aktuell. En kampanjeside trenger ofte både publiseringsdato, sluttdato og en plan for videresending eller arkivering.

Kontroller også at nettstedets tidssone er riktig satt. Feil tidssone kan føre til at tidskritisk innhold publiseres tidligere eller senere enn forventet.

Planlegg endring, arkivering og sletting

Publiseringsflyten slutter ikke når siden blir synlig. Alt innhold bør ha en eier og et forventet tidspunkt for ny vurdering. Dette er særlig viktig for priser, medarbeiderprofiler, produktinformasjon, arrangementer og beskrivelser av tjenester som endres ofte.

Definer hva som skal skje når innhold tas ut:

• Oppdater siden dersom behovet fortsatt finnes.
• Arkiver innhold som skal være tilgjengelig, men ikke fremheves.
• Slå sammen sider som dekker samme behov.
• Send besøkende videre til et relevant alternativ når en side fjernes.
• Slett bare når innholdet faktisk er uten verdi og konsekvensene er vurdert.

En enkel innholdsoversikt med sideeier, dato for siste kontroll og neste vurdering er ofte tilstrekkelig. Den kan ligge utenfor WordPress dersom organisasjonen allerede har et egnet arbeidsverktøy.

Bruk revisjoner med en tydelig begrensning

WordPress lagrer revisjoner av innhold og kan gjøre det mulig å hente tilbake en tidligere tekstversjon. Det er nyttig ved feilredigering, men revisjoner erstatter ikke sikkerhetskopi eller en teknisk plan for tilbakeføring.

Hvis en publisering endrer maler, utvidelser eller data på tvers av nettstedet, må den tekniske ansvarlige ha en egen plan. Redaksjonelle revisjoner hjelper først og fremst med innholdet i den enkelte siden.

Ved store omskrivinger kan det være klokt å dokumentere formålet med endringen i oppgaven som ligger bak publiseringen. Da er det lettere å forstå hvorfor teksten ble endret, ikke bare hvilke ord som var annerledes.

Start med fire konkrete beslutninger

Bedrifter som vil forbedre publiseringsarbeidet, kan begynne uten et omfattende prosjekt. Ta først stilling til disse spørsmålene:

1. Hvem kan opprette, godkjenne og publisere innhold?
2. Hvilke Gutenberg-mønstre og blokker skal redaksjonen bruke?
3. Hvilke endringer kan gjøres i produksjon, og hvilke krever testmiljø?
4. Hvem eier innholdet etter at det er publisert?

Skriv svarene i en kort redaksjonell veiledning og bruk dem i opplæringen av nye bidragsytere. Revider veiledningen når nettstedet, organisasjonen eller arbeidsfordelingen endres.

En trygg publiseringsflyt handler ikke om å legge flest mulig godkjenninger mellom idé og publisering. Den handler om å gi riktig person nok handlingsrom, samtidig som konsekvensrike endringer blir kontrollert. Når roller, miljøer og kvalitetskrav er avklart, blir WordPress enklere å forvalte og mindre avhengig av enkeltpersoners hukommelse.