Android Instant Apps and the web

Today’s Google I/O keynote intro­duced a new tech­nol­o­gy called Android Instant Apps. In a nut­shell, Instant Apps dis­plays a small, focused por­tion of an app when a user clicks on a relat­ed link — even if the app isn’t installed on their sys­tem. The exam­ple used in the keynote was the Buz­zfeed Video app: when a user clicks on a URL to view a Buz­zfeed video, and doesn’t have the app installed, the URL is inter­cept­ed by the Android sys­tem and opened in a part of the app, deliv­ered from the Google Play servers, rather than in a browser.

Instant Apps requires the app cre­ator to build their app in a pre­scribed way, using deep link­ing and set­ting up mod­u­lar views, but it appar­ent­ly only takes about a day to mod­i­fy an exist­ing app to work in this way. There are still some unan­swered ques­tions about Instant Apps, not least in regards to whether their use is optional.

This cer­tain­ly solves the biggest prob­lems with apps: hav­ing peo­ple find them, and install them. And from the per­spec­tive of the user it prob­a­bly makes no dif­fer­ence if they ful­fil their task through the medi­um of a web­site, app or Instant App — pro­vid­ed the medi­um is seam­less to tran­si­tion, fast to load, and focused on the task.

But for devel­op­ers, an Instant App doesn’t seem to offer much val­ue beyond a web­site: as it’s an Android-only ser­vice, the URL that launch­es it can be shared across iOS and desk­top also, mean­ing there is still a dupli­ca­tion of effort to build that web presence.

So then what’s the incen­tive of putting in the extra work for Instant Apps? Per­haps it exists only when the app can offer some­thing that the web is unable to, such as access to sys­tem-lev­el APIs (like pay­ments); or per­haps when the web alter­na­tive isn’t optimised.

Oth­er­wise this seems like it’s a drop-in replace­ment for the web; and, as Klint Fin­ley said when dis­cussing the con­cep­tu­al­ly-relat­ed uni­ver­sal links on iOS:

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

installing


A Little Less Metacrap

Jere­my Kei­th wrote a (typ­i­cal­ly great) post about metacrap, the unnecce­sar­i­ly ver­bose and repet­i­tive meta­da­ta in the head of web doc­u­ments, that’s required for con­tent to be more eas­i­ly share­able across social media. I ful­ly agree with his broad point — there’s an awful lot of crap in head — but there’s a flaw in his ini­tial exam­ples. It’s explained in this extract from Twitter’s Get­ting Start­ed [with Cards] Guide:

You’ll notice that Twit­ter card tags look sim­i­lar to Open Graph tags, and that’s because they are based on the same con­ven­tions as the Open Graph pro­to­col. If you’re already using Open Graph pro­to­col to describe data on your page, it’s easy to gen­er­ate a Twit­ter card with­out dupli­cat­ing your tags and data.

So actu­al­ly the meta­da­ta you need to cater for most social shar­ing 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 per­haps too much, and (as point­ed out) would prob­a­bly be best writ­ten as JSON-LD in the man­i­fest. But there’s no redun­dan­cy, so is not quite as bad as paint­ed in Jeremy’s arti­cle, even with his ele­gant squish­ing solution.


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

Auto­mat­ed sys­tems pow­ered by new break­throughs in Arti­fi­cial Intel­li­gence will soon begin to have an impact on the web indus­try. Peo­ple work­ing on the web will have to learn new design dis­ci­plines and tools to stay rel­e­vant. Based on the talk “OK Com­put­er” that I gave at a num­ber of con­fer­ences in Autumn 2015.

Read the full article


The Changing Form of the Web Browser

I wrote an arti­cle, The Chang­ing Form of the Web Brows­er, for rehab­stu­dio (my employ­er). It’s about the present and near-future of the web brows­er, in a mar­ket where the con­sump­tion of infor­ma­tion and ser­vices is shift­ing. It’s quite a long piece, and nec­es­sar­i­ly broad for a non-tech­ni­cal audi­ence, so there is per­haps a lack of nuance in its con­clu­sions. Still, I’m quite proud of it, a lot of research and writ­ing was involved.

There’s an extract below, but I sug­gest you read the whole thing in con­text if you can.

Read the full article


Innovation in Mobile Browsers, and the iPhone

Last week I wield­ed the mighty pow­er of Twit­ter to say this:

If you use an iPhone I feel a bit sor­ry for you, because you’re miss­ing out on the real­ly inno­v­a­tive stuff hap­pen­ing in mobile browsers.

A few peo­ple asked me what I meant by that, per­haps think­ing that I was crit­i­cis­ing iPhones in gen­er­al (I wasn’t[1]), so I want to take a moment to elab­o­rate on my state­ment. To do that, I’ll begin with a story.

Read the full article


Feeling Like An Unwelcome Guest on medium.com

I have a short­cut to medium.com on the home screen of my Android phone. It’s there because I browsed the site a cou­ple of times and Chrome’s app install ban­ners prompt­ed me to add it to my home screen, so I did. Some time lat­er I launched the site from the short­cut icon and it opened and loaded so quick­ly that I actu­al­ly thought it had retrieved a copy from an offline cache. But it hadn’t, it was just very well opti­mised. So ten points to the Medi­um team for that.

Today I launched the site from the short­cut again – but this time the expe­ri­ence was some­what dif­fer­ent. So dif­fer­ent that I have to take away all the points I pre­vi­ous­ly award­ed to the team. The prob­lem is that when I launched the site today, I had the door emphat­i­cal­ly slammed in my face.

Read the full article


Archive by category and date