CMSWatch

A press release was sent to me today with the title "SDL Tridion Puts Online Forms at the Heart of Interaction." Which made me smile, in a nostalgic sort of way.

Nowadays, when we discuss interaction, we tend to quickly drift off to social media, networking, or collaboration. How do you deal with those bidirectional (or rather, multidirectional) streams of interacting content? Is a Web CMS really suited for this, especially those (like Tridion) that emphasize "publishing to" a delivery tier (in other words, pushing out the content like a fire-and-forget thing)? It's not something you can reduce to "here's the form, so there's your interaction."

For sure, web forms are often more important (and more complex) than you'd think at first glance. However, the Tridion module doesn't actually process the form content, store it, or create a workflow around it. It just allows you to create the forms themselves, "to manipulate the form as if it were just another type of web content." Useful as that may be, it's quite different from actually managing the interaction.

So if web forms are at the heart of Tridion's interaction, as the company's marketing suggests, that's a bit like Kafka 2.0. At least now, you can send in really pretty forms. In triplicate.

The greater Boston area, no stranger to the Web CMS world (with companies like Percussion, PaperThin, Telerik US, and Refresh Software already based in the area), is about to add yet another content management mainstay to its denizens: Switzerland-based Day Software has announced it will move its US Headquarters to Boston (from Newport Beach, CA) on December 1.

Kevin Cochrane, Day’s chief marketing officer, explained the move by saying: “It’s just inefficient for us to be anywhere other than Boston," adding that “the majority of the partners we need to work with today in the Enterprise 2.0 and Web 2.0 universe are in the Boston area...”

Day's relocation of its US headquarters to an area known for high technology probably makes good business sense, but Boston is also a hotbed of tech startups, IPOs, and merger-and-acquisition activity (or was, before the economic downturn). One wonders if Day might also be relocating to Boston to have easier access to capital markets and/or potential suitors.

Certainly, many of Day's activities over the past two years are consistent with those of a company primping itself in anticipation of sale -- including installation of new leadership. The company got a new CEO, Erik Hansen (formerly with Interwoven), in May 2008. Later that year, Kevin Cochrane (another Interwoven alumnus) joined Day as its CMO. In August 2009, Day got a new Chairman of the Board when Barry Bycoff was elected to replace Michael Moppert.

In tandem with the personnel alignments, the company showed a convincing return to profitability in the first half of 2009 (following the release of Day Communiqué 5.1, and a sudden surge of  "sloshover" business from the disruptions caused by the Interwoven and Vignette buyouts).

Late in 2008, Day sold off its UK agency services subsidiary, MarketingNet, to advertising company WAA. Exactly the sort of thing that could be seen as a "trimming down" effort to clean up the balance sheet in anticipation of making the company suitor-ready.

Interestingly, before joining Interwoven, CEO Erik Hansen had been VP of Sales in EMEA for Netegrity, Inc. (the enterprise security software company which was acquired by Computer Associates in 2004). Netegrity, in turn, was founded by Day Chairman Barry Bycoff -- who lives in Boston.

With the current economic down-cycle approaching (some would say it has actually passed) its nadir, there is bound to be a vigorous M&A market when investment capital finds its way back into the tech market. Companies positioned to catch the first wave of this capital may find themselves in an enviable position if too much capital chases too few opportunities. That may be exactly what Bycoff & Co. have in mind.

Who knows? 2010 may be an even sunnier year for Day than 2009 was -- if that's possible.

Today we release some new ECM research. It focuses (as does much of our broader research) on the so called mid-market. ‘Mid’ is a terribly misleading term as it conjures up the idea that this is the average, sub-par section of the market. In fact, this is the single most important, vibrant, and sizable section of the market. It is from here that the majority of ECM (Document Management) solutions are procured and where many of the most interesting and innovative products emerge.

In our most recent research we have added evaluations for Docuware, FileBound, Westbrook, and Fabasoft. They are all worthy competitors alongside established players such as Laserfiche, Hyland, SpringCM, and Alfresco. As you can see, mid-market ECM buyers have a bevy of options to compare against the biggest name in mid-market ECM players, SharePoint.

Last year I blogged about several free enterprise search solutions, and it looks Coveo is now bringing coffee to the free beer party I described back then. A couple of weeks ago the vendor announced "Expresso," "your free entry to enterprise search."

As always, "free" sounds too good to be true, as anyone who has reached the 25,000 document limit of the free version of Ultraseek (now owned by Autonomy) can attest ("Reached your 25K document limit? Call Sales at 1-888-3287-EEK!"). In the case of Expresso, the limits are much more hip to the times: 50 users, 1 million emails and attachments, and 100,000 documents. The product won't suddenly stop functioning at those limits, just nag you about it, and what's more, the licenses for more users or documents are in the thousands of dollars (not tens or hundreds of thousands, as with Ultraseek.)

