The way we generally understand innovation is that technology gets smaller, faster, smarter, cheaper, as described by Moore’s Law. This is helpful, but also isolating. A perhaps more nuanced story is told by Metcalfe’s Law, that networks get more useful when there are more nodes connected to them. This explains everything from long distance phone networks to Facebook, but it’s also a useful framework for thinking about the next wave of holistic technological change1.

Why did the Newton, Palm Pilot, and Windows Tablet PCs become terminal branches in the evolutionary tree but iOS and Android lead to a Cambrian explosion? The simplistic, and not entirely wrong, answer is the one that fits with Moore’s Law: the component parts all got small and fast and cheap enough. A more nuanced answer is that WiFi wasn’t ubiquitous, cloud storage didn’t really exist yet, and apps weren’t even apps but software that came in boxes sold on shelves. The iPhone and iPad of course have vastly superior hardware but they also connect to an entire ecosystem that could scarcely be imagined when the Newton was unceremoniously killed.

As we transition beyond mobile, the Moore’s Law approach will obviously continue to be important in order to make these new, more intimate machines small and increasingly invisible. But the network of devices will be just as, and eventually, more important. Right now, we bifurcate these as “wearables” and “the internet of things”, but maybe it’s better to think of them as co-dependent “constellation computers”.

Much of the thinking about these early next generation devices, including my initial criticism of the Apple Watch, has been preoccupied with the hardware and features. Apple’s focus, too, is mostly about the artifact for obvious reasons: the rest of the pieces aren’t ready yet. The Watch has to be able to stand on its own to reach a critical mass, at which point it will become its own star in the constellation, alongside the iPhone, the Apple TV, and also lightbulbs, thermostats, door locks, cars, refrigerators (and the food in them!), medical devices, etc.

These connected objects are easy to mock, and are going to be slow and stumbling to roll out, but are critical asterisms to the constellation. I don’t want a watch to replace my phone, I want it to replace my wallet and my keys. That means a lot of chips and radios and software embedded in the real world.

If you were to imagine the tools for powering and connecting these points, they might look like Google’s just announced Brillo and Weave, an operating system and protocol for building constellation computers. It’s a typically Google approach, a big, open source idea without a product yet, but perhaps better suited to the challenge than top-down mandates like HomeKit. Of course, Apple’s more product-focused plans – start with the wrist, then expand to the place where people have the most control over their environment, then out to the world – makes some sense, too. Perhaps the competing designs for constellation computers will interoperate, like the web today, or maybe they’ll serve to lock us further to our chosen platforms.

A computer in isolation is useful. A computer that connects to every other computer an order of magnitude more. A pocket-sized computer that instantly connects to all the world’s information and services has been transformative. A constellation computer is as close as we’ve gotten yet to the promise of machines that enhance and empower our lives.

I’m being a bit fast and loose here with Moore’s and Metcalfe’s Laws, which refer to fairly specific, observable phenomena. Moore’s Law is about the number of transistors that can fit on a chip doubling every 18 months, but it’s a useful shorthand for thinking about the pace of hardware innovation: hard drive capacities get bigger, memory gets denser, screens get sharper, radios get more powerful, it all gets cheaper. Metcalfe’s Law was an observation about nodes on a network but is similarly useful for thinking about the transformative effect of many pieces fitting together. ↩︎

The Committee to Project Journalist notes it is now possible to attach a PGP key to one’s Facebook profile. This is another in a series of steps Facebook has taken recently to secure its networks, from HTTPS at every endpoint to enabling connections via Tor. The PGP feature lets anyone add their public key and includes an option to have any notice Facebook sends be encrypted via that key.

Given the sheer size of Facebook’s network, this is an impressive step forward for security and privacy, although the challenges of setting up a keypair and understanding the basic mechanics of public key cryptography are still largely left to the user. Projects like Keybase are trying to solve many of the UX problems inherent to widespread public key adoption, but still seem largely limited to geekier types on Twitter and Github.

Given how much Facebook is a stand-in for people’s identity online, having a place to advertise a public key is a step in the right direction. And since news about Facebook and privacy is often a cause for concern, it’s perhaps ironic that Facebook could help push more widespread adoption of public key cryptography1.

There is a fair piece of criticism to be made here, that Facebook is working diligently to improve security to and within its own network, but its business of harvesting massive amounts of user data to sell to brands and advertisers remains unchanged. These are both true and probably incompatible to privacy absolutists but not necessarily wholly dissonant. ↩︎

