Testing time with Tim.
Long story short, the NOSCRIPT intervention looks like a really great feature for users. More often than not it provides significant reduction in data usage, not to mention the reduction in CPU time—no small thing for the many, many people running affordable, low-powered devices.
I love this deep dive that Sara takes into the question of marking up content for progressive disclosure. It reminds me Dan’s SimpleQuiz from back in the day.
Then there’s this gem, which I think is a terrificly succinct explanation of the importance of meaningful markup:
It’s always necessary, in my opinion, to consider what content would render and look like in foreign environments, or in environments that are not controlled by our own styles and scripts. Writing semantic HTML is the first step in achieving truly resilient Web sites and applications.
I had a great time chatting with Lea and Emily about service workers on this episode of their podcast—they’re such great hosts!
Here’s the huffduffed audio.
Power to the people!
Scores of people who just want to deliver their content and have it look vaguely nice are convinced you need every web technology under the sun to deliver text.
This is very lawnoffgetting but I can relate.
I made my first website about 20 years ago and it delivered as much content as most websites today. It was more accessible, ran faster and easier to develop then 90% of the stuff you’ll read on here.
20 years later I browse the Internet with a few tabs open and I have somehow downloaded many megabytes of data, my laptop is on fire and yet in terms of actual content delivery nothing has really changed.
The beauty of this approach is that the site doesn’t ever appear broken and the user won’t even be aware that they are getting the ‘default’ experience. With progressive enhancement, every user has their own experience of the site, rather than an experience that the designers and developers demand of them.
A case study in applying progressive enhancement to all aspects of a site.
Very valuable observations from Paul on his travels, talking to developers and business people about progressive web apps—there’s some confusion out there.
My personal feeling is that everyone is really hung up on the A in PWA: ‘App’. It’s the success and failure of the branding of the concept; ‘App’ is in the name, ‘App’ is in the conscious of many users and businesses and so the associations are quite clear.
Oh, this is magnificent! A rallying call for everyone designing and developing on the web to avoid making any assumptions about the people we’re building for:
People will use your site how they want, and according to their means. That is wonderful, and why the Web was built.
I would even say that the % of people viewing your site the way you do rapidly approaches zilch.
What an excellent question! And what an excellent bit of sleuthing to get to the bottom of it. This is like linguistic spelunking on the World Wide Web.
Oh, and of course I love the little sidenote at the end.
I love having discussions like this!
Aw, this is so nice! Chris points to the way that The Session generates sheet music from abc text:
Here’s another way of thinking of it: I was contacted by a blind user of The Session who hadn’t come across abc notation before. Once they realised how it worked, they said it was like having
alt text for sheet music! 🤯
The slides and video from a really great well-rounded talk by Aaron, filled with practical examples illustrating concepts like progressive enhancement and inclusive design.
A directory of progressive web apps.
Here’s an intriguing proposal that would allow web apps to indicate activity in an icon (like an unread count) in the same way that native apps can.
This is an interesting one because, in this case, it’s not just browsers that would have to implement it, but operating systems as well.
Andy describes the technical approach he took building his handy reporting tool, My Browser:
Although the site is built with bleeding edge technology such as web components, it’s built with a progressive-first approach. This means that in order to get the best experience, you need to be on a modern browser, but to do the most basic function—reporting data, you can still do it by pressing a “generate report” button, which is the default state.
Not only is this a liberating way to work, it really pays off in performance:
We’re given so much for free to make a progressively enhanced website or web app. We’ve got feature detection and
@supportsin CSS which means that “My Browser” ships with no polyfills, fallbacks or hacks like Autoprefixer. The app degrades gracefully instead.
This has been a very refreshing way to work that I’ve enjoyed a lot. The fact that the whole thing comes in around 25kb tells you how effective progressive enhancement can be for performance too.
Léonie makes a really good point here: if you’re adding
Adriana Blum lists progressive web apps that are doing very, very well from Twitter, Trivago, Starbucks, Forbes, Debebhams, West Elm, Washington Post, Pinterest, AliExpress, and Lancôme.
Instead of choosing between the immediacy of a mobile website and the rich experience offered by native apps, you can now offer your target audiences the best of both and improve the commercial performance of your business to boot.
Ultimately you can’t control when and how things go wrong but you do have some control over what happens. This is why progressive enhancement exists.
Here’s a really quick (ten minute) talk about the offline user experience that I gave at the Delta V conference recently. I’m quite happy with how it turned out—there’s something to be said for having a short and snappy time slot.
There’s a common misconception that making a Progressive Web App means creating a Single Page App with an app-shell architecture. But the truth is that literally any website can benefit from the performance boost that results from the combination of HTTPS + Service Worker + Web App Manifest.