Getting better at Progressive Enhancement

Naga IT Services
Filed under: Industry, Process

Alex, smart cookie that he is, wrote a thoughtful, well-reasoned, post about PE (Progressive Enhancement), in response to a conversation on The Twitters (which was in response to another post of his). I think he hits the nail on the head with "It’s actually an argument about practicality." If you’re new to PE, it can take longer at first (like any new thing), and I think there are two big reasons why. Firstly it’s a big shift in mindset. It requires you to think about a continuum of experiences, and to solve really hard problems. Secondly, it means writing different code. Here are some thoughts around how to make these things a bit easier.

Aside: see also Progressive Enhancement: busting some myths

Shift in mindset

PE starts with design. You need to consider the simplest possible version of the thing / feature / task. Think about it in terms of what can be done using just HTML (and a trip to the server and back); ignore CSS and JS for now.

Once you’ve found and figured out that core functionality, you can layer on some CSS. Think about how you can enhance the presentation with CSS, change the layout for larger screen sizes. Finally, layer on JS. Think about what extra behaviours and interactions you can add to aid the user completing their task.

Keep in mind that this layering isn’t a smooth curve. Newer devices don’t automatically have better CSS and JS support for various features: low cost Android phones are still being released that run version 2.3

For me, it has a lot in common with a Mobile First philosophy: solve the hardest problem first. Reduce things to their essence and think about what you can do with very little (small screen size, low browser capability, crappy network connection) to work with.


Not picking on Le Roux, but taking some of his list as ideas to bat around, here as some quick thoughts on how you could PE some more complex apps. These are tricky ones, and these ideas aren’t fleshed by any means, but they do try and think about what the simplest possible version of a thing is. What is the most basic version of the experience: what can we do with just HTML?

  • image editors. There are a number of things you might want to do: applying a filter, cropping or resizing an image. For filters, you could have checkboxes or radios with the names / examples of the filter on, and an "Apply filter" button that returns the filtered image from the server. For cropping, you could display the image’s dimensions in pixels and ask for the new dimensions, along with a series of checkboxes for choosing the cropping direction (to the top left, left, bottom left, etc.)
  • wysiwyg layout tools. Here you want to set the position on a grid of a content module. You could use an ordered list to represent rows, with each row having an input type="number" to set the row order. Each row could contain an ordered list of content items, and for each you could use input type="number" to set their column position and width.
  • word processors. The core functionality here is writing. Formatting is an enhancement! What could work is to use markdown for formatting, and convert that into a wysiwyg editor for more capable browsers.
  • games. Honestly, exceptionally tricky to do with PE, except for fairly rudimentary games. PE depends on having a server-side fallback for functionality. The nature of many games kind of goes against that.

Writing different code

Adopting a PE way of coding means doing things differently, which means writing code a bit differently. I read a lot and keep a list of PE-related links on Pinboard to help keep my brain in order.

Writing modular, re-usable, components and putting them into a Front-end Style Guide means you can share your PE modules with your team. Very importantly, this include future you (and your team): one you’ve written a PE solution to a pattern, re-use it. Huge bonus points if you share your patterns with the rest of the world, via GitHub or your site.

When looking for inspiration or ideas, it helps to look to the experts. I am a complete and unashamed Filament Group fanboy. Their South Street set of tools is amazing and worth working through in detail. Their book Designing With Progressive Enhancement should be required reading for anyone writing Front-end code. Quite a few of the code samples in the book are available on the book’s page.

Progressive Enhancement: busting some myths

Naga IT Services
Filed under: Industry, Process

I’m on a bit of a warpath at the moment with PE. So here are some myths about it, and their busts.

Myth: it holds you back

PE doesn’t stop you from going as fancy as you like. All it says is: start with a simple, functional, baseline, and enhance up from there. That means HTML plus limited CSS, but no JavaScript. Once you’ve got that working: go wild!

It also doesn’t mean spending all your time getting things to work on older browsers. You’re starting with something simple enough that you know it will work there so that you can spend more time with the fun, fancy, stuff for more capable browsers.

Myth: it’s about users turning off JavaScript.

Nope. Very few users turn JavaScript off. PE is about coping with JavaScript failing to load or only partially loading. It’s about JavaScript being blocked by corporate firewalls. It’s about last minute "fixes" that introduce bugs and break the whole JavaScript application.

PE is actually about dealing with unknowns: we don’t know the user’s browser, what their network connection is like, or if they have any disabilities. Building with PE means not caring if a user is running IE6 on Windows XP or Android 5.0.1 on a Sony Xperia Z3: you know that your site will still work on those, and on whatever is released next week and next year.

Myth: it only works for small projects

A modern front-end web workflow is all about making modular, re-usable, components. Even very large web things (apps, sites, wotsits) are essentially made up of a lot of repeating patterns. Building these modules up with PE in mind means building your large, complex, project in way that will work for everyone (albeit in different ways).

More gooder

This was actually a bit of a run up to what I really wanted to write about: Getting better at Progressive Enhancement.

It’s a continuum. Still.

Naga IT Services
Filed under: Industry, Reading

I finally got around to reading How To Create Your Own Front-End Website Testing Plan and that got me a bit angry talking about support levels. The article steers towards a binary way of thinking: have / have not and supported / unsupported, and I think that’s not quite right. The way that users will experience a site sits on a continuum, and it’s not for us to tell them that their browser is or isn’t “good enough.”

I’m going to pick on the Smashing Mag article a little. Sorry.

Support level 2: partially supported browsers and devices

The turn of phrase here is a little off for me. It’s not that they are partially supported: it’s more that they’re full supported for a different experience. The article also talks about degradation instead of enhancement. I’d much rather build with Progressive Enhancement: a tasty base, with goodness layered on top.

Support level 3: unsupported browsers and devices

Ideally there should be no such thing as an unsupported browser or device. Every browser should get a functional experience, even if it’s not fancy.

Notes from UX Craft Movember Masterclass

Naga IT Services
Filed under: Talk notes

Last night I went to the November UX Craft meetup and listened to Dennis Williams from and Vaughn Gunnell from Tag Worldwide talk about all things UX. Below are some brief notes I made.


Dennis’s talk

  • Start with the basics: the user goals and usability testing.
  • Multi-screen journeys are very important today.
  • Look at your customer lifecycle.

Vaughn ‘s talk

  • User Experience is applying validated learning.
  • Design is iterative and knowledge must flow up the organisation
  • Continuous Improvement is your competitive advantage.