Exploring and stretching coding contingencies using code documentation practices as a backdoor to inject context in software.
### Coding Contingencies
Coding contingencies are conditions we found ourselves in. Not entirelly by chance, but on entirelly by choice as well. Sometimes these contingencies are economical: in order to work in this studio, you need to program with this framework. Sometimes affective: a friend shares the excitement over a new visual programming language. Sometimes
Politics of participation & representation
from transfeminist servers to queer motto api to 360 degrees of proximity
from alt-text poetry to p5js inclusivity guidelines to soupboat
Aesthetic practices
the screenless office and chimeric worlding
aesthetic programming and software studies
!!! placeholder ""
- when the entry points are blocked one has to search for backdoors
- little context for backdoors
- not only to participate in the making of software
- but also to inject values,
Here documentation is seen as a surface that could host principles in close contact with algorithms, letting them entangle and shape each other. A way to orientate our instruments towards "non-extractive relationships, but in the meantime, being accountable for the ones they are complicit with." (A Wishlist for Trans\*feminist Servers, 2022)
!!! placeholder ""
- a way to transform coding contingencies? see introduction / move it here?
- programming as a way of sharing context
- what is contingent in this context? (meaning slightly out of reach)
- materiality? text editors? popular languages? economics?
- what can be changed?
How do you choose a particular programming language, a coding paradigm, a development environment, an infrastructure where to run the code, and so on? These are not just technical choices, but rather coding contingencies.
How do you choose a particular programming language, a coding paradigm, a development environment, an infrastructure where to run the code, and so on? These are not just technical choices, but rather coding contingencies.
@ -35,7 +8,7 @@ The IT class in a public school. The job requirements for working in a tech comp
These contingencies are situated in specific contexts.
These contingencies are situated in specific contexts.
Programming then is not just sharing code, but sharing context. A significant statement about our relationship to the world, and how we organize our understanding of it (Ullman, 2017). A perspective to look at reality, before attempting to get some grip onto it with a script. A way to deal with both the software and hardware circumstances of code (Marino, 2020), but also engaging with the sociality and communities around it.
Programming then is not just sharing code, but sharing context. A significant statement about our relationship to the world, and how we organize our understanding of it. A perspective to look at reality, before attempting to get some grip onto it with a script. A way to deal with both the software and hardware circumstances of code, but also engaging with the sociality and communities around it.
It's an approach that helps us to think about software as a cultural object. Something "deeply woven into contemporary life –economically, culturally, creatively, politically– in manners both obvious and nearly invisible." (Fuller, Manovich and Wardrip-Fruin, 2009), and not just as technical tool existing in a vacuum.
It's an approach that helps us to think about software as a cultural object. Something "deeply woven into contemporary life –economically, culturally, creatively, politically– in manners both obvious and nearly invisible." (Fuller, Manovich and Wardrip-Fruin, 2009), and not just as technical tool existing in a vacuum.
@ -45,22 +18,8 @@ The main focus of this chapter is to explore software documentation as a surface
A way to situate programming in specific contexts.
A way to situate programming in specific contexts.
Here documentation is seen as a surface that could host principles in close contact with algorithms, letting them entangle and shape each other. A way to orientate our instruments towards "non-extractive relationships, but in the meantime, being accountable for the ones they are complicit with." (A Wishlist for Trans\*feminist Servers, 2022)
!!! placeholder ""
- to expose people usually out of reach to different contexts
- literacy and exposition to certain concepts
- care vs attention economy
If we follow mainstream narratives, programming strives to be purely technical. Immaculate from the sin of politics. It's not rare to read comments online from users that demand to keep politics out from code repositories. Faithful to the western tradition of separate fields of study, coding wants just to be coding. All about performance and speed, new updates and features. A space where all problems are mechanical and can be solved.
But it wouldn't be fair to think that programmers simply don't care. Sometimes it's just a matter of being exposed to certain ways of thinking. Before the bachelor at the Accademy of Fine Arts for example, I've never been exposed to the writings of Donna Haraway, and I had no idea that concepts from feminism could have been so relevant also for me.
!!! note ""
if you cite Haraway better explain why it's important for you etc
Here code documentation could work as a backdoor: hacking its way to people that have never been exposed to certain topics. A way to offer an entry points to other worlds, and ground political choices into technical details.
from reaching a public to creating a public
### Documentation & distribution
### Documentation & distribution
@ -89,13 +48,13 @@ One example is the paradigm of constant availability of the server. Behind every
To inject context in software is required to operate at different scales. Within both public and private dimensions, with technical and social frameworks. During a workshop for example, people meet face to face. Here togetherness can glue technicalities together, questioning reproduction of knowledge and its power dynamics.
To inject context in software is required to operate at different scales. Within both public and private dimensions, with technical and social frameworks. During a workshop for example, people meet face to face. Here togetherness can glue technicalities together, questioning reproduction of knowledge and its power dynamics.
Code documentation is knowledge trasmission, traditionally conceived as a vertical and centralized practice, where who is teaching and who is learning stand at radically diametrically opposite sides of the spectrum, in well defined roles. From this perspective only the _real programmer_, the expert that detains a phantomatical _foundational knowledge_, is allowed to share wisdom and document code.
Code documentation is knowledge trasmission, traditionally conceived as a vertical and centralized practice, where who is teaching and who is learning stand at diametrically opposite sides of the spectrum, in well defined roles. From this perspective only the _real programmer_, the expert that detains a phantomatical _foundational knowledge_, is allowed to share wisdom and document code.
As argumented by Kit Kuksenok during the activation of their workshop _Sharing Programming Knowledge_ at Varia (Rotterdam), things are more fluid than that: everyone is sometimes a learner, and sometimes a teacher. Each role brings valuable insights to its counterpart, and taking it into account open the way for other pedagogical and organizational tactics for sharing knowledge. One example are collective learning moments, situations where code documentation is at the same time active practice and shared surface, wobbly ok but more horizontal.
As argumented by Kit Kuksenok during the activation of their workshop _Sharing Programming Knowledge_ at Varia (Rotterdam), things are more fluid than that: everyone is sometimes a learner, and sometimes a teacher. Each role brings valuable insights to its counterpart, and taking it into account open the way for other pedagogical and organizational tactics for sharing knowledge. One example are collective learning moments, situations where code documentation is at the same time active practice and shared surface, wobbly ok but horizontal.
_360 degrees of proximities_ is a project emerging from a network of feminist servers, addressing the problem of invisible labor tipically associated with maintainance of digital infrastructure.
_360 degrees of proximities_ is a project emerging from a network of feminist servers, addressing the problem of invisible labor tipically associated with maintainance of digital infrastructure.
After a sucessfull setup of a self-hosted Peertube instance, a federated platform for sharing video contents, the group started questioning aspect regarding the maintenance of the system. Instead of centralizing the service in a self-exploitative scenario, they decided to redistribute it on the network working together with other feminist and queer communities, empowering them to build their own video platforms autonomously, but in a joint effort where different knowledges meet. On one hand the know-how about installation and configuration of Peertube brought by the _360_ team, and on the other site-specific knowledge of the hosting server.
After a sucessfull setup of a self-hosted Peertube instance, a federated platform for sharing video contents, the group started questioning aspects regarding the maintenance of the system. Instead of centralizing the service in a self-exploitative scenario, they decided to redistribute it on the network working together with other feminist and queer communities, empowering them to build their own video platforms autonomously, but in a joint effort. Here different knowledges meet: on one hand the know-how about installation and configuration of Peertube brought by the _360_ team, and on the other site-specific knowledge of the hosting server.
Here is where the interesting friction of situated documentation arises: how to share knowledge about something deeply situated with other contexts? How to remain legible and accessible, while at the same time preserving specific and characterstic choices? Usually documentation doesn't take into account the messiness of coding contingencies, where multiple software cohexist in the same server and configurations conflict with each other, or are installed with different setups. Collective learning moments can close the gap between an ideal setup described in the docs and a real-world, situated one.
Here is where the interesting friction of situated documentation arises: how to share knowledge about something deeply situated with other contexts? How to remain legible and accessible, while at the same time preserving specific and characterstic choices? Usually documentation doesn't take into account the messiness of coding contingencies, where multiple software cohexist in the same server and configurations conflict with each other, or are installed with different setups. Collective learning moments can close the gap between an ideal setup described in the docs and a real-world, situated one.
@ -104,7 +63,7 @@ Here is where the interesting friction of situated documentation arises: how to
_Alt-text as poetry_ is a project by Bojana Coklyat and Shannon Finnegan:
_Alt-text as poetry_ is a project by Bojana Coklyat and Shannon Finnegan:
a workbook dedicated to the alternative text descriptions that make web images accessible to people who are blind, with a low vision condition, or have other cognitive disabilities.
a workbook dedicated to the alternative text descriptions that make web images accessible to people who are blind, with a low vision condition, or have other cognitive disabilities.
Websites are made of HTML, a markup language composed of tags. Each tag represents an element of the document: a header, a paragraph, a link to another page, an image, and so on. As in a sandwich, these tags can be composed together, and organized to structure the contents of a web page. Every tag comes with particular attributes, and the image `<img>` one requires the developer to specify the source `src` of the picture to display. Here is also possible, but not technically mandatory, to add an `alt` attribute, with the alternative description of the image used by screen readers and other assistive technologies.
Websites are made of HTML, a markup language based on tags. Each tag represents an element of the document: a header, a paragraph, a link to another page, an image, and so on. As in a sandwich, these tags can be composed together, and organized to structure the contents of a web page. Every tag comes with particular attributes, and the image `<img>` one requires the developer to specify the source `src` of the picture to display. Here is also possible, but not technically mandatory, to add an `alt` attribute, with the alternative description of the image used by screen readers and other assistive technologies.
@ -116,9 +75,7 @@ Alt-text is an essential part of web accessibility. It has existed since the 199
The workbook of Cocklyat and Finnegan is a whole piece of code documentation dedicated to a single HTML attribute. It re-frames `alt` text as a type of poetry, and provides exercises to practice writing. Their intention is not just to allow alt-text users to be able to access visual content on the internet, but to let them feel a sense of belonging in the digital spaces. By highlighting the needs of often marginalized minorities, and giving them propper representation, documentation can activate ways of thinking that actively shape technical implementations, acknowledging both the needs of machines and programmers and users as well.
The workbook of Cocklyat and Finnegan is a whole piece of code documentation dedicated to a single HTML attribute. It re-frames `alt` text as a type of poetry, and provides exercises to practice writing. Their intention is not just to allow alt-text users to be able to access visual content on the internet, but to let them feel a sense of belonging in the digital spaces. By highlighting the needs of often marginalized minorities, and giving them propper representation, documentation can activate ways of thinking that actively shape technical implementations, acknowledging both the needs of machines and programmers and users as well.
Documentation and technical implementations influence each others as in a feedback loop. The power of code documentation of encouraging a certain set of practices molds successive implementations, that in turn consolidate and normalize previous choices. Here technical and design decisions can create or foreclose spaces for others to participate in programming practice.
Documentation and technical implementations influence each others as in a feedback loop. The power of code documentation of encouraging a certain set of practices molds successive implementations, that in turn consolidate and normalize previous choices. Here technical and design decisions can create or foreclose spaces for others to participate in programming practice. This process of course doesn't happen in a streamlined and linear fashion, but rather as a bouncing and transversal echo, reaching neighbouring contexts and other projects as well.
This process of course doesn't happen in a streamlined and linear fashion, but rather as a bouncing and transversal echo, reaching neighbouring contexts and other projects as well.
Inspired by Alt-text as poetry for example, I decided to write the code for the pages in my space of the Soupboat in a way that does not display images if they don't come with a propper description. An implementation aimed to slowly train and sensibilize myself.
Inspired by Alt-text as poetry for example, I decided to write the code for the pages in my space of the Soupboat in a way that does not display images if they don't come with a propper description. An implementation aimed to slowly train and sensibilize myself.
@ -131,6 +88,11 @@ Inspired by Alt-text as poetry for example, I decided to write the code for the
```
```
_Code for the project pages on the soupboat. The figure with the header is added if and only if both cover and alt description are provided._
_Code for the project pages on the soupboat. The figure with the header is added if and only if both cover and alt description are provided._
!!! note "proper description?"
what does it even mean "proper"
you are just checking if there is an alt or not
not checking quality
An implementation first approach however is not always an option, and code documentation is a more adeguate surface to work with. The `p5.js` library for instance offers a `describe()` and `describeElement()` functions, to provide a description analogue to the `alt` text one for their visual sketches. The interactive graphics are based on the HTML `canvas` element, that instead of dealing with its contents in a semantic way as HTML does, works on pixel bases. Similar to images, these contents are not compatible with screen readers, and require a text explanation in order to render accessible what's happening on the display. Even more: while images are usually static, p5.js visuals are often in motion, and evolve through time. With `describeElement()`, developers can even be more granular in their descriptions, captioning transformations of different elements in their animations.
An implementation first approach however is not always an option, and code documentation is a more adeguate surface to work with. The `p5.js` library for instance offers a `describe()` and `describeElement()` functions, to provide a description analogue to the `alt` text one for their visual sketches. The interactive graphics are based on the HTML `canvas` element, that instead of dealing with its contents in a semantic way as HTML does, works on pixel bases. Similar to images, these contents are not compatible with screen readers, and require a text explanation in order to render accessible what's happening on the display. Even more: while images are usually static, p5.js visuals are often in motion, and evolve through time. With `describeElement()`, developers can even be more granular in their descriptions, captioning transformations of different elements in their animations.
@ -138,22 +100,24 @@ In the discussions around the development of this open source project, contribut
!!! note "better conclusion"
wrap up why documentation here is better than implementation
### Hello worlding
### Hello worlding
The Screenless Office is an _artistic operative system_ by Brendan Howell and Mikhail Pogorzhelskiy to reimagine personal computing away from pixel-based displays, using radically alternative forms of everyday human interaction with media.
The Screenless Office is an _artistic operative system_ by Brendan Howell and Mikhail Pogorzhelskiy to reimagine personal computing away from pixel-based displays, using radically alternative forms of everyday human interaction with media.
Similarly to other operative systems, the Screenless Office can be used to read news, browse websites and interact with social media. What's different here is that the surface where all these exchanges happen is not a screen, but rather an articulated ecosystem of thermal and laser printers, barcode scanners and other interconnected physical devices that can be plugged in or printed at need.
Similarly to other operative systems, the Screenless Office can be used to read news, browse websites and interact with social media. What's different here is that the surface where all these exchanges happen is not a screen, but rather an articulated ecosystem of thermal and laser printers, barcode scanners and other interconnected physical devices that can be plugged in or mounted at need.
The first interaction with the Office prints a menu that lists the available commands, in the form of a list of functions with description and relative barcode. From here one can scan the barcode to read the news, for example, and receive a web-to-print feed with the latest stories. Each post in the feed is a small preview of an article scraped from several online sources, and can in turn be barcode-scanned to get a print of the complete version.
The first interaction with the Office prints a menu that lists the available commands, in the form of a list of functions with description and relative barcode. From here one can scan the barcode to read the news, for example, and receive a web-to-print feed with the latest stories. Each post in the feed is a short preview of an article scraped from several online sources, and can in turn be barcode-scanned again to get printed the complete version.
In an interface culture dominated by few corporate players and cristallized on touchscreen glass, the project offers multivarious gestures for interaction, in contrapposition with the single act of scrolling. Instead of sitting in front of a screen with a singular, centered, and linear perspective, the user displaces the office all around through printers, scanner and printed materials. Code documentation plays a key role in the orchestration of all these different interactions.
In an interface culture dominated by few corporate players and cristallized on touchscreen glass, the project offers multivarious gestures for interaction, in contrapposition with the single act of scrolling. Instead of sitting in front of a screen with a singular, centered, and linear perspective, the user displaces the office all around through printers, scanner and printed materials. Here code documentation plays a key role in the orchestration of all these different interactions.
The system is written in Python, and its code documentation consists mainly of _docstrings_ and comments written directly in the source.
The system is written in Python, and its code documentation consists mainly of _docstrings_ and comments written directly in the source.
A _docstring_ is a piece of text written at the very beginning of a function to document it. Unlike normal comments, that are usually stripped out from code at runtime, _docstrings_ are preserved, and can be consulted with interactive help systems or used as metadata. Many programming languages support this pattern, that is often used to produce automatic pieces of documentation by simply collecting and listing all the functions and relative descriptions.
A _docstring_ is a piece of text written at the very beginning of a function to document it. Unlike normal comments, that are usually stripped out from code at runtime, _docstrings_ are preserved, and can be consulted with interactive help systems or used as metadata. Many programming languages support this pattern, that is often used to produce automatic pieces of documentation by simply collecting and listing all the functions and relative descriptions.
In the project these are used to create a world around the code and its structure: in the initial menu, for example, they are used as scenography for the Screenless Office. Reading it we discover how the office is organized in different _bureau_, each dedicated to a specific task. The _Pubblications Office_ deals with daily news and weather forecast, the _Public Relations_ department manage exchanges with social platforms, the _Audio Service Dept._ provides for playback soundtrack, and so on, with the _Inhuman Resources bureau_ keeping track of them all.
In the project these are used to create a world around the code and its structure: in the initial menu, for example, they are used as setting for the Screenless Office. Reading it we discover how the office is organized in different _bureau_, each dedicated to a specific task. The _Pubblications Office_ deals with daily news and weather forecast, the _Public Relations_ department manage exchanges with social platforms, the _Audio Service Dept._ provides for playback soundtrack, and so on, with the _Inhuman Resources bureau_ keeping track of them all.
