Sådan gør du dine web-redaktører markant mere produktive
Artikel

Sådan gør du dine web-redaktører markant mere produktive

Redaktionelt arbejde kommer i bunker — et produktnavn der skal skiftes på to hundrede supportartikler, fem hundrede FAQ'er der skal blive til blokke, et SEO-eftersyn af en hel sektion. Produktivitetsværktøjerne i Editor Power Tools findes præcis til det: masseredigering, masseimport og de overblik der holder et sites daglige rytme synlig.

Før eller siden skifter enhver organisation navn på noget. Et produkt, en forretningslinje, en sjælden gang hele virksomheden. Marketing sender mailen ud, det nye navn gælder fra mandag, og et sted nede i kæden arver en redaktør den del, ingen havde sat på en slide: det gamle navn står i titlen på hver eneste supportartikel, og der er to hundrede af dem.

CMS’et har teknisk set et svar. Åbn siden, ret titlen, publicér. Gentag. Optimizelys redigeringsvisning er faktisk god til netop dén ene side — egenskaberne er fornuftigt sat op, der er validering, versionering, det hele. Problemet er, at ingen har afgrænset arbejdet som “én side”. Arbejdet er en bunke. Værktøjet er en løkke.

Jeg sluttede audit-indlægget af med at sige, at auditten er oversigten, og oprydningen er arbejdet. Dette indlæg handler om arbejdet: produktivitetsværktøjerne i Editor Power Tools — masseredigering, masseimport og de to overblik, der holder et sites daglige rytme synlig.

Skatten på at gøre tingene ét ad gangen

Når man først begynder at lede efter arbejde i bunkeformat, er det overalt. Produktnavneskiftet ovenfor. SEO-nøgleord der skal opdateres på de sider, I rent faktisk satser på i dette kvartal, fordi dem der står der nu, afspejler det, I satsede på for to år siden. Sæsonindhold der skal masse-publiceres. Den lange hale af elementer, som en audit lige har afsløret, der skal pensioneres.

CMS’et redigerer ét element ad gangen. Arbejdet kommer næsten aldrig på den måde.

I virkelige teams ender det på en af to måder, og begge er dårlige. Enten bliver arbejdet udskudt — sådan vokser indholdsgælden — eller det bliver givet videre til en udvikler, som skriver et engangs-script mod content-API’et. Jeg har skrevet en masse af den slags scripts. De virker. De er også engangskode med publicerings-bivirkninger, skrevet af den person der står længst fra indholdet, reviewet af ingen, og kørt præcis én gang i produktion. Det er ikke en proces; det er et væddemål.

Bulk Property Editor — masseredigering uden scriptet

Bulk Property Editor med hundredvis af indholdselementer i et filtrerbart gitter, celler med egenskaber der kan redigeres inline, og en værktøjslinje til at gemme og publicere i bulk.

Bulk Property Editor er den regnearksvisning, CMS’et aldrig fik. Filtrér ned til præcis det indhold, I mener, se egenskaberne som et gitter, ret cellerne inline, og gem eller publicér så hele bundtet i én operation. Sortering og paginering holder det brugbart, når “hele bundtet” er flere hundrede elementer.

Produktnavneskiftet bliver til: filtrér til supportsektionen, sortér efter titel, ret titlerne, masse-publicér. Nøgleords-opdateringen er samme bevægelse i en anden kolonne. Det, der var en halv dags klikkeri — eller en nervøs eftermiddag med scriptskrivning — er tyve fokuserede minutter, udført af den redaktør, der faktisk forstår indholdet.

Én ting er værd at sige ligeud: en masse-publicering er en rigtig publicering. To hundrede gemte rækker er to hundrede nye versioner live. Gitteret viser jer præcis, hvad I er ved at røre ved, før I trykker — det som faste læsere vil genkende som spørgsmålet om konsekvensradius fra audit-indlægget, besvaret her i det øjeblik, det betyder mest.

Content Importer — når indholdet findes, bare ikke her

Den anden halvdel af bunke-historien handler ikke om at redigere indhold, I har; den handler om at oprette indhold, I har fået udleveret. Supportteamet afleverer fem hundrede FAQ’er, der skal blive til genbrugelige blokke ud over sitet. Eller I konsoliderer platforme, og et helt andet systems blogindlæg skal lande i Optimizely med titler, datoer, forfattere og brødtekst intakt. Ingens jobbeskrivelse siger “copy-paste fem hundrede gange”, men i de fleste teams ender nogen alligevel med at gøre det — eller indholdet kommer simpelthen aldrig ind.

Content Importer fra ende til ende — upload, forhåndsvisning, vælg mål, map kolonner til egenskaber, dry-run, import.

Content Importer tager CSV, Excel eller JSON og gør rækker til indholdselementer. I mapper kildefelter til indholdsegenskaber, forhåndsviser hvad der er ved at blive oprettet, og valideringen fanger de rækker, der ikke overlever mødet med jeres indholdsmodel, før noget som helst bliver skrevet.

Den funktion, jeg vil mene betyder mest, er dry-run. Alle, der har kørt en indholdsmigrering, kender den helt særlige fornemmelse af at trykke på knappen og håbe. Et dry-run er generalprøven: hele importen, kørt fra ende til ende, uden at gemme noget. I læser resultatet, retter mappingen, kører igen. Når den rigtige import endelig kører, er det tredje eller fjerde gang, I ser udfaldet — hvilket er præcis så kedeligt, som en migrering bør være.

