Interaction, canvases and ecosystems

Suppose that in 5 years or so I send you a Yelp review of a restaurant, from my phone to yours. What will that mean? 

  1. First, I might well use something like Airdrop, or touch my phone to yours to pass it across, or tell Now to give it to you, or indeed Now might decide to give it to you without my even explicitly asking. Or the review might be invoked by a Bluetooth LE beacon as you hold your phone next to the menu on display by the door
  2. But for the sake of simplicity, suppose I send it to you using an internet messaging app - either one built into the OS or a third-party one - Facebook, Whatsapp or more probably one that doesn't exist yet but by then has 15 engineers and 1bn MAUs. 
  3. It seems pretty unlikely that you'll see a dumb URL string on your screen. Rather, you'll get something rich and interactive, within the message.
  4. And you'll be able to go into that experience and tap the number to call the restaurant, or make a live booking, or swipe through photos.
  5. And if you tap 'book', it'll pass them a $10 booking fee in bitcoin, authorised with a fingerprint swipe. 
  6. Now suppose you decide to save this item, as an icon on your home screen, or some other yet-to-be created place. 

Now, what were you using? An app? a widget? Native code? What programming language? Did you install an app or surf the web? I'd suggest that none of those questions would really mean anything, at least not as we think of them right now. The programming language matters much less than the user flow. And some of this example sounds 'webby', but Google is the first to advance interaction models that are not remotely webby (such as Now). 

This is a pretty simple illustration (an expansion of the super-hot card metaphor) of a broader point I've made before: on the desktop internet, the web was by far the dominant model and that didn't actually change very much for well over a decade (before that, the interfaces of Windows and Mac were also very stable for a long time). But on mobile, not only are other models just as important as the web, but they're not remotely stable, settled or mature. The platform war may be over but that doesn't mean things are settling down. 

So I have very little idea what precisely I would mean if, in 5 years, I were to say 'I installed an app on my smartphone'. Further, I'm pretty sure that if it's an Apple smartphone it will run an iteration of iOS but I'm rather less sure what Google will have done with Android and Chrome by then. And of course I might be running a fork of Android from Amazon or, perhaps, Microsoft. 

This is the key reason why the new social messaging apps are so interesting - not because they have users and inventory now, but because they can be vectors for some of this sort of behaviour - a third acquisition, discovery and distribution channel besides Facebook and Google.

This may also have implications for any discussion about what it means for Apple that its ecosystem will have a minority of mobile users. We need to think about what it means to call a ecosystem that might have 800m-900m live devices 'minority', but we also need to think about what 'ecosystem' might mean. What, if any, 'winner takes all' dynamics operate in this environment? One reason the Mac didn't die was because the web changed what it mean to be a computer ecosystem: the mobile ecosystem has lots of changes to come too. 


The two strongest trends in Internet content are atomisation/unbundling on one hand and sealed silos within smartphone and tablets apps on the other. This is contradictory. 

As we all know, many sites see the majority of their traffic going to individual pages rather than the home page, Tumblr and Pinterest disaggregate, reaggregate and remix individual pieces to content far away from where they started, and of course social sharing on Facebook or Twitter remixes and redistributes everything. Twitter cards and the trend for social messaging services to embed content within messages take this another step. In a sense, there is no home page for any site. 

Every piece of content becomes a packet that can be routed anywhere across any service layer - but the service layer is Twitter, Kik, Line or AirDrop, not TCP/IP or HTTP. 

But at the same time, after the end of the HTML5 head fake (as Bill Gurley put it), it seems clear that apps will also be a major component of content consumption. To hope that this will not be the case is to wish to turn the clock back to 2007, and of course to ignore a pretty clear demonstration of what customers want. The last 6 years were not a temporary aberration. 

So apps are a new, permanent part of the content landscape, just like social or search before, and apps are silos. Yes, you can deep link, up to a point (including with things like AirDrop), and share back to the unsiloed web version of many content properties from within an app, but the app experience itself is essentially exclusive. You go in, you engage, and then, often after much longer than you'd spend on a website, you leave and do something else. This is quite different from the promiscuous flitting from site to site and tab to tab that's the general model for the web. And, of course, it's the complete opposite of the atomisation that's happening in parallel. 