Of course, I had to try this out. Coveo claims you can get Expresso up and running in under 45 minutes; and I must admit that the hardest part was to get a new Windows Server VM running on my Mac. The actual install, and a first index run of some documents on my own server was completed in about 15 minutes. Just enough time for me to brew a Moka. And after that, it performs exactly as I'm used to with Coveo: a straightforward search interface, which immediately, out-of-the-box, facets on document metadata (like document type, date, author).

Still too good to be true? Well, yes. If there's one qualm I have with Expresso, it's that it's relatively limited. It's easy to get going, sure, but so is the full Coveo solution. If you want a trial run before comitting to the full CES, you're better off requesting a download for that, instead of trying to extrapolate from Expresso. (Actually, I find the full Coveo product is easier to use than Expresso -- CES already is one of the most straightforward solutions to implement of all that we evaluate in our Search & Information Access Report, and if you need to, you can dig into all the detailed controls -- Expresso has hidden all that.)

Expresso really is Coveo Enterprise Search -- light. If this really were coffee, it'd be black, no sugar, hold the milk. It's good espresso, no doubt -- it indexes file shares, Exchange, and SharePoint, and even offers a mobile interface. So if you're a small-to-medium business that runs all things Microsoft, you should certainly give Expresso a go. However, it doesn't, currently, index websites or other mailservers (let alone other sources). If your intranet isn't on SharePoint, and your email isn't on Exchange, you're not going to get a lot of value out of the software. Free or not.

We've recently updated how we evaluate the nuts and bolts of the forty-one Web CMS vendors we cover in our Web Content Management research. Specifically, we've expanded and re-organized our ratings categories. See the sample, right. To be sure, this is a supplement to our assessment of vendors' "fit" against different business scenarios. When developing a short-list, look to scenarios first, and then these ratings.

At a high level, we keep the same four main categories:

• Technology & Management Services
• Content Production Services (contributor-facing)
• Content Delivery and Interaction Services (visitor facing)
• Vendor Intangibles

Then we break down services into subcategories that attempt to match up to particular team members' concerns. For example, your system administrator might be more interested in performance than templating and integration. It'd be easy to think that all our customers read an entire 10- to 20-page chapter about a particular vendor, but you've told us that you wanted better segmentation of topics, especially between businesspeople keen to assess criteria like usability or e-marketing, and IT team members, who may bring different interests.

We've also added or modified several service descriptions

• Content Reuse gets addressed more directly. All vendors say they can do it; few support it as well as you might like (though you need to be careful what you wish for, since granular content re-use in particular can present serious management challenges).
• UI Accessibility became an official consideration, partly at the request of our public-sector subscribers. This refers to the accessibility of the content management interface itself, as opposed to the generated website. We had always covered this topic, but not as deeply as now, especially since vendors tend not to pay attention to it. You'll find a lot of check-minus scores there.
• Multi-site Management refers to a spectrum of services you may want to exploit to help you manage multiple properties from the same system instance.
• Friendly Output is also new as a first-class service, although we had covered some of the key issues previously. This segment covers criteria like friendly URLs, standards-based output, and the related issue of website accessibility. Much of the responsibility here will lie with your specific implementation, but it turns out that some Web CMS offerings natively support friendlier output than others.

"Vendor Intangibles" might look like a bit of an appendage, but we actually seem to spend more and more time on this with each update. I'll never tire of repeating: the vendor (or open source project) "fit" is at least as important as tool fit. Key factors of late include the growing importance of community-based support to help satisfy your broader support needs, as well as the breadth of any consulting partner channel for those Web CMS offerings that are more platform-like.

I hope you find this list useful as you consider your own needs and opportunities. As always, our generic ratings must be weighed against more contextual requirements. For explanations of how we arrive at those ratings, consult the narrative for each vendor evaluation.

Please feel free to share any feedback below.

At the Interop conference yesterday I heard a familiar refrain: "IT is the problem." The epithet was issued by a cloud computing guru, but you could replace "cloud computing" with nearly any emerging technology and hear the same thing. Enterprise IT just doesn't adopt new technologies as fast as many consultants and analysts would wish.

In this case, the argument was doubly specious because the cloud consultant: 1) accused IT managers of trying to subvert the business to keep their jobs (impugning motives is rarely a winning argument); and 2) accused IT managers of dragging their feet due to irrational security fears. Now, I have seen some poor decisions made in the name of security, but a careful assessment of enterprise data safety and business continuity in the face of still-emerging cloud models seems pretty sensible. Ironically, a customer panel preceding the consultants' session included an anecdote where a cloud customer lost service for two hours because another customer mis-behaved in what was supposed to be a nicely-walled environment.

