Gadgetopia

I’ve been a judge of the Packt Open Source Content Management Awards ever since they started the program.  Packt has been wonderful about it, and I’ve really enjoyed doing it.  It’s given me the opportunity to look at a lot of systems I wouldn’t otherwise find the time to play with, and I’ve discovered some real gems over the years (CMS Made Simple, ModX, Silverstripe, etc.)

But, 2009 was my last year.  If they ask me in 2010, I will decline.  Packt has been great, but I’m starting to have a problem with the entire thing.  Not their awards in particular, but with this whole concept of “the best CMS.”

I get asked quite frequently what the “best” CMS is.  Over the years, my answer has devolved into “the best for what?”

Here’s my issue: without concrete evaluation criteria, it’s not possible to say any particular CMS is “the best” anymore.

All content management systems have sweet spots – those requirements for which they were designed.  You need a blog?  WordPress is arguably the best.  You need a LAMP system with a strong hierarchical content model and extreme extensibility?  eZ publish will do well.  You need a platform on which to manage some content but really just serve as a framework for your own app development?  Consider Drupal.

In all those cases, I was matching a CMS with some requirements.  This is the only way you can ever approach a question like “what is the best CMS?” 

Without some requirements, that question is like asking, “is that man standing to the right?”  Well…to the right of what?  Something is only “right” if something else is “left.”  Without “left,” “right” doesn’t mean anything.  Similarly, without some standard criteria or hypothetical situation on which to judge something, any concept of “the best” is pointless.

Tony Byrne, over at CMS Watch, has echoed the same thing:

There is no “best” web content management system. […] The best CMS for you is the one that best matches your needs — your budget, scope, and type of project — in short, the one that fits best for your web publishing and interaction scenarios.

CMS Watch does it right – when they evaluate a CMS, they have 12 different scenarios to consider, and they evaluate how will the CMS would do for all 12.  Scenarios like:

• Corporate Brochure
• Enterprise Intranet
• Ultra-Large Single Site
• Microsites

Even just with simple labels like this, you’re in a much better position to choose what CMS fits.  A CMS that does well with a “corporate brochure” may fail spectacularly for an “enterprise intranet.”

WordPress won the Packt Awards this year for “Best Overall CMS” – the category I was judging in.  There was some grumbling about this – I was not thrilled with the results.  (In searching for that post, I found this one from two years ago when WordPress won “Best Social Networking CMS,” and I was struggling with that too.)

My chief problem with it was that I didn’t think WordPress was a full-blown CMS.  But, let’s think about that statement for a second – my feelings about whether or not WordPress can be called a “CMS” like Drupal is called a “CMS” is entirely dependent on what you’re asking it to do.  If you want a straight-up blog, then WordPress is as much a CMS (more, even) than anything out there.  If you need a product catalog…not so much.

So, this is my position – just asking for ‘the best” CMS is a fallacy.  If you’re asking for a vague concept of “the best,” you need to have some set of criteria or scenario in mind to anchor your choice.  Without that, no answer really means anything.

WhiteHouse.gov Goes Drupal : Interesting.

WhiteHouse.gov has gone Drupal. After months of planning, says an Obama Administration source, the White House has ditched the proprietary content management system that had been in place since the days of the Bush Administration in favor of the latest version of the open-source Drupal software

Can Java CMS match the PHP ones? : This is a very interesting post from a Java development community.  You can sum it up in this excerpt:

Maybe while the Java world was engaged in talking of high end, super techie stuff, with the words ‘enterprise’, ‘transactions’ and ‘SOA ‘embedded in every sentence, the PHP guys actually went out and created a lot of simple yet very useful software.

Introducing The Dynamic Data Store : EPiServer is shipping a handy new feature in CMS 6 which provides for data storage of…whatever.

[…] storing data in a database using Entity Framework or NHibernate requires you to design and compile a class when developing your application. This works really well when you know the shape or structure of your data at compile time. EPiServer CMS has a few features where the shape or structure of the data isn’t actually known until runtime.

