Author Archives: Steve Barnett

A sketch of how to do a thing with PE

Naga IT Services
Filed under: Industry, Process

As part of the discussion that started with Alex’s post, that caused me to write mine, then to Le Roux to write his, I wanted to have a quick look at Le Roux’s excellent tool for looking at the Open Type features of Google fonts from a Progressive Enhancement point of view.

Here’s what the tool looks like normally:

Screenshot 2014-12-18 16.57.21

Here’s what it looks like with JavaScript turned off, to simulate broken or failed JavaScript:

Screenshot 2014-12-18 16.57.41

Not as awesome. To be fair, it’s not the only thing that relies on JavaScript for core functionality. It’s not even the only thing about Typography that relies on JavaScript for core functionality. Here’s The State of Web Type with Javascript turned off:

Screenshot 2014-12-18 17.05.10

(Quick aside: checkout Kenneth Normandy’s Normalize-OpenType.css for some additional interesting Open Type stuff.)

So I did a very quick and dirty bit of code to see what could the basic, core, experience of the tool look like without relying on JavaScript. Here’s how I built it up.

Problem: it requires JavaScript

The tool lets you preview a Google font, and tells you what Open Type features it supports. The steps are:

  1. Choose a font and variant
  2. View the preview
  3. Toggle open type features on and off

That core functionality is essentially ticking a few boxes, submitting a form, and seeing the result. This is a prime candidate for being done with Progressive Enhancement!

A quick sketch of a solution

Here’s what I came up: just HTML and a tiny bit of CSS. It’s a prototype. Sketch. Thing. And it looks ugly. It’s not functional (because the filtering and selecting would happen on the server), but hopefully you get the idea. It doesn’t contain all the fonts. For this purpose, that’s okay.

Bonus features

  • I added some styles to make it small screen friendly, which the original tool is not. A little bit of column shuffling means that people not on a large screen can also use the tool.
  • I enabled deep linking by using the GET method on the form. That means you can share a link to a filtered version of the results ("Hey, look, this font has All The Things Open Type!").

The nay-saying corner

  • People won’t do {that} on small screen devices. Yes they will. People will do anything on small screens if you make it good enough. Sometimes it’s the only screen they have with them, sometimes it’s the only screen they have.
  • That example is just PE for PE’s sake. No, that’s just PE: that’s what it is. Taking the simplest (and to be fair, often dullest) version of an idea and building it up from there. This sketch is just the first step.
  • Why don’t you just build the real thing with PE then? Because, like you, I am busy and don’t have much free time. The free time I do have to code, I want to spend on my own stuff. (Like fixing up this site that is now other three years old.)
  • Ha! I told you PE takes longer! Not necessarily, but (like writing any code) it does take some time. See the point above.
  • You’ve gained nothing from a PE approach here. I think that we have. Now people on a wider range of screens could use the the tool. Now if the JavaScript fails or errors, they could still use the tool. I think those are both worthwhile things.
  • Shut up, let it go now. Okay.

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.

Examples

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.