I have worked with many customers where globalization [G11N] of content (which is combination of Internationalization [I18N] - making sure your code is not tied to any language specific logic, and Localization [L10N] - having content in multiple languages), is a hot topic during the requirement phase but it does not get fully implemented by end of the project. Reason? Well, there are many reasons, but most importantly is how critical is this for business users compared to other things in the project.  One of the hard part of this process in L10N, as developers can be guided to write logic keeping I18N in mind, but business processes have to be in place to translate appropriate content in a timely manner.

Reading the ‘The Global CMS Reality‘ on CMS Myth made me reflect on those customers again. This blog entry on CMS Myth mentions the report on ‘The World in 2009 - The Economist‘, which explains “Of the 1.5 billion people who will use the Internet regularly in 2009, only fifteen percent live in the United States. Only thirty percent speak English as their first language”. This is a powerful statement, as it explains clearly if you want to the company with global reach, you better have a globalized site, and this cannot remain a nice-to-have requirement, but should be part of critical requirement.

CMS vendors have also come a long way in making this process easy (well, easy in a relative manner), and with the combination of their products and best practices of G11N (extremely important to know, else you may end up with an inflexible design), customers have a fair chance of getting their site globalized.

If your site is not G11N ready, time to wake up and start planning, it doesn’t matter whether you have a CMS tool or not, if you want to reach the global audience, you better be multi-lingual!

As per Wikipedia, Microsite refers to an individual web page or cluster of pages which are meant to function as an auxiliary supplement to a primary website. The Microsite’s main landing page most likely has its own URL.

Microsites are quite effective as information outlet and its use is rising. You could give content authors wide range of freedom on how to create Microsite and what structure they can use. They could use any HTML editor of choice and copy the entire output folder to their Microsite folder on web-server (files including, but limited to images, JS, CSS etc). You point a URL to that folder and you are live! Content authors love this freedom of choosing their own structure, even if they have to comply with certain UI templates, they can still tinker with those templates quite fast.

On one hand this option promotes creativity, on other hand it can lead to stale content/template/message on internet longer than you want. You choose WCM and/or Portal products to help you manage the content life-cycle, so one naturally expect managing Microsites within these products. What happens when you try to manage Microsite using these products, can you still provide same level of freedom to content authors on creating Microsites?

Most of the WCM/Portal products would expect you to create templates and use those templates to deliver the content. If you want to create a new template or change existing ones, it would take time (Product companies may claim otherwise, and even if it is as easy to make template changes in few clicks, how about your governance process and testing the impact of template changes on existing content?). In short, it is not easy to change templates easily and give content authors same level of freedom in creating Microsites. This could create discontentment in content authors towards WCM/Portal tool, as it restricts them to certain existing templates for creating Microsites or makes them wait for the template creation process before they can publish their Microsite.

I have seen many of my clients struggling with this situation, where they have departments who want to rapidly create Microsites for promotions/campaigns and thay don’t want to live within the structure of existing templates. The discussion always boils down to this, IT team would ask how many templates you need and we would provide you the library, and the response would be, we don’t know what all we need, we need to be able to create the Microsites with new templates as we go.

I don’t think there is a perfect solution for this problem, but you can arrive at one which could accommodate majority of creativity requests upfront, but still leave room for one-off situations where you have no option but to allow content to be created on free-form HTML and dropped in web-server. Both sides would have to resist the temptation to follow one or the other route (WCM/Portal Vs. Free Form HTML) for all the Microsites. You would have to create governance process to keep an eye on those sites and regularly review them for their content and message.

This entry is about Web Content Management (WCM) content security (potentially delivered through a Portal) and does not refer to Digital Rights Management (DRM), although I can see this discussion being extended to discuss DRM as well.

When you talk about securing content in WCM world, it could fall under two main categories, content security and content personalization. It could be surprising to see personalization being talked under the security, but some people still blur the difference between two. Here is my definition to differentiate the two; security, when you should not have access to content if it is not meant for your consumption, personalization, when you don’t see the content on your landing pages, but you can access it through some other means.

Any WCM/Portal application designed to provide this feature has to deal with performance of application, as each user is accessing the pages with different combination of security (groups , roles or profile attributes) resulting in different queries to generate the page Vs. each user accessing the same page generated through one query. If the combination of security attributes is small, overall number of queries for all pages would remain in vicinity of non-secured content pages. But, when you talk about thousands (or millions) of end-users hitting the site resulting in millions of page-views, you would have to think about how much hardware you are ready to use for your site that deliver content security and/or personalization. More combinations you use, chances are high you would end-up using more hardware.

Most WCM/Portal solutions have some kind of caching mechanism to reduce the impact on back-end, but they work efficiently when overall cache-hit is high (cache-hit: same page is accessed by multiple users, so only first user hit would create an impact on back-end, rest access would result in serving the content from the cache). In case of content security and/or personalization, these cache hits are reduced, creating an impact on your back-end systems.

In the end, it boils to down to balancing the two, how much functionality you would provide to end user for content security/personalization Vs. how much you would like to spend for delivering that content through your infrastructure. It is not an easy decision, as we move towards more personalized web, every consumer of your site is expecting this feature, at the same time, the relentless cycle of extracting more out of less puts high pressure on delivering this functionality with limited infrastructure.

If you are in a similar position, you could try to limit the scope of personalization/security to certain pages (you would have to analyze overall use-cases to come up with recommendations) or use an intelligent caching solution (either part of WCM/Portal, or built on top of it). This functionality will make more impact on your infrastructure than non-personalized content, although you can limit the impact through judicious business requirements and/or technical design.

I was surprised to see this topic for an upcoming event in NYC hosted by ISF and SIM (Feb 26, 2008). Surprised, not shocked, as I have seen enough customers to know the sentiment, and I believe that there is some truth to it.

CMS promises to be ultimate in flexibility, and it does not lives up to it all the time. Rather than accepting the limitations, many customers end up walking on heavy customization path and then find themselves in a position where base product cannot be customized any further. Now, they have invested a lot of time and money, and they still don’t have what they wanted and so the sentiment comes out, “I hate my CMS”!

I think we have to start accepting that there is no magic-bullet when it comes to CMS and CMS do have limitations. If we understand its limitations and see that we choose right platform for our current and future needs, with focus on reducing customizations, you could have a winner.