The other arena where IT sometimes plays villain is among Enterprise 2.0 evangelists. Thankfully, this appears to be changing. In my experience, IT teams frequently have significant experience with -- and substantial enthusiasm for -- social computing. For every case where IT is holding up internal social computing initiatives, I can point you to several cases where IT is trying to push the business side to adopt these technologies more effectively. When IT fails here, it is often because they assume, incorrectly, that their non-tech peers will adopt social tools along familiar patterns (which almost by definition they won't).

Remember that IT teams are frequently more interested in emerging technologies than you know. But they are also held accountable for some old-school requirements....little stuff like: security, reliability, performance, continuity, cost-effectiveness, regulatory compliance, and the like. If you want your IT group to be more creative, then you also need to give them the freedom to experiment, too.

I was talking with one of our Web CMS Report subscribers today, someone who is leading a state government's effort to modernize its WCM system. The question arose as to how to keep vendors from giving softball answers to hardball questions when submitting a Request for Information. I proposed a simple expedient: Require screenshots.

If a product supports a certain type of functionality via a graphical user interface, the vendor should have no qualms about showing the UI in question, doing the operation in question. It's one thing to be told "Yes, our admin interface supports restricting a user's right to Copy or Move a file" (for example), but a picture, as they say, is worth a thousand workarounds.

What about when the vendor comes back with "This functionality is easily implemented via changes to a configuration file" (or via an API call)? Very well: In that case, let's see the relevant XML fragment (or code snippet) with the changes highlighted. Demand to see the relevant lines of code. Is that so much to ask?

Hey, the worst that could happen is that the vendor will skip past a few of your harder questions -- or complain that your RFI process is just too burdensome. In which case, you've already learned a great deal indeed.

Earlier this year I caused quite a stir when I predicted the death of taxonomies. Taxonomists worldwide told me I was an idiot, nuts, completely delusional. Some were deeply concerned that their jobs were threatened, as if employers would change org charts based on my prediction. Others secretly told me they agreed.

Of course, as so often happens in these dark days of 140-character tweets, my prediction was often taken out of context. I had predicted the death of traditional, monolithic, and single-hierarchy taxonomies, as well as the death of what I’d call the typical turn-of-the-21st-century taxonomy project (which I did dozens of times, as a former taxonomist), where librarians and/or linguists spend a few months in an organization determining how enterprise content should be categorized, so content technology could use it optimally. This project would usually be followed by an even longer period when people would admire the taxonomy, nod knowingly, saying “that’s exactly what we need!” - but not tag anything, despite the roadmap and project plan saying they should. 

As 2010 fast approaches, I’ve never been more sure of my prediction. Metadata continues to be vital, but technology is constantly getting better at mining and organizing it. As an example, this week I visited three organizations in Paris using Sinequa (one of the vendors we evaluate in our Search & Information Access research) on their intranets. In an approach similar to Endeca’s, entity extraction and semantic analysis create multi-faceted categorizations by people, country, city, language, companies, and other topics. Most of the content was unstructured; no taxonomy or tagging projects were undertaken.

“In over a hundred categorizations, we only have found two small errors in the past year,” said one implementer, from one of France’s largest wireless service providers. “We refine categorizations, but it takes very little time,” said another implementer at a systems integrator. “We wouldn’t have undertaken an enterprise taxonomy project because we never could have spent the time and money to write scripts or manually tag everything afterwards.”

Taxonomists might decry this as foolhardy; the fact is these companies achieved the results they wanted and increased the productivity and efficiency of their knowledge workers. These examples are not to say the technology is perfect -- far from it. My point is to reiterate that taxonomists need to adapt and work with technology to improve the results of what they can achieve for enterprises.

Also, the title “taxonomist” should die – as it pushes people into the mindset of fixed hierarchies and navigations, despite over a decade of efforts to change that. Evolve the title, I say, into a metadata architect, or an information cartographer. Those are far more descriptive of what this role must be -- and for the more savvy, already is -- as we move into the next decade.

Metadata architects can no longer get away with being topic generalists, they must be specialists in the industry content they’re refining and understand the end-user: what are the specialized topics that perhaps aren’t contained in content, that can’t be extracted, that would make knowledge workers more efficient? Another customer I met with this week, a large French government agency, pointed out the main thing their search tool couldn’t extract meaning from was acronyms. “We had to make a list of all the acronyms we use,” said the IT director. “Once we spelled out the acronyms, what they stood for and their synonyms, the software worked beautifully.”

Taking taxonomies beyond what technology can achieve on its own is the metadata architect’s challenge for the next decade, because technology is at the point where it achieves what taxonomists were doing a decade ago.

For buyers of technology, remember that different entity extraction and search tools are often geared towards different kinds of content; we detail this in our Search & Information Access product evaluation research. There’s also higher and lower-risk scenarios for allowing technology to do more vs. less work. Legal firms should have more categorization checks from a metadata architect or a content specialist, less so than a news agency where topics are more wide-reaching and less fraught with risk if an end-user doesn’t find something.

As I’m based in Europe this quarter, I’ll be missing Taxonomy Boot Camp in San Jose, CA for the first time in several years. Last year, the opening session devolved into a debate as to how to define a taxonomy and a taxonomist. This year, I propose embracing a new era of metadata architects, ones that work with technology rather than be willfully ignorant of its inner workings. It’s only by studying the “how” of technology just as much as the “what” of the content that we’ll get to the next stage of content management, search, and information access.
 

Last week I attended the J. Boye Aarhus 2009 conference in Aarhus Denmark. For me, the highlight of the event was the opportunity to kick off the Web Content Management track by serving on a panel with Janus Boye (a.k.a., @janusboye) and LBi's Jon Marks (a.k.a., @mcboof). The theme of this panel was "How do we fix WCM?" The session even had a Twitter hashtag - #fixwcm – where Jon crowd-sourced the Twitter community for their ideas.

While my fellow panelists brought up many cogent arguments for why web content management is broken, the most poignant moment of the session was when a gentleman in the front row of the audience told a story of picking a Web CMS and only after the implementation had started realizing that the organization had picked a system incapable of doing what they wanted to do. He told how his company did not do adequate research and due diligence when selecting the product and described the disaster that resulted when the project ultimately had to be stopped and delayed by two years and untold thousands of dollars.

Surely, this is an example of how WCM is broken, right? I say no.

WCM can be broken if an enterprise picks a system that is designed for different scenarios. WCM can be broken if a WCM vendor misleads potential buyers by embellishing their products' capabilities. WCM can be broken if a client's requirements or budget are unreasonable. WCM can be broken if an implementer or systems integrator doesn't configure, customize, or extend the system properly.

But, WCM is not inherently broken. Heading into 2010, the WCM marketplace is more vibrant than ever. In our recently released WCM research, we broke up 42 of the most significant WCM players into 5 tiers of systems: Complex Enterprise Platforms, Upper-Range Platforms, Mid-Range Platforms, Mid-Range Products, and Simpler Products. In each of these tiers, buyers have varying license, deployment, and technology options.

Buyers today can choose between platforms and products; traditionally installed, hosted, or pure SaaS deployment models; traditional license or the many flavors of open source; one of many pricing models; and a variety of vertical-specific expertise.

There is healthy competition among vendors and unlike some other markets, there is no one system dominating the WCM world. The web content management system buyer has a plethora of choices and options. I, for one, think this is a good thing.

We talk to a lot of Web CMS customers on a regular basis.  Each story is different, and there's a spectrum of satisfaction with the choices they've made.  Many customers are frustrated, but just as many can point to success stories.  Implementing content management in a fast-changing web environment is hard, but not impossible. 

So, is WCM perfect? No. But it is not broken either.

Many Web CMS products tout "in-context," wiki-like content editing as an important feature or enhancement. In-context means letting contributors create or edit content from within the context of the site, without actually having to retrieve a content item from the back-end and filling in long forms.

Not all vendors offer in-context editing, and many do so only partially.  You can find more about different vendors' support for in-context editing in our Web CMS Report.

To be sure, many products have allowed you perform in-context editing for some time now. However, the difference is that in the past, clicking on "edit" in the site would open up the back-end form, whereas now, you can typically make in-place changes right on the page.

From the point of view of usability and convenience, this is certainly useful. In fact, I see in-page editing actually becoming a "preferred content contributor interface" rather than just a "casual business user content contributor interface" of yesteryear.

The main problem I have with this approach, if used exclusively as recommended by some vendors, is that it goes against a basic tenet of Content Management -- to separate content from its presentation. Basically when you create content based on how it looks, you tend to think about only those fields that appear on that specific page. Consider the implications:

• What happens to those extra fields that do not appear but exist because of other reasons - administration, reporting, analytics, personalization, search and so on? They would either take default values or be ignored. Or perhaps someone else will enter those values later.
• When you enter content in context of a page, what happens if the content appears at different destinations with a different look and feel - say an intranet and public website? Even worse, what if the fields that appear on the Intranet are different from those that appear in the public website?
• Similarly, if an article appears on the home page with a few fields and on a detailed page with many other fields?
• And then what do you do if the look and feel is changed due to a redesign?

There are many other implications that we detail in our research reports.  Like everything else, there are obvious work-arounds as well as trade-off here, and the trick is to maintain a balance between in-context content contribution and more traditional content contribution.

Make sure that the WCM products you are evaluating support different mechanisms of content contribution: from form based, to in-context authorship, to integration with external products and automated ingestion. Also consider very carefully the scenarios and then enable appropriate roles with the right corresponding content entry mechanisms.  Not all contributors will require in-context editing.

Last week I attended J. Boye's 5th annual conference in Aarhus, Denmark, which always attracts a high quality of speakers, and (unlike many other conferences) focuses on case studies and end-user implementation challenges. Since we at CMS Watch focus our research on end users and technology buyers, we were elated that the conference provided a wealth of information on the current plight of website and intranet managers. Jarrod Gingras and I attended presentations and case studies given by Wipro and Philips, as well as CMS Watch advisory clients Nokia, the UK National Trust, and The British Museum.

Several themes repeated themselves:

• Getting people up to speed on technology, and training, is vital to adoption
• Waterfall project management and development methods don't allow for the agility needed to incorporate iterative testing and ongoing improvement of websites
• Many organizations are new to managing video and audio on websites, and these content types require special handling, and WCM technology often falls short
• Rich media improves website and brand engagement for all types of organizations
• Applying standards increases accessibility and makes code easier to maintain

For many these may seem like obvious points - and though the nodding was universal in the audience as case studies were presented, the application of change management, agile methodologies, and standards remains an ongoing challenge. It's often what keeps our advisors and consultants involved with our clients even after they've picked a technology.

As a buyer and end-user of content technologies, be sure to keep these at the forefront of your plans. They tend to get under-emphasized, and will contribute more to your success than the technology you choose. Also feel free to e-mail us if you have questions about how you might best apply standards, change management, or rich media on your organization's web site.

Also, note that J. Boye's 2010 Philadelphia conference is already booking speakers. We hope to see you there to continue the knowledge exchange.

My colleagues Tony Byrne and Shawn Shell (the lead analysts for our SharePoint Research ) recently reported on the hysteria generated around product announcements for SharePoint 2010 earlier this month in Las Vegas.

As subscribers who received our latest SharePoint advisory paper know, there is plenty to be excited about in SP2010, especially if you belong to the SharePoint channel of resellers, consultants, developers, and system integrators. But over the past few weeks I have been noticing something of a shadow side to this excitement.

I may well be wrong, but I am starting to get the distinct impression that the SharePoint bubble is about to burst. Or at the very least, that enthusiasm for SharePoint is waning and demand for the platform set will begin to plateau.

Discussions with a number of ECM practice leads at major SIs (System Integrators) have told me that SharePoint is no longer perceived as a silver bullet by larger enterprise customers. SIs report that many purchased licenses have not gotten deployed, and that some hard lessons were learned when SharePoint was allowed to grow at viral rates. Once bitten twice shy.

Without doubt SharePoint still has its fans within large organizations, but there is enough real world experience floating around now to recognize both SharePoint's strengths and its limitations. Many large deals that would have simply defaulted to Microsoft and SharePoint a year or two ago, instead go out to competitive tender. These are not my only data points, but they start to paint a picture.

SharePoint has been with us in one form or another for nearly 10 years now, longer if you consider SiteServer as its foundation point. It has been a huge success for Microsoft, and has without doubt transformed and invigorated not just the document management space, but at various times the portal, search, and collaboration sectors too. In terms of desktop integration and meeting the needs of end-users SharePoint has raised the bar.

But time moves on, and SharePoint is not the only horse in the race (to mix a metaphor). SharePoint's various features have never has been best-of-breed, and still aren't today. For the SMB market SharePoint will remain a leader for a long time to come, and it will continue to play a key role in larger organizations. But SharePoint is a product just like any other, and subject to the same laws of fashion that all IT products endure, and I am getting the distinct impression that rather than trailblazing in 2010, SharePoint will subsist among the ranks of many other worthy ECM competitors.

I've been covering IBM's search technology (for our Search and Information Access Research) for two years now, and I confess that I've never quite totally understood the strategy (if there is one) behind IBM OmniFind Yahoo! Edition (OYE).

OYE is the free, Apache Lucene-based search application that IBM has offered since 2006. IBM does have customers who pay for commercial support for OYE, and according to Big Blue there have been over 50,000 downloads of OYE to date. But OYE isn't something IBM pushes heavily, and Google's search appliance business hasn't suffered appreciably in the face of competition by OYE.

One wonders, then: Why bother offering something like OYE at all? What's the point in putting the "IBM OmniFind" moniker on a technology that is really mostly Lucene on the back end and Yahoo on the front end? It seems (on the surface) like rather a quick-and-easy way to try to get some of the "cool factor" from Lucene to rub off on OYE -- a kind of coolness by association.

It now seems likely that OYE was (among other things) an IBM testbed project for Lucene development, ahead of the eventual, inevitable Lucenization of the entire OmniFind family of products. And in fact an IBM rep told me that Big Blue will indeed be moving OmniFind Enterprise Edition to a Lucene-based core architecture eventually. This is big news from a number of standpoints. It's a huge endorsement (if Lucene needed any, at this point) of the open-source search engine's maturity and soundness; and it can only solidify Lucene's position of dominance in the open-source search firmament. It also brings Lucene and UIMA (Unstructured Information Management Architecture) closer together, hinting at the emergence (though not right away) of an industry-standard text analytics architecture.

A lot is at stake for IBM, too: The key pieces of IBM's information-access strategy -- including InfoSphere Content Assessment (ICA), InfoSphere Content Collector (ICC), and InfoSphere Classification Module (ICM) -- all employ the OmniFind Enterprise Edition search infrastructure in various ways. With Lucene and UIMA occupying center stage, IBM is betting a lot on this technology. 

What does it mean to you, the technology buyer? First, expect to see further significant investment in Lucene by the IT world -- and further blossoming of the technology ecosphere around Lucene -- as Lucene becomes the key enabling technology underneath a variety of content-analytics applications. A year from now, Lucene won't simply mean "search" -- it could become the enabling technology for content-analytics apps of various kinds (including some kinds that haven't even been envisioned yet).

