Website traffic patterns in the presence of native apps

A serious question for anyone running a website that has a matching native app to go with it: looking at the platform on which the app is available, is the share of website traffic from this platform going up or down (or staying static)?

My suspicion is that the share of mobile web traffic for most platforms is still going up, even in cases where a native app alternative is available.

Please comment, or contact me if you have any data to share!

A rich client tipping point

Francis Hwang talks about reaching a tipping point in web application development:

If you are writing a new web application, you should make it a rich-client application from the start. Your servers should not generate any HTML. You should do all that work in the browser with a Javascript framework such as Backbone.js or Ember.js, and the server should only talk to the browser via a REST API.

I’m very close to agreeing with this, but I have my own set of caveats.

First of all: mobile. If you’re using an iPhone 4(S), you might not realize that a lot of web browsers on mobile devices are abominably slow. In terms of getting the first page of your app/site up and running on a mobile browser, an HTML page rendered on the server is going to beat a client-side JS application hands down in at least 90% of cases.

After that first page has rendered, the comparison is different. A server-rendered site/app with full-page reloads is (probably) going to have to do more round-tripping, re-parsing and rendering, whereas a client-side app that has bootstrapped itself might only need to load up small chunks of data and refresh parts of the page. But remember that mobile devices are often tight on working memory, and even switching between tabs (let alone switching between apps) can be enough to kick your app out of memory, so that it has to bootstrap again when you switch back.

With IE6 and 7 effectively dead, the desktop doesn’t really have this problem any more. Desktop browsers are now sufficiently fast and capable that the bootstrapping cost is tiny, and from an architectural point of view separating the front-end from the back-end API is the service-oriented way of doing things, which is to say the right way.

(Then we still have to make our client-side apps internally resilient and service-oriented, so that one poorly performing component on the page doesn’t crash the whole app. But. Baby steps.)

It irks me that mobile web development, which in many ways was running ahead of classic desktop web development (advanced CSS3 capabilities, lack of IE6, et al.) is now going to fall behind in this architectural shift. Instead of incapable legacy browsers (IE6,7), we’re stuck with at least a couple of generations of poorly performing devices. The platform that is most suited to “app-like” web content is the one least capable of running the damn things.

Having said that, it’s important to know your audience. In Western Europe, at least, turnover of mobile devices is high, and the shift away from Blackberries and Nokias towards iPhones and Androids is massive. As usual, “it depends.”