Talk of the tools of the modern media company invariably leads to technology stacks. These will include reverent nods to Vox Media’s Chorus, Quartz hacking Wordpress beyond the reach of mere mortals1, or BuzzFeed’s voodoo for conjuring virality out of the ether. These are great and truly valuable for advancing the conversation about how we publish.

Recently, the newsdev team at The New York Times has been putting together a collection of small tools that are as interesting and possibly as important as the monolithic systems that get so much attention. The latest, Driveshaft, is a simple Ruby-based app that converts a Google doc into JSON, and deploys it to S3. This sounds simplistic (or maybe esoteric) but it’s profound in what it enables: editors can quickly and easily update information in a place and format they are familiar with and confidently publish to the web. Custom apps can be built around these tools, new visualizations can be published quickly, and breaking news infographics can be updated in real-time. These continue to be difficult challenges, especially as the publishing ecosystem expands beyond the web and mobile apps, and small, simple tools help make it possible.

Driveshaft, and siblings like ArchieML and ai2html, are philosophically aligned with an old-school philosophy of software design, that applications should be small, focused, and good at their jobs. A fitting mantra for today’s publishers as well.

This Quora question appears to be genuine. ↩︎

Frédéric Filloux, who writes an excellent, long-running column at Monday Note, was also thinking about Ad-blockers recently and has a much more dire set of predictions. Filloux has seen an as-yet-unpublished report that says ad-block usage is as high as 30-40% in France and Germany, and sites with very tech-savvy readers, like game sites, seeing as much as 80-90% of their traffic using ad-blockers.

Filloux also points out that plugins like AdBlock Plus are stripping out the “sponsored content” headers on native ads, which makes my proposed solution a bit murkier.

I continue to be optimistic about the end of banner-style and pageview driven ad models and that finding better ways to make money online will ultimately be better for publishers in the long run. Assuming there are any publishers left by then.

In 2005, I was mostly building big, fairly overwrought multimedia packages for a big, fairly overwrought media conglomerate. I thought it was pretty futuristic, but try finding, let alone watching, any of the Flash I labored over.

My memory of reading David Foster Wallace’s ‘Host’ in The Atlantic was that it was a revelation. I must have read it in print first, as I distinctly remember the ingenious design of DFW’s extensive footnotes, with the highlighted text and sidebars. It read like hypertext on a printed page.

Memory is a tricky thing, I feel like I remember the original treatment online being pretty clever and similar in style to print, but the only record I can find is one with links and pop-ups and without the stylistic panache. This may well have been what ran ten years ago and I’m conflating the two in my mind.

Regardless, The Atlantic has rebuilt the nearly 15,000 word piece to fit not just their latest responsive layout but also reworked the footnotes so they work inline and hew more closely to the original design. It’s incredible work and if you’ve never read ‘Host’ now is a great time to dig in. If you have, a long weekend seems like a fine time to read it again.

Two stories about ad blocking almost make a trend. European telecoms want to build ad-blocking into their networks via proxies1 that would halt most banner-type ads by default. And Adblock Plus has built a standalone Firefox-based browser for Android that would perform roughly the same function as its eponymous and quite popular browser plugin. These are both small but meaningful steps to move ad-blocking from desktop to mobile.

The black-and-white rationale against ad blocking is simple enough: ads are how publishers pay the bills, blocking them is effectively stealing. This, of course, is roughly equivalent to the piracy argument the music and movie industries have made, without much traction, for a decade and a half.

The pro-ad-blockers have their own moral, and compelling, argument that online advertising degrades the user experience, destroys privacy, and is generally reader-hostile2.

As in all things, there is no absolute truth but a muddled middle. It’s unclear how big a problem ad-blockers actually are – 5% of global internet users doesn’t sound very high, but the kind of reader who installs an ad-blocker is likely exactly the kind of reader an advertiser wants to reach. And if mobile users get automatically opted-in at the network level, it certainly becomes a much bigger deal3.

The problem may be murky, but the solution is a bit more clear, if not exactly novel: build a better product. Not a fancier iPad app, a better ad product. For all the haranguing about native ads, they have the advantage of being immune to filters and, when done right, a genuinely better experience, certainly better than green double-underlines or the “content marketing platform” ads at the bottom of far too many web pages.

