Android Instant Apps and the web

Today’s Google I/O keynote introduced a new technology called Android Instant Apps. In a nutshell, Instant Apps displays a small, focused portion of an app when a user clicks on a related link — even if the app isn’t installed on their system. The example used in the keynote was the Buzzfeed Video app: when a user clicks on a URL to view a Buzzfeed video, and doesn’t have the app installed, the URL is intercepted by the Android system and opened in a part of the app, delivered from the Google Play servers, rather than in a browser.

https://youtu.be/cosqlfqrpFA

Instant Apps requires the app creator to build their app in a prescribed way, using deep linking and setting up modular views, but it apparently only takes about a day to modify an existing app to work in this way. There are still some unanswered questions about Instant Apps, not least in regards to whether their use is optional.

This certainly solves the biggest problems with apps: having people find them, and install them. And from the perspective of the user it probably makes no difference if they fulfil their task through the medium of a website, app or Instant App — provided the medium is seamless to transition, fast to load, and focused on the task.

But for developers, an Instant App doesn’t seem to offer much value beyond a website: as it’s an Android-only service, the URL that launches it can be shared across iOS and desktop also, meaning there is still a duplication of effort to build that web presence.

So then what’s the incentive of putting in the extra work for Instant Apps? Perhaps it exists only when the app can offer something that the web is unable to, such as access to system-level APIs (like payments); or perhaps when the web alternative isn’t optimised.

Otherwise this seems like it’s a drop-in replacement for the web; and, as Klint Finley said when discussing the conceptually-related universal links on iOS:

If you want apps that work like the web, the web is still your best choice.

installing


A Little Less Metacrap

Jeremy Keith wrote a (typically great) post about metacrap, the unneccesarily verbose and repetitive metadata in the head of web documents, that’s required for content to be more easily shareable across social media. I fully agree with his broad point — there’s an awful lot of crap in head — but there’s a flaw in his initial examples. It’s explained in this extract from Twitter’s Getting Started [with Cards] Guide:

You’ll notice that Twitter card tags look similar to Open Graph tags, and that’s because they are based on the same conventions as the Open Graph protocol. If you’re already using Open Graph protocol to describe data on your page, it’s easy to generate a Twitter card without duplicating your tags and data.

So actually the metadata you need to cater for most social sharing is Open Graph, with a few extra tags just for Twitter:

<meta name="twitter:card" content="summary">
<meta name="twitter:site" content="@adactio">
<meta property="og:url" content="https://adactio.com/journal/9881">
<meta property="og:title" content="Metadata markup">
<meta property="og:description" content="So many standards to choose from.">
<meta property="og:image" content="https://adactio.com/icon.png">

I mean, it’s still perhaps too much, and (as pointed out) would probably be best written as JSON-LD in the manifest. But there’s no redundancy, so is not quite as bad as painted in Jeremy’s article, even with his elegant squishing solution.


OK Computer: how to work with automation and AI on the web

Automated systems powered by new breakthroughs in Artificial Intelligence will soon begin to have an impact on the web industry. People working on the web will have to learn new design disciplines and tools to stay relevant. Based on the talk “OK Computer” that I gave at a number of conferences in Autumn 2015.

Read the full article


The Changing Form of the Web Browser

I wrote an article, The Changing Form of the Web Browser, for rehabstudio (my employer). It’s about the present and near-future of the web browser, in a market where the consumption of information and services is shifting. It’s quite a long piece, and necessarily broad for a non-technical audience, so there is perhaps a lack of nuance in its conclusions. Still, I’m quite proud of it, a lot of research and writing was involved.

There’s an extract below, but I suggest you read the whole thing in context if you can.

Read the full article


Innovation in Mobile Browsers, and the iPhone

Last week I wielded the mighty power of Twitter to say this:

If you use an iPhone I feel a bit sorry for you, because you’re missing out on the really innovative stuff happening in mobile browsers.

A few people asked me what I meant by that, perhaps thinking that I was criticising iPhones in general (I wasn’t[1]), so I want to take a moment to elaborate on my statement. To do that, I’ll begin with a story.

Read the full article


Feeling Like An Unwelcome Guest on medium.com

I have a shortcut to medium.com on the home screen of my Android phone. It’s there because I browsed the site a couple of times and Chrome’s app install banners prompted me to add it to my home screen, so I did. Some time later I launched the site from the shortcut icon and it opened and loaded so quickly that I actually thought it had retrieved a copy from an offline cache. But it hadn’t, it was just very well optimised. So ten points to the Medium team for that.

Today I launched the site from the shortcut again – but this time the experience was somewhat different. So different that I have to take away all the points I previously awarded to the team. The problem is that when I launched the site today, I had the door emphatically slammed in my face.

Read the full article


Archive by category and date