This is a nice overview (in French) of how Hopwork handles progressive enhancement in their SaaS product. Their back-end is Java too. It’s nice to see folks talking about how to progressively enhance products in that language; we don’t hear about that often enough.
The Best of the Internets
A nice overview (in Dutch) of why you should combine progressive enhancement with RWD.
As usual, Jason Grigsby nails it:
- Progressive Web Apps still work on iOS
- Progressive Web Apps perform better on iOS
- Billions of people use browsers that support Progressive Web Apps
- Apple appears to be warming to Progressive Web App technology
- Progressive Web Apps benefit all users
Done and done.
This is an excellent post about progressive enhancement from the “technical credit” (as opposed to “technical debt”) point of view.
This is an excellent missive from Nicholas covering the progressive enhancement debate.
Second, progressive enhancement isn’t a strict prescription, it’s a way of thinking about the software you’re building. … Instead, it encourages you to think more deeply about the problem you’re trying to solve, and guides you towards solutions that work for the maximum number of users.
These two points are why I believe progressive enhancement is as relevant today as it has ever been. The only difference now is that we have more options for improving the user experience than ever before.
I couldn’t have said it better myself.
Accessibility is hard. It’s a broad term encompassing a variety of special needs ranging from low vision and color blindness to motor impairment and language barriers (to name but a few) which means guaranteeing our projects are “100% accessible” is a significant challenge.
Accessibility becomes even more of a challenge when you begin to factor in the dependency chain. Blind and low-vision users, for example, often use screen readers in order to access the Web. With screen readers, we need to consider the capabilities of both the browser and the screen reader being used. If either piece of software isn’t up to the task or contains a bug our users suffer for it.
Getting multiple inter-dependent programs on the same page sometimes requires that we do things we’d rather not do. This post from Steve Faulkner chronicles one such case where the particular versions of Chrome and JAWS required for a project didn’t see eye-to-eye on the semantics of heading levels. He talks about the issue and the less-than-optimal fix he had to put in place to ensure users got the experience they were meant to.
Very clever bit of flexbox here for laying out text optimally when you don’t know its length.
I don’t know that I would consider it a hack so much as pushing flexbox beyond what most people would even consider doing.
I love how Mandy deftly wove progressive enhancement into her content strategy and publishing discussion:
Perhaps ironically, we’ve found that the best way to create that resiliency is by harking back to the web principle of progressive enhancement: each story created in Chorus begins as a platform-neutral collection of text, images, and video. That foundation ensures that we can publish that story as easily to our own platform as to, say, AMP or Apple News, and be confident that our audience will experience that story in a way that fits whichever platform they are using. On our own platform, we’re then free to enhance up, adding stylistic or experiential flairs that elevate the experience of the story. This practice — which I refer to unoriginally as progressively enhanced storytelling — also has the added benefit of helping us make our content more accessible to more kinds of users, especially those with disabilities. (It wouldn’t be inaccurate to consider speaking browsers one among the many platforms we must publish to.)