The Utility of Drag-and-Drop Page Composition in Content Management

By Deane Barker on March 9, 2011

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?


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.

What Links Here


  1. Excellent post.

    Only other caveat I would add is that in addition to landing pages, these sorts of one-off compositors can be useful for some microsites where marketers need to make frequent, arbitrary structural changes (I’ve seen it work in practice, though to be sure, it’s not commonly essential and as you point out you lose all benefits of inheritance).

    One topic you didn’t raise: the quality and standards-compliance of the generated code. We’ve found some nasty gotchas among different vendors there…

  2. Interesting post. I agree that pages shouldn’t be completely composed by editors and some templating is needed in most scenarios. However for EPiServer projects we are tending to use a mixed modal approach. Take a news article as an example. Content editor fills in headline, byline, masthead image etc into proper CMS defined fields. However we often have a composer area for let’s say the tricky “put anything here” section on the right hand side. It means you can still show abstract information about the news item on the rest of the site but gives editors a bit of flexibility to surround the news item with, well whatever they like within reason.

    Its not without it’s flaws. But it’s the kind of requirement we are increasingly seeing and is an approach that works on our projects.

  3. This was the topic of a dinner conversation I had with the Ektron engineering team last night.

    Tools like Ektron PageBuilder, EPIServer Composer, Interwoven SitePublisher, etc. became popular because editors became increasingly frustrated with hearing “that requires a template change” each time they wanted a slight presentation variation. Often the number of template variations required to meet user requirements would end up being unmanageable; I remember hearing about Interwoven customers with hundreds of templates. Some developers began to work around the template explosion problem by adding presentation data into the authoring environment (like image centered left-center-right), handling the display logic in the template. This wasn’t optimal either, because users don’t think like developers and designers think. While the complete separation of content from presentation makes developers happy- it often doesn’t meet user requirements. Especially as it applies to marketing-driven use cases like landing pages and microsites. It’s also useful for emerging channels like Facebook pages, for example

    Ultimately I think the answer lies somewhere in the middle. Context-driven page assembly is a must, and your press release example is spot on. I’ve challenged our engineering team to start thinking about new ways to tackle this problem, as the current vendor approaches are far from perfect. How can we empower users with an appropriate level of design flexibility while ensuring developers and designers are happy with their ability to architect and design the site for consistency.

    And yes, Ektron Pagebuilder does provide a master layout capability to nest page regions :)

  4. Great post Dean!

    I’m not a big fan of drag and drop page builders either, because:

    1.) They promote loosely structured content

    I believe that highly structured content is very valuable. Page builders is all about loosely structured content. Page builders offer a lot of freedom, and seen in isolation, it can be useful. But the long term effects are very bad IMO.

    2.) They promote lazyness during design and development

    The basic issue that page builders try to fix is a lack of freedom in templates. To fix it, they give you almost total freedom. I believe that most templates can be made flexible enough without going for a page builder, and at the same time keep a better structure on the content. All it requires is a little more forethought by the designers and developers during planning and implementation.

    A lot of times I’ve seen developers blindly implementing templates as designed by the designers, without any thoughts on how it might be used. A good developer should think about how each template might be used, and how they can make the template as flexible as possible without ruining the structure or design. In my experience, by doing that, you’re able to meet the majority of requests for flexibility in the templates.

    3.) The lack of separation between content and presentation is not only a problem if you want to change the composition of 10 000 pages as you point out, but it also makes it hard to reuse the content in other channels.

Comments are closed. If you have something you really want to say, email and we‘ll get it added for you.