Good News From Europe PMC

 

2018

So… it’s been a bit of a year. I was pretty busy looking back. I think I spent about 9 months on the road. I did some surfing. Bought a fridge. Plus some other stuff… so…. looking back….

The year started with a yet-to-be formed PubSweet community. PubSweet is the underlying ‘open infrastructure’ piece of the puzzle that enables folks to build any kind of publishing workflow on top of it. It is used for books, micropubs, content aggregation, journals… a lot. But at the beginning of this year there was one org building on top of it – Coko. Now, we have 9 publishing organisations building on it and 13 or so platforms in play. All that in one year… can you imagine. It is phenomenal growth. The best thing is the feeling in the community is awesome. As Geoff Builder recently said at a Coko meet “I can’t say enough how amazing it is that you aren’t killing each other”… very true.

This kind of growth and goodwill didn’t happen over night. I’ve been involved in many open source projects where there is no noticeable growth at all over many years. In fact, it was by watching these projects and trying and failing myself a number of times that I learned how to make this work. I had a plan from the start and strategised this growth. There are a few key parts…  First… the proposition is transparent. It’s a no bullshit kinda thing. You can’t buy your way in, you can only be part of this community if you play nice. You must be upfront and work in good faith. If not, then we don’t want you. So it’s transparent, we require transparency, but it is required. If you aren’t transparent then see you later.

Another critical piece was to develop processes for consensus. We have a number of workgroups that have helped with this. We also have an RFC process and 3 meetings in person a year where more difficult stuff can be meted out. It works very well. It is all also, by design. You must intentionally design such stuff and I spent a lot of time working through these scenarios in my own head. It takes time because each community has its own character. You want to make sure you have the right resonance with your strategies and sometimes I need to ponder this stuff a lot, let it sit and then bring it about. Also necessary is to have leadership. I provide a lot of that but I also strategised very explicitly for Jure to be the central pin for the PubSweet community. He is an awesome leader of the PubSweet clan but also it must be noted that this doesn’t ‘just happen’. Jure and I spent a lot of time talking through these things, working out what sort of tone we needed, how to best enable people to feel they could be part of this while curating it so it’s not a free for all. Jure has really risen to the challenge and IMHO stands as a case study of good community leadership.

Andrew Smeall from Hindawi and Paul Shannon from eLife have been early leaders in this community. To have such goodwill and leadership from folks like Andrew and Paul is really amazing. They have been in boots ‘n all from the beginning and never blinked. They are heart n soul and mainstay keepers of the PubSweet community ‘way’. I feel very privileged to work with them.

Also at the beginning of the year, Editoria was alive but no books were being put through. We have since changed that with at least three scholarly publishers using it in production as well as Book Sprints using it (recently used in a World Wild Life Fund Book Sprint). We got there also by careful strategy. Alison McGonagle-O’Connell has been out there presenting, demo-ing, and explaining Editoria to all comers. Alison is a joy to work with and I admire her can-do immensely. She’s a tough cookie and now the wizard of Editoria. Alison has brought people closer to Editoria which peaked this year with a Editoria community event. We got about 35 people there and I facilitated the process (after designing the event loosely based on the PubSweet events). Critical was a newly designed Feature Proposal process. I had to design it so that publishers with no in house dev resources could ‘take ownership’ of the product and also so that publishers, rather than technicians, could write the proposals. We received 36 proposals in 2 weeks from 6 publishing orgs. Amazing. There is now a 3-month roadmap in play because of this.

xpub-collabra and perhaps micropubs will go through similar process transitions next year.

paged.js is also flourishing. I started the project with Shuttleworth funding in Feb and now it is integrated into Editoria and it has already been used for several books. It is also growing quite quickly as a community, some of this is ‘auto growth’ – growth that just occurs with no assist – and some of it is from the efforts of the paged.js crew – Fred Chasen, Julie Blanc and Julien Taquet. Julien in particular is proving to be a very good community leader in this area. They are an amazing crew doing amazing work. I don’t suffer from FOMO (fear of missing out) but I really regretted not being able to go to the paged.js workshops in Paris and Brussels in November. They looked amazing.

Then there is Wax…. the editor is growing fast. We had to rebuild it because the libs we were using were not supported and slow growing. But Christos knuckled down and got it done.. amazing. It is currently a one person endeavor but watch this space as I have plans for community growth around it next year.

XSweet, the XSLT docx-to-HTML converter is also going great guns. V2.0 with math support out in the next weeks. This more or less completes all the things we need form it and the lib will flick into a maintenance mode.

Then there is Workflow Sprints. The process I designed for helping publishers work though their workflow woes. It takes 1 day per org/workflow and has proven to be extremely effective. I’m now training facilitators to do this as it is proving popular and I can’t do them all next year if it comes down to that. Coko is also able to generate revenue from it which is cool.

Then there are design sessions which I still facilitate for various products including Editoria, xpub-collabra, and micropubs. All interesting projects and the design sessions are fun and sooooo effective. Who said publishers couldn’t design their own solutions? Not me…

Also this year I have been peripheral to the Book Sprints team. I gave up direct involvement when I got my Shuttleworth Fellowship. Thankfully Barbara was there to take the helm and has done an amazing job. We have had a couple of meetings this year and it has been awesome. We broke 1m NZ this year for the first time…amazing. Many people still don’t think it’s a real thing 😉

Also from Book Sprints we get many requests from people who love what we do but want ‘not a Book Sprint’…ie they have some other format/media/context etc they want to think about. So this year I have also founded SprintLabs to act as a bucket to put these experiments in… more on this in the new year.

