Chapter 4a: Computational Publishing

Wiki publishing

This is a very drafty version still! Text under construction.

recent changes snapshots (check changes)

So, if I remember correctly... We were interested in questioning what making layouts is with a wiki. And thinking less about the cosmetic aesthetics of wiki layouting and diving into the structural aesthetics of a wiki as a layout engine. What do you mean with cosmetic aesthetics? Layout is generally understood as an arrangement of graphic elements on a page, but we started to realise that the writing of the wiki pages would create a structure and how this was somehow invisibilized when making printed matter with a wiki. So for example, that there are so many different versions of a wiki page, all stored in the version tracker, that become invisible. And also other things, like hyperlinks that can't be clicked anymore, or red links. This realisation came through making the APRJA newspaper, when we were thinking about which article should be on which page and the cosmetic aesthetics started to take over: the thinking about the size of the title or the text itself, or how it was positioned next to visual material took the overhand. The fact that there were many people in the room writing wiki pages was something that did not find a place in the layout. At the same time, we asked them to follow a specific structure in their pages, a structure that we needed to make the layout, such as the specific order of the title and authorname, how they made bibliographic references, and also the practical thing of adding a specific category to their page so we could find their pages on the wiki.

To me, layout is not only spatial, it also needs structure. When you generate layout from code, you always work from structure. When you write a document in a word processor, you also use structure, on a textual level. Like, headings, bold, italic, lists, block quotes, all those things. But when you generate layout through code, you don't only have the textual structure, but the text comes with paratextual structure. Can you say more about that? Such as, all the metadata that gets generated by the version tracker that is built into the wiki, information about other pages edited by the same author, other pages that were edited around the same time... The structural approach doesn't stay within the page. The page itself is not the only place that holds structure. There is a lot of structure that comes from the writing environment, which in this case is the wiki. And so the question is, can this structure/information also find a place within the layout? Or what are other ways to experiment with this?

