<!-- Content Here -->

Context and the Future of Web Content Management.

Tom Wentworth, from Ektron, has written an inspirational article on Forbes called "http://www.forbes.com/sites/ciocentral/2011/08/30/context-will-drive-the-future-of-web-content-management/". The article describes a very legitimate strategy for achieving a goal that CMS customers all want: serving their audiences with the right content, at the right time, and in the right format. The strategy, which uses visitor context (location and device) to infer intent and other preferences, is something that a CMS can help with. Content management systems have been introducing increasingly sophisticated profiling and presentation functionality to implement elaborate display logic. Content management systems have always been able to capture the metadata and other configuration that drives this logic.

The right CMS will give you the capability. But that is only part (and a really small one) of what is needed to be successful in this strategy. The bigger, harder part is designing, implementing, and testing the rules behind this logic. How would you treat a visitor differently if you knew his context? The fact is that you still don't know the visitor and what he wants. Context may give you a clue or a hint, but you can't be sure. You can only make assumptions and these assumptions may be very wrong.

These assumptions are like any stereotype. Sometimes they are accurate and you look like you have some kind of sixth sense. But when they are wrong, you better be prepared for damage control because you can look like an idiot and frustrate people. Success with a context-based strategy, or any other personalization depends on 1) knowing the likelihood of being wrong, 2) knowing when you were actually wrong, and 3) recovering from a mistake.

Let's take these elements in a concrete example. Let's say you work for a movie theater company and have a theory that the mobile visitors to your website only want to see showtimes and directions. One of your customers sees a help wanted sign at one of the theaters with a link for information on how to apply. This young applicant's only computer is a smart phone (an increasingly common phenomenon). He goes to the website and is redirected to a mini-site that only has show times and directions. He can't get to the desktop version of the site with job information. You just lost a job applicant and embarrassed yourself.

Running through the tests.... You might think it was a reasonable assumption to only show certain information to mobile users, but if you were not absolutely sure, you could have put a link to the full site and suppressed the redirect logic. How would you know about this incident? Are you tracking clicks on that "desktop version" link? Was there a place to leave feedback? Or will that incident only be seen as a bounce in your traffic report? If you figured out what happened, what are you going to do about it? Do you have the resources to correct mistaken assumptions and continually improve the behavior of the site(s)?

I really like Tom and what he has done at Ektron since he joined. In particular, Tom has helped focus Ektron and elevate the discussion about serving audiences. Buyers should definitely listen to these ideas but be aware that supporting context-aware visitor experiences adds cost to the initial implementation and ongoing maintenance. There is more logic to test before you launch the new site; but the real effort is after deployment when you have to constantly test and tune the logic as you see it respond to real users. You have to accept that context-driven logic has the potential to worsen visitor experience and be prepared to make corrections. This means having a team with the time and skills to monitor and adjust the logic. If you have access to that talent, you should be able to use context information to help deliver great visitor experiences.

CMS Selection Workshop Handout Published on Scribd

I just published my CMS Selection Workshop handout on Scribd. The handout contains:

• Examples of how to specify content types

• Example usage scenarios

• An example RFP table of contents

• An example vendor demo agenda

Enjoy!

CMS Selection Handout

Product Management Work Program

David Hobbs published a nice post describing how to define a work program for managing your website. The role of website product manager is near and dear to me. In fact, in my CMS Selection and Content Management Assessment projects, I get concerned about long term success if the client has not designated and empowered a strong product manager and a established a disciplined product management process.

What I like about David's process model is that it shows the components of the process and how competing requirements work through that process. The diagram is a nice visual for a product manager when receiving requirements and setting expectations.

What Game is your Team Playing?

I am trying to get a friend of mine to quit his job. No, I don't want him to join the massive ranks of the unemployed. I want him to move to a job that appreciates his talents and efforts. My friend (let's call him Bob) is totally dedicated to his profession. He is continually trying to improve his skills and productivity and wants to help his colleagues achieve better results too. Nobody brings more thought and interest to any task he faces. But he is surrounded on all sides by people who just don't care. They are satisfied by doing mediocre work. If something they build doesn't immediately fall over, they consider it done. If they can assign responsibility to someone else, they will. If nobody else notices a problem, it never happened.

It's frustrating for Bob. He can't accomplish his goals without help or at least cooperation. His company doesn't recognize the difference between his performance and that of his peers. In fact, he is constantly getting passed over. It doesn't feel fair. But it is fair. Bob is just playing the wrong game. Queue the metaphor...

Imagine that you are a world class tennis player. You live and breath tennis. You go into every volley trying to do your best and to improve upon the last one. You invest in coaching and resources to improve your game. If something might help you play better, (like a different diet, a different racket, or even one of those magnetic bracelets) you will try it.