Secondly, there’s the small matter of linkability and history management. If there is any part of your application that you want people to jump to directly, either as a bookmark for their own benefit, or as a link to hand out to others, it has to be have a URL. Using hash fragments for navigation may be a well-established pattern, but it’s still a hack. So long as you’re using hash fragments, that URL can only be run on the client. pushState() and replaceState() can fix this, but we’re still a little while away from these methods being universally available (IE10).

  • And then, if I’ve been clicking around in the application, what happens when I press the back button? Does it take me to a previous state within the application, or does it take me out of the application altogether? I don’t think that the field of front-end development has answered this question with a consistent set of patterns to meet (and reset) user expectations yet. Far too often I still hear, “er…don’t use the back button because that’ll break everything”.

    The back button doesn’t reign as supreme as it used to, though; multi-tab browsers have seen to that. Running an app in a dedicated browser tab, and closing it when you’re finished is a common option now. Adding a web app to your phone’s home screen so that it can run without browser chrome is less common, but on the rise. Still, the back button is likely to still be in play in the vast majority of cases. If you’re going to build an app, make sure that you have a plan to deal with it.

    Of course, none of this applies to document-oriented web content. But the distinction between apps and documents is an entirely different discussion.

  • Apple TV, Airplay, and the future of video

    I didn’t get the Apple TV for a long time; neither in the sense of “buy” nor “understand”. Certainly here in the Netherlands, where Apple didn’t start selling video content through the iTunes Store until last year, it seemed entirely pointless. Even now in 2012 the selection of films on offer in the Dutch iTunes store is still anemic at best, and the Apple TV is a dubious proposition — if you think of it as the equivalent of the DVD player that sits below your TV.

    But that’s not what it’s for.

    My first glimpse of understanding came in November last year, when the keynote at Minecon was being streamed live across the internets. Minecraft 1.0 was finally going to be released, and Alex and Fiona were super excited about it. We plugged my old laptop into our big-screen living room TV, and let the kids stay up late so we could all watch the big moment together. But while we were waiting, we watched a couple of videos on YouTube. And afterwards, we left the laptop plugged in for a few days, and the kids watched some more videos.

    Turns out there is a place in our life for watching YouTube on the living room TV instead of just on our computer screens. But also: it reminded me of a long-dormant desire to rip all of my DVDs to hard disk and have them available through some kind of media centre interface. I had played around with using a Mac Mini as a media centre before, but there’s something a bit naff about having a computer with a big whopping external hard disk plugged into your TV. Sure, it works, and it gives you all of the power! of a general purpose computer (web browser! games!); but it also gives you all of the downsides (software updates! manual configuration!). A home-built HTPC may be a source of massive geek cred, but in the end it’s just a hack.

    That’s where the Apple TV came in. It’s a perfectly silent, tiny device that plugs into an HDMI socket, and provides a lovely interface for streaming video. It has a built-in YouTube “app”; no web browser required. I can rent and watch movies directly from the iTunes store. And best of all, I can use it to stream videos from a computer acting as a media centre — which means that the bulky NAS can be conveniently tucked away out of sight in my office. So I bought an Apple TV in December, and it’s great. Mark Boulton gives a good overview of a similar setup (including his backup options) in his post Backups, Networks and a Digital Home. I haven’t installed aTV Flash on ours, but I might in the future.

    But although this setup is groovy, it’s still not what the Apple TV is for.

    All of these features are about pulling content to your TV. It assumes that the TV is the important thing, and everything else is a peripheral designed to serve it. It assumes that the living room is where you have your TV, and that’s where you settle in for the evening to watch your shows. This is the paradigm that other consumer-level devices operate in: DVD players, cable TV set-top boxes, game consoles. They are all static boxes designed to complement your TV, and to maintain its supremacy as the core of your home entertainment setup.

    The Apple TV looks like just another content box, but that’s camouflage. It’s actually is a secret weapon in disguise. Its purpose is to stand that home entertainment model on its head: to place content at the heart instead of the screen. This is where Airplay comes in. Airplay is all about pushing your content (music, video) to a device (speakers, screen) from wherever you are and whatever you are using, rather than assuming that you are tied to a delivery mechanism (your hifi speakers, your living room TV) and want to pull content towards you.

    The “aha!” moment for me came when my parents were visiting us a few weeks ago. We were talking about our trip to see the magician Hans Klok in Carré last summer, and about magic in general. My dad pointed out that Hans Klok’s wine bottles trick is a variation of Tommy Cooper’s classic “bottle, glass” routine. Of course, we fired up the Apple TV and went straight to YouTube to find a clip of it. Cool. My iPad was around as well, and while we were watching clips on the TV, we were also browsing YouTube on the iPad and looking up our other favourite acts. And then, rather than pulling up the next clip on the Apple TV, I used Airplay to push the video from my iPad up onto the TV.

    This was the lighbulb moment.

    The iPad is the device I’m using. It could just as easily be an iPhone, or my laptop. The TV happens to be nearby. The TV becomes a temporary extension of the device.

    Another example: I have a friend round to visit. They want to show me their holiday photos, or a funny video of their cat. They could show me on the screen of their iPhone, or they could just push it up onto the big screen.

    Or: I go round to a friend’s house. I have a bunch of music on my iPhone. They have an Airport Express plugged into their hifi, and — boom — I can push my favourite song through their speakers rather than having to plug my phone in to the stereo. If they have an Apple TV box attached to their TV, we can watch any movie I have with me, without futzing about with HDMI cables and adapters, or cursing myself for forgetting to bring the DVD.

    As more music and video gets stored in the cloud, this becomes an even more low-friction scenario. I won’t even have to worry about putting music or video onto my iPad to take with me wherever I go, because it’ll be accessible from anywhere with a wireless signal. As flexible screen technology develops, more and more ordinary surfaces will be transformed into displays. Maybe I’ll be able to walk into a café with my iPod, and play a movie onto my table. Maybe I’ll be able to play funny pictures onto your T-shirt.

    You know, in the future, when Captain Jean-Luc Picard says “On screen!“, and some random ensign pushes the video from their console up onto the main viewing screen? Airplay.

    This is also why I think Apple is not about to produce an actual consumer TV. (Although I may be proved wrong on this very soon.) With Airplay, they have relegated the TV to the status of a peripheral. A very expensive peripheral to be sure, but as Fred Wilson has pointed out, cheap things will be smart, while expensive things will be dumb. Apple likes smart things that you will upgrade every couple of years. A small, cheap Apple TV device that makes any big screen TV smart fits in that category; a 42-inch “smart” TV that will be obsolete in two years, but is too expensive to replace in that timeframe, doesn’t. And any kind of Apple-branded TV definitely would be a high-end, premium, and expensive device.

    Apple used to make speakers: remember the iPod Hi-Fi? But they got out of that business. TVs and speakers don’t matter any more. They’re just surfaces through which we push our media. Smart, highly personal devices that control the TVs and speakers — that’s where the real value lies.

    How to turn off keyboard sounds on Android 3.2

    It’s not under SettingsSound. Oh no. That would be far too easy.

    Go to SettingsLanguage & InputConfigure input methodsSettings, and uncheck the Sound on keypress checkbox.

    Someone was thinking: “You paid for these sounds. Why on earth would you want to turn them off?”