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.
The system makes the website. Don’t blame the web developer, blame the organisation. A web developer embedded in a large system isn’t the one making the websites.
To make a progressively enhanced website that performs well and loads quickly even on slow connections, you need to first make an organisation that values those qualities over others.
This is a great blow-by-blow account of making an agency website perform better.
I love the side-by-side comparisons with other agencies, including Clearleft—the gauntlet has been thrown down!
Progressive Enhancement remains the best option for solving web development issues such as wide-ranging browser support, maintenance and future-proofing your application.
This Async event at 68 Middle Street on June 11th looks like it’s going to good (and relevant to my interests).
Apps must run on specific platforms for specific devices. The app space, while large, isn’t universal.
Websites can be viewed by anyone with a web browser.
And that doesn’t mean foregoing modern features:
A web browser must only understand HTML. Further, newer HTML (like HTML 5) is still supported because the browser is built to ignore HTML it doesn’t understand. As a result, my site can run on the oldest browsers all the way to the newest ones. Got Lynx? No problem. You’ll still be able to find matches nearby. Got the latest smartphone and plentiful data? It’ll work there, too, and take advantage of its features.
This is why progressive enhancement is so powerful.
My site will take advantage of newer technologies like geolocation and local storage. However, the service will not be dependent on them.
This is a wonderful presentation by Kimberley at O’Reilly’s Fluent Conference, running through the history of the Line Mode Browser and the hack project we worked on at CERN to emulate it.
And that’s why you always use progressive enhancement!
I like this nice straightforward approach. Instead of jumping into the complexities of the final interactive component, Chris starts with the basics and layers on the complexity one step at a time, thereby creating a more robust solution.
If I had one small change to suggest, maybe
aria-label might work better than offscreen text for the controls …as documented by Heydon.
A superb piece by Ross Penman on the importance of being true to the spirit of the web.
The responsive BBC News site is live! Hurrah!
Here’s a look at the highs and lows of the site’s story, emphasising the importance of progressive enhancement and all that enables: feature detection (by “cutting the mustard”), conditional loading, and a mobile-first approach.
Jeffrey muses on progressive enhancement and future-friendliness.
Because in 10 years nothing you built today that depends on JS for the content will be available, visible, or archived anywhere on the web.
It will come as no surprise that I agree with every single word that Tim has written here.
The minimum dependency for a web site should be an internet connection and the ability to parse HTML.
A great description of progressive enhancement.
Progressive enhancement in its basic form means not making assumptions
Smart thinking from Sara on providing a PNG fallback to browsers that don’t support SVG. Although, actually what I like about this solution is that it’s less about providing PNG as a fallback, and more about treating PNG as the baseline and SVG as the enhancement (an approach that the picture element is perfect for).
A nice little pattern for generating a swish timeline in SVG from a plain ol’ definition list in HTML.
You know what? Just go and read everything that Jason writes, okay?
Ruddy good stuff.
The engineering benefits of building websites with a layered approach.
Why, yes, I am talking about progressive enhancement yet again! Why do you ask?
Tom doesn’t mention the phrase “progressive enhancement” once, but that’s okay—his post is still about progressive enhancement.
FastBoot is coming to Ember. That means server-side rendering. And that means progressive enhancement will become a possibility for Ember apps. Exciting!
I really enjoyed chatting with the guys on the The Dirt podcast about progressive enhancement, but my goodness; it certainly sounds like I need to switch to decaf! Yappity-yapity-yap!
This is a talk I gave at An Event Apart about eighteen months ago, all about irish music, the web, long-term thinking, and yes, you guessed it—progressive enhancement.
Rob Larsen was published a book with O’Reilly called “The Uncertain Web: Web Development in a Changing Landscape”. I like it:
A refreshingly honest look at the chaotic, wonderful world of web development, with handy, practical advice for making future-friendly, backward-compatible websites.
I’m not a new developer, but I can definitely relate to this. In fact, when I’ve spoken to any developer about this, it turns out that everyone feels overwhelmed by how much we’re expected to know. That’s not good. We should open up and talk about this more (like Charlotte is doing here).
You can now read Aaron’s excellent book online. I highly recommend reading the first chapter for one of the best descriptions of progressive enhancement that I’ve ever read.
Watch this space.
My contribution to this year’s edition of the web’s best advent calendar.
A superb article by Josh on planning for progressive enhancement—clearly laid out and carefully explained.
Focus on what you want to learn; not what you think you should learn.
There is a lot of pressure out there: to learn new things, to spend all your time coding, to be the super developer. I now believe that to be impossible and unhealthy. It means you aren’t living a balanced life and it also means that you’re living under constant stress and pressure.
Angry, but true.
Don’t lock yourself into a comprehensive technology that may just die within the next few months and leave you stranded. With progressive enhancement you’ll never go wrong. Progressive enhancement means your code will always work, because you’ll always focus on providing a minimal experience first, and then adding features, functionality, and behavior on top of the content.
Tantek shares a fascinating history lesson from Tim Berners-Lee on how the IETF had him change his original nomenclature of UDI—Universal Document Identifier—to what we now use today: URL—Uniform Resource Locator.
I don’t tend to be a “magic pill” kind of believer, but I can honestly say that embracing progressive enhancement can radically change your business for the better. And I’m glad to see Google agrees with me.
Google has updated its advice to people making websites, who might want to have those sites indexed by Google. There are two simple bits of advice: optimise for performance, and use progressive enhancement.
Just like modern browsers, our rendering engine might not support all of the technologies a page uses. Make sure your web design adheres to the principles of progressive enhancement as this helps our systems (and a wider range of browsers) see usable content and basic functionality when certain web design features are not yet supported.
Petra has always been the strong one. She was the best friend that Chloe could have possibly had. Little wonder then that Chloe’s death continues to hit her so hard.
I still can’t fully comprehend it all nor do I have any idea how to learn to move on. All I know is that ever since the day I found out, I’ve been on an emotional rollercoaster. I go from being in shock, to being sad and angry, or completely numb.
Petra is getting help now. That’s good. She’s also writing about what she has been going through. That’s brave. Very brave.
She is one of the best human beings I know.
Patty Toland — Design Consistency For The Responsive Web (Smashing Conference Freiburg 2014) on Vimeo
Patty’s excellent talk on responsive design and progressive enhancement. Stick around for question-and-answer session at the end, wherein I attempt to play hardball, but actually can’t conceal my admiration and the fact that I agree with every single word she said.
Some thoughts on progressive enhancement, although I disagree with the characterisation of progressive enhancement as being the opposite choice to making “something flashy that pushes the web to it’s limits”—it’s entirely possible to make the flashiest, limit-pushing sites using progressive enhancement. After all…
it’s much more a mindset than a particular development technique.
It’s very early days for ServiceWorker, but Jake is on hand with documentation and instructions on its use. To be honest, most of this is over my head and I suspect it won’t really “click” until I try using it for myself.
Where it gets really interesting is in the comments. Stuart asks “What about progressive enhancement?” And Jake points out that because a ServiceWorker won’t be installed on a first visit, you pretty much have to treat it as an enhancement. In fact, you’d have to go out of your way to make it a requirement:
You could, of course, throw up a splash screen and wait for the ServiceWorker to install, creating a ServiceWorker-dependant experience. I will hunt those people down.
I very much agree with Orde’s framing here: I don’t think it makes much sense to talk about “above the fold” CSS …but it makes a lot of sense to talk about critical CSS.
And, yeah, it’s another example of progressive enhancement.
I’m sad about Robin Williams. I was also a little bit angry with him. In much the same way, I was sad about and angry with Chloe Weil when news of her suicide reached me.
Dan Donald gets to the heart of progressive enhancement:
Assumptions in themselves don’t have to be inherently bad but let’s recognise them for what they are. We know very little but that can hopefully enable us to be far more flexible and understanding in what we create.
Almost six minutes of me squinting in the sun and sharing my reckons while seagulls squawk in the background.
I really hope that this is the kind of usage we’ll see for web components: enhancements for the browsers that support them without a good ol’ fashioned fallback for older browsers.
Right now, this move to remove URLs from the interface of Chrome is just an experiment …but the fact that Google are even experimenting with it is very disturbing.
“Who? Me? No, I was never going to actually blow the web’s brains out—I just wanted to feel the heft of the weapon as I stroked it against the face of the web.”
Derek’s excellent advice on avoiding over-reliance on data attributes has this brilliant nugget of insight:
In the web front-end stack — HTML, CSS, JS, and ARIA — if you can solve a problem with a simpler solution lower in the stack, you should. It’s less fragile, more foolproof, and just works
A terrific post from Trent, touching on all the important facets of building for the web: universality, progressive enhancement, performance …great stuff!
Scott writes an absolutely spot-on skewering of the idea that progressive enhancement means you’re going to spend your time catering to older browsers. The opposite is true.
Progressive Enhancement frees us to focus on the costs of building features for modern browsers, without worrying much about leaving anyone out. With a strongly qualified codebase, older browser support comes nearly for free.
The importance of long-term thinking in web design. I love this description of the web:
a truly fluid, chaotic design medium serving millions of imperfect clients
A nice look at responsive design, progressive enhancement, and the principle of One Web.
Like Drew, I’ve noticed some real hostility to the idea of progressive enhancement recently. Like Drew, I don’t really understand where this attitude comes from. It’s not like progressive enhancement prevents you from doing anything you would do otherwise: it’s just another way of approaching the way you build for the web.
I hope I’m wrong, but I suspect that some developers are letting their tools dictate their principles—the tail wagging the dog (where the tail is Angular, Ember, etc.).
Another good ol’ rant from Tom. It’s a bit extreme but the underlying lamentation with the abandonment of progressive enhancement is well founded.
Some excellent practical advice on progressive enhancement.
I really like Scott’s approach to defining what “support” means in terms of browsers—it makes a lot sense to break things down to the component level.
A love letter to HTML, prompted by the line-mode browser hack event at CERN.
A cogent definition and spirited defence of progressive enhancement:
Progressive Enhancement is an extension of our shared values on the web and goes to the root of the web. I believe—and hope you agree—that the web is for everybody and should be accessible regardless of the device a user brings to the party.
Go, Dan, go!
‘Sfunny, I was talking about just this kind of thing at An Event Apart today.
Jason pulls together some of the themes that emerged at An Event Apart DC this week.
Yet another timely reminder from Tim, prompted by the naysayers commenting on his previous excellent post on progressive enhancement, universal access, and the nature of the web.
This a great proposal: well-researched and explained, it tackles the tricky subject of balancing security and access to native APIs.
Far too many ideas around installable websites focus on imitating native behaviour in a cargo-cult kind of way, whereas this acknowledges addressability (with URLs) as a killer feature of the web …a beautiful baby that we definitely don’t want to throw out with the bathwater.
There’s something fundamental and robust about being able to request a URL and get back at least an HTML representation of the resource: human-readable, accessible, fault tolerant.
A terrific case study in progressive enhancement: starting with a good ol’ form that works for everybody and then adding on features like Ajax, SVG, the History API …the sky’s the limit.
A nice description of progressive enhancement by Norm, as applied at GDS.
Some good thinking from Jason here. In a roundabout way, he’s saying that when it comes to responsive images—as with just about every other aspect of web development—the answer is …it depends.
I think it’s a bit of a shame that Brett is canning his mobile-first device-detection library, but I totally understand (and agree with) his reasons.
There is a consensual hallucination in the market, that we can silo devices into set categories like mobile, tablet, and desktop, yet the reality is drawing these lines in the sand is not an easy task.
This off-canvas demo is a great practical example of progressive enhancement from David. It’s also a lesson in why over-reliance on jQuery can sometimes be problematic.
Now this is what I call tech reporting.
The women leave the stage, wet computer in hand, and a new man takes the stage. He plays a schmaltzy video where Portuguese children teach adults to use Windows 8 accompanied by a hyperloud xylophone soundtrack that slices through my hangover like cheesewire though lukewarm gouda.
A really nice explanation by Todd Kloots of Twitter’s use of progressive enhancement with Ajax and the HTML5 History API. There’s even a shout for Hijax in there.
I wholeheartedly agree with Christian’s diagnosis of the average web page: it’s overweight to the point of obesity. Fortunately Dr. Heilmann has some remedies.
Some great thoughts from Mike Davies about the strengths of the web, prompted by some of the more extreme comments made by James Pearce at Full Frontal last week.
I should point out that James was being deliberately provocative in order to foment thought and discussion and, judging from this blog post, he succeeded.
The Web’s independence from the hardware and software platform people use is a feature. It’s better than cross-platform frameworks which are constantly criticised for not producing exact native-feeling apps on the multitude of platforms they run on. The Web is above that pettiness.
You’ve probably seen this already, but it’s really worth bearing in mind: when you’re scaling up JPGs for retina display you can safely reduce the image quality by quite a lot—to the point of getting the exact same file size as a higher quality image that’s half the size.
This is the talk I gave at the Webdagene conference in Norway a few weeks back. I called it Responsive Enhancement but I think the Norwegian title translates as “Improvements Through Responsive Design.”
A lovely bit of hypertext.
This looks like a really handy tool for reducing the file size of JPEGs without any perceptible loss of quality (in much the same way that ImageOptim works for PNGs)—available as a Mac app or an installable web service.
Remember when I linked to the story of Twitter’s recent redesign of their mobile site and I said it would be great to see it progressively enhanced up to the desktop version? Well, here’s a case study that does just that.
Nicholas is inside my head! Get out of my head, Nicholas!
What makes the web beautiful is precisely that there are multiple browsers and, if you build things correctly, your sites and applications work in them all. They might not necessarily work exactly the same in them all, but they should still be able to work. There is absolutely nothing preventing you from using new features in your web applications, that’s what progressive enhancement is all about.
A really great markup and CSS pattern for “content first, navigation second” from Aaron.
A fascinating insight into the psychological implications of animated progress indicators.
A run-down of the various approaches to the responsive images problem, concluding that this is something that needs to be solved in the image format.
An idea for handling responsive images not with a new format, but with an existing one: progressive JPGs.
An in-depth analysis (graphs! data!) of how popular sites are using—or not using—compression.