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.
A few days ago, I watched a short video: Ben Callahan – Small Screen Navigation & Hamburgers. It’s well worth (the 13 minutes of) your time. That, and chatting with Rich on Friday about our upcoming talk at CTFEDS, got me thinking about hamburgers for navigation.
People still don’t get the burger; I had this confirmed during usability testing while I was at Flow. It’s more than just the icon itself, though. Us designers and developers throw it in there to free up screen space by hiding the navigation off the screen, but out of sight is out of mind for most users. It seems like hiding the navigation is the actual problem, not the burger icon itself. The most obvious (and oft-cited) solution is “fix your Information Architecture,” but that’s seldom easy, especially for something like an e-commerce site with a lot of stuff.
Another thing the video reminded me of was the value of regular, short, usability testing. It helps you find glaring problems quickly, and fix them. Then you can follow that up with a long tail of deeper testing if you have the time and money.