A tartalomkezelő rendszerek 4 módja, és miért fontos ez az újságíróknak

A digitális média forradalmának egyik mellékterméke, hogy a legtöbb újságíró egy bizonyos pontig technikus. Egyre ritkábban lehet találkozni olyan újságírókkal, akik nem vágynak a legújabb hipermotoros okostelefonra.

Régóta találkoztam olyan újságírókkal, akik soha nem írtak HTML-kódot, ennek ellenére szívesen kihagyják az internetet, és elkezdenek mesélést kitalálni táblagépeken. Ha arról írnék, hogyan fejlődött a helyalapú hálózatépítés, nagy eséllyel sok olyan kíváncsi újságot vonnék be, akiknek esze ágában sincs geoadatokat hozzáadni a történeteikhez. De nehéz felkelteni az emberek érdeklődését az egyetlen technológia iránt, amelyet nap mint nap használniuk kell, ami vagy gátolja vagy lehetővé teszi az űrkorszaki történetmesélést, amit szeretnének – a tartalomkezelő rendszerük iránt.

Ha az Ön munkája bármilyen módon közcélú vagy félnyilvános médiát állít elő, akkor nagy valószínűséggel Ön egy tartalomkezelő rendszer (CMS) erős felhasználója. És elég nagy az esélye annak is, hogy szervezete le akarja cserélni vagy javítani kívánja CMS-jét. Érdemes tudni néhány kulcsfontosságú leckét, amelyeket megtanultunk a tartalomkezelés fejlődésével kapcsolatban, hogy tudja, mire kell figyelnie.

Miután számos hírszervezetnek dolgoztam és együtt dolgoztam, egy ideje az volt az érzésem, hogy kezdünk másképp közelíteni a tartalomkezeléshez, mint a Web kezdeti napjaiban. Érzékelésünk, hogy mit kell tennie egy CMS-nek, kezd érlelődni. Hogy többet megtudjak, három emberrel beszélgettem, akik mindannyian fontos szerepet töltöttek be a CMS-fejlesztésben több hírszervezetnél, közülük kettővel az Argo Project szerkesztői termékmenedzsereként dolgoztam együtt:

• Andrew Fitzgerald , aki nemrég költözött a Current TV-től, hogy az Al Jazeera „The Stream” című műsorának online jelenlétének vezető producere legyen.
• Patrick Cooper , korábban a USA Today napi hírbloggere, jelenleg az NPR.org terméktulajdonosa és az NPR digitális platformjait működtető CMS („Seamus”).
• Marc Lavallee , a csapattársam, aki olyan szervezeteknél tartózkodott, mint a The Boston Globe, a The Washington Post és a National Journal, mielőtt az NPR-hez érkezett, hogy megépítse a Project Argot („Navist”) meghatalmazó platformot.

Mindhárom rendszer nagyon különbözik egymástól, mégis megosztanak bennük néhány kulcsfontosságú közös vonást, amelyek véleményem szerint hasznos mutatót mutatnak a CMS-ek fejlődése felé.

Az újságírás a „tartalomkezelő rendszerekről” a „tartalomkezelő ökoszisztémák” felé halad.

A digitális hírszolgáltatók korábban úgy gondolták, hogy CMS-eik egyablakos ügyintézők: egy olyan eszköz, amely mindent megtesz, amit az ember a tartalommal szeretne. Ez lenne az a hely, ahol a szerkesztők történeteket oszthatnának ki, a riporterek sztorikat készíthetnének, a multimédiás szakemberek tárolhatnák videóikat, az online producerek programozhatnának rovatfrontokat, a közösségi menedzserek kezelhetik a megjegyzéseket és így tovább. A hírszervezetek a potenciális CMS-eket inkább az alapján ítélik meg, hogy a szoftver hány különböző funkcióval rendelkezik, nem pedig az alapján, hogy a szoftver milyen jól teljesít egy adott funkciót.

Végre elkezdtük elfogadni, hogy egyetlen CMS sem képes ellátni a digitális hírszervezetek összes tartalmi funkcióját. Egy jó tartalomkezelő rendszert ma úgy terveztek, hogy sok más szoftverrel együttműködjön. Ma már őszinte elvárás, hogy a CMS jól fog játszani a YouTube-on tárolt videókkal, vagy a Disqus által kezelt megjegyzésekkel, vagy a CoverItLive-ból beágyazott élő csevegésekkel. Más környezetek, például a Facebook, a Twitter és a Tumblr saját eszközkészlettel rendelkeznek. És egyre inkább az, amit „tartalomkezelő rendszernek” nevezünk, valójában több, szorosan integrált rendszer kombinációja.

