Content Delivery Options in CMS

Recently, I was part of a Web Portal selection process, various vendors proposed their product and came up with demos, and tried their best to answer most of the questions which we asked them in our RFP.

One of the questions was about ‘Integration with our existing CMS’. This was the area where I was interested, so I was attentive and analyzed every word they spoke about integration. Unfortunately, none of the MQ ‘leaders’ were convincing enough on the CMS integration side, moreover, they were trying to propose their WCM product,  in line with their Portal Stack.

I was quite surprised while they were pushing their WCM product, without even knowing why and for how long we(customer) were using other vendor’s WCM product. They were having no idea about the volume of content we had and how simple or complex our implementation was.  It’s quite common for vendors to propose related products alongside their core product. But, when it comes to Integration of their product with other vendor-product, you will often hear them saying – ‘we have a partnership’,  ‘we can write a custom connector’, ‘we can use web services’ etc…. But how truthful are they while making these claims is an intriguing question? I think it is better to research integration options beforehand or ask your vendor for a specific case study along with customer testimonials.

Coming back to the topic of this post –

We all are aware that the vital principle of the content management system is to separate content from presentation. This is true, as we don’t create different versions of the same content differently for different delivery platforms. One content can be targeted to many channels such as – desktop browser, portal interfaces, mobile devices, etc…and when we say different delivery channels, we have different options to deliver the content to these channels,  I will cover some of them here –

  1. Presentation Templates: This is pretty common, most of the implementation takes this approach, be it intranet microsite or internet website, developers can use product-specific APIs to fetch the content and present the same to the site visitors.
  2. Presentation Portlets: Some of the content technology vendor ships CMS portlets for their portal products. Ex. OT-Vignette, IBM (Authoring/Rendering Portlets), and others. On the other hand, few core CMS vendor ships content portlets for different Portal Products. These portlets can be deployed on the supported portal platform and are responsible to fetch the content from CMS and display it on a portal page. You can configure CMS portlets in a portal page which can display your content from one or more CMS sites/nodes/workspace. Most of these portlets provide an interface to create, manage and display the content.  Management Functions are quite limited and if in case they do not cater to your requirements, you may want to extend these portlets and write additional custom code based on your requirements.
  3. Presentation Templates(For portal interface):  This is straight forward. You can use this approach when there is no clean integration available between your CMS and the Portal Platform. Write a simple presentation template as mentioned in #1 for fetching the content, apply the right CSS(as per your portal look and feel), and make sure that the HTML you use is aligned with the portlet/channel/i-view, etc. Once the template is complete, publish the page as HTML(static publish). Configure your portlet to fetch this HTML file. This is a quite simple/fast/non-expensive way to get your CMS content on a portal page. A disadvantage of this approach is that it’s a one-way communication channel. You can only ‘read’ your static content. Dynamic content delivery, in-context editing, and User Generated content will not be applicable in this approach.
  4. REST: This could be one of your options to access content if your CMS provides REST APIs for accessing the CMS data. All you need is to use REST URLs and access a resource in the system and get the output in either XML or as a JSON object. Once you have the required information/content, you can apply the presentation to render it. It’s not only the read but a  supported REST service that provides developers with Create, Edit, Update, Delete (CRUD) functions for operating on the specified content/content-object.
  5. RSS: There are a couple of scenarios and options to fetch and render content using RSS.  Take an example of a news feed from CMS – You can write a content template to search your News content based on publish date/time, retrieve the data, and generate the RSS XML. You can now either display it for a web page or you can consume it in an RSS Portlet/Reader. Another way is to export your content as XML from within the CMS and write a utility to generate the RSS XML and to display/consume it.
  6. Content Delivery on Mobile: If you are using a WEM stack with a Mobile delivery platform integrated with your content management system, it becomes fairly easy to target content to a particular mobile device. You can leverage the device database to know the device’s OS, type(touch/key-based), screen(size and resolution), and apply the right presentation (Layout and CSS) Template, before rendering it to the Mobile device. If you are not using any sophisticated mobile delivery platform, you can use application filters to Modify(Only HTML & CSS) your actual CMS specific Presentation templates based on the type of device group (as you don’t have a huge device database in this case)and then target the content + presentation to the Device Groups.