One day, a friend challenges you to a game of Wii Tennis. You start to play tennis as you know how. Your knees are bent. You move your feet. You swing with explosive power. You are playing great tennis... but you are losing. You look over and you see your friend. He is slumped on the couch barely moving his controller with a flick of wrist. He looks like he couldn't walk across a tennis court without losing his breath.

As pathetic as he looks, Wii thinks your opponent is a better tennis player. Wii doesn't care about his form, his position, or how much leverage he has over the ball. Wii only cares about timing and maybe a couple other factors. Your friends knows this and he is not wasting any energy on what Wii doesn't care about. Your friend is the better Wii Tennis player because he has figured out how to do less but still satisfy the minimal inputs that Wii has been programmed to observe.

Bob is trying to play real tennis in his company's Wii Tennis tournament. He is not exactly losing, but he should be winning. The frustrating part is that he could be doing a lot less and get the same results. When he is on a team, he is constantly questioning whether he should be compensating for others by fixing their work — like in a doubles game when you see your partner is not running so you cover more of the court. His extra efforts only result in bumping into things and annoying people who just want to "sit on the couch and casually wave their hands."

Now the big question: who is playing the wrong game? It is difficult to tell if Bob's company would perform better if it paid attention to the finer aspects of how people worked and measured performance more holistically. It is unknown whether the company's customers would appreciate a higher quality product. But there are two things I know. 1) Bob wants to play real tennis, not Wii Tennis. 2) He doesn't have the clout to change the game that the rest of the company is playing.

The reason why I am writing this post on this blog is that I think that this story is very relevant to the pursuit of any type of organizational change, be it adopting Agile development or Enterprise 2.0. Companies can delude themselves into thinking they are playing a different game than they actually are. They may think they have a bunch of real tennis players who are striving for excellence and victory on a dynamic playing field; instead, they have a bunch of Wii tennis players who are looking for ways to minimize their personal/professional investment to only what is recognized. These companies get confused when they put a tool or way of working out in the wild and nobody adopts it; they shouldn't be.

Organizational change is much harder with the Wii Tennis company because you have to actively incentivize every behavior you want to see. It is not enough to say "this will make our company more effective." You have to say "do this specific thing and get points towards your performance review;" and you better not be lying because Wii Tennis players will see right through that. Finding real tennis players like Bob is hard to do — especially if you work for a large company. Real tennis players need a lot of room to move around and large companies tend to compartmentalize people. They need to be challenged in different ways to keep things interesting. Their rewards need to be tied to company achievement. Plus, other employees will get annoyed when you change the game that they have gotten so good at.

When building a company or even just a team within a company, think about what game you are playing. If your industry is commoditized and the difference between average and excellent is under appreciated by the market, it may pay to go after the Wii Tennis players and be very specific about expectations and incentives. If you are competing in a dynamic industry with a large upside, build a team of competitors who will take ownership of optimizing their personal performances and also the effectiveness of the overall team. They will innovate and try new tools and techniques that are offered. Most importantly, they will not stop a practice if it is difficult to do — they will only stop if it is ineffective or if they find something more effective.

Is your organization's digital presence "house poor?"

Occasionally when I do content management assessments I run into what I call the "house poor syndrome." This is when an organization builds a website it does not have the resources to maintain.

Here is the metaphor.

Imagine you have been saving for years to build your dream house. You lived in a rundown house for longer than you would have liked in order to put together as much money as you can; and you collected quite a sum of cash given your income. With this pile of savings you bring in the best architect and contractor and the three of you get swept up in a vision of what an ideal house would be like.

The concept grows. The architect puts in all the latest features he has seen in his architectural magazines. The contractor says things like, "if you think you might want a heated three car garage, it would be cheaper to put it in when we pour the foundation." Pretty soon you have something worthy of your wildest dreams — at least on paper

Then construction starts and unexpected details start ballooning out the expected cost. Forgotten but really necessary items (like a drainage system) need to be put in. By the time you are done, you are way over budget but you can just swing it. You can't really go back out now anyway.

On move-in day you have this grand house and you are excited. Your old furniture looks a little shabby and awkward in the new rooms. Some "future use" rooms don't have any furniture at all but that's OK because you will get to them in due time.

Then a few years go by. You can't afford to heat those rooms let alone furnish them. The elegant landscaping is overgrown. You don't have time to weed those beds. You have made some home repairs yourself and the results are worthy of There I Fixed It. You don't have plumbing skills and you can't afford a plumber. The windows are dirty, every surface is dusty... well, you get the picture.

By this time you realize you are in over your head. The contractor and architect know this too — they don't bring their prospective customers to your home for site visits any more. There is a reason why only the ridiculously rich live in houses like these.

