After an enjoyable five months at the PublishingLab, the wiki ebook project has come to a (momentary) halt. To borrow the eloquent term that Mondotheque used in our conversation, this blog post will be an ‘incision’ into the research that we have done so far.
Our aim and starting point was to reflect upon the new possibilities that ebook making software would bring in the context of Wikimedia platform ecologies through exploratory research. The project, which was initiated by Sandra Fauconnier, an art historian, researcher and Wikimedian, asked the question:
What is the potential of e-books based on Wikimedia content?
We tried to answer this by first mapping existing software packages that would allow a user to collect articles and render them as an EPUB or PDF. To our surprise, this turned out to be a less explored area of publishing and we could only find a handful of projects, each presenting some advantage over others, but having their own shortcomings. It was easier to find artistic projects on the topic on printing content from the internet1 than actual tools to give you the capacity to do so. Considering how many people use projects like Wikipedia on a daily basis, this seemed a strange prospect.
There were a number of options we considered for the format. Despite our enthusiasm growing with more experimental suggestions, we continued to focus on EPUB, which is essentially a ZIP file containing multiple other files, as a format for a few practical reasons:
- it can be used offline, which makes it ideal for situations without an internet connection,
- it’s an open format and can be read by most common devices like smartphones, tablets, computers and e-readers,
- it has a reflowable text capacity which adjusts the size and the font of the text to any type of screen or reader preference,
- the format supports inline styling, CSS features, metadata, as well as vector and raster images,
- it doesn’t have a steep learning curve for users who are not familiar with it.
One of the most interesting aspects of the project was to establish a dialogue with current practitioners who are relying on independent wikis as a publishing sphere either for ideological or practical reasons. The conversations we have had with artists, archivists, activists and designers informed our choices in shaping the tool and inspired our technological imagination: we became more aware of the necessity for interventions of a personal nature within the Wikimedia systems.
With this in mind, working with the API (Application Programming Interface) as a means for customisation of the interface was a conceptual choice as much as it was technical. By deconstructing an article, the user can take Wikimedia content as a springboard for other-minded endeavours, perhaps of a scholarly or even artistic nature. Thinking about a publishing artefact that responds to these needs, the scrapbook came up in our conversations.
Here we have two example pages from the scrapbooks of Alexander Gumby (1886-1961)2, who is also called ‘Mr. Scrapbook’. His collection ranges around 300 items. Gumby gathered historic and personal documents in his scrapbooks, which although was a self appointed task at the time, turned out to be a valuable archival resource of African American history in Harlem New York for years to come.
Over the course of our research, we became very interested in the idea of the personal archive and how it can give an individual the possibility of determining the value of items that are gathered and maintained in their collection. Scrapbooks have historically been connected to a personal interpretation of events and although the autobiographical nature is often stressed, this way of archiving and organising items can also be a transgressive means to record one’s journey through information. Thinking of the scrapbook as a device for alternative navigation of history files fitted our quest for an alternative navigation of Wikimedia content.
Back to the wireframe drawing board. In order to maintain a direct connection to the Mediawiki software and also the Wikimedia community, four pillars were chosen around which we constructed the identity of the tool: multiple languages, last revisions, number of contributors and random articles.
The result was a platform where the user can paste a Wikimedia URL, select the modules that they want to keep, edit the metadata of the collection and order of modules, generate an EPUB or markdown file and decide whether they want to save it on the platform or their own computer.
To get into the technical nitty-gritty, there are more details about it on our meta-wiki project page, where you are welcome to leave a comment (or intervention). The code can also be found on our GitHub. Unfortunately, we didn’t have the time that was necessary to make the platform functional, but hopefully the documentation of the project can provoke some further ideas on the subject matter for other interested parties.
Further, we proposed three instances in which the tool could be useful:
- moving to the Netherlands (download)
- art class about Goya’s special interest in bull fighting (download)
- documentation of an edit-a-thon (download)
Using the code we had for each individual module, we extracted the html from the JSON document that we received after making the API calls, put all of it into a larger html file and attached a CSS stylesheet. Using Pandoc, the file was converted into the resulting EPUB. The final proposal for this project is the automatisation of the process through the above-mentioned platform.
When searching for the content to include in the publications, we were reminded of the incredibly granular level of specificity that is so wonderfully characteristic of the Wikimedia community. There is minutiae of content abounding – we invite you to discover it and become a Wikimedia publisher yourself.
1 For example Michael Mandiberg’s ‘Print Wikipedia’ or James Bridle’s ‘The Iraq War – A Historiography of Wikipedia Changelogs’.