PubSweet events

Our next PubSweet event is coming up and we are laying down some new themes in an attempt to make the events even more valuable for the community. To give you a taste of what they look like, you can check out this post by Jure about the forthcoming PubSweet next week at EBI. The Organisation for Human Brain Mapping will be attending with their new platform dev for Aperture. Awesomeness.

Looking for Devs?

I just got asked by a buddy that runs a great dev shop if I knew of any interesting publishing projects. If you are looking for a crew let me know and I’ll put you in touch ūüôā

Also, Charlie Ablett is looking for new projects also. Great full stack dev, rails, js and many other talents. I’ve worked with Charlie and can vouch for her. Great person, great dev.

Its all about Workflow

I think I have written this many times but it’s super interesting to see the same issue repeated over and over. I often get approached by organisations that want to build a publishing platform. They typically, let’s say it’s at about 95% of these conversations, start with the questions like ‘will it be able to do X?’ – ‘X’ as it happens, turns into a big bucket of things. It ranges from ORCID login credentials, to ‘produce JATS’ to ‘could it do peer review?’ etc etc etc

They have¬†¬†a bucket list of features. The point I like to make is –¬†a publishing platform can do all of those things, but it’s not the technology that we should be talking about. We should be talking first about the problem you are trying to solve —¬†and the problem you are trying to solve is workflow. We should be talking about your workflow first – before technology even enters the conversation.

Workflow is the problem you are trying to solve and it should inform the technology you build. The technology can then be built to enable the workflow you want. If you approach it from the position of ‘technology first’ you are missing the point. If you want technology to help you, you first must understand the problem that you are trying to solve. And that problem is workflow.

Phasing out INK

When Coko was established, we developed a application¬† called INK. It was a publishing-orientated job manager. You could write ‘jobs’ and it would process them and manage the resources. By ‘job’ here I mean something computational such as converting a file from one format to another, analyzing content, validating formats, and so on.

INK has been around for 3 years and it has served Coko well. We developed it  with the talented Charlie Ablett. Charlie did an awesome job and if you are looking for a great full stack dev that specialises in Rails, I highly recommend Charlie.

INK is still being used,  but we are phasing it out and replacing it with a job manager built into PubSweet. The reasons for this are as follows (not in order of importance):

  1. to reduce dev costs for us (we are a small team) and for anyone wanting to run job processing we need to harmonise the tech stack. PubSweet is exclusively JavaScript while INK is Rails. So rather than rely on a specialist dev we can pass the work around our existing PubSweet team.
  2. INK is a complex stack. It relies on a lot of additional technologies that made it very hard to set up, though that hasn’t stopped people from setting it up!¬†However,¬†such things can be done a lot more simply these days, so we are opting now to take¬†an easier path now available to us.

At the time of first development,¬† the stack we used for INK was the right decision. PubSweet was also at an early stage, as was all the tech it relied on. JS on the server was emergent and there wasn’t the tech to run good job managers. At the same time we needed something to do the job and INK has served that purpose well.

Jure, the lead dev for PubSweet, has built out the new job runner and we have some scripts that now run the XSweet (docx->HTML) conversion scripts. You can see that code here:

EBI are integrating this for their PubSweet platform. After Editoria has hit its community milestones we will also flick it to the new system. The nice thing about all this is that you’ll be able to install (eg) Editoria and all the docx->html ingestion pipelines will work without needing to scramble for INK auth details.

We would be very lost without INK, and we have made great use of it. I want to again thank the equally amazing Charlie Ablett for the amazing INK.

coda: Charlie is often looking for interesting new projects. If you are looking for a great dev then let me know and I’ll put you in touch.

Wax List Management

Vid showing Wax lists at work. Might not seem a big deal but it’s been a long haul getting here. We now have fully customisable list management in Wax 1. Importantly though, it shows a fairly traditional list style with typical names (numbered list etc) but we have complete style control so you customise the styles for any number of named list types. Which means no arbitrary styling/list creation. Having this sort of named-style control and not using one ‘universal list’ type that you must manually identify and style when typesetting – is important for publishers. One list style-type does *not* rule them all. Nice work Christos.

Interesting Article on Siyavula

Article on an awesome project that I’ve been following for a long time and happy to consider as friends…

“Siyavula is known as a pioneer developer of high-quality free digital maths and science textbooks to address resource gaps and disadvantage in South African schools. This case study identifies the success factors which could be replicated in other contexts.”