Hogyan válasszuk ki a megfelelő tartalomkezelő rendszert (CMS - Content Management System)?

Minden esetben jól át kell gondolni, hogy milyen funkcionalitást várunk el a tartalomkezelő rendszertől (CMS, admin, adminisztrációs rendszer), mert konkrét elképzelések nélkül nagyon hamar elkeveredhetünk a különböző látványos de a jövőben semmire sem használható funkciók tengerében. Mit vegyünk figyelembe amikor CMS-t választunk?

Mielőtt felmérjük a lehetőségeket készítsünk "bevásárlólistát", hogy valójában mire van szükségünk, így elcsábulunk el, mint az éhes ember mindenféle nyalánkság láttán bevásárláskor. Ez azért is hasznos, mert így könnyebben eligazodunk majd a funkciók között, és hamarabb rájövünk, ha nincs is szükségünk a legbonyolultabb és legdrágább CMS rendszerre, mert nekünk bőven elegendő egy nyílt forráskódú blogmotor.

Hogyan állítsuk össze a listát?

Alap funkciók

Minden CMS rendszer alap funkciója a tartalom létrehozás, törlés, módosítás és a rendezés. Ezt nem minden fejlesztő gondolja így, ezért valójában nagy eltérések vannak a rendszerek között. Nem minden rendszer engedi, hogy az oldalainkat kategóriákba, rovatokba, csoportokba rendezzük, még kevesebb az melyben fastruktúrát használhatunk. A korlátozott rendszereket könnyebb átlátni és egyszerűbb a használatuk is, de van amikor a kötöttségek kifejezetten idegesítőek.

Mindig gondoljuk át alaposan az igényeinket, ha jelenleg nem is akarjuk rendezgetni a tartalmat az oldaladon, mert kialakult elképzelésünk van, lehet, hogy a jövőben szükségünk lesz erre a funkcionalitásra. Ügyeljünk, hogy az alap funkciókat használhassuk a választott rendszerben és figyeljünk oda, hogy mennyire egyszerű vagy bonyolult a rendszer kezelése. Ezer és ezer CMS rendszer van a piacon mely minden alap funkciót használ, de elég nehéz használni azokat, midig próbáljuk ki a rendszert, hogy megtapasztaljuk mennyire jól használható!

A szerkesztő

A szerkesztő egy olyan alap funkció, amit érdemes kiemelni a többi közül. A legtöbb CMS, WYSIWYG editort (szerkesztőt) használ A WYSIWYG szerkesztőben azonnal úgy látjuk a tartalmat, ahogy az az oldalon meg fog jelenni. Furcsa módon a megfelelő szerkesztő kiválasztására fordítjuk a legkevesebb figyelmet, annak ellenére, hogy ezt használjuk leginkább. A szerkesztő az a rész amin keresztül a tartalmunk az oldalra kerül.

A népszerű szerkesztők engedik az alap formázások használatát, azaz a betűtípus és szín változtatást, mindemellett a jelenlegi fejlesztési irányok ettől ellentétesek, elindultak a legjobb gyakorlat irányába.

Az egyik nagy veszély a WYSIWYG szerkesztőben, hogy túl nagy szabadságot ad a felhasználónak a design alakításában, egyszerűen változtatható a tartalom megjelenése, ezáltal megbontja a tartalom egységét, egyöntetűségét és káros a brand építésnél. A másik nagy probléma, hogy ekkora szabadság túl nagy átfedést eredményez a tartalom kezelés és a design között.

Az új generációs szerkesztők, ezzel szemben nem mutatják meg, hogy valójában hogyan fognak kinézni a linkek, felsorolások, listák, hivatkozások, csak jelzik azokat. Legyünk biztos benne, hogy olyan szerkesztő van a rendszerben amelyik e szerint ez elv szerint működik, és nem enged túl nagy teret a tartalom kezelőnek a design alakítására. A legjobb ha nyitva marad a lehetőség, hogy a későbbiekben egy ezeknél jobb szerkesztőt lehessen az oldalba építeni.

Az editor képes kell legyen külső elemek kezelésére is, mint a képek és a letölthető állományok.

Tartalomba ágyazható elemek kezelése

A tartalomkezelő rendszerek általában nem jól oldják meg a képek és egyéb kapcsolódó elemek kezelését. Különösen a képeknél van sok probléma. Kérdezzünk rá, hogy a rendszer tudja-e kezelni az <ALT> kiterjesztést, továbbá milyen szerkesztést segítő funkcióval rendelkezik. Sokan elvárt működésnek tekintik a forgatás, átméretezés és darabolás funkciókat, de itt tudnunk kell, hogy ha rendelkezik is ezen tulajdonságokkal a rendszer, akkor sem éri el egy képszerkesztő szoftver tudását. Ha lehetőségünk van rá inkább rendszeren kívül kezeljük a képeket és csak a végterméket töltsük fel az oldalra. Ebből a szempontból jó alternatívát találni igen nehéz.