Secondly, it may prompt the much-prophesied (but never realized) advent of a broad secondary ecosystem around UIMA: an ecosystem of parsers, annotators, and pluggable business rules.

Thirdly, we may see the emergence of a new wave of prospective standards around things like index formats, relevance, and tokenization.

And finally? Expect to see interesting arguments from the likes of Microsoft and Autonomy as to why their proprietary search solutions are better for you in the long run than more open architectures. It should make for an interesting discussion. Subscribers, stay tuned.

The much-awaited version 7 of Autonomy/Interwoven TeamSite finally seems to have been released by Autonomy. While we will cover the details shortly for our Web Content Management subscribers, the key changes come in a new Unified Administration Console for TeamSite and OpenDeploy, enhanced UI features including the ability to do in-context editing in a wiki-like fashion, and various other improvements. Autonomy has also deprecated Crystal Reports (a bummer, since some customers spent real money there) as well as iLog JRules. There's a substantial new emphasis on employing Autonomy IDOL throughout, including as a persistence tier for LiveSite. So if you are upgrading, these changes will impact you.

I say "seems to have been released" because Autonomy has been strangely quiet about it. Typically, when vendors release a new product or a major upgrade, there's a lot of noise: press releases, demos, conferences and so on. Nothing of this sort happened when Autonomy released upgrades to version 7.0 of TeamSite, LiveSite, and OpenDeploy.  This is not typical of Autonomy Marketing and so the question emerges....have they actually released it? The new version is available, but many customers as well as partners aren't even aware of it.