Also this year I finished my Shuttleworth Fellowship having reached the 3 year maximum and became an alum. That was quite a moment. Strange thing is, I feel more a Shuttleworth Fellow now than I ever have 🙂

Needless to say my journey is unconventional. All this stuff is stuff people told me wasn’t possible. All of it. Book in 5 days, impossible! You can’t use browsers to typeset books! Headless modular publishing CMS – impossible! Publishing platforms are an intractable problem! You guys will never be able to build community, it just won’t work!

Yeah yeah. Fuckem.

And there was a lot of other stuff this year too. But honestly, where do I get the time? Where do I get the time to surf? I have no idea. One of the tricks though that I have learned is to trust the people you delegate stuff to. Create an environment for them to succeed and let them go. For the most part I just need to talk things through with them and help keep them and everything on course. They also have to go with my rather counter-intuitive, emergent, way of problem solving and doing things. If they can’t then it doesn’t work out, if they can then we do great things. Which means, of course, lots of travel is needed and talking to people. I am a great believer in remote teams but I am not a believer in remote-ness. If that makes sense. You gotta be close to people so they can trust you and you trust them when you aren’t there. Its for this reason some of our meetings happen on beaches 🙂

It is what it is. It’s been a huge year.

Still, got to make a surfboard this week and 2 Workflow Sprints to go (in the US)… no matter, I’ll be here in no time…

Feet up mate, Koutu
Feet up mate, Koutu

Intractable?

Scholarly publishing loves intractable problems. Building publishing platforms is often argued to be such a thing.

I think there’s a reasonable amount of skepticism here toward any claims to have solved what has been, for decades, an intractable set of problems. We’ve watched Wiley pour (estimated) tens of millions of dollars into building a platform, only to give up and purchase Atypon. We’ve watched Elsevier pour similar (estimated) amounts of money into building Evise, only to give up and purchase Aries. We’ve watched PLOS pour similar (estimated) amounts of money into building Aperta, only to give up and sign on with Aries.

David is talking to a belief in the scholarly publishing sector that publishing workflow platforms are an intractable problem. And yet, so the belief goes, Aries and others, have apparently ‘solved’ this problem.

Well, intractable problems aren’t ones that have been previously solved. So whats going on with this argument?

I’m guessing there is a lot of unspoken stuff embedded in this position. For example, I think that some take the ‘intractable problem’ line because they are feeling threatened. Pure and simple. Threatened by the current wave of interest and optimism around open source solutions in this sector. You can see this defensiveness at play in some articles and comments on Scholarly Kitchen. It’s not too hard to spot.

But all that aside, why not just take the argument on face value. What of this apparent intractableness? Let start by admitting, Aries and other systems, have not ‘solved’ publishing workflow. None of the publishers I know that use these systems celebrate them. So maybe it is true…publishing platforms are trying to solve an intractable set of problems…since no one has solved it yet…hoho…

Well, I’d say the reality is this:

  1. Existing platforms are trying to solve complex publishing workflow problems
  2. publishing workflow is not complex

Sum the two up and its easy to see that existing publishing platforms are trying to solve the wrong problems. They are trying to solve a complex set of problems when the actual problem is actually pretty simple. This kind of defective problem-solution context has too nasty outcomes:

  1. bad solutions – when you make a problem unnecessarily complex you design an unnecessarily complex solution. An unnecessarily complex solution is another way of saying a bad solution.
  2. a broken solution culture – bad solutions confuse the people you are trying to help. If the solution becomes mainstream it results, in turn, in a dysfunctional, and self perpetuating, circle of dependency between ‘vendor’ and ‘user’ – where the ‘unduly complex problem and resulting solution’ become the normative conceptualization of ‘how things are’.. Solve a problem badly and people will want you to solve it badly for a long time. That’s culture for you.

So, the big problem really is… what is the problem we are trying solve?

Workflow, in a word. Workflow is what we are trying to solve. How to get a paper from submission to publication. All the processes that occur in between those two points is what I refer to as workflow. What needs to be done, by who, and when. Thats the crux of it – this is what workflow is, that is what publishing platforms are trying to solve.

Perhaps it’s best to start there – to understand the workflow problem so we can design the best solution for it.

You can already see that when we take this view on the problem that designing good publishing platforms already feels a little more in reach. The problem space is not solved by some kind of complex magic performed by software developers. The problem is solved by first having a good understanding of workflow. Who does what and when. That’s it. Not too tricky to get your head around.

So how do we understand workflow? Well despite my philosophy degree, I’m not always a theorist, I’m also a pragmatist. The best way to understand what a publishing workflow is, is not to come up with some handy abstractions (although I’ve also done this), it is to ask a publisher.

I do this all the time. I travel to publishers and get all the folks involved in the publishing workflow in to a room and then ask them to go through it step by step.

0e7a0485

When all these folks are in the same room, I simply ask the group to step me through the workflow process starting at step one – author logs in to the submission system – right through to publication. I ask each step to be described in the format  – who does what. The ‘when’ is looked after by the order of steps.

There are usually a few circular steps, revisions and so forth, but it can all be captured in this simple process. It takes maybe 1.5 hours or so. At the end we have a complete picture of their workflow.

Now… if you were to design a system to capture the workflow as it is described at this point you would have a bad solution. Why? Because of this broken solutions culture I spoke about above. Current publishing platforms solve the problems badly and so we currently have bad workflows.

To avoid making overly complex, bad, solutions we need to first look at better understanding the problem. Can we look at a current workflow and reduce its complexity without losing anything? Thats the first step.