The Dynamic Data Store is very key-value-ish, like Amazon’s SimpleDB or Google’s BigTable.  It gives you a simple place to store variably-shaped data when building your apps, without having to roll new tables or build ORMs.  There are so many times when you just want to store some random piece of data, and the Dynamic Data Store gives you a simple way to do that, and get it back out, strongly-typed, even.

The comments on this blog post are interesting – there are a lot of people expressing reservations that developers will mis-use it, which is understandable.  In everything, it’s all in the execution.  Anything can be mis-used, if you’re careless.

Allan has written a handy example to store ratings of a certain page.  He wrote a simple “Rating” class, which has a property for the page to which it’s applied.  Then he wrote a couple extension methods so you can get this information directly off EPiServer’s core content object.  In the end, he’s built a feature that looks as though it’s built right into EPiServer and has an infrastructure behind it, when really it consists of nothing but a half-dozen methods and perhaps 20 lines of code.

Gilbane Boston 2009 - Content Management Conference: I managed to wrangle a speaking slot at Gilbane Boston on December 1-3.  I’m going to be giving a shortened version of my Chicago talk entitled “Content Types: The Building Blocks of Your Content Model.”

COPE: Create Once, Publish Everywhere : Here’s an interesting article from NPR on what they call COPE – Create Once, Publish Everywhere.

COPE is the key difference between content management systems and web publishing tools, although these terms are often used interchangeably in our industry. The goal of any CMS should be to gather enough information to present the content on any platform, in any presentation, at any time.

What they’re talking about is storing content in such a way that the final presentation layer is unimportant.  In fact, they differentiate their “CMS” from what they call “WPT” — “Web Publishing Tools.”

This is important – page through the SlideShare presentation on the page.  In it, they show the editing interface where they put together the story, and they show all the different forms which came out of it, from Web to iPhone.  Great examples of presentation-free content management.

In reading this, I was really stuck how similar it is to the post I made this spring called Beyond Web Centricity in Content Management.  I said:

[…] sometimes we (as Web developers) get too caught up in the “Web” part. Sometimes we get very Web-centric about our content, when we really should be looking at content from a completely presentation-free perspective.

The NPR article includes an extensive graphic explaining their different layers of their storage system and where items are cached along the pipeline.

Why do WYSIWYG editors suck at invisible, surrounding elements?

I’m evaluating a design right now to quote a content management implementation.  One of the elements involved arbitrarily shading an area of the page.  The HTML jockey in me says, “Just wrap that section in a DIV…”  But the CMS integrator in me knows that the client is going to be doing this in a WYSIWYG editor, and how do you do this?

One of the problems is that it’s a somewhat abstract thing for content editors to understand – they don’t know anything about HTML and tags, so they can’t grasp the idea of some invisible, surrounding…thing, around their other content.

WYSIWYG editors don’t help.  Try to find easy functionality for surrounding other content in a div and then – and here’s the kicker — putting a class or an ID on that DIV.

If you end up finding or configuring this, then you have to explain it to the editors.  It becomes a training issue, because it’s much tougher to understand than just, “Write some text there…” or “Put an image there…”

So, what ends up happening?  Tables, baby.  A single-row, single-column, single-cell table with a class on it.  WYSIWYG editors have all sorts of functionality for tables, and they show them visually very well in a way content editors understand.

A little sad, though.

Rant over.

Intranet in the cloud : A nice rant about how more companies should host their intranets externally, rather than inside their own infrastructure.

I was recently pressed on the subject of a “hosted intranet” and why an organization shouldn’t outsource their intranet to “the cloud.” God forbid we let professionals who know what they’re doing maintain our second-rate, after-though, cost-center of an intranet!

