Door tijs 21/03/06 (5 jaren geleden)
Re: CMS voor bedrijfswebsite

Volgens 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, ...

 

Door Michael 21/03/06 (5 jaren geleden)
Re: CMS voor bedrijfswebsite

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

 

Door Erlend 21/03/06 (5 jaren geleden)
Re: CMS voor bedrijfswebsite

Wordpress 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.

 

Door Chris R. 21/03/06 (5 jaren geleden)
Re: CMS voor bedrijfswebsite

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.

 

Door stuffie 22/03/06 (5 jaren geleden)
Re: CMS voor bedrijfswebsite

Denk 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.

 

Door Roel 22/03/06 (5 jaren geleden)
Re: CMS voor bedrijfswebsite

Een 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.)

 

Door Marc Portier 23/03/06 (5 jaren geleden)
Re: CMS voor bedrijfswebsite

Hm....,

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 :-))

 

Door Roel Storms 14/08/06 (5 jaren geleden)
Re: CMS voor bedrijfswebsite

Volgens 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.

 

Door P.Hamers 07/10/06 (5 jaren geleden)
Re: CMS voor bedrijfswebsite

Zonder 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.

 

Door Johan 18/03/08 (3 jaren geleden)
Re: CMS voor bedrijfswebsite

Allereerst 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? ;)

 

Door Peter 13/02/10 (1 jaar geleden)
re: CMS voor bedrijfswebsite

Wie gebruikt de CMS?
Dat is toch de klant niet?
Een CMS moet gebruiksvriendelijk en toegankelijk voor het blondje dat achter de helpdesk zit van bedrijf X.
Sorry voor de blondjes, ze mogen er ook zijn :-)

Vandaar ik nooit zal kiezen voor Drupal of Joomla! Probeer dat blondje maar is uit te leggen hoe ze een pagina structuur moet onderhouden! Ja, na 1 week cursus... en dan nog.

Ik geloof ook niet dat elke website een CMS moet hebben...
Veel klanten willen het gewoon super simple... zonder CMS, updaten via FTP! Ja echt, zoals vroeger op de oude manier.

En als ik dan voor een CMS kies, dan kies ik voor CMS made Simple : Openscourse, eenvoudig en lage instapdrempel. En je kan er alles mee... van eenvoudige websites, blogs tot ingewikkelde product website..

 

Door Siteseaing seo 24/03/10 (1 jaar geleden)
re: CMS voor bedrijfswebsite

In onze ogen dient een bedrijf niet noodzakelijk met een CMS systeem te werken om een degelijke corporate website te hebben. Tenzij het gaat om een heel productassortiment dat schuilgaat achter de website en waaraan een database dient gekoppeld te worden via een e-commercesysteem. In alle andere gevallen lijkt het ons meer aangewezen om gewoon content te schrijven zonder die ergens aan te koppelen.

 

Door korting-reduction.be 08/08/10 (1 jaar geleden)
re: CMS voor bedrijfswebsite

CMS is mijn ogen alvast geen absolute noodzaak. Veel websites van KMO's zijn ook te klein, waardoor het in verhouding geen moeite loont om er een CMS systeem achter te steken en je beter puur in html kan werken.

 

Door mlitn 10/08/10 (1 jaar geleden)
re: CMS voor bedrijfswebsite

@korting-reduction.be:
Hier ga ik je even tegenspreken. Een goed CMS biedt voordelen voor zowel kleine als grote websites.
Voor complexe websites bestaat er uiteraard geen twijfel dat een CMS een noodzaak is.
Is het inderdaad een kleine standaard-site, dan nog is een CMS een verstandige keuze: op deze manier kan de klant - mocht het ooit nodig zijn - toch zelf de nodige aanpassingen doen, maar ook de ontwikkelingstijd & het hierbij nodige budget zullen aanzienlijk scherper zijn. Gezien het toch een eenvoudige website betreft kan de slice meteen geïntegreerd worden in het CMS. Het is dus niet langer nodig om het x-aantal pagina's manueel aan te maken.