APIs

 

If a new article is posted on the New York Times containing the keyword ‘explosion’, then send a blink event.

An explosion somewhere in the world is the catalyst for a reaction that goes something like this: explosion > reporters and witnesses > publication > IFTTT > blink(1). In that sense, the blink(1) event is a continuation of a reaction set off by a real world explosion.

• • •

A bulk of the craft involved in arts-engineering is making technologies talk to each other. This fact is highlighted in Jim Campbell’s “Formula for Computer Art”, a diagram resembling a slot machine that reveals (painfully so, for me) the unoriginality of merely mapping an input to an output via some unseen algorithm. Campbell’s astute diagram is a challenge to move beyond this formulaic approach to art-making. But as Golan pointed out in class, Campbell neglects to include mention of a viewer or participant (aside from inputs like “spoken words” or “number of people”). Perhaps this exclusion is telling, and interactive elements makes for more engaging art.

I don’t think Campbell’s diagram precludes mapping of some input to an output, so long as the mapping is meaningful. In “Art and the API” Jer Thorp makes the case for connections via APIs. APIs are glue for connecting people, systems and events through the medium of software. He illustrates a number of interesting use cases for APIs, like using drone strike data provided by The Bureau for Investigative Journalism to populate a Twitter feed. IFTTT (“If This, Then That”) simplifies the process of orchestrating technologies by leveraging the APIs of popular services.

What IFTTT gains in accessibility, it sacrifices in flexibility; connections can only be made between the included APIs. For prototyping projects at a smaller scale that aim join two of the included services, I could see IFTTT being useful.