Written by Pia Pol
Introduction
Making a digital modular publication is never easy. Modular publishing has its own set of requirements and challenges. Modularity on the backend of projects is a much accepted and preferred strategy. Cutting the work up in blocks makes for a clear and easier to handle workflow. But what happens if modularity is the goal not only for the backend but also for the finished project? What happens if the goal is to present the reader with a publication that is non-linear? A navigable repository? How does that change the role of the author and the publisher? And what do designers and developers need to make this happen? Is that the same for content creators? Choosing modularity can happen for a great number of reasons. It allows, for example, for a change in navigation. Linearity is no longer a requirement. Or it might be that the creators of the publication want to give its readers more freedom.
It all starts with dissecting the ideas and materials and the starting point of the creative team. Are you working with pre-existing content or is the publication still in the idea-phase? Whichever the starting point is, this initial phase in the publication process is key. This is the point where the writer or editor, guided by the publisher, could start identifying the modules in their content. These modules can be big or small. They are the elements that make up the whole. They can be words or subjects, themes or chapters, phrases or titles.
As a creator, more often than not, you want the reader to have freedom, but the content still needs to make sense. It is, after all, intentionally selected and meant to convey a message. The road through the content is created with relations. Choosing what to base these relationships on is a difficult process. It defines the structure of a project and of its content. They will form the road that guides the reader through the process. These relations between elements are the central component of the ‘Stand Alone Object’ research group.
Elements
At the start of the publishing process the publisher (or editor or author) needs to define the different elements of the content, their weight and the relationships between them. These relationships can be defined on similarity, (navigable) order, etc. Seeing them, creating them and relating them to the bigger picture of the publication can be difficult. You need to be able to cut up the content in blocks, placing them on a pin-up board and drawing the relations between them. It would be much easier is this step could be done with a tool, preferably one which would be able to generate an output to give all the materials, including the drawn relationships.
Developing such a tool would be an enormous task. The research group, thus, set out to look for existing tools. Is there something out there already which could solve our problems for us? Or is there a tool in existence which could be modified to be what we need it to be? We found three possible candidates: TiddlyWiki, Scalar and Twine.
Tested tools
These tools were tested with the following question in mind: Is this a tool that helps us in the early stages of the editorial process to identify and create relationships between the different elements in the selected content, and if possible creates something that translates that into a package which is transferrable to a third outside party? To structure the testing procedure the following questions were added:
- What is the promise of this tool?
- Which inputs and outputs does it have?
- Does the software allow for the cutting up into different elements or building blocks
- Is there a way to create/draw relationships between these elements and how are they then visualized?
- Is everything there that you need In terms of textual elements for example?
- What was the learning curve? How user friendly was the tool?
Each member of the team, all with a different background, set out to start testing each of the three aforementioned tools. TiddlyWiki promises to be a non-linear personal notebook. It should help the user with ordering and organizing complex information. Unfortunately, it was jointly concluded that for the less digitally experienced members, TiddlyWiki’s learning curve was too steep. The tool required familiarity with the Wiki-structure and way of working. Although the visitor of the website www.tiddlywiki.com is led straight to a ‘getting started’ page, it is difficult to get to additional information of how the tool actually works. Because of these reasons TiddlyWiki was discarded.
Next in line was Scalar. Scalar is an open-source online publishing platform that’s designed to make it easier for authors to write long-form, born-digital material. Scalar enables users to include media from multiple sources and allows the user to create relationships between different elements in the material . Scalar lets the user visualize the created relationships with a simple click on the button. The reality of using these tools is always quite different from the promises made. If only for how much time it takes one to fully understand what they are doing. Our conclusions for Scalar read: It is very dense in its functionality and as a result not very easy to use. It does offer a really good overview of each of the layers of the content. It seems to be most suitable for heavier text projects and has a built in feature to work with footnotes and endnotes. It is quite easy to upload different media, but the overall learning curve for the tool is very steep.
Twine advertizes itself as an open-source tool for telling interactive, non-linear stories. This tool seemed the easiest to start working with as a beginner; there is a clear guide leading the user through the tool step by step. It seems to primarily used by game developers looking to set out their story lines. This process struck us as quite similar of what we are trying to accomplish. There is either content or an idea of what this content should be and where it might lead. The questions if this than that? or If this then what? are at the forefront for all the users of this tool and of course these are question similar to what the creators of a non-linear modular publication are also asking themselves. Twine struck us a relatively easy to use tool from which some key elements are still missing (the ability to use foot- and endnotes, including thumb-nail images in the overview), but which also has the ability to be built upon, to add extensions to.
Having gone through this testing process, we have fine-tuned our questions and wants into the following:
- We want a tool which helps to think through developing content for digital non-linear publishing. This tool needs to do several things:
- It helps with finding the right structure and relationships between the different elements that make up the content of the project.
- It helps to communicate these to outside third parties(like designers, developers etc.)
- It should give feedback on how these relationships work
- A Tool that helps to deliver/transfer this content in a structured manner to the developer, so with relations made and intact.
Our conclusion is that Twine is best suited for what we are trying to create with this project.