How do we do this? Well… the pragmatist enters the room again…. With the same group of people we can simply ask them to walk through an ideal workflow. I do the same thing… ask them to start with step one – author logs in to a submission system – and then walk through an ideal process step by step.

094a8844

What happens? Well, you would be surprised. In a few hours the same group has radically simplified their workflow without losing anything. It is, in effect, a lovely kind of lossless compression (I used to do a lot of streaming, and lossless compression is the holy grail!).

Recently, for example, I did this process with a publisher and reduced the steps from 41 to about 9. This is not uncommon.

So… as to intractable problems… imagine designing a system to encapsulate 41 steps. Now imagine designing one to solve 9.

Its not difficult to design a system for 9 steps. In fact, it’s pretty easy.

This is at the heart of the ‘intractable problem’ blah blah. Its just blah blah motivated by a lot of self interest, woolly thinking and a broken solutions culture. We have become trapped by these ideas as a sector. At the same time, publishing is itching to find a better way… however, we have (as David says) looked to see the solution as being software. The solution is not software, the solution is that we need to understand workflow better. If we can do that we can make better solutions.

Editoria Feature Proposals

Proposals now closed. Below is the synopsis of each proposal, cut and pasted from GitLab. Titles link to the GitLab issue. I didn’t copy across  any images, so where you see a reference to an image, please check the original item.

All items can be found in GitLab also of course:

https://gitlab.coko.foundation/editoria/editoria/issues

Create an account here: https://gitlab.coko.foundation/

1. Feature Proposal: Color code tracked changes by user

Feature request: Please display tracked changes in different colors by user.

The request originates from UCP for Editoria, where only three users are expected to be within a given book/chapter editing at any given time.

Suggest retaining the tooltip, too, but adding this additional ‘at a glance’ feature to allow editors to quickly see who entered which tracked change within a longer book where checking each change by tool tip would become time consuming.

2. Feature Proposal : enable “read only” chapter mode

Org: Book Sprints

User story: As an author, I want to review a chapter while someone else is editing it.

To do this, I’d like to click on a read-only link for each chapter in the book builder. It doesn’t matter about the layout of the content, it just needs to be readable so that I can read it without having to render the entire book. No edit tools or comment tools are necessary, just a read-only version. As many people as needed should be able to click on the read-only view. Ideally, the read-only link should appear next to the edit button, and be permanently available (no permissions necessary).

3. Feature Proposal : Indenting chapters in book builder

Org: Book Sprints

User story : As an author, I want to be able to see the difference between parts and chapters at one glance.

To do that, it would be great to indent the chapters more so that the difference is more easily visible.

4. Feature Proposal : Configure book builder to omit blue buttons

Org: Book Sprints

User story: As an author in a Book Sprint, I want the book builder to look as much as a table of content as possible. We do not upload word files in a Book Sprint, so we have no need for the blue buttons showing the upload status, therefore this UI element is unnecessary and distracting.

We would like to have the option to omit the blue buttons.

5. Feature Proposal: Autocomplete for adding book team roles

punctum books proposes an autocomplete feature when typing in names for book team roles (see attached image)

For example, when one of the possible users is Vincent it would be great if when I type Vinc it already suggests the rest of the name. Especially with large teams, this can be useful because you may not remember the exact spelling of each team member.

6. Feature Proposal: List User Roles under Users

In the overview of Users under the Users menu include the different roles these users fulfill in the different Books

For example, under Username Vincent I would see Production Editor of followed by a list, Author of followed by a list, etc. This allows a quick review of which Users are involved in which Books.

7. Feature Proposal: Error message when uploading incorrect file format

punctum books proposes: an error message when you try to upload a file format that is not DOCX (such DOC) rather than XSweet trying to process it and then crashing.

8. Feature Proposal: Toggle invisible characters in Wax

punctum books proposes a toggle for invisible characters in the Wax editor.

This would allow quick discovery of double spaces, returns instead of enters, correctly inserting em/en spaces, weird tabs, and so on.

9. Feature Proposal: Author Style

punctum books proposes: An additional Wax paragraph style “author.”

10. Feature Proposal: Automatic typographer’s quotes in Wax

punctum books proposes that Wax automatically uses typographer’s quotes (for now, until there is proper language control).

When typing single or double quotes in Wax, they are not formatted as typographer’s quotes

11. Feature proposal: Always show chapter name

punctum books proposes a feature that makes sure that the chapter name is always shown somewhere on the top of the page, so you know where you are.

12. Feature Proposal: Usernames allowed with special characters

punctum books proposes that usernames with underscores, periods, etc. are allowed.

Currently, it appears that no such usernames, such as “John_Doe” or “Paul.Smith” are allowed. When you try to create them, you get a 400 error without any further explanation.

13. Feature Proposal: Ask for first name and surname on sign up

punctum books proposes that new users are asked for first name and surname on signup.

Currently the only way to distinguish users is by username, and this becomes quickly problematic as the number of total collaborators on all book projects increases, especially if at some point users will start to make their own usernames which may not be directly comprehensible to Production Editors.

Registering first names and surnames allows for a better way of organizing users on the Users page.

14. Feature proposal: Kill automatic numbering in numbered list style

Proposed by University of California Press

Adding sequential numbers to text styled as a numbered list would be helpful if one were authoring in Editoria. However, authors who want a list numbered submit it that way in .docx files, so the automatic numbering feature in this style adds a duplicate set of numbers to list items.

15. Feature proposal: Front- and backmatter styles

Proposed by University of California Press

