The spring/summer conference season is about to kick into high gear, and we’re here to help you plan your travel. We’ll be busy at both the Society for Scholarly Publishing and Association of American University Presses conferences in May and June, and we’d love to connect with you to talk about Editoria.

Society for Scholarly Publishing, Boston, MA, May 31st-June 2nd

Erich van Rijn will be participating in several session at this year’s SSP meeting in Boston between May 31st and June 2nd, and is also available for individual appointments to talk about Editoria. Come find us at the following sessions:

Open Source Tools for Scholarly Publishing — This is a pre-meeting session, organized by Kristen Ratan of the Collaborative Knowledge Foundation, during which we’ll be talking about incorporating open source tools into scholarly publishing.  We’ll explore how to build them and enhance adoption, and how tools like Editoria can improve scholarly publishing workflows.

Open for Discovery? Open Access Monographs in Scholarly Research Workflows — Erich van Rijn will be moderating a panel on discoverability of open access monographs.  The panel will include presentations from Jennifer Kemp of Crossref, Frank Smith of JSTOR, and Wendy Queen of ProjectMUSE.

Preview Session: New and Noteworth Product Presentations — We’ll be doing a five-minute pitch on Editoria alongside a number of other cool new tools during this session.  Please come check this session out. From what I’ve seen, there should be a number of great presentations in addition to our own.

If you’d like to set up a time to talk outside of these sessions, please get in touch.

Association of American University Presses, Austin, TX, June 12th-13th

Interest Group Meeting — I’m organizing a breakfast session at this year’s AAUP, which will happen on June 12th.  Please use this form to get in touch or tweet me (@erichvanrijn) if you’re interested in attending.  I’ll be giving a brief overview of the software, answering your questions, and discussing how we can create a community of Editoria adopters, developers, and partners.

Individual Meetings — If you’d like to schedule an individual meeting to discuss Editoria, please use the following form to request a meeting, and we’ll be in touch.  I’d be more than happy to get together with anyone who’s interested in a deeper dive.

We look forward to seeing you this spring!

1. Built team manager functionality that will allow the various members of a team involved in the production of a book (e.g. project editor, copyeditor, author) to interact with the text based upon permission assigned to them.
2. Designed and implemented a commenting and querying system in the editor that allows for participants in a project to interactively comment on the text.
3. Built out the libraries, known as XSweet, that are required for converting Word files to HTML for editing and display in the Editoria system.
4. Developed and implemented a chapter structure navigation in the right column of the editor that allows a participant to easily navigate to any component of a chapter.
5. Output print-ready PDFs from HTML using the Vivliostyle HTML/CSS typesetting engine.

1. Adding track changes functionality.
2. Integrating the system with the INK file conversion service that allows for automated upload and conversion of Word files.
3. Adding an index builder.
4. Building of the image management functionality necessary for image placement.
5. Automating the output of PDF and EPUB files.

I came up for air recently try to catch up on what’s been going on in scholarly publishing. I love Bill Trippe’s Flipboard magazine on university press publishing, and I value the crowdsourced knowledge of all the hundreds of folks I follow on Twitter, but I wanted a deeper dive.  I wanted to create my own news stream, so I installed a good old fashioned RSS reader, and started loading up some of my favorite blogs and websites.  Today, I am going to use my limited powers of social media persuasion to encourage readers of this blog to check out the new Paged Media blog.

Paged Media was started by Dave Cramer of Hachette and Adam Hyde of Collaborative Knowledge Foundation.  In addition to contributions from its founders, Paged Media so far has contributions from several folks who are trying to make the open web support books and other paginated content better:

• Martin Eve, an Editoria advisory board member and co-founder of the Open Library of the Humanities.
• Hugh McGuire, the founder of the excellent PressBooks book production software.
• Julien Taquet, the designer for Booksprints.

Paged Media is dedicated to a simple mission: “To educate and inspire publishers to use HTML, CSS and JavaScript(JS) to produce print and paginated electronic content.”

But some of you may be asking, “In this era of digital scholarly publishing, why is pagination important?”  I can tell you that pagination is crucially important to digital scholarly publishing, and it has been a critical development concern for Editoria.  Why?  Consider these use cases, reprinted from the first public working draft of the W3C’s “Portable Web Publications Use Cases and Requirements” document:

• Ann reads War and Peace, which, when printed, is over 1200 pages. In order to have a better sense of her progress in the book and to make navigation within the book easier (i.e., to support usability) she decides to switch her reading environment to paged view.
• Susan uses CSS, images, flexboxes, and more to create a rich, interactive publication on the history of a city. Each major historical milestone is defined as a standalone unit that would be a single page when printed, with a timeline with the main events in the footer area of the page.
• Fatima wants to choose between a scrolled view and a paginated view of content that extends across multiple HTML documents.
• IndyPublisher wants to provide transition effects between pages, both within and across content documents.
• Mr. Oayia, a classroom teacher, says, “turn to page 137 of your textbook.” Students with both print and digital editions need to find the same text.

All of these are use cases that regularly present themselves in long-form scholarly communications, and any systems built to support text-based scholarly communications, including Editoria, need to be able to support them in some fashion. While the Portable Web Publication is being developed to enhance HTML-based formats to accommodate pagination, a lot of the functionality that is represented in these use cases can already be found in the good old PDF.

