After over 10 years of working in content management, I have come to realize that there is only one way to learn the value of managing structured information: the hard way — and that way is only 50% effective. People can intellectually accept concepts like content re-use and content/layout separation, but in the heat of the moment, few can resist the siren song of a word processor and the clipboard. Pasting in a bunch of text into a rich text area (and then re-formatting it) provides so much more instant gratification than data entry into the fields of a structured content form. It is only after a number of painful global content changes that people come to realize that the value of all that painstaking WYSIWYG work has a very short shelf life. It is not until a migration onto another platform that one becomes aware of all that semi-redundant content. But that realization only happens around half the time. The other half of the time the site’s unmanageability is blamed on the CMS. A clear sign that the content manager didn’t make the connection is when there is a requirement that the new CMS have a global search and replace feature.
As someone who has seen many companies succeed and fail (and really fail) with content management, it is easy for me to notice these patterns. But that doesn’t mean that I can make anyone short-circuit his/her learning process. If I were able to forcefully impose a highly structured content model on a client, all they would notice was the complexity of the content entry forms. They would take for granted the downstream benefits. The best you can do is gently guide and hope that guidance will lead to recognition when the site becomes unmanageable. I don’t get too worked up about it. If I get frustrated, I can just talk to my friends in the DITA/XML advocate community. Their pain in working with technical documentation teams is way worse.
In the software development world, we have the concept of DRY (Don’t Repeat Yourself). The idea is “every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” I call the opposite of DRY WET (Write Everything Thrice) or DAMP (Developer Accepts Maintenance Problems. Hat tip to Brian Kelly). This means copying and pasting code (rather than referencing it) or writing the same data over and over again. Part of the development process is recognizing patterns and coming up with ways to reduce redundancy. Good developers are constantly thinking about maintaining the code they write because they will inevitably need to add a feature of fix a bug. And the feedback cycle is really short for developers. You write a bit of code, test it, fix it, write some more code, test that and the first code you wrote, fix it…. If you did anything stupid, the time you have to wait before suffering for it is usually short. I am not saying that all developers practice DRY, but they have a better track record than content contributors.
Most content contributors don’t have that short feedback loop. Too often, content is considered a “set it and forget it” initiative. You publish and move on. But I am seeing two positive trends in the content management industry that may shorten the feedback loop. First, there has been some great thought leadership around solving the “post launch paradigm”. Second, many CMS vendors are building in analytics and multivariate testing functionality that encourages the content manager to constantly tweak a website to maximum performance. My hope is that awareness of this functionality will compel buyers to think of their content in a more dynamic way — something that evolves and improves like software. Then maybe we will hear content managers talking about their websites being DRY, WET, or DAMP.



Will Day stay committed to web standards under Adobe’s ownership?
Wednesday, July 28th, 2010I JUST heard about Adobe’s acquisition of Day Software and have to admit my first reaction was total disappointment. I always admired Day’s commitment to architecture and standards. Day is one of the few upper upper tier web content management companies to stay focused on the web — not just as a place to dump files but as medium for information exchange and creativity. David Nuescheler and Roy Fielding seemed to have a vision for how systems could openly interoperate through lightweight architectures like REST and standards like the JCR. Day has also been a great contributor to the Java community by pushing lighter weight technologies like OSGi and server-side JavaScript to keep Java relevant in a trend toward dynamically typed, scripting languages like PHP, Python, and Ruby. Day promoted this vision through the products they sold and also by contributing to open source projects.
I feel the complete opposite about Adobe. Adobe seems more interested in conquering the web than improving it. While Adobe has contributed several technologies that lowered barriers to entry, I think the overall net impact has been negative. Yes we have more content on the web thanks to Adobe, but much of that content is locked in Adobe’s PDF and Flash formats where it is less accessible (and maintainable) than plain old DHTML. Adobe customers tend to overuse Adobe technologies like PDF for online forms when HTML would have done quite well. Flash-based navigation is also a problem; I can’t tell you how many restaurant websites I have been where you can’t link to a specific page because the whole site is one Flash movie. As a web consumer, how many hours have I waited for Acrobat reader to install/upgrade plugins (which further degrade performance) before allowing me to read PDFs that I clicked on? Expert tip: disable the PDFViewer plugin for Safari. Don’t even get me started on DreadWeaver.
As you can see, my frustration with Adobe has been building for quite some time. It felt good to let that out. I haven’t talked to David or Roy about Adobe so I don’t know their opinion of Adobe before or after the merger talks started. I hope that Adobe permits them (even better, supports them) to continue their good work in web-based architectures. More likely Adobe is buying Day for its CRX repository and CQ5’s workflow and digital asset management (DAM) functionality to connect creative teams using Adobe Creative Suite (Why couldn’t they have just bought vjoon or WoodWing?) If this is the case, I hope Adobe will invest more in web publishing than they did JRun.
Posted in commentary, day | 2 Comments »