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 –
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.