Now, lets think about how that experience parallels a website project.

• You got wrapped up in a dreaming exercise with designers and engineers that want to build something beautiful (with your money) that is a monument to their talents.

• You based your vision on the websites of companies with lots of money.

• You didn't think about the content that you have (your furniture) and how it might fit. Paragraphs of "lorem ipsum" were replaced by one sentence on an otherwise empty page. You still have images with iStockPhoto watermarks in them.

• You overestimated your available time to create content. After a year, the blog still has only one post; the "what's new" section hasn't changed in months.

• You overestimated your skills to maintain the website — the outdated flash promotions, the broken HTML, the awkward looking label images with the slightly wrong color and font.

• You paid for functionality that you can't afford to use or promote: the empty customer forum.

Like with houses, you see organizations "downsize" their websites by migrating to simple tools like Wordpress and keeping things simple. If your resources are constrained, a neat and tidy small site looks much better than a dilapidated mega-site. But, like with an underwater house, it does cost money to get out of an outsized website. More importantly, you have to make peace with your constraints and set your sites to more realistic goals.

But you can save yourself this expensive excursion beyond your limits by taking a practical view during the requirements and scoping phases and think ahead to how you are going to support that content and functionality. When you see whiz-bang Flash elements, ask how will you be able to modify them. When you see esoteric fonts in the style guide and a lot of image labels, ask who is going to produce them and how. In short, think of yourself living with and maintaining every feature you entertain in your fantasy. You could save yourself a nightmare.

PHP + JCR = PHPCR

My former colleague Lukas Kahwe Smith recently gave me a update on what is happening with the PHPCR initiative. Readers of this blog might remember me make a brief mention of PHPCR and the Jackalope implementation. My initial response was that I was unsure of whether the idea would take off but now I am pretty impressed with what I heard from Lukas.

Lukas and his team from Liip AG have been contributing to Jackalope as part of a large custom, content-centric web application they are building for a client using Symfony2. Jackalope goes beyond standard relational database persistence by providing sophisticated content services like content hierarchy, tree traversal, versioning, and content staging — common weaknesses in homebrew CMSs.

I can see a number of benefits to a PHP developer using PHPCR

• There is less to build than when working directly against a REST interface like Apache Sling. You don't have to worry about making requests and marshaling XML or JSON into programmable PHP objects.

• Your code can store any type of data in the JCR (not just documents). Using CMIS would be a bit of a stretch for anything but document data. Liip has developed an object-to-JCR node mapping layer (called phpcr-odm. Part of the Doctrine project) that behaves like a PHP ORM service.

• The persistence engine is abstracted so you can swap it out with something that meets your performance needs. Jackalope ships with Apache JackRabbit but there are also transports in the works for MongoDB and standard SQL databases. They should be mature by the end of the year.

• You can use PHP to build delivery tiers and other web applications using content managed in a JCR-based CMS (such as Adobe CQ5, HippoCMS, or Magnolia).

If you are building a content-centric web application in PHP, and you find yourself doing unnatural things to a relational database to meet your requirements, consider using Jackalope or the Midgard PHPCR implementation (which is designed more for speed). You are probably already be using Lucene for search indexing, how much trouble can one more Java application be to manage on your infrastructure?

Why CMS Implementations Are Getting More Expensive

Adriaan Bloem is starting to hear both customers and vendors estimate implementation costs to be 7-8 times software licensing costs. That is a big increase over the old budgeting rule of thumb which was 4-5 times licensing fees. I am not saying that there was a sudden increase, but I had been holding onto that old number for a long time so the new number came as a bit of a shock.

My immediate reaction was to try to explain the increase and I thought I would share some of my ideas here.

• Sites and technologies are getting more sophisticated. We have come a long way from the old world of static publishing. Now we are building interactive content applications that can be constantly tuned to optimize visitor experience and maximize business value. The tools have come a long way to support this but that doesn't mean that everything comes out of the box. Every new feature and option requires design, configuration/customization, testing, and management. The market is buying potential and the vendors are selling it — but realizing that potential isn't free.

• Document management is no longer bringing down the average. Back when I heard the 4-5x estimate, it seemed that was across web content management, document management, and digital asset management. Back then many document management projects had minimal implementation effort. There was basic functionality that came out of the box that didn't need to be (or couldn't be) configured. You just had to configure what metadata was captured, roles and permissions, and, for that nice touch of customization, add the client logo. That was OK because it didn't really matter if Company A's document management system looked nearly identical to Company B's. Not only am I seeing more web content management these days, but document management is getting more web-like. Leading the charge is SharePoint, which you use to create an interactive web site out of your documents (plus a whole lot more). Understandably, SharePoint implementations are very expensive. I am seeing the same thing with digital asset management systems that allow you to create an eCommerce-like site to browse through and collect assets.

