Link tags: progressive

439

sparkline

Giving your future self a little credit with progressive enhancement - Blog - Pixo | Apps, websites, and software development

We often talk about technical debt — the costs we’ll need to pay in the future when we make short-term compromises. Progressive enhancement is the opposite of that — a sort of technical credit that will make things easier for us in the future.

A good explanation of how progressive enhancement works perfectly with the idea of a minimal viable product:

We focus first on a core experience that delivers what your users are looking for, and then we start adding enhancements that will delight them.

Baldur Bjarnason -

This is kind of brilliant:

Maybe what’s needed for websites and web apps is a kind of Prepper Web Dev?

It’s Time to Build a Progressive Web App. Here’s How – The New Stack

Much as I appreciate the optimism of this evaluation, I don’t hold out much hope that people’s expectations are going to change any time soon:

Indeed, when given a choice, users will opt for the [native] app version of a platform because it’s been considered the gold standard for reliability. With progressive web apps (PWAs), that assumption is about to change.

Nonetheless, this is a level-headed look at what a progressive web app is, mercifully free of hand-waving:

  • App is served through HTTPS.
  • App has a web app manifest with at least one icon. (We’ll talk more about the manifest shortly.)
  • App has a registered service worker with a fetch event handler. (More on this later too.)

Equality vs. Equity :: Aaron Gustafson

Though I didn’t make the connection until much later, the philosophy of progressive enhancement in web design, which I’ve been advocating for nearly two decades now, is very much the embodiment of equity. It’s concerned with building interfaces that adapt to a wide range of circumstances, both tied to an individual user’s capabilities as well as those of the devices, networks, and environment in which they are accessing our creations.

Stop supporting Internet Explorer!

The headline is clickbaity, but the advice is solid. Use progressive enhancement and don’t worry about polyfilling.

When I say ‘Stop supporting IE’ it means to me that I won’t go the extra mile to get unsupported features working in Internet Explorer, but still make sure Internet Explorer users get the basics, and can use the site.

How we think about browsers | The GitHub Blog

JavaScript doesn’t get executed on very old browsers when native syntax for new language features is encountered. However, thanks to GitHub being built following the principle of progressive enhancement, users of older browsers still get to interact with basic features of GitHub, while users with more capable browsers get a faster experience.

That’s the way to do it!

Concepts like progressive enhancement allow us to deliver the best experience possible to the majority of customers, while delivering a useful experience to those using older browsers.

Read on for the nitty-gritty details…

The Biggest Thing from WWDC 2022 - Webventures

Web Push on iOS will change the “we need to build a native app” decision.

I agree.

Push notifications are definitely not the sole reason to go native, but in my experience, it’s one of the first things clients ask for. They may very well be the thing that pushes your client over the edge and forces them, you and the entire project to accept the logic of the app store model.

News from WWDC22: WebKit Features in Safari 16 Beta | WebKit

Good news and bad news…

The good news is that web notifications are coming to iOS—my number one wish!

The bad news is that it won’t happen until next year sometime.

CSS { In Real Life } | My Browser Support Strategy

This is a great succinct definition of progressive enhancement:

Progressive enhancement is a web development strategy by which we ensure that the essential content and functionality of a website is accessible to as many users as possible, while providing an improved experience using newer features for users whose devices are capable of supporting them.

Progressively Enhanced Builds - Jim Nielsen’s Blog

Rather than thinking, “how do I combine a bunch of disparate content, templates, and tooling into a functioning website?”, you might think “how do I start at a functioning website with content and then use templates and build tooling to enhance it?”

I think Jim is onto something here. The more dependencies you have in your build process, the likelier it is that over time one of them will become a single point of failure. A progressive enhancement approach to build tools means you’d still be able to launch your site (even if it’s not in its ideal state).

I want to be able to view, edit, and if need be ship a website, even if the build process fails. In essence, if the build does fail I can still take all the source files, put them on a server, and the website remains functional (however crude).

