I don’t remember what got it stuck in my craw, but I’ve been thinking a bit about HTML fallbacks of late.
Browse by Tag: Progressive Enhancement
In the work that we do on the Web (as well as in our daily lives), we’re often confronted, informed, or judged based on averages. I never really stopped to think about it, beyond being bugged by the fact that averages aren’t truly representative of reality. Then I listened to 99% Invisible’s episode “On Average”. It was incredibly enlightening and the stories shared in that episode provide sage wisdom that is very relevant to the work that we do.
Late last week, Josh Korr, a project manager at Viget, posted at length about what he sees as a fundamental flaw with the argument for progressive enhancement. In reading the post, it became clear to me that Josh really doesn’t have a good grasp on progressive enhancement or the reasons its proponents think it’s a good philosophy to follow. Despite claiming to be “an expert at spotting fuzzy rhetoric and teasing out what’s really being said”, Josh makes a lot of false assumptions and inferences. My response would not have fit in a comment, so here it is…
Full disclosure: We both work at Microsoft, but on different teams. ↩
Sixteen years ago, Stewart Butterfield conceived of a contest that would test the mettle of any web designer: The 5k. The idea was that entrants would build an entire site in 5kB of code or less. Its aim was to force us to get creative by putting a bounding box on what we could do:
Between servers and bandwidth, clients and users, HTML and the DOM, browsers and platforms, our conscience and our ego, we’re left in a very small space to find highly optimal solutions. Since the space we have to explore is so small, we have to look harder, get more creative; and that’s what makes it all interesting.
In two back-to-back, potentially NSFW posts discussing web development vs. native development, Eran Hammer covered a lot of the pain points encountered in each. For instance, on the Web, you’ve got rendering and user interface inconsistencies between browsers. On the other hand, retention for native apps is notoriously crappy.
I had the great pleasure of delivering the following talk at the Edge Web Summit on April 4th. The talk is largely about accessibility with a push for thinking about the future of the interface and how considering accessibility now will help us prepare for a world of “headless UIs”.
Unfortunately, I was unable to spend Tuesday in Nashville for An Event Apart (for reasons that will be revealed in about a month), but I did catch Monday and it was amazing.
For the last few years I’ve been running a workshop alternately titled “Planning Adaptive Interfaces” or “Beyond Responsive”, depending on the conference. It’s been one of my favorite workshops to run for a number of reasons, but before I get into that, let me explain what it is and how it works.
On March 4th, I’ll be in London to give the closing talk at EnhanceConf, the first conference dedicated progressive enhancement. Over the last few months, I’ve been talking to the conference’s organizer, Simon McManus, quite a lot. He’s put a lot of thought into the conference and I thought it might be interesting to interview him so he could share his motivations and hopes for the event.
User experience encompasses more than just the interface. Download speed, render performance, and the cost of accessing a site are often overlooked areas when it comes to the practice of UX, but they all affect how users experience what we build on the Web.
I wrote the bulk of Adaptive Web Design in early 2010 while taking a much-needed break from client projects. I had originally slated for it to be released just before the holidays that year, but life happened and the book did not make it out into the world until mid-2011. Six months is a long time in the technical world, and especially on the Web. A year is forever.
The fine folks at 18F just posted a beautiful write-up of the talk on progressive enhancement that I delivered as part of the 18F Design Speaker Series. I thoroughly enjoyed talking to the folks that came. They presented some interesting challenges and asked pressing questions—exactly the kind of engagement I love.
I had the great pleasure of delivering the closing keynote for the final Responsive Day Out. Here’s what I had to say.
One of the greatest challenges of progressive enhancement lies not with the coding, but with the planning. It can be incredibly challenging to articulate how a single interface might adapt to a wide variety of situations. Interface Experience Maps (Ix Maps) can help.
Today is the day Google updates it algorithm to take into account mobile-friendliness. Here are a few tips that will help you embrace mobile without tearing your hair out.
In more than a handful of conversations lately, it’s become quite clear that we, the web development community, are prioritizing our own convenience and our own time over that of our users. With our industry’s focus on “user-centered design”, you might find that hard to believe, but it’s true.
Jason Garber has penned a series of posts on progressive enhancement. Here’s a quick rundown on what they cover and why you should read them.
One of the biggest headaches of responsive design has been dealing with images. Thankfully our work on the Responsive
Images Community Group has resulted in a rock-solid set of elements and attributes to address all of your adaptive image needs. My company, Easy Designs, recently redesigned Nichols College’s website and that project just happened to coincide adaptive images landing in Blink (the rendering engine that powers Chrome and Opera). Naturally, we jumped at the opportunity to use them.
In case you missed it, yesterday Pierre Far updated Google’s Webmaster Guidelines. In his post, Pierre lays out their case for progressive enhancement:
Just like modern browsers, our rendering engine might not support all of the technologies a page uses. Make sure your web design adheres to the principles of progressive enhancement as this helps our systems (and a wider range of browsers) see usable content and basic functionality when certain web design features are not yet supported.