This is a real challenge for content owners. How do you think about editorial on the premise that it will both be shared everywhere and read in the course of a half hour session with your brand's app? Do you have to pick one model or the other? If you're in the long-form business already (the New Yorker, say) this is an easy conversation, but if you run a typical magazine with a mix of content of all different types and lengths, what does your 'digital' proposition look like? How many different types of engagement do you need to think about? What's your social messaging app sharing strategy? And, of course, how do you address this across 30 titles in three cities, most of which are only run by half-a-dozen to a dozen people who're only just keeping up with updating a Facebook page? 


App stores, portals and discovery

We used to browse Yahoo to discover cool websites. 15 years later we browsed apps stores in the same way. Neither scaled very well. 

For those too young to remember, Yahoo started as a hierarchical tree that, theoretically, contained every single website that existed. The screenshot below (from the Web Archive) shows it circa 1996. If you clicked on those links you could see a listing for every site on the web (or at least that was the idea). Does this look familiar


Screen Shot 2013-08-15 at 11.10.36.png

Of course, this didn't scale once the web started taking off. You can't browse through a catalogue with millions of entries. Equally, with over 900k apps on the iOS app store and almost as many on Google Play, browsing there has also become meaningless. Browsing an app store is like browsing Amazon - you could spend the rest of the year clicking 'next item' and not see that one cool thing you really want but didn't know existed. 

After the web directory the next stage was the 'portal' - a page with someone's ideas of what might be useful. This is what Yahoo became, and it's also what the front page of the iOS or Android app stores look like now. The purpose of these screens is not to allow people to discover your  app or service - they cannot hope to be comprehensive in that way. The front pages of an app store do not exist to help developers - they can't. Rather, they exist to help the users - to ease them into the idea of apps. But they can only scratch the surface of 'discovery'. 

All of this means that saying "we made an app and no-one downloaded it, and Apple didn't help" is like saying "we made a website and no-one came, and Google didn't help" or, even more, "I wrote a book and no-one bought it, and Amazon didn't help". Amazon might help - it might feature you, just as Apple might. But that's for the users' benefit, not yours, and it cannot possibly scale to all apps or all books. 

The difference between Yahoo and app stores, of course, is that web search came along and addressed some of the underlying tasks in a quite different way, but search does not necessarily work well for apps. Search requires you to know roughly what you're looking for, but a lot of the best apps (and indeed web sites) are things you hadn't imagined could be possible - they're 'magic wands'. If you didn't know Hailo or Evernote were possible you wouldn't search for them - and yet the app store home page cannot possibly showcase all such things. 

The obvious answer, of course, is self-promotion - you promote your app like you would your website or your book.

Screen Shot 2013-08-15 at 11.54.14.png

But there are some other more interesting things also going on in discovery.  

The first trend is the way that Siri and Google Now surface information. If you ask Siri for sports scores or restaurants or films, you don't need to work out what the best service or app to use might be - you just ask the question (and Apple's BD team has picked one). Google Now takes this a step further - it it also knows the sports score, but it tries to work out new things you might be interested in unprompted - it reads your email, knows you're interested in a flight and pops up to tell you it's running late. As they develop, these concepts may work well for the discovery of some kinds of apps, but neither approach scales well across thousands of apps. And neither would tell you about a 'magic wand'.

The other trend, though, is social. I don't really mean social recommendation aggregators, which work on the basis "people who liked this also liked'. Rather, plain vanilla sharing. Twitter cards let you share an app directly, but also deep link to content within one. 


Many of the emerging mobile social messaging apps are trying to turn themselves into platforms, and they have hundreds of millions of users. A little piece of atomised content, a card, the size of a smartphone screen, embedded into a message, is a great way for knowledge of a service to spread (I wrote a little more about this angle here). Meanwhile,  the grandpa of social networks, Facebook, is pushing hard to build a mobile app distribution business. Kik, of course, has just launched a Zynga game built in HTML5 within the messaging app itself. 

Even more interesting, though, are some of the APIs inside iOS7. Apple has built a local, zero-configuration wireless sharing tool kit. No access point and no NFC needed - any app can reach out and find any other iOS device.

Screen Shot 2013-08-15 at 11.45.52.png