Web Components as Progressive Enhancement - Cloud Four

This is exactly the pattern of usage I’ve been advocating for with web components—instead of creating a custom element from scratch, wrap an existing HTML element and use the custom element to turbo-charge it, like Zach is doing:

By enhancing native HTML instead of replacing it, we can provide a solid baseline experience, and add progressive enhancement as the cherry on top.

Be the browser’s mentor, not its micromanager. - Build Excellent Websites

This one-page site that Andy has made to illustrate his talk at All Day Hey is exactly what I was talking about with declarative design.

Give the browser some solid rules and hints, then let it make the right decisions for the people that visit it, based on their device, connection quality and capabilities. This is how they will get a genuinely great user experience, rather than a fragmented, broken one.

Make Beautifully Resilient Apps With Progressive Enhancement

You had me at “beautifully resilient apps with progressive enhancement”.

This is a great clear walkthrough of enhancing a form submission. A lot of this seems like first principles to me, but if you’ve only ever built single page apps, then thinking about a server-submission process first might well be revelatory.

Make it boring — jlwagner.net

People are propelled by their interests, and web developers have a lot of space to be interested in all sorts of stuff. For you, it may be JavaScript ‘n Friends, or HTML and CSS. Maybe it’s all that stuff, but put aside your preferences for a moment and answer me this: what are you helping people to do? If the answer involves any remotely routine or crucial purpose, consider putting aside your personal desire for excitement. Instead, make boring things that are usable, accessible, and fast. Ours is a job done by people for people, not a glamorous rockstar gig.

Excellent advice from Jeremy who wants us to build fast, reliable, resilient websites …even if the technologies involved in doing that don’t feel exciting.

Central to that endeavor is recognizing that the browser gives you a ton of stuff for free. Relying on those freebies requires a willingness to not npm install a solution for every problem — especially those that are best solved with CSS and HTML. Those technologies may seem boring, but boring is fast. Boring is usable. Boring is resilient and fault tolerant. Boring is accessible. When we rely wholesale on JavaScript to build for the web, we’re inevitably reinventing things. At worst, our reinventions of rock-solid HTML features — such as client-side form validation  — break in unexpected ways despite our carefully written tests. At best, a flawless reimplementation of those features adds unnecessary code to applications, and depends on a technology less fault-tolerant than CSS and HTML.

Progressive Enhancement, the New Hotness™ | Go Make Things

Here’s a great explanation of progressive enhancement, complete with practical examples and myth-busting. Pass it ‘round!

If you care about quality engineering, you want as much fault tolerance in the things you build as possible.

Add Responsive-Friendly Enhancements to `details` with `details-utils`—zachleat.com

This is how a web component should be designed! Zach has made a custom element that wraps around an existing HTML element, turbocharging its powers. That’s the way to think about web components—as a progressive enhancement.

How to progressively enhance a nav menu | Go Make Things

A lot of folks assume that progressive enhancement means having to write the same code twice, but often, it can be as simple as extending the pattern you already have once the JS loads.

“Evergreen” Does Not Mean Immediately Available | CSS-Tricks - CSS-Tricks

Smart advice on future-proofing and backward-compatibility:

There isn’t a single, specific device, browser, and person we cater to when creating a web experience. Websites and web apps need to adapt to a near-infinite combination of these circumstances to be effective. This adaptability is a large part of what makes the web such a successful medium.

Consider doing the hard work to make it easy and never remove feature queries and @supports statements. This creates a robust approach that can gracefully adapt to the past, as well as the future.

Embrace the Platform - CSS-Tricks

This is a wonderful piece by Bram. Half history lesson, and half practical advice for building resilient websites today:

By embracing what the web platform gives us — instead of trying to fight against it — we can build better websites.

Keep it simple. Apply the Rule of Least Power. Build with progressive enhancement in mind.

HTML, CSS, and JavaScript — in that order.