So whether you are a prospective customer planning to evaluate new products or an existing customer planning an upgrade, we would recommend that instead of moving to a dot zero release you hold on for a while or at least till the next point release of version 7 is announced. We'll have more to share in the coming months with our research subscribers.

Last week the catchily-named organization ICANN (Internet Corporation for Assigned Names and Numbers) announced that it had approved the use of Hindi, Mandarin, Hebrew, Korean, and twelve other languages -- that are not based on the Roman/Latin alphabet -- for use in domain names. It may not seem like much to most people in the USA or Europe, but in Asia, the Middle East, and Africa this news was was momentous.

Consider that you have been told about a source of near unlimited business, entertainment, and information, but to get access to it you have to read Korean... That is how the internet has appeared to the bulk of its users. Typing in domain names in characters you don't understand is a total roadblock for many. With this change the floodgates will likely open, bringing literally millions more users online -- those who have never used Roman characters in their daily lives.

Such an announcement will have implications for the world of web content management and e-commerce for sure. it will likely drive demand for technology to manage the increase in web content and the ever greater lingual fragmentation of that content. Something that will excite vendors for sure. For developers, business users, and implementers (the constituency of CMS Watch) the initial impact may be simply testing that your applications still work with non-Latin characters. Don't assume they do, as though most browsers can support all kinds of character sets, software applications are typically much more limited.