Apple surfaces this in the new system service Airdrop, shown above. The demo uses photos, but Airdrop is part of the standard sharing panel that any app can use, and (without breaking the NDA) it looks like anything you can make into a file could be sent. So an app can include a 'share this with friends' that sends people in the room an app store link. Or a game level. Or in-game currency. Or a deep-link to content within an app. That makes app discovery work quite differently. 

Airdrop, though, only works with people in the same room, and so has a different set of scaling problems.  The leading social messaging apps all have hundreds of millions of users, and I've lost count of how many such services there are in total - I found over 50 on Google Play that had over 1m reported downloads, and there are dozens more. Pretty soon there'll be more messaging apps than ad-tech companies - a new bubble is inflating. But  there might be a fair bit of value for those that can turn themselves into distribution and discovery channels. 

Twitter, canvases and cards

Twitter used to be a protocol - rather like SMTP or IMAP. Other people made Twitter clients, with many different interfaces, and Twitter poked around with metadata (adding retweets, for example), but the user experience was something other people built.

Then Twitter pivoted, and deprecated the third party apps, and took control of the interface. The obvious thing that it did with that was to deliver a predictable offer for advertisers. But the more interesting thing to me was that it created a canvas - which is now turning Twitter from a protocol to a platform. 

Twitter is turning 'Twitter cards' into a platform. You can embed video, or slides, or music - all sorts of things. You can embed a call to action that will harvest the account's email address. And, increasingly, you can drive acquisition - of Spotify users, or apps, or customers. And thanks to retweets these cards can end up anywhere on Twitter, far beyond the original poster's network. 


Twitter isn't the only company doing this sort of thing. Many of the new crop of social messaging apps, such as Line, Kakao, WeChat and Kik, are also creating canvases of various kinds within their services - within individual messages. Kik and WeChat are exploring HTML5 games within the app itself, and WeChat is playing with retail coupons. Some of the results are pretty strained, but there's obvious value in being able to send tracks, game levels or yelp reviews through such apps, and sending them as rich, actionable cards is much better than a URL string.

(Interestingly, though, probably the biggest social messaging app outside China, Whatsapp, is pretty much the only such app that isn't  trying to become a platform in this way, at least not yet.)

Cards are an interaction model that are spreading pretty widely, in fact. They're an important part of how Google presents the newish 'entity' based search, which crop up in the right sidebar on the web and of course as part of Google Now. Part of the magic is the semantic understanding of data that lets Google make these automatically, but the presentation is, again, a card. 


And then there's Airdrop, an intriguing feature in the new iOS7 that's been rather buried by all the fuss about the new visual design. Instant, zero-configuration local sharing (remember Bluetooth?). Apple's screenshots focus on photos, but to developers this is just part of the standard sharing API, and you can put anything in here - coupons, game levels, deep links to reviews or songs. But instead of sending it by SMS or email, you can pass it across a bar top. No canvas, this time (except for pictures themselves), but again the atomised content. 


What all of these have in common is that they're pulling information out of the app or the service and making it relevant to the moment. They're taking things out of silos, packetising them and making them sharable. But at the same time, they're making them canvases - not just files, but cards, content, real things that you can pass around. 

In some senses, this started with Facebook, which had a canvas a long time ago (in internet time, at least). Facebook is present on mobile and doing well, claiming close to 800m mobile users, though it isn't close to winning in the sense that it won on the desktop, not with hundreds of millions of Facebook users choosing also to use WhatsApp et al.

But Facebook is about aggregation - about sucking everything into the gravitational well and spitting it back out through a black box filter to stop you being swamped. Facebook is an endless stream whereas cards are individual. The point of 'cards', like the story of mobile social, is disaggregation - of the over 200m people who already had Facebook but are using WhatsApp for messages - the 100m Instagram users who prefer it to Facebook for photos, and so on, and so on.  

From a business point of view, this is interesting because it points to distribution and discovery. How do new products and services get passed around? How does social sharing evolve? Complexity is increased, too - how do you do SEO for Google Now? How should you think about conversion rates on a Kik card or a game shared over Airdrop? There's a sort of inexorability to this: Zawinski's Law states that "Every program attempts to expand until it can read mail." One might now say that every product and service online expands until it can distribute freemium games. 

I think there's also a question of being native to the platform, though. Chris Dixon wrote recently about finding things that are native to mobile as opposed to mobile versions of desktop products. What could be more native to a smartphone than a piece of content the size and shape of a smartphone screen, that can be sent anywhere?