Synlighed — De seks audits jeg altid kører på Optimizely-opgaver

Hver eneste Optimizely-installation, jeg har arbejdet med, der har kørt i nogle år, har mindst én indholdstype med et navn i stil med TeaserBlockRightImageNEW2. Navnet siger allerede sit. En kampagne havde brug for noget en smule anderledes, en udvikler vidste ikke, at der allerede fandtes en type, der ville have fungeret, og den nemmeste vej var at lave en ny. Gør det i fem år med et par platformsopgraderinger imellem, og opret-indhold-dialogen ender som en mur af valgmuligheder, ingen helt stoler på.

Bag navnene er mønstret altid det samme. Ti-tyve blokke og to-tre sidetyper laver halvfems procent af arbejdet. Derefter en lang hale på tres, hundrede, nogle gange halvandet hundrede flere — brugt én gang, brugt to gange, eller bare bevaret fordi ingen tør slette dem af frygt for, at noget stadig afhænger af dem. Redaktørerne lever med det hele.

Det fortsætter, ikke fordi nogen er dovne, men fordi dem, der kunne rydde op, ikke kan se billedet klart nok til at handle. Udviklerne ser exceptions i logfiler og tickets i deres kø. Redaktørerne mærker en daglig friktion, der ikke dukker op nogen af de steder. Audit-værktøjerne i Editor Power Tools findes for at lukke det hul — seks perspektiver på den slags CMS-ophobning, der ellers ikke kan måles.

Content Type Audit — begge sider af sagen

Den første audit, og den jeg kører på dag ét af enhver opgave, er Content Type Audit. Den gennemgår hele CMS’et, lister hver enkelt indholdstype og fortæller jer, hvem der bruger den, og hvordan. Tallene øverst sætter rammen i sig selv: hvor mange rigtige indholdstyper kontra systemtyper, hvor mange der helt har mistet deres .NET-klasse (Code-less-tallet — typer hvor koden blev udgivet, udgivet igen, og så refaktoreret væk to opgraderinger siden uden at typedefinitionen blev fjernet), og hvor mange der ikke bruges af noget indhold.

Allerede inden I klikker ind i en enkelt række, fortæller summerne en historie. Et lille, velholdt site har typisk mellem tredive og halvtreds reelle indholdstyper. Et rigtigt enterprise-site, der har levet i nogle år, ligger som regel på over firs. Når man kommer over halvandet hundrede, er spørgsmålet ikke længere, om der er gæld i indholdsmodellen — det er hvor meget, og hvor. Tallet alene er ikke en dom, for nogle sites har reelt brug for mange typer, men kombineret med navnene bliver det det som regel. Når I scroller ned og ser Old, NEW, NEW2, V2, Final, Temp eller forkortelser, som kun den udvikler, der stoppede i 2022, kunne tyde, har auditten allerede fortalt jer det meste — før I overhovedet har klikket på en række.

Men det rigtigt brugbare arbejde ligger i rækkerne. Hver type har et brugstal, og et klik åbner en oversigt over de konkrete indholdselementer, der findes af typen, med antal referencer for hver. Det er i den oversigt, audittens andet job lever.

Her er pointen. Første gang man kører det her på et site, der har levet i nogle år, kommer de oplagte fund først: typer ingen bruger længere, typer hvor .NET-klassen er væk, typer I ikke vidste stadig fandtes. Nyttigt, tilfredsstillende, alt det der. Det mere overraskende fund ligger ét lag dybere. En indholdstype, der bruges på ti eller tolv blokke, hvor flere af blokkene selv ikke er refereret fra nogen side. De ligger i databasen, men er væk fra det egentlige site. Kaskaderende forældreløse. Det er reference-kolonnen ovenfor, der gør dem synlige — og på en rigtig opgave finder man indimellem en hel type, hvor alle forekomster er i den tilstand.

Det er den del, der finder problemerne. Den anden del dukker op, når man ikke rydder op, men planlægger.

Når en designer siger “vi vil ændre, hvordan denne teaser-blok ser ud over hele sitet”, er det de egentlig spørger om: hvor lander den ændring? På tolv sider, eller tolv hundrede? Koncentreret i én sektion, eller spredt over det hele? I kan grep’e gennem koden, sådan cirka, men det I egentlig vil have, er et kort over brugen på tværs af det publicerede indhold. Det er den samme drill-down-visning, der er det kort. Samme audit, andet spørgsmål.