Our approach to this with Editoria has been to use the Vivliostyle CSS typesetting engine.  Vivliostyle has allowed us to develop the Editoria application in a way that supports both paginated (PDF) and non-paginated (EPUB) outputs at the end of the book production process.  While pages, particularly printed pages, have their limitations (eg. multimedia content), in many cases, pages are critically important to monographs as well as to the production other types of scholarly and educational materials, and to making them useful to readers.

While controversial, the proposed IDPF/W3C merger, if successful, and the work of the group developing the portable web publication specification may eventually succeed in bringing much of the functionality necessary to represent the concept of pagination to the EPUB specification.  The W3C is the right forum for this work to be done, and would likely help advance the use cases for pagination that scholarly publishing demands of EPUB and help abolish the bifurcation of the PDF/EPUB world and our reliance on the two-dimensional PDF format.  If that world emerges, Editoria will stand ready to support it. For now, most monographs will have pages, and Editoria will be developed in such a way that those pages can be represented at the end of the production process, and allow publishers using the system to give readers the choice of whether they prefer to read in paginated or unpaginated formats.

In a blog post, Martin Eve, Professor of Literature, Technology and Publishing at Birkbeck, University of London, and Editoria advisory board member, summed up the impact of Microsoft Word on the current system of scholarly communication:

It may sound overblown, but a crucial stumbling block in reconfiguring the economics of scholarly communications for the digital age is Microsoft Word. Specifically, the fact that users are wedded to this format presents typesetting and conversion costs that are completely out of proportion to the needs of the system.

I encourage everyone to read Martin’s post, which summarizes nicely one of the central challenges posed by the Editoria project: how to get manuscripts out of Word as early in the editorial production process as possible.

From the outset, we felt that the only viable way to both control the outputs of the editorial production process and build a collaborative editing environment was to remove Word from the process entirely.  Because the use of Word is so ubiquitous among authors of monographs and journal articles there are many pieces of software that have been built over the years as add-ins or plug-ins for Microsoft Word.  While this approach can be very successful in an environment where documents are passed from one participant to the next, it is not appropriate for a collaborative, web-based editorial production environment, which was what we intended to build.  Moreover, it forces publishers to continue to rely on a piece of proprietary software that was never designed with the needs of scholarly communication in mind.

Thus, one of the first tasks we set ourselves in the development of Editoria was developing an ingest and conversion mechanism that would allow project editors (or anyone else on the team for that matter) to upload a Word document and convert it to HTML, which is how content is stored in Editoria. This would allow authors to continue to use their tool of choice, Word, to craft the manuscript, and allow us to enforce document structure and semantics once the manuscript is submitted and we take over production.  We’ve been working with Wendell Piez, Alex Theg, and Adam Hyde at the Collaborative Knowledge Foundation on developing a set of XSLT 2.0 stylesheets for extraction and refinement of data from MS Office Open XML (.docx) format and producing HTML for editorial workflows, which will be incorporated into Editoria. 

As it exists now, the first part of the conversion is to extract as much information as possible from the Word document and clean it up.  Initially there’s some of noise in it—things like duplicate tags, Word-specific tags we don’t need in the HTML, or empty tags left over from user actions in Word (say, bolding and then unbolding some text), so there’s a fair amount of cleanup to do.  We want to make this extraction and cleanup as robust as possible so it can handle lots of author inputs.

The second part of the conversion is enhancing the clean HTML.  Currently, the conversion translates footnotes and endnotes from Word into the HTML as numbered links that connect the endnotes and their inline callouts.  It’s also capturing indentation for paragraphs and block quotes.  Soon the converter will be able to recognize things like links, potential headings, text alignments, etc.  It’s a long road, but the Coko team has made significant progress on developing enhancements and refining the tool.

Because the MS Office Open XML format is so complex, and because there is so much required to tidy up a document that was authored in Word and present it as a structured HTML document, there will always be a crucial role to be played in styling and structuring a manuscript that will necessarily need to be done post-conversion by a skilled editor or someone familiar with a book structure. But, the work that the Coko team have been able to do on creating a conversion pipeline, is getting us much closer to the day when all work on a manuscript after submission will be able to happen on the web.

With the Book Builder interface nearly complete, the team is now turning their attention to the authoring and editing interface which, in addition to supporting composition and styling, will also need to provide tools for commenting and task management. To meet these needs, the development team will be working on both interface and infrastructure challenges in the month ahead.

Collaboration interface

Editors, authors, copyeditors & proofreaders all need a way to mark up text, engage in conversations around proposed changes, and track tasks related to these comments. Editoria will make use of space directly to the side of the main “page” area to enable this functionality. Comment threads will link directly to the text that needs changing, and threaded conversations related to those comments will be enabled. Users will also be able to use quick shortcuts to create tasks within comments or mark conversation threads as ‘resolved’ so everyone can keep on top of what work remains.

Authoring & editing infrastructure

One of the main goals of Editoria is to meet authors where they already do their work. This means that, in addition to providing an intuitive browser-based authoring tool, Editoria also needs to support import of existing manuscript materials in Microsoft Word *.docx format and perform some clean-up on imported files to match the publisher’s style guidelines. The development team will deliver an initial prototype of this functionality alongside the new collaboration interface in Editoria 0.4.

Looking ahead

We are also actively gathering requirements for remaining development challenges scheduled for completion by January 2017, including:

• User and role management
• Support for basic art placement
• Tag-based index generation
• Automated typesetting and multi-format output