A really nice example of progressive enhancement: creating a layout with
inline-block, then flexbox, then Grid.
Thursday, September 14th, 2017
A really nice example of progressive enhancement: creating a layout with
Friday, August 4th, 2017
Oh, how I wish I could’ve been at Web Directions Code in Melbourne to see this amazing presentation by Charlotte. I can’t quite get over how many amazing knowledge bombs she managed to drop in just 20 minutes!
Tuesday, July 25th, 2017
A great example of progressive enhancement in action.
You can perfectly use CSS grid layout today if you don’t expect exactly the same appearance in every single browser, which isn’t possible to achieve nowadays anyway. I’m well aware that this decision isn’t always up to us developers, but I believe that our clients are willing to accept those differences if they understand the benefits (future-proof design, better accessibility and better performance). On top of that, I believe that our clients and users have — thanks to responsive design — already learned that websites don’t look the same in every device and browser.
Thursday, July 6th, 2017
Tell it, brother!
Wednesday, July 5th, 2017
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.
Wednesday, June 7th, 2017
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!
Friday, May 26th, 2017
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!
Monday, May 1st, 2017
Friday, April 28th, 2017
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).
Thursday, April 20th, 2017
Ethan’s been thinking about the trends he’s noticed in the work he’s doing:
- prototypes over mockups,
- preserving patterns at scale, and
- thinking about a design’s layers.
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.
Thursday, March 30th, 2017
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.
Monday, March 20th, 2017
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!
Friday, March 17th, 2017
An open beta of Smashing Magazine’s redesign, which looks like it could be a real poster child for progressive enhancement:
Saturday, February 25th, 2017
A nice look at the fallbacks that are built into CSS.
Friday, February 17th, 2017
Teaching in Porto, day four
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:
- Identify core functionality.
- Make that functionality available using the simplest possible technology.
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.
Friday, February 3rd, 2017
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!
Friday, January 27th, 2017
A practical guide to Progressive Web Apps for organisations who don’t know anything about Progressive Web Apps : Records Sound the Same
Sally gives a really good introduction to using service workers as a progressive enhancement.
Sunday, January 15th, 2017
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!
Sunday, January 1st, 2017
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.