Workflow Engineering

It has been so interesting to work through workflows with a variety of publishers. I’ve learned a lot from this process but there are two core learnings that keep coming back to me

  1. publishing workflows aren’t that complicated
  2. don’t design systems from the point of view of an article, design through the eye of the people involved in the process

Probably both of these need some explanation. First, I have worked with a number of publishers that cannot see their workflow clearly. That is actually quite normal and understandable as publishing workflows seem to take on a life of their own, each department soon is doing things few others understand in detail. But when considering building or adopting a new publishing tool, the software folks (often) talk to everyone in the organisation and carefully document all that needs to be done, in the order it needs to be done, and by whom’. This leads to a very crazy complex plotting of the journey of an (eg) article from submission to publishing. They then proceed to grapple with what appears to be a complex logical flow, with many eddies and cul de sacs, parallel processes, and contingencies. It all appears hopelessly complicated.

But publishing workflows aren’t as complicated as this kind of process will suggest. For example, I made this slide to describe the general workflow for a Journal:

screenshot-from-2017-09-30-19-35-50-1

This is pretty much the workflow for almost every journal. It is not that complex. If you take a specific journals flow and map it onto this you can see the workflow much more clearly and simply. For example, the following image maps the workflow of the Collabra Psychology journal onto the above:

screenshot-from-2017-09-30-19-39-06

You can see it’s pretty simple. However, if you went through the process of ‘auditing’ the workflow by querying all parties and trying to see what the path of the article was in system, and working out all the touch points and forks etc, you may imagine the workflow to be a lot more complicated than it actually is… in fact, you may even feel that the flow is so horribly complex it’s impossible to get a good handle on it.

Which leads me to the second point… I think it’s a bad idea to develop a system from the point of view of an article following a logical path. As per above, the system will become hopelessly complex and full of exceptions and if-then dependencies. This will lead to a system that is very complex, prescriptive, and hard to optimise. Instead, look through the eyes of the people involved in the workflow and imagine how you could make their job as simple as possible.

To help you get there try this exercise – imagine if all roles involved had just one browser window where they could do what they needed to do. What would the workflow look like then? Literally draw out these spaces on a single sheet of paper per space. Discipline yourself to this one space per role. Once you have done this, challenge yourself to imagine if two or more roles could use the same space… what would you need to change in order to achieve this? You might be surprised how much overlap there is…

For an example of what I mean, have a walk through this slideshow:

You can see we have encapsulated the entire workflow in a series of just 5 spaces, we may even collapse this to four.

Awesome post about Coko and Open Source in Scholarly Publishing

The following post is so ridiculous its actually pretty funny:

Naiveté Scene — Open Source vs. Scale in Scholarly Publishing

It is also kinda great because not only does the author exhibit an incredible lack of understanding of what Open Source is and how it is made, but it also shows that we are getting under the skin of the right people #mustbedoingsomethingright

Surfing and Stuff

I’m taking a holiday in Hawaii to surf and do nadda for a week. I hired a 9ft Walden Magic from Mikes Maui Beach House. Nice folks. Wind is up but I had a good day yesterday on some small waves.

In the meantime, Coko had a big announcement. Announced at COASP (Conference for Open Access Scholarly Publishers) by eLifes Mark Patterson. You can find the complete announcement here:

https://elifesciences.org/for-the-press/67d013c4/elife-and-collaborative-knowledge-foundation-partner-to-deliver-open-source-submission-and-peer-review-platform

In essence, eLife is building on top of PubSweet to build their new manuscript submission system. They will possibly re-use parts of the PubSweet components built for Collabra. That’s the beauty of the PubSweet ecosystem – you can reuse what you want, and build only the new stuff (significantly reducing the burden).

We are already collaborating with eLife and have been for some 4 weeks to refactor parts of PubSweet according to some excellent recommendations made by eLife and their dev partners YLD. They are all great people to work with.

Stay tuned, more interesting news to come!

I love Book Sprints

Sigh…I don’t have much to do with Book Sprints these days. It is its own company now, I’m still the owner and founder, but it is it’s own thing. It’s own thing run by some amazing folk. Anyways…photos like those you find here from a Book Sprint happening right now in Capetown make me miss it sorely!

https://www.flickr.com/photos/129798087@N03/albums/72157686618588024

Some samples from that album below.

36375029644_8474e2cb3f_z

36397459153_cd0fa218c1_z

37069587571_8c7f92ac23_z

37211952675_347e7a32f3_z

36814068670_2b01a9b834_z

37039827852_05f14a60b7_z

37069600851_87461cdce2_z