There are so many potential implications to this announcement. Implications that we can currently only guess at, with repercussions that may resonate over the next decade or so. In English-speaking regions we may not even see or even hear of much change, but the rest of the world (most of the world) will be busy building their own web, drawing in billions of new users, and spawning a new set of web teams (many of which will likely be bigger than ours). All of which could nonetheless remain quite invisible to us.

The (excellent) Enterprise 2.0 Conference concluded yesterday in San Francisco. Here are some thoughts on several of the key issues bandied about, including ROI, adoption, usability, SharePoint, and the evolving industry.

My first observation is that the conference vibe was much more practical, and much less like a religious revival meeting than previous Enterprise 2.0 events. Some gurus complained about a lack of passion and energy, but I think Andrew McAfee set a great tone in his keynote when he exhorted the audience to replace liberation theology with more realistic goals.

There was much discussion about creating business cases, and ROI in particular. Like many information management projects, demonstrating a financial return on social computing investments can be a fraught (and sometimes fake) exercise. Of course, that doesn't mean there isn't a true business case. When enterprises are successful at collaboration or social networking, usually it started with a leap of faith. However, to see what your CFO thinks of faith-based initiatives, read about this illuminating panel discussion. CFOs are right to ask for tight program management, business sponsorship, and real deliverables.

