A good introduction to custom elements, one piece of the web components stack.
Jason breaks down the myths of inputs being tied to device form factors. Instead, given the inherent uncertainty around input, the only sensible approach is progressive enhancement.
Now is the time to experiment with new forms of web input. The key is to build a baseline input experience that works everywhere and then progressively enhance to take advantage of new capabilities of devices if they are available.
Andrew picks out his favourite bits from this year’s Google I/O, covering web payments, CSS containment, and—of course—Service Workers and progressive web apps, although he does note (and I concur):
I wish Google would focus as much attention on ‘normal’ sites that perform navigations as they do on so called ‘app-shell’ (which is just a new name for single-page apps, as far as I can tell), but then many people will be building SPAs and these recipes will make those apps fly. In news publishing we seem to flip flop between traditional page navigations and SPAs, but I’ve never found a SPA news site (or a native app) that I really like more than a normal website. Maybe a really good progressive web app will change that. But I’m not convinced.
Still, as he says:
All this really just underscores how flexible ServiceWorker is and that with it we can disagree on what the right solution is, but we can all get what we want anyway.
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)
The roadmap for progressive web apps from Microsoft; not just their support plans, but also some ideas for distribution.
I really, really like what Ember is aiming for here:
That’s how you get the holy grail of resilience and performance:
Subsequent visits and interactions are therefore nearly instantaneous, because they don’t rely on the network.
I sincerely hope other frameworks are paying attention to this layered approach.
Oh, and I also like this observation:
There’s an age-old argument about the difference between “web pages” and “web apps”. In reality, there’s a continuum between the two.
One way of implementing the growing/shrinking navigation pattern—an alternative to just shoving everything behind a hamburger icon.
Hidde’s write-up of the Progressive Web App Dev Summit:
It was exciting to hear about the technologies, and to see that a lot of them already work on a great deal of platforms. Most of the major browser vendors expressed how much they liked the idea, so it is realistic to say support will increase in the short term. This, and the fact that all PWA techniques can be regarded as a ‘progressive enhancement’ (with some leniency as to what that term means), entails that we can build Progressive Web Apps today.
Hopefully, we will do so responsibly. Native apps really only work on their particular platforms. PWAs, in theory, can be built to work universally. For everyone with a web enabled device. This is awesome! Major browser vendors are behind the idea, and I think as developers we should be, too.
Cameron looks back on his 2007 Mobile Web Design book:
I don’t anticipate native apps will die off anytime soon. But I’m warming to the idea that they may be less relevant to the future of the web, and I reaffirm that “a browser will be — or should be — sufficient for interacting with web content.”
Progressive web apps are poised to be remarkably relevant to the future of the web. Let’s not screw it up.
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.
This beautiful poster could be the ideal decoration for your home or office.
You can download the original size (DIN A3) and print it to hang it on the walls in your office or wherever you want.
I love the thinking that Scott puts into all aspects of building on the web. Here, he outlines a really robust approach to cutting the mustard for progressive enhancement.
A good impartial overview of progressive web apps, as described at the most recent Google I/O. This is very telling:
The term also begs the question; what is the difference between websites and apps? It seems many of the new capabilities fit well for any dynamic website, not just apps.
Anyhow. It’s good to have an umbrella term to talk about these things.
Google have asked me to moderate a panel on the second day of this event in Amsterdam dedicated to progressive web apps. Very brave of them, considering some of my recent posts.
Progressive web apps – let’s not repeat the errors from the beginning of responsive web design | justmarkup
Those who cannot remember the past are doomed to repeat it:
When people learned about responsive design, there were many wrong assumptions. The iPhone and early Android phones all had the same screen size (320x480px) and people thought it is a good idea to change the design based on these device-specific sizes.
We wouldn’t do that now, right? We wouldn’t attempt to create something that’s supposed to be a progressive web app, only to make it device-specific, right?
We are still at the beginning of learning about the best ways to build Progressive Web Apps. I hope it will make many more people aware of progressive enhancement. I hope that nobody makes the error again and concentrates on the device part.
Stuart’s ideas for Lighthouse sound a lot like the resilience validator tool that Scott mentioned recently.
This is our chance to help stamp out sites that don’t do things right, and help define that a progressive web app should actually be progressive.
If you have ideas on this, please file an issue.
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?”
I agree with everything Andrew says here. Progressive web apps are great, but as long as Google heap praise on mobile-only solutions (like the Washington Post doorslam) and also encourage separate AMP sites, they’re doing a great disservice to the web.
More features arrive regularly to make this “one web” even better and easier to maintain. Service worker, streams, app manifests, payment request, to name a few. But adding these features one at a time to large, mature applications like WaPo or FT or Nikkei is a slow and painstaking process. That’s why it’s taking us a long time for us to tick off all these new features, and why it seems like madness to try and build the entire app several times over.
However, by creating the concept of PWAs and marketing them as they do, Google is encouraging publishers to ‘start again’. And they’re doing exactly the same thing with AMP.
Dave turned Day Trip into a progressive web app.
Starting this week, Android users (~13% of our active user base) who use DayTrip more than once will eventually be asked if they want to install our web app to their Home Screen. That’s important real estate for a small startup like ourselves.
In the web developer community’s collective drive to be more App Like and compete with native apps we may lose or weaken some of the web’s strongest features and we need to consider carefully before we throw away urls or the entire browser chrome in an effort to look like and behave like the cool kids of native.
Y’know, I think PPK might be on to something here. It’s certainly true that developers have such an eversion to solving a problem twice that some users end up paying the cost (like in the examples of progressive enhancement here).
I will be pondering upon this.
Turbolinks intercepts all clicks on
a hreflinks to the same domain. When you click an eligible link, Turbolinks prevents the browser from following it. Instead, Turbolinks changes the browser’s URL using the History API, requests the new page using
XMLHttpRequest, and then renders the HTML response.
During rendering, Turbolinks replaces the current
bodyelement outright and merges the contents of the
documentobjects, and the HTML
htmlelement, persist from one rendering to the next.
Here’s the mustard it’s cutting:
It depends on the HTML5 History API and Window.requestAnimationFrame. In unsupported browsers, Turbolinks gracefully degrades to standard navigation.
This approach matches my own mental model for building on the web—I might try playing around with this on some of my projects.
So remember when I was talking about “the ends justify the means” being used for unwise short-term decisions? Here’s a classic example. Chris thinks that Progressive Web Apps should be made mobile-only (at least to start with …something something something the future):
For now, PWAs need to be the solution for the next mobile users.
End users deserve to have an amazing, form-factor specific experience.
I couldn’t disagree more. End users deserve to have an amazing experience no matter the form-factor of their device.
A heartfelt call to web developers to consider the needs of the many and varied people trying to use what we build.
It is about making products that serve all users equally. It is about putting ourselves in others’ shoes. It is about trying to imagine the frustration and difficulty of using our products when the conditions aren’t what we’re used to. It is about being human.
A typically superb article by Aaron. Here, he breaks down a resilient approach to building for the web by examining the multiple ways you could add a button to a page. There’s a larger lesson here too:
We don’t control where our web-based products go or how our users access them. All we can do is imagine as many less-than-perfect scenarios as possible and do our best to ensure our creations will continue to do what they’re supposed to do. One of the easiest ways to do that is to be aware of and limit our dependencies.
Download it now and watch this space for more titles around building inclusive web apps, collaboration, and maintaining privacy and security.
Did I mention that it’s free?
Here’s the video of the talk I just gave at the Beyond Tellerrand conference in Düsseldorf: Resilience.
Eric asked me some questions and I was only too happy to give some answers.
While many challenges remain, the good news is … it’s progressive. Developers can already see the benefits by sprinkling in these technologies to their existing websites and proceed to build on them as browsers and operating systems increase support.
Here’s an interesting proposal from ppk: use
requestAnimationFrame to gauge how performant a browser in behaving and then enhance accordingly.
I’m so happy that Ember is moving to a server-side rendering model. Not only that, but as Tom points out here, it’s crucial that the server-side rendering is the default and the client-side functionality than becomes an enhancement.
Well, I’m convinced.
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.
I don’t care about Opera Mini (I’m not its Product Manager). In the same way, I don’t care about walking sticks, wheelchairs, mobility scooters or guide dogs. But I care deeply about people who use enabling technologies — and Opera Mini is an enabling technology. It allows people on feature phones, low-powered smartphones, people in low-bandwidth areas, people with very small data plans, people who are roaming (you?) connect to the web.
Here’s a bit of convergent evolution: Hugo’s script is similar to what I wrote about recently.
He also raises a point that Kevin mentioned:
I would like to investigate on the
summaryelements as they are basically a native implementation for content toggles.
For some reason
details never got much browser love, even though it’s clearly paving a well-trodden cowpath.
A lovely outlook on designing with progressive enhancement:
There will always be users coming from places you didn’t expect, using devices you didn’t test for.
Come for the videos of EnhanceConf. Stay for the skateboarding beagle.
Making web apps? Care about SEO? Here’s Google’s advice:
Use feature detection & progressive enhancement techniques to make your content available to all users.
If you’re going to override or reimplement something that already exists, do some research on what the existing thing does first. You cannot possibly craft a good replacement without understanding the original.
Remember that for all the power the web affords you, the control is still ultimately in end user’s hands.
The full text of Adam’s excellent talk at EnhanceConf.
The videos from EnhanceConf are started to go up already. Stefan’s talk really struck me—all the talks were great but this one had the most unexpected insight for me. It really clarifies a lot of ideas that I’ve been trying to articulate, but which Stefan crystalises by taking the long-zoom view.
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.
A wonderfully thoughtful piece on typography, Jan Tschichold and the web. This really resonated with me:
It’s only been over the past year or so in which I’ve recognised myself as a ‘Web designer’ with a capital W, as I now believe that something happens to information and technology, and even typography itself, when people pass through these interconnected networks and interact with hypertext.
It’s for these reasons that I don’t believe in “digital design” or “designing for screens” and it’s why I’m often attracted to one particular side of this spectrum.
Robin proposes three “principles, suggestions, outlines, or rather things-that-I-ought-to-be nervous-about when setting text on the web”:
- We must prioritise the text over the font, or semantics over style.
- We ought to use and/or make tools that reveal the consequences of typographic decisions.
- We should acknowledge that web typography is only as strong as its weakest point.
There’s an in-depth look at applying progressive enhancement to web type, and every single link in the resources section at the end is worth investigating.
Oh, and of course it’s beautifully typeset.
Related: this great chat between Jen Simmons and Stephanie Rieger.
Aaron interviews Simon who’s organising the upcoming EnhanceConf which is going to be ruddy good.
I love this little markup pattern: simple, accessible and elegant …with some quirky CSS gotchas around styling non-standard prefixed pseudo-elements. They came from the Shadow DOM …dun dun DUN!
A great description of a solid architectural approach to building on the web (and not just for accessibility either).
A larger screen is now a progressive enhancement. Hell, with things like Siri and Google Now and Amazon’s Echo, we’re getting to the point where even a screen is an enhancement.
A response to a rant I linked to recently.
I couldn’t agree more. The tools have evolved and we now have frameworks and practices that allow us to render from the server and use the same code to render on the client, progressively enhancing from a solid robust base.
The problem is that I don’t see a willingness from developers to embrace this way of thinking. Instead I see it dismissed as being unrealistic or more expensive.
Still, it always takes time for behaviour to change so maybe things will only get better. I certainly hope so.
This a magnificent piece of writing from James …all about pieces of metal fabric.
A single technology – the vacuum-deposition of metal vapour onto a thin film substrate – makes its consecutive and multiple appearances at times of stress and trial: at the dawn of the space age, in orbit and on other planets, at the scene of athletic feats of endurance, in defence and offence in the mountains of the Hindu Kush, on the beaches of the European archipelago. These are moments of hope as well as failure; moments when, properly utilised, technological progress enables us to achieve something which was beyond our capabilities before. And yet: we are still pulling bodies from the water wrapped in material which was meant to send us into space.
A great piece by Christian on taking a responsible, customer-focused approach to building on the web.
You don’t have to support old browsers and terrible setups. But you are not allowed to block them out. It is a simple matter of giving a usable interface to end users. A button that does nothing when you click it is not a good experience. Test if the functionality is available, then create or show the button.
A linkbaity title for a ranty post. But it’s justified.
My point is that from an architectural perspective, most single page apps are the result of making the wrong choices and missing important opportunities.
I think that “Do we want to support users without JS?” is the wrong question. Progressive enhancement has benefits that reach far beyond that user group.
- Resilience—”If users can perform critical tasks when your JS breaks, it’s a minor inconvenience instead of a show stopper.”
- Business, Business, Business.
Matthew describes a very nice bit of progressive enhancement for drag’n’drop file uploads (similar to the CSS Tricks article I linked to recently).
It uses the Dropzone JS which looks like it aligns nicely with the progressive enhancement approach.
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.
Ethan demonstrates progressive enhancement at the pattern level using flexbox.
I’ve found that thinking about my design as existing in broad experience tiers – in layers – is one of the best ways of designing for the modern web.
Two sides of a debate on progressive enhancement…
Andrey “Rarst” Savchenko wrote Progressive enhancement — JS sites that work:
Joe Hoyle disagrees:
Caspar acknowledges this:
I don’t have any problem buying into pragmatism as the main and often pressing reason for not investing into a no-JS fallback. The idealistic nature of a design directive like progressive enhancement is very clear to me, and so are typical restrictions in client projects (budgets, deadlines, processes of decision making).
But concludes that by itself that’s not enough reason to ditch such a fundamental technique for building a universal, accessible web:
Ain’t nobody got time for progressive enhancement always, maybe. But entirely ditching principle as a compass for resilient decision making won’t do.
It would be convenient to think that because we live in a world where people’s browsers are regularly updating, that we live in a world where the web is in a reliable state.
The web is a continually moving target. It probably changed in the time it took me to write this. If you work with web stuff you need to embrace this fact. It will be the only constant in your career.
Do not panic:
On the web progressive enhancement is and will always be, the methodology of choice. It makes your site robust to the shifting sands of the web front end.
I have no hands-on experience with React, but this tutorial by Jack Franklin looks like a great place to start. Before the tutorial begins he succinctly and clearly outlines the perfect architecture for building on the web today:
- The next time a user clicks, rather than being sent to the server, the client-side app is in control.
Y’know, I had a chance to chat briefly with Jack at the Edge conference in London and I congratulated him on the launch of a Go Cardless site that used exactly this technique. He told me that the decision to flip the switch and make it act as a single page app came right at the end of the project. I think that points to a crucial mindset that’s reiterated here:
A rousing call to arms for progressive enhancement. I agree with the sentiment, but I’m less comfortable making assumptions about the reasons why developers don’t use progressive enhancement:
However, what’s actually happening is that “universal access to content” is being subversively replaced with “universal access for a limited subset of users that I care about”.
I particularly like the point in here about content blockers like NoScript:
In fact, it’s probably more likely that a user will try browsing the Web today without scripting than at any other time since the 1990s.
This is a terrific example of progressive enhancement in action: going from a simple file input to a lovely interactive drag’n’drop interface.
Apple offers its users the power to turn off much of the Web: fonts, styles, scripts, and more.
He rightly points out that the answer to building a robust, resilient web has been here all along:
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”
Outlining the architectural thinking required to create what the Google devrel folks are calling progressive apps.
Browsers without service worker support should always be served a fall-back experience. In our demo, we fall back to basic static server-side rendering…
…but this is only one of many options.
Hmmm. In my opinion, sending usable HTML on first request isn’t an implementation detail—it’s crucial. But on the whole, this approach is very sensible indeed.
Paul gives the lowdown on the Google+ responsive relaunch. They set themselves this performance budget:
- 60K of HTML,
- 60K of CSS,
- 60 frames per second animations, and
- 0.6 seconds latency.
And this bit is crucial:
Are we doomed to see history repeat itself? With the amount of client-side MVC frameworks and the upcoming implementation of the ES6 syntax, will we soon be seeing a repeat of the “browser wars.” Will more websites only work in a select number of browsers with the capabilities to run their code?
The full transcript of Scott’s excellent presentation on performance and progressive enhancement.
There’s going to be a conference about progressive enhancement. It’ll happen in London in March of next year. You should speak at it.
You’ve got until December 20th to submit your proposal. What have you got to lose?
It’s official: hash bang URLs are an anti-pattern, and if you want your content indexed by Google, use progressive enhancement:
Since the assumptions for our 2009 proposal are no longer valid, we recommend following the principles of progressive enhancement.
Here’s the 20 minute talk I gave at the inaugural Responsive Field Day in Portland.
Websites should not come with minimum software requirements.
Here’s the video of the talk I gave at An Event Apart last year.
Guess what it’s about. Go on, guess!
No! It’s about progressive enha… oh.
Aaron collects some recent examples that demonstrate
- why we should use HTTPS and
- why we should use progressive enhancement.
The video of my talk at this year’s Beyond Tellerrand. I was pleased with how this went, except for the bit 16 minutes in when I suddenly lost the ability to speak.
What a lovely bit of progressive enhancement—styling data tables to display as charts.
Here’s the video of the panel I participated in at Edge conference, expertly moderated by Lyza.
Thanks to the video editing, you can’t see the face I’m making when the guy from Facebook talks about user-agent sniffing as a totally cool and reliable way of working.
The full text of Jason’s great talk at this year’s CSS Summit. It’s a great read, clearing up many of the misunderstandings around progressive enhancement and showing some practical examples of progressive enhancement working at each level of the web’s technology stack
Many believe we should leave the term “progressive enhancement” behind and start anew, but why not educate developers, clients and stakeholders and change many of the misconceptions surrounding it? Changing the name won’t change anything unless we address the real fundamental problems we have when describing the underlying concepts.
A superb illustration of why playing the numbers game and dismissing even a small percentage of your potential audience could be disastrous.
This is the way to approach building for the web:
I want to make as few of those assumptions as possible. Because every assumption I make introduces fragility. Every assumption introduces another way that my site can break.
It’s progressive enhancement, but like Stuart, Tim is no longer planning to use that term.
Stuart writes up his thoughts on progressive enhancement following the great discussions at Edge Conf:
So I’m not going to be talking about progressive enhancement any more. I’m going to be talking about availability. About reach. About my web apps being for everyone even when the universe tries to stop it.
I really like Alex’s framing of best-of-breed progressively enhanced websites as “progressive apps” (although Bruce has some other ideas about the naming).
It’s a shame that the add-to-homescreen part isn’t standardised yet though.
This sounds like it could be a very useful tool to introduce early in projects to get a shared understanding of progressive enhancement.
Using Progressive Enhancement makes your site better for all users and enables the 275 million users of Opera Mini worldwide.