It is baffling to me that the intranet isn’t hosted externally for more organizations. Well, I’m well versed with clueless executives with knee-jerk reactions around “security”, privacy, and “the way things have always been done” but I guess I’m naïve to have faith that more would start to embrace the 21st century. If these dolts can Facebook then surely there’s hope, right?

At first glance, this fits with my experience.  Intranets should be developed under the auspices of Business Communications, rather than IT.  Blend does continuing technical maintenance of two large-ish intranets, and in both cases, we don’t work directly under IT.  The IT staff of the companies involved are very helpful, but the intranet is not their primary concern.  They only get involved when there’s a problem.

However, my second reaction to hosting an intranet in a cloud is that intranets often (hopefully) get embedded deep into the technical infrastructure of a company.  With any luck, they’re more than just tacked-on news article generators, but instead integrate with internal tools and resources like scheduling, task management, Active Directory, messaging, and the like.

Integrating a system this deep can be hard to do remotely.  I was just looking at Amazon’s Virtual Private Cloud the other day, which puts a cloud of machines local to your network.  While this would certainly work, there would likely be latency issues, and you have to ask what the point is, then.  If your intranet is crippled when it can’t talk closely with other, internal systems with crazy-fast response times, then what’s the point of having it in the cloud in the first place?

Nine Mistakes That Turn Your Corporate Intranet into a Ghost Town : I really enjoyed this article.  It’s full of some good, practical advice.

Mistake #2: Creating a one-way communication platform: Intuitively, it doesn’t make sense. Tight controls around who can publish, and strict policies and heavy approval processes only stop people dead in their tracks. If you make it easy for people to contribute and publish information, they’ll gravitate towards the intranet, not away.

This post goes back to my post from years ago entitled The Three Types of Intranets.  So does the point below:

Mistake #5: Downplaying the importance of integration. […] the primary value of an intranet lies within its ability to integrate data from a variety of applications for easier management, accepting anything less would give you little more than a fancy Web interface.

Let us now praise metators : Tony Byrne succumbs to use of the word “metator.”

Metators are not just found among corporate web teams. Records managers have been dealing with metadata for decades. Now, you might think of your enterprise records manager as some corporate ninny who makes you clean up your virtual bedroom. In reality, she is organizing and processing large volumes of information on behalf of the enterprise, its customers, and ultimately for you, too. She is, in short, a metator.

Bob Boiko coined this word long ago – it’s a portmanteau of “editor” and “metadata.”  I’ve loved the idea of it since I read about it in the first edition of The Content Management Bible, so many years ago.  I resist using the term because it’s really awkward to say (seriously – try saying it out loud in a sentence).

The idea is that there’s an editor who isn’t so much concerned with dotting i’s and crossing t’s in an actual piece of content, but more concerned with figuring out where that single piece of content fits into the larger picture – how it relates to other content, and where it should fit in the overall scheme of the information architecture of an organization.

A metator is a librarian, really.  Someone who assumes responsibility for ensuring the all the bits of information in a domain is intelligently organized in relation to each other.  An actual librarian doesn’t read every book, but they know where the books of beekeeping are, and why they’re in that particular spot, and why books on yachtmanship aren’t in the same place.

For a large-enough organization, this role is critical.  Content editors turn out reams of content, and the last stop in the workflow should be a metator who effectively puts the content in his wheeled cart, and pushes it into the stacks to be shelved in the right place.

Content Management Systems just don’t work. : This is an excellent post about something we’ve discussed before – is a “boxed” CMS really worth it?  For instance, in this excerpt, the author is struggling with the decisions that the vendor or platform makes for you:

See— the problem with a full scale Content Management System is that it has too many opinions. Those opinions were though of by somebody other than you and the needs of your organization. The more developed a content management system (or any piece of software, really) the more “opinions” it has. And the more “opinions” it has, the more likely one of them is going to really tick you off.

I can relate to this.  We work with one system in particular that makes an astonishing array of presumptions about how you’re going to use it, and if you try to step outside those presumptions, demons fly out of the abyss and try to suck your eyeballs out.

