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
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.
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).
This was actually a bit of a run up to what I really wanted to write about: Getting better at Progressive Enhancement.
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.
This weekend, I tore through the excellent Responsible Responsive Design by the crazy-smart Scott Jehl, the latest from A Book Apart. It’s a great read, and a succint summary of some new (focus on performance) and not so new (do Progressive Enhancement) ideas and themes that are bouncing around Front-end web dev land.
I’ve been having fun trying out sketchnoting things, rather than my previous technique of trying to scribble down every single word of something. I’m particularly interested to see if it helps my memory, which at the moment is terrible. Here are my sketchnotes form the book. Click a pic for a larger version.
“A Front-End Developer’s Ode To Specifications” on Smashing Magazine the other day made me kinda mad. I’m all for having a final Front-end implementation that matches up with the designer’s vision, but I think that this idea of “correctly implemented design” and pixel perfection is a damaging way of thinking about web sites because it implies there is one correct, pixel perfect, version of the design.
Designs, by and large, are still created in applications that create fixed width, fixed fidelity, non-squishy, output. This works well with the idea of a specification: “this one version of the product is the correct version.” It doesn’t work well with web sites, which are by their nature, flexible and changeable. Trying to exert this kind of control and constraints on a web site just isn’t tenable in today’s world wide web, or the future’s.
Even something as simple as a font is very flexible. You can specify a base font and size exactly in a specification. But how do you adjust the font size (and line height) for larger screens? And what is the font stack: if the desired font isn’t available, or doesn’t load, what fonts should be tried next?
If the specs were all in percentages rather than pixels: that would be a good start. But then you still need to consider breakpoints and showing layout changes across them. The drift that the author discusses between the designer’s final version and the implementation feels wrong. The developer might get the site looking pixel perfect in the latest version of Chrome. But what about Firefox? And what about Safari on an iPad? And what about Internet Explorer 10 on a Windows machine? These will already look different from each other, even thought they’re using the exact same implementation of the design. I think that that’s completely fine: but it won’t match the spec.
Front-end style guides, mentioned at the end of the article, are much more promising. They feel like a logical step into code from Style Tiles, the squishy design deliverable.