To move to the next stage of testing and put a whole book through Editoria, we need styles for frontmatter components and a few more backmatter ones.

I’d like a separate section each for front- and backmatter styles in the vertical styling toolbar, with the former at the top and the latter at the bottom. There do not need to be too many styles in each of these lists, since the styles in the other sections (display, general text, lists) should be context-sensitive (e.g., for backmatter level-head, use Heading 1).

Because the front- and backmatter styles are rarely used in body components, it would be great if those style lists could be collapsed. They should still be available because there are instances where one might want one of those styles in a body component (e.g., in an edited volume, you might have bibliographical listings at the end of a chapter).

FRONTMATTER Here are the (most of the) styles we need that are not currently accounted for in the other lists (I am not including toc styles–that’s coming in another feature request):

Half Title Title Subtitle Author [if Barbara’s proposal of adding an author style is implemented, I assume it would be in Display, and we could just use that] Publisher

Series Title Series Editor Series List

Copyright Page

Dedication

Frontmatter Signature

For the rest of the elements in frontmatter, we could use styles in other sections (on output, the system would impose the frontmatter versions of these elements):

BEP Book Prose Epigraph —> Epigraph: Prose

BEPSN BEP Source Note —> Source Note

BEPO Book Poetry Epigraph —> Epigraph: Poetry

BEPOSN BEPO Source Note —> Source Note

FMH Frontmatter Head —> Title

FMAU Frontmatter Author —> Author

FM1 Frontmatter 1 Head —> Heading 1

FMTXT Frontmatter Text —> General Text

FIL Frontmatter Illustration List —> Numbered list

FAB Frontmatter Abbreviation List   --->  Hoping we can add Abbreviations as a List style

