Blogs

As a companion piece to Eduardo Garcia's excellent Divide and Conquer blog post I thought it would be worthwhile writing up some reasons, from more of business, usability and flexibility perspectives than pure technical ones, why you might want to choose this approach for structuring and designing web content.

When I read Eduardo's blog post I had a couple of thoughts.  I've been using a slight variant of his approach for a couple of years now for Liferay demos I've built - and I always seem to be the only one using this.  To me it was obvious - keep the content itself separate from the design - and allow the dynamic presentation capabilities offered by the Asset Publisher to be used to full effect.  I've been meaning to write the approach up for a while - but in the end got beaten to it!

But while Eduardo's post is about the technical implementation, what I thought I could add was a bit more of the why you might want to use this approach - after all, we have a lot of customers who are maintaining their content with relatively non-technical users - and who otherwise might not see the value.

So, what are the benefits?  Well, if you've ever created a Liferay "Basic Web Content" article you'll know that you get a Rich Text editor to use - and you can switch this to HTML source mode if you're comfortable in doing so.  While extremely powerful, this can create its own challenges:

• To get the best out of the editor it helps if you know HTML
• You are combining the data of the content with the design of the presentation
• Each article is entirely separate from every other one - what if you want consistent display formatting across lots of articles?
• While the editor does its best to ensure that content that is authored is "proper" HTML there's still the chance that your users could create inaccessible content - forgetting to assign ALT tags to images, hard-coding font sizes, setting unhelpful colours etc.

Of course this is one of the reasons why we have the ability to design Web Content Structures anyway - the user simply completes a simple Web Form - and doesn't need to know (or care) anything about HTML, CSS, etc. etc.

So, what's the benefit of combining the use of Web Content Structures and Templates with Application Display Templates in the Asset Publisher?  Well, there are a few, but the biggest one for me is the ability to display dynamic content using the Asset Publisher - and to allow Audience Targeting to be incorporated as well.

Consider the following screenshots.  If you look carefully you'll see that in the first image the Carousel has 4 items, while in the second it has only three:

What's happening here is that I'm using a simple Audience Targeting rule to determine whether a user is logged in or not - and then using Asset Publisher to select all matching articles of my Web Content Structure.  This is obviously a really basic example - but the opportunities are almost unlimited.

The more typical approach for carousels in Liferay is to create a single Web Content Article, based on a custom structure that allows repeating items - in other words all of the items for the carousel are defined in one place.  While you're still benefitting from separating the data from the presentation you are limiting the flexibility available.  Your carousel always displays the same content, in the same order.  If you want to add a new item it will be at the end, if you want to delete an item you can - but deleting the first item is somewhat tricky.  You can't auto-expire content without expiring all items since you've only got one Web Content Article. And so on.

With the Divide and Conquer approach you can define content that expires on a certain date safe in the knowledge that the Asset Publisher will simply stop displaying it at the appropriate time.  You can sort the content using any field available (both system defined and per the structure) - so for example you could set a Priority (which is a system field) on each article so that the most important items show first.  When you couple this with Audience Targeting you could have an item for a specific campaign that runs for a limited period of time but that is only shown to users who meet the criteria for that campaign.

In this example the structure itself is really simple - I'm using the default "Title" for the headline, "Description" for the text, a link to an Image for the background image, and a link to a Page for the "Click for more" link - and then using CSS to overlay the text over the image:

What this means is that it really is trivially simple to create a new content item - so for content authors there's no need for them to have any knowledge of web design at all.  What it also means is that the look and feel for this content can be modified at any time - need to refresh the website - change the Web Content Template or ADT that renders the content and all articles of this type are updated.

Another benefit is that you can use Media Queries in the CSS (I use custom CSS classes that are defined in my theme) to render the content appropriately for different devices.  There's a huge benefit in keeping text separate from the image because it means that the rescaling that Responsive Design provides automatically will not simply shrink the text to a point where it can't be read.  In this case I've decided to hide the descriptive text entirely when presenting the carousel on a phone-sized screen:

So, are there any downsides?

Well, not really - and if there are any they are in my opinion more than offset by the ease-of-use and maintainability benefits.  In theory using the Web Content Display application to display one web content article with multiple items is less expensive (computationally) than using the Asset Publisher to dynamically select content of a given type based on users matching Audience Targeting user segments - but I think you'll probably agree that the flexibility offered far outweighs that.  There's cost associated with anything we do, but it is sometimes easy to overlook intangible costs like the time it takes people to create and maintain content compared to the known costs of a server.

If there are any thoughts on this please share! 

Cheers, Ben