Tags: progressive

411

sparkline

Tuesday, September 17th, 2019

NoJS Side-by-Side

Drag this to your browser’s bookmark bar now!

Such a useful quick check for resilience—this bookmarklet shows you a side-by-side comparison of a site with JavaScript enabled and disabled.

Monday, September 16th, 2019

The Book | The Lean Web

This is such a great little web book from Chris Ferdinandi that you can read online for free.

  1. Intro
  2. Modern Best Practices
  3. How did we get here?
  4. Lean Web Principles
  5. What now?

Saturday, August 31st, 2019

Less Data Doesn’t Mean a Lesser Experience| TimKadlec.com

If you treat data as a constraint in your design and development process, you’ll likely be able to brainstorm a large number of different ways to keep data usage to a minimum while still providing an excellent experience. Doing less doesn’t mean it has to feel broken.

Friday, August 9th, 2019

Redux: Lazy loading youtube embeds

Remy has an excellent improvement on that article I linked to yesterday on using srcdoc with iframes. Rather than using srcdoc instead of src, you can use srcdoc as well as src. That way you can support older browsers too!

Wednesday, July 24th, 2019

Progressive Enhancement

This post was originally written in 2015, but upon re-reading it today, it still (just about) holds up, so I finally hit publish.

Tuesday, June 25th, 2019

In defence of graceful degradation and where progressive enhancement comes in by Adam Silver

This does a really good job of describing the difference between progressive enhancement and graceful degradation …but I don’t buy the conclusion: I don’t think that feature detection equates to graceful degradation. I do agree though that, when it comes to JavaScript, the result of progressive enhancement is that the language degrades gracefully.

This is progressive enhancement. An approach to making interfaces that ensures JavaScript degrades gracefully—something that HTML and CSS do automatically.

But there’s a difference between something degrading gracefully (the result) and graceful degradation (the approach).

Friday, June 7th, 2019

Building on Vimeo

Here’s the video of the opening talk I gave at New Adventures earlier this year. I think it’s pretty darn good!

Thursday, June 6th, 2019

Patterns for Promoting PWA Installation (mobile)  |  Web Fundamentals  |  Google Developers

Some ideas for interface elements that prompt progressive web app users to add the website to their home screen.

Designing for actual performance by Adam Silver

This is something I’ve been thinking about a lot lately. The justification for single page apps feels like circular thinking to me. A JavaScript framework is needed to avoid full page refreshes because full page refreshes are expensive because that means assets will be reloaded …assets like the JavaScript framework that only exists to avoid the full page refresh.

This is how it goes. We put a load of shit into a single web page. This makes the page slow. Slow to load, slow to render. Slow.

Instead of getting rid of the shit, we blame the page refresh.

Tuesday, April 30th, 2019

Progressive Font Enrichment: reinventing web font performance | Responsive Web Typography

Jason describes the next big thing in web typography: streaming fonts!

…to enable the ability for only the required part of the font be downloaded on any given page, and for subsequent requests for that font to dynamically ‘patch’ the original download with additional sets of glyphs as required on successive page views—even if they occur on separate sites.

Friday, April 12th, 2019

Disenchantment - Tim Novis

I would urge front-end developers to take a step back, breathe, and reassess. Let’s stop over engineering for the sake of it. Let’s think what we can do with the basic tools, progressive enhancement and a simpler approach to building websites. There are absolutely valid usecases for SPAs, React, et al. and I’ll continue to use these tools reguarly and when it’s necessary, I’m just not sure that’s 100% of the time.

Monday, April 8th, 2019

User interfaces: hiding stuff should be a last resort by Adam Silver

When we hide content, there’s a greater risk the user won’t see it. There’s a higher reliance on digital literacy and it’s generally more labour intensive for the user.

Worse still, sometimes we kill off essential content.

Sunday, April 7th, 2019

Drag’n’drop revisited

I got a message from a screen-reader user of The Session recently, letting me know of a problem they were having. I love getting any kind of feedback around accessibility, so this was like gold dust to me.

They pointed out that the drag’n’drop interface for rearranging the order of tunes in a set was inaccessible.

Drag and drop

Of course! I slapped my forehead. How could I have missed this?

It had been a while since I had implemented that functionality, so before even looking at the existing code, I started to think about how I could improve the situation. Maybe I could capture keystroke events from the arrow keys and announce changes via ARIA values? That sounded a bit heavy-handed though: mess with people’s native keyboard functionality at your peril.

