This is a long-winded reply to a short retweet that came from Retail Week online editor Martin Stabe of a question from developer Mark Ng: "Journalists: do you think internet story research tools built into your CMS would be a good idea?"
My initial response was along the lines of "let's try walking before we start with the whole running thing". Content management systems promise much but frequently fail to deliver anything vaguely usable. Their biggest failing lies in the idea that you should work in them entirely, yet fail to provide tools that word processors have had for 20 years. And writing in them directly is like playing chicken: how long do you have in which to compose and edit a story before it loses all the copy?
Compare it with the situation with blogging software which is often better written - thanks to having more complaining users – and more flexible. I very rarely use the CMS that Movable Type provide. Instead, I write most posts in MarsEdit and then, to publish, use the XMLRPC function that it provides. It also lets me work offline, which is a major plus. It is something that most CMS writers fail to understand: reliable network connections are not always present, particularly when you are out and about.
So, the idea of forcing even more of my working day into the CMS fills me with dread. However, it doesn't mean that the idea of putting research tools into a CMS is an entirely bad one. It just depends what they are.
As Martin points out, Wordpress has plug-ins that help with linking to related stories. This is the kind of thing to include in a editorially focused CMS. Mark suggests storing notes in the CMS and then having the system go out and find information that relates to them.
The problem with this idea is that web research is often more useful early in the process. What's going on? Is this story actually news? Has someone already reported on this or something very similar? What's the background?
As you progress into research, the questions are much more focused. So the idea of having a tool go out and sift the web for more is nice to have but probably just going to contribute to information overload. In reality, you are going to be cross-checking individual claims from a set of interviews. And very rarely do I transcribe an entire interview from shorthand, just key quotes and references to important sections. I may scan the pages but that's just to make the notes easier to find later on.
I've found, for long-term storage, a private blog or a wiki as good as anything for holding transcriptions. The other useful tools are outliners and, occasionally, mind maps for structuring material and spreadsheets and databases for those situations where the story or feature revolves around numbers or timelines. If you are doing financial reporting, then a way of just adding quarterly results to a rolling spreadsheet is probably going to be handy. But, do you need to put that in a CMS or just stick it all in something like Google Docs? Probably, a database is going to be more useful as you have more flexible ways of querying the data.
One area where I think a CMS could make a difference would be if stories acquired more metadata. Again, this is an area fraught with difficulty as the last thing you want to do is force writers to add metadata just to keep the machines happy, which is what tends to happen today. But if you were able to do something akin to what Microsoft tried to do with Smart Tags earlier in the decade, I can see some advantages down the road. Instead of writing "Q4 revenues were $2.4bn", you point to the source data within the financial repository. When someone clicks on the tag, they get taken to a virtual P&L sheet which shows the same number and, if it all works properly, whether that number was later restated.
Similarly, you might tag people so that the system can log all stories about them and build dynamic timelines so you can see when they moved companies or said certain things. That would go some way to making the information that goes into stories more remixable. You don't create new stories from the parts, but you can at least extract some structured information that may prove useful to a reader.
Looking back at that, I think the future for an editorial CMS is less to do with research for the journalist per se but for all the people who might use a news site.