This looks interesting—a new book by Dean Hume all about progressive web apps. A few chapters are available to download.
Thursday, December 14th, 2017
Friday, December 1st, 2017
24 Ways is back! Yay! This year’s edition kicks off with a great article by Hui Jing on using
Chances are, the latest features will not ship across all browsers at the same time. But you know what? That’s perfectly fine. If we accept this as a feature of the web, instead of a bug, we’ve just opened up a lot more web design possibilities.
Tuesday, November 28th, 2017
In which Brian takes a long winding route through an explanation of why the
is attribute for custom elements is dead before he demonstrates the correct way to use web components:
<!-- instead of writing this --> <input type="radio" is="x-radio"> <!-- you write this --> <x-radio> <input type="radio"> </x-radio>
Sadly, none of the showcase examples I’ve seen for web components do this.
Thursday, November 23rd, 2017
Here’s a nice one-sentence definition for the marketing folk:
A Progressive Web App is a regular website following a progressive enhancement strategy to deliver native-like user experiences by using modern Web standards.
But if you’re talking to developers, I implore you to concretely define a Progressive Web App as the combination of HTTPS, a service worker, and a Web App Manifest.
Wednesday, November 15th, 2017
What is a Progressive Web App?
It seems like any new field goes through an inevitable growth spurt that involves “defining the damn thing.” For the first few years of the IA Summit, every second presentation seemed to be about defining what Information Architecture actually is. See also: UX. See also: Content Strategy.
Now it seems to be happening with Progressive Web Apps …which is odd, considering the damn thing is defined damn well.
Regardless of the specifics of the name, what I like about Progressive Web Apps is that they have a clear definition. It reminds me of Responsive Web Design. Whatever you think of that name, it comes with a clear list of requirements:
- A fluid layout,
- Fluid images, and
- Media queries.
Likewise, Progressive Web Apps consist of:
- A service worker, and
- A Web App Manifest.
There’s more you can do in addition to that (just as there’s plenty more you can do on a responsive site), but the core definition is nice and clear.
Except, for some reason, that clarity is being lost.
Here’s a post by Ben Halpern called What the heck is a “Progressive Web App”? Seriously.
I have a really hard time describing what a progressive web app actually is.
He points to Google’s intro to Progressive Web Apps:
Progressive Web Apps are user experiences that have the reach of the web, and are:
- Reliable - Load instantly and never show the downasaur, even in uncertain network conditions.
- Fast - Respond quickly to user interactions with silky smooth animations and no janky scrolling.
- Engaging - Feel like a natural app on the device, with an immersive user experience.
Those are great descriptions of the benefits of Progressive Web Apps. Perfect material for convincing your clients or your boss. But that appears on
developers.google.com …surely it would be more beneficial for that audience to know the technologies that comprise Progressive Web Apps?
Ben Halpern again:
Google’s continued use of the term “quality” in describing things leaves me with a ton of confusion. It really seems like they want PWA to be a general term that doesn’t imply any particular implementation, and have it be focused around the user experience, but all I see over the web is confusion as to what they mean by these things. My website is already “engaging” and “immersive”, does that mean it’s a PWA?
I think it’s important to use the right language for the right audience.
If you’re talking to the business people, tell them about the return on investment you get from Progressive Web Apps.
If you’re talking to the marketing people, tell them about the experiential benefits of Progressive Web Apps.
But if you’re talking to developers, tell them that a Progressive Web App is a website served over HTTPS with a service worker and manifest file.
Tuesday, November 7th, 2017
The latest edition of Heydon’s Inclusive Components is absolutely fantastic! The pattern itself—toggling sections of content—is quite straightforward, but then there’s a masterclass in how to create a web component that still allows the content to be accessible in older browsers. The key, as ever, is progressive enhancement:
Whether implemented through web components or not, progressive enhancement not only ensures the interface is well-structured and robust. As we’ve seen here, it can also simplify the editorial process. This makes developing the application and its content more inclusive.
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.
Tuesday, October 31st, 2017
A great bucketload of common sense from Jake:
Rather than copying bad examples from the history of native apps, where everything is delivered in one big lump, we should be doing a little with a little, then getting a little more and doing a little more, repeating until complete. Think about the things users are going to do when they first arrive, and deliver that. Especially consider those most-likely to arrive with empty caches.
And here’s a good way of thinking about that:
I’m a fan of progressive enhancement as it puts you in this mindset. Continually do as much as you can with what you’ve got.
All too often, saying “use the right tool for the job” is interpreted as “don’t use that tool!” but as Jake reminds us, the sign of a really good tool is its ability to adapt instead of demanding rigid usage:
Netflix uses React on the client and server, but they identified that the client-side portion wasn’t needed for the first interaction, so they leaned on what the browser can already do, and deferred client-side React. The story isn’t that they’re abandoning React, it’s that they’re able to defer it on the client until it’s was needed. React folks should be championing this as a feature.
Sunday, October 22nd, 2017
Pattern Libraries, Performance, and Progressive Web Apps
Ever since its founding in 2005, Clearleft has been laser-focused on user experience design.
Recently we’ve been doing a lot of strategic design work—the really in-depth long-term engagements that begin with research and continue through to design consultancy and collaboration. That means we’ve got availability for front-end development work. Whether it’s consultancy or production work you’re looking for, this could be a good opportunity for us to work together.
There are three particular areas of front-end expertise we’re obsessed with…
We caught the design systems bug years ago, way back when Natalie started pioneering pattern libraries as our primary deliverable (or pattern portfolios, as we called them then). This approach has proven effective time and time again. We’ve spent years now refining our workflow and thinking around modular design. Fractal is the natural expression of this obsession. Danielle and Mark have been working flat-out on version 2. They’re very eager to share everything they’ve learned along the way …and help others put together solid pattern libraries.
Thinking about it, it’s no surprise that we’re crazy about performance at Clearleft. Like I said, our focus on user experience, and when it comes to user experience on the web, nothing but nothing is more important than performance. The good news is that the majority of performance fixes can be done on the front end—images, scripts, fonts …it’s remarkable how much a good front-end overhaul can make to the bottom line. That’s what Graham has been obsessing over.
Progressive Web Apps
Over the years I’ve found myself getting swept up in exciting new technologies on the web. When Clearleft first formed, my head was deep into DOM Scripting and Ajax. Half a decade later it was HTML5. Now it’s service workers. I honestly think it’s a technology that could be as revolutionary as Ajax or HTML5 (maybe I should write a book to that effect).
I’ve been talking about service workers at conferences this year, and I can’t hide my excitement:
There’s endless possibilities of what you can do with this technology. It’s very powerful.
Combine a service worker with a web app manifest and you’ve got yourself a Progressive Web App. It’s not just a great marketing term—it’s an opportunity for the web to truly excel at delivering the kind of user experiences previously only associated with native apps.
I’m very very keen to work with companies and organisations that want to harness the power of service workers and Progressive Web Apps. If that’s you, get in touch.
Whether it’s pattern libraries, performance, or Progressive Web Apps, we’ve got the skills and expertise to share with you.
Thursday, October 19th, 2017
The end result is really impressive but there’s still the drawback that the browser history will be updated every time you click on an image thumbnail (because the functionality relies on
ID attributes referenced via
:target). Depending on your use-case, that may or may not be desirable.
Monday, September 25th, 2017
It looks like this is landing in Chrome. The
navigator.connection.type property will allow us to progressively enhance based on connection type:
A web application that makes use of a service worker to cache resources during installation might have different bundles of assets that it might cache: a list of crucial assets that are cached unconditionally, and a bundle of larger, optional assets that are only cached ahead of time when
There are potential security issues around fingerprinting that are addressed in this document.
Saturday, September 23rd, 2017
There’s a lot of misinformation on the internet as to how to build a PWA and how “appy” and SPA-y one must be.
This simply isn’t true. Disappointingly, It is what most of the documentation, blog posts and public discourse seem to imply.
I’m so, so happy to see some pushback against the misinformation that progressive web apps automatically imply client-side rendered single page apps built from scratch. There’s so much value to be had in turbo-charging an existing site into a progressive web app.
But what we don’t need is yet another TLA like Alien Web Apps.
Friday, September 22nd, 2017
You can use
navigator.storage.estimate() to get a (vague) idea of how much space is available on a device for your service worker caches.
Tuesday, September 19th, 2017
Two of my favourite things together at last: pattern libraries and service workers. Infusion is a tool for generating pattern libraries that also work offline.
Thinking about it, it makes total sense that a pattern library should be a progressive web app.
Sunday, September 17th, 2017
There are some great service worker optimisation tips in these slides.
Thursday, September 14th, 2017
A really nice example of progressive enhancement: creating a layout with
inline-block, then flexbox, then Grid.
Monday, September 11th, 2017
Along the lines of John’s recent post, Henrik makes the business case for progressive web apps.
He also points out how they can be much better than native apps for controlling hardware.
They can be up and running in a fraction of the time whether or not they were already “installed” and unlike “apps” can be saved as an app on the device at the user’s discretion!
Essentially they’re really great for creating “ad hoc” experiences that can be “cold started” on a whim nearly as fast as if it were already installed.
Friday, September 8th, 2017
John makes the point that unless you’re one of the big, big players, your native app is really going to struggle to find an audience. But that’s okay—a progressive web app might be exactly what you need.
In short, using native apps as a path to reaching a large number of potential customers and benefitting from crucial network effects is close to impossible.
But, in the meantime, the Web has responded to the very significant impact that native apps had on user behaviour.
For me, the strength of the web has never been about how it can help big companies—it’s about how it can amplify and connect the niche players.
Friday, September 1st, 2017
Manifest files can have categories now. Time to update those JSON files.
A fantastic piece by Aaron who—once again—articulates what I’ve been thinking:
Your site—every site—should be a PWA.
He clearly explains the building blocks of progressive web apps—HTTPS, a manifest file, and a service worker—before describing different scenarios for different kinds of sites:
Progressive Web Apps may seem overly technical or beyond the needs of your project, but they’re really not. They’re just a shorthand for quality web experiences—experiences that can absolutely make a difference in our users’ lives.