Authoring: November 2005 Archives

A user wrote the following question to the CMPros list, but didn't get much response, so I offer it here, with some initial thoughts. I would love to hear more ideas about this kind of thing, as I get queries like this at least a couple of times a year.

I write and manage content for a small non-profit (80+ employees). We’re just now implementing a CMS that’s basically a set of templates with no functionality for managing and scheduling content to ‘go into’ the templates.

I’ve tried doing all that with Outlook and Sharepoint, and they kinda work, but I’m hoping there’s something a lot better out there.

I suggested the server version of Microsoft Project. The Project server can interact with Outlook clients via Exchange Server, and it can also generate Web clients. For example, you could have a server version of Project running a very high level schedule, which could then provide prompts to the user community. These prompts could be emails, they could be emails with URLs, or they could be tasks sent to the user’s email account which then appear as either tasks or calendar events in the user’s outlook. I did this for a Web development team a couple of years ago, and another client has implemented something like this recently.

Of course, this doesn't address interaction of the Project server with the CMS, which in this case happens to be Enginuity from Pandora Systems.

Other thoughts and ideas? Feel free to email me as well as posting your comments here.

Jon Udell wrote yesterday that we should really be getting beyond the office document format debate swirling around the Massachusetts decision, because all heavy footprint authoring applications are headed for oblivion in our increasingly net-software-as-service world. (David Berlind also weighs in on the death of fat clients apps.) Tim Bray is skeptical because "... authoring software is hard." While my view of the ODF debate is much closer to Jon's than Tim's, I agree with Tim's caution here. While my coding skills were never in the league of either of these guys I have spent a lot of time working on authoring software, and more importantly, collecting requirements from users. Admittedly this was well before the Web existed, but what hasn't changed one bit, is the need for authoring software to meet a staggering array of complex user requirements. Authoring software has to be flexible and extendable to meet the always unanticipated user needs. Authoring software is hard, and differing formatting and integration requirements will keep it that way.

Note that extending software functionality is not unrelated to extending the encoding of the content, which reminds me that...

Ironically, the reason I agree with Tim here is exactly why I disagree with the ODF decision: extensibility should be the first requirement of a government decision on an open document standard, and ODF looks uncomfortably like a limited implementation. From a practical point of view, scope is critical, but as Jon says, "In theory, governments should mandate standards, not implementations." Perhaps the way to think about it is that governments should mandate standards (XML) but adopt implementations (form OASIS and Microsoft and perhaps others). Realistically there will be multiple versions (implementations) of each anyway, so a single implementation will never be enough.