The slides from Calum’s presentation about progressive web apps. There are links throughout to some handy resources.
Friday, July 14th, 2017
Thursday, July 13th, 2017
This primer on progressive web apps starts by dispelling some myths:
- Your thing does not have to be an “Application” to be a PWA.
- PWAs are not specifically made for Google or Android.
- PWAs are ready and safe to use today.
Then it describes the three-step programme for turning your thing into a progressive web app:
- The Manifest.
- Go HTTPS.
- The Service Worker.
Thursday, July 6th, 2017
Tell it, brother!
Friday, April 28th, 2017
If your company is or is planning on doing business in emerging markets, architecting your web applications for performance through progressive enhancements is one easy way to drastically improve accessibility, retention, and user experience.
This article uses “progressive enhancement” and “progressive web app” interchangeably, which would be true in an ideal world. This is the first of a three part series, and it sounds like it will indeed document how to take an existing site and enhance it into a progressive web app—a strategy I much prefer to creating a separate silo that only works for a subset of devices (the app-shell model being pushed by Google).
Thursday, March 23rd, 2017
Turning your existing website into a progressive web “app”—a far more appealing prospect than trying to create an entirely new app-shell architecture:
…they are an enhancement of your existing website which should take no longer than a few hours and have no negative effect on unsupported browsers.
Friday, February 17th, 2017
A useful tool to help you generate a manifest file, icons, and a service worker for your progressive web
Sunday, December 4th, 2016
Henrik points to some crucial information that slipped under the radar at the Chrome Dev Summit—the Android OS is going to treat progressive web apps much more like regular native apps. This is kind of a big deal.
It’s a good time to go all in on the web. I can’t wait to see what the next few years bring. Personally, I feel like the web is well poised to replace the majority of apps we now get from app stores.
Monday, September 19th, 2016
A nice introduction to progressive web apps. There’s a little bit of confusion about permissions—whether a site has been added to the home screen or not has no effect on the permissions granted to it (for things like push notifications)—but the wrap-up nails the advantages of using the web:
No more waiting to download an app, no more prompts for updating an app. From a developer perspective, it means we will be able to iterate a lot quicker. We don’t need to wait for app store approvals anymore, and we can deploy at our own leisure.
Another advantage that a progressive web app has over a native mobile app is that it is linkable, hence it is easier to share and, probably even more importantly, can be indexed by search engines. This makes discoverability of the app a lot better.
Tuesday, July 19th, 2016
Jason looks at the business reasons for and against building progressive web apps. In short, there’s everything to gain and nothing to lose.
Seriously, why would you not add a Service Worker and a manifest file to your site? (assuming you’re already on HTTPS)
Wednesday, June 22nd, 2016
If you’re going to make a manifest file for an existing site, start with this very handy tool. You give it the URL of your site and it then parses the content for existing metadata to create a best first stab at a manifest JSON file.
Tuesday, May 24th, 2016
Regressive Web Apps
There were plenty of talks about building for the web at this year’s Google I/O event. That makes a nice change from previous years when the web barely got a look in and you’d be forgiven for thinking that Google I/O was an event for Android app developers.
This year’s event showed just how big Google is, and how it doesn’t have one party line when it comes to the web and native. At the same time as there were talks on Service Workers and performance for the web, there was also an unveiling of Android Instant Apps—a full-frontal assault on the web. If you thought it was annoying when websites door-slammed you with intrusive prompts to install their app, just wait until they don’t need to ask you anymore.
I've been "Maybe I'll go Android" for awhile but today's announcement of http:// links getting hijacked into apps got me all like Nope.— Dave Rupert (@davatron5000) May 18, 2016
Peter has looked a bit closer at Android Instant Apps and I think he’s as puzzled as I am. Either they are sandboxed to have similar permission models to the web (in which case, why not just use the web?) or they allow more access to native APIs in which case they’re a security nightmare waiting to happen. I’m guessing it’s probably the former.
- Connectivity independent
A lot of those points are shared by good native apps, but the first and last points in that list are key features of the web: being responsive and linkable.
Alas many of the current examples of so-called Progressive Web Apps are anything but. Flipkart and The Washington Post have made Progressive Web Apps that are getting lots of good press from Google, but are mobile-only.
I’m getting very concerned that the success criterion for Progressive Web Apps is changing from “best practices on the web” to “feels like native.” That certainly seems to be how many of the current crop of Progressive Web Apps are approaching the architecture of their sites. I think that’s why the app-shell model is the one that so many people are settling on.
Personally, I’m not a fan of the app-shell model. I feel that it prioritises exactly the wrong stuff—the interface is rendered quickly while the content has to wait. It feels weirdly like a hangover from Appcache. I also notice it being used as a get-out-of-jail-free card, much like the ol’ “Single Page App” descriptor; “Ah, I can’t do progressive enhancement because I’m building an app shell/SPA, you see.”
But whatever. That’s just, like, my opinion, man. Other people can build their app-shelled SPAs and meanwhile I’m free to build websites that work everywhere, and still get to use all the great technologies that power Progressive Web Apps. That’s one of the reasons why I’ve been quite excited about them—all the technologies and methodologies they promote match perfectly with my progressive enhancement approach: responsive design, Service Workers, good performance, and all that good stuff.
For example, I’ve seen people use a meta viewport declaration to disable pinch-zooming on their sites. As justification they point to the fact that you can’t pinch-zoom in most native apps, therefore this web-based app should also prohibit that action. The inability to pinch-zoom in native apps is a bug. By also removing that functionality from web products, people are reproducing unnecessary bugs. It feels like a cargo-cult approach to building for the web: slavishly copy whatever native is doing …because everyone knows that native apps are superior to websites, right?
Here’s another example of the cargo-cult imitation of native. In your manifest JSON file, you can declare a
display property. You can set it to
fullscreen. If you set it to
fullscreen then, when the site is launched from the home screen, it won’t display the address bar. If you set the
display property to
browser, the address bar will be visible on launch. Now, personally I like to expose those kind of seams:
The idea of “seamlessness” as a desirable trait in what we design is one that bothers me. Technology has seams. By hiding those seams, we may think we are helping the end user, but we are also making a conscience choice to deceive them (or at least restrict what they can do).
Other people disagree. They think it makes more sense to hide the URL. They have a genuine concern that users will be confused by launching a website from the home screen in a browser (presumably because the user’s particular form of amnesia caused them to forget how that icon ended up on their home screen in the first place).
Fair enough. We’ll agree to differ. They can set their
display property how they want, and I can set my
display property how I want. It’s a big web after all. There’s no one right or wrong way to do this. That’s why there are multiple options for the values.
Or, at least, that was the situation until recently…
Remember when I wrote about how Chrome on Android will show an “add to home screen” prompt if your Progressive Web App fulfils a few criteria?
- It is served over HTTPS,
- it has a manifest JSON file,
- it has a Service Worker, and
- the user visits it a few times.
Well, those goalposts have moved. There is now a new criterion:
- Your manifest file must not contain a
Chrome developers have decided that displaying URLs is not “best practice”. It was filed as a bug.
I’m somewhat flabbergasted by this. The killer feature of the web—URLs—are being treated as something undesirable because they aren’t part of native apps. That’s not a failure of the web; that’s a failure of native apps.
Now, don’t get me wrong. I’m not saying that everyone should be setting their
display property to
browser. That would be far too prescriptive. I’m saying that it should be a choice. It should depend on the website. It should depend on the expectations of the users of that particular website. To declare that all users of all websites will be confused by seeing a URL is so presumptuous and arrogant that it beggars belief.
I wouldn’t even have noticed this change of policy if it weren’t for the newly-released Lighthouse tool for testing Progressive Web Apps. The Session gets a good score but under “Best Practices” there was a red mark against the site for having
display: browser. Turns out that’s the official party line from Chrome.
Just to clarify: you can have a site that has literally no HTML or turns away entire classes of devices, yet officially follows “best practices” and gets rewarded with an “add to home screen” prompt. But if you have a blazingly fast responsive site that works offline, you get nothing simply because you don’t want to hide URLs from your users:
I want people to be able to copy URLs. I want people to be able to hack URLs. I’m not ashamed of my URLs …I’m downright proud.
The app manifest declares properties of the app, but the
displayproperty isn’t about the app; it’s about how the app’s developer wants it to be shown. Do they want to proudly declare that this app is on the web and of the web? Then they’ll add the URL bar. Do they want to conceal that this is actually a web app in order to look more like “native” apps? Then they’ll hide the URL bar.
I think there’s something to that, but digging deeper, developers and designers don’t make decisions like that in isolation. They’re generally thinking about what’s best for users. So, yes, absolutely, different apps will have different
display properties, but that shouldn’t be down to the belief system of the developer; it should be down to the needs of the users …the specific needs of the specific users of that specific app. For the Chrome team to come down on one side or the other and arbitrarily declare that one decision is “correct” for every single Progressive Web App that is ever going to be built …that’s a political decision. It kinda feels like an abuse of power to me. Withholding the “add to home screen” prompt like that has a whiff of blackmail about it.
The other factors that contribute to the “add to home screen” prompt are pretty uncontroversial:
- Sites should be served over a secure connection: that’s pretty hard to argue with.
- Sites should be resilient to network outages: I don’t think anyone is going to say that’s a bad idea.
- Sites should provide some metadata in manifest file: okay, sure, it’s certainly not harmful.
- Sites should obscure their URL …whoa! That feels like a very, very different requirement, one that imposes one particular opinion onto everyone who wants to participate.
This isn’t the first time that Chrome developers have made a move against the address bar. It’s starting to grind me down.
Up until now I’ve been a big fan of Progressive Web Apps. I understood them to be combining the best of the web (responsiveness, linkability) with the best of native (installable, connectivity independent). Now I see that balance shifting towards the native end of the scale at the expense of the web’s best features. I’d love to see that balance restored with a little less emphasis on the “Apps” and a little more emphasis on the “Web.” Now that would be progressive.
Monday, May 23rd, 2016
Issue 596729 - chromium - Do not show the app banner unless the Manifest has a display set to standalone or fullscreen - Monorail
I am shocked and disgusted by this arbitrary decision by the Chrome team. If your Progressive Web App doesn’t set its manifest to obscure its URL, you get punished by missing out on the add to home screen prompt.
Monday, March 21st, 2016
Friday, March 18th, 2016
Remy sums up the psychological end goal of progressive apps (HTTPS + Service Worker + manifest JSON file) prompting an add to home screen action:
This high bar of entry will create a new mental model for our users.
If I add this app to my home screen, it will work when I open it.
It’s a shame that this charge to turbo-boast the perception of the web on mobile is a bit one-sided: I would love to see Apple follow Google’s lead here. But if Android succeed in their goal, then I think iOS will have to follow suit just to compete.
Sunday, March 6th, 2016
Fear and loathing in Houston.
- Humanity will never colonize Mars, never build moon bases, never rearrange the asteroids, never build a sphere around the sun.
- There will never be faster-than-light travel. We will not roam across the galaxy. We will not escape our star.
- Life is probably an entirely unexceptional phenomenon; the universe probably teems with it. We will never make contact. We will never fuck green-skinned alien babes.
- The human race will live and die on this rock, and after we are gone something else will take our place. Maybe it already has, without our even noticing.
- All this is good. This is a good thing.
Tuesday, December 15th, 2015
A hands-on look at building a progressive web app with Service Workers, manifest files, HTTPS, and all that good stuff. This is nice and balanced, extolling the virtues but also warning about the potential difficulties in implementing this stuff.
One nitpick though: there’s talk of graceful degradation, and while I get that that’s the outcome, I think it’s better to think in terms of progressive enhancement, which is the approach.
Friday, November 27th, 2015
Bruce gives a great run-down of what’s involved in creating one of those new-fangled progressive apps that everyone at Google and Opera (and soon, Mozilla) are talking about: a secure connection, a service worker, and a manifest file.
Crucially, in browsers that don’t support it, you have a normal website. It’s perfect progressive enhancement.
Funnily enough, this here website—adactio.com—is technically a progressive app now.
At their simplest, Progressive Web Apps are application-like things hosted on your web server. If you’re as old as me, you might call them “web sites”
Wednesday, November 18th, 2015
Friday, January 9th, 2015
There’s more than a whiff of Indie Web thinking in this sequel to the Cluetrain Manifesto from Doc Searls and Dave Weinberger.
The Net’s super-power is connection without permission. Its almighty power is that we can make of it whatever we want.
It’s quite lawn-off-getty …but I also happen to agree with pretty much all of it.
Although it’s kind of weird that it’s published on somebody else’s website.
Tuesday, August 19th, 2014
Glenn eloquently gives his reasons for building Transmat:
When I was a child, my brothers and I all had a shoebox each. In these we kept our mementoes. A seashell from a summer holiday where I played for hours in the rock pools, the marble from the schoolyard victory against a bully and a lot of other objects that told a story.