This goes back to a previous discussion we had about Content Management as an API.  In that post, we had a great experience with hand-rolling a CMS.  Sadly, in another situation it was the exact opposite – we tried to hand-roll something simple, but the client wanted more and more “CMS-ish” features, and there came a point where we realized we had spent so much time and effort that we could of purchased a commercial system and been better off.

For me, the solution is a boxed system with a great API.  In fact, ensure that the system is built from the API out, rather than the interface and publication layer in.  For now, EPiServer has filled this need for us.  eZ publish is good too, and Ektron’s API is getting better and better every release (though they’ve had the distinct disadvantage of backing the API into the product, which makes it so much harder and longer, as they’ve been fleshing out this API for about four years now, and are just now getting close to done with it….)

So, in the end, I don’t agree with the author’s contention that you just need a good Rails/Django developer over a boxed CMS.  He says it’s an over-used point, but I still believe you just end up re-writing too much functionality in the end.

Web content migration: disastrous strategy : Gerry McGovern has a great plan for solving the intranet content problem – don’t migrate your old content. Abandon it and start again.

Taking your old intranet content and migrating it into a new software system is doomed to failure. If your website isn’t working then ask this question: why isn’t the website working? Is it because of the technology? Is it because of the graphics and the layout? Or is it because of the content? Nine-times-out-of-ten it will be the content.

Are you paying competitive hourly rates? : J. Boye did a survey of the rates charged by content management integration firms, mostly in Europe.

The values quoted here are in Euros, and the current exchange rate is 1 Euro = $1.42.  As such, system integrators are expensive, it turns out.

Blend charges a list rate of $125/hour, which puts us well under any rates quoted on this page.

Via Seth.

Open Source CMS Award:Packt is launching their annual open-source CMS contest.  This year, I’m a judge in the “Overall” category, but with Drupal and Joomla moved to the “Hall of Fame” and not eligible in the category,  it’s anyone’s game.

The 2009 Open Source CMS Award nominations have begun. Nominate your favorite CMS for the appropriate categories today and help them win their share of $24,000! If you’ve benefited from an open source CMS and would like to give something back to the team that made it happen, now is the time!

Judging this is, for me, a little grueling.  Every year, I download, install, and try out every single candidate system.

A long time ago, I wrote a post about how the interface to your app should be removable – you should be able to lift it off, and have a competent enough API underneath to still work with the app.

eZ publish is very good at this.  All their PHP code will run from a command line.  Ektron, not so much – to my knowledge, Ektron’s API will only run in the context of the Web server.  And they’re not alone – I would say the majority of CMS are like this.

I’m probably nitpicking here, actually.  But the ability to run a program outside of the context of the Web server is usually a pretty good indication of the general strength of the API and how it’s been architected.

Like eZ publish, EPiServer has strict separation of their API and their interface, and here’s the ultimate manifestation of that: a command-line interface to an EPiServer CMS.

Written by Magnus Stråle, this allows you to browse an EPiServer content repository from the command line – you can “cd” through the tree, list “files” (really content objects), etc.  I played around with it last month at EPiServer’s new digs outside Chicago, and it’s kind of neat.

But…also kind of pointless.  I mean, there’s not much you can really do with it, and I’m sure Magnus knew this.  In truth, I suspect he wrote it as a semi-comedic exercise – a gee-whiz bit of functionality to show off at a conference.

But, it does demonstrate the point I made two years ago:

When building a new piece of software, you really need to completely divorce the interface from the API. You need to get in the mindset that your app is really just a data store and a set of logic modules that do something. That is your application.

At the same time, you can build an interface that lets a human interact with your application. This an obviously very important piece, so it should get at least as much attention as the application itself. But never forget that the interface is layered on top of the application. In a perfect world, it can be lifted off and thrown away, leaving a fully-functional API underneath.

In that sense, it’s awesome.