One of the main benefits of using a coupled (aka "frying") web content management system (WCMS) is that you get a web application development framework with which to build dynamic content-driven applications. Like nearly all modern web application development frameworks, a coupled CMS provides an implementation of the MVC (Model-View-Controller) pattern. For the less technical reader, the MVC pattern is used in just about all software that provides a user interface. The essence is that the model (the data), the view (how the information is presented and interacted with), and the controller (the business logic of the application) are separate concerns and keeping them separate makes the software more maintainable. I will let Wikipedia provide a further explanation of MVC.
The MVC implementation that comes with a typical WCMS is less flexible than a generic, all purpose web application framework. Your WCMS delivery tier makes a lot of assumptions because it knows that you are primarily trying to publish semi-structured content to some form of document format — probably an HTML page, but possibly some XML-based syndication format. Your WCMS knows roughly what your model looks like (it is a semi-structured content item from the repository that has only the data types that the repository supports); it has certain way of interpreting URLS; and the output is designed to be cached for rapid page loads. Those assumptions are handy because they make less work for the developer. In fact, most of the work on a typical WCMS implementation is done in the templates. There is hardly any work done in the model or controller logic.
But there are times when the assumptions of the CMS are broken. Anyone who has implemented a relatively sophisticated website on a CMS has had the experience of either overloading or working around the MVC pattern that comes with the CMS. The approach that I want to talk about here is what I call the PAC (Placeholder Application Controller) pattern. In a nutshell, this pattern de-emphasizes the roles of the model and controller and overloads the view (template) to support logic for a mini-application. The content item goes from being the model to a placeholder on the website. The controller is used more like a switchboard to dial up the right template.
Here is a common example. Let's say that you are building a web site for an insurance company. Most of the pages on the site are pretty much static. But there is one page that has a calculator where a visitor enters in some information about what he wants to insure and gets back a recommended coverage amount and estimated premiums. It would be pretty silly to try to manage all the data that drives the coverage calculator as content in the CMS. Instead, you would probably want to write the calculator in client-side Javascript, copy it into a presentation template and then assign that presentation template to a blank content page with the title "Coverage Calculator." The Coverage Calculator page in the content repository is really just a placeholder that gives your Javascript application a URL on the site.
To a lesser extent, home pages often implement the PAC pattern. In this case, the home page might be a simple empty placeholder page that is assigned a powerful template that queries and features content from across the site. When the controller grabs the template and model, it may only think that it is rendering the content that is managed in the home page asset. Little does the controller know, the template is going to take over and start to act like a controller — grabbing other models and applying other templates to them.
Placeholder Application Controller is one of those patterns that, once you think about it, you realize you use it all the time. It is convenient and practical but be careful with it because it is easy to get carried away. The main risk of the PAC pattern is that you are going against the grain of the WCMS architecture. Templates are supposed to be for formatting only. You may be pushing the templating language a little farther than it was intended to go and your code may become unmanageable. You also may be short-circuiting the security controls provided by the controller. Some WCMS platforms have a pluggable architecture that allows 3rd party modules (programmed in something other than the template language) to step in and play the roles of model, view, and controller. This helps keep the architecture cleaner but there will always be some limitations on how these modules are allowed to work. After a certain point, you will be better off going with a generic web application framework that affords you more flexibility and just use the WCMS to publish content into your custom web application. But that is a much larger undertaking.
Every organization should have a good hard look at their content strategy and bring in help if they need it. However, doing any kind of content strategy work (using external or internal resources) is a waste of time without first establishing a solid foundation.
Your content strategy cannot succeed unless:
You have information that a desirable audience wants
In order to create content, you need information. In order to create content that your target audience wants to consume, you need to have information that is of interest to them. A steady stream of irrelevant press releases cannot be the basis for a good content strategy. Neither is a random Twitter stream of links and retweets. The good news is that any organization with customers (product purchasers, potential buyers, subscribers, members, etc.) probably has information that is of interest to them. The challenge is figuring out what that information is, which requires an understanding of the audience.
The information you have is capable of driving desired behaviors
While your audience may find it intriguing, simply airing your dirty laundry isn't very strategic. For every bit of information you publish, think about expected and desired reponses. If you work for a product company that has launched a new product, the content should contain information about who should buy the product and why. If you have no information that would compel a customer to buy your product (that is, your product stinks), there is really nothing worth saying and no content strategy can solve that problem. Lying is a not a good content strategy. If you have information about a defect in your product, the content you produce should support customer loyalty by resolving the issue. If publishing is your business, your content should establish your organization as the authority on this topic (and topics like it) so that the audience subscribes and/or returns.
I call these the "First Principles of Content Strategy." Any content strategy work should be grounded on these principles. If you hire a content strategy consultant or staff an internal resource, testing these assertions first will help you start off on the right direction and save time. If your answer to either of these assertions is "no," put that content strategy project on hold. You have more pressing issues to address.
The other part of the announcement that intrigued me was why they went to the Eclipse Foundation and not the Apache Software Foundation. After all, Apache already has Chemistry, which is a collection of projects that implement the CMIS standard. My first reaction was that Nuxeo thinks the ASF is broken since its tiff with the Java Community Process. That may be so but I think there are better explanations. First, Chemistry already has a number of projects and it is still in the incubation stage. Perhaps Nuxeo feels that these aspects would dilute Nuxeo's influence. Second, Nuxeo has had a long relationship with Eclipse. Back in 2006, Nuxeo announced the Apogee project. Apogee is an RCP (an Eclipse build), designed to be a universal thick CMS client. Apogee never really caught on in the general marketplace, but I know that Nuxeo has been very successful implementing it for their customers as an efficient user interface for their own CMS. With the advantages of influence and the Eclipse Foundation's community and resources, Nuxeo Core may have great potential as the Eclipse Enterprise Content Repository Project (ECR).
Drupal represents a middle ground between framework and CMS that we’ve chosen not to take. Drupal is far more capable than a CMS like WordPress, but also much less flexible than a pure framework. But more importantly, the facts that Drupal isn’t object-oriented, isn’t MVC/MTV, doesn’t have an ORM, and is generally less flexible than a pure framework, not to mention our preference for working in Python over PHP, all contribute to our decision not to use it.
I reached a similar conclusion on a recent project.
There is a mini-meme going around about the fragility information in a digital society. The argument goes that, because we manage information in proprietary digital formats and rapidly changing devices, we are increasing the risk of losing everything. Archeologists of the future will not be able to analyze MS Word 2010 files on old hard drives like the archeologists of today can read ancient texts on papyrus and stone. One of the better posts is Cheryl McKinnon's OpenSource.com article "From information overload to Dark Ages 2.0?" and the video embedded below.
I call this a mini-meme because it is not stirring up a Y2K-bug-grade hysteria. I guess you need images of planes falling out of the sky to get that level of reaction. The concern for this is more in line with that of the constant low level anxiety that all CIOs feel from the information overload problem — "this is a big problem that we are going fix after we take care of all the urgent matters on our plate."
We do need to curate and preserve information that is important. We need to do it on an individual level so our descendants can know where they came from and we need to do it on a societal level to teach future civilizations what we know. The problem is that we have a lot of crap to sift through. It used to be that producing information assets was hard and expensive. If you got an idea to create something, you would consider the effort and cost it would take to produce and distribute it, and then weigh that against the value. If something was created, you could assume that someone thought it was important. Now... not so much (queue the LOLCats).
In ancient times you had to have near-deity status for someone to go through the trouble of carving your likeness in stone. The cost of portraiture has been steadily going down to the point where now people don't even know when their picture is being taken. Remember, not long ago (before digital photography became the norm), you would really hesitated before snapping the shutter because each picture would cost you regardless of whether it even came out or not? When I got my first digital camera, I would snap away but delete the photos off the card to save space. Now I don't even bother to delete the bad ones. You can even go onto Facebook and see that a grainy blur has been tagged as you.
The same thing happens in the office. When I came of age professionally, one of my first responsibilities was to produce and distribute a productivity report. This meant running the report, printing it, making copies, and then putting them in physical mail boxes. It took the better part of a morning to do it. If there was even an outside chance that report wasn't useful, that task would disappear. Ten years earlier, I would have had to type up the report and run it through a mimeograph. It would have taken more than a day and wouldn't have been worth it. Now email inboxes are flooded with automatically generated reports that nobody reads.
It will be difficult to go through all the digital information we are producing and decide what is worthy of preserving for the long term. We will probably procrastinate this effort until there is some sort of scarcity or scare that brings the threat of loss to the forefront. When we do get around to it, however, I think we are going to learn about ourselves in the process.
The one aspect that doesn't quite sit right with me is the implication that less investment in the product translates into less risk for the customers. In my opinion, there is extreme risk in products that are getting minimal development. Static-ness can be the first sign of decline. The supplier (be it a commercial software vendor or open source development community) may be losing interest in the product and is reducing investment. You could say that this risk is captured in the vendor restructuring dimension as downsizing the group managing the product. Still, I think that risk on the product development axis is higher on both extremes. In the example of the diagram, if Microsoft invested even less in their WCM Platform, I think risk would increase. Anyone remember Microsoft Content Management Server 2002?
BTW, I tried to add this as a comment to the post IntenseDebate appeared to be swallowing my comments :)
I have a complicated relationship with personal information management (PIM) tools. I love PIM software and services that promise to remember everything that I once knew. I am tempted by every new information gadget that comes down the pike. But I have also been burned lots of times too. I spent hours on corporate intranets documenting my knowledge only to have them shut down. I used proprietary software like the The Brain which became inaccessible when I switched computing platforms (note: now The Brain supports Linux and Mac OSX as well as Windows). My Google notebooks are now barely supported by Google. And now we have news of Delicious's uncertain future.
Because of these experiences, I have been fighting my urges to use services like Evernote, SpringPad, Yojimbo, etc.. Instead, I have been sticking with humble text files. In an earlier post, I described how I am using TextMate as a blogging tool. I have started to use it as a knowledge management tool as well.
I don't pretend that I have the features that products like Evernote do, but here is what I can do:
Create notebooks with multiple pages by using TextMate's project feature.
Organize pages into folders.
Create todo items and other tags that I can summarize by using the ToDo bundle
Search using "Find in Project" or Spotlight.
Collaborate with others using GitHub or another code hosting service.
Store and organize binary files like diagrams created in OmniGraffle.
The truth for me is that the greatest benefit of any PIM tool is simply the act of recording and organizing the information. These activities help me remember and process information into actionable knowledge in my head. You can do that with any tool. The second most important aspect is search and recall. This is where the open format of text files really excels. It would be really frustrating to try to retrieve some information but not have access to the software to consume it.
While I generally don't enjoy 2011 prediction posts, I really loved James Hoskins's article (20)11 predictions from the CMS coal face. I found it thoughtful, pragmatic, and meaningful. One of my favorite predictions is #8 Personalisation falters again. I have had similar challenges with personalization. Most content organizations do not have the maturity, discipline, and energy to fully leverage this kind of technology. Interest and investment inevitably subsides after irrational expectations are not immediately gratified. Investment is higher than expected: you have to manage more complex technology, you need to develop more content, and you need to test a lot more. Return is lower than expected: most companies don't even know how to measure the value of the return.
There are, of course, exceptions. The importance of display and placement are ingrained in retail culture (online and offline) and small tweaks can lead to big returns. Customer extranets are inherently personalized so I am not including that here.
Traditional media companies (magazines, newspapers, and television/radio stations) would like to personalize but they don't have quite the upside eCommerce sites do; on a media site, an extra click means a few more ad impressions rather than a potential sale. Most media clients find that the volume and turnover in content makes the cost of tuning personalization greater than the return. Showing articles that are related to the current article brings the biggest bang for the buck. Marketing sites are more campaign driven than personalized; you put up different pages with different URLs rather than creating a personalized user experience.
As problematic as it has been in the past, I think that succeeding with personalization is only going to get harder. First of all, multiple device support is going to eat up your development resources so you will have even less time to test and tune complex personalized views. Second, unless you are lucky enough to be one of the premier social networking sites, most of your audience will only be on your site for a page or two — if at all. Most visitors will follow a deep link to your site, scan the content, then go back to the conversation about it. Some visitors will take snapshot of the page using a service like Read It Later or Instaper. Some visitors will just read the conversation and never click through. The upshot is that most visitors will not hang around long enough to implicitly or explicitly build a profile that can drive personalization logic.
I think that the greatest potential for personalization will be to use a service like Facebook Connect like Levis is doing. When a visitor comes with Facebook Connect, they bring some additional context that can be used to drive personalization logic. Most web savvy people find Facebook Connect creepy (and will try to avoid it) but the vast majority of web surfers are either unaware or unconcerned with privacy issues. I would look for a major uptake of Facebook Connect. In particular, I expect to see recommended content display components that can be used in different presentation channels. In the near term, however, I the greatest returns will come from the "make every page a home page strategy" where each page promotes content that is related to the current page. That's not personalization. That's just good content re-use.
Search is probably the most common visitor-facing requirement in web content management system implementations. Usually the requirement is written in terse form such as "basic search" or "advanced search." But there are many nuances that need to be accounted for. There are essentially two approaches to implementing search requirements: repository-based search and page-based search.
A repository-based search indexes content items in the content repository. A page-based search indexes the pages of the site. This distinction is more important than you might think — especially if the site design heavily re-uses content. Here is an example. Let's say your site has pictures that are presented in slideshows. The picture content type has a caption that is searchable. A page-based search for a word in the caption of a picture will return the slideshow(s) where the picture is used. A repository-based search will return the picture item itself — but what if there is no detail page for the picture content type? You might have to do something like create a fake detail page that redirects the user to a slideshow page. Another difference is that a page-based search will index text that is hard coded into the presentation templates. For example, you might have your hours of operation in the footer of every page of the site and a "Visit" page that contains the hours plus directions. If a visitor types "hours" into a page-based search engine, he will get every page on the site in the results. A repository-based search engine will return the "Visit" page.
Generally speaking, the search functionality that comes out of the box in a CMS is repository-based. This is necessary because content contributors need a repository-based search to navigate the repository and find content to work on. Some of this content has not yet even been published on the site. Whether you need a page-based search engine for your visitors to use will depend on the nature of your site. Most types of websites do better with a page-based visitor search because a page is a good enough proxy for a piece of content and page-based search engines are generally easier to set up (look how easy it is to set up Google Custom Search). However, page-based search doesn't work well for all sites. In an eCommerce site that has a product catalog, you want to index the products themselves, not all the pages where the products are promoted. If you have requirements for a fielded search, like finding calendar events that occur within a date range, you will also need a repository-based search that indexes individual fields.
So, next time you are thinking about search, think about whether you want the search engine to index the pages on your site or the content that is being presented in those pages. As with all requirements, the best way to capture search requirements is through scenarios that present real-world examples.
After taking a break from conferences in 2010, I am planning on doing more speaking in 2011. I am starting off my 2011 conference campaign with one of my favorite conferences: J. Boye in Philadelphia. As I have mentioned before, the J. Boye conferences are excellent. The sessions are informative and practitioner-oriented, but what really makes the conferences great is the social element. More than any other conference that I know of, the J. Boye team plans and promotes social activities that encourage attendees to get to know each other and exchange ideas.
I will be presenting a session called Grading your CMS implementation. There is greater potential to understand requirements in the months after a CMS rollout than leading up to and during the implementation. The only form of failure is not using that information to make corrections. However, most organizations label the selection/implementation project as either a qualified success or a total failure and suffer until the next CMS procurement (when they will repeat the cycle). They don't treat it as a milestone in a larger content initiative, which they should. My presentation will show how to create feedback loop to correct issues in three areas: expectation rationality, platform suitability, and project execution. Organizations preparing for a CMS initiative will learn how to set their project up for success and avoid common pitfalls.
Hopefully, I will see you at J. Boye in Philadelphia this May (3rd-5th). If you don't catch my session, I am sure I will see you at one of the social events.
