When Microsoft began releasing betas of Internet Explorer 9 in 2010, Redmond's huge global user community quickly started uncovering various strengths and weaknesses of the new version. One demerit quickly emerged that still hasn't completely gone away: IE9 doesn't play well with certain versions of the popular rich text editor ("RTE") TinyMCE as well as its main competitor, FCK/CK.

TinyMCE is embedded in about half of the ~40 Web Content & Experience Management (WCXM) tools we evaluate. FCK and its successor CK can be found in many of the rest.

The TinyMCE community applied various fixes spanning a series of dot-releases. Unfortunately, problems with IE9 kept recurring, albeit fewer with each new TinyMCE release. The bigger issue for content contributors is that WCM vendors were often loathe to upgrade their editor with such frequency, especially since many if not most of them customize their TinyMCE instances, or give customers recourse to heavily customize the editor themselves.

Various WCXM tool communities started recommending different workarounds. Some suggested emulating IE8 (e.g., Plone, MODx), while other observers suggested modifications to some source .js files.

Meanwhile, a very similar set of events happened in the FCK editor community. A series of IE9-specific releases in 2011 to the more modern "CK" version seems to have addressed the major issues. Note however that not all FCK-bound vendors have migrated to CK.

I don't point this out to be critical of the TinyMCE or FCK/CK core develpers, who have tried to address problems as they cropped up. And most bugs seem to have been caused by non-standard behavior in Internet Explorer.

In fact, we have historically argued for deploying industry-standard RTEs like TinyMCE, FCK/CK, and Aloha (more about that last one in a future post). This is because they have proven far superior to the two major alternatives:

1. Thickish clients like Java applets and Flex-based interfaces
2. One-off RTEs developed by the WCXM vendor itself, an approach that usually brings longterm support problems and perishability risks

But the ongoing saga of IE9 and TinyMCE/FCK should give more evidence -- if any were needed -- that WCXM tools are never install-and-forget. Usability and reliability for content managers requires ongoing vigilance. Even if you employ a cloud service (like Salesforce.com, which embeds TinyMCE) you're still beholden to the decisions those vendors make with respect to key 3rd-party tools. Remember that in a multitenant environment, the workaround has to work for everyone, and if it doesn't work for you...well...tough luck.

So you need someone internally -- someone who understands the platform you've licensed -- looking out for the needs of your colleagues as tools and browsers both evolve. Who plays that role in your enterprise?