Which brings me to the next big theme: adoption. Many enterprises are struggling with employee adoption of social tools. So, this prompts me to ask -- perhaps unfairly -- what about the whole idea of "emergence"? Aren't these tools so cool, so fun, so essential to modern work, that they will sweep through the enterprise in a groundswell held back only by your troglodyte executives? It turns out that many social computing efforts are actually championed by C-level executives. This led several observers at the conference to blame power-hoarding middle managers for poor adoption. Maybe that's the case in some enterprises, but as a generalization it feels trite to me.

In fact, this whole debate reminds me of all the talk circa 2004 about getting better Intranet adoption. Enterprises had invested in pricey portal systems that employees rarely bothered to visit. Intranet managers learned over time to provide useful services that ease employees' daily tasks. Often what employees really wanted was a single simple application, like an online org chart. There's a lesson there.

I have another theory about the adoption conundrum: many of these tools (especially the big combo suites and platforms) are simply too hard to use. Social software vendors high on their own fumes claim their products can be adopted "without training." That's bunk. Our evaluation research finds usability varying widely among the products, with unexpectedly high requirements for employee training across the board. We also see a broad trend towards more complex, dashboard-style interfaces that appeal to information addicts like me (and maybe you), yet frequently induce vertigo in normal people.

The other big topic, of course, was SharePoint. This crowd was a bit more skeptical about SP2010 than I might have guessed. It turns out that many community and collaboration managers felt burned by SP2007, and they're cautious. At the same time, some of the larger and more successful case studies can point to SharePoint as the underlying platform -- albeit always heavily customized.

Speaking of customization, I'll end on a positive note. The services community around social/collaborative computing appears to be evolving at a healthy rate. It's still dominated by indie evangelists, but a broader consulting ecosystem is slowly developing. Companies range from boutique advisory firms who can help with key business issues, to small and large integrators with growing experience implementing complex systems. In other words, this is becoming a more "normal" technology space. This also means that social software vendors are going to have to learn how to run effective channel programs. Today, many vendors are quietly making very good coin providing "adoption" consulting and other non-technical services to customers at a time when I'd rather see them focus more on improving the scalability of their technology. Anyway, for you the customer, a maturing ecosystem is very good news.

Sometimes a secondary service or subsystem in a content management platform can gum everything up.  This came to mind when a couple of our advisory clients ran into trouble with some non-core -- but important -- services.

In one case a MAM (Marketing Asset Management) project became bogged down in expensive and time consuming technical issues regarding an associated search platform. In the other client's case, they eschewed a thorough, RFP-based selection process in favor of simply buying an additional module from their incumbent Web CMS vendor. This turned into a highly costly and difficult situation.

The common thread: both enterprises wrongly assumed that adding subsidiary functionality to a core system would be easy. In the former situation what was sold as an "out of the box" search connector proved anything but. In the latter, the additional module from an incumbent vendor was in fact something acquired from another vendor 5 years ago -- and a technology that has always refused to play nicely with their core ECM platform.

Unfortunately for these two clients the tail ended up wagging the dog, with all of their efforts  now focused on complex integrations that should on paper have been simple connections.

Suffice it to say that connectors can resemble "treacle soup." As for 'suites', all the major ECM vendors suites were in large part assembled by acquisition, for example Open Text, Autonomy, EMC, IBM have added key components to their "Suite" offerings by acquiring and then integrating outside technologies. Some pieces have integrated easily and successfully others have been more of a challenge. There are examples of Suites that have been built from the ground up - for example Objective and Hyland -- yet even these too have to integrate with heterogeneous computing environments and though homegrown, they have elements that are stronger and weaker than others.  In some cases bringing in best of breed outside technology to replace elements of major Suites makes good sense.

With the value of hindsight the MAM client should have realized sooner rather than later that their digital assets were in a mess, and bolting on a sophisticated search system was not a solution to that situation. Remember, chaos in chaos out. Further, due diligence regarding the search vendor and its "connectors" could have uncovered plenty of warnings.

Likewise the team that avoided the RFP process should also have done their homework better. Short circuiting the selection process will speed your project up in the short term, but experience from the field tells us that it can deliver negative mid and long term consequences - short circuiting the selection process simply short changes you the buyer and user in the long term.

Those of you in the content management world undoubtedly know about AIIM – the non-profit organization with a long history of providing education and other resources to help you address the challenges of managing enterprise content. AIIM is currently in the process of electing a new board member to join their current board.