Auditten beslutter ikke, hvad I skal gøre. Den lader jer bare holde op med at gætte på, hvor stor flade I rører ved.

To spørgsmål, jeres CMS ikke svarer på selv

Det er mønstret, og det gentager sig. Hver audit i familien udfører ét eller begge af to job:

• Hvad er stille og roligt i stykker? Ting der fungerer godt nok til, at intet kaster en exception, men koster redaktørerne tid eller tillid hver dag. Forældreløse indholdselementer. Forældede tilstande. Tilladelser ingen kan huske at have ændret. Oversættelser der er sakket bagud.
• Hvad kommer denne ændring til at røre ved? Konsekvensradiussen, før I handler. Hvor en blok bruges. Hvilke sider en besøgsgruppe personaliserer. Hvilket indhold der hænger på en sprogdefinition, I er ved at ændre.

CMS’et giver jer ikke nogen af delene som standard. Ikke fordi dataene mangler — de ligger der hele tiden. Problemet er, at ingen har bygget den læsbare oversigt, fordi dem der har mest brug for den, ikke selv kan bygge den. Auditterne er den læsbare oversigt.

Personalization — besøgsgrupperne og hvad de faktisk rører ved

Personalization Audit er det dobbelte perspektiv i sin reneste form. Felterne øverst fortæller jer det samlede antal besøgsgruppe-anvendelser på sitet, hvor mange forskellige grupper der reelt er i brug, og hvor anvendelserne ligger: indholdselementer, adgangsrettigheder, content areas, XHTML-strenge. På et rigtigt site er forskellen mellem besøgsgrupper defineret i admin og besøgsgrupper faktisk brugt et sted som regel den første overraskelse.

Oprydningsdelen er ligetil: forældreløse besøgsgrupper, defineret for år tilbage, koblet til ingenting. De ligger der bare.

Konsekvensradius-delen er den, der ændrer, hvordan teams arbejder. Når nogen vil ændre en besøgsgruppe-definition (stramme kriterierne, pensionere den, migrere den til en ny segmenteringsmodel), er det umiddelbare spørgsmål: hvad gør den her lige nu? Filtrér på gruppen, og auditten viser jer hver side, hver adgangsregel, hvert content area, hver XHTML-stump, der er personaliseret på den. Med den liste i hånden bliver det at ændre gruppen en planlagt handling i stedet for en tilbageholdt vejrtrækning.

Language — hvad I faktisk har, og hvad der er forældet

Language Audits rolle afhænger af sitet. På et site med kun ét sprog fortæller den meget lidt. På et site med fem, otte eller tolv sprog er det sådan, I holder redaktørerne ærlige over for hinanden.

To spørgsmål, den svarer på, som CMS’et ikke viser noget andet sted. For det første: hvor meget indhold har I faktisk på hvert sprog? Ofte mindre, end organisationsdiagrammet antyder. Det tyske site, der “findes”, viser sig at have tre sider oversat, mens resten falder tilbage til engelsk. Det norske indhold var opdateret for atten måneder siden og er ikke blevet rørt siden.

For det andet, og mere brugbart: hvilke sider er sakket bagud? Når den engelske kilde opdateres, og oversættelserne ikke gør, er den forskel usynlig, indtil nogen rapporterer det — som regel en kunde, og som regel vredt. Auditten gør forældelsen synlig, før kunden gør det.

Security — de tilladelser nogen ændrede og glemte

Næsten ethvert site, der har kørt i nogle år, har mindst én adgangsgrænse, ingen kan huske at have sat. En side hvor Everyone blev fjernet på grund af én hændelse og aldrig genindført. En folder hvor en kollega gav adgang til nogen, der stoppede for to år siden. Et content area hvor brugerdefinerede tilladelser overstyrer forælderens, og ingen kan huske hvorfor.

Security Audit er den oversigt, I har brug for, før I kan beslutte, hvad der er bevidst, og hvad der er rester. Filtrér på rolle, på indholdselement eller på tilladelsestype, og auditten fortæller jer præcist, hvor hver adgangsbeslutning ligger. De interessante fund er næsten altid dem, I ikke ledte efter: adgangen sat som workaround for en bug, der blev rettet for atten måneder siden; rollen stadig afgrænset til en sektion, der ikke længere findes; den brugerdefinerede tilladelse anvendt under en launch og aldrig ryddet op efter.

