Scoor met uw website.

CMS voor bedrijfswebsite

Een CMS (Content Management Systeem) is een "web-applicatie die het mogelijk maakt dat mensen eenvoudig, zonder veel technische kennis documenten en gegevens op internet kunnen publiceren".

Naar mijn gevoel moet élke website een CMS hebben.

Inhoud moet kunnen aangepast worden op de plaats waar ze geproduceerd wordt. Elke extra stap (bv. webdesigner die inhoud moet aanpassen) zorgt voor een onoverkomelijke bottleneck. (Daarom ben ik bijvoorbeeld ook geen voorstander van een workflow systeem in zo'n CMS, waarbij er redacteuren, goedkeurders en schrijvers zijn.)

Er zijn op dit moment duizenden verschillende CMSen op de markt. Vergelijken kan op de website CMSmatrix.org.

Mijn grootste probleem met de meeste CMS software is dat ze volledig tegen het principe van user centered design in gaan. Ze vertrekken vanuit het CMS, en gooien daar, via een paar layouts en templates, een website over.

Onze filosofie is totaal omgekeerd. We bouwen eerst een website, gebaseerd op de noden van doelgroep en eigenaar. Daarna pas injecteren we de nodige CMS-functionaliteit.
Dit zorgt voor 'juist genoeg'. Niet teveel features (dat zorgt alleen voor verwarring, en verminderde bruikbaarheid), en ook niet te weinig.

Op dit moment denken we binnen Netlash hard na over het ideale CMS.

Welke eigenschappen heeft volgens jullie het ideale CMS?

Dit artikel gaat over: - .
CMS voor bedrijfswebsite werd geschreven door Bart op 21-03-2006 (852 dagen geleden) - Share!

Reacties:

Re: CMS voor bedrijfswebsite

Gravatar beeld van tijsVolgens mij is het ideale CMS de "core" van de website. Niet in de zin van wat je hierboven beschreef, maar wel een "dashboard" dat je volledige webaanwezigheid samenbrengt. Het up to date houden en beheren van je website is daar dus maar een deeltje van. Andere elementen zijn bijvoorbeeld de mogelijkheid om emailadressen/FTP accounts op je server te beheren, statistieken van je site, een e-marketing luik, een project management tool voor de website beheerders, ...

tijs , 21-03-2006 (852 dagen geleden)

 

Re: CMS voor bedrijfswebsite

Gravatar beeld van MichaelEen "project-planning" in de admin UI lijkt me onontbeerlijk. Alle andere toeters en bellen lijken me gewoon van het goede te veel.

Michael , 21-03-2006 (852 dagen geleden)

 

Re: CMS voor bedrijfswebsite

Gravatar beeld van ErlendWordpress kan nu niet echt doorgaan als CMS voor een bedrijf maar het biedt heel wat functies zonder de gebruik af te leiden - het laat me mijn ding doen zonder boe of ba.

CMS systemen zouden hieraan een voorbeeld moeten nemen. Plaats inhoud op de voorgrond en niet allerhande snufjes.

Erlend , 21-03-2006 (852 dagen geleden)

 

Re: CMS voor bedrijfswebsite

Gravatar beeld van Chris R.Het eerste goede CMS wat een klant kan gebruiken zonder eerst enkele uren te moeten ploeteren moet ik nog tegenkomen vrees ik.

De meeste CMS'en die ik gebruik zijn op maat gebouwd met een PHP framework (Cake of Seagull). Zo heb je toch de flexibiliteit van maatwerk maar de stabiliteit en snelheid van ontwikkeling van PHP in een framework. En eens je wat CMS versie hebt ontwikkeld is het modulair opbouwen simpel en kan je code gaan hergebruiken.

Chris R. , 21-03-2006 (851 dagen geleden)

 

Re: CMS voor bedrijfswebsite

Gravatar beeld van stuffieDenk dat het voor een CMS zeer belangrijk is dat deze voor zich spreekt. De gebruikers krijgen deze voorgeschoteld en met een minimale uitleg zouden ze moeten aan de slag kunnen...
En daarin moet ik Erlend gelijk geven. Wordpress spreekt voor zich en is zeer gebruiksvriendelijk.

stuffie , 22-03-2006 (851 dagen geleden)

 

Re: CMS voor bedrijfswebsite

Gravatar beeld van RoelEen paar dingetjes waar ik zo direct aan denk...

Technisch
* Een goed CMS spuwt zelf geen HTML uit, maar geeft ontwikkelaars de bouwstenen die je kan inpassen in je eigen templates
* Een goed CMS doet aan URL rewriting (properer URLs, permalinks)
* Een goed CMS doet ook aan caching zodat je databaseserver ontlast wordt en laat je toe om het CMS op een andere server te draaien dan de server die je website host (gegenereerde pagina's worden via FTP overgepompt na het updaten)
* Een goed CMS heeft een API zodat je er zelf nieuwe tooltjes voor kan maken en de data eruit kan halen om er andere dingen mee te doen
* Een goed CMS maakt automatisch backups

En voor content editors:
* Geen adminpagina's en complexe interfaces, maar gewoon 'edit in page'-dingen (zoals die nieuwe gratis wikidienst waarvan de naam me ontglipt).
* Minder vrijheid voor editors! Wysywig-edtors mogen het niet toestaan om visuele markup te gebruiken. Enkel structurele markup (headings, lijstjes, blockquotes zouden toegelaten mogen worden.
* Ingebouwde accessibility checks (geen alt-tekst? Sorry, dan komt de afbeelding er niet op etc.)

Roel , 22-03-2006 (851 dagen geleden)

 

Re: CMS voor bedrijfswebsite

Gravatar beeld van Marc PortierHm....,

Onafhankelijke partij zijn we wschl niet (gezien onze inmenging in het Daisy CMS: http://cocoondev.org/daisy/, voorwaar eens een CMS _niet_ in php én van Vlaamse bodem.)

Maar net door de betrokkenheid is mijn inkijk msch net zo boeiend:

Ik hoor in de post en de commentaren nogal wat warm en koud tegelijk blazen eerlijk gezegd, hier alvast mijn stokjes in het hoenderhok:


1. Een CMS is...

Met alle respect, maar de aangehaalde definitie deugt msch nog net voor een Web-CMS, maar dekt zeker niet de lading van wat allemaal onder CMS verstaan wordt. (1) Bij media bedrijven hebben ze bijvoorbeeld heel wat streaming of specifieke media content waar de aangehaalde opmerkingen over vlot en inline editeren zowiezo niet opgaan, (2) ons eigen Daisy CMS bv. wordt evengoed gebruikt om manuals of open source project-documentatie (http://cocoon.zones.apache.org/) in te beheren, (3) zowiezo is voor een beetje complexe website al heel snel een document != een pagina wat wil zeggen dat enerzijds 1 page is samengesteld uit verschillende 'documents' die afzonderlijk worden beheerd maar ook anderzijds 1 document best wel op verschillende pages kan terecht komen (microdocuments en hergebruik dus), en (4) voor een aantal hardcore document-stroom beheerders heeft een CMS in se niets met het web (en publiceren an sich) te maken, is het eerder een veredeld RDBMS waar men vrij ongestructureerde tekst in kan pleuren en weer opzoeken, versioneren, full text indexeren, en toch ook gestructureerde metadata aan kan koppelen...

enfin, je kiest maar, of begint alles nu al wat op het circusnummer met de chinese borden te lijken :-)


2. "eenvoudig MIJN ding doen"

Jammer genoeg merkt men zelden de contradictio in terminis... Enerzijds moet het CMS alles kant en klaar bevatten en dus eenvoudig bruikbaar/inzetbaar zijn voor zowel configurator, administrator, contenbeheerder als eindgebruiker.

Anderzijds moet het wel tot op elke punt en komma configureerbaar, instelbaar, verbergbaar, herdefineerbaar, negeerbaar, ...

The swiss army knive? Waw! 40 functies, maar welke moet ik nu gebruiken, en waar zit dat zaagje ook alweer? En hoe verwacht je nu dat ik weet wat ik met die schroevendraaier moet doen als ik eigenlijk alleen maar mijn nagels wil knippen?

Neem het van me aan: vertrekkend van een general purpose tool kun je heel gericht een optimaal product voor zowel contentbeheerder als eindgebruiker realiseren, én profiteren van alles wat de 'proven technologie' aan 80% herbruikbare functionaliteit levert. Verschiet alleen niet dat er om die laatste 20% te realiseren (waar 80% van de appreciatie van afhangt overigens) een aanzienlijk stuk HARD WERK overblijft. Je moet maar denken: 'iemand moet het doen' dus zorg alvast dat het niet de content-creator of website-gebruiker hoeft te zijn (maar dus de webintegrator)


Dat brengt ons meteen bij het


3. user centered design

trouwens: om daarin 100% de kans aan de specialisten te laten hebben we in Daisy effectief de publishing totaal losgekoppeld van de repository, tussenliggend een pure storage API met nette REST-based XML/HTTP interface (dus aanspreekbaar vanuit eender welke taal, shellscripted wget moet zelfs kunnen) met voor het gemak een Java API sausje erbovenop.

Daarnaast hebben we ook nog (optioneel) een standaard XML publishing engine ervoor gekoppeld (Apache Cocoon) die zich gedraagt als een wiki en waarvan layout en functionaliteit met behulp van standaard XSLT naar de hand kunnen gezet worden. Dat is de vereiste openheid ongetwijfeld, maar dan weer veel te ver-van-het-bed van de typische HTML/CSS/JS/Flash powerhouses, die al het voorgaande aanhoren als 'programmeren' (en dan een vies gezicht trekken) en dus zichzelf veroordelen tot de allerlaatste laag in het proces...

Enfin, de 'user' die CMS producenten in hun hoofd hebben is dus de web-integrator die WEL moet toegang hebben tot alle features in het CMS, maar die wordt dus ook verwacht te investeren in hoe hij die dingen naar zijn hand kan zetten.

(heeft mysql een user centered design? de apache httpd?)

Maar goed, alles kan wel beter natuurlijk, en ik ben er redelijk zeker van dat de Daisy community het inzicht, opmerkingen, use cases, practische ervaring en werklust van usability experts met open armen zal ontvangen ;-)


4. workflow...

Zoals je terecht aanhaalt wordt deze term al te vaak gebruikt om angstvallig:
- enerzijds mensen die net geresponsabiliseerd moeten worden bepaalde rechten te ontzeggen
- anderzijds de mensen die in vertrouwen moeten leren delegeren in de organizatie een vals gevoel van belangrijkheid te geven door hen tot bottleneck te bombarderen

Workflow wordt wat dat betreft teveel verward met 'toegangscontrole' en/of uitgehold tot 'authorizeren en goedkeuren'.

Let wel: in grote deployments met veel documenten en contentbeheerders (en echte content-rollen zoals vertalers, correctors, commentatoren, ...) maakt het toevoegen van flow-ondersteunende features echt wel zin.

Ik denk dan aan overzichtpagina's (op basis van dynamische content-queries) die aangeven wat er nog aan werk op je bord ligt, welke stukken content nog te kort zijn, welke vertalingen nog moeten gemaakt....

En aan document 'events' op het systeem die kunnen gebruikt worden om de aaandacht van belanghebbenden via email te trekken op een of ander, of zelfs een aantal automatische taken te triggeren.


5. ... alle toeters en bellen van het goede teveel....

Euh, zie de film 'Mozart', is dit het equivalent van "too many notes" ?

Dat een stuk software teveel features heeft lijkt me dus een vreemd uitgangspunt, ik heb liever dat iets zich gedraagt zoals de oude perl filosofie 'make easy things easy, make hard things possible'...

Zoals hoger aangehaald is alleen wat 'easy' zou moeten zijn voor iedereen weer wat anders in CMS land...


6. Het ideale CMS...

... zal iedereen voor zichzelf moeten uitmaken, op het eind van de rit is het een platform waar je als web-integrator gaat in investeren (zoals een van de comments aanhaalde: na een tijdje krijg je herbruikbare stukken/manieren van werken te pakken).

Wat dat betreft is het logisch me dunkt om iets te kiezen dat een aanzienlijk groeipad naar de toekomst heeft (zet dus even aan de kant dat je al die toeters en bellen niet meteen nodig hebt of zelfs maar begrijpt).

Let ook op standaards-compliance: zowiezo zul je heel wat arbitraire dinges moeten leren die aan het CMS zelf gekoppeld zijn, maar als overwegend de behandeling van de content-stromen terug kan vallen op web-standaarden waar je elders ook mee weg kunt, dan minimaliseer je de verloren kost mocht je ooit toch van platform moeten/willen veranderen.

En helemaal gebiassed: kies voor een open source systeem, zo worden er niet alleen nooit details voor je verborgen, mits het vinden van de energie om het effectief op te brengen: je krijgt ook de kans mee te sturen, te verbeteren, te fixen wat moet beter kunnen...

En tenslotte, vergeet vooral niet iets te kiezen. :-) Ga er gerust van uit dat je je keuze zonder de minimale inhoudelijke investering nooit volledig gaat kunnen apprecieren (of jammerlijk beklagen)...

Het is weer eens zoals stijldansen en bungee springen: van aan de kant staan kijken is écht niet hetzelfde :-)


Ik wens je alvast veel succes bij de zoektocht, ik lees zeker geboeid na wat je nog allemaal ontdekt...

-marc=
(die aan het kleine textarea-schermpje begint te vermoeden dat hij de grenzen van het user centered design ervan aan het aftasten is :-))

