7 Nascent Thoughts on Critical Artwork

Law is often an indequate discourse to publicly and intelligibly express the difficulties of legislating online space, digital privacy, surveillance, and the agency of our creations.

Art is potentially an adequate discourse to do these things.

Critical Design is an adequate discourse to do these things.

We require tactics to query legislation and norms around this politics, in an intelligible, public, and open way. In a way which isn’t couched in rhetoric. Not a strategy, not a critical stance, not in art galleries.

The erosion of public space, laws and practices curtailing individuals ability to document police action, are all of vital importance to expression, communication, socialization, and fundamentally “human-ness”.

We cannot adequately challenge a law without a legal case. The most expedient path to a challenge of a law is for someone to break it.

This is of course, bold, almost a crazed thing to ask of an artist. No one wants to go to jail, face increased surveillance, TSA pat-downs, any of the other potentially life-altering difficulties that a criminal record leads to. Yet I think that art is perhaps the only arena in which a discussion of these issues can take place. It is outside of the realm of direct commerce (by happenstance). It requires and is often granted the permission to be purely provocative and critical. It is one of the last vestiges of pure exploratory rhetoric. For that reason, it’s worth asking what questions a critical art can ask that any other type of investigation cannot ask.


[Design can be …] The stable platform on which to entertain unusual bedfellows. The glue for things that may not be naturally sticky. The lubricant that allows movement between ideas that don’t quite run together. The medium through which we can make otherwise awkward connections and comparisons. The language for tricky conversations and translations.

— Dr Ken Arnold, Head of Public Programs, The Wellcome Trust, London.

Thinking about OOO

I have read Ian Bogost and I’ve begun reading Graham Harman, and it’s becoming entirely clear to me why new media artists are so enamored with their ideas. First, Graham Harman is hard reading if you’re not comfortable with Husserl and Heidegger, but his core concepts, the necessity of considering objects and systems, is undeniably compelling. It makes perfect sense that the populist approach to OO would be taken by a video game developer. To people who make who things which really do go on to do weird unexpected things in the world the idea of a world really being filled with things which are very much independent of our selves and attitudes towards them seems very commonsense. When we can model some of the behavior of wildly disparate things like a magnet, DNA, fiber optics, and potentially lightning, all with the same fundamental mathematical concept then why not posit that things, objects really, are the superset of us and experiences, rather than vice versa?

It get particularly acute when one thinks about the things that we actually create. We can say “what do words do when they’re not being spoken?” but that’s essentially poetic nonsense. A video game however, actually might do things when it’s not being played, it has a relationship to its creator and to its player, but it also is perfectly capable of doing things that we may or may not understand at the time or at any time. It seems to have agency and increasingly computational artists are investigating that agency, the structures that enable that agency, and how we perceive that agency and structure in our own terms. We’re trying make sense of systems around us in strange ways because systems around us are irrupting into our lives in strange ways. As Clement Valla writes on glitches in Google maps:

these images are not glitches. They are the absolute logical result of the system. They are an edge condition

However, going a step beyond that, making things as a condition of thinking seems a natural response to living in a place and set of systems which we have given agency and which we can inspect at a remove, in a strange way. These are our creations, but they are, taken in sum, acting far beyond us, and when we see their processes, it is in a translated artifact. Screenshots, videos, do not accurately represent the state of a system, but they can stand in for it, they can pique our imagination. Aestheticizing these images and this artwork does as much to help us actually comprehend a system as say a Marinetti painting helped Europeans understand the burgeoning military-industrial complexes of late 19th and early 20th century Europe: it doesn’t in the strict sense. That’s an interesting place for a programmer, an engineer of sorts, to be: creating and exploring impressionistic artifacts. It might be though, that it’s the most appropriate place for an engineer/artist to be:

“the human/world relation is just a special case of the relation between any two entities whatsoever.” – Quadruple Object

That’s a great quote, particularly appealing to a programmer: my program interfacing with a user is not entirely dissimilar from my program interfacing with another program. We live in a world where despite our best efforts the motivations and inner workings of others remain rather mysterious, worthy of aestheticization, poetry, and wonder. We also increasingly surrounded by human-scale actors and the artifacts of their actions, in that “we” live in cities, we live quite connected, we live quite instantaneously, and we can either by ourselves or with proxies capture a remarkable amount of the world as it appears to us. We have odd strategies for comprehending this, for example:

“All information is grounds for knowledge, whether empirical or aphoristic, no matter its truth-value” – Meta-Modernism

Which sounds to me an implicit recognition that incoherence, error, invisibility, might just be temporary states of our particular relation to something. Our tools and systems might be able to make more sense of it than we can, having, unlike us, infinite attention spans and no need for sleep or sitcoms. Taking that as the departure point for aesthetic investigation, an active and inquisitive investigation that is conducted through making machines and tools which will form their own opinions on things and which we can query in whimsical or critical ways, seems to me, the most coherent aesthetic I can imagine.

7 quotes germane to Object Oriented Ontology

Ian Bogost

“Ontology is the philosophical study of existence. Object-oriented ontology (“OOO” for short) puts things at the center of this study. Its proponents contend that nothing has special status, but that everything exists equally—plumbers, DVD players, cotton, bonobos, sandstone, and Harry Potter, for example. In particular, OOO rejects the claims that human experience rests at the center of philosophy, and that things can be understood by how they appear to us. In place of science alone, OOO uses speculation to characterize how objects exist and interact.”

Ludwig Wittgenstein

“What is the meaning of the word ‘five’? No such thing is in question here, only how the word ‘five’ is used.”

CS Pierce

“Consider what effects which might conceivably have practical bearings we conceive the object of our conception to have. Then, our conception of these effects is the whole of our conception of the object.”

