4 måter innholdsstyringssystemer utvikler seg på og hvorfor det er viktig for journalister

Et biprodukt av den digitale medierevolusjonen er at de fleste journalister i dag er teknologer, til et visst punkt. Det er stadig mer sjeldent å møte journalister som ikke begjærer den nyeste hyperdrevne smarttelefonen.

Jeg har møtt mangeårige journalister som, etter å aldri ha skrevet en slikk HTML-kode, likevel er ivrige etter å hoppe over nettet helt og begynne å finne ut historiefortelling for nettbrett. Hvis jeg skrev om hvordan stedsbasert nettverk utviklet seg, er sjansen stor for at jeg ville hektet på mange nysgjerrige journalister som ikke har tenkt å legge til geodata i historiene deres. Men det er vanskelig å få folk interessert i den ene teknologien de må bruke hver dag, den tingen som enten hemmer eller aktiverer historiefortellingen fra romalderen de ønsker å gjøre - innholdsstyringssystemet deres.

Hvis jobben din på noen måte innebærer å produsere medier for offentlig eller semi-offentlig forbruk, er sjansen stor for at du er en storbruker av et innholdsstyringssystem (CMS). Og sjansen er også ganske stor for at organisasjonen din ønsker å erstatte eller forbedre CMS. Det er verdt å vite noen nøkkelleksjoner vi har lært om hvordan innholdsadministrasjon utvikler seg, slik at du vet hva du skal se etter.

Etter å ha jobbet for og med en rekke nyhetsorganisasjoner, har jeg en stund hatt en følelse av at vi begynner å nærme oss innholdsstyring annerledes enn vi gjorde i de tidlige dagene av nettet. Vår følelse av hva et CMS bør gjøre, modnes. For å finne ut mer snakket jeg med tre personer som alle har hatt integrerte roller i CMS-utvikling hos flere nyhetsorganisasjoner, to av dem har jeg jobbet med som redaksjonell produktsjef for Project Argo:

• Andrew Fitzgerald , som nylig flyttet fra Current TV for å bli seniorprodusent for online-tilstedeværelsen for Al Jazeeras 'The Stream'.
• Patrick Cooper , tidligere en daglig nyhetsblogger for USA Today, nå produkteier av NPR.org og CMS som driver NPRs digitale plattformer ('Seamus').
• Marc Lavallee , lagkameraten min, som oppholdt seg i organisasjoner som The Boston Globe, The Washington Post og National Journal før han kom til NPR for å konstruere plattformen som driver Project Argo ('Navis').

Alle disse tre systemene er svært forskjellige, men de deler noen viktige fellestrekk som jeg tror gir en nyttig pekepinn på hvordan CMS-er utvikler seg.

Journalistikk beveger seg fra 'innholdsstyringssystemer' til 'innholdsstyringsøkosystemer'

Digitale nyhetsoperasjoner pleide å tenke på CMS som deres one-stop shop: et verktøy som ville gjøre alt man måtte ønske å gjøre med innholdet sitt. Det ville være stedet hvor redaktører kunne tilordne historier, journalister kunne lage utkast til historier, multimediekunstnere kunne lagre videoene sine, nettprodusenter kunne programmere seksjonsfronter, fellesskapsledere kunne administrere kommentarer og mer. Nyhetsorganisasjoner ville bedømme potensielle CMS-er etter hvor mange forskjellige funksjoner programvaren hadde, snarere enn etter hvor godt programvaren utførte en bestemt funksjon.

Vi har endelig begynt å akseptere at ingen enkelt CMS kan håndtere alle innholdsfunksjonene til en digital nyhetsorganisasjon. Et godt innholdsstyringssystem i dag er designet for å samhandle med mye annen programvare. Det er nå en genuin forventning om at et CMS vil spille bra med videoer som er lagret på YouTube, eller kommentarer administrert av Disqus, eller live chat innebygd fra CoverItLive. Andre miljøer som Facebook, Twitter og Tumblr kommer med sine egne verktøypakker. Og i økende grad er det vi kaller et 'innholdsstyringssystem' faktisk en kombinasjon av flere tett integrerte systemer.

Etter at vi undersøkte flere alternativer for å bygge plattformen som skulle bli Prosjekt Argo , bestemte teamet mitt å bruke WordPress som en grunnlinje. Men vi ønsket å oppnå flere ting som WordPress ikke ville gjøre enkelt, så Lavallee blandet WordPress med django . Dette gjorde at vi sømløst kunne koble Argo-plattformen til tjenester som f.eks Nydelig og Dagsliv , med minimal friksjon for brukere av programvaren. Hvert verktøy gjør akkurat det det er designet for å gjøre, uten å prøve å sette sammen stadig mer kompleks funksjonalitet i ett system.

Al Jazeera så for seg ' Strømmen' som en show- og nettbasert nyhetskilde bygget på toppen av den robuste samtalen som foregår på sosiale medier over hele verden. Så da nettstedet valgte innholdsstyringssystemet som skulle håndtere programmets tilstedeværelse på nettet, begynte de med programvare laget for å kurere den samtalen – Storify . Nettappen lar vanlige brukere enkelt samle historier fra innlegg på sosiale medier.

