Aké a ako CMS vyberať

Na začiatok zasa musím pripomenúť, že nejdem radiť ani rozdávať tipy. Nezameriavam sa na široký rozhľad v ponuke rôznych systémov pre správu obsahu avšak už som v stave, keď pohľadom na rozhranie takéhoto systému dokážem aspoň zhruba ohodnotiť jeho prepracovanosť.

V predošlom seriáli som spomenul, že medzi ľuďmi panuje predstava o systéme pre správu obsahu internetovej prezentácie ako webovej aplikácie. Musím podotknúť, že proklamovaná výhoda „publikovania odkiaľkoľvek“ nemusí byť vždy zásadnou podmienkou.
Pozorovaním jednotlivých CMS ich musím rozdeliť do dvoch skupín:
– správa obsahu „webzine“,
– správa obsahu webového sídla.
Webzine by som charakterizoval ako „priebežný“ typ média, kde sa podobne ako u weblogov proste pridávajú články a úvodná stránka je viacmenej kompilát vo forme výkladnej skrine plnej najčerstvejšieho tovaru – príspevkov, článkov, informácií.
Pre webzine je teda potrebný zodpovedajúci systém pre správu jeho obsahu ale v zjednodušení je to všetko prakticky o tej istej štruktúre skladajúcej sa z primitívnej jednotky – príspevok. Samotný príspevok je opäť primitívum s minimálne dvomi podstatnými zložkami – nadpis a text. Zvyšné ošperkovanie je už prakticky zvyšovaním komfortu autorov a čitateľov.
Aj keď som ešte nepovedal nič o systémoch pre webové sídla, vyššie spomenuté CMS pre webzine nie sú príliš sofistikované a stavajú na pomerne jednoduchej nemennej schéme publikovania navzájom si podobných stránok.
Praktickými príkladmi takýchto systémov sú všetky klony PHPnuke, PHP RS a aj väčšina systémov komerčne ponúkaných českými a slovenskými firmami. Ich úspešnosť sa teda rozvíja hlavne nad webzinovo organizovanými stránkami a akékoľvek pokusy nasadzovať tieto systémy spočívajú v ich prešívaní kus od kusu pre každého klienta zvlášť.
Ako majiteľ iného typu webového sídla z komerčného priestoru som už niekoľkokrát prešiel analýzou potrieb a stanovil hrubé požiadavky na systém správy obsahu. Vždy som narazil na niekoľko bodov, ktoré čiastočne vylučovali aj pomerne kvalitné komerčné CMS:
– systém správy obsahu proste musí mať dostatočnú dokumentáciu k rozhraniu pre nezávislé programovanie vstupov, výstupov a formulárov – napr. formou pluginov,
– nutnosťou je veľmi komfortný návrhár štruktúry dát, formulárov a rozhrania pre redaktorov a tu musím poznamenať, že naozaj kvalitný sa ako webová aplikácia skôr nedá ako dá vytvoriť, (tento systém by som nazval editor CMS – niečo na prispôsobovanie jeho samotného),
– voľne konfigurovateľné rozhranie pre „absolútnych tupcov“, kde je možnosť z neho odstrániť všetky viditeľné prejavy jeho „neaktívnych“ častí a ponechanie toho najnutnejšieho (osvedčuje sa to najmä ak formuláre sú vo vyšších úrovniach už plné volieb, prepínačov, polí…),
Asi by som našiel ďaleko viac požiadaviek.
Už som spomenul, že oproti webzine systémom tie ostatné rozširujú svoje požiadavky na rôzny typ a formu dát a to nielen ich štruktúrou ale aj spôsobom ich vznikania a potrebami k ich udržovaniu. Tu už proste nepostačuje jednotný formulár s pár textovými poliami vytvorenými ako TEXTAREA. Často je totiž v rámci nejakej časti dát potrebné kombinovať udržovanie dát interaktívnou editáciou ale hneď pod ňou nasleduje automaticky generovaný zoznam z úplne inej časti stránky. Dokonca časť dát prichádza do systému ako výsledok práce iných IT systémov a iba sa automaticky „importujú“.
Požiadavka editovania „šablón“ vzhľadu je častým atribútom webzinových CMS a výkon tejto časti systému sa považuje za nosný prvok. Aj keď nepopieram význam dobre zvládnutej editácie šablón vzhľadu, musím nesúhlasiť.
Vzhľad je totiž vytváraný nezávisle na správe dát a počas existencie webového sídla je tak trochu mimo celého tohto diania. Preto nepožadujem na systéme správy obsahu akékoľvek prepojenie s konkrétnym prepájaním sa s konečným vzhľadom sídla.
Celé webové sídlo by som teda rozdelil na niekoľko častí:
– vzhľad sídla; súbor prvkov ako grafický design, layout, šablóny…
– dátový sklad; sem načierajú dva ďalšie komponenty,
– zobrazovací motor prezentácie; tento stroj generuje samotné stránky s použitím šablón vzhľadu naplnené dátami pripravenými systémom správy obsahu. Naozaj kvalitný „motor“ by mal vedieť pracovať s akýmikoľvek podkladmi a byť „subtílny“,
– správa obsahu; v tomto smere vie prispôsobiť požiadavkam formu dát pre zobrazovací motor,
Oddelenie v tomto uhle pohľadu požadujem z rôznych dôvodov – praktické, bezpečnostné…
Možno som nenapísal nič nové ani pozoruhodné ale vypichol by som ešte raz myšlienku návrhára. Tu vidím naozaj slabinu všetkých bežne dostupných systémov. Zrejme je nevyhovujúce poskytovať „iba“ možnosť rozširovať administrátorom systému počet položiek v položke „článok“ o ja neviem rozklikávatko s názvami produktov či anotáciou článku.
V bežnom „webzinovom“ CMS sú ešte veľmi propagované vlastnosti, ktoré môžeme shrnúť do pojmu workflow. Podľa všetkého sa vychádza z práce redakcie denníka – autor napíše text ale už nemá práva ho publikovať. To za neho robí šéfredaktor. Viacmenej v podobnej schéme funguje väčšina takýchto systémov.
Tok dát však môže vybočuje z nich vybočiť a to už napríklad vsunutím externého korektora textu (skúste korigovať text v TEXTAREA). Viem si ale vymyslieť omnoho zložitejšie postupy.
Len návrh workflow prostredníctvom webového rozhrania si viem veľmi ťažko predstaviť. Pripomína mi to skôr prácu s obláčikmi, šípkami do diagramov ako klikanie do FORM.
Pomerne úzko s workflow súvisí aj tok dát. Vyššie som písal, že okrem mechanického ďatľovania do rozhrania CMS by sa mohli dáta do neho alebo cezeň dostávať z iných systémov. Tu je tiež nutné okrem programovania „pluginov“ pre daný formát aj navrhovať ďalšie parametre ich prísunu a pravidlá pre spracovanie. Občas proste dáta prichádzajú pravideľne a „len“ sa aktualizujú. Bohužiaľ sa líšia napríklad požiadavky na zachovanie sa systému pokiaľ proste dáta „neprídu“ alebo majú iný rozsah, hodnoty a pod.
Práve tieto aspekty si uvedomujú aj autori jadier CMS, ktoré prvoplánovo využívajú ako prostriedky pre webzine. Časť práce totiž majú za sebou a pokiaľ programovali efektívne vedia pomerne kvalitne dopracovať aspoň časť systému správy obsahu firemného sídla. To však vyžaduje pomerne rozsiahlu analýzu prostredia u klienta.
Na klientovi je už iba zvážiť, čo je vlastne vhodnejšie… ale toto už patrí do obchodných úvah s troškou marketingu. Určite sa ľahšie rokuje s klientom, ktorý proste do veci nevidí. Vo svojej praxi sa totiž v drvivej väčšine stretávam so situáciou, keď dodávateľ pri predstavovaní systému takticky zamlčí detaily. Verklíkovou odpoveďou je vždy „áno, vie to“. Rozlišuje sa len v intonácií ;-) Po uzatvorení zmluvy nastáva deň implementácie systému a dochádza k prvým menším nezrovnalostiam (to ľahko dorobíme, zavolám do centrály a pošlú update), faktickým nedostatkom (zrejme ste si to nevšimli v špecifikácií prezentovanej obchodníkmi) až nevhodnosti produktu (panebože, tie programovacie práce „to dorobíme“ stoja štyrikrát viac ako samotný systém!).
Príjemný deň, pretože som úlohu danú titulkom nesplnil ;-)

Zhrnutie článkov na tému CMS do 21. mája 2004:

• 30. apríl 2004: spravodaj: Fiktívny CMS by mal vedieť viac
• 4. máj 2004: spravodaj: CMS I.: medzery v texte
• 5. máj 2004: spravodaj: CMS 2.: tri typy medzier z jedinej I.
• 6. máj 2004: spravodaj: CMS 2.: tri typy medzier z jedinej II.
• 7. máj 2004: spravodaj: CMS 2.: tri typy medzier z jedinej III.
• 12. máj 2004: spravodaj: CMS 3.: Interpunkčné znamienka I.
• 13. máj 2004: spravodaj: CMS 3.: Interpunkčné znamienka II.
• 14. máj 2004: spravodaj: CMS 4.: Verzálky na koniec
• 20. máj 2004: spravodaj: Aké a ako CMS vyberať