Paper Bits

Designing for obviousness is hard because you have to account for existing user conventions despite their weaknesses.

Here’s the thing about the CueCat: it wasn’t that the hardware sucked, it’s that people aren’t going to scan things to go to a web page.

And yet now we have QR codes, which we’re laughing at, and which will disappear like an American Idol contestant.

QR codes, the CueCat, and other printed hyperlinks are just that. Links. They’re like the <a> tag¹. But they’re not useful enough yet in their own right to bear the weight of their use in advertisements.

Advertisements are parasites on useful and desirable tools we already understand. Like the <a> tag.

The web runs on <a> tags. We love them. They fuel everything. And oh, yeah, some of them are ads. That’s an acceptable cost to many of us, though, because the others are so damn useful.

Would the <a> tag have caught on if the only place you saw it was on an advertisement or flyer? Would you “click here for more information” if you knew it was going to be a come-on?

Pretty sure I wouldn’t. In fact, I’d probably learn to avoid anything that looked like a clickable link.

Just like I’ve learned to ignore the big square 2D barcodes cropping up in stores and ads.

QR codes are a limited but powerful tool for some innovative applications. It’s a damn shame that they’ve come to mean, “some asshole wants me to wave my phone at a big square on the subway so I can watch a commercial about how awesome he is”.

Tom Armitage:

When Igor says “Only hire people to work at the crossover of creative and technology if they have strong, practical, current coding skills.” I say: of course; why would you do otherwise? I thought that’s what that job title meant.

Tom’s (and Igor’s) primary thesis seems to be that ideas, on their own, are worthless. If you’re worth hiring, you must have the hard skills necessary to implement them. No objection here. Except (and this may be me projecting here), they assume that implementation begins and ends with software.

This grinds my gears a tiny bit: “coding” is not the only concrete skill required “to work at the crossover of creative and technology”. Especially if you want to make an actual thing that lives outside of a screen.

Unlike Tom, I can’t personally write software to scale, whether for the web or Arduino. I can do just enough to go from sketch to creaky prototype. “A smattering of Processing here and some weak PHP there,” yeah, that’s me.

On the other hand, I’m fairly certain I can take a pencil sketch of the thing that the prototype runs on, and turn it into an actual object to be printed, or machined, or molded. That object might even fit well in the hand (or on the body), and use its form to complement the behavior my shoddy, rinky-dink code programmed into it.

Like Tom, I found myself nodding my head through his and Igor’s articles. They’re both absolutely worth reading. And Wieden+Kennedy are a web development firm, so it’s understandable they’d need to make a firm stand and declare that they will only hire people with strong, relevant skills in their field.

As the so-called “internet of things” begins its slow crawl up the steep side of the hype cycle, though, it’s going to become more and more important for coders to learn a little bit about the other ways of making things.

You know: a smattering of SketchUp here, some weak foam carving there. So that they can take ideas and put them into the world, and test them, break them, and iterate, to “go from a fragile prototype and turn it into solid reality”, in Tom’s words.

I’m pretty sure that’s what being a “Creative Technologist” means.

“A Systematic Approach to Interactive Visualization”

One thing about Bret Victor: he doesn’t go in for halfway measures. You really have to get your hands on this thing and play with it.