Tell it, brother!
Tell it, brother!
Rachel uncovers a great phrase for dealing with older browsers:
It isn’t your fault, but it is your problem.
She points to multiple ways of using CSS Grid today while still providing a decent experience for older browsers.
Crucially, there’s one message that hasn’t changed in fifteen years:
Websites do not need to look the same in every browser.
It’s crazy that there are still designers and developers who haven’t internalised this. And before anyone starts claiming that the problem is with the clients and the bosses, Rachel has plenty of advice for talking with them too.
Your job is to learn about new things, and advise your client or your boss in the best way to achieve their business goals through your use of the available technology. You can only do that if you have learned about the new things. You can then advise them which compromises are worth making.
As you might expect, lots of sites just don’t work, but there are plenty of sites that work just fine—Google search, Amazon, Wikipedia, BBC News, The New York Times. Not bad!
I love, love, *love, traintimes.org.uk—partly because it’s so useful, but also because it’s so fast. I know public transport is the clichéd use-case when it comes to talking about web performance, but in this case it’s genuine: I use the site on trains and in airports.
Matthew gives a blow-by-blow account of the performance optimisations he’s made for the site, including a service worker. The whole thing is a masterclass in performance and progressive enhancement. I’m so glad he took the time to share this!
If your company is or is planning on doing business in emerging markets, architecting your web applications for performance through progressive enhancements is one easy way to drastically improve accessibility, retention, and user experience.
This article uses “progressive enhancement” and “progressive web app” interchangeably, which would be true in an ideal world. This is the first of a three part series, and it sounds like it will indeed document how to take an existing site and enhance it into a progressive web app—a strategy I much prefer to creating a separate silo that only works for a subset of devices (the app-shell model being pushed by Google).
Ethan’s been thinking about the trends he’s noticed in the work he’s doing:
On that last point…
The web’s evolution has never been charted along a straight line: it’s simultaneously getting slower and faster, with devices new and old coming online every day.
This is wonderful meditation on the history of older technologies that degrade in varied conditions versus newer formats that fall of a “digital cliff”, all tied in to working on the web.
When digital TV fails, it fails completely. Analog TV, to use parlance of the web, degrades gracefully. The web could be similar, if we choose to make it so. It could be “the analog” web in contrast to “the digital” platforms. Perhaps in our hurry to replicate and mirror native platforms, we’re forgetting the killer strength of the web: universal accessibility.
The second part of Bruce’s excellent series begins by focusing on the usage of proxy browsers around the world:
But how!? Well, Bruce has the answer:
I call this amazing new technique “progressive enhancement.”
You heard it here first, folks!
An open beta of Smashing Magazine’s redesign, which looks like it could be a real poster child for progressive enhancement:
A nice look at the fallbacks that are built into CSS.
Day four was a deliberate step away from all that. No more laptops, just paper. Whereas the previous days had focused on collaboratively working on a single document, today I wanted everyone to work on a separate site.
The sites were generated randomly. I made five cards with types of sites on them: news, social network, shopping, travel, and learning. Another five cards had subjects: books, music, food, pets, and cars. And another five cards had audiences: students, parents, the elderly, commuters, and teachers. Everyone was dealt a random card from each deck, resulting in briefs like “a travel site about food for the elderly” or “a social network about music for commuters.”
For a bit of fun, the first brainstorming exercise (run as a 6-up) was to come with potential names for this service—4 minutes for 6 ideas. Then we went around the table, shared the ideas, got feedback, and settled on the names.
Now I asked everyone to come up with a one-sentence mission statement for their newly-named service. This was a good way of teasing out the most important verbs and nouns, which led nicely into the next task: answering the question “what is the core functionality?”
If that sounds familiar, it’s because it’s the first part of the three-step process I outlined in Resilient Web Design:
We did some URL design, figuring out what structures would make sense for straightforward
GET requests, like:
Then, once it was clear what the primary “thing” was (a car, a book, etc.), I asked them to write down all the pieces that might appear on such a page; one post-it note per item e.g. “title”, “description”, “img”, “rating”, etc.
The next step involved prioritisation. They took those post-it notes and put them on the wall, but they had to put them in a vertical line from top to bottom in decreasing order of importance. This can be a challenge, but it’s better to solve these problems now rather than later.
Okay. I know asked them to “mark up” those vertical lists of post-it notes: writing HTML tag names by each one. By doing this before doing any visual design, it meant they were thinking about the meaning of the content first.
After that, we did a good ol’ fashioned classic 6-up sketching exercise, followed by critique (including a “designated dissenter” for each round). At this point, I was encouraging them to go crazy with ideas—they already had the core functionality figured out (with plain ol’ client/server requests and responses) so they could all the bells and whistles they wanted on top of that.
We finished up with a discussion of some of those bells and whistles, and how they could be used to improve the user experience: Ajax, geolocation, service workers, notifications, background sync …the sky’s the limit.
It was a whirlwind tour for just one day but I think it helped emphasise the importance of thinking about the fundamentals before adding enhancements.
This marked the end of the structured masterclass lessons. Tomorrow I’m around to answer any miscellaneous questions (if I can) and chat to the students individually while they work on their term projects.
Phil describes the process of implementing the holy grail of web architecture (which perhaps isn’t as difficult as everyone seems to think it is):
I have been experimenting with something that seemed obvious to me for a while. A web development model which gives a pre-rendered, ready-to-consume, straight-into-the-eyeballs web page at every URL of a site. One which, once loaded, then behaves like a client-side, single page app.
Now that’s resilient web design!
Sally gives a really good introduction to using service workers as a progressive enhancement.
Scott runs through the latest improvements to the Filament Group website. There’s a lot about HTTP2, but also a dab of service workers (using a similar recipe to my site).
Oh, how I wished everyone approached building for the web the way that Rachel does. Smart, sensible, pragmatic, and exciting!
I’m really touched—and honoured—that my book could have this effect.
It made me fall back in love with the web and with making things for the web.
Everything that happens to the content prototype from now on is merely progressive enhancement. Because while the prototype is in a shared git repository, microcopy sneaks in, text gets corrected by a copywriter, photos change for the better and flows shape up, meta data is added, semantics are double checked, WAI-ARIA roles get in…
Remy wants to be able to apply progressive enhancement to React: server-side and client-side rendering, sharing the same codebase. He succeeded, but…
In my opinion, an individual or a team starting out, or without the will, aren’t going to use progressive enhancement in their approach to applying server side rendering to a React app. I don’t believe this is by choice, I think it’s simply because React lends itself so strongly to client-side, that I can see how it’s easy to oversee how you could start on the server and progressive enhance upwards to a rich client side experience.
I’m hopeful that future iterations of React will make this a smoother option.