Technotextual editorial guidelines
Technotextual editorial guidelines for wiki layout practices
Wiki software has an attitude! The following are a set of handles to be reused as guidelines during a conversation between editor-designers and design-editors at the start of a publishing project, to shape the editorial workflow together.
Open questions:
- the scope of this document: focus on wiki-to-print or wiki-layout practices (which includes websites, printed publications, ...)
- do we want to include examples of wiki projects?
- check references
- opinionated enough?
What role does the wiki play?
A wiki invites readers to become writers. And to be messy, to repeat and re-embed material, to let unfinished thoughts linger around and to let structure emerge collectively and over time.
As a writing environment, it invites us to bend the idea of an individual genius author into a distributed practice of writing.
- Is the wiki an online environment that readers can find and browse?
- Can readers also write?
Is the wiki a temporary production environment or continuous infrastructure?
We understand infrastructure as something that exist because multiple people depend on it, something that is present for a longer amount of time, and something that does not change a lot but needs maintenance.
When using a wiki to publish from, writing can go through phases of transformation, versioning and change.
- Is this publication a snapshot of a particular state of a wiki in flux?
- Or is this wiki a production environment for the making of this publication?
What can a page become?
What we like about the wiki as a writing environment, is that it comes with a very open understanding of a page. Wiki’s are based on the idea that everything is a page. By default, a wiki does not work with templates and input fields for a title, subtitle, introduction, etc, such as Wordpress for example does. There is no structural difference between the landing page or any other page, even the uploaded images are stored on a specific File namespace page. This radical horizontal approach gives the space to turn each wiki page into any kind of page you want. A wiki page can turn into an essay, an annotated image gallery, a piece of code, a logbook or a budget sheet.
- What limits do we want to set for a page?
Does hypertext shape our writing?
Can the content be written in smaller pieces that can be assembled together in different ways?
non-sequential writing
finding different paths through the material
Ted Nelson describes a feature of hypertext: to create a public repository through which new texts can be re-assembled
when writing smaller pieces, it's easier to "hook in" to each others writing
How to motivate others to write?
How can a page become an invitation to write another page in response?
role of red-links, parking an idea
[ref olia lialina "links" in A Vernacular Web text?] https://art.teleportacia.org/observation/vernacular/links.html
Who is the author of this publication?
Which authorship regimes does the publication cross with? How does this shape our common understanding of an author? How does this shape our approach to referencing?
- wiki understanding: "a wiki is actually hyper-authored" (Michael), everything is traced through revisions, based on a single branch (no diverging and merging), there is always just one published version of the text, disagreement is not visible (there is space for it in Talk pages and in the History)
- academic economy of referencing, footnotes/endnotes
- practice based attribution
- CC4r: i as an author am not disconnected from all the authors that i learned from and have grown with, plus i want to keep their living conditions into account
What is the difference between:
- contributor (multiple ways to contribute to a larger body of text)
- author (having the authority/responsibility to speak)
Let's not say: this publication is made by us all in "collective authorship". That might mean that we avoid any conversation about this. Has there been a consensus about this, really? At the same time, collective authorship can be a strategic way to share responsibility across a group.
Who can reuse the material?
[Something about authorship as revisions? About the hidden position of the version tracker under the “View history” tab?]
In a forum, for instance, the focus lies much more on individual voices. Different authors state their ideas, and formulate them clearly in a post. On a wiki however, the focus is on the text on a page. The name of an author is not even visible by default. The text that is written is the central point of attention.
[ref olia lialina "tilde" in A Vernacular Web text?] https://art.teleportacia.org/observation/vernacular/tilde.html
Who commits to be responsible for what?=
- wiki understanding: bureaucrats, administrators, moderators, editor - design-editors and editor-designers: it's not about anyone can do anything, it's about committment!
How does the wiki shape our collaboration (or not)?
The role of the RecentChanges page, the diff's, the wiki as an async collaboration environment. The need to switch to pads sometimes to be close to a thought process in real time.
How can traces of our collaboration be included in the layout?
What we know of layout comes from the history of the printing press.. The traces of the digital are often invisible... How can we show that this layout comes from another timeline/history/context?
How does the visibility of edits and editors co-shape the writing? What kind of paratext can the recent changes become? What role can they get in a book?
[recent changes snapshots thinking here?]
The RecentChanges page as the (backstage?) a wiki, as a place that reveals both the social dynamics and also its specific culture. Who is there? Who wrote something today? It's a page that signals that a wiki page, that has maybe been forgotten for years, is relevant again and connects to a specific activity happening today.
The RecentChanges page as a social environment is exciting.
Taking samples at different moments to make layouts. It introduces an element of time and temporality.
Which medium will this publication transform into?
- wiki-to-print
- wiki-to-pdf
- wiki-to-graphs
- wiki-to-slideshow
- wiki-to-stickers
- wiki-to-podcast
- wiki-to-website
- wiki-to-index-cards
- wiki-to-stencil
- wiki-to-riso
- wiki-to-polymer-clay
- wiki-to-email-thread
- wiki-to-rss-feed
- wiki-to-video
- wiki-to-puppet-show
A layout engine is an environment that defines the parameters with which you can produce layout. Layout is about situated meaning making through positioning/arranging graphic elements spatially.
Thoughts about Graphviz?
Notes about Paged.js and wiki-to-print?
wiki-as-wiki
browser
A wiki skin is a layout in itself.
wiki-to-print
Paged.js, Python, Jinja, Flask, Pandoc, Mediawiki:Common.js, Mediawiki:Common.css
polyfill, codex logics
wiki-to-graphs
GraphViz, Python, Jinja
Taking snapshots of a wiki using GraphViz to make layout. As a layout engine, 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 the software.
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 have 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 at a particular moment in time. From the start, we were excited about the aesthetics of the wiki that are structural. The GraphViz output comes close to this, as it starts to show this structure.
[include link to the code we wrote]