A personal site, or a blog, is more than just a collection of writing. It’s a kind of place - something that feels like home among the streams. Home is a very strong mental model.
Sunday, March 13th, 2022
Tuesday, January 18th, 2022
Installing progressive web apps
I don’t know about you, but it seems like everyone I follow on Twitter is playing Wordle. Although I don’t play the game myself, I think it’s pretty great.
Not only does Wordle have a very sweet backstory, but it’s also unashamedly on the web. If you want to play, you go to the URL
powerlanguage.co.uk/wordle. That’s it. No need to download an app.
That hasn’t stopped some nefarious developers trying to trick people into downloading their clones of Wordle from app stores. App stores, which are meant to be curated and safe, are in fact filled with dodgy knock-offs and scams. Contrary to popular belief, the web is quite literally a safer bet.
Wordle has a web app manifest, which means you can add it to your home screen and it will behave just like a native app (although I don’t believe it has offline support). That’s great, but the process of adding a web app to your home screen on iOS is ludicrously long-winded.
Macworld published an article detailing how to get the real Wordle app on your iPhone or iPad. On the one hand it’s great to see this knowledge being spread. On the other hand it’s dispiriting that it’s even necessary to tell people that they can do this, like it’s a hidden nerdy secret just for power users.
At this point I’ve pretty much given up on Apple ever doing anything about this pathetic situation. So what can I do instead?
Well, taking my cue from that Macworld article, the least I can do is inform people how they can add a progressive web app to their home screen.
That’s what I’ve done on thesession.org. I’ve published a page on how to install The Session to your home screen.
On both Android and iPhone the journey to installing a progressive web app begins with incomprehensible iconography. On Android you must first tap on the unlabeled kebab icon—three vertical dots. On iOS you must first tap on the unlabeled share icon—a square with an arrow coming out of it.
When it comes to mobile operating systems, consumer choice means you choose which kind of mystery meat to eat.
I’ve included screenshots to help people identify these mysterious portals. For iOS I’ve also included a video to illustrate the quest to find the secret menu item buried beneath the share icon.
Handy tip: when you’re adding a
start_url value to your web app manifest, it’s common to include a query string like this:
I’m guessing most people to that so they can get analytics on how many people are starting from an icon tap. I don’t do analytics on The Session but I’m still using that query string in my
start_url. On the home page of the site, I check for the existence of the query string. If it exists, I don’t show the link to the installation page. So once someone has installed the site to their home screen, they shouldn’t see that message when they launch The Session.
If you’ve got a progressive web app, it might be worth making a page with installation instructions rather than relying on browsers to proactively inform your site’s visitors. You’d still need to figure out the right time and place to point people to that page, but at least the design challenge would be in your hands.
Should you decide to take a leaf out of the Android and iOS playbooks and use mystery meat navigation to link to such a page, there’s an emoji you could potentially use: 📲
It’s still worse than using actual words, but it might be better than some random combination of dots, squares and arrows.
(I’m not really serious about using that emoji, but if you do, be sure to use a sensible
aria-label value on the enclosing
Tuesday, June 29th, 2021
If you download Safari Technology Preview you can test drive features that are on their way in Safari 15. One of those features, announced at Apple’s World Wide Developer Conference, is coloured browser chrome via support for the
meta value of “theme-color.” Chrome on Android has supported this for a while but I believe Safari is the first desktop browser to add support. They’ve also added support for the
media attribute on that
meta element to handle “prefers-color-scheme.”
This is all very welcome, although it does remind me a bit of when Internet Explorer came out with the ability to make coloured scrollbars. I mean, they’re nice features’n’all, but maybe not the most pressing? Safari is still refusing to acknowledge progressive web apps.
That’s not quite true. In her WWDC video Jen demonstrates how you can add a progressive web app like Resilient Web Design to your home screen. I’m chuffed that my little web book made an appearance, but when you see how you add a site to your home screen in iOS, it’s somewhat depressing.
The steps to add a website to your home screen are:
- Tap the “share” icon. It’s not labelled “share.” It’s a square with an arrow coming out of the top of it.
- A drawer pops up. The option to “add to home screen” is nowhere to be seen. You have to pull the drawer up further to see the hidden options.
- Now you must find “add to home screen” in the list
- Add to Reading List
- Add Bookmark
- Add to Favourites
- Find on Page
- Add to Home Screen
It reminds of this exchange in The Hitchhiker’s Guide To The Galaxy:
“You hadn’t exactly gone out of your way to call attention to them had you? I mean like actually telling anyone or anything.”
“But the plans were on display…”
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a torch.”
“Ah, well the lights had probably gone.”
“So had the stairs.”
“But look you found the notice didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of The Leopard.’”
Safari’s current “support” for adding progressive web apps to the home screen feels like the minimum possible …just enough to use it as a legal argument if you happen to be litigated against for having a monopoly on app distribution. “Hey, you can always make a web app!” It’s true in theory. In practice it’s …suboptimal, to put it mildly.
It’s a little bit weird that this stylistic information is handled by HTML rather than CSS. It’s similar to the
viewport value in that sense. I always that the plan was to migrate that to CSS at some point, but here we are a decade later and it’s still very much part of our boilerplate markup.
Some people have remarked that the coloured browser chrome can make the URL bar look like part of the site so people might expect it to operate like a site-specific search.
I also wonder if it might blur “the line of death”; that point in the UI where the browser chrome ends and the website begins. Does the unified colour make it easier to spoof browser UI?
Probably not. You can already kind of spoof browser UI by using the right shade of grey. Although the removal any kind of actual line in Safari does give me pause for thought.
I tend not to think of security implications like this by default. My first thought tends to be more about how I can use the feature. It’s only after a while that I think about how bad actors might abuse the same feature. I should probably try to narrow the gap between those thoughts.
Tuesday, June 22nd, 2021
There’s a nice shout-out from Jen for Resilient Web Design right at the 19:20 mark.
It would be nice if the add-to-homescreen option weren’t buried so deep though.
Thursday, March 26th, 2020
Apple’s attack on service workers
Apple aren’t the best at developer relations. But, bad as their communications can be, I’m willing to cut them some slack. After all, they’re not used to talking with the developer community.
John Wilander wrote a blog post that starts with some excellent news: Full Third-Party Cookie Blocking and More. Safari is catching up to Firefox and disabling third-party cookies by default. Wonderful! I’ve had third-party cookies disabled for a few years now, and while something occassionally breaks, it’s honestly a pretty great experience all around. Denying companies the ability to track users across sites is A Good Thing.
In the same blog post, John said that client-side cookies will be capped to a seven-day lifespan, as previously announced. Just to be clear, this only applies to client-side cookies. If you’re setting a cookie on the server, using PHP or some other server-side language, it won’t be affected. So persistent logins are still doable.
Then, in an audacious example of burying the lede, towards the end of the blog post, John announces that a whole bunch of other client-side storage technologies will also be capped to seven days. Most of the technologies are APIs that, like cookies, can be used to store data: Indexed DB, Local Storage, and Session Storage (though there’s no mention of the Cache API). At the bottom of the list is this:
Service Worker registrations
Okay, let’s clear up a few things here (because they have been so poorly communicated in the blog post)…
The seven day timer refers to seven days of Safari usage, not seven calendar days (although, given how often most people use their phones, the two are probably interchangable). So if someone returns to your site within a seven day period of using Safari, the timer resets to zero, and your service worker gets a stay of execution. Lucky you.
This only applies to Safari. So if your site has been added to the home screen and your web app manifest has a value for the “display” property like “standalone” or “full screen”, the seven day timer doesn’t apply.
That piece of information was missing from the initial blog post. Since the blog post was updated to include this clarification, some people have taken this to mean that progressive web apps aren’t affected by the upcoming change. Not true. Only progressive web apps that have been added to the home screen (and that have an appropriate “display” value) will be spared. That’s a vanishingly small percentage of progressive web apps, especially on iOS. To add a site to the home screen on iOS, you need to dig and scroll through the share menu to find the right option. And you need to do this unprompted. There is no ambient badging in Safari to indicate that a site is installable. Chrome’s install banner isn’t perfect, but it’s better than nothing.
Just a reminder: a progressive web app is a website that
- runs on HTTPS,
- has a service worker,
- and a web manifest.
Adding to the home screen is something you can do with a progressive web app (or any other website). It is not what defines progressive web apps.
In any case, this move to delete service workers after seven days of using Safari is very odd, and I’m struggling to find the connection to the rest of the blog post, which is about technologies that can store data.
As I understand it, with the crackdown on setting third-party cookies, trackers are moving to first-party technologies. So whereas in the past, a tracking company could tell its customers “Add this
script element to your pages”, now they have to say “Add this
The best explanation I can come up with for this move by Apple is that it feels like the neatest solution. That’s neat as in tidy, not as in nifty. It is definitely not a nifty solution.
If some technologies set by a specific domain are being purged after seven days, then the tidy thing to do is purge all technologies from that domain. Service workers are getting included in that dragnet.
Now, to be fair, browsers and operating systems are free to clean up storage space as they see fit. Caches, Local Storage, Indexed DB—all of those are subject to eventually getting cleaned up.
So I was curious. Wanting to give Apple the benefit of the doubt, I set about trying to find out how long service worker registrations currently last before getting deleted. Maybe this announcement of a seven day time limit would turn out to be not such a big change from current behaviour. Maybe currently service workers last for 90 days, or 60, or just 30.
There was no time limit previously.
This is not a minor change. This is a crippling attack on service workers, a technology specifically designed to improve the user experience for return visits, whether it’s through improved performance or offline access.
I wouldn’t be so stunned had this announcement come with an accompanying feature that would allow Safari users to know when a website is a progressive web app that can be added to the home screen. But Safari continues to ignore the existence of progressive web apps. And now it will actively discourage people from using service workers.
If you’d like to give feedback on this ludicrous development, you can file a bug (down in the cellar in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying “Beware of the Leopard”).
No doubt there will still be plenty of Apple apologists telling us why it’s good that Safari has wished service workers into the cornfield. But make no mistake. This is a terrible move by Apple.
I will say this though: given The Situation we’re all living in right now, some good ol’ fashioned Hot Drama by a browser vendor behaving badly feels almost comforting.
Friday, January 10th, 2020
There’s an interesting thread on Github about the tongue-twistingly named
Let me back up…
Progressive web apps. You know what they are, right? They’re websites that have taken their vitamins. Specifically, they’re responsive websites that:
- are served over HTTPS,
- have a web app manifest, and
- have a service worker handling the offline scenario.
The web app manifest—a JSON file of metadata—is particularly useful for describing how your site should behave if someone adds it to their home screen. You can specify what icon should be used. You can specify whether the site should launch in a browser or as a standalone app (practically indistinguishable from a native app). You can specify which URL on the site should be used as the starting point when the site is launched from the home screen.
So progressive web apps work just fine when you visit them in a browser, but they really shine when you add them to your home screen. It seems like pretty much everyone is in agreement that adding a progressive web app to your home screen shouldn’t be an onerous task. But how does the browser let the user know that it might be a good idea to “install” the web site they’re looking at?
The Samsung Internet browser does ambient badging—a
+ symbol shows up to indicate that a website can be installed. This is a great approach!
I hope that Chrome on Android will also use ambient badging at some point. To start with though, Chrome notified users that a site was installable by popping up a notification at the bottom of the screen. I think these might be called “toasts”.
Needless to say, the toast notification wasn’t very effective. That’s because we web designers and developers have spent years teaching people to immediately dismiss those notifications without even reading them. Accept our cookies! Sign up to our newsletter! Install our native app! Just about anything that’s user-hostile gets put in a notification (either a toast or an overlay) and shoved straight in the user’s face before they’ve even had time to start reading the content they came for in the first place. Users will then either:
- turn around and leave, or
- use muscle memory reach for that
Xin the corner of the notification.
A tiny fraction of users might actually click on the call to action, possibly by mistake.
beforeinstallprompt can be used.
It’s a bit weird though. You have to “capture” the event that fires when the prompt would have normally been shown, subdue it, hold on to that event, and then re-release it when you think it should be shown (like when the user has completed a transaction, for example, and having your site on the home screen would genuinely be useful). That’s a lot of hoops. Here’s the code I use on The Session to only show the installation prompt to users who are logged in.
The end result is that the user is still shown a toast notification, but at least this time it’s the site owner who has decided when it will be shown. The Chrome team call this notification “the mini-info bar”, and Pete acknowledges that it’s not ideal:
The mini-infobar is an interim experience for Chrome on Android as we work towards creating a consistent experience across all platforms that includes an install button into the omnibox.
I think “an install button in the omnibox” means ambient badging in the browser interface, which would be great!
Anyway, back to that thread on Github. Basically, neither Apple nor Mozilla are going to implement the
beforeinstallprompt event (well, technically Mozilla have implemented it but they’re not going to ship it). That’s fair enough. It’s an interim solution that’s not ideal for all reasons I’ve already covered.
But there’s a lot of pushback. Even if the details of
beforeinstallprompt are troublesome, surely there should be some way for site owners to let users know that can—or should—install a progressive web app? As a site owner, I have a lot of sympathy for that viewpoint. But I also understand the security and usability issues that can arise from bad actors abusing this mechanism.
Still, I have to hand it to Chrome: even if we put the
beforeinstallprompt event to one side, the browser still has a mechanism for letting users know that a progressive web app can be installed—the mini info bar. It’s not a great mechanism, but it’s better than nothing. Nothing is precisely what Firefox and Safari currently offer (though Firefox is experimenting with something).
In the case of Safari, not only do they not provide a mechanism for letting the user know that a site can be installed, but since the last iOS update, they’ve buried the “add to home screen” option even deeper in the “sharing sheet” (the list of options that comes up when you press the incomprehensible rectangle-with-arrow-emerging-from-it icon). You now have to scroll below the fold just to find the “add to home screen” option.
So while I totally get the misgivings about
beforeinstallprompt, I feel that a constructive alternative wouldn’t go amiss.
And that’s all I have to say about that.
Except… there’s another interesting angle to that Github thread. There’s talk of allowing sites that are launched from the home screen to have access to more features than a site inside a web browser. Usually permissions on the web are explicitly granted or denied on a case-by-case basis: geolocation; notifications; camera access, etc. I think this is the first time I’ve heard of one action—adding to the home screen—being used as a proxy for implicitly granting more access. Very interesting. Although that idea seems to be roundly rejected here:
A key argument for using installation in this manner is that some APIs are simply so powerful that the drive-by web should not be able to ask for them. However, this document takes the position that installation alone as a restriction is undesirable.
I understand that Chromium or Google may hold such a position but Apple’s WebKit team may not necessarily agree with such a position.
Thursday, June 6th, 2019
Some ideas for interface elements that prompt progressive web app users to add the website to their home screen.
Friday, February 1st, 2019
It’s interesting to compare the release notes for each browser and see the different priorities reflected in them (this is another reason why browser diversity is A Good Thing).
A lot of the Firefox changes are updates to dev tools; they just keep getting better and better. In fact, I’m not sure “dev tools” is the right word for them. With their focus on layout, typography, and accessibility, “design tools” might be a better term.
Oh, and Firefox is shipping support for some CSS properties that really help with print style sheets, so I’m disproportionately pleased about that.
In Safari’s changes, I’m pleased to see that the
datalist element is finally getting implemented. I’ve been a fan of that element for many years now. (Am I a dork for having favourite HTML elements? Or am I a dork for even having to ask that question?)
And, of course, it wouldn’t be a Safari release without a new made up
meta tag. From the people who brought you such hits as
apple-mobile-web-app-capable, comes …
supported-color-schemes (Apple likes to make up
meta tags almost as much as Google likes to make up
There’ll be a whole bunch of improvements in how progressive web apps will behave once they’ve been added to the home screen. We’ll finally get some state persistence if you navigate away from the window!
Updated the behavior of websites saved to the home screen on iOS to pause in the background instead of relaunching each time.
Maximiliano Firtman has a detailed list of the good, the bad, and the “not sure yet if good” for progressive web apps on iOS 12.2 beta. Thomas Steiner has also written up the progress of progressive web apps in iOS 12.2 beta. Both are published on Ev’s blog.
Chrome 72 for Android shipped the long-awaited Trusted Web Activity feature, which means we can now distribute PWAs in the Google Play Store!
Very interesting indeed! I’m not sure if I’m ready to face the Kafkaesque process of trying to add something to the Google Play Store just yet, but it’s great to know that I can. Combined with the improvements coming in iOS 12.2, these are exciting times for progressive web apps!
Friday, August 3rd, 2018
I got an intriguing email recently from someone who’s a member of The Session, the community website about Irish traditional music that I run. They said:
When I recently joined, I used my tablet to join. Somewhere I was able to download The Session app onto my tablet.
But there is no native app for The Session. Although, as it’s a site that I built, it is, a of course, progressive web app.
They went on to say:
I wanted to put the app on my phone but I can’t find the app to download it. Can I have the app on more than one device? If so, where is it available?
I replied saying that yes, you can absolutely have it on more than one device:
But you don’t find The Session app in the app store. Instead you go to the website https://thesession.org and then add it to your home screen from your browser.
My guess is that this person had added The Session to the home screen of their Android tablet, probably following the “add to home screen” prompt. I recently added some code to use the
window.beforeinstallprompt event so that the “add to home screen” prompt would only be shown to visitors who sign up or log in to The Session—a good indicator of engagement, I reckon, and it should reduce the chance of the prompt being dismissed out of hand.
So this person added The Session to their home screen—probably as a result of being prompted—and then used it just like any other app. At some point, they didn’t even remember how the app got installed:
Success! I did it. Thanks. My problem was I was looking for an app to download.
On the one hand, this is kind of great: here’s an example where, in the user’s mind, there’s literally no difference between the experience of using a progressive web app and using a native app. Win!
But on the other hand, the expectation is still that apps are to be found in an app store, not on the web. This expectation is something I wrote about recently (and Justin wrote a response to that post). I finished by saying:
Perhaps the inertia we think we’re battling against isn’t such a problem as long as we give people a fast, reliable, engaging experience.
When this member of The Session said “My problem was I was looking for an app to download”, I responded by saying:
Well, I take that as a compliment—the fact that once the site is added to your home screen, it feels just like a native app. :-)
And they said:
Yes, it does!
Tuesday, July 10th, 2018
Twitter and Instagram progressive web apps
The two major candidates are Twitter and Instagram. I added them to my home screen, and banished the native apps off to a separate screen. I’ve been using both progressive web apps for a few months now, and I have to say, they’re pretty darn great.
There are a few limitations compared to the native apps. On Twitter, if you follow a link from a tweet, it pops open in Safari, which is fine, but when you return to Twitter, it loads anew. This isn’t any fault of Twitter—this is the way that web apps have worked on iOS ever since they introduced their weird
web-app-capable meta element. I hope this behaviour will be fixed in a future update.
Also, until we get web notifications on iOS, I need to keep the Twitter native app around if I want to be notified of a direct message (the only notification I allow).
Apart from those two little issues though, Twitter Lite is on par with the native app.
Instagram is also pretty great. It too suffers from some navigation issues. If I click through to someone’s profile, and then return to the main feed, it also loads it anew, losing my place. It would be great if this could be fixed.
For some reason, the Instagram web app doesn’t allow uploading multiple photos …which is weird, because I can upload multiple photos on my own site by adding the
multiple attribute to the
input type="file" in my posting interface.
Apart from that, though, it works great. And as I never wanted notifications from Instagram anyway, the lack of web notifications doesn’t bother me at all. In fact, because the progressive web app doesn’t keep nagging me about enabling notifications, it’s a more pleasant experience overall.
Something else that was really annoying with the native app was the preponderance of advertisements. It was really getting out of hand.
Well …(looks around to make sure no one is listening)… don’t tell anyone, but the Instagram progressive web app—i.e. the website—doesn’t have any ads at all!
Here’s hoping it stays that way.
Monday, June 4th, 2018
I was just talking about how browser-based games are the perfect use-case for service workers. Andrzej Mazur breaks down how that would work:
- Add to Home screen
- Offline capabilities
- Progressive loading
Monday, November 6th, 2017
Installing Progressive Web Apps
It used to literally say “add to home screen.”
Now it simply says “add.”
I vaguely remember there being some talk of changing the labelling, but I could’ve sworn it was going to change to “install”. I’ve got to be honest, just having the word “add” doesn’t seem to provide much context. Based on the quick’n’dirty usability testing I did with some co-workers, it just made things confusing. “Add what?” “What am I adding?”
Additionally, the prompt appeared immediately on the first visit to the site. I thought there was supposed to be an added “engagement” metric in order for the prompt to appear; that the user needs to visit the site more than once.
You’d think I’d be happy that users will be presented with the home-screen prompt immediately, but based on the behaviour I saw, I’m not sure it’s a good thing. Here’s what I observed:
- The user types the URL
archive.dconstruct.orginto the address bar.
- The site loads.
- The home-screen prompt slides up from the bottom of the screen.
- The user immediately moves to dismiss the prompt (cue me interjecting “Don’t close that!”).
This behaviour is entirely unsurprising for three reasons:
- We web designers and web developers have trained users to dismiss overlays and pop-ups if they actually want to get to the content. Nobody’s going to bother to actually read the prompt if there’s a 99% chance it’s going to say “Sign up to our newsletter!” or “Take our survey!”.
- Because the prompt now appears on the first visit, no trust has been established between the user and the site. If the prompt only appeared on later visits (or later navigations during the first visit) perhaps it would stand a greater chance of survival.
It’s still possible to add a Progressive Web App to the home screen, but the option to do that is hidden behind the mysterious three-dots-vertically-stacked icon (I propose we call this the shish kebab icon to distinguish it from the equally impenetrable hamburger icon).
I was chatting with Andreas from Mozilla at the View Source conference last week, and he was filling me in on how Firefox on Android does the add-to-homescreen flow. Instead of a one-time prompt, they’ve added a persistent icon above the “line of death” (the icon is a combination of a house and a plus symbol).
When a Firefox 58 user arrives on a website that is served over HTTPS and has a valid manifest, a subtle badge will appear in the address bar: when tapped, an “Add to Home screen” confirmation dialog will slide in, through which the web app can be added to the Android home screen.
This kind of badging also has issues (without the explicit text “add to home screen”, the user doesn’t know what the icon does), but I think a more persistently visible option like this works better than the a one-time prompt.
Firefox is following the lead of the badging approach pioneered by the Samsung Internet browser. It provides a plus symbol that, when pressed, reveals the options to add to home screen or simply bookmark.
I don’t think Chrome for Android has any plans for this kind of badging, but they are working on letting the site authors provide their own prompts. I’m not sure this is such a good idea, given our history of abusing pop-ups and overlays.
Sadly, I feel that any solution that relies on an unrequested overlay is doomed. That’s on us. The way we’ve turned browsing the web—especially on mobile—into a frustrating chore of dismissing unwanted overlays is a classic tragedy of the commons. We blew it. Users don’t trust unrequested overlays, and I can’t blame them.
For what it’s worth, my opinion is that ambient badging is a better user experience than one-time prompts. That opinion is informed by a meagre amount of testing though. I’d love to hear from anyone who’s been doing more detailed usability testing of both approaches. I assume that Google, Mozilla, and Samsung are doing this kind of testing, and it would be really great to see the data from that (hint, hint).
But it might well be that ambient badging is just too subtle to even be noticed by the user.
On one end of the scale you’ve got the intrusiveness of an add-to-home-screen prompt, but on the other end of the scale you’ve got the discoverability problem of a subtle badge icon. I wonder if there might be a compromise solution—maybe a badge icon that pulses or glows on the first or second visit?
Of course that would also need to be thoroughly tested.
Friday, July 14th, 2017
The slides from Calum’s presentation about progressive web apps. There are links throughout to some handy resources.
Thursday, December 8th, 2016
Jason talks through the service worker strategy for his company website.
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.
Wednesday, June 22nd, 2016
Tuesday, June 7th, 2016
Smart thinking from Alex on how browsers could better indicate that a website is a progressive web app (and would therefore benefit from being added to the home screen). Ambient badging, he calls it.
Wouldn’t it be great if there were a button in the URL bar that appeared whenever you landed on a PWA that you could always tap to save it to your homescreen? A button that showed up in the top-level UI only when on a PWA? Something that didn’t require digging through menus and guessing about “is this thing going to work well when launched from the homescreen?”
Monday, May 30th, 2016
Regression toward being mean
I highly recommend Remy’s State Of The Gap post—it’s ace. He summarises it like this:
I strongly believe in the concepts behind progressive web apps and even though native hacks (Flash, PhoneGap, etc) will always be ahead, the web, always gets there. Now, today, is an incredibly exciting time to be build on the web.
I agree completely. That might sound odd after I wrote about Regressive Web Apps, but it’s precisely because I’m so excited by the technologies behind progressive web apps that I think it’s vital that we do them justice. As Remy says:
Without HTTPS and without service workers, you can’t add to homescreen. This is an intentionally high bar of entry with damn good reasons.
When the user installs a PWA, it has to work. It’s our job as web developers to provide the most excellent experience for our users.
It has to work.
That’s why I don’t agree with Dion’s metrics for what makes a progressive web app:
If you deliver an experience that only works on mobile is that a PWA? Yes.
I think it’s important to keep quality control high. Being responsive is literally the first item in the list of qualities that help define what a progressive web app is. That’s why I wrote about “regressive” web apps: sites that are supposed to showcase what we can do but instead take a step backwards into the bad old days of separate sites for separate device classes: washingtonpost.com/pwa, m.flipkart.com, lite.5milesapp.com, app.babe.co.id, m.aliexpress.com.
A lot of people on Twitter misinterpreted my post as saying “the current crop of progressive web apps are missing the mark, therefore progressive web apps suck”. What I was hoping to get across was “the current crop of progressive web apps are missing the mark, so let’s make better ones!”
Now, I totally understand that many of these examples are a first stab, a way of testing the waters. I absolutely want to encourage these first attempts and push them further. But I don’t think that waiving the qualifications for progressive web apps helps achieves that. As much as I want to acknowledge the hard work that people have done to create those device-specific examples, I don’t think we should settle for anything less than high-quality progressive web apps that are as much about the web as they are about apps.
Simply put, in this instance, I don’t think good intentions are enough.
Which brings me to the second part of Regressive Web Apps, the bit about Chrome refusing to show the “add to home screen” prompt for sites that want to have their URL still visible when launched from the home screen.
if you think the URL is going to get killed on my watch then you aren’t paying any attention whatsoever.
so, your choices are to think that I have a secret plan to kill URLs, or conclude I’m still Team Web.
I’m galled that anyone, particularly you @adactio, would think the former…but contrarianism uber alles?
I am very, very sorry that I upset Alex like this.
But I stand by my criticism of the actions of the Chrome team. Because good intentions are not enough.
I know that Alex is huge fan of URLs, and of the web. Heck, just about everybody I know that works on Chrome in some capacity are working for the web first and foremost: Alex, Jake, various and sundry Pauls. But that doesn’t mean I’m going to stay quiet when I see the Chrome team do something I think is bad for the web. If anything, it’s precisely because I hold them to a high standard that I’m going to sound the alarm when I see what I consider to be missteps.
I think that good people can make bad decisions with the best of intentions. Usually it involves long-term thinking—something I think is very important. “The ends justify the means” is a way of thinking that can create a lot of immediate pain, even if it means a better future overall. Balancing those concerns is front and centre of the Chromium project:
As browser implementers, we find that there’s often tension between (a) moving the web forward and (b) preserving compatibility. On one hand, the web platform API surface must evolve to stay relevant. On the other hand, the web’s primary strength is its reach, which is largely a function of interoperability.
For example, when Alex talks of the Web Component era as though it were an inevitability, I get nervous. Not for myself, but for the millions of Opera Mini users out there. How do we get to a better future without leaving anyone behind? Or do we sacrifice those people for the greater good? Do the needs of the many outweigh the needs of the few? Do the ends justify the means?
I hope not. I hope we can find ways to have our accessible cake and eat it too. But it will be really, really hard.
Returning to progressive web apps, I was genuinely shocked and appalled at the way that the Chrome team altered the criteria for the “add to home screen” prompt to discourage exposing URLs. I was also surprised at how badly the change was communicated—it was buried in a bug report that five people contributed to before pushing the change. I only found out about it through a conversation with Paul Kinlan. Paul encouraged me to give feedback, and that’s what I did on my website, just like Stuart did on his.
Of course the Chrome team are working on ways of exposing URLs within progressive web apps that are launched in from the home screen. Opera are working on it too. But it’s a really tricky problem to solve. It’s not enough to say “we’ll figure it out”. It’s not enough to say “trust us.”
I do trust the people I know working on Chrome. I also trust the people I know at Mozilla, Opera and Microsoft. That doesn’t mean I’m going to let their actions go unquestioned. Good intentions are not enough.
As Alex readily acknowledges, the harder problem (figuring out how to expose URLs) should have been solved first—then the change to the “add to home screen” metrics would be uncontentious. Putting the cart before the horse, discouraging
display:browser now, while saying “trust us, we’ll figure it out”, is another example of saying the ends justify the means.
But the stakes are too high here to let this pass. Good intentions are not enough. Knowing that the people working on Chrome (or Firefox, or Opera, or Edge) are good people is not reason enough to passively accept every decision they make.
Alex called me out for not getting in touch with him directly about the Chrome team’s future plans with URLs, but again, that kind of rough consensus to do something is trumped by running code. Also, I did talk to Chrome people—this all came out of a discussion with Paul Kinlan. I don’t know who’s who in the company’s political hierarchy and I don’t think I should need an org chart to give feedback to Google (or Mozilla, or Opera, or Microsoft).
You’ll notice that I didn’t include Apple there. I don’t hold them to the same high standard. As it turns out, I know some very good people at Apple working on WebKit and Safari. As individuals, they care about the web. But as a company, Apple has shown indifference towards web developers. As Remy put it:
Even getting the hint of interest from Apple is a process of dumpster-diving the mailing lists scanning for the smallest hint of interest.
With that in mind, I completely understand Alex’s frustration with my post on “regressive” web apps. Although I intended it as a push towards making better progressive web apps, I can see how it could be taken as confirmation by those who think that progressive web apps aren’t worth investing in. Apple, for example. As it is, they’ll have to be carried kicking and screaming into adding support for Service Workers, manifest files, and other building blocks. From the reaction to my post from at least one WebKit developer on Twitter, not only did I fail to get across just how important the technologies behind progressive web apps are, I may have done more harm than good, giving ammunition to sceptics.
Still, I hope that most people took my words in the right spirit, like Addy:
We should push them to do much better. I’ll file bugs. Per @adactio post, can’t forget the ‘Progressive’ part of PWAs
Seeing that reaction makes me feel good …but seeing Alex’s reaction makes me feel bad. Very bad. I’m genuinely sorry that I made Alex feel that way. It wasn’t my intention but, well …good intentions are not enough.
I’ve been looking back at what I wrote, trying to see it through Alex’s eyes, looking for the parts that could be taken as a personal attack:
Chrome developers have decided that displaying URLs is not “best practice” … To declare that all users of all websites will be confused by seeing a URL is so presumptuous and arrogant that it beggars belief. … Withholding the “add to home screen” prompt like that has a whiff of blackmail about it. … This isn’t the first time that Chrome developers have made a move against the address bar. It’s starting to grind me down.
Some pretty strong words there. I stand by them, but the tone is definitely strident.
When we criticise something—a piece of software, a book, a website, a film, a piece of music—it’s all too easy to forget that there are real people behind it. But that isn’t the case here. I know that there are real people working on Chrome, because I know quite a few of those people. I also know that their intentions are good. That’s not a reason for me to remain silent—that’s a reason for me to speak up.
If I had known that my post was going to upset Alex, would I have still written it? That’s a tough one. On the one hand, this is a topic I care passionately about. I think it’s vital that we don’t compromise on the very things that make the web great. On the other hand, who knows if what I wrote will make the slightest bit of difference? In which case, I got the catharsis of getting it off my chest but at the price of upsetting somebody I respect. That price feels too high.
I love the fact that I can publish whatever I want on my own website. It can be a place for me to be enthusiastic about things that excite me, and a place for me to rant about things that upset me. I estimate that the enthusiastic stuff outnumbers the ranty stuff by about ten to one, but negativity casts a disproportionately large shadow.
I need to get better at tempering my words. Not that I’m going to stop criticising bad decisions when I see them, but I need to make my intentions clearer …because just having good intentions is not enough. Throughout this post, I’ve mentioned repeatedly how much I respect the people I know working on the Chrome team. I should have said that in my original post.
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.