Wiki layouting
[what]
This chapter stretches what wiki layouting could be.
It does not focus on design, cause this tends to lean towards the cosmethic aesthetics, but we're interesting in aesthetics in a broader sense, in structural aesthetics that come from writing through a wiki.
[how]
We will engage with the materiality of MediaWiki by looking at a range of features of this software and the forms of sociality it activates. For instance:
- at the different tools for versioning that are there and how they relate to ideas of authorship,
- through explorations of hypertext, the idea of transclusion, and different ways of linking/relating pages, categories, user contributions, what links here, even going to semantic data models perhaps (triples)
- possibly by engaging with the size of media files + database
- embracing the strength of messiness in a non-templated environment
[why]
Printed material made with the wiki-to-print setup does not really smell like a wiki. This is one thing we feel interested to dig into. Why doesn't it smell like a wiki?
But also, we make a printed object as a thing that will last on paper. But meanwhile, we also produce wiki pages, but nothing happened with them. What is left when making something with a wiki? How can it feed back into the wiki?
That is why we are shifting from a focus on wiki printing to wiki layout.
How can we use wiki pages to render multiple layouts and publications from? How can reuse become a central attitude when working with the wiki?
How can we work with an attitude curious of:
- reuse of material
- transformation through layouting
Finding different paths through the material.
We want to explore a range of experimental wiki based writing/reading environments, by exploring:
- the materiality of MediaWiki, wiki writing, wiki reading..
- the materiality of layout engines (HTML, Paged.js, graphviz, ...)
Wiki activity snapshots
Taking snapshots of a wiki using Graphviz to make layout. Graphviz is not easy to control, and that's meant to be so. You can control some things like fontsize and shape of the nodes, but the placement of nodes and edges is controlled by Graphviz.
If you make something for print, or for the web, you think about how long something will last. We tend to then simplify layout, to make it accessible for people for as long as the layout exists. We follow conventions based on our reading direction (left to right, top to bottom in our language). Putting something on the top-left of the page (like a link to a homepage), is a decision that feels very accessible.
But Graphviz follows a different approach. It places the nodes and the edges without thinking about usual hierarchies, or usual ways of reading. We done a bit of that with the title of the graphs. Here the placement at the top is important, it is different information to the content of the graph. But the rest of the layout of the graph is decided upon by Graphviz. And also placed differently once the content of the graph changes. It connects the act of making snapshots and taking a particular slice from the bigger whole in the form of a graph on a particular moment in time.
In this way, it fits a technotext-ethnographic approach. Taking samples at different moments to make layouts. It introduces an element of time and temporality.
Notes from reading from the booklet "16 case stories", published by the LGRU in 2013:
- layout is the spatial arrangement of text and graphical elements
- what we understand of it is directly exported from the Gutenberg press
- there are little traces of the encounter of layout with digital systems
What we notice and remember about wiki-to-print practice: the digital systems that are involved in the making of printed matter often become invisibilized.