BACKMATTER Here are the (most of the styles we need that are not currently accounted for in the other lists:

Bibliography Glossary Contributor list Index

For the rest of the elements in backmatter, we could use styles in other sections (on output, the system would impose the backmatter versions of these elements):

Appendix Number —> Number [assuming we add a number style to Display]

Appendix Title —> Title

Appendix Subtitle —> Subtitle

Backmatter Head —> Title

Backmatter 1 Head —> Heading 1

Backmatter 2 Head —> Heading 2

Backmatter 3 Head —> Heading 3

Backmatter Text —> General text

Backmatter Prose Extract —> Extract: Prose

Backmatter prose extract Source Note —> Source note

Backmatter poetry —> Extract: Poetry

Backmatter poetry Source Note —> Source note

BM Numbered List Extract —> List / Bulleted

BM Unnumbered List Extract —> List / Unnumbered

BM Bulleted List Extract —> List / bulleted

Chronology —> Hoping we can add Chronology as a List style

Backmatter Abbreviation List —> Hoping we can add Abbreviations as a List style

I realize there’s a lot here. Please let me know if clarification or rethinking is needed. Thanks!!

16. Feature proposal: Automatically generated table of contents

Proposed by the University of California Press

Although authors usually provide a toc with their manuscripts, we would like one to be generated from the book components. I do think a placeholder needs to be present in the book builder so it can be specified for pagination. It could say something like “Table of Contents will be generated on final output.”

For frontmatter, toc should include every component that follows the toc and use text with the style Title.

For body text, toc should list chapter number and text styled as Title, Subtitle, and (if there is one) Author.

For backmatter, toc should include every component and use text with the style Title.

When a book has backnotes (most of our titles), it is sometimes a little tricky to figure out where they go (they could be preceded in the backmatter by appendixes, abbreviation lists, etc.), so maybe the easiest thing to do is add a placeholder component to the backmatter with the heading Notes styled as Title and boilerplate language saying something like “Backnotes will be gathered here on final output.” That way, we could specify placement, pagination, and the title could pull into a generated toc.

17. Feature Proposal: Toolbar button to change case

Proposed by University of California Press

Authors often format display type in all caps. If the design specifies title case, we need to specify how letters are treated (e.g., articles and prepositions lowercased)–it is an editorial decision, not one that can be automated. Right now, the only option seems to be to retype text to remove cap formatting. It’s time-consuming and a chance for introducing errors. Word’s options are uppercase, lowercase, sentence case (first letter only capped), and title case (first letter of all words capped–gets you most of the way there).

18. Feature proposal: No global italics in BookBuilder component listings

Proposed by University of California Press

Display component names in Book Builder in roman, not italic, type (italic type really shouldn’t be used unless there is a reason). Allow italic type to be within the name. See, e.g., in UCP deployment Wickes / Bible and Poetry** chapter 1 title: Ephrem’s Madrashe on Faith in Context.

19. Feature proposal: Allow toggle to turn off reveal of spaces in record changes

Proposed by University of California Press

The revealed spaces between words make longer sections of inserted text difficult to read. Could we have a toggle to show these or not?

20. Feature Proposal—Media Library/Asset Manager

This is a placeholder feature proposal. Right now, Editoria expects camera-ready artwork to be placed inline in order to become a part of the book. At the moment, a caption can be included with the inserted artwork, but no additional metadata about the image. This feature would allow a user to insert artwork from a media library. The media library would be similar to WordPress’s media library and allow for media to be uploaded and inserted inline in a book via the Wax editor, which would then become part of the media library, or to be added directly to the media library. The media library would allow for some basic media editing as well. It should be a “media” library rather than an image library because ultimately Editoria should be able to support multimedia in addition to static images.

21. Feature Proposal—CSS Book Page Template Gallery

This is a placeholder feature request for a CSS template gallery that would allow users to select from a gallery of page templates that can be rendered to PDF using Editoria’s CSS/javascript-based automated typesetting process. These templates would include the following variables:

  • Page dimensions (translates to book trim size)
  • Display and text fonts
  • One or two-column designs
  • Various other differences

22. Feature Proposal—Epubcheck EPUB Output Validation

This is a placeholder feature request for Editoria to validate EPUBs produced by the system using the open source Epubcheck validation tool to validate the EPUB output for adherence to the EPUB standard.

23. Feature Proposal—Book-level (and perhaps chapter-level) metadata

This is a placeholder feature request for a mechanism to add a book and/or chapter-level metadata data entry mechanism to Editoria. This could be achieved either by integration with an API or export-drive feed from a publisher’s existing title management system or by adding a form to Editoria that would allow for the entry of this metadata. In some cases, this metadata will need to be added to create a valid EPUB file, so an MVP could include just those metadata elements necessary to create a valid EPUB. This would also be useful for output and distribution to other systems (e.g. a publisher’s digital asset management system).

24. Feature Proposal—Accessibility Validation and Tools

This is a placeholder feature proposal to develop tools for validating EPUB outputs against accessibility guidelines as codified by the W3C and other standards organizations. This could include anything from validating the inclusion of alt-text and alerting users to missing alt-text for images/media to validating whole book files against API-driven accessibility validation services such as those being developed by the DAISY consortium.

25. Feature Proposal: Allow components to move from body to front- or backmatter and vice versa

Longleaf Services proposes that component types be changeable. Currently, it’s possible to change the order of components within each type, but it is not possible to change the component type without deleting a file and reloading it. For example, Introductions are often moved from the main text into the front matter, and abbreviations lists are moved from front matter to the back matter. Being able to use the drag-and-drop function would be more efficient.

26. Feature Proposal: Add more information to the “Books” dashboard and make it sortable

Longleaf Services proposes that author name(s), team member names and roles, author name, and current status be visible for each project, and that the page be sortable.

Currently only the title of a project is visible, and projects are listed alphabetically. Team members tend to think of projects by author, not title, so being able to see the author will be helpful. Being able to see the other team members for each project, and what stage the project is in, will help in managing the work. Finally, as the number of projects increases, it’ll be useful to be able to sort out those that are complete from those still in progress. Being able to sort on other attributes, such as series or imprint for example, will also be helpful.

In the interest of conserving space, a user could click on the project title and the list of team members could appear, as it does when one clicks on “Team Manager” on the individual page for each project.

27. Feature Proposal: Provide a larger text box for inputting figure captions

Longleaf Services proposes the caption text box be enlarged. Currently only a limited amount of the caption text is visible; a larger text box would make reviewing/editing the text easier. If there is a total character count limit, it would be helpful to provide the number of characters remaining.

Additionally, perhaps we could encourage accessibility/alt-friendly caption or descriptive entry? Maybe above the text box there could be a suggestion such as, “Consider providing a caption that is accessibility/alt-text friendly.”

28. Feature proposal: Export parts of a book

punctum books proposed the option to export only parts of a book.

Currently, only an entire book can be exported through paged.js. It would be great if you could select on or more chapters for export, which again would be very useful for edited collections.

29. Feature proposal: discretionary hyphens

punctum books proposes an additional special character: a discretionary hyphen.

Foreign names such as Nietzsche are often broken off erroneously by automatic hyphenation, for example Niet-zsche. A discretionary hyphen is an invisible character that shows paged.js where to properly hyphenate a word or name.

30. Feature proposal: Inline semantic markup

punctum books proposes inline semantic markup in Wax.

Currently, there is an asymmetry between paragraph styles, which have semantic values (Title, etc.), and character styles, which have typographical values (italic). Especially with an eye on future export to InDesign formats, it’s important that italics for emphasis and italics for book title, for example, are separated.

At the same time, authors are usually not familiar with this type markup and it might cause confusion. I’m not entirely sure how to solve this practicality.

31. Feature Proposal: Language control

punctum proposes a language control feature.

I guess this is a big one, and not an enormous priority for us, but something that needs to exist in the future because we often work with multilingual books. There needs to be a way to signal that an entire chapter of part of a chapter is written in a certain language in order to properly control hyphenation (upon export) and interpunction, such as the type of quote marks (curly, fishhook), non-breaking spaces before colons/semicolons (in French etc.), writing direction (Arabic/Hebrew), etc.

32. Feature Proposal: Tag what you want in Wax

punctum books proposes a features that allows you to “tag what you want” in Wax.

This proposal is in line with (and expansion of) our proposal on inline semantic markup. The current number of standard paragraph and character styles is limited, and should remain so. However, there are frequently books that require custom definitions.

I suggest that in Wax you can add a new paragraph or character style by means of (+) button, prompting you to give the style a name (New Fancy Style), from which a slug is generated (new_fancy_style) that you can then define in CSS, and a simple display format in Wax (italic, bold, indent, etc.). The display format doesn’t have even to be matching or fancy, as long you can then control the tagged words/paragraphs in CSS.

33. Feature Proposal: Indexing tool

This is a proposal for an indexing tool, written from the perspective of an indexer, not a production editor. It would be great to have some feedback from the production side. I do not know what happens to an index after it is submitted to a press.

Ideally, Editoria should accommodate, or improve on, the two most common professional back of the book indexing methods:

  1. Writing and editing an index using the final page proofs. This method has multiple approaches, which includes a) marking the page proofs, then entering the headings and page numbers into an editor, and b) displaying the page proofs on a monitor, and entering the headings and page numbers directly into the indexing software/editor, which simplifies many aspects of the editing process and automates all of the formatting specifications, which can vary by publisher and or text.
  2. Embedded indexing, where an indexer can create an interactive/XML index by marking up/tagging the text during the production process for exporting with the final page proofs. While I’m not as familiar with embedded indexing, I am aware that there is a general sentiment among indexers that they do not produce the quality well-structured analyzed indexes desired for scholarly monographs. However, publishers cite benefits to the workflow. For example, first page proofs will be of the entire book, including a fully set index in page form; overall schedule time should be shorter; they have a fully usable index in whatever form the content is published in, now and in the future. Few indexers are trained in this method. If Editoria could simplify (GUI interface required) the process of compiling and editing a quality index during the production process, rather than as the final task before the book goes to press, it would be adopted widely. I’ve discovered a new commercial effort that claims to do this, but I haven’t used or seen it demonstrated, Index Manager.