At the same time, the wiki software that we are exploring is not only providing these programmed layers of information, the software itself also comes with an idea about ways of writing, and attitudes towards writing, and a certain form of sociality. It's not only the programmed stuff that comes out, but it also invites you to engage with the writing differently. In a wiki, everything is a page, you can use that space for whatever you want. I've seen students using it for a text adventure game engine, as a slow async chat environment, as a place to store code, photogalleries, diary entries and journaling, essay writing, or to write practical tutorials. The wiki is not really restricting a type of writing that it can hold. But this is in situations where people are writing wiki pages for themselves or for friends/peers, either in the context of education (like XPUB) or in self-organised cultural initiatives (like Varia). [something about wiki's that are used in a specific community of practice]

Do you ever edit Wikipedia? Never. Me neither. I think there's something about stepping into that space that feels difficult.. it's a contested space, there is a lot of ownership. I'm afraid to write something personal that would be edited for reasons that are very distant to me, and i would not have any say about it. That's interesting, actually, it reminds me of something Michael (Murtaugh) said that the wiki is actually a hyper-authored space, because all the changes are tracked, which means that if someone wanted to monitor them, they can. And of course on Wikipedia, there are people who are monitoring those changes for a reason.

But it's funny because we have used the same tools to look at the latest changes made on a wiki [unpack], but with a very different intention.

How would you describe that intention? Well, when we started to look at the recent changes page of monoskop.org, we were interested to understand the dynamics of that specific wiki, also to understand its current state and focus points. And when we were there and looked at the recent changes, of course, without surprise, found many edits made by Dusan. And because we know that Dusan is the main person running and editing monoskop, this was not really a surprise. But it was nice to see how the different edits he made that day, all seemed to link to each other. I'm just looking now to see which specific changes... It included edits made on a page called Ljubljana, which was followed by edits to the page BioTechna, followed by edits to the page Marc Dusseiller, which we then were curious about how they connected to each other. Yes, I started to wonder why Dusan is making edits on this day at this time. If you go to the frontpage of Monoskop.org you see a Mastodon feed and it kind of reminded me of this temporality of micro-blogging, where updates come in to the minute. So does the wiki editor then think, i must go and update my wiki? Ah you mean, after seeing a post on social media? Yes. Yes, I'm curious about what triggers Dusan to make or edit wiki pages (haha). It seemed to be closely related to his day-to-day surroundings, or the things he sees around him. But how can he see all these things? He must be the spider overlord!

What was interesting to you about the snapshots that we made?

First of all, that they did not conform to the usual top-to-bottom and left-to-right reading of a page layout. Because we were using graphviz, which is a very unorthodox page layout tool, we did not have or ask for much control over the hierarchy of information. And we used colors to indicate what were pages, what were the times the pages were edited and to indicate who edited them. In a way, it kind of reminded me of reading the age of a tree from concentric circles. It was more like a slice, rather then a snapshot. And yeah, i had to think about a different way to read layout, but diagrams generally do this, they ask you to read things in many different ways. It was interesting how when going through the process of making the diagrams and engaging with the MediaWiki API to do so programmatically, we had to work with the way of thinking about pages that comes with/from the MediaWiki software. It meant that we had to approach wiki pages as collections of revisions. Which in itself, I find there is something poetic there that really interests me. It's about re-visioning and re-visioning and re-visioning. For instance, you couldn't just ask for a page and get its content, but instead we were first pushed to ask for a page and then be explicit about which revision of that page we wanted access to. And after finding that particular revision, that was also how we could find who was the author of that revision, and the time that the revision was made. So the revision was really the central way to approach pages, the focus [something about materiality?]. Also, authors were referred to as "contributors", which aligns with this thinking of revisions instead of pages, because it shifts the focus to reworking material that is already there.

Was there something about the time as well? The word "recent" came up. How did we determine what was recent? For us what could be recent is something that happened in the last day, or the last week. And of course in the wiki you can list all the changes that were made in a certain amount of time. But we had to decide on a particular understanding of "recent" when making this snapshots, and we settled on a day. Because in a snapshot, you can't put more to it, it's fixed. What do you mean? The snapshot is a frozen moment in time. So if you want to add more to it, you need to expand the definition of what you think is recent.

It's funny that you use the word snapshot again. I like slice a lot more now. Time slices! (Snapshot comes from photography, but also from the practice of taking photographs.)

We tried to look at a few different wiki's, one's that are close to us, including monoskop.org, the XPUB wiki of the Piet Zwart Institute, TITiPI's wiki, the wiki4print wiki and our own CC wiki. Why did we do that again? I think because we wanted to look at a range of wiki's that have different purposes and audiences and also different frequencies of edits. But also, the reason to choose those that were close to us is because we knew the culture of these wiki's, or we would know the people who are editing it, which would not be the case at Wikipedia for instance. This would give us a sort of understanding of the time slices we were making. They were more familiar to us. And because we would be more familiar to use we would be able to make more accurate inferences, like what's inferred by what we see. Do you remember any other reasons? I don't remember other reasons for why we chose these particular wikis, but I did feel like visualising a layer of the wiki that in print stays invisible. But that, actually, is full of very suggestive information. It feels like its a place that leaks a bit of the day-to-day reality of the people editing it into a layout. It just leaks. Which I understand can't always take place in a printed publication. But it would reveal something about the way in which a publication was made. Of course I switch now to thinking about using a wiki for publication making, but I guess that was what we were trying to look for. What the printing of this particular layer of the wiki could mean. And it turned into a kind of wiki culture form of studies. Ah yes we had a word for this! We called it an ethnographic technotext.

relearning from wikitext (edit source)

We started by thinking about all the things that disappear when you print a wiki page. We also started to think about what we could pass on to other people using wiki's to do print work.

I think there is something about the role of pedagogy in all this.

It is not really efficient to learn a new process each time you make something. But we are more interested in learning then we are interested in efficiency.

One thing i remember we did is inspecting the source on the Monoskop wiki. We went to monoskop.org and inspected the source. Once there we found a mixture of text, HTML, wikitext and also.. sparql queries? Seeing the source so directly is exciting, to seeing how other people apply ways to structure a page. I was familiar with the syntax. I could understand what was doing what. It's exciting but there is also a moment of surprise and because it is surprising it turns into a moment to learn. When you work with a workflow that is just the same every time you come back to it.. such moments of surprise do not happen. When seeing the particular way in which the Monoskop main page was made, taught me a little bit about ...

It was exciting seeing the source code, but why? Let's open the page again to look at it. Ah yes. It was exciting to see things that are familiar, such as the way that the image gallery was generated. But there are also things that are not familiar, such as the DynamicPageList thing at the bottom, I have never seen that. Have you seen this? Yes. To me it makes me curious about what this is and how it has been used. Could I use it for something else?

I know it from a project that i worked on 10 years ago... which actually brought up some interesting tensions.

On Monoskop, it's the Recent Files. The DynamicPageList is an extension that is made to generate page content based on a query. So, what this means is that it uses a particular way to send a request to the database of the wiki to render page content. In this case, it is asking for 20 images ordered in a descending way, rendered as a gallery in which each image has a width of 240px, and in which each image comes with its file size and name. I guess for Monoskop, it is a way to show the latest uploaded images, as an "update board".

You mentioned that project you worked on 10 years ago? What were the tensions? Yes, I thought it was interesting that the tensions that came up were related to a hierarchical way of working, or even thinking about how layout emerges. What I'm trying to say is that when working on Beyond Social, a project that was part of a course, so within an educational setting, in which the person who was leading the project that we made the wiki for was approaching the layout of this wiki as something that seh would need to decide upon. In other words, she would come with some sort of structure idea to have a list of projects being shown at the top of the page, and then another list of let's say practitioners under that, and then another list of student's essays. So, very much in a classical editorial way, in which she performed the role of the editor, thinking about what kind of content needs to be shown on the page. Interestingly enough though, each item in these lists were just wiki pages. And on a structural basis, by default, there is no difference in a project page, a biography page, or a student's essay page. And so, you need to come up with another layer of structure yourself in order to realise the structure that was decided upon by this editor. The tension that then emerged was, that the wiki allowed to make any kind of page, but the editorial stricture that was used to make the front page would only show the pages that followed this particular structure. So what it did, was that it pre-decided what kind of content this wiki could present while the idea of wikis actually is that a page can easily turn into any kind of $InsertWordLater(writing).

I don;t know if this makes sense, because it also feels like it describes any kind of editorial project? I was just thinking about that.. This word "editor", we are using small "e" editor.. which means a shared role that multiple people can take in. But when you speak about an Editiorial, you speak about a single person with a specific idea or vision for how the content should be presented to a reader. It does not mean that a group of people can't have a specific vision, but within the wiki cultures that we're more familiar with, this tends to come about more organically then from a top-down position. You don't see so much visions being executed, as you see conventions.

Can you give an example?

For example, the wiki that I've edited a lot and has been around for a long time is the Mediadesign wiki of the Piet Zwart Institute. This was the first wiki I edited a lot, unashamingly, and with full knowledge that other people could also see the edits that I was making. And I could also see the source code of their pages, and I could even edit the source code of their pages ;). And this was helpful, because I did not have to make the structure for my own pages myself, I could copy other peoples structure and start from there.

I was thinking about what Kendal was saying about Melonland, and the idea that people could make their own pages and with that build their own worlds. To me this sounds exciting now, because I have become a builder, but I can remember a time in which I rather inhabited a structure, rather than building it. What kind of builder have you become? I'm not sure if builder is a good metaphor. But it's the same excitement of seeing the source code of Monoskop and realising that I can build something from this. And to realise what I can learn from it.

It's great to indeed go back to these memories, because when thinking back of the project, I struggled explaining to this person that structure could emerge in other ways. I struggled to convince her, because it comes with so much more than a way to come up with a structure. If you let content emerge first on the wiki, it means that you need to organise a group of people who will write on this wiki first, to write. Which means, that first you need some kind of energy, or shared desire to contribute to a wiki. Because what happened in this project, is that students were forced to contribute something to this wiki, and to follow this particular structure. Which I think, is in two levels, not how wikis actually work.

Now I'm starting to think about the APRJA journal table of contents and how the second time we worked on it I was convinced I could come up with a clearer way to make it. And specifically keeping the another person in mind who would work on this APRJA journal after me, without knowing who this person would be. I thought it was extra important to find a semantic way of doing it. With doing it you mean making the structure? Yes. The HTML structure that you could then apply style to? Yes, MediaWiki already has a way to make a TOC, which gets activated when there are more then 2 or 3 headers on a page. But in this situation, there was already a design for the table of contents (made in InDesign years before), where the author name and title had to be presented in a particular way. There was a convention, a design convention. And it's possible to change it, but if there is a convention there, the first thought is not to change it, because it's there for a reason. So you ended up not changing the visual structure and also not the Wikitext structure that was used to create this table of contents. Where did the friction come in? It came in understanding that I was working against MediaWiki, while using MediaWiki. I was customizing it. I was bending it in a way it was not designed to be bend, in order to make a PDF. You mean that you were replicating a layout that was initially designed in InDesign, not in a MediaWiki, and thus followed a different way of building up a layout? Yes I think so... Maybe to explain more: APRJA is an academic journal. Each first page of a contribution includes the name of an author, the title of their contribution, then a subcolon, followed by the subtitle of their contribution. To make this work in wiki-to-print, all of these things had to be seperate wikitext headings. And to use the in-built table of contents of MediaWiki, would mean there would be 3 headings as the title of each contribution. It would mean that the authors name, the title and the subtitle would each be listed with their own page number (laughter). This would be so amazing, and conceptual for an experimental publication, but in this context of academic publishing, this was not desired. And also not very easy to explain to the next person who would make this publication in the future. I ended up making a heavily annotated wiki page explaining all of this, because it seemed to me that somebody just looking to the source code, would not understand what was happening there. Or it would be something that they would just copy/paste and edit it.

I want to go back to pedagogy and the notion of building. There is something about the luxury to have the time on your side. All these things are very different when you have a deadline or something.

Isn't working with a wiki something you can train yourself to do, in the same way that you need to train yourself to use InDesign? So I wonder if it is more interesting to speak about this process of continuous learning.

Even though I have familiarity with MediaWiki's and CSS print, if i would have a deadline the next day, I would not have the time to dig through the exoticness of someone else's code. It's hard to be excited about learning in those moments.

Yes, I think it's important to acknowledge that side of it, and at the same time, this aspect of learning from each other also feels like a way to build some kind of resilience or some kind of networked knowledge sharing practice that is very much based on informality, of knowing where to find things, and slowly understanding how you can become part of this network.

It reminds me a bit of the moment of discovering the Coko Foundation Mattermost chat room. After you told me that you had been in touch with the Paged.js developers. It made me more comfortable to use these tools, also to see my questions being answered, and to feel that they were intruiged by these questions. What did you ask them? How did you intruige them (haha). The first question i asked them was a question to which i did not realize that it actually was one of the most requested features, which was about footnotes and end notes, and how you could position them on a page.

I'm trying to remember where I learned about wikis when I worked on Beyond Social. I think at the time Cristina (Cochior) was working with Andre (Castro) and the design studio Manufactura Independente on a project with Renee Turner about the collection of Gisele d'Ailly's clothes, photographs and descriptions of them. The thing is, they worked with Semantic MediaWiki to annotate the collection, not through keywords but with relations. Which means that (browsing through the wiki), you can use those relations to navigate the materials on the wiki.

Kind of like how Categories organise content on a wiki?

Yes, but there is this other layer that inscribes another layer of structure, which in the end are... It feels a bit like categories and subcategories, but I think in the end there was another idea.

I worked with Semantic MediaWiki a bit and what I remember of it is the structure of a data triple. Which means that every item in a database can be the subject or object of a statement. So, for example: a shoe can have the property of leather material. A shoe + made of + leather. And somebody could have worn that shoe, resulting in the triple: a person + wearing + a shoe. This allows you to present the data in dynamic ways, simply through navigating a wiki. You could for example a list of all materials shoes are made of. Or all persons who wore this shoe.

How did we get here?

We were talking about learning. Ah yes. Learning from other wiki's.

In a way it feels like a shame that we're talking about wiki-to-print... Because the non-printed side of these publications offer so many things that you can learn from. Once you print something from a wiki, all this is not part of the printed publication. There is also a mindset that goes along with printed publications, and it's the Editorial mindset, the one with the big E. And this is because professionally printing things requires expertise, with machinery and software.. and it's almost always outsourced to professional suppliers: printers, which makes it expensive, but also very final.

I'm comparing it to this wiki here, the Warp and Weft wiki, where you have many different pathways you can follow. And all you need is a browser and the URL.

...

wiki printing as a practice (what links here)

...