Apart from the delivery options I mentioned above, there could be other ways to deliver content from your content management system. It all boils down to your requirements, the participation level of end-users at the presentation end, and most importantly, the delivery interface.

Thanks for dropping by and do share your experience and your approach to content delivery from CMS.

Digital Experience Platform and the foundation called WCM

The buzz is just getting louder, it was Liferay who introduced the acronym DXP a couple of years back and was then followed by other WCM and Enterprise portal vendors (Adobe, Day, Sitecore, and Vignette).

To me, this concept is here to stay. It’s too early to evaluate the pros, cons, and business implications of this concept. We still have to witness a large size implementation of these “DXP” yielding some true business results. Well, This is my take on DXP, I am sure most of the readers would relate, especially the ones coming from the CMS background. So…let me try to answers some questions which come to my mind –

Q-1) What is DXP?

Answer:  Digital Experience Platform, is an emerging category of enterprise software where the base Content Management Product is an integrated set of technologies to create, manage, analyze, deliver relevant content to the targeted audience on a variety of end-user devices. This is also a marketing term coined by WCM/Portal vendors to position themselves above pure WCM vendors. A term that is now helping them to sell more licenses. A Nice-looking User Interface, an SSO software to back it up with integrations of the below software from the same vendor-

  1. Web Content Management
  2. Analytics
  3. Local/Social Collaboration/Community
  4. Targeting/Segmentation
  5. Omnichannel Delivery Platform
  6. Connectors for other WCM/ECM/DAM products

..and the list goes on.

Q-2) Is DXP a product, suite, or framework?

Answer:  For product marketing & sales group it’s a ‘suite’, for a buyer it’s a ‘product’,  for a technical developer it’s a ‘framework’,  for a business user/content contributor it’s a User Interface with drag-drop of layouts & content and for an end-user/content consumer it’s a ‘this is what I need’ delighter.

 Q-3) Do you need DXP or WCM?

Answer:  You need a WCM for creation, modification, targeting, publishing, versioning, and managing the lifecycle of content. You might need a Mobile delivery platform if you are targeting your content to a range of Mobile Platforms. If it’s just a couple of handsets you don’t even need the Mobile Delivery platform (more on a separate post). Analytics is a way to go if you want to know your online users, website visitors but it’s no point buying an analytics product from the WCM vendor. Separate specialized analytics software will give you more flexibility, control, and a higher degree of reuse. Revisit your business and technical requirements,  talk technically to the product vendor to check “how” DXP can help you cater to those requirements. So far, I have not seen anyone specifically writing requirements or budgeting for DXP.

However, if the DXP vendor is giving the customer the flexibility to choose from a range of products (those part of the DXP suite/framework) and charging only for the selected products then I think it’d be a good way to move forward.

Q-4) Is DXP a revolution, evolution, or transformation?

Answer: It’s not a revolution, but yes, there is a significant change in the way consumers are using the web. Users do not want one-sided communication but also want to contribute, provide feedback, personalize their content from across multiple channels, not just ‘web’.  DXP is an effort to provide a rich experience to both the content contributors as well as content consumers. Having said that, it does not mean WCM has evolved or transformed to DXP. The core WCM remains the same, and ironically, product vendors are not putting much effort to enhance the content management capabilities of WCM.

Final Thoughts:

Product vendors always look for some buzzwords to be in the news, to market their product, and to impress buyers. ‘God lies in the details ’ – don’t get fascinated, involve your IT staff, let your technical team sit with a vendor, let the vendor explain to you the basics and underlying components (REST, SSO, JSF, Taglibs, Delivery model, Web-services, etc). Get feedback from your technical team and see if similar can be achieved with your existing software infrastructure without much effort and cost.  If you still want to use DXP, check with the vendor if you can choose and use your apps on a’ la carte basis.

Blog at WordPress.com.

Up ↑