Towards Web-based Word Processors p1

Working with publishers is fantastic because they are hardcore text workers. These people need a lot from their tools, in particular, they need a lot from the tools they use to edit and improve texts.

Typically this has been the realm of Microsoft Word. But there are very many reasons why we need to liberate the publishing world from this approach. I won’t list all the reasons here, but at the top of my personal list are the following:

  • MS Word forces publishers into an email-and-attachment workflow which is probably one of the single biggest problems in publishing workflows today
  • MS Word is not transparent to publishing systems. You cannot see what is being done by whom and when. You can only look back and reflect on what has been done (if you are lucky enough to have the most recent version)
  • MS Word is unstructured. This means that the display semantics (what you see) do not match the ‘under the hood’ document structure in any sane way. Ugh. I don’t know how to write about this without first saying ‘World of Pain’. Publishing needs (surprise!) nice clean structured content – even if only to make nice looking things to share (eg books) or, and this is where it really hurts, to share important information (eg scientifc research) that is machine-readable. MS Word really has caused the world so much hurt in this area and this issue in itself has slowed down the sharing of research and made the process unnecessarily expensive (and no, LaTeX is not the answer).
  • Publishers rely on extending MS Word through macros… well, you might think this is completely awesome because you can extend MS Word. Well…take a moment.. .exhale that cool aid…. this is just the worst situation imaginable. This forces publishers to resort to maintaining workstations (yes, physical spaces where you need to go to in order to be able to do your work) running the exact version of MS Word that still supports the critical macros some developer made (before they moved to some inner rural district and started their own microbrewery) so the publishing staff can do their work. If you are a publisher, you know this is true. If you are not, please believe me – I am not kidding. Not ideal.

Oh my… I was just getting started. I have to stop – the list is much longer and I’m not even sure I am really putting the most important issues at the top. The situation is that bad.

So… we need to liberate publishers, and (most other) humans, from this situation. So, what would be ideal? Well… imagine a situation where display semantics have a 100% reliable co-relation to the underlying structure of the document – so you could just look at a document and know it was well structured. Imagine a world where you, as a publisher, knew what stage the document was in your workflow without you (or your staff) having to send out emails to whoever has the latest version.. .imagine if you could ask staff to work on the document with the tools they need from anywhere in the world…. imagine if this situation was also customisable to the nth degree, that you could take control of your tools, own your tools, and that the tools where… wait for it….  free…

Interestingly, most publishers seem to think this is still crazy future-think. However, it is not so. We can do it.

The trick is for us to collaborate on open source products and to move beyond the idea that word processors belong to the desktop and everything online is just a text editor. We can’t fault people for thinking like that – it has largely been true. However at Coko, we are moving away from the idea of building web based text editors, and towards building web-based word processors.

This is an interesting proposition because web-based word processors are not exactly like the word processors you know today… what makes them different? That’s the subject for my next post on this topic!