Episode One Hundred And Thirteen: The Material (1)
0.0 Station Ident
It's been a while since I've written these in the back of an Uber meandering around the Bay Area. But here I am again, and outside of the hybrid Japanese-built shell that I'm temporarily inhabiting, it's a sunny 65 degrees in this part of the cloud.
Having been on the sharp end of working to rebuild user trust in Facebook, it's been interesting to watch the reaction to the details of their emotional contagion study and the context that it finds itself embedded in. There are so many parts to Facebook the company - from the researchers and data scientists who ran the study, to the part of Facebook that - although two years ago - believed that terms of service would be adequate for covering their actions, and now, did not anticipate this degree of reaction.
I suppose this is how people are discovering the latest iteration of the universe that they inhabit. That there is a non-monetary price to services provided for free.
1.0 The Material (1)
In episode 110, I wrote about "beyond thinking computationally"[1], trying to express my unease at the "learning to code" movement, that I was worried it was espousing a sort of faux familiarity with how things work these days by assembly-line instruction, imparting knowledge of HTML and Javascript frameworks.
This, obviously, is an unfair position to take: not all "learn to code" programs are the same, and some of course will be better than others.
I'm still grappling - and, you might think, rather naively - with the thought that I might know at least a little bit more than I think I do and that I have something of a blind spot toward it.
Part of this is the idea that there's so much in the stack of the computing experience that's invisible, or opaque, to the ordinary end-user. How much understanding should there be for the goals that we're trying to achieve? And that's just for regular *visible* computing experiences, never mind more hidden ones, or the ones that are trying harder to be more "magical".
There's just so much. There's the "this is how computers work" part about computational thinking, logic and so on. And then there are the components - the atoms or molecules, I suppose, stretching the metaphor somewhat ludicrously - that make up the overall material, I suppose. I mean, there are things like "look, here's what a Turing Machine is" and "hey, did you know how computers talk across the internet" and "it turns out that latency is a thing". And that's before you even get into the silly stuff like "make me a triangular web browser".
If you take a thing like a Space Shuttle, you can, through its physical effect in the world, and the way in which it interacts with the world (slowly, on a crawler, from its processing tower, to the launch pad, and then so, so much faster) gain a certain appreciation of it, I think. Quite how you surface that in terms of the other types of things that we make, that are designed to be easy to use and to be compelling to us in their re-use, I'm not sure.
It used to be that you'd look at view-source, and you might have an idea of how something worked in a web browser. Compiled desktop applications themselves were fundamentally more opaque. In fact, I remember, many, many years ago, picking up a book about C when I was an irritating precocious child and thinking that you needed to include Studio H otherwise programs wouldn't compile - not really understanding that what I was looking at was the standard input/output headers for the language.
I suppose things like visual interrogation help. There's a wonderful tool in the beta version of Xcode that lets you interrogate how views are composited together.
But a lot of this also feels like - drum roll - systems thinking. Knowing what all the boxes do, and recombining them in different ways. Knowing *how* the boxes work and how you can tweak them.
You could think of this, a bit, in terms of something like "speaking in systems". We're good, in terms of language, in picking up lots of building blocks and effortlessly producing unique utterances and being stupendously creative (and sometimes not). There's this visual programming dream that we keep seeing in things like Scratch and the interfaces to Apple's Automator[2] and, in a grosser way, the internet's IFTTT.
But the components that we'd love to play with, the "let someone upload something" here hooked up to the "do some CV there" and then "publish the result here" boxes are boxes with awesome functionality, but simultaneously - if we're going with the physical metaphor here - they aren't necessarily *reliable* or easy to use. Perhaps one of the best examples is cryptography and security, whose terrible usability just in terms of the back-end components, is responsible for a great many vulnerabilities.
This, of course, is a conceptual mindfuck. I don't suspect that anyone's done an fMRI study on this, or even if it would yield data halfway usable, but what are the brains of people who can keep all of these non-physical structures in place, and what do they look like when they're assembling those structures?
Some of this has to do with what the goal is in all of the "learning to code". Are we talking about a degree of literacy as to how the world works? Is it because this is just the next iteration of "knowledge worker" and that, well, if you can code, then you can make something of yourself?
Okay, sure: this is more true than it has been before. The internet has, net neutrality or no, for now - certainly allowed many people the *opportunity* to make different kinds of things and to reach a large audience with them. At the same time, we shouldn't kid ourselves that increased access to a market (that didn't even exist before) doesn't mean equal or equitable access. Just that there's a new marketplace that (as we're figuring out) works like every other marketplace out there, modulo the will of Apple or Google, for example, to actually do something about it.
We have science museums, for example. I have fond memories of the one in London. You get big machines in it. I wonder what a museum of software engineering would like, if it tried to explain how these things worked to children. I used to love The Way Things Work[4] when I was growing up. What are cut-away diagrams of Facebook like? Are there books or other things that explain how not just an iPad works, but how Toca Boca games work?
It used to be that this was the sort of thing people would use virtual reality for. Flying around a networked matrix, Hugh Jackman programming and breaking firewalls on a multi-monitor setup with an OC-48 to some block rockin' beats.
So, I don't know. If I were Moma, and I had already acquired certain pieces of software, then I'd be thinking about how I'd exhibit them. And that's just in a sense of enhancing understanding of Moma's acquisitions of designed objects. That's not even something like the Exploratorium helping people understand what an Instagram is.
Whilst I acknowledge that this is the worse case of armchair punditing having not even been to Google's (now-closed) Web Lab exhibit[5] at the Science Museum, reports sound like the exhibit was primarily focused upon what the web *can* do and not necessarily how the web works.
Because, again, we're spatial(ish) creatures who are embodied in a physical world - that's why even with Google's new Material Design[6], they talk of the affordances made use of in helping us intuitively understand and interact with software.
[1] Episode 110 - Beyond Thinking Computationally
[2] Automator
[3] If This Then That:
[4] The New Way Things Work, by David Macaulay and Neil Ardley
[5] Chrome Web Lab,
--
A short one today - the day kind of ran away with me and I'm here in the Bay Area catching up with friends. More tomorrow.
Best,
Dan