It is difficult to future-proof, properly record, and accurately document a web-based project. The benefits of other forms of documentation (traditional photography, camera recordings, text-based archiving) over screengrabs, gifs, or pngs, often include metadata that is stored to place context around the image, or video. Screengrabbing was used as a method of documentation in two recent online exhibitions I curated: Real-Time Constraints in late 2020 and arebyte’s Plug-In for The Wrong in late 2021/22.

Real-Time Constraints
Real-Time Constraints was a group exhibition I curated featuring works by artists working within the realms of artificial intelligence, algorithms, machine learning, big data, and interventions in web-based platforms. The exhibition brought forward the complexities of the present tense, in light of the emergence of such technologies, through works that were generated using real-time information pulled from the internet, or other sources, including news items, message exchanges, memes and image banks.The works looked critically at the current state of automated and autonomic computing to provide alternative narratives to data-driven and algorithmic approaches, referencing fake news, gender bias and surveillance.

Taking the form of a browser plug-in, the exhibition revealed itself as a series of pop-ups, where the works were disseminated over the duration of a typical working day, interrupting the screen to provide a ‘stopping cue’ from relentless scrolling, email notifications and other computer-centred, interface-driven work. Real-Time Constraints presented itself as a benevolent invasion - the size, quantity, content and sound of the pop-ups had been decided upon by each artist to feed into the networked performance. The exhibition was experienced through a synchronised global approach where viewers encounter the same pop-ups at the same time, no matter where they were, amplifying the exhibition’s disturbance of mundanity across every time zone.

Real-Time Constraints made its primary argument through a reconfiguration of the usually annoying and uninvited browser pop-up, turning what is typically a tool of the system (and its owners) into a user-centric stopping cue. Stopping cues were most prevalent in the 20th century as a way to signal the end of something, the space in between one activity and the next. Stopping cues imposed a choice for the viewer: do you want to continue watching/reading/listening, or do you want to do something else? They also made the mental space available one needs to digest what they'd just experienced, enabling useful processing of information, and thus, satisfaction through action. In the way we consume media today, there are no stopping cues. There is no design in place that allows us to question our behaviour; social media applications, news sites, streaming services, email and messaging services are a bottomless source of mindless scrolling. Real-Time Constraints invited critical reflection on the systems and processes we are (still) embedded in all day long and allowed viewers to take a break from the animated bombardment of working online, albeit unannounced, to be a welcome distraction.

The Wrong
As an adaptation of the Real-Time Constraints, the Plug-In for The Wrong condensed the magnitude and unique breadth of exhibitions and works featured in the biennale to be presented as a more selected presentation. Originally positioned as a new way to experience, The Wrong projects were made iterative, pulled apart and pieced back together via programming a series of pop-up windows, their size, position on the screen, timing and information to be decided by each curator. The pop-ups could contain images, audio, auto-play video, iframed websites and 3D digital worlds which were streamed directly to the viewer's screen, relinquishing the need to click through to experience the works. Instead the projects unfolded slowly, or quickly, over the period of a week, allowing the fragments to be digested in a different way. It was important for the online projects, especially website-based exhibitions, to be fluid and to make sense to be seen away from the website it was initially intended to be experienced. The dual-sited nature of this meant curators could revisit and adapt their projects for a new way of viewing; for some curators this meant adding extra or exclusive content, for others it meant delivering something long form, like a film series, as an extended screening.

Screengrabbing as a net art practice
It is difficult to future-proof, properly record, and accurately document a web-based project. The benefits of other forms of documentation (traditional photography, camera recordings, text-based archiving) over screengrabs, gifs, or pngs, often include metadata that is stored to place context around the image, or video. Exchangeable Image File Format data can contain camera exposure, date and time the image was captured, GPS location, ISO and shutter speed, aperture, white balance, camera model and make. This data is useful when conducting search functions on large amounts of imagery, and provides important information for identification and copyright protection, as well as for other photographers who might need this information when trying to learn new techniques.

However, this type of data is perhaps only relevant for documentation of physical work. What are the perimeters when documenting a project that exists solely online? This is something I encountered when thinking about how to capture the essence of the plug-in tool for exhibition curating. Documentation of an online tool, custom webpage or project is especially difficult if the backend isn’t pushed to github, isn’t made openly accessible and/or maintained by the artist, developer or gallery. Not to mention the fact that all of this relies on the larger currents of the tech economy and their interest in maintaining technologies and saving them from redundancy… There are many examples of great work done in the field of archiving net art and web-based projects, Rhizome’s Artbase and the Digital Art Archive to name a couple, but it’s important to understand the breadth of the project to be documented and what might be useful to keep a record of. Art that is mediated through a screen requires a different methodology of documentation, a methodology that DAA describes as being “an expanded concept of documentation”, and one that needs careful consideration and forward planning.

Net art is inherently context-dependent through the nomadic sites of presentation it carries: sometimes a projection, sometimes a large tv, sometimes a laptop, sometimes a phone, sometimes a QR code, and-so-on. It is also usually a mix of many kinds of viewability: procedural, interactive, process-driven, multimedia, multiplayer, transient, performative, generative, automated, and often sometimes faulty. All of which adds to the complexity and specificity of experiencing it again in retrospect, or as documentation.

Unlike physical artwork that requires at least some form of IRL medium, art of a digital nature isn’t necessarily situated within the material landscape - with the exception of the physical infrastructure of the internet, of course, and other more hybrid works - but is rather made up of web browsers, developer codes, scripts, search engines, and various other online tools, as well as zeroes and ones and bits and bytes, that coalesce together to form the work on the screen. This may pertain more to the conservation of such work but is important to note within the context of documentation as net-art challenges this binary. As an integral part of the work, if you aren’t also archiving the code, the developer notes, the iterations, or the roots of the work, then do you have complete documentation of it? Discounting the inevitable possibility that the software used to create the work might cease to exist in the near future (Javascript, for example) the question of how net-art should be documented properly has been mulled over since the early nineties by many notable figures in the scene. It is also inherently reliant upon the existence of software, browser engines, programming languages, server architecture, and everything in between, in such a way that it becomes contingent.

To return to arebyte’s plug-in and the two projects it has shown, Real-time Constraints in 2019, and a curated selection of embassy’s from The Wrong biennale in 2021/2022, understanding the best way of documenting has been and continues to be somewhat ambiguous. Understanding the span of a project - with all the nuance, interaction and reach, accounts of visitor experiences, and relevance - often comes with hindsight and so documentation of transient projects like the plug-in is often transient too. Screengrabbing as a form of documentation is often the first port-of-call but should be one of many ways adopted to ensure a project receives the documentation it deserves.