Then I looked at the code. That was when I realised that the fix was going to be much, much easier than I thought.

I documented my process of adding the drag’n’drop functionality back in 2016. Past me had his progressive enhancement hat on:

One of the interfaces needed for this feature was a form to re-order items in a list. So I thought to myself, “what’s the simplest technology to enable this functionality?” I came up with a series of select elements within a form.

Reordering

The problem was in my feature detection:

There’s a little bit of mustard-cutting going on: does the dragula object exist, and does the browser understand querySelector? If so, the select elements are hidden and the drag’n’drop is enabled.

The logic was fine, but the execution was flawed. I was being lazy and hiding the select elements with display: none. That hides them visually, but it also hides them from screen readers. I swapped out that style declaration for one that visually hides the elements, but keeps them accessible and focusable.

It was a very quick fix. I had the odd sensation of wanting to thank Past Me for making things easy for Present Me. But I don’t want to talk about time travel because if we start talking about it then we’re going to be here all day talking about it, making diagrams with straws.

I pushed the fix, told the screen-reader user who originally contacted me, and got a reply back saying that everything was working great now. Success!

Thursday, April 4th, 2019

A progressive disclosure component - Andy Bell

This is a really nice write-up of creating an accessible progressive disclosure widget (a show/hide toggle).

Where it gets really interesting is when Andy shows how it could all be encapsulated into a web component with a progressive enhancement mindset

Monday, March 25th, 2019

Stuffing the Front End

53% of mobile visits leave a page that takes longer than 3 seconds to load. That means that a large number of visitors probably abandoned these sites because they were staring at a blank screen for 3 seconds, said “fuck it,” and left approximately half way before the page showed up. The fact that the next page interaction would have been quicker—assuming all the JS files even downloaded correctly in the first attempt—doesn’t amount to much if they didn’t stick around for the first page to load. What was gained by putting the business logic in the front end in this scenario?

Friday, March 22nd, 2019

All you need to know about hyphenation in CSS | Clagnut by Richard Rutter

Everything you need to know about hyphenation on the web today, from Rich’s galaxy brain.

Hyphenation is a perfect example of progressive enhancement, so you can start applying the above now if you think your readers will benefit from it – support among browsers will only increase.

I Used The Web For A Day On Internet Explorer 8 — Smashing Magazine

A fascinating look at the web today with IE8. And it’s worth remembering who might be experiencing the web like this:

Whoever they are, you can bet they’re not using an old browser just to annoy you. Nobody deliberately chooses a worse browsing experience.

The article also outlines two possible coping strategies:

  1. Polyfilling Strive for feature parity for all by filling in the missing browser functionality.
  2. Progressive Enhancement Start from a core experience, then use feature detection to layer on functionality.

Take a wild guess as to which strategy I support.

There’s a bigger point made at the end of all this:

IE8 is today’s scapegoat. Tomorrow it’ll be IE9, next year it’ll be Safari, a year later it might be Chrome. You can swap IE8 out for ‘old browser of choice’. The point is, there will always be some divide between what browsers developers build for, and what browsers people are using. We should stop scoffing at that and start investing in robust, inclusive engineering solutions. The side effects of these strategies tend to pay dividends in terms of accessibility, performance and network resilience, so there’s a bigger picture at play here.

Wednesday, March 20th, 2019

Competing by mimicking - Andy Bell

In my mind, the only way to “compete” with native apps is to do better than native apps—and with the web platform consistently improving and enabling us to produce app-like experiences, with Service Workers, ES6+ JavaScript, modern CSS and Web Components: we are very much on the path to do better than native apps.

Monday, March 18th, 2019

The Lean Web video from Boston CSS | Go Make Things

A good talk from from Chris Ferdinandi, who says:

One of the central themes of my talk on The Lean Web is that we as developers repeatedly take all of the great things the web and browsers give us out-of-the-box, break them, and then re-implement them poorly with JavaScript.

Tuesday, March 5th, 2019

An exercise in progressive enhancement - DEV Community 👩‍💻👨‍💻

Hui-Jing talks through her process of building a to-do app on Glitch using a progressive enhancement mindset:

I found that HTML out-of-the-box takes care of a lot of things when it comes to collecting user inputs from the front-end, which resulted in much less code required. This is not to say client-side Javascript is bad, because the experience was smoother (and faster) when I used it for updating content.