My studio looks like Mission Control, with barely a surface not home to a computer, a monitor, or a knot of cables. The other surfaces are covered with books.
According to a data visualisation by David McCandless, the designer behind Information is Beautiful, one million lines of the computer code that runs my various laptops, tablets, and so on is equivalent to eighteen thousand pages of printed text, or roughly fourteen copies of War and Peace. The same visualisation tells me that the operating system of one of these computers, Mac OSX 10.4 Tiger, contains roughly eighty-six million lines of code, which is more than the Space Shuttle, the Hubble Space Telescope, the Mars Curiosity Rover, the Large Hadron Collider, and the Jurassic Park computer system combined. That is only the operating system, never mind the Adobe Creative Suite, Microsoft Office, and other installed software programs.
A few days ago I was having lunch with one of my colleagues and the conversation turned, as it so often does, to our respective artistic practices. I began describing to her a piece I am working on at the moment: a projection piece that displays photographs of different species of birds based on the frequency of their appearance in a list of recorded sightings on an RPSB reserve in Dumfries and Galloway. I explained the program I had written cycled through a list of sightings and chose a photograph to display when the named bird appeared. When I finished, she sat for a moment looking thoughtful.
“That’s really interesting,” she said eventually, “so to make that work you have to make a program.”
It was my turn to think. “Well,” I began, “I supposed I could make it by editing a video together but I dread to think how long it would take.”
In the days since our conversation I have been thinking a lot about programs; about my work as programs, and about the increasing overlap of photographs and programs more generally. I have been thinking about code. I realised that, so far, I have said very little about code in my writing. I have written much about photography, but little about code. This is an unforgivable oversight on my part, but perhaps also a demonstration of how deeply embedded in my practice writing code has become; and how much my own attitudes to the practice have shifted.
During my undergraduate degree, after I wrote my first program, I printed the code and pinned it to the wall of my studio. I cannot remember the precise number of pages, but it cannot have been more than twenty or so – certainly a far cry from eighteen thousand – and I am sure if I were to look at it now, I would find it unnecessarily long-winded. This was not the ‘code’ of photographs of famous works of art Yousuke Ozawa displayed in galleries, nor the RGB colour values of photographs I experimented with last year. This code was my instructions to the computer of what to draw and when to draw it: this was the program.
At the time, I was fascinated by the way this code, these normally invisible words and numbers, produced the images that appeared on screen when I ran the program. Not only that, but back then writing code for me was a struggle; my cautious first steps into Adobe Flash flanked by constant checking and re-checking online forums and my own vast collection of Post-It notes. It took time for me to make the transition from working visually to working with code, to translate images and timings into instructions for the computer.
My works, like many that fall under the term of ‘digital artworks’ are programs, pieces of software. I rarely, however, think of them in this way, and they do not sit comfortably under a banner like software art, which refers to the work of artists who write their own software and intend for it to be sued, or experienced as software. For me the program is only a part of the work – the part that controls the visibility of the photographs, or changes their colour. Making them, it goes without saying, requires a different skillset from that of taking a photograph; requires programming skills.
Working with technology, writing code, is not without its frustrations. On my less optimistic days I can sometimes be heard to mutter, “I wish I did painting. Or, to be more accurate, I sometimes wish my work were not so dependent on constantly changing commercial technologies. To cite just one example, Apple updates their desktop and mobile operating systems every year, which means to make work to run on one of their computers or mobile devices one must too constantly update both software and hardware. Older hardware does not support newer software and newer hardware does not support older software, programs simply cease to function. Digital technology’s pace of change is so fast I will struggle to run code I wrote only two or three years ago. This is not only challenging for me, as the artist making work, but for the museums and galleries tasked with showing and preserving digital artworks; not to mention costly.
That said, on my more optimistic days, I remember why I started writing code in the first place: the possibilities. My undergraduate thoughts on the subject were, I grant, rather overly optimistic, but with code I saw the possibility to do things I couldn’t do with photographic prints, or with video. In that moment, my focus was on making work that was ‘interactive’, that responded to the presence or actions of the viewer. An infatuation, it must be said, that did not last long.
Interactivity is a subject I could elaborate on in more detail, indeed I wrote my undergraduate dissertation on the subject, but for now it will suffice to say that I am highly sceptical of those works that equate interactivity with user action: pressing a button to navigate through a work of art is no more interactive than turning the pages of a book. As such, I am reluctant to use the word ‘interactive’ to describe Polaroid’s new Swing smartphone application, released earlier this month, but the user action encouraged by the app seems to point towards a broader convergence of photographs and programs.
I must point out that I have so far been unable to capture any image sequences using Polaroid Swing, as none of my current iDevices are fully compatible with the application, my iPhone and iPad are too old. I was able to install the application on my iPod, only to find that I could not use the camera function and was restricted to looking at images posted by others. My observations, therefore, are derived from looking at images posted by others both in the app and online.
Polaroid Swing is not unique in creating what the company describes as “moving photographs”, [1] ‘photographs’ that ‘move’; what are essentially very short video clips. Nor indeed is it unique in requiring user action to ‘activate’ the ‘photographs’. Apple, for instance, introduced a feature in the iPhone 6S they called ‘Live Photos’, which captures a full-resolution photograph and a few seconds of video from just before and just after the capture button was pressed. When viewing a ‘Live Photo’, if the user taps or clicks somewhere on the photograph the video will play.
Swing’s ‘moving photographs’, image sequences, are less video-like than Apple’s ‘Live Photos’, but they share a similar need to be ‘activated’ by a viewer. Instead of tapping or clicking on the photograph to advance the sequence, the viewer has to ‘swing’ the device from side to side, or move the cursor from left to right if viewing on a computer. Unlike ‘Live Photos’ the sequence can move forwards or backwards. The effect is rather like scrolling backwards and forwards through a video clip frame by frame. According to its iTunes description, Swing captures one second’s worth of images for each moving photograph, [2] though it is not clear how the images are captured and stored by the application. When I tried to save one from the application’s website, my computer downloaded a single PNG file, which suggests they are stored as individual frames.
It was the need to ‘swing’ the device that got me thinking about the relationship between the photograph and the program. The iPhone detects movement using its built-in accelerometer – a small electronic device that generates different voltages depending on its orientation – which means the Swing app is taking responding to changes in the accelerometer’s voltage output and ‘mapping’ these changes to different points in the image sequence, moving it backwards and forwards. The image only moves so long as the device is in motion, if the user stops moving the device the image remains still. Similarly, on the computer, the sequence only moves forwards or backwards so long as the mouse is moving.
Again, Polaroid Swing is not entirely unique in this respect, but its method of ‘activating’ the photograph seems more inspired by the design of today’s smartphones – specifically the incorporation of an accelerometer – than some of the other examples that spring to mind. Microsoft’s now-discontinued Photosynth application, for instance, too responded to user’s input in the sense that users could ‘drag’ the panoramas they created to view them from different angles. YouTube’s three hundred and sixty degree videos operate in a similar manner. A closer comparison might be made with Google’s Project Tango tablet, which allows the user to explore virtual three-dimensional models by moving the tablet around in space.
Frustrated by not being able to install Polaroid Swing on any of my iDevices, I decided to try my hand at making a similar image sequencer so I could better understand how the program might work. I am currently having some compatibility issues between my computer and my iPhone so I have not run my code on a smartphone yet, but I have made a simple desktop version – only nineteen lines long – using a video clip from my computer. I am used to writing programs like this, but I do not think it is an overstatement to suggest that a significant number, perhaps even the majority, of photographic practitioners are not. This is significant, for what is potentially most interesting about Polaroid Swing and other similar applications is a shift away from ‘image-making’ being focused on still images (including panoramas) and videos or animations (including GIFs) to making, for lack of a better term, ‘image programs’.
This might then be an obvious statement to make, but if there is a shift towards making ‘image programs’, then writing code is only going to be increasingly important. When I started writing code, it was because I saw possibilities not offered by other media, in a sense to not be constrained by existing tools. Polaroid Swing is a tool to make a specific kind of ‘image program’, but the ability to code, to write programs, allows for the possibility to create new tools for new kinds of ‘image programs’. Photographers will need to think about programs.
Notes
1. Polaroid, “Description”, Polaroid Swing iTunes Preview [online], https://itunes.apple.com/us/app/polaroid-swing/id1035142291 (accessed 28 July 2016).
2. Polaroid, “Description.”