I suspect we’ll look back on non-native ads as an aberration, one that only made sense during the brief period when all publishers were local monopolies, hardly an ideal situation either. Now it’s time to make an ad your readers won’t want to block.

Nerds of a certain vintage will recall a time when a proxy, or mucking around with one’s hosts file, was one of the only ways to transform web pages. Then extensions like Greasemonkey were meant to usher in an enlightened time of client-side data mashups that never quite materialized but did lead to Adblock Plus. ↩︎

Those arguing on the side of ad-blockers will need to contend with the fact that Adblock Plus is a for-profit corporation that has cut deals to whitelist ads from networks willing to pay. ↩︎

Telecoms refuse to think of themselves as just dumb pipes (an inverted version of telecoms blocking ads is Verizon buying AOL) so they seeking to add value for their existing and potential customers (or, more likely, extract a payoff from ad networks). Regardless of what you think about the morality of ad-blocking, it’s hard to see how filtering packets for content is a good thing, even for ostensibly benign reasons. ↩︎

Instead of merely waiting for Facebook to deliver Instant Articles to everyone, it’s worth looking for some insights from last week’s launch.

Foremost, it’s always nice to be reminded that performance matters. Page load time has, of course, always mattered, but as mobile accounts for more traffic and attention keeps getting sliced thinner, we should expect it to become a key metric, not a nice to have. When managers and executives start to ask why their site’s pages are so slow, the blame is going to quickly circle back around to deals cut with third-party widget providers, share buttons, and other cruft that tries to monetize pageviews. This is going to lead to some awkward conversations and hard choices.

It’s not just pages that need to be nimble but the systems that build those pages will need to be increasingly agile. Facebook didn’t choose their launch partners merely for the content, great though it may be, but because they have some of the best devs in the media business. If your CMS can’t quickly and easily rebuild and repurpose stories in a variety of formats and contexts, it’s not just Instant Articles you’ll miss out on. The good news is, this is precisely the kind of thing computers are great at doing; the bad news, sadly, is off-the-shelf enterprise publishing systems aren’t. Invest in your developers.

Instant Articles raises important questions about websites, to be sure, but it also begs the question of what to do about apps. Your app is competing not just with other magazines and newspapers but Facebook and Instagram and Twitter, who just so happen to employ thousands of the best app designers and developers in the world. It certainly takes a small bit of hubris to believe your readers are going to open your app if it offers little more than what they could get from your website.

Facebook has telegraphed a strategy that Apple and Google could also use to bring more publishers to their mobile platforms. They each have their own Newsfeed-like ecosystems in the form of Newsstand (Apple) and Play Newsstand (Google) that are built into their respective mobile operating systems. Google even has Play Newsstand Producer1 to let publishers build fairly rich, branded editions of their stories. Facebook, of course, has a billion-and-a-half users, whereas Newsstand gets shunted off to a hidden folder along with the Stocks app. The point is, alternatives to Facebook’s Newsfeed can exist and it’s worth figuring out if they’re viable.

The big takeaway from Instant Articles is that we learned the wrong lesson from the rise of mobile and the app ecosystem. We’ve spent far too long trying to compete with native experiences by making our websites look and behave like apps. This includes not just thousands of lines of javascript to mimic native app swipes and scrolling but even the lower overhead aesthetics of fixed position headers and persistent navigation. Consider that a reader is just as, if not more, likely to get to your page via an app like Twitter or Facebook, with its own chrome, than the built in browser. Those positioned elements are only taking up valuable screen space and replicating functionality the reader already has built-in. Simplify your pages, reduce overhead (both cognitive and bandwidth), prepare them to live outside of browser.

Instant Articles are impressive2 and Facebook has made a seductive offer, perhaps one only they can make: we will give you the world’s biggest audience, native performance, storytelling tools built by the best mobile engineers, built-in monetization, all we ask is you give us your content. Maybe going back to basics is a better alternative.

I suspect Apple is on the verge of releasing something similar with their purchase of PRSS, assuming they don’t kill off Newsstand entirely. Perhaps we’ll see at WWDC. ↩︎

It’s been a week since Instant Articles launched and there haven’t been any new articles published, which could mean anything. It certainly suggests Instant Articles aren’t exactly plug-and-play just yet. Obviously, Facebook wants as many stories as possible to be Instant Article-ized, eventually. If publishers treat them as another Snowfall, something to save just for special stories, it’s going to temper their success. ↩︎