Nagy figyelmet kell szentelnünk rá, hogy miként kezeli a rendszer a feltöltött fileokat, mint a PDF, a Word dokumentum. Miként jelennek meg a letöltések a felhasználó számára? Lehet-e kiegészítő, magyarázó információt fűzni hozzá, ill. a beépített kereső beindexeli-e a fileokat?

Keresés

A keresés kulcsfontosságú, lévén a felhasználók fele a keresőt fogja használni, hogy megtalálja a megfelelő tartalmat az oldalunkon. Mire kell figyelnünk a kereső működésénél?

Frissesség. Milyen időközönként indexeli újra az oldal tartalmát a keresőnk? Ez akkor a legfontosabb, ha rendszeresen változik az oldal tartalma.
Tüzetesség. Mennyire alaposan, milyen mélységben kereshetünk a tartalomban? Vannak rendszerek ahol mi magunk szabhatjuk meg, hogy a tartalom mely része legyen kereshető, vagy a dokumentumokat is indexelje-e a kereső, így azok is találatként jelentkezzenek a felhasználó számára.
Sebesség. Néhány keresőnél „éveket” kell várni az eredményre, ez különösen sok tartalom esetén lehet, de mindenképpen figyelnünk kell rá, hogy minél gyorsabban kapjon választ a látogató.
Fókusz. Be lehet-e állítani, hogy az oldal egy bizonyos részén, bizonyos tartalomban, vagy egy meghatározott szekcióban, rovatban keressünk csak?
Rangsorolás. Miként rangsorolja a kereső rutin a találatokat? Állítható-e ez valamilyen szinten általunk vagy a felhasználó által?
Testre szabhatóság. Állítható-e, hogy miként jelenjenek meg a keresési eredmények az oldalon, mennyire kötött a design?

Testreszabás

Sajnos vannak olyan rendszerek, melyek teljesen rögzített megjelenéssel rendelkeznek és csak szűk határok között módosítható a design. Ne a CMS szabjon határt a kinézetnek, éppen elég korlátot jelent maga a háttértechnológia! Sajnálatos módon sok CMS készítő, nem a legjobb módszereket alkalmazza, mikor a megjelenés és a tartalom közötti kapcsolatot kialakítja, így iszonyatosan rossz kód készül, mely nem csak a kereső robotokat zavarja össze, hanem a különböző böngészőket is próbára teszi, sőt magát a tartalmat is képes átrendezni.

Olyan rendszerre van szükségünk, mely több lehetőséget is ad a tartalom bemutatására és rendezésére. Kérdezzünk rá, hogy a híreket lehet-e időrendben visszafelé elhelyezni az oldalon, megjelenhetnek-e a legújabb hozzászólások az oldalsó hasábban, van-e lehetőség események megjelenítésére egy naptárban? A rugalmasság teszi a rendszereket kimagaslóvá!

Felhasználó kezelés

Ha weboldalad célja valamilyen közösség építése, akkor a CMS is kell rendelkezzen az ehhez szükséges lehetőségekkel, mint chat, fórum, hozzászólás és értékelés. A legalapvetőbb, hogy el tudjunk helyezni az oldalon űrlapot és így tudjanak például üzenetet küldeni a látogatók. Kérdezzünk rá, milyen könnyen lehet ilyet létrehozni? Lehet-e módosítani a mezőket? Hogyan kapjuk meg a visszajelzést? Állítható-e, hogy hova érkezik az elküldött információ? Adatbázisban tárolja a rendszer az adatokat, vagy akár Excelbe is letölthető? Gondoljuk át mely funkciókra van szükségünk és ahhoz keressünk megfelelő rendszert.

Tudjuk meg, hogy milyen eszközök állnak a rendelkezésünkre ahhoz, hogy felhasználókkal kommunikálhassunk! Tudunk a rendszerből e-mail-t küldeni felhasználóknak vagy felhasználók egy csoportjának? Tudunk csoportokat létrehozni, hogy bizonyos leveket csak a megfelelő csoportba tartozók kapjanak meg? Mi a helyzet az RSS-el?

Ismerjük meg milyen lehetőségeket rejt a rendszer a felhasználók adatainak kezelésére, hogy tudunk-e jelszót változtatni, tudjuk-e a jogaikat állítani, vagy exportálhatóak-e az adatok, más rendszerben is fel tudjuk-e azokat használni? De nem csak a felhasználók jogosultságaival kell törődni, azokét is fontos ismerni akik szerkesztik az oldalt.

Jogosultság kezelés