Nettprodusenter for «The Stream» bygger historier i Storify som blir trukket inn i en installasjon av Drupal, hvor de redigeres, godkjennes og publiseres på nettet. Storify-plus-Drupal-kombinasjonen gir 'The Stream'-teamet flere fordeler:

• Storify gir produsentene et slankt, brukervennlig grensesnitt for å trekke inn nuggets fra samtalen på sosiale medier.
• Drupal håndterer oppgaven med å publisere nettstedet, slik at 'The Stream' kan fortsette å publisere selv om Storify er utilgjengelig.
• Den legger også til funksjoner som Storify ennå ikke har, for eksempel håndtering av Google Maps.

NPR.orgs CMS, Seamus, er hjemmelaget, og det er et fullt team dedikert til den pågående utviklingen og vedlikeholdet av programvaren. Men selv med disse robuste ressursene, er ikke Seamus den eneste aktøren i organisasjonens innholdsstyringsøkosystem. Et eget hjemmelaget system ('NewsFlex') administrerer lydressurser og historiebudsjettering for radio. Og e-post er så dypt integrert i arbeidsflyten til NPRs nettredaktører at man kan si at en annen av CMSene våre er Outlook.

Men Seamus’ største partner i å administrere NPRs innhold er noe som kalles NPR API («Application Programming Interface»). Det er skrevet mye om de mange måtene det på API har tillatt NPR å bygge sin digitale tilstedeværelse ; her er en fantastisk artikkel fra min Poynter-redaktør Mallary Tenore om arbeidet med å utvide denne API-en til alle offentlige medier. API-en gjør det mye enklere for alle innholdsstyringssystemene våre å snakke med hverandre. Det er en perfekt gjenspeiling av hvor sammenkoblet innholdsadministrasjonsprogramvaren vår har blitt.

Det er en økende forståelse for at innholdsstyringssystemer bør være 'vakre'

Jeg har sett noen fæle CMS-er - kontekstløse klynger av tekstinntastingsbokser overfylt med minefelt med popup-vinduer. Så en dag i 2005 eller 2006 gledet jeg meg over Wilson Miners strålende administrasjonssidedesign for Django.

Etter år med CMS-er som etterlignet den tøffe utilitaristiske estetikken til Windows 3.1, var Django-administratoren fantastisk – en flott fargepalett; smakfulle, målrettede gradienter; fortryllende ikondesign. Selv opplevelsen av å samhandle med tingen var en fryd. Å trykke på en knapp kan fremkalle en sjarmerende JavaScript-effekt - ingenting unødvendig dekorativt, alt glatt og tilfredsstillende. Verden endret seg litt.

Din gjennomsnittlige nyhetsorganisasjon CMS pleide å kreve uker med opplæring for å akklimatisere nye brukere. Tross alt, hvorfor skulle et selskap bruke dyrebare designressurser på å polere et 'back-end-grensesnitt' som brukere av nyhetssiden aldri ville se? Det viser hvor langt vi har kommet når Storify – rost for sin fantastiske intuitive brukeropplevelsesdesign – nå fungerer som et back-end-grensesnitt for en nyhetsorganisasjons CMS. Vakker programvare, selv for back-end-brukere, begynner å bli en forventning.

Vi beveger oss i denne retningen fordi vi nå forstår at bedre innholdsstyringssystemer fremmer bedre innhold. 'Jo lykkeligere folk er, jo bedre innhold vil de være, jo mer innhold vil de produsere,' sier NPRs Cooper. Pluss, som han påpeker, gjør digitale journalister nå mye mer kreativt, originalt arbeid enn de gjorde da nyhetssidene startet opp, da det meste av innholdet deres ble portert fra andre medieformater. 'Digitale redaksjoner har gått fra å måke til å skape,' sa han. 'Disse to oppgavene krever svært forskjellige miljøer.'

Da vi lanserte de 12 Argo-sidene i september i fjor, var ikke teamet mitt i stand til å trene personlig med noen av bloggerne som skulle drive sidene. Vi ga bloggerne lenker til en startguide og noen opplæringsprogrammer, og vi var tilgjengelige på telefon, men ellers måtte de få fart på plattformen på egenhånd. I løpet av få dager kunne til og med brukere som var nye til HTML publisere robuste, attraktive nettsteder. Dette ville ikke vært mulig uten årene med testing, bruk og utvikling som har gått inn i WordPress-grensesnittet, påpeker Lavallee. 'En WordPress-utvikler kan få tilbakemelding fra millioner av brukere direkte,' sier han, 'noe som vanligvis ikke er tilfelle i et bedriftsstøtteforum.'

Noe som leder meg til neste punkt.

Åpen kildekode-programvare har hevet standarden for standard innholdshåndteringsopplevelse

Da jeg jobbet i avisbransjen, så det meg som en enorm sløsing med ressurser at vi hadde tusenvis av individuelle aviser med nesten identiske behov for innholdsstyring, men vi hadde ennå ikke bestemt oss for noen grunnleggende innholdsstyringsstandarder eller plattformer. Det virket som om hver dag en ny leverandør kom inn på innholdsadministrasjonsmarkedet med et proprietært produkt, bygget fra bunnen av.

