APIs, Openness and the expanded field: A Q+A with Even Westvang 0
Now that we’re starting to get nostalgic and have cravings and abstinence crisis about Webdagene 2014 (It’s been 5 weeks, can you believe it?), it seems like a good idea to refresh and expand a few relevant topics, like Even Westvangs‘ talk “Open developments: A short talk in 2 parts”:
Bengler’s principal have reported to us about his Safari adventures in the public sector data and it got me thinking about how to self-initiate change, transformation and how to structure information so it can resist the test of time. So we don’t always have to built the same things from zero, but rather, establish a strong network of interrelated services that help each other.
João Doria: I’d like start our chat by throwing two distinct references on the table. One, apparenty silly but super serious is an excerpt of one of R. Kelly’s lyrics (shout out Harry Gassel) in his song Real Talk:
Girl, I’m not about to sit up here and argue with you
About who’s to blame or call no names, real talk
See girl, only thing I’m tryin’ to establish with you is not
Who’s right or who’s wrong
But what’s right and what’s wrong, real talk
And, most importantly, another reference is Pierre Huyghe’s The Housing Projects:
Under that light, let’s talk a little bit about the use of the terms architecture and ecosystem in design practices, and what they personally mean to you and your work? I still have a vivid memory of two respected urbanists laughing at me once I mentioned such terms in a conversation about interactive design. Still, I find it quite useful to borrow concepts and terms from other fields of knowledge (I’m not the only one doing so) and try to establish bridges as a way to stay in touch with a broader idea of what design is and does.
Even Westvang: Ah, yes. We do steal like ravens and the urbanists do laugh. But the field does deliver some apt metaphors. For example when thinking about how to build social software, new urbanism has a bucket of useful concepts, like armature, enclaves and heterotopias for dealing with flows of people and a I think a pretty apt normative view on how to structure space for “positive” outcomes.
Also there is the whole strand of thinking about patterns and anti-patterns from software design that is directly derived from Christopher Alexander and his pattern language for the built environment.
2. Design principles, architecture for Openness
João Doria: Beautiful references! A few friends did a poster series starting from Alexander’s “Green-Making Sequence” resulting in a series of design principles for local publishing that can easily be transposed to whatever media we might choose.
Even Westvang: People might imagine immaterial artefacts like software to be plastic and mutable. They’re not. Information technology ossifies, hardens around original intents. In this respect it’s exactly like the built environment. Just because you have a bungalow and low rise block of apartments doesn’t mean that you can combine them in a meaningful way at a later point. Mash them together.
It is therefore important to consider infrastructures that embraces the future needs – that’s not brittle. So we design modular systems, with clear abstractions at the points where we expect needs to change, to hopefully let software learn a bit easier than buildings do. At the same time a freely composable modularity comes with costs that make them unfriendly to the real world. Therefore you don’t live snap fit housing.
3. Networked actions and aesthetics
João Doria: I’ve been for a couple years now busy with researching and doing projects that involve layered and simultaneous actions, investigating where the structure ends and the meaning begins. My first contact with APIs was when I took the Networks and Transactions course at Yale (taught by Linked by Air’s Dan Michaelson) and the strongest lesson I learned from it was the practice of inviting an external element/factor to act on one’s project.
This way it is possible for a given website design to be affected and changed by the weather, the transit, someone’s twitter feed, airport traffic or tax data – like your Deluge project. Hence there’s a mix between the poetic and the practical/functional aspects and the possibilty of de/recontextualize plus the freedom to just go and do it.
So about all this I have a a 3-fold question:
One – could you talk about how do you see the dialogue between the practical/functional and aesthetic/poetic aspects of using APIs?
Even Westvang: I think this question goes for any kind of work with data, irrespective of source. When you find visual form for data outside the envelope of the stringently defined academic discipline of data visualization you will may find yourself in the middle of this discussion of function, form and truth. It’s a polarized discussion at times. But I think there are lots of interesting positions to occupy. Like drawing beautifully clear, explanatory charts. Or wallowing in delirious complexity.
4. Data and context
João Doria: Two – Could you talk about de/recontextualization of data in the API context?
Even Westvang: Allowing people to get at information may sometimes let them get at power. Getting data in its raw form, as machine readable files, means that it is easy to transfer into other contexts where it can contribute value. Be the crux of of an argument or give someone a better margin for their business. This is of course one of the reasons you will find resistance to allowing people to get at the data itself. I once asked for the detailed budgets for the city of Oslo only to be told by a bureaucrat that they entered the world as PDFs. I don’t think that was true.
Given the value of information exchanged over APIs parties like Facebook carefully and continuously gauge the value equations at work. The moment they feel they are getting the short end of the stick the world changes and anything you have built on their platform breaks. See “platform risk.”
There is also a point that can be made here that goes beyond the “more information is better” When you have a large information dump it can be used to prove almost any point by cherry picking from the data. A few years ago I was instrumental in releasing a dump of all the projects Innovation Norway has funded. The press had a field trip with this, but I found most of the reporting unfair to the bureaucrats. People inevitably make mistakes so if we want bureaucracies to be open we must foster a culture where it is permissible for the system to occasionally document its own failings publicly.
There is also a language of acceptable transparency we have yet to develop. The experiment the Norwegian press ran with showing everyone’s tax records to Google underlines this gap in the legal frameworks and nomenclature. At least, by my standards, information like this shouldn’t be serendipitously discoverable, yet it should be public.
5. Freedom of access
João Doria: And three — could you talk about the idea of freedom when doing so? I especially like the kindergarden example you mentioned in Webdagene and your recent struggle when proposing open models to public data and services. Whenever current interfaces for services that we really need are rough, but data is open and available, we can propose new solutions without asking for permission.
Even Westvang: There again there are different freedoms at work. One person’s freedom to access, may impinge on another person’s freedom from stigmatisation. On the other hand, when it comes to public services find myself quite on the libertarian side of things. Given that the data exists I think we should be allowed to see how our services perform. But we also need to be careful how we benchmark as constant testing communicates distrust and can undermine quality in the very services you are trying to improve. You know, New Public Management.
6. Everlasting love, conclusions
João Doria: My final question so I can leave you and the reader alone (of course it’s not an easy one and again a 3-fold): how to prepare for open architecture; how to start on a right foot from the get go and more importantly…
…how does Open Architecture and APIs deal with the passage of time, meaning, how do they age? I feel like it’s a crucial aspect when presenting and proposing Openness as a mode of thinking and working because in the end we all want everlasting love, right? Thanks Even!
Even Westvang: Hah. We do like to imagine technologies as untouched by time, but it is just as damaged by age as the rest of us. The world changes and infrastructure changes with it. Yet with careful planning and a versioning strategy you may at times have yesterday’s needs running alongside contemporary reality.
João Doria: So basically all our conversation summed up becomes about two topics: how to age gracefully and beautifully, and how to self-initiate change once data is open and accessible!