The Nook returns with stock Android to compete with Amazon’s closed Fire ecosystem.
The Best of the Internets
Ever wonder if websites can track your every move?
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.
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.