Content management is still an unsolved problem
12

Content management is still an unsolved problem

Content management remains an unsolved problem. Untold billions of dollars (and hours) have been spent building commercial, open source, and custom content management systems since the first Web page was pushed to a Web server using FTP, and yet they all still suck.

Former Salon editor Scott Rosenberg ruminates on the fact that TechCrunch founder Michael Arrington lists frustration with technology as one of the reasons he’s happy to be selling TechCrunch to AOL. That doesn’t surprise me.

I’ve worked on many content management projects in the past, and to be honest, I’d be perfectly happy if I never worked on another one again. For some reason, finding an adequate balance between usability, flexibility, and performance is nearly impossible.

When building content management systems there are two options. You can base your work on an existing system which is just inflexible enough to make your life a living hell on a daily basis, or you can build something from scratch and spend a large amount of time repeatedly reinventing the wheel. Frameworks like Rails and Django make it a lot easier to reinvent the wheel, but you still can’t escape the fact that you’re spending time creating forms that enable users to enter content that will be inserted in a database so that it can be presented on a Web page.

That’s why it’s hard to find competent engineers to work on content management systems for publishing companies.

12 thoughts on “Content management is still an unsolved problem

  1. So I guess that means we’re waiting for the brilliant engineer who can figure out what a CMS would look like/be that did something different from “providing forms that enable users to enter content that will be inserted in a database so that it can be presented on a Web page.”

    I mean, lord knows what that would be. But we’re doing it the same way we’ve done it for nigh on 15 years. Presumably someone will come up with something better someday!

    FWIW I am pretty happy as a user these days with WordPress. Really, it does what I need and it keeps getting better.

  2. A timely post for me, having just spent a week trying to get Drupal to display some content in the same way my hand-written PHP script has been doing for ages.

  3. Hanan’s comment rings true in my experience as well: content management is not an intrinsically hard problem, as the tons of people using WordPress, Plone, Google Sites, etc. can attest. The problems come from the combination of business users wanting to avoid the technical details related to web publishing while maintaining very high goals for both flexibility and constraints. This essentially consists of teaching a computer your business processes, which are rarely codified at that level of detail and rigidity.

    A related problem is usually that people have bought into the enterprise mentality that software is, and should be, hard to write; this usually leads to people trying to come up with systems which are incredibly flexible, making configuration effectively programming in a more restrictive environment. I’ve rarely seen that be as successful as using a more nimble platform and simply having a developer make changes as the business adjusts – everyone seems to need that kind of absolute flexibility eventually.

  4. (Disclosure: Lead Developer for WordPress, and web publishing consultant).

    The problems come from the combination of business users wanting to avoid the technical details related to web publishing while maintaining very high goals for both flexibility and constraints.

    Well said. Business users want the best of both worlds. As a result, they’re much harder to please than a “regular Jane” user who will gladly live within constraints and who just wants something easy to use. The challenge for us is to make the software conceptually “go away” for those regular users, but transform, adapt and grow for the more demanding users. With WordPress, we try and dogfood as much as possible; plugins and themes get to interact with the core the same way that the core interacts with itself. That way, if something in core isn’t doing it for you, you can programmatically remove it and replace it with something that does. That’s been a big part of our success — empowering plugins to do more than just minor tweaks. It almost guarantees that you’re better off modifying WordPress with a plugin than coding a CMS from scratch. Mike’s quote makes it sound like a big part of the issue was finding talented people to work on it. Unfortunately for independent publishers, most of the people at the top of the web publishing software consulting business are consultants and aren’t looking for a full time employer.

  5. The problem is largely one of perception; Web site owners believe that there should be this holy grail of software that will automagically run their Web sites for them to their exact specifications, and if the package being used doesn’t do exactly what they need, it’s the developer’s fault or the software’s fault. This impulse stems from a misunderstanding of what content management really is (a software development endeavor), and more generally from a misunderstanding of what software development is (an iterative process in which one must occasionally utilize someone else’s products and, in some cases, repeatedly re-invent the wheel). None of this is unique to CMS.

  6. I think what’s unique about content management is that the end users can envision what they want to a greater extent than they can with other software and for a variety of reasons believe achieving that result is within their power and more importantly, within their budget.

  7. The reason CMS systems have so much trouble is that they are constantly expected to latch on new features based on what happens to be hot at the time. These new requirements are often in conflict with the original design and the result can be messy.

    So building a CMS system is not ‘nearly impossible’ if you freeze your requirements, but that’s not the world we live in.

  8. @rafe:

    Content management remains an unsolved problem. Untold billions of dollars (and hours) have been spent building commercial, open source, and custom content management systems since the first Web page was pushed to a Web server using FTP, and yet they all still suck.

    true, sad, and barely shy of criminal, mainly because for all these attempts no one seems to advance the general state of play, and economically thats insoluble.

    @ScottRosenberg:

    So I guess that means we’re waiting for the brilliant engineer who can figure out what a CMS would look like/be that did something different from “providing forms that enable users to enter content that will be inserted in a database so that it can be presented on a Web page.”

    i have a similar sense, that the utility of heavily templated pages with purely linear content inside is diminishing. cms is an unsolved problem because “everyone” has been “solving” it with the same approach.

    i havent been able to find the counter-example i’m looking for, which was a composition based kind of hyper-cardy cms; i cant remember what they called the unit of composition, blocks pages cards, who knows, but my google fu is having trouble cutting through the colossal amounts of results i’m getting back.

    my prognostication– one i’m actively, slowly working towards– is that the notion of CMS will become a non-entity as we adapt more transparent easier to manage programming environments. a lot of words are spent in the comments talking about business users wanting to avoid technical complexity, yet i think the only real answer of any lasting value is the technical one, a complete departure from this dual-worlds mentality of code and program/site being separate. in the entirely opposite direction, we stop shielding “users” from complexity and embrace everyone as a developer. expose the full stack of the page and the framework, and provide usable tools for everyone to be able to to understand and manage whatever cost-complexity the web stack has associated with it. relentless optimization to reduce the cost-complexity of the stack, tools to gracefully expose only as much of the stack as is currently of interest, and embracing every “user” as instead a form of developer is the only way to stop “bridging the gap”, and to start building a real connection.

    this innovation will almost certainly not evolve from CMS systems, but rather from left field systems and programming environment “research”. live programming environments like kojo, logo, and sugar are examples.

    @Rafe: last week was a fantastic collection of posts, thanks for drawing marshaling the nebulous fluid things floating about my head into such concise and elegant posts. it is truly and sincerely appreciated, and your ability to distill an image of these complex and many-faced problems is quite commendable.

    also, reposting, presently on http://thefowle.livejournal.com/449114.html

  9. “people have bought into the enterprise mentality that software is, and should be, hard to write; this usually leads to people trying to come up with systems which are incredibly flexible, making configuration effectively programming in a more restrictive environment”

    Great comment – I find this attitude pervasive in the industry and the refusal to accept simple answers to simple questions infuriating. There is an attitude that “real engineering” involves lots of complicated moving parts, and even among people who’ve been burned by complicated systems and will pan them to you, there’s a willingness to believe that next time some new complicated system is going to work out great.

    CMS is a solved problem – if what you want is a blog, or a Wiki, or a bunch of web pages on a site. Which is what most people really want, they just believe that they want something else.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>