The Utility of Drag-and-Drop Page Composition in Content Management
One of the big new trends in Web content management is drag-and-drag page building. Episerver has Composer, Ektron has PageBuilder, Sitecore has something similar, SiteFinity is pretty much completely built around drag-and-drop everything, etc.
This is very sexy stuff, and I’m sure it plays amazingly well in software demos. However, I’m not 100% convinced of the utility of it yet. It’s right for some things, sure, but not everything.
In reality, it’s probably good for only a small fraction of pages.
Not every page needs to be hand-built, or should be hand-built. Content management thrives on consistency, and on any site beyond simple brochureware, 90%+ of pages are and should be templated. Editors may claim they want the freedom of drag-and-drop page assembly, but it’s going to get pretty tiresome when you’re pushing out five news updates a day and have to continually be dragging things around on the page.
In well-planned and executed implementations, pages are more often assembled from context, rather than assembled according to the whims of an editor. Displaying a press releases? Then you need the press release navigation in the left sidebar, period. And we know this because you’re in the press release section, so this decision is driven solely from the context of where the page is in the content structure. This is a setting based on content location, and should be cascaded down through all the content in that location.
On top of all this, allowing editors to hand-assemble pages becomes one more governance issue. Now we’re not just concerned about the content, we have to be concerned about how the page was assembled. Is the page composition versioned? Do changes to it go through workflow? How do we manage permissions around it?
And this is sort of my core problem –
Are we assembling pages or are we assembling templates? This is key – if you’re assembling individual pages, then the composition of a single page really becomes a frozen configuration, captured in time, and applied to a single piece of content. The composition of that page is managed just like the content of that page. Want to change the composition of the page? Find it and edit it. Want to change the composition of 10,000 pages at once? Uh…
What we lose here is the separation of content and presentation. Why? Because the presentation becomes content. It sort of acts like content, in that it’s bound to a single page, but it sort of doesn’t act like content for all the governance reasons I mentioned above (workflow, versioning, permissions, etc.). The composition of a page is like content stuck in a parallel – and really crappy – CMS.
So, what I think we all really want to be able to do is compose templates. You really want to assemble the structure of a page, sans content, and then have this content injected at request time.
(When I first set out to use PageBuilder on an Ektron site, I was somewhat horrified to find out that you couldn’t do this. You could only assemble single pages. The utility of this for my situation was approximately nil. Now, before I get nasty-grams from Nashua, I believe this has changed. Last I heard, Ektron was developing some “Master Wireframe” system, that let you inherit PageBuilder configurations…or something. I trust that someone from Ektron will comment and set me straight on this.)
So, let’s assume for a moment that our dream system is competent enough that we’re actually assembling templates. So we can drag and drop a page, leave a hole for content injection, and apply this template to 10,000 pieces of content in real-time. Great, right?
Meh.
The reality is that people are going to be just turning on and off small pieces of functionality. Or – more likely – not doing anything at all. The Holy Grail of this exercise, we’re told, is for editors to spend all day dragging stuff around. In my experience, this just isn’t going to happen. The appearance of surrounding content and functionality is usually driven by business rules, not an editor manually swapping things in and out.
(Additionally, I don’t know about you, but once a site is launched and running, template changes – while often technically trivial – are organizationally much more complex than “hey, drag something over there.”)
However, in the end, I’m not universally opposed to the idea because it does fill a pretty important hole – landing pages. And by “landing page,” I mean those one-off pages in every content management implementation that look like nothing else. These are pages that when you come across them in a wireframe, you think, “Crap…” and start making plans for one-off templates to support them.
For these pages, you often end up with multiple WYSIWIG areas called “Content Area 1,” “Content Area 2,” etc. This is sub-optimal, and needs to end. Editors want and could use freedom in this area, and they usually have multiple formats to these pages that involved merging and spanning columns, and generally re-arranging the core layout of the page;.
All things considered, I feel like drag-and-drop page-composition is only marginally useful. In my experience, it has an advantage in letting editors manage a specific type of page – and a rare one, at that. In exchange for this, you introduce a lot of complexity, training, governance, and maintenance issues.
Or perhaps I’m just cynical and resistant to change.