• The technologies are getting cheaper. Content technologies are coming down in price — not just because of the pricing pressure from open source. The market is maturing and that leads to commoditization and competition. The super high-end products which commanded ridiculously high license fees are quickly becoming irrelevant and being acquired by infrastructure companies for maintenance annuities rather than sales potential. When buyers are using cheaper technologies to build more sophisticated websites, the implementation/license multiplier is going to go up.

The net of all of this is that buyers are seeing the potential of content and are investing in building solutions that can realize that potential. The underlying software products are only part of those solutions, which also require strategy, execution, and continual attention to be successful.

CMS Selection Checklist

A few days ago, I was asked by a potential client to provide documentation on my CMS selection process. As readers of this blog know, I write a LOT of articles on the various aspects of selecting a content management system. Probably the most concise descriptions are these two: "Selecting a CMS" and "How to Select a CMS." These posts go pretty deep and I have many other posts that go deeper into the specific activities. But, I still felt like I was missing a nice clean (less bloggy) overview. To solve that problem, I put together this CMS Selection Checklist. The most fun part of writing the checklist was finding all the articles that I wrote over the years that discussed each element of the process. I also see areas where I can write more.

CMS Selection Checklist

Enjoy!

Publishing to mobile is more execution than platform

Mobile publishing functionality is becoming an increasingly important requirement for web content management (WCM) selections and I am starting to hear more customers ask "can this product do mobile?" The fact is, most WCMS have that core functionality built into their DNA since multi-format publishing has been going on since the beginning of time. In the early days it was publishing "printer friendly" versions, PDFs, portlets, or RSS (we only dreamed of mobile). Now we are talking layouts and navigation that are optimized for smaller screens. In fact, what differentiates a WCMS from a document management system is the "rendering" or "presentation" tier that takes structured content and applies a layout template to generate a formatted output. The specific purpose of the rendering tier is to be able to reuse content and publish to different formats.

Just because nearly all WCMSs have the foundation to support a decent experience for a mobile user, it doesn't mean mobile will come easily to your solution. Why? Because WCMSs are also very flexible and give you plenty of opportunity to shoot yourself in the foot. WCMSs allow you to model your content with enough structure to make it reusable, but they don't require it. You can still use a single generic content type and turn your WCMS into a 6 million dollar WYSIWYG editor. You can fail to keep your content DRY. If you committed these sins, your mobile project is when they will come home to roost.

While structured, reusable content is a key to success in mobile and nearly all WCMSs support some degree of content modeling, there are a few non-universal features that will make supporting mobile easier. Look out for these features when evaluating WCMSs.

• Configurable template selection rules. All WCMS should be able to associate presentation templates to content types. You should look for a platform that allows you to configure template selection rules based on criteria like the section of the site or the user agent (browser). Otherwise, you need to build complex switching logic into your display templates.

• Themes. A theme is a collection of templates that define a comprehensive style (layouts, behavior, font, palette, images, etc.) of the site. A theming model allows you to group templates that are used for a style. This makes themes interchangeable and selectable so you can manage a mobile theme (or multiple mobile themes for different devices). It is particularly helpful if the platform allows themes to override each other — similar to cascading style sheets. For example, you could have a base theme and specific themes that override selective elements of the base theme.

• Multi-site content sharing. Designing for mobile is not limited to layouts and styling. There is growing consensus around the value of having a separate site with content that mobile visitors are likely to want. This doesn't have to be fresh, mobile-only content. Rather, it is a subset of the main content with a simplified navigation. Some WCMSs will represent this mobile area as a different "site." Others will represent it as a folder in the hierarchy. Regardless of the semantics, you need to be able to have the same piece of content exist in both of those places at once. Different WCMSs use different metaphors to allow contributors to manage these placements: "locations," "aliases," "references." Some metaphors come more easily to contributors than others but all contributors need training to get it right.

Those are the key CMS features to look for. The rest is in the execution. In addition to content modeling, make sure you are working with a competent designer than knows mobile and web developers that know how to implement the design to make pages lightweight (for example: compressing HTML, CSS, and Javascript; using sprites for buttons and logos; and effective placement of script references to prevent blocking). Also don't forget to account for increased testing.

Content Management Assessment Worksheet

I uploaded this content management assessment worksheet up on Scribd a few weeks ago and buried a reference in another blog post. To make it easier to find, I am reposting it here. I would love for people to put their scores in the comments but I assume that most people would be too embarrassed to share. If you find this fun and interesting, you should take the the CMS Implementation Survey to anonymously share your experiences with others.

CMS Implementation Worksheet