We will provide more detailed guidance about these in a future advisory paper, but in the meantime, here are the key points to consider:

1. Which Devices to target: This obviously depends on your target audience and what constitutes a mobile device for you. While simple cell phones, PDAs, smartphones, and tablets are quite obvious, what may be less obvious are devices such as gaming consoles or even the good old television that can act as delivery channels in some contexts. In my previous organization, I worked on developing a strategy for a hospital that wanted to be able to stream patient data on a linux-based handheld device carried by docs. Even without going that deep into what constitutes a mobile device, at the very minimum, you will need to decide what kinds of phones and tablets you want to target. This includes both the form factor (or the size) and operating systems (iOS, Android, et.al.). We've discussed this issue in these blogs before:
   • Thinking Holistically Beyond the Smart Phone
   • Android Tablet or iPad
2. Mobile Apps, Web Apps, or Hybrids: There are many ways to develop applications and sites for mobile devices. So you'll need to decide whether you'll stick to browser-based web apps, create downloadable applications, or use both for different use cases. We provide some guidance on which option is suitable for specific use cases in our advisory paper Mobile-Enabling Enterprise Applications: Browser or Downloadable Apps? as well as number of blog posts like:
   • Different Ways for Building Mobile Apps
   • Mobile Apps are Dead. Long Live the Mobile Web
   • Mobile brings site-building tools back from the dead
   • Mobile - the Next Web CMS Frontier
   • DAM and mobile: should you go with a dedicated mobile app?
3. Existing tools or new ones: You probably already have numerous enterprise applications that  provide some sort of capabilities for building mobile applications or web sites. For example, many Document Management vendors provide device specific applications to access a subset of functionality provided by their tools. Similarly, for a mobile website, you could possibly use your existing Web Content Management (WCM) tool or a Portal tool. Alternatively, depending on your scenario, you could invest in a sophisticated mobile middleware framework:
   • Advisory: Adapting Your Content Management Platform for Mobile Delivery
   • Blog: An iPad for DM and RM?
   • Blog: FileNet P8 on your iPhone
4. Managing content for mobile site and related architectural Issues: Publishing a mobile site will raise additional issues related to content duplication, publishing, workflows, and presentation. So you will need to have a handle on technical issues such as:
   • Do you employ a separate repository for mobile content (and this duplicate content) or do you use a common content repository?
   • How do you publish content from your regular web production environment to mobile environment?
   • Do you repurpose or recreate content?
   • How do features such as in-context editing and rich text editors work for mobile websites?
5. What happens to existing websites and content:  You obviously would not want to throw away your existing site, especially if it was not developed a long ago. So it'll be important to understand how you'd reuse existing content or mobilize an existing website. There are many approaches and tools to do that but if you've followed some basic principals of content management -- such as separating your content from its presentation -- you should experience fewer problems here.

There are many more considerations -- such as information architecture and user experience in a mobile context, content migration, alternative development approaches, and so forth. Yet, addressing the key starter issues above will give you a good launch point in your mobile roadmap.

What has been your experience and what are the key issues you've faced? Please feel free to comment below, email or tweet me.

One big area of confusion lies around pasting content from Word. Yes, many people still want to do this, often for good reason. I've been mentoring several of our research customers through vendor demos lately, and in a simulated environment, Word copy-paste can demo pretty well. It's in the real world that problems start cropping up.

Vendors talk a lot about differentiating features, but when copy-pasting Word to HTML, you really just have two broad choices:

1. Retain visual fidelity, which means passing Office-specific mark-up through to the page
2. Maintain pure HTML standard mark-up, which inevitably means losing at least some visual fidelity upon paste

You can see where this is going: contributors tend to prefer the former; web and IT managers prefer the latter.

Incidentally, this challenge is not limited to Word. Try pasting some marked-up content from Google Docs into your CMS rich text editor, then view source and check out the funky extra mark-up.

Some vendors try to work around this by offering the contributor different choices at paste-time, often reflected as different tiny icons in the editor toolbar. That sounds promising, but requires careful education, and will lead to inconsistent behavior on your rendered pages.

If you have to train your colleagues one way or another, then I'd typically recommend defaulting to clean-HTML and show people how to fix the formatting as necessary within the editor itself. Yes, this could lead to more help-desk calls ("the editor is broken!"), but the point is to satisfy site visitors, and they want clean, light, accessible, readable pages.

In our evaluations of 40+ Web CMS vendors, we pay very careful attention to the authoring and editorial interfaces. Far from a commodity, the contributor experience can actually represent key differentiators among the tools. You need to watch carefully for things like homegrown rich text editors -- a clear warning sign. Or, you can ask us to watch for you. Either way, assess your choices carefully.

