In the past months I have tried to understand how the Sausage Machine exists in the book publishing field. I talked to people from divers disciplines to find out if and how each of them could use the tool, among them researchers, authors, publishers, designers and developers. The people I’ve talked to are: Janna Meeus & Hilde Meeus (of Meeusontwerpt), Barbara Lateur (of Studio BLT), Marc de Bruijn (of Puntpixel), Silvio Lorusso, Mark Minkjan (of Non-Fiction), Loes Sikkes and Gert-Jan van Dijk (of Uitgeverij 1001).
How to explain the Sausage Machine
The Sausage Machine (SM) is, among other things, a tool for collaboration, for connecting people with different skill sets. Explaining what the SM does means talking to people about skills and techniques other than their own. For example, if you want to explain the whole process from .docx to .epub to an author, you would have to talk about .css, .icml and inDesign; file formats and programmes they don’t know or work with.
The promise of the SM is that the hybrid publishing process becomes more efficient and more collaborative. How do you convince people of this without having to go into quite technical details?
I’ve made a sketch of the involvement of the different people in the hybrid publishing workflow using the SM:
What becomes clear is that the workflow has an advantage to authors and editors that doesn’t involve difficult terms: different outputs (especially web and ebook) are available for preview without the intermediary of a designer or developer. Authors can edit text in the .md file and immediately see the effects in the (semi) designed outputs. This means that decisions on for example the length of a paragraph can be made more easily.
Because I think publishers play a central role in determining the way a book is made, it’s important to consider the way the workflow is presented to them. Perhaps they don’t need to know the exact process that a designer goes through when using the SM. That brings me to the following:
User interface design
I promised to discuss this about a month ago, so here I finally go.
While the technical functionality of the SM is excellent, it has not yet been designed with the user in mind. I’ve collected some comments over the months which I’ll go through here:
1. the aim of each of the tabs is unclear, and it’s counterintuitive to start on the second tab. Perhaps the tabs could be turned into a step-by-step guide? As the process can be difficult to grasp as a whole before you actually do it, it might be good to really take the user by the hand and hide parts that are not important in that particular step. A better word ‘Book projects’ might be ‘Archive’, and it should be accessible from another point in the page, as should the About page.
2. users find this list confusing: ‘what are these items and why do I see them here? What can I do with them?’ This part of the page should be reconsidered: if people should be able to edit the files in the SM, then the UI design should indicate this. It is also confusing that there are template files like ‘Test-markdown-document.md’ that will also show up in your finished product, unless you delete them.
3. It is interesting to be able to see your documents in the tool, but this functionality should be presented differently. People have indicated that they thought they had to read through this text, as though it was an instruction to the SM, while it is more useful as a reference guide to MarkDown. Perhaps there can be a section to the page that has resources like a MarkDown cheat sheet and a GitHub 101 tutorial?
4. It can’t be assumed that users will know what GitHub is, so this needs to be explained to them. Perhaps the Template function can be hidden to users that are not designers (they could instead attach the project automatically to one template). The Outputs could also be presented differently, in order to allow people to create multiple outputs in one go.
Ones these changes have been made, especially focusing on the publisher as a user, I am sure that the SM could be used by almost everyone.