Flicker Fusion

Slack just capped a pretty flawless year by announcing a new platform, an iteration on existing APIs for building bots and integrations. Now, there's a curated app directory, improved and simplified documentation, a new open source framework, and an $80 million fund aimed at developers to build even more apps. All this in a brisk and breezy half hour that was exactly what you'd expect from this smart and quirky enterprise software company1.

This is a great, necessary step because, despite the thousands of existing integrations (the vast majority of them custom to a single organization) and millions of installations, building Slack apps was more difficult than it should be. Finding these integrations was often just as challenging, and a searchable, curated place that vets new apps will be a huge win for everyone who loves Slack.

It's an impressive start, especially considering they only hired a director of platform five months ago. It also suggests something deeper about what Slack actually is -- the real product isn't just an evolved enterprise messaging app but the platform itself. To put it another way, the Slack we know today -- the IRC client you want to live in with bots that help you get your work done -- is just one of the apps that could be built on the Slack of the near future. It's clear that messaging and collaboration will always be core to what Slack is -- their previous acquisitions demonstrate as much -- but you can easily imagine the platform continuing to expand to allow apps that don't just tie into the messaging interface. Once Slack adds a proper store that gives developers build apps and add-ons they can charge for and access to hundreds of thousands of paying customers, the platform will truly take over as the product.

To talk of platforms and app stores brings to mind Apple's App Store but I'm not sure that's the right approach. As great as the App Store is for Apple, it's proved to be much more difficult to build a real business on. Microsoft, on the other hand, dominated the computer industry for two decades on the strength of the relatively open Windows APIs (and, to be sure, a take-no-prisoners ruthlessness). Slack, of course, doesn't have the advantage of Microsoft's operating system monopoly but they still have an incredible opportunity to build the foundational layer of a new enterprise computing stack that looks like the future -- mobile, cloud-connected, with a smart, conversational UI.

When April Underwood, Slack's Director of Platform, introduced all of this she made an allusion to the command line and even talked wistfully about using Pine for email. This is certainly a kind of Proustian proto-nerd nod to the developers that will be essential to making the platform work but demonstrated Slack's ambition as well. The command line is incredibly powerful, even in the era of multitouch voice activated virtual reality, and continues to be foundational to all software. If Slack can pull off redefining the command line in for the enterprise, they will have built a pretty incredible business.

Paul Ford's incredible What is Code is one of those magazine pieces we're going to remember as a master of the form. Yes, it's a business magazine talking about how computers work, but like Gay Talese profiling Frank Sinatra, Hunter S. Thompson crashing the Kentucky Derby, or David Foster Wallace getting inside the mind of a right-wing radio host, it's a story of how we live now1.

Like those other seminal pieces, it's not just the story, but how it's told. 'What is Code' weaves a fictional narrative with technical exposition that could be dry even in capable hands, yet Ford makes it understandable, relatable, and even funny. To be able to effortlessly drop in William Blake allusions, 50-year-old computer history, and internet memes requires a deft hand and uncommon mind.

If 'What is Code' were merely dropped into Bloomberg's standard web template, it would be a gift, but a team of bright and hilarious coders and designers built a custom site that is the perfect complement. Ford is showing and telling a story, the page itself is reinforcing it2.

By now, this -- article? mini-book? tome? -- has its own gravitational pull. There's a Github repository, that, as of a few hours ago, is still being updated. That repo has a pull request arguing over the semantics of Javascript's package manager (of course it does) as well as a very thoughtful request to update the attribution of a quote. There's a Bloomberg podcast episode, an On the Media interview, and interviews with Vice’s Motherboard, Gawker, and Huffpo. At some point, 'What is Code' might achieve sentience itself -- exactly the kind of ill-informed joke you might have made before reading 'What is Code'.

It's in a business magazine but this is absolutely required reading for journalists of all beats. Tech reporters, sure, but anyone who needs to report on anything that code touches, which is everyone. Reporting on labor issues? Read it to better understand Uber. Political reporter? Read it to understand net neutrality, cyber warfare, and modern campaigns. Entertainment? Celebrities are venture capitalists now!

What's most impressive about 'What is Code', and this has been true of Ford's writing for two decades, is his humanity. Lots of people could explain programming in a way that makes them look smart, it's a rare talent that does it in a way that makes the reader smarter at the end. For all the talk out of Silicon Valley about code eating the world, it took a writer/programmer in Brooklyn, writing in a weekly east coast business magazine, to make code something to get excited about, not be afraid of. For that, we owe Paul Ford a bit of gratitude.

Ford has his own, unmistakable voice, one he's honed for years, yet I couldn't help but hear echoes of David Foster Wallace. I mean this only as a compliment, the entire 38,000 word article could be a chapter (or, just as likely, a footnote) in a sprawling Wallace megaworld. ↩︎

An important thing to understand about Apple is it is a company that builds products for people to buy. This sounds like a very simple and obvious thing but in tech it's actually quite rare -- most tech companies build platforms, networks, services, or ecosystems. Apple, of course, has their own platforms, networks, services, and ecosystems but they all serve a product, preferably a beautiful device, or an app that runs exclusively on that device.

Apple News is a product that captures the interests of a person who has bought an Apple device. The very first thing it does is ask you what you like, in the form of newspapers, magazines, and blogs you already read, or topics you pick. It uses machine learning to refine its understanding of what you like and will, eventually, suggest new things for you to like1.

Just as important, the articles, stories, and posts in News look beautiful and designed, not merely dumped into a feed with an auto-layout engine. This will help ensure content that is not just relevant but high quality. If Apple can also deliver on the promise of letting publishers make money from News (a big 'if' considering not one single ad was demonstrated), they will have truly built an amazing news product that had mostly been written off.