Exhibit A: copy/pasting from Microsoft's Word.

Where does content commonly come from when it's repurposed for the Web? Microsoft Office, which is pretty much the standard for office productivity applications. In fact, it's quite usual for editors to send in their content as Word documents -- with webmasters or web managers diligently copying all the text, and pasting it into a rich text editor within a CMS.

Or rather, pasting it in Notepad, and then pasting it into the editor. Because what Word leaves on the clipboard is Microsoft's interpretation of what HTML should look like -- and that's quite a mess. Redmond's proprietary tags routinely break pages and standard layouts. And then there's the separate problem of content encoding -- those magic quotes often don't translate too well. In short, Word doesn't really separate content and design -- one of the basic tenets of content management.

Most systems nowadays have some sort of solution to this. Popular rich text editors like CKEditor and TinyMCE have buttons to either paste plain text only (the equivalent of the Notepad intermediary) or "clean" the Word content. Alternatively, your CMS may offer filters that will try to scrub the HTML after it is saved.

Cleaning, however, never quite works. Either too much gets stripped, so tables or more complex document structures don't make it across; or too little, leaving us with a bunch of tags with unpredictable results. All of this is difficult to get right. (I know this all too well, having once tried my hand at writing an XSLT filter for the purpose. The horror!) Unrealistic expectations here can lead to many help-desk calls -- "the CMS screwed up my document" -- and the like.

The reality is that the only reliable way to get text from Office to the web editor is "text only" -- forget any formatting. That's what the Notepad-route does; and it's what Google's Chrome browser now does with CTRL + SHIFT + V.

It's fair to say only Microsoft could really fix this. How hard would it be to just paste minimal markup, instead of proprietary lingo? This isn't exactly rocket science, cold fusion, or teleportation. So, I asked the company.

The problem for Microsoft, of course, is that while pasting into web applications is common, pasting from one Office document to another is much, much more common. In those cases, you'll often want to preserve formatting, and according to Redmond, "the HTML clipboard format in Word is optimized for those scenarios." What's more, there's now the Office Web Apps -- so Microsoft enables pasting into those web versions of the Office suite with all formatting intact, too.

That's all fair, but what about the web editor and her tedious clean-up process? Well, according to Microsoft, "[Y]ou can save your documents as 'Web Page, Filtered' where the extra markup will be removed and you will be left with a simpler set of HTML markup." Alas, even filtered HTML is not entirely MS-free. 

So, there's a glimmer of hope, yet we remain pretty much were we've been the past decade on this problem. There is no single answer to something as simple as copying text from an Office document and pasting it into your CMS. Microsoft's solution is a bit cumbersome and incomplete, and Google's rips out tables and other content you may like to keep.

However, instead of blaming Microsoft for this, consider it a reminder. The trenches aren't glamorous, but it's where you're most likely to encounter hurdles. There are plenty more day-to-day obstacles to getting it right. And nobody's going to magically fix this for you any time soon.

1) Enterprise Content Management and Document Management will go their separate ways
This has largely happened, primarily because customers have persuaded vendors to (mostly) give up the ghost on "enterprise" content management and return to practical applications.

2) Faceted search will pervade enterprise applications
This has definitely happened, though what constitutes best practices is evolving (c.f., difference between SharePoint Search and FAST Search results).

3) Digital Asset Management vendors will focus on SharePoint integration over geographic expansion
Definitely. The North America / EMEA divide in this marketplace remains stark, while vendors push SharePoint "connectors" -- albeit of varying stages of maturity.

4) Mobile will come of age for Document Management and Enterprise Search
Yep, though that was an easy one; questions about usability, persistence, security, etc. still remain.

5) WCM vendors will give more love to Intranets
No, didn't happen. Wishful thinking.

6) Enterprises will lead thick client backlash
Yes, I think we are seeing the back-side of flex-based clients for enterprise applications.

7) Cloud alternatives will become pervasive
Sure, but that was another easy one.

8) Document Services will become an integrated part of ECM
Sort of. ECM vendors are starting to promote document composition services more, but integration with other document management systems remains thin.

9) Gadgets and Widgets will sweep the Portal world
Definitely true, and more interestingly, they are making inroads into the non-portal world.

10) Records Managers face renewed resistance
We argued that, "the movement for simple retention rather than detailed RM practices will continue to gain ground." And by that measure, I'd say yes.

