Curious to see what effect the 'paid for blogging' program is having on Marqui's search positioning, I googled the word "marqui" and discovered that my blog is ranked number 4 in the results (as of this writing)... ahead of the official marqui.com website at number 5! Hee hee. Only the internetnews.com article and the announcements from Marc Canter placed above me in that search. So there, ordinary bloggers do have 'influence' after all. Oh, the ego-puffery! (nb: interestingly, the Wikipedia page for "product placement" came in at number 7, even though as of this writing it doesn't even mention Marqui! Perhaps it was previously mentioned but has since been edited out...)
So let's talk Content Management Systems. Shorewalker has a fantastic article entitled Web content management systems: find the appropriate solution, which pretty much sums up my feelings about the subject. This is the executive summary:
"Web content management's dirtiest secret is that most organisations not only don't need most CMS bells and whistles, but should actively avoid them."
The article goes on to give a history of CMS. It gives special attention to Philip Greenspun's ArsDigita Community System (ACS) from the late 90's - "...for a time the world's most competent content management system". Vignette is singled out as an example of a high-end CMS that largely failed to live up to user expectations:
"Whatever Vignette's merits, there was clearly a gap between what buyers expected and what the product delivered. And other vendors of six-digit price-tag Web content management systems seemed to attract similar angst."
Then comes the point that I made in my recent post Automation and the Real Costs of CMS's. It's worth repeating again, in Shorewalker's words this time:
"...the real cost isn't in the box of software. It's in the cheques you write to the people who install, adapt and maintain the software. And it's in the business opportunities you miss out on when badly-designed software makes Web site updates too hard - and users simply don't change the site."
With a CMS system, you don't want to be spending lots of money for the "development overhead" (as Shorewalker terms it). Keep it simple, and cheap. Shorewalker suggests Perl or PHP scripts, blogging packages such as Movable Type, or other low cost solutions. You may end up with a "patchwork quilt" of a system, but Shorewalker thinks this is commonplace and best practice. He says that "Web content can be so many things" and therefore no one generic CMS can cater to all business requirements.
In the words of Tony Byrne from CMSWatch site, content management is "highly situational". Byrne explains:
"Your content is unique, and your management requirements will vary."
I can certainly attest to that, having been involved with implementing and administering numerous CMS's over the years. Every situation was different and customization has always been required.
The Shorewalker article is a terrific analysis of the CMS marketplace and I totally agree with its conclusion: most companies are better off with simple and cheap content management solutions, rather than high-end expensive systems.
I suppose you're wondering where Marqui fits into this? Well to be honest I still don't know. The bloggers participating in this program were fed some high-level technical details about the Marqui product this week. For example it seems that content is saved onto Marqui's server, then static HTML files are FTP'ed to the client's host server. Another example: "Our web service engine will also allow full integration with any third party application". Right... but I'm still not clear how much development effort is required to set-up and customize Marqui.
OK, Marqui doesn't appear to be an overly complex and expensive CMS vendor like Vignette. But look at it like this: I'm an IT person who is 'once bitten, twice shy' with Content Management Systems - and I bet there are many more like me. We're kind of like the Generation X of Content Management - we're cynical and disillusioned with CMS's. We want to just Go Grunge - install Wordpress or MT, develop some PHP scripts, and wear flannel shirts (ok, strike that last bit). Basically, we want cheap and simple. And that my friends would be CMS Nirvana [groan, lame Gen X joke I know].
]]>I wrote a response to this and David Walker's piece, but can't get trackback to work with your site....
Anyway, it's at http://weblog.writableweb.com/archives/2004/12/cms-without-vignette/
I worked on one for 3 years - one that was 5 years old when I got there, and slowly, but surely, helped shape it (with others) to a more formal application - the fact that it was ad-hoc at that point was crippling, not empowering, and in fact, even when I left I was introducing large, new concepts. Before that, I worked on a cobbled together mess of scripts which could be loosely defined as a CMS - both for large, well-known companies.
This company last year did a million dollars gross a DAY in november and december. I'd like to decline giving out the name, but they're a large musical instrument retailer.
My intent isn't to brag, but to point out that there is a time where ad-hoc development stops being productive - this I would like to assert, is the time when maintenance becomes more cumbersome than new features - as maintenance is a large part of any software project, this approaches rather quickly and due to it's nature, without warning.
If someone out there is managing an Web/IT project that incorporates a CMS - please, for the love of your talented programmers, know when rewriting is appropriate. Plan for it ahead of time and stick to the plan - set a firm date to start development and do not set a date for release, but shove a few developers permanently on to that project.
Let them pontificate long on designs, write prototypes, and "get it right the first time", the impossible goal... If you have a good team, you will have something much better (although rarely "right") as a result - make sure you use your most disgruntled programmers, the ones who are intolerant of the current situation, as they will have the most drive to fix the glaring issues.
The antithesis to this is "top-down" development, which never solves anything the right way, just merely covers up the ugly bits. And if you try and shove a complex program into a complex framework, you will have this problem. A simple framework should allow complex designs by combining simple parts to form that complexity - this is called "bottom up" development and works rather well - your lower-level pieces become more mature, and the rest of your application benefits from that indirectly, while the top is easier to replace with less overall impact.
]]>