This year, we have nominated my colleague, Alan Pelz Sharpe.

Alan would bring to the board more than 20 years of dedicated experience in the world of document and records management. He has been a user of document and records management technology, an implementer of major ECM systems, a consultant, and an industry analyst.

As the lead analyst on our Enterprise Content Management Report and as a consultant to major enterprises, Alan focuses on helping buyers of technology make the right decisions and gain maximum value from their ECM investments. His work is grounded in a truly international end user perspective, having regularly interviewed and advised hundreds of ECM end-users world-wide.

AIIM is asking for letters of support for the nominees. If you've received good advice via The ECM Report or Alan's musings in the CMS Watch blog, please consider sending a note of support to Jessica Lombardo, AIIM's Manager of Membership and Chapter Relations, at jlombardo@aiim.org by Tuesday, 22 September.

Thanks for your help!

Once upon a time, when people started building web content management systems that actually allowed you to manage the content (and not just publish it), there were hundreds of editors. Vendors were quick to recognize that while HTML was a lot easier than SGML, there weren't going to be a whole lot of people actually doing all of it directly in <h2>Hyper Text Markup Language</h2>.

But in updating our Web CMS Report, I've noticed a funny thing happened on the way to storing rich text in the repository. We used to describe a colorful smorgasbord of editors, each in their own way trying to emulate pre-2007 MS Word (or, in some cases, Word 2007). Every vendor would lend their own particular sense of style to the JavaScript buttons for bold and italics. Each would have its own way of editing tables, adding links, picking images. In short, this was a big differentiator, and something to describe at length.

And at that time, Internet Explorer had some handy features which allowed developers to quickly whip up a rich text editor. Netscape Navigator had lost the browser wars and represented a negligible percentage. Microsoft still had a fairly recent version of IE for Mac. And Linux, well, nobody used Linux on the desktop in the enterprise, really. In short, there was no real reason not to use the IE-specific functionality. Especially since building everything for an editor from scratch was a lot of hard work. And even for those who didn't use IE's niceties, there wasn't a real need to test on any other browsers.

Then came Firefox, and everything changed. And IE7 made it worse.

Suddenly, cross-browser compatibility was an issue again, and a developer-intensive one, at that (like I said, building a rich text editor is a lot more complicated than you'd think, and building one that works in every browser is nearly impossible). Vendors and open source projects alike were reeling from this changed reality. And fast-forwarding a few years, this means that by now, all but a few CMS products have thrown in the towel. You can have whatever UI you want, but the editor is likely going to be either TinyMCE or FCKeditor. (We're coming out with a matrix of vendors' editors shortly.)

Now, I could go on with a lengthy exposé on which is better for which purpose, but the differences are Tiny, and we describe them in our research, so FCK it. (I couldn't resist that). If you really want to, you can usually swap one out for the other -- though this will often take some effort, so make sure you have good reason to do so.

It's also tempting to discuss some of the less used alternatives, such as Ephox (which is used by many high-end systems because, as my colleague Kas Thomas tells me, it's considered "top-of-the-line," not in the least because of its extensive Java API.) Or Xinha, the successor to HTMLarea. Maybe .NET favorites Telerik RadEditor (now part of a larger set of .NET components, and therefore usually showing up in bespoke .NET applications) and Ektron's eWebEditPro (which used to be everywhere, but most vendors have probably decided they'd rather not pay a licensing fee to a competitor).

In the end though, if you're sitting through a vendor demo, watching some pre-sales engineer type in "Hello world," then changing it to bold, the question to ask is simple. Is this FCK or Tiny?

Only if it's something else should you check how it stacks up. Given the fact that both Tiny and FCK have their drawbacks, and the integration of either with a CMS is unlikely to be very tight, there are plenty of reasons why "something else" might be better or worse (and browser compatibility is just one of the highlights). But with many shortlists, you can move on to more pressing issues.

With the recent flurry in acquisitions, there's a lot of talk about consolidation in the web content management space. However, for every vendor acquired, there's a new product on the horizon. The real consolidation isn't in products or projects; it's in components. Know about Lucene and Solr; and Tiny or FCK -- and spend your time on the real differences.

At the Enterprise 2.0 conference this past June, I facilitated a session called "Social Software: Key Debates" -- and wrote a brief summary of the outcomes for EContent Magazine. They just put the column online here.

The four hottest topics turned out to be:

• Can social software consistently bring real ROI?
• Which category of tools is best: platforms, suites, or best of breed?
• Socialize existing applications, or invest in purpose-built social software?
• Should community managers be responsible for information life cycle management?

I'll be leading a similar session this November at the E2.0 conference in San Francisco, albeit with updated topics. What do you think we should debate? Comment below.