jeudi 15 décembre 2005

Interwoven CPS and market segments In this InfoWorld story, Interwoven's CPS product is a good illustration of the ongoing separation between content production and content delivery in the (cough) ECM market. "... what will make IT executives take notice of CPS is that it operates as a single system of record for changes," says the article. Content delivery has become a pretty mature industry, especially in light of legislation like Sarbanes-Oxley. Interwoven's CPS product is part of the larger ECM sector, which shows its price tag: $50k per server. 9:22:40 PM   comment []

CMSWatch's "The Case For Agile Content Development" In this blog post, Tony Byrne at CMSWatch gives a quick rundown of his colleague Mark Baker's meme about agile content. In a series of posts from a few years back, Mark brings a nice, big, shining spotlight to a topic that really doesn't get enough discussion. Namely, CMS systems seem to take the fun out of writing. First, in Structured Content: What's in it for Writers, Mark reminds us that content management starts when someone who has something to say confronts the tool where she has to say it. Mark explains that he knows intimately (perhaps more than most CMS product builders) both sides of this equation. I really like the philosophy and viewpoint from which Mark approaches this critical and overlooked starting point of content management. This article is the first of a series of Revealing Truths(tm) brought to focus by Mark. First, a CMS should be about the process of writing. This is a messy process that doesn't always fit into the big-system, data-oriented forms approach that most CMS products seem to take. Look at the page for adding a document in a modern CMS. Out of the 500,000 pixels inside an average browser window, maybe 200,000 are available in the authoring spot. Most likely, you have to scroll to see the bottom of the authoring window, and quite possibly the toolbar scrolls out of view. When I first started on Kupu, when it was EpozNG, I wanted badly to focus exclusively on a single goal: "Improve the process of networked authoring." That is, make it fun to write, make the document the focus, make it productive to connect the document to other content in the system (images, hyperlinks, related items, whatever), and finally, make it reasonable to collaborate in real-time. Ultimately the need to make it work in a forms generator (Archetypes) outweighed this goal. I concede the point, as Archetypes is a primary selling point for the CMS. Still, I lament that the crystal-clear goal was diverted for the Plone integration of Kupu. (Silva retains most of this.) Mark next makes a deep point about context-sensitive authoring. "Very few people are willing to change the way they work in order to make somebody else's life easier." The "somebody else" he mentions refers to management, the CMS vendor, or the webmaster. The purpose of the tool isn't to give WYSIWYG display. Rather, he says, it is about task appropriateness for the context of the author. It has to make their life easier, otherwise it is "doomed". Mark also applies this to knowledge architecture, which is similar to the familiar pattern of workflows in CMS deployments. Consultants get paid twice: once to implement the "we can micromanage to universe" workflow dreamed up by the customer's management, and again to rip that out and put back the default, non-obtrusive, simple workflow. Authoring must make the author's life easier, not harder. In his third point, "All Pain, No Gain", Mark talks about cost and reward. If I'm an author, and I'm thinking about the words I'm writing, and you want me to fill in 10 fields which I don't care about, then you're interrupting my job. You're asking me for the "Coverage"? Why do I care about "coverage", I don't even know what it is! Mark says, wisely, that the tool has to give some tangible, visible payback for each burden it places that disrupts writing. I'll go 2 steps further: the payback has to be immediately visible and has to contribute to the ease of the author's use of the system. If you want people to tag content, for example, then design a high-speed, personalized navigation system that lets them browse their tags as part of the authoring tool. Most of the time when writing a new document, they'll want to refer to their own articles, as we're all closet narcissists, right? [wink] Basically, we need to trick people into providing structure. In What Does Your CMS Call This Guy?, Mark talks about overdesign in structure and naming. The CMS community trends towards machinery that helps the CMS, not machinery that helps the author. Sure, you want a 32-bit GUID as an opaque identifier for every "object", but try telling that to a civilian. Mark stresses that using naming conventions and structure that makes sense to the author is required to pull them into doing structure. He expands on this in Considering Fluency in XML Design. Finally, on his Analecta company site, Mark puts together these ideas together as Agile Content Development. His article discusses how manufacturing formalized the benefits of agile development, and how this is approached in software development. He then explores how this might work in development of a content management deployment for a customer. This is the part where I think Mark has hit a home run. As I read it, I thought: "This is the meme I've been waiting for." For whatever reason, content management has become a software exercise. I remember seeing a presentation at EuroOSCON by the "leader in open source ECM", from a long-time industry figure, and it was utterly dominated by big acronyms and big architectures. I don't recall any discussion of the experience of the author, nor adaptability. Certainly in the CMS worlds I'm familiar with, it is the same story: content development is software development. In the early days of Zope, you could design content "TTW" (through the web). You could answer questions about structure and suddenly, you had new kinds of content -- YOUR content -- that could be added to folders in the system. No programmers were involved, no special login permissions on the server, no database schemas to update. It was liberating to a certain class of user. For example, at a Major Media Company (alias: MMC) that was an early adopter of Zope and Digital Creations (my former company), there was a person in the newsroom entering content into a big, expensive, Vignette system. This person was, as Mark describes above, a context expert. He got disgusted, taught himself just enough TTW Zope to be agile, and built a replacement for the Vignette system. On his own time. In 6 weeks. And it was vastly superior, because it was a shoe that perfectly fit his newsroom's foot. This is the payback for agile content development. It isn't treated as a software exercise, because the people who know the software don't know the content...and vice versa. If you can treat large parts of the client's domain as content development, rather than software development, then you can let authors and client teams be in control. You can let them do the refactoring so necessary to agile content development. Alas, later in the history of Zope, the component folks decided that TTW was grotty and should be banished. There were good reasons for this...from their perspective. However, the miracle at the MMC described above is gone, gone, gone. So now, if you want to do a CMS rollout, you learn component architectures and write software. If you want to refactor "content", you modify software, install it on the server, and restart the site. I think the concept of "agile content development" is brilliant. It puts the discussion into a known structure with known audiences and benefits. I believe the time is right for this, as well as a return to joyful authoring. 11:20:36 AM   comment []

Plone and OpenID Brian Ellin announced Plone support for OpenID. The OpenID system gives distributed, decentralized authentication in a non-evil way. Brian setup a Plone site at 10:23:26 AM   comment []