Paul Churchland

“Your brain is far too complex and mercurial for its behavior to be predicted in any but the broadest outlines or for any but the shortest distances in the future.”

Alain Badiou

“I think multimedia is a false idea because it’s the power of absolute integration and it’s something like the projection in art of the dream of globalization. It’s a question of the unity of art like the unity of the world but it’s an abstraction too. So, we need to create new art, certainly new forms, but not with the dream of a totalization of all the forms of sensibility.”

Bruno Latour

“…scientific and technical work is made invisible by its own success. When a machine runs efficiently, when a matter of fact is settled, one need focus only on its inputs and outputs and not on its internal complexity. Thus, paradoxically, the more science and technology succeed, the more opaque and obscure they become”

Thomas Kuhn

“Contrary to Latours oft-repeated claim that politics has never taken technology seriously, totalitarian regimes stand out from traditional forms of authoritarianism precisely by the role assigned to technology as the medium through which citizens are turned into docile subjects, specifically parts of a corporate whole. While attention has usually focused on totalitarian investments in military technology, of more lasting import have been totalitarian initiatives in the more day-to-day technologies associated with communication”

World Map for data viz

All elements are tagged with nice labels, nations and US states. US states are a bit messy as I did them by hand, but the boundaries are approximately right

I wanted this for a while, mostly for doing “where are people” visualizations, but never could find a nice SVG file that had all of this in it. Now I do. Download it here

A Tool For Thinking versus A Tool For Doing Things

I was just teaching a workshop at CIID in Copenhagen where we introduced designers of various sorts, industrial, graphic, service, to Processing, generative design, and to the idea of Natural User Interfaces, i.e. the Kinect. I was happy with the results, what the students learned and what they produced (here for instance), but I walked away wondering the same thing I always wonder when I teach non-CS students programming: what’s the difference between thinking about code as a tool for doing things and thinking about code as a tool for thinking? What does that mean for making things and for talking about and teaching people code? Since I write about code, teach workshops, do documentation, these questions are, as they say, relevant to my interests.

Lots of times we, and by “we” I mean “programmers” think of code as a tool for doing stuff, we don’t care about the implementation underneath, we blindly reach into boost::asio, we fire up Rails without actually looking at what ActiveRecord actually does, we just do things. Make a website, a routine phone app, a CRUD application, these are things that I and I suspect many others, often do on auto-pilot. When I use code to think, I find myself usually looking at weird compiler behavior, hidden or little-known features of languages (example). I think about code, about computation, about what it means to think in code when I think in code. Sometimes I think about algorithms, but rarely. Sometimes I think about the behavior of an algorithm or the pattern in a signal or dataset, but then I’m not thinking in code, I’m looking through code, but I’m not really thinking with it, I want it out of the way so I can see what I’m looking at. So there’s really a few different levels of involvement here:

  1. Running Code
  2. Using Code
  3. Thinking Code

And those are interesting things to try to explain to students. I didn’t do a good job of it this time, and I regret that, and I’m going to rectify that mistake next time because, particularly in design and for designers, it’s important to tell people what the tool they’re picking up actually is. When you pick up a library in Processing that has clearly defined behavior, you’re usually doing something like #1: just running code. Maybe you change some colors, some parameters, tweak what things do, off you to see how your thing works. To someone raised on reading Hackers Delight, that’s complete heresy. To someone raised to think of tools as being nothing more than elements of a task, then that’s of course what you do. If you buy a hammer that doesn’t hammer your nails, then you go back to the hardware store and get another one, no? And that sort of makes sense, except that it also cripples you. You end up with the rote permutations on the low-lying fruit of algorithms. You treat programming like you treat Excel. Instead of invention, discovery, and experimentation, you get expressions, behaviors, and pre-defined routines that you can mix and match, but never alter. So, is that wrong? I’m not sure. I teach people to think of code as tools because it gets them started thinking that code is interesting. They can do things with it. They are, without a doubt, horrible programmers, and they will continue to be horrible programmers hamstrung by their tools, for perhaps years, or in all likelihood, forever. They implement things they barely understand, leverage things they don’t appreciate, and run into mistakes that they can’t comprehend. And, I think, that’s probably ok. It’s not a failure of mental capability on their part or failure to communicate on the part of their professors: it’s simply not necessary for being a designer working with interaction.

Thinking about things is using a medium to formulate an expression. Grammar, syntax, norms. These tools for creating novel expressions of the medium itself. Algorithms, data types and containers, device drivers, protocols, fundamental objects of a mode of interaction, I could go on, but these are a few things that strike me as being to code what poetry is to written language. A tool for thinking has codified norms and rules but generally a limited interface because the more complex the interface, the more limited the possibilities for expression. We limit the interfacing mechanics because to do so frees the mind. A tool for making something on the other hand has an intentionally limited interface, because we’re primarily concerned with having blocks of functionality be legible to us. It’s that last word that sums up what I think designers and non-traditional technical people need to have and what I was trying to teach at CIID: code literacy. Code fluency is a vital and profound tool for interaction design, but it’s a necessary one. Code literacy increasingly is a necessary tool, though how exactly that sits at the intersection of “thinking” and just “doing”, how to best fit tools to both of those scenarios, is something that I’ve yet to parse out completely. I’m far from the only one thinking of this. In fact, a great number of people who do interaction design, whether they know it or not, are working on this problem. That’s what makes it a good problem: it’s big, there’s a lot of ways to be wrong and right, and a lot of fruit that can be born from it, both in terms of thinking about how we learn things and thinking about how we think. Which is a long way of saying: I had fun in my workshop, and I’m looking forward to doing it again next year.