The course consists of 6 two-hour sessions, in a class composed of graduate students and researchers from a mix of disciplines, including arts, humanities, social sciences and technology. Participants worked in pairs, each with a technology student who provided an element of peer-tutoring in basic programming skills. No previous programming experience was required for humanities and social science researchers.
Although participants will acquire basic programming skills, the software applications are expected to challenge conventional assumptions regarding the purpose and function of interactive digital systems. Those challenges should be grounded in rigorous critical thinking, drawing on diverse theoretical perspectives. Exemplars can be found in programmes such as Matt Ratto's Critical Making, Tony Dunne and Fiona Raby's Critical Design and Phoebe Sengers' Reflective Design.
Critical Coding 2015 will take place 12-19 June, 10.30-12.30 in the Alison Richard Building, West Road. University of Cambridge Humanities and Social Science researchers or graduate students wishing to apply for a place should download the application here and email to Dr Alan Blackwell (email@example.com). The closing date for applications is 29 May.
Here we present brief summaries of some of the projects completed in 2014.
Visualising your emotion: An interactive tool for group music making
Mao Mao and Nik Sultana
The difference between the mental model of the psychologist and the computer scientist is one critical thing that we learnt from the course. The major difference lies in the transition process from the social-oriented objectives to the technical-based solutions. In most cases, the thought-for-granted idea from social side warrants a number of steps from the digital side. And it is quite necessary to reach an agreement on the input and output of the group objective from both social side and digital side. We also gained critical insights on how to distribute labour in a team with mixed backgrounds (namely, social scientists, computer scientists, etc.) It is quite valuable to learn to make things concrete and prepare data that is ready-to-use for technical construction and communication. This is a kind of strategy for conducting effective communication between social scientists and computer scientists.
The screenshot above shows the interface for the conductor (an overview of affective status of singers when singing music 1)
Text comparison tool
Advait Sarkar and Maartje Scheltens
One can learn a lot from comparing different versions of texts. The insertions and deletions between, for instance, the Quarto and Folio editions of Shakespeare's plays can reveal interesting artefacts such as Shakespeare's changing tastes, editorial influence, or reflections of the political climate of the time. Since comparing long texts is typically extremely laborious, we wanted to build an automated tool to assist this process. We learnt some fundamental computing principles, and the basics of coding in Python by implementing some small games — it was encouraging to see these working in a few short hours! We then began iteratively developing our tool, designing its various modules and the display of the interface.
We built our tool from largely from scratch, leveraging existing modules when appropriate. In two days we had a working tool, but our software wasn't picking up differences in longer pieces of text. After days of code inspection, and at the last minute, we discovered the culprit: an undocumented default setting in an imported module. The module didn't take into account the character profile of English because it was originally designed to find matching patterns or differences in genome sequences. Our final product clearly shows differences between the texts and displays them side by side. The course was really relaxed and enjoyable and it was very useful to see the other teams presenting at the end of each session. The most interesting part was perhaps the interdisciplinary discussion about the different ways computers and humans read text, and the joint problem solving that came out of this. We now know better than to call someone crazy if they propose to teach a humanities scholar how to code, or to teach a computing scholar critical inquiry, in just 10 hours.
Ella McPherson and Meredydd Williams
The project we developed is a digital platform for citizen reporting of human rights violations. In particular, we designed this platform to facilitate the verification of these reports by allowing citizen witnesses to amalgamate a variety of corroborating digital information. Through speeding the verification process, this platform aims to improve the possibility that this reported information is picked up by human rights organizations and media outlets, and therefore the possibility that these violations receive attention and resources deployed towards their mitigation.
We called the site ‘The Whistle’ instead of ‘The Whistleblower’ because we wished to critique the extent to which identity is a requisite for digital interaction as well as how the verification of online identity on mainstream social media platforms is often linked to the person in question’s power. This can be seen, for example, with the predominant allocation of the Twitter blue verified badge to ‘highly sought users in music, acting, fashion, government, politics, religion, journalism, media, sports, business, and other key interest areas.’ This is problematic in the case of human rights, both because witnesses may wish to protect their identities, and because it is the least powerful who are more likely to be the subjects/witnesses of violations. Our platform’s facilitation of the cross-referencing of a variety of information related to the report’s content and metadata is thus designed to, as much as possible, let the information speak for itself, and therefore to somewhat shift the focus of verification away from the identity of the source.
A second critique is manifest in our site’s interface design, where we rejected the increasingly sophisticated possibilities in favor of a form-following-function simplicity. Sophistication requires complicated code, and often layer upon layer of code. The more code, the greater the chance of corruption and the greater the possibility for obfuscation. Since The Whistle exists to facilitate verification, it thrives on visibility and transparency. Accordingly, we made our interface, and therefore our code, as simple as possible.
Online Marginalia Tool
Katherine Powlesland (Department of Italian/Faculty of Computing) and Isak Herman (Faculty of Computing)
Kath: My PhD is on Dante’s Commedia, a medieval text, and I’m fascinated by some of the creative marginalia inspired by the text, particularly where readers have sought to visualise some of Dante’s more abstract or geometric concepts in Paradise (Fig. 1).
I wanted to explore with Isak whether it was possible to develop an online tool that facilitated not only textual annotation (already successfully developed in MIT’s Annotation Studio, for example) but also took advantage of the interactability of the digital environment in other, non-linguistic, ways. I was interested to know whether the reader’s engagement with a text could be deepened and rendered more active and creative, by inviting the reader to play with animated, sonic or other visual elements to collage their own multimedia marginalia.
Isak: My contribution to this collaboration involved a rudimentary introduction to front end web publishing environments, as well as a discussion of the book-keeping trade-offs inherent to online collaborative environment with one or multiple annotators, in light of the common characteristic of modern coding projects wherein the task is less of implementation, rather than design, given prior implementations of sub-components.
In the course of our interactive learning process, we explored the opportunities and limitations of the annotation constraints placed on the interface by the language, as well as the potential for dynamic description of non-textual annotations.
Kath further notes that the sheer volume of code required to script even the simplest of interactions exposed some central issues relating to authorial power and control in the programming environment. Without limitless hours of development time, the process becomes as much about selection and adaptation of existing code as about authoring original code, shifting the creative focus to disambiguation, de-bugging and the necessary application of faultless logic, giving rise to an unequal power relation: for any unexecutable script, the computer will always be right, and the programmer, by opposition, ‘at fault’. As a humanities student, my automatic reaction was to seek to defamiliarise such apparently sterile authorial control through seeking to build in elements of disruption, surprise and challenge. A new theoretical interest in how to script such possibilities such that the code doesn’t simply fail – and a mirrored exploration in my own field of whether and how an equivalent such failure may lurk in language use in ways not conceived of by Adorno and Foucault, for example – is an important legacy of this project for me.
Figure 1: Cornell Fiske Collection, Neumeister 1472: Paradiso 14.