METHOD 1, TRADITIONAL INDEXES Most indexes are created by professional freelance indexers (using one of the three highly sophisticated indexing software programs, Sky, Cindex and Macrex), who are hired by the authors. Freelancers may submit the final index file to the author or the production editor. Indexes are generally submitted to the press/author as a double-spaced single column file, with the requisite detailed formatting Feature_proposal-indexing_tool.docxSample_Index.RTF requirements. I do not know what production editors do with the index once it is received from the indexer, or how that process could be simplified for them.

  • Editoria should allow for an indexer to write and edit an index within Editoria using the final page proofs AND allow an indexer, or team manager, to submit into Editoria an RTF file of an index generated from the final page proofs

METHOD 2, EMBEDDED/XML INDEXES Any automated XML indexing tool should be able to handle these very basic and common indexing practices:

  • To create multiple index styles automatically – indented and run-on (examples can be supplied if necessary).
  • To create main headings and subheadings, including words and phrases that do not appear in the text.
  • To alphabetize all headings and subheadings and choose between letter-by-letter and word-by-word alphabetizing order.
  • To designate stop/ignored words in alphabetizing.
  • To create and auto-format cross reference style and placement, See and See also.
  • To indicate how page ranges should be handled (e.g., simple, aggressive, aggressive 2, Chicago, Chicago 2; examples of effects can be supplied if necessary).
  • To indicate the character to use between page numbers, hyphen or en dash.
  • Punctuation placement (commas, semicolons, colons) should be automated.
  • To indicate how many columns the index will be.
  • To generate an introductory note to describe special features of the index.

As mentioned above these are basic practices. Fine tuning some of the more complex aspects of constructing and editing an index would be an ongoing effort. They concern what occurs after completing the rough index, when an indexer edits it for structure, clarity and consistency, formats it to specifications, and proofreads it. Anything to simplify the XML-index editing and output process in Editoria would be an improvement over the current complex and time-consuming options that indexers currently have for XML-indexing that is not compatible with their indexing software programs.

I’ve attached a Word file of the proposal and a sample index, submitted to Cambridge.

34. Feature Proposal: Alert team members when workflow status changes

Longleaf Services proposes a function that allows team members to be notified when the status of a project changes—For example, “File _____ is available for editing”

I’d think an email alert would be best, as it doesn’t require the person to be logged into Editoria to see the notification: An author, for example, wouldn’t necessarily bother logging in unless they knew the file was ready for them.

If feasible, development-wise, it would be useful to let the Production Editor decide who (that is, which team member) should get the notifications for a project. There are instances in which one user (generally the PE) performs multiple functions, such as also being the copyeditor, and wouldn’t want/need the notification that a file is ready to edit.

35. Feature Proposal: Configurable archive options for completed / abandoned books

Attaching our sketch and some notes from the community meeting:

Completed / abandoned books need a long-term archiving solution, and users probably won’t want these titles cluttering up their Books Dashboard, so we propose a new ‘archive’ option on the Books Dashboard that would spawn a modal with options for where to send the archive and what to do with the dashboard entry. These options could be configured by an admin to connect to various preservation solutions (e.g. LOCKSS, Portico, FTP).

There was also some debate regarding whether this functionality made more sense at the Book Dashboard level, or at the final export step; though export is something that – at least while it’s functioning as a preview, which it is now – is used repeatedly, while archiving likely happens once.

… of course there might be cases where an archived book comes back to life, so there would need to be a way to enabled that, and / or perhaps a clone / fork feature (e.g. for a future edition).

36. Feature Proposal: Add a “Print” option

Longleaf Services proposes that the option to print be available.

Our pilot project requires that a print version of the final file be available to participating authors/presses to satisfy tenure committees, reviewers, and awards committees that don’t yet accept digital versions. Would it be possible to provide the option to download a project’s pdf version, next to the option to download the epub?

Article :”New advances in open source infrastructure support”

https://insights.uksg.org/articles/10.1629/uksg.442/

How can open source infrastructure support a modernized, accelerated book production workflow? The California Digital Library, the University of California Press and the Collaborative Knowledge Foundation collaborated to design a new platform – Editoria – to do exactly this, following a new user-driven design method to result in a simple, people-centric interface. This case study details the main problem facing publishers who are restrained by outdated, print-oriented production platforms, the ‘reimagining’ exercise and the iterative design process that has resulted in new technology which can be adopted, adapted and integrated by publishers.

Whooohoooooooo!

Hindawi launches its Journal system today built on Coko PubSweet tech!!!

