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!

Onto Journals…

We (at Coko) have been working with Collabra Psychology to develop a Manuscript Submission System with them. The cool thing is, we can re-use a lot of work that we put into Editoria since we built PubSweet with the notion of highly reusable components (on the frontend and backend)…

I find it so satisfying to see our ideas and hard work put into building systems with the ‘right level of abstraction’ paying off. We are pretty much putting together a cluster of tech that can be re-assembled to meet a huge variety of publishing workflows very quickly…

The platform is called ‘xpub’ for now and it’s looking pretty good. We were able to assemble a basic dashboard, submission page, and editor plus link it up to INK for MS Word -> HTML conversion in a matter of days. All still in early days but looking great.

Login page for our first Journal platform.
Login page for our first Journal platform.

You knew the day was coming … 🙂

The Case of the Missing Click

We are drilling down further into Editoria – currently running production workflow tests with the copy editors and authors involved. During this process we are discovering some interesting insights into how production editors work.

One such case is that Kate Warne and Cindy Fulton from UCP wanted to be able to double click on a name of a chapter in the book builder component (a segment of which is displayed below), inorder to open up that chapter in the editor…

2016-06-28_15-41-37

The interesting thing about this is that double clicks generally aren’t used in the web platform world. However, Kate and Cindy found they were constantly, out of habit, double clicking on the chapter names (but of course, nothing happened). This comes from their experience of working with MS Word documents on a file system (their computer). In these environments you do double click on the relevant .docx file to ‘open the chapter’.

I found this pretty interesting. It also exposes an interesting tension between what is generally considered standard user experience best practices for the web and established behavior (even if coming from another context). Many UX experts will go so far as to say double-click must die).

However, if Editoria did not support this, it would drive the production editors crazy as the behavior is so normal for them now. We will change Editoria’s behaviour to match their expectations.

Learning things like this is exactly why we use the Cabbage Tree Method to design software. Users are, after all, use case specialists and we should develop open source practices to involve them in the production design process as much as possible.