Fires, Cars, everything

So, my last few days have had some unusual travel disruptions.

On Monday, there was a fire next door to my place in New Zealand. I was just leaving to rush to the airport at Kerikeri, about an hour and a half away. All was ok, but checking on the fire meant I missed my flight to Auckland, so I rebooked for Tuesday. On Tuesday, the plane was cancelled due to mechanical issues, so I rebooked for Wednesday.

On Wednesday I flew from Auckland to San Francisco, though the flight was delayed 5 hours. Someone had apparently forgotten to switch the body scanner on and so 53 people went through the scanner without actually being scanned. Problem is, they didn’t know which 53 people. So they cleared the entire international airport and rescanned everyone…

17 hrs later I got to San Francisco and had enough time to grab a drink with a friend, pack, and get up at 4am to fly to Los Angeles with Kristen (Coko) for a 2-day Cabbage Tree Method workshop I facilitated. The next day… flights canceled into SFO (San Francisco) due to the fires around the city …so we hired a car and drove back (6 hours). Giving just enough time to sleep, pack, and get a 9am flight to India…. which was delayed 1 hour leaving due to the fires… my stopover is 1.25hrs so it’s going to be tight…let’s see how it goes…

My Question for Today

So, I went out to Shippies for another surf today. It was awesome. On the way I was pondering a lot of Coko things. One thing in particular is on my mind – how do we change the solutions provision ecosystem in publishing today?

This is actually what Coko is all about – breaking down the legacy, big box, proprietary software lock-in that exists in the scholarly publishing sector today. But there are many things that need to change in order for this to happen and my mind is on one in particular.

The current situation is that publishers ‘buy in’ a solution. This comes with support for the software, hosting, deployment etc. Publishers only have a limited choice when it comes to selecting one of these solutions, each of which has been developed by a vendor and their own internal development staff. Hence, the developer market for publishing is pretty contained. But what if we could change that?

What if we could stimulate the current dev culture (and I’m being expansive with the use of ‘dev’ to include all those involved in the dev process, not just developers) to start working with publishers directly. What if every small town which has a university, which might have a small press or Journal of some description, did not have to look to the big software solution providers but could just ask their local dev shop to help them solve their publishing infrastructure needs…

What if we could decentralise the publishing development sector by empowering a whole lot of dev shops with the tools to build out publishing solutions for their local university?

Essentially, right now, this publisher development sector does not exist…dev shops don’t even know it is ‘a thing’…but if we could let them know and give them the tools to create it…. the change in the publishing sector could be exponential…

So I’m wondering how we could stimulate this to happen. What are the mechanisms we need to put into place to make this work?

Coko and Hindawi

for immediate release…

https://about.hindawi.com/opinion/hindawi-partners-with-the-collaborative-knowledge-foundation-to-develop-open-science-tools/

and

Which means we are partnering with key Open Access publishers eLife and Hindawi…pretty cool!

Surfn, but not with a browser

So, I have been surfing for about 3 months now. Which of course means I’m still really crap. But over that time it seems I have already surfed nice beach breaks in Costa Rica (where I did a one week surf school in July), reef breaks in Hawaii, some nice beach rollers in Linda Mar (down the road from my apartment in San Francisco, California), and a bit of fumbling around on various beaches in New Zealand.

And of course, today I discovered that one of the best point breaks in the world is just north of the Hokianga at Shipwreck Bay, otherwise known as ‘shippies’. A modest day today out there. A 3m swell today created these lovely lines… I think there were about a dozen people surfing…

dsc03254

dsc03255

dsc03264

I drove my car onto the beach and waxed up my new Walden 9ft 6 longboard…an amazing board…

It was an awesome day! Going out again tomorrow!

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.