In a typically thoughtful post, Peter Sefton discusses the advantages and disadvantages of Wordpress as an authoring environment. I though I would clarify my feelings on this a little.

Previously, from our experience on Knowledge Blog suggests to us that the Wordpress environment is very poor for editing, something we have expressed in our process documentation.

I should be clear that this is in the context of knowledgeblog. Academics have their own way of working, and normally are used to this. They use tools which fit with their lifes. For example, Google docs is a good tool but, basically, useless if you do most of your paper writing on an plane. The same will be true for tools such as Annotum if it ever appears. It is hard to beat Word and email (or frequently dropbox nowadays).

Of course, there are other ways; for example Wordpress offers “A complete revision history of the document is maintained with the ability to roll-back to earlier versions”. But, then, so does Word with dropbox. And the Wordpress facilities are in no way comparable to the versioning that you get with latex, or asciidoc and Subversion or Git. Although, in practice, I rarely use versioning when authoring, and dropbox’s poor-mans roll-back is enough.

The only clear advantage of using Wordpress tools is that you don’t need a two stage publication process. But, the general idea behind blogs, is that publication does not happen often; it happens once, and then the post remains. This is in contrast to a Wiki, where using external editing tools is impractical at best. And the situation is very similar to current publication where PDF is the common medium.

My conclusion — there are lots of people, lots of use cases, and lots of requirements. I don’t say that authoring must be independent from the publication environment; I do say that publication environment must not require a single authoring tool. Fortunately, for the tools that we have created for kblog, we can afford to be agnostic. They will work integrated with Wordpress editing also. Still, I just spent 10 minutes longer making this post than I need to, to stop the shortcodes in Peter’s quote below from being kcite’d (check the source for the trick!), which was harder because I use asciidoc. There are going to be problems. Supporting a heterogenous environment is painful. I wish there were a perfect solution, but there there are just a set of messy compromises.

Peter also makes a second point about our plugins (and others): that is, that they are non-standard.

There are similar issues/risks with stuff like WordPress shortcodes such as KCite from KnowledgeBlogs. It’s a great tool for authors, allowing them to cite things in a rational way:

DOI Example – [cite source=’doi’]10.1021/jf904082b[/cite]

PMID example – [cite source=’pubmed’]17237047[/cite]

But it’s proprietary to a particular processing environment.

There is a risk of creating a new form of the proprietary lock-in we had up until recently (and arguably we still have) with document formats like Microsoft’s .doc.

— Peter Sefton

It’s a fair point, and one which I agree with. The last thing that we need is hundreds of independent shortcode or other syntaxes; I mean, imagine what a nightmare it would be if every single Wiki engine and text conversion tool used their own, almost identical, but slightly different and incompatible syntax. Hmmm.

We chose to use shortcodes for two highly pragmatic reasons. First, Wordpress has nice support for them. Building a shortcode handler is nice and simple and does not require us to build regexps (the first version did it by hand for one reason or another, and the regexps were painful). The second reason stems from our desire for a decoupled authoring environment. Shortcodes pass through the HTML publishing step without escaping; to use XML or HTML compliant mechanisms would require us to change, for example, the HTML export mechanism of Word. Not somewhere we wished to go.

In practice, however, I don’t think that this is a major problem, if the code is written carefully. With Mathjax-latex, the shortcodes are transfered into Mathjax syntax, then mathjax does the rest. The development version of kcite works this way — the shortcodes are translated into a span-tag based microformat, then the bibliography tools operate on the client to format the bibliography. So long as the code is crafted reasonable, it should not be dependant on Wordpress.