Marc Portier , 23-03-2006 (850 dagen geleden)

 

Re: CMS voor bedrijfswebsite

Gravatar beeld van Roel StormsVolgens mij moet je niet de layout van een site in de CMS proberen te krijgen zoals ze in bv PHPBB doen met hun .tpl files maar moet je de CMS in de template krijgen waardoor het volgens mij gemakkelijker is een CMS te maken (geen template files) en ook gemakkelijker om er een layout in te krijgen. Het kost echter meer werk om het op deze manier te doen. Je kan ook een standaard layout hebben en er images in veranderen maar voor een goed bedrijf is dit waardeloos.

Roel Storms , 14-08-2006 (706 dagen geleden)

 

Re: CMS voor bedrijfswebsite

Gravatar beeld van P.HamersZonder de nadruk te leggen op de technische details zou een goed CMS voor zich moeten spreken.Dat wil zegen als ik medewerker A zonder enige webdesignkennis zoiets voorschotel moet hij in staat zijn om na een uurtje rondkijken enig content toe te voegen.Met andere woorden het moet voor zichzelf spreken.Helaas hebben sommige systemen een wel erg stijle leercurve.Technisch gezien geweldig maar praktisch eigenlijk waadeloos daar ze enkel " bediend" kunnen worden door techneuten.Dus gebruikersvriendelijkheid staat voorop naast dat het zaakje goed en overzichtelijk en veilig gecodeerd moet zijn.

P.Hamers , 07-10-2006 (652 dagen geleden)

 

Re: CMS voor bedrijfswebsite

Gravatar beeld van JohanAllereerst moet je natuurlijk een provider hebben die CMS ondersteunt. Onze provider ondersteunt bijvoorbeeld geen CMS, wat zich toch wel laat gevoelen als een serieuze aderlating.

Ik denk weliswaar dat de ideale CMS moet toelaten om makkelijk concent online te plaatsen zonder afbraak te doen aan het design van de pagina. Het oog wil ook wat, nietwaar? ;)

Johan , 18-03-2008 (124 dagen geleden)

 

Reageer:

Naam
Jouw website adres
Jouw e-mail adres
Titel
Reactie
Ben jij een mens?

Hoeveel is zeven plus twee (in cijfers) ?

Scoor met uw website.
© Netlash Webdesign en Grafisch Ontwerp