11) Internal and external social and collaboration technologies will diverge
Yes, though to be honest, this has been an organic trend in the marketplace for a couple years, mitigated only by an emerging trend to extend some internal collaboration services to limited sets of external partners.

12) Multi-lingual requirements will rise to the fore
Sort of. This is obviously a long-term trend, yet some smaller vendors still suffer in delivering multi-lingual capabilities.

So, on the whole, we were 10 for 12. That's slightly better than 2009's 9 out of 12, though one might argue that the future is getting clearer rather than us becoming more prescient.

Meantime, stay on the look-out for our 2011 predictions, which promise to be a thought-provoking collection...

She had reason to be frustrated because:

• Some of the tools were not one-dimensional programs like twitter clients but more advanced solutions for things like communities of practice
• The same vendors who claimed their tools didn't require training had actually rolled out very sophisticated (read: complex) user interfaces with myriad options that confused some employees
• Her training budget was reduced amid broader corporate cuts -- in part because it "came last" in the project and thus remained available for pruning, but also because her execs believed...no one should need training
• She knew she needed to educate as well as train in any case

Now she faces a looming adoption problem for which she might well take the blame. What should she do next?

[P.S. I'll be leading a free webinar on contemporary trends in intranet technologies on Wednesday, 8 December, and will address some of the usability hurdles we see customers confronting.]

Vendors are especially excited, such that Product X is no longer a WCM offering but a "WEM Suite" now. But you should be forewarned that in their quest for improving presentation management, vendors are soft-pedaling many core CMS concepts which haven't really seen a lot of innovation in recent times, and this, too, could impact your website visitor experience.

The services that make up the "E" part have been around for a long time, including: analytics, multi-variate testing, landing page management, CRM integration, personalization, template management, social functionality, and so on.  So, we are witnessing a natural progression and not something drastically new. The big difference now is that -- while these features tended to come separately in the past -- the trend now is to more tightly integrate them with traditional WCM services.  In many cases, these additional features are natively provided by WCM vendors themselves as part of a larger package.

You don't have to look far to find examples. Clickability, one of the hosted WCM vendors that we cover in our WCM evaluation research, recently announced a new module called Website Marketing Accelerator (WMA).  It's targeted at B2B marketers, enabling them to focus more on visitor segmentation and targeting. Other vendors such as IBM, Day, Fatwire, Open Text-Vignette, Autonomy-Interwoven, SDL, Sitecore, Alterian, EPiServer, et. al., have also been promoting their so-called WEM capabilities rather than core content management functionality. Some of them have gone as far as changing their product names.

You can understand this new emphasis because in many scenarios, content managers want to manage the consumption and interaction experience -- and not just the production process. Also, experience management includes the sexy stuff: personalization, Rich Internet Applications (RIAs), Social applications, User Generated Content (UGC), and other Web 2.0 stuff, while core content management services entail less fancier features, such as authoring, workflow, library services, and publishing.

If you are new to Web Content Management, don't assume that vendors and consultants have figured the basic stuff out. In fact, as an industry we have not really solved some fundamental content production problems:

• Online authoring for most people, most of the time, is still a buggy and sometimes painful process
• It is still difficult for business users to create and participate in workflows
• Publishing from one environment to another still remains one of the most trickiest aspect to master
• Caching of web content remains a black art
• Issues related to standards and formats still plague the industry; You don't know if you'd be able to watch your home videos in 5 years time or not or whether the fonts and styles as you know them today will exist or not
• Many more challenges of content production, such as those related to multi-site management, content reuse, deployment, and so forth still remain tauntingly difficult

Don't get me wrong. It's important to manage visitor interaction, and often the best people to do this are content contributors and publishers. But you should know three things:

1. In the early days of WCM, systems typically followed the current all-bundled-in-one-system approach, and the long-term results were not always positive: reduced capabilities at system edges and and architectural inflexibility led to various knots that were difficult to untie.
2. Your WCM vendor may not be the right supplier for the varied services they are peddling today. Template management, native to your WCM tool? That's a good candidate. Blogs and wikis? Maybe. Testing and analytics? Probably not.
3. Above all, good content lies at the heart of good services and a constructive customer experience.

Vendors differ markedly in how they approach the "E" part. The pros and cons of your various choices constitute a large topic in itself, something that we cover in detail in our online Fundamentals of Web Content Management Technology course as well as our WCM evaluation research. So, call it WCM or WEM. The acronyms don't matter too much. Just remember: there is no point in having a great website front-end with content that's stale or fails to engage users in its own right. Get the production part down, or your visitors won't stick.

Initially, vendors were skeptical about providing information for a vendor neutral, independent analyst operation. Things have changed over the years, primarily because buyers like you have come to trust our evaluations as a complete and objective resource. The vendors are now more forthcoming with access to customers and solutions. It's made our job a lot easier, and it has also contributed to making the research more complete.

This is one of the big reasons I'm really pleased with the 5th edition we released earlier this month. It's been rounded out by lots of input from practitioners who are putting these solutions through their paces every day in large and small deployments and for both simple and complex analytics scenarios. My updates this year were also informed by my colleagues at Semphonic, who spend a lot of time "hands on" with Omniture, Webtrends, Coremetrics, Google Analytics, Yahoo! Analytics and Unica, and much of my own vendor selection work.

While we've seen change in the market over the last year, notably the acquisition of Omniture and Coremetrics, I don't think of this as consolidation. I think of this as part of a continuum in the evolution of analytics that was started when Google acquired Urchin, and continued with Yahoo's acquisition of IndexTools.  Specifically, these moves represent large, well-funded companies purchase analytics because of their perception that analytics can help them add value to their existing offerings and create upsell opportunities within their existing client base.

What I find interesting and perhaps more challenging from a consumer perspective, is that the base line functionality of these tools can no longer be taken in a vacuum, but has to be considered in context with the influence and direction of the larger company. So, the question you face in the future may go something like this: "I like Coremetrics functionality but I also like the idea of being able to embed Omniture tags in our Adobe Creative Suite content. What's the trade off if I go with one instead of the other?"

Trade offs in functionality and price already exist today. What I see frequently is that tool selection often comes down to nuanced differences in functionality and price. Sure, it sounds clever to say "all analytics tools are basically the same" or "you can get 80% of what you need from Google Analytics." But if you look really closely at the solutions you'll find small but important differences...differences that translate into solution acceptance or rejection by your user base (such as ease of use), or complete data analysis (such as ease of analytics data export).  

I think you'll find our evaluations helpful as you begin to explore those trade-offs.

So here's a tip. Your project team can mitigate the risk of alienating end-users by separating notions of "education" and "training." Training is something that cannot take place until a system is ready to use – usually later in the project. "Education" should begin as early as possible, and conducted in parallel with or before a technology implementation. 

Future users of any new system will almost always need education on key concepts.  In a Web CMS context, for example, key concepts would include everything from the basic, "what is content?" and "what are templates?" to explaining metadata and the impact it has on where and when content appears on the site.  Many of you reading this may think that everyone knows these basics, but trust me, they do not.

Alan and I recently helped a client create an education program for a major web content management overhaul being conducted in conjunction with a major front-end redesign.   This project marked a fundamental change in the way this enterprise manages and publishes content. Like many major CMS projects, business processes throughout the organization were substantially impacted. With more than a thousand stakeholders and users across seventy different countries, the project risked getting seen internally as simply just another in a long series of front-end redesigns that didn't really impact their daily work.

In a hands-on workshop that was purposefully a bit of fun (do NOT expect 1000+ people to get energized and ready to change over just another PowerPoint presentation), we were able to simulate how the current way of working was not sustainable, and showed the power of a new way of working. This education (remember: it wasn't system training) became the centerpiece of the company's global change management effort. Users were engaged with the project as the actual development was on-going. A rarity in these types of projects, we found end users thrilled to get included in the process, and excited to see how they could be a part of the company's fundamental change.

Projects that skimp on education and training usually do not launch smoothly. Users are inadequately prepared for their "new" jobs, and often take out their frustrations on the new system. Sometimes this leads to complete lack of adoption, or people using the system in ways it was never intended. While most project leaders tend to focus on budget and schedule, user satisfaction and their ability to adequately perform their jobs is the most meaningful metric for determining success or failure.

Focus your attention there.

To quote:

Workflow services can help minimize the cost and time required to coordinate common approval processes -- but only if the service does what you want it to do, and users don't "work around" the system....

Subscribers to our WCM and DAM research streams can download the workflow paper here.

From the introduction:

An important, yet rarely acknowledged architectural and product development shift has transpired over the past couple of years in the content technology marketplaces we cover. The debate has shifted from "Suite vs. Best of Breed" to "Platform vs. Product." This is partly a natural evolution in vendor marketing as technologies and marketplaces mature. Yet this shift also has profound implications for you, the customer. Beyond the normal criteria of cost, functional fit, and vendor fit, you need to assess a tool's position on the Platform-Product continuum against internal needs and capabilities.

The three-page briefing offers five specific steps your enterprise can take today to make sure you make the best technology choices for near-term and long-term success. To subscribe to our research so that you can receive advisories like this, contact us here.