Miután megvizsgáltunk több lehetőséget a platform felépítésére Argo projekt , csapatom úgy döntött, hogy használja WordPress alapállásként. De sok olyan dolgot szerettünk volna megvalósítani, amit a WordPress nem tesz egyszerűvé, ezért Lavallee összekeverte a WordPress-szel django . Ez lehetővé tette számunkra, hogy az Argo platformot zökkenőmentesen összekapcsoljuk olyan szolgáltatásokkal, mint pl Finom és Nappali élet , minimális súrlódással a szoftver felhasználói számára. Mindegyik eszköz pontosan azt csinálja, amire tervezték, anélkül, hogy egyre bonyolultabb funkcionalitásokat próbálna egyetlen rendszerbe beilleszteni.

Az Al Jazeera azt képzelte, A patak” műsorként és online hírforrásként a közösségi médiában világszerte zajló erőteljes beszélgetésre épül. Így amikor a webhely azt a tartalomkezelő rendszert választotta, amely kezeli a program online jelenlétét, a beszélgetést irányító szoftverrel kezdték – Storify . A webalkalmazás lehetővé teszi a mainstream felhasználók számára, hogy egyszerűen összegyűjtsék a történeteket a közösségi oldalakon közzétett bejegyzésekből.

A „The Stream” online producerei történeteket készítenek a Storify-ban, amelyek bekerülnek a Drupal telepítésébe, ahol szerkesztik, jóváhagyják és közzéteszik őket az interneten. A Storify-plus-Drupal kombó számos előnnyel jár a „The Stream” csapat számára:

• A Storify egy sima, könnyen használható felületet ad a producereknek, amelyek segítségével a közösségi médiában zajló beszélgetések apró részeit vonhatják be.
• A Drupal kezeli a webhely közzétételének feladatát, lehetővé téve a „The Stream” számára, hogy továbbra is közzétegye, még akkor is, ha a Storify nem érhető el.
• Olyan képességeket is hozzáad, amelyekkel a Storify még nem rendelkezik, például a Google Maps kezelését.

Az NPR.org CMS-je, a Seamus hazai gyártású, és egy teljes csapat dolgozik a szoftver folyamatos fejlesztésén és karbantartásán. De még ezekkel a robusztus erőforrásokkal is, a Seamus nem az egyetlen szereplő a szervezet tartalomkezelési ökoszisztémájában. Egy külön otthoni rendszer („NewsFlex”) kezeli a rádió hanganyagait és a történet költségvetését. Az e-mail pedig olyan mélyen beépült az NPR online szerkesztőinek munkafolyamatába, hogy azt mondhatnánk, egy másik CMS-ünk az Outlook.

De a Seamus legnagyobb partnere az NPR tartalmának kezelésében az NPR API („Application Programming Interface”). Sokat írtak már ennek sokféle módjáról az API lehetővé tette az NPR-nek, hogy kiépítse digitális jelenlétét ; íme egy nagyszerű cikk a Poynter szerkesztőmtől, Mallary Tenore-tól az API-nak az összes közmédiára való kiterjesztésére tett erőfeszítésekről. Az API sokkal könnyebbé teszi az összes tartalomkezelő rendszerünk számára, hogy beszélhessen egymással. Tökéletesen tükrözi, hogy tartalomkezelő szoftvereink mennyire összekapcsoltak egymással.

Egyre jobban megértik, hogy a tartalomkezelő rendszereknek „szépeknek” kell lenniük.

Láttam néhány förtelmes CMS-t – szövegbeviteli mezők kontextus nélküli klasztereit felugró ablakok bányamezőivel. Aztán egy napon 2005-ben vagy 2006-ban megláttam a szememet Wilson Miner dicsőséges adminisztrációs oldalain a Django számára.