This week, Hindawi is releasing a new peer review system that will debut on Bioinorganic Chemistry and Applications. The new platform is open source, developed as part of Hindawi’s collaboration with the Collaborative Knowledge Foundation (Coko). This release is a first step towards a network of open publishing infrastructure that Hindawi, Coko, and collaborating organisations will develop and share with the research community.

https://about.hindawi.com/blog/hindawi-launches-new-open-source-peer-review-system/

This is major news for the Coko Community.

PrePostPrint

You need to know about these folks..

https://discourse.opensourcedesign.net/t/prepostprint/727

https://prepostprint.org/

PrePostPrint is a laboratory and research group for alternative free publishing workflows. We are specifically interested in the creation of hybrid and printed publications with web technologies.

PrePostPrint gathers those working with experimental publishing techniques and helps to make their projects and tools more accessible. We share the desire to re-think all links in the chain of publishing. We want to forego the classical DTP programs and turn to technologies that are more accessible and sociable, and that can evolve and adapt for each given project. Coding becomes a design tool that permits to reinvent the editorial process, and allows to continuously question and re-invent publishing forms and formats.

Open Source and Scholarly Publishing

Please share! (by me)

https://scholarlykitchen.sspnet.org/2018/09/06/guest-post-open-source-and-scholarly-publishing/

There are many misconceptions about open source and scholarly publishing that often overshadow the enormous potential it has to lead organizations to modernized, efficient workflows and to allow them to innovate sustainably. Let’s take a first look at some commonly asked questions…

Rethinking Workflow

I spent an awesome session at UCP with Dan Morgan and Alison O’Connell discussing workflow. We were working through ideas of Journal workflows and how they would be encapsulated in a single system, namely xpub-collabra. It was a super interesting discussion and I think we have some solid concepts that rethinks how systems can capture multiple workflows in such a way they avoid endless configuration options and hardcoded prescriptive paths. We will be creating some narrative around this to get out here for people to think on and feedback…

dsc01046 dsc01047 dsc01049 dsc01050

What is xPub?

So, there are a lot of product names at Coko – PubSweet, Editoria, XSweet, INK, xPub etc etc etc… so becoming tricky to track, but I wanted it seems there are quite a few people interested in xPub right now.

xPub is not really a product as such, it’s more a group of products – each of which relates to Journal workflows. The names for each product indicyae those relationships: xpub-collabra, xpub-elife, xpub-faraday (Hindawi) and xpub-epmc

Each of these is a platform, so yip, you read it right – there are actually no less than 4 journal platforms being developed in the Coko community, not including the Micropublications platforms (of which there are two – one developed with Wormbase, and the other with the Organisation for Human Brain Mapping).

So, right from the get go our ‘offer’ is not standard. We don’t offer one platform to rule them all – there are many journal platforms in production. All of these are built on top of PubSweet… PubSweet is a kind of ‘headless’ publishing platform….it’s more or less the backend brains in that it is a kind of framework that ‘thinks like a publishing system’ but has not determined a workflow for you. So, each of the xpub-* platforms are actually publishing platforms built to meet a specific workflow and built on top of PubSweet…

Here is a crappy diagram (drawn in haste) to get the basic idea across:

ya

In the above, you see a PubSweet platform (eg. xpub-elife). PubSweet itself is the whole app – it sort of ‘encapsulates’ everything. Really though, you get the PubSweet core and then extend it with front-end components to meet your workflow needs. A typical front-end component might be a login screen, or a dash, a submission info page, a reviewer form etc.

You can also extend PubSweet on the back end as well (eg to enable integration with external services etc). The following is a more accurate but slightly techy architectural overview (you can skip this image and the following paragraph if you want to avoid the slightly techie part of this article).

ps2

In case you are wondering – everything is written in Javascript. Why did we choose JS? It was a deliberate choice to go with a language that was prolific. Almost every dev around these days needs to know some Javascript (it’s the most popular language by far on Github), this makes finding a developer to work on your project is as easy as we could possibly make it. JS is also a phenomenal language these days. Fast, sophisticated and more than capable of supporting large-scale publishing requirements. I mean, if it’s good enough for Paypal, Netflix, Linkedin, Uber and ebay, then it is good enough for you.

So each PubSweet platform has its own collection of front and back end components to meet the workflow of someone’s dreams… the idea is that to achieve the platform of your dreams you can reuse what others have already built and then just build what isn’t already available. In a sense, you can ‘assemble’ your platform from existing parts.

c1e22edf10cd018c9d1a697c29fbd891

The nice thing about this is that each of the organisations building Journal platforms are sharing the following:

  1. the same back end/framework (PubSweet)
  2. various front (and back) end components
  3. lessons learned…

Each organisation has a vision of their ideal Journal workflow. They then design and build this on top of PubSweet, but as they do, they build various components (either page-based components such as a dashboard, or smaller UI components we call atoms and molecules) and they share these components with everyone. Hence, you should check the list of components before you start building in case the component you need already exists.

We have various agreed-upon ways to build and share components (see this as an example). These best practices are continuously evolving but you can read some of the latest discussions about this approach here – https://gitlab.coko.foundation/pubsweet/pubsweet/issues/408

Of course, all code is reusable in the Coko community because it’s all open source. The best practices are there to make the code easy to reuse.

All agreements as per above are made by consensus by the community. It is actually a pretty snappy process – don’t believe every crappy thing you read about how open source is built. Open source community processes can be elegant and fast, and the resulting code can beautiful. Coko is a good example of this – a community of professionals collaborating together to make fantastic open source software.

dsc01017

