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.
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.
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), so I want to take a moment to elaborate on my statement. To do that, I’ll begin with a story.
Remote debugging of sites on mobile and tablets is getting a little easier, but still has too many pain points; for example, while you can debug iOS Safari through desktop Safari, you can only do so with a single device at a time; and to debug on Android you have to download and install the full SDK, and even that only works with Chrome.
Adobe Edge Inspect is useful for remote debugging but is limited by many requirements: you must install an app on each target device, so it won’t work on any platform other than Android or iOS; it uses Chrome desktop for the debug tools (although a new open API may open that to other browsers); and you must buy a subscription to unlock multi‐device debugging.
If you want to do truly cross‐platform remote debugging on the cheap you need weinre, a free and open source project which is actually the basis of Edge Inspect; Adobe bought the technology, then released the original source under an open license. weinre’s quite easy to install, although it doesn’t appear to be, so in this article I’m going to lay out the few simple steps required to get it up and running.
As you probably know, icon (or, symbol) fonts are a great way to implement scalable, styleable icons which work across pretty much every browser (every one that supports web fonts, anyway). There are many top quality icon fonts available, such as Pictos and Font Awesome, but sometimes you’ll want to create your own bespoke icons. Github wrote detailed instructions of how they made their icon set, Octicons, in their post The Making of Octicons, but that relies on using some professional tools. In this article I’m going to show simple alternative method that uses the brilliant free tool, IcoMoon. Read the full article
Today Adobe released a preview of their new WYSIWYG website creator, Muse. Shortly after, I had a good old moan about it on Twitter. Not, as you may think, because I feel threatened by website creation being made easy — it’s been easy for ages, but ‘easy’ doesn’t always mean ‘good’ — but because it gets a few fundamental things badly wrong.
My code purist side rejected it because the markup it outputs is horrendous; if you don’t believe me, take a look at the code for one of their example sites, ‘Lucid Synergy’. My educator side rejected it because it teaches you nothing about how a web page is made; I learned to code by using Microsoft FrontPage many (many) years ago, and understood HTML by editing the source of the document and tweaking it until I got it the way I wanted — but Muse has no code view, so this is made very difficult.
But the real problem with Adobe Muse is deeper than that: it’s that all semantic sense is completely removed from the page. There are no headings, no lists, all text is in
p elements, inline styles are applied with
span rather than
b, etc; this gives no structure, no meaning, no aboutness to your page, which at the very least means penalties for SEO.
And worse still is that there’s no document flow; all the elements you add to the page are positioned relatively to their parent and follow no particular order, which is pretty bad for search engine spiders (and hence your SEO), but absolutely terrible for visitors using assistive technology.
It’s the product of a company that cares only about appearance, and nothing for content. As @paulrobertlloyd said on Twitter:
It’s not that the code Adobe Muse generates is ugly, it’s that it’s meaningless.
The issue with the lack of semantic elements is not insurmountable, it just needs some work by Adobe before the final release. The lack of document flow and content order is more serious, however, and will need a complete rethink; I hope that this happens.