A Windows 3.1 kemény haszonelvű esztétikáját utánzó CMS-ek évek óta a Django adminisztrátora lenyűgöző volt – egy lenyűgöző színpaletta; ízléses, céltudatos színátmenetek; lenyűgöző ikon design. Még a dologgal való interakció élménye is öröm volt. Egy gomb megnyomása elbűvölő JavaScript hatást idézhet elő – semmi szükségtelenül díszítő, minden sima és kielégítő. Kicsit megváltozott a világ.

Az Ön átlagos hírszervezetének CMS-je korábban hetekig tartó képzést igényelt az új felhasználók hozzászoktatásához. Végül is miért költene egy vállalat értékes tervezési erőforrásokat egy olyan „háttérfelület” csiszolására, amelyet a híroldal felhasználói soha nem látnának? Megmutatja, meddig jutottunk el, amikor a Storify – amelyet a csodálatosan intuitív felhasználói élmény kialakításáért dicsértek – immár háttérfelületként szolgál egy hírszervezet CMS-je számára. A gyönyörű szoftverek, még a háttérfelhasználók számára is, elvárássá válnak.

Ebbe az irányba haladunk, mert most már tudjuk, hogy a jobb tartalomkezelő rendszerek jobb tartalmat eredményeznek. 'Minél boldogabbak az emberek, annál jobb lesz a tartalom, annál több tartalmat fognak előállítani' - mondja az NPR Cooper. Ráadásul, amint rámutat, a digitális újságírók ma sokkal kreatívabb, eredetibb munkát végeznek, mint a híroldalak indulásakor, amikor tartalmuk nagy részét más médiaformátumokról vitték át. „A digitális szerkesztőségek a lapátolástól az alkotás felé mozdultak el” – mondta. 'Ez a két feladat nagyon eltérő környezetet igényel.'

Amikor tavaly szeptemberben elindítottuk a 12 Argo-webhelyet, csapatom nem tudott személyes képzést tartani egyik bloggerrel sem, aki az oldalakat üzemeltette volna. A bloggereknek linket adtunk egy kezdő útmutatóhoz és néhány oktatóanyaghoz, és telefonon is elérhetőek voltunk, de egyébként maguktól kellett felgyorsulniuk a platformon. Néhány napon belül még a HTML-t még nem ismerő felhasználók is képesek voltak robusztus, vonzó webhelyeket közzétenni. Lavallee rámutat, hogy ez nem jöhetett volna létre az évekig tartó tesztelés, használat és fejlesztés nélkül, amelyek a WordPress felületére kerültek. „A WordPress-fejlesztők közvetlenül több millió felhasználótól kaphatnak visszajelzést” – mondja –, ami általában nem így van a vállalati támogatási fórumokon.

Ami a következő ponthoz vezet.

A nyílt forráskódú szoftverek megemelték a mércét az alapértelmezett tartalomkezelési élmény terén

Amikor az újságiparban dolgoztam, óriási erőforrás-pazarlásnak tűnt, hogy több ezer egyedi újságunk volt, amelyeknek tartalomkezelési igénye közel azonos volt, de még nem állapodtunk meg semmilyen alapszintű tartalomkezelési szabvány vagy platform mellett. Úgy tűnt, minden nap új gyártó lépett be a tartalomkezelési piacra egy saját fejlesztésű, a semmiből felépült termékkel.

Eközben a 2000-es évek elején a nyílt forráskódú CMS-szoftver még nem volt erős alternatíva. A nyílt forráskódú közösség azonban kezdett közeledni a szabványokhoz, és a térben mások által végzett munkára építkezett. (A WordPress például a b2 nyílt forráskódú blogplatform leszármazottjaként kezdte életét.)

Az évtized közepére az olyan projektek, mint a WordPress, a Drupal és a Django, elkezdték elérni a kritikus tömeget. Lavallee szerint az elmúlt néhány évben a médiacégeknél szoftveres döntéseket hozó vezetők elkezdtek látni olyan nyílt forráskódú szoftvercsomagokat, amelyek simábban néznek ki, mint a gyártók által forgalmazott drága termékek.

Manapság a szoftvereket bemutató gyártók vagy hírügynökségek saját CMS-t fontolgatnak egy magas lécet, hogy igazolják a befektetést: valami olyat kell készíteniük, ami jobb, mint a WordPress vagy a Drupal – gyorsabb, funkcionálisabb, stabilabb, biztonságosabb vagy jobban testreszabott. igényeiket. Ahogy az ingyenes szoftver fejlődött, minden CMS-nek fejlődnie kellett, hogy lépést tudjon tartani.