So… back to the xPub story. To make these decisions on how to share components etc, we have regular meetings with various workgroups (we keep the numbers in each group small so we can move fast), and we also have quite a few in-person meetings. Not only do we have PubSweet community meetings where all of these organisations meet, but we have various get-togethers on various topics if required. For example, we met in Cambridge recently to discuss Libero (the eLife delivery product), before that EBI there was an onboarding session in Athens, next month we have a special designers workgroup in-person meet, anbd so on. All this helps us keep in contact with each other, which helps build trust, but also turns out to lift energy levels and boost production. These meetings are fun.

dsc01022

Also at these meetings, we learn from each other. One of the big problems in this sector, and one of the reasons people ask ‘why are publishing platforms so hard to build?‘ (after a number of high profile failures), is that there has not been a focused effort to share experiences on how to build publishing platforms. So, that is what we are doing – at each meeting we talk about what we have learned, how we are thinking about things, and show each other what we have done. The last meeting, for example, each xPub platform gave a deep dive to everyone in the group in a process known as speed geeking (it wasn’t so speedy as each table had 25-30 mins to go through their platform).

dsc00903

dsc00944

So, xPub isn’t a single platform, it’s more the community that is building journal platforms on top of PubSweet and sharing learnings and components. It is a very cool thing.

As a community, we also produced a book entitled ‘PubSweet – how to build a publishing platform’. You can get this for free here – https://coko.foundation/books/

I can also send you a print copy (they look great!) if you send me a postal address.

dsc00851

The book covers many things – a whole lot of technical documentation for how to build and share components etc, as well as some information about to think about workflow and how to map this into a PubSweet system. Personally, I don’t think the technology is very hard when it comes to building platforms – we knew what we wanted from the beginning with PubSweet and went about and built it (not to downplay the extraordinary job Jure Triglav has done in leading this effort). But the real hard stuff is actually thinking about workflow – not many publishing orgs have had the opportunity to think about designing their workflow to meet exactly what they want (rather than shoe-horning it into an existing system), and so we have had to beat this track for other to follow. It has been quite a journey but the book pretty effectively outlines how to think about workflow (which of course is a process that can be accelerated using Workflow Sprints which is a process I designed to facilitate a publisher to design their own workflow and PubSweet platform in one day).

0e7a0345

In that book you can see some high level ‘architectures’ of each of the xPub platforms such as the following (xpub-collabora):

02-adam-workflow-v3

Or this (xpub-epmc):

ebi

So, you might be asking…. at what stage of development  are each of these platforms? … I’ll leave it to each of the teams to say exactly, but it has been shocking to see how fast things have come along. I mean, the xPub community only really got together for the first time mid-last year, and building started for most late last year and early this year. It looks like we will have a lot of platforms landing by the end of this year. In this sector that is lightning fast. EBI are particularly impressive – they started two months ago and are almost ready to go – if it weren’t for the fact we are all replacing the under-the-hood data model we designed together at the last PubSweet meet, they would be good to go already. They can achieve such speed because they are reusing a lot of the components that the other teams built before them (and because EBI are just very good 🙂 ).

I can speak a little more about xpub-collabra since that is the platform Coko is building for and with the Collabra Psychology Journal. It’s looking pretty nice. We have some work tidying up the UI, replacing the data model and a few other things, but it’s looking rather good. We are also putting some time into making it a generic platform since the Collabra workflow follows a fairly ‘plain vanilla’ model. So we are building in some management interfaces and various bits and pieces to make it more widely useful – for example, Giannis just built in a Submission Info builder – enabling a Journal admin to build their own submission forms. It requires some hand-holding to use right now, but we’ll shape it to be very usable by your general journal adminy-type. We also have to integrate ORCID and DOIs, extend the range of submission file types etc… but it’s pretty close.

Below is a video showing xpub-collabra in action. It is a a version from some months ago, but you can see the workflow pretty well in this demo.

I think most of the xpub community is going to offer their new platforms to the market in various ways. This will be interesting as there are very different approaches at play. Hindawi, for example, is looking to make their platform a multi-tenant platform, eLife will put JATS at the centre of the workflow etc… So look for more news on that also. For our part, Coko will offer xPub through a partnership with a hosting provider – probably with the same organisations we will work with for Editoria hosting services. Since everything we do is open source, we will also be supplying all the Docker, Helm and Kubernetes scripts so that you can set up your own commercial hosting service if that is your cup of tea (or you can extend your offering should you already be a hosting provider). Coko is pretty close to getting our first hosting partnership set up, so look for news of that soon!

One last thing – because of the modular nature of any platform built on top of PubSweet, it is possible to take any of the xPub platforms and customise it to meet your needs. No need to start building from zero. Additionally, the modularity means you can extend the systems with your own interesting new innovation – finally a place for innovation to call home in the publishing platform world….

So… there is a lot going on in the xPub world….we look quite different to the rest of the market because we are not building one platform – we have instead focused on building a community to support the development of multiple platform solutions for journal workflows. You can pick and choose which one you want, or build something else, reusing as much of the other systems as you can to reduce your development costs (we also spend a lot of time onboarding new folks and supporting them as much as we can).

But it’s not just about improving the game today – supporting the optimisation of workflows is one part of what we are trying to do, the other is to support future innovations.

If you want to know more, feel free to jump into the Coko community channel and chat – https://mattermost.coko.foundation

Come and join the party. We are happy to support you and happy to learn from you…. not-for-profit or commercial we don’t care, build a better journal platform on PubSweet than the rest of us and we’d be happy!  We are in it for the mission – come to talk to us! no preciousness here 🙂