Minél többen szerkesztik az oldalunkat, annál nagyobb szükségünk lesz rá, hogy meghatározhassuk, ki mihez fér hozzá. Például, lehet olyan csoport akik híreket tehetnek fel az oldalra, de eseményeket nem kezelhetnek. Ehhez olyan CMS-t kell választanunk ami rendelkezik jogosultság kezelő modullal. Vannak rendszerek ahol meghatározhatjuk, hogy milyen tartalmi elemeket kik szerkeszthetnek, de vannak olyanok is ahol az oldal bizonyos részét vagy bizonyos funkciókat csak a szerkesztők egy jól meghatározott csoportja használhatja.

Ha még tovább fejlődik az oldal, eljutunk egy olyan szintre amikor már kell valaki aki jóváhagyja a megjelenő tartalmat. Ezt is érdemes már az elején meggondolni, hogy szükség lesz-e valamilyen moderátori, engedélyező pozícióra. Legjobb ha a rendszer képes több jog együttes kezelésére, ill. egy felhasználó több típusú jogosultsággal is rendelkezhet.

Még hatásosabb egy szerkesztői rendszer, ha maga a tartalmi elem képes követni, hogy éppen milyen állapotban van, éppen elkészült, vagy a szerkesztő már ellenőrizte, publikálásra kész, engedélyezett, tehát élesben is mehet az oldalra. Erre lehetőséget biztosít a verziókövetés.

Verziókövetés

Ha verziókövetéssel rendelkezik a tartalomkezelő rendszer, akkor könnyen visszaállítható az előző mentett állapot, ha véletlenül valamit hibásan publikáltunk. Néhány rendszer dátum alapján visszakereshetővé teszi a korábbi verziókat, ami egy kicsit túlzás, de jól használható ha legalább az előző mentett verziót vissza tudjuk állítani.

Ez a funkció igen ritkán használt és feleslegesnek tűnik, de életet menthet. Általában nagy céges alkalmazásoknál használták a verziókövetést, de egyre elterjedtebb a tartalom kezelő rendszerekben.

Több weboldal együttes kezelése

Manapság már elvárható egy CMS-től, hogy tudjon párhuzamosan több weboldalt kezelni, ez már-már alap funkció. Gondoljunk bele, hogy szeretnénk a vásárlóink egy csoportjának, egy kisebb vállalati szegmensnek, esetleg a belső kommunikációnak egy elkülönült oldalt indítani, de nem szeretnénk újabb rendszert csatasorba állítani, a jelenlegi keretek megfelelnek. Erre a legjobb megoldás, ha már maga a CMS el tudja végezni a munkát, azaz rendszeren belül ki tudjuk alakítani az eltérő megjelenésű új oldalt. Nem kell újratanulnunk a kezelést, a már meglévő tartalom használható az új oldalon is - ennek feltétele, hogy ne WYSIWIG szerkesztőt használjunk -, a design egységes marad, a jogosultsági szintek sem változnak.

Más alkalmazási terület lehet, az egyre jobban kibontakozó mobil internetezés. Az így böngészők számára általában az információt, más formában szeretnénk megjeleníteni, ehhez sem kell új rendszer a tartalom készen van, csak át kell csoportosítani és a megfelelő módon kell prezentálni.

Többnyelvűség

Erről a funkcionalitásról a legkönnyebb lemondani, mert ha úgyis a helyi piac elérése a célunk, akkor miért is kellene más nyelveken megszólalnia az oldalnak, miért kellene erre még több erőforrást áldozni? De gondoljuk meg kétszer mielőtt ezt a funkciót feleslegesnek nyilvánítjuk.

Ha most nyelvspecifikus is a tartalom amit kínálunk, még megváltozhat. Érdemes megtartani a nyelvi funkciókkal való bővítés a lehetőséget, hogy növeljük a piacunkat. Egy multikulturális világban élünk, ahol sokan sokféle nyelven beszélnek és használják az internetet, miért korlátoznánk le magunkat nyelvi határokkal?

De nagyon sokan választják úgy is ezt a funkcionalitást, hogy sohasem használták, vagy fogják használni, mert nem gondolnak bele, miként fognak idegen nyelvű tartalmat készíteni, vagy mennyibe fog kerülni lefordíttatni a már meglévő cikkeiket. Ilyen esetben ez csak felesleges pénzkidobás.

Összegzés

A funkciók átgondolása még nem minden, tisztában kell lennünk a licenc, support, elérhetőség, biztonság, betanítás, fejleszthetőség kérdésével és még számos egyéb problémával.

Fontos figyelmeztetés! Soha ne váljon a funkciók listája kívánságlistává! Tartsuk magunkat a minimumhoz, de mindig gondoljunk a jövőre is! Ne fizessünk olyan funkcióért, amit soha nem fogunk használni, de ne is hagyjuk, hogy a CMS bekorlátozza lehetőségeinket!

gballa
2009. november 22.

Forrás: 10 Things To Consider When Choosing The Perfect CMS

Címkék: cms | tartalom | választás | web
 

© 1994-2011 Deepskeye Systems - info@deepskeye.hu