For redaktørerne er det den audit, der løser “hvorfor kan jeg ikke redigere denne side?”-tickets uden at involvere en udvikler.

Content — oversigten I kan tage med i Excel

Content Audit gør for indholdselementer det samme, som Content Type Audit gør for typer: en fuld oversigt med filtre på status, sprog, sidst-ændret og antal referencer. I sig selv er det nyttigt. Publiceret-men-urefereret indhold dukker op hurtigt, sproghuller bliver synlige på elementniveau, og de elementer, der spiser plads i søgeresultaterne uden at være linket til fra nogen steder, kan endelig findes.

Det er dog ikke browse-visningen, der giver auditten det meste af dens reelle brug. Det er eksporten.

Hver audit i familien har en eksport-knap, men Content er der, hvor det holder op med at føles som en udvikler-feature og begynder at føles som et værktøj til content strategy. Når oversigten først ligger i et regneark, kan de mennesker, der reelt kan lave noget nyttigt med den (content leads, marketing-ansvarlige, redaktionelle planlæggere), filtrere den, lave pivottabeller på den, dele den og møde op til mødet med deres egen filtrerede liste. Audittens job inde i CMS’et er at gøre dataene læsbare. Eksportens job er at flytte den læsbarhed derhen, hvor samtalerne faktisk foregår.

Mange redaktionelle beslutninger holder op med at være abstrakte, så snart de ligger på et ark. Hvilke sektioner har forældet indhold. Hvilke forfattere har ikke publiceret i et år. Hvilke sprog trækker dækningen ned. Hvilke indholdstyper bliver nostalgisk bevaret, men aldrig brugt til noget. Intet af det er ny information — det lå hele tiden i CMS’et. Auditten og eksporten er det, der gør det muligt at tale om det.

Link — auditten over ødelagte ting, ingen får tjekket i tide

Link Audit gennemgår interne og eksterne links på hele sitet og rapporterer, hvad der er brudt eller redirecter. Redaktørerne ved som regel godt, at de har døde links; auditten fortæller dem hvor mange, hvor, og hvilken vej det udvikler sig. Det er den audit, der oftest bliver kørt to gange om året, omkring kvartaler med oprydning, og det er fint — det er den slags værktøj, og værdien er at have det klar, når I endelig beslutter jer for at kigge.

Hvad I gør med fundene

Audit-familiens to halvdele har forskellige næste skridt.

For den halvdel, der finder problemerne, er auditten oversigten; oprydningen er arbejdet. Bulk-redigering, masseopdatering af properties, indholdsmigrering, pensionering af typer — det er emnet for det næste indlæg i serien. Synlighed alene løser ingenting; den gør bare det rette arbejde synligt.

For den halvdel, der viser konsekvensradiussen, er næste skridt som regel en samtale. Designer vil ændre en blok? Træk brugslisten. Marketing vil pensionere en besøgsgruppe? Træk personaliseringslisten. Jura vil vide, hvilke foldere der har adgangsbegrænsninger? Træk tilladelseslisten. Auditten ændrer ikke beslutningen; den ændrer, om beslutningen er truffet på et oplyst grundlag.

Seks audits, to spørgsmål. Kør dem på et site, der har levet i mere end to år, og første kørsel er altid en smule ubehagelig. Pointen er anden kørsel, et halvt år senere, når der er mindre at finde.

Prøv dem

Audit-værktøjerne følger med Editor Power Tools, den open source-add-on til Optimizely CMS 12 og 13, jeg skrev om i lanceringsindlægget. MIT-licens, én NuGet-pakke, der understøtter begge CMS-hovedversioner samtidig. Installér, registrér middleware, og audit-familien står i menuen — uden ekstra konfiguration.

Hvis I har arbejdet med et Optimizely-site længe nok til at have en mening om, hvilken af disse audits I først ville bruge, hører jeg den oprigtigt gerne — åbn en issue eller en PR. Og hvis jeres CMS er nået det punkt, hvor listen her virker mere skræmmende end interessant, så er Optimizely det, vi laver, og en opgraderingsopgave starter som regel netop her: med et klart billede af, hvad der faktisk er i jeres CMS.