És ha nem tudod legyőzni őket, építs rájuk. Még a leginkább erőforrásokkal rendelkező hírszervezetek is használnak nyílt forráskódú eszközöket, például a Django-t, a Ruby on Rails-t, a WordPress-t és a Drupalt saját gyártású vagy gyártók által épített CMS-eik mellett vagy belül. A Seamus például olyan nyílt forráskódú termékeket foglal magában, mint pl jQuery és ImageMagick a belsejében. Gyorsan tudtuk elindítani az Argo oldalakat, mert a WordPress-t használhattuk kiindulópontként; minden fejlesztésünk a szoftver igényeinek megfelelő adaptálására és bővítésére irányult. Az NPR digitális szolgáltatások részlege segít a tagállomásoknak webes jelenlétük fejlesztésében; legújabb termékeik a Drupal legújabb verziójára épülnek.

Mindez nem jelenti azt, hogy a nyílt forráskódú szoftver csodaszer. Az NPR Cooper és az Al Jazeera Fitzgerald cége egyaránt óriási értékre hivatkozik a nagyobb vállalatokban, amelyek házon belüli fejlesztési szakértelemmel rendelkeznek a tartalomkezelés terén. A WordPress és a Drupal nagyszerű alapértelmezéseket és kiindulási pontokat kínál, de minél nagyobbak és összetettebbek a szervezet igényei, annál jobban szembeszáll e termékek korlátaival.

Tavaly az NPR áthelyezte blogjait a WordPressről a Seamusba, lehetővé téve a zökkenőmentes integrációt a blogtartalom és az NPR által generált többi anyag között. És ahogy a Current médiavállalatként értelmezte önmagát, a szervezet képes volt saját tartalomkezelő platformjait is alkalmazkodni.

Felismertük, hogy a jó tartalomkezelés folyamatos fejlesztést igényel

A média minden területén a hírszervezeteknek meg kellett szokniuk, hogy az állandó változás az új normális. A tartalomkezelés nem más. Az elmúlt évtized nagy részében úgy tűnt, hogy minden hírszervezet néhány évente átáll egy új rendszerre – ez rendkívül jelentős vállalkozás. Az ezüstgolyót kerestük – azt a rendszert, amely elég rugalmas és robusztus lenne ahhoz, hogy minden problémánkat megoldja és minden igényünket kielégítse a következő 10 évben.

Ma már tudjuk, hogy ilyen rendszer nem létezik. Kezdjük megérteni, hogy egy CMS – minden CMS, nyílt forráskódú, vállalati vagy egyéb – folyamatos befektetést és fejlesztést igényel. Nem számít, milyen kicsi vagy nagy a szervezete, a tartalomkezelő rendszernek úgy kell fejlődnie, hogy megfeleljen az évről évre drámaian változó digitális hírkörnyezetnek.

Ha Ön egy nagy médiaszervezet tagja, olyan emberekre van szüksége, akik elkötelezettek a CMS karbantartásában és bővítésében – legyen szó akár házon belüli fejlesztőcsapatról, akár szoros, folyamatos kapcsolatról egy szállítóval. Ha egy kétszemélyes, független hírműveletben vesz részt, amely a WordPress-t futtatja, akkor rendszeresen frissítenie kell a szoftvert, és az igényeinek megfelelő bővítményeket kell hozzáadnia és eltávolítania.

Ez a valóság sok tekintetben aláhúzza a fenti másik három megfigyelést. Mivel tudjuk, hogy tartalomkezelő környezetünknek a belátható jövőben gyakran és jelentős mértékben kell fejlődnie, olyan rendszereket kell építenünk, amelyek elég könnyűek és rugalmasak ahhoz, hogy együttműködjenek másokkal.

Mivel nincs értelme egy hónapos képzést eltölteni egy éven belül megváltozni fogó rendszeren, olyan tartalomkezelő felületeket kell használnunk, amelyek elég szépek ahhoz, hogy a felhasználók intuitív módon megértsék.

És mivel gyorsan kell fejlődnünk, eszközöket és ötleteket kell kölcsönvennünk a nyílt forráskódú szoftverek világából, hogy jobbá tegyük tartalomkezelő ökoszisztémánkat.