Given Apple's very public stance on privacy in opposition to Google and Facebook (cf. Dustin Curtis's Privacy vs. User Experience), it raises the question about how good the machine learning (and ad targeting especially) can be in News. Apple believes they can do in-device what everyone else does in data centers, which seems like a reasonable enough approach until proven otherwise.

If News is successful, it means more than another good default app on Apple's devices, it means tremendously useful data -- a personalized Interest Graph2 -- for other services, like Siri, possibly even available to developers. Then it becomes more than a product but a foundation.

Watching the demo reminded me of the very smart, though apparently not widely used, Prismatic. The people who built Prismatic are brilliant at constructing machine learning algorithms but don't seem to have been able to turn that into a product. It's perhaps worth noting that one of Prismatic's co-founders worked at Apple until very recently. Prismatic also offers an Interest Graph API that I would not be surprised to learn Apple licenses. ↩︎

Not to dwell, but it may be helpful to recall why the promise1 of native apps for publishers has been unfulfilled.

Expectations were set very high -- recall unironic heralds that the iPad would save newspapers. Also, The Daily once existed2.

Apps are expensive to develop from scratch and maintain.

Tools that try to leverage existing print and web workflows result in sub-par user experience (huge downloads, difficult navigation, static PDF-like rendering).

Publisher apps don't require a lot of hardware-specific features and offer few advantages over a well built responsive website. In-app purchasing and notifications are probably the two most cited.

Paying 30% to app stores is an enormous upfront cost.

Media apps aren't competing with other media apps they are competing with Facebook, Instagram, and Snapchat (this is true on the web of course, but homescreen real estate make it more true).

These are worth keeping in mind with the rumor that Apple is considering rethinking its 30% take from media companies, possibly in conjunction with changes to Newsstand. As Apple's annual World Wide Developer's Conference is upon us, let's speculate what this could possibly look like.

Apple introduces Newsstand Publisher, an update to PRSS, which they acquired last fall. This is a tool that lets anyone publish to Newsstand without having to write an app. At its simplest, this would involve providing an RSS feed (probably with some new tags, a la podcasts) and some custom configuration (colors, typography, image placement). More complex features will allow for authentication with an existing user database, a paywall counter, fully customizable templates, rich media tools, and immersive native ads.

Apple will let publishers set subscription prices, starting at free, and will take a much smaller percentage of sales, starting at 5%. More complex features like paywalls will mean a higher payout to Apple.

This will position the Newsstand app for iOS users more as a general purpose news reader, which means it will compete head on with apps like Flipboard and Feedly but also Facebook and Twitter. It also gives users a reason to move Newsstand out of the junk folder on their last screen, alongside the Stocks app.

This neatly solves all of the aforementioned problems of native apps for publishers, save those pesky high expectations.

"Complete failure" would be a more accurate description, however, the Flicker Fusion style guide calls for avoiding snark and negativity wherever possible. ↩︎

Chris Sacca's ever hopeful What Twitter Could Be is quite a read. Too long and often meandering, it nevertheless shows how deeply he thinks about every aspect of Twitter as a product and a business. I like to imagine a hush fell over Twitter HQ as the entire staff took the time to read then re-read the entire thing.

Sacca lays out a way to capture a bigger audience and reinvigorate what, from the outside at least, looks like a muddled company. He shifts from grand strategic thinking ("live is the biggest opportunity yet") to very specific feature recommendations1. There are several great product ideas buried in the post worth pursuing -- by Twitter, some plucky upstart, or even more established companies.

Sacca insists Twitter's problems are the result of not telling its story, either to investors, potential new users, or users who have abandoned the platform. That strikes me as charitable, not just because telling the right story is a fundamental purpose of any business, but because it seems like Twitter itself doesn't know what story to tell.

More than monthly active users or revenue growth, this lack of direction is the most troubling. Twitter has a mission statement -- "to give everyone the power to create and share ideas and information instantly, without barriers" -- that expresses a purpose, but they seem to lack foundational values2. This has led to a near-perennial change in direction that for now seems to be focused on live events and broadcast, especially with the Periscope3 acquisition.

It wasn't an investor or analyst who identified Twitter's primary tension but, fittingly, writer and artist Teju Cole when he noted it's a genuinely novel form of communication but also a corporation. Others have made similar points, that Twitter wasn't so much invented as discovered, and everything fundamental to how Twitter works was built by the people who use it, not the company itself.

This tension has made capturing the value of Twitter from the top down elusive, however, there's something perhaps just as valuable: the individual corpus of every user's interests and passions. Twitter has one of the biggest data stores in the world, maybe the value is in all of the little data. Mining the big data of all of Twitter is interesting for knowing what's happening all over the world, but giving everyone who uses Twitter insight into everything they care about is equally valuable and, potentially, much more lucrative. To make this work would require unwinding years of strategy, starting with reversing the infamous v1.1 of the API. It would mean not merely competing for users to show ads to, a la Facebook, and not insisting on a top-down, completely controlled approach to product development like Apple. It would mean more third-party apps and letting Meerkat exist alongside Periscope.

Everyone who wanted a microblog or novel communication app signed up for Twitter long ago. The question Twitter can answer for everyone else is how do they connect to everything they care about.

An unapologetic hustler, many of these naturally end in Twitter acquiring one of Sacca's portfolio companies. ↩︎

This may be because none of Twitter's founding members are currently at the company, though there's no indication any of the founders would be any better than the current leadership. ↩︎

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.

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.

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.

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.

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.

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. ↩︎

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. ↩︎