Manage Child Items — når bunken er “alt herunder”

Ikke enhver bunke er en filtreret søgning på tværs af hele sitet. Nogle gange er arbejdsenheden én forælder og alle dens børn: en nyhedsforside med to års artikler under sig, et kampagnehub hvis børn alle udløber samme mandag, en produktkategori der skal pensioneres. I behøver ikke at finde de elementer — I ved præcis, hvor de er. I vil handle på dem samlet.

Optimizelys indholdstræ lader jer gøre det én knude ad gangen. Manage Child Items giver jer hele mængden på én gang: alle børn af en side i én liste, vælg dem alle eller bare nogle, og publicér, afpublicér eller slet udvalget i én handling.

Manage Child Items — alle børn af en side i én liste, med masse-publicering, -afpublicering og -sletning.

Det er samme princip som Bulk Property Editor, bare afgrænset til en forælder i stedet for et filter. Indholdstræet holder op med at være noget, I klikker jer igennem knude for knude, og bliver noget, I opererer på. Og det samme ærlige forbehold gælder: en masse-afpublicering eller -sletning gør præcis, hvad der står, ved alt det I har sat flueben ved — så det er udvælgelsestrinnet, man skal sætte tempoet ned på.

Produktivitet er også at vide, hvad der foregår

Bunker er halvdelen af historien. Den anden halvdel af at holde redaktører produktive er mindre prangende: at vide, hvad der sker på sitet, uden at skulle spørge sig for.

Activity Timeline med et tospaltet feed af redaktionel aktivitet på tværs af sitet, med versionssammenligning og kommentarer.

Activity Timeline er mandag morgen-visningen: en tidslinje over redaktionel aktivitet på tværs af hele sitet — hvem der ændrede hvad, og hvornår — med versionssammenligning og kommentarer hæftet på. På et site med én redaktør er det en lækkerbisken. På et site med et distribueret team er det sådan, I finder ud af, hvad der skete i sidste uge, uden et møde, og sådan I sporer ændringen, når en side pludselig ser forkert ud. Den uendelige scroll betyder, at historikken ikke stopper ved bunden af første skærm, hvilket betyder mere, end man skulle tro.

Scheduled Jobs Gantt dækker det arbejde, sitet udfører af sig selv. Enhver Optimizely-installation kører en stille natlig økonomi af planlagte job — indeksering, linktjek, arkivering, integrationer der trækker data ind. Når et af dem fejler i stilhed, opdager ingen det, før noget længere nede bliver forældet, og en supportsag dukker op i forklædning. Gantt-diagrammet viser kørselshistorikken på en rigtig tidslinje: hvilke job der kørte, hvor lang tid de tog, hvilke der overlapper, og hvornår de næste kørsler er planlagt. “Hvorfor er søgningen forældet?” og “hvad laver serveren klokken tre om natten?” holder op med at være ekspeditioner i logfiler og bliver et diagram, I kan scrolle i.

Scheduled Jobs Gantt-diagram med 28 Optimizely-planlagte job som rækker, hver med sin kørselshistorik tegnet ind på en 48-timers tidslinje. Et job med musen over viser et tooltip med starttid, sluttid, varighed under et sekund og status Success.

Hvad jeg ville ændre ved måden, arbejdet bliver afgrænset på

Hold op med at afgrænse bunkearbejde som side-arbejde. Når opgaven lyder “ret titlerne”, er det første spørgsmål hvor mange. Svaret afgør, om det er en redigeringsopgave eller en værktøjsopgave, og at ramme det forkert er sådan, en halv dag forsvinder.

Lad redaktørerne gøre det færdigt, auditten startede. En oversigt over forældet indhold er kun nyttig, hvis det ikke kræver en udvikler at handle på den. Audits fra forrige indlæg finder arbejdet; masse-værktøjerne er det, der lader dem, der står tættest på indholdet, faktisk udføre det.

Hold generalprøve på enhver import. Hvis et migreringsværktøj ikke har en dry-run, er den første produktionskørsel dit dry-run — I har bare valgt at gøre det med live data.

Næste i serien: CMS Doctor — det udvidbare sundhedstjek-dashboard, hvordan I udvider det, og hvorfor pluggbare tjek er den rette form på problemer, der hober sig op i stilhed.

Prøv det

Produktivitetsværktøjerne følger med Editor Power Tools, den open source-add-on til Optimizely CMS 12 og 13, jeg skrev om i launch-indlægget. MIT-licens, én NuGet-pakke, multi-targeted på tværs af begge CMS-hovedversioner. Installér den, registrér middleware, og Bulk Property Editor, Content Importer, Activity Timeline og Scheduled Jobs Gantt ligger alle i menuen.

Har I en bunkeopgave, I går og frygter — et navneskifte, en import, en oprydning auditten fortalte jer om — vil jeg gerne høre, om de her værktøjer bringer jer i mål, og hvor de kommer til kort. Åbn et issue eller en PR; det er den mest direkte vej ind. Og hvis det er den bredere opsætning, der er problemet — gæld i indholdsmodellen, en migrering i horisonten, redaktører der arbejder uden om platformen i stedet for med den — så er Optimizely det, vi laver.