I mellomtiden, tidlig på 2000-tallet, var åpen kildekode CMS-programvare ennå ikke et sterkt alternativ. Men åpen kildekode-fellesskapet begynte å konvergere på standarder, og bygge videre på arbeidet andre i rommet hadde oppnådd. (WordPress, for eksempel, begynte sitt liv som en etterkommer av bloggplattformen med åpen kildekode b2.)

Ved midten av tiåret hadde prosjekter som WordPress, Drupal og Django begynt å oppnå kritisk masse. I løpet av de siste årene, sier Lavallee, har ledere som har tatt programvarebeslutninger i medieselskaper, begynt å se åpen kildekode-programvarepakker som var mer elegante enn de dyre produktene som ble markedsført av leverandører.

I dag har leverandører som demonstrerer programvare eller nyhetsorganisasjoner som vurderer et proprietært CMS en ganske høy bar å fjerne for å rettferdiggjøre investeringen: de må bygge noe som er bedre enn WordPress eller Drupal – raskere, mer funksjonelt, mer stabilt, sikrere eller mer tilpasset til deres behov. Ettersom den gratis programvaren har blitt bedre, har hvert CMS måttet forbedres for å følge med.

Og hvis du ikke kan slå dem, bygg på dem. Selv de mest ressurssterke nyhetsorganisasjonene bruker åpen kildekode-verktøy som Django, Ruby on Rails, WordPress og Drupal sammen med eller inne i deres hjemmelagde eller leverandørbygde CMS-er. Seamus, for eksempel, inkorporerer åpen kildekode-produkter som f.eks jQuery og ImageMagick i innmaten. Vi var i stand til å lansere Argo-sidene raskt fordi vi kunne bruke WordPress som utgangspunkt; all vår utvikling var orientert mot å tilpasse og utvide programvaren for våre behov. NPRs digitale tjenester-avdeling hjelper medlemsstasjoner med å utvikle deres netttilstedeværelse; deres nyeste produkter er bygget på den nyeste versjonen av Drupal.

Alt dette er ikke å si at åpen kildekode-programvare er et universalmiddel. NPRs Cooper og Al Jazeeras Fitzgerald oppgir begge en enorm verdi i større selskaper som har intern utviklingsekspertise på innholdsstyring. WordPress og Drupal gir fantastiske standardinnstillinger og utgangspunkter, men jo større og mer komplekse behovene til organisasjonen er, desto mer vil den møte begrensningene til disse produktene.

I fjor flyttet NPR bloggene sine fra WordPress og til Seamus, noe som muliggjorde en mer sømløs integrasjon mellom blogginnhold og resten av materialet NPR genererer. Og etter hvert som Currents forståelse av seg selv som et medieselskap utviklet seg, var organisasjonen i stand til å konstruere sine hjemmelagde innholdsadministrasjonsplattformer for å tilpasse seg også.

Vi har innsett at god innholdsstyring krever konstant utvikling

I alle aspekter av media har nyhetsorganisasjoner måttet venne seg til at konstant endring er den nye normalen. Innholdsstyring er ikke annerledes. I store deler av det siste tiåret så det ut til at hver nyhetsorganisasjon alltid gikk over til et nytt system med noen års mellomrom - en enormt betydelig oppgave. Vi lette etter sølvkulen – systemet som ville være fleksibelt og robust nok til å løse alle våre problemer og dekke alle våre behov de neste 10 årene.

Vi vet nå at et slikt system ikke eksisterer. Vi begynner å forstå at et CMS – ethvert CMS, åpen kildekode, bedrift eller annet – krever kontinuerlig investering og utvikling. Uansett hvor liten eller stor organisasjonen din er, må innholdsstyringssystemet ditt utvikles for å imøtekomme et digitalt nyhetsmiljø som endrer seg dramatisk fra år til år.

Hvis du er en del av en stor medieorganisasjon, trenger du folk som er dedikert til å vedlikeholde og utvide CMS - enten det betyr et internt utviklingsteam eller et tett, pågående forhold til en leverandør. Hvis du er en del av en uavhengig nyhetsoperasjon for to personer som kjører WordPress, bør du oppdatere programvaren regelmessig og legge til og fjerne plugins som oppfyller dine behov.

På mange måter understreker denne virkeligheten de tre andre observasjonene ovenfor. Fordi vi vet at innholdsadministrasjonsmiljøet vårt kommer til å måtte utvikle seg ofte og betydelig i overskuelig fremtid, må vi bygge systemer som er lette og fleksible nok til å fungere sammen med andre.

Fordi det ikke gir mening å bruke en måned med opplæring på et system som skal endres i løpet av et år, må vi bruke grensesnitt for innholdsadministrasjon som er vakre nok til at brukerne kan forstå det intuitivt.

Og fordi vi trenger å utvikle oss raskt, må vi låne verktøy og ideer fra verden av åpen kildekode-programvare for å gjøre innholdsstyringsøkosystemene våre bedre.