It’s official, I am my own worst client. Missed deadlines, flip-flopping briefs, no budget, unrealistic expectations and an insatiable urge to endlessly tweak, refine and experiment. Applying the same discipline reserved for client work to my own projects still seems beyond my capabilities… I seem to recall the cure for perfectionism is to embrace Satisficing - launching when you reach the “acceptability threshold”. That’s tough to swallow when it’s your own personal brand.
Here’s the story, and please forgive my self-indulgence; it’s a form of much-needed therapy following my first serious responsive design.
Before pushing the EJECT! button at my secure, steady and comfortable corporate day job a couple of months ago, one of the hardest decisions I faced was whether to continue trading under my personal brand on my beloved jamessmith.co.uk domain or whether to launch a new separate brand. There are certainly pros and cons on either side, but it turns out that even coming up with a meaningful and available company name is really hard!
I don’t have (genuine) plans for World Domination and am not particularly inspired by building empires or the prospect of getting sold to Big Fish Inc., so keeping my personal brand was the easy choice. Faced with impending client work, short deadlines and learning the new complexities of responsive web design meant that a full rebrand would not be realistic.
For now at least then, it’s James Smith Web Consultancy.
Hooray! I made a decision.
Soon I’ll be satisficing all over the place.
As a quick aside, I’m no futurologist (and if I were I’d tell myself to get a real job), but I do sense a trend (at least in the tech community if not society as a whole) towards working in small, modular, loosely connected groups instead of behemoth organisations. I believe the same is true of software and the web in general, but that’s probably another whole article… Whilst not entirely unrelated, Paul Saffo’s article on the Creator Economy is a fascinating read if you have a spare moment.
Designs usually have a starting point other than a blank canvas - sometimes it’s a typeface, sometimes the textured bark of a tree, a photograph or a maybe even a song or the smell of doughnuts. Mm, doughnuts. This time it was this colour combination of some pretty-yet-uncomfortable office furniture in the canteen of the Glasgow office of Ceridian UK:
A fun little technique I use sometimes to create a palette is to put the photo through one of Photoshop’s pixellate filters (the one shown here is Crystallize). On photos with lots of different colours this helps to distil them down to their essence:
You can then take a single pixel column and stretch it with Free Transform (cmd+T) to give yourself an instant palette:
A few manual tweaks and round-trips to Jonathan Snook’s WCAG compliant colour contrast analyser and I had a whole palette ready to go. As the design developed I revisited the palette and added variations where necessary:
Front end coding
Responsive web design - where the layout changes based on the visitor’s screen size - has rightly been hailed as the saviour of the web. It has taken a few years to become commercially feasible (though some might argue it still isn’t). A few minority voices have also argued that responsive design is not a panacea. Quite frankly though, anyone who uses words like ‘panacea’ in public should probably not be allowed any kind of opinion.
Oh wait, that probably includes me. Nevermind.
These are incredibly exciting times for web design - almost as groovy as the web standards revolution of 10 years ago. If you or your designers are not designing responsive websites you should at least be able to give several reasons why not. Sure, it’s hard, complicated, stressful and time-consuming at first, but so was making table-less pure CSS layouts work in IE5 in 2004, and as a community we managed it, dragging the browser makers along with us and ultimately making the web a (much) Better Place.
So, having deliberately delayed my own personal journey into responsive design until it was no longer bleeding edge (the edge is awe inspiring but there are very compelling commercial reasons to stay a step or two behind it - not to mention the risks posed to your mental health), it was with trepidation I ventured forth…
Responsive design is Hard
Forgive me sounding like a whining teenager but there’s really no avoiding or denying this fact. Even before you bring cross-browser and backwards compatibility into the equation, responsive design is hard. Sometimes it’s brain-meltingly hard. The only good thing about it being hard is that front end engineering will now command the respect that it has truly deserved all along.
With this level of complexity something has to give. What will it be? Well, lots of things it turns out. What follows are some thoughts on responsive design that I am really jotting down here to remind myself as much as anything else. This is not intended to be a comprehensive guide to responsive design: things are still changing a lot in this area but with any luck some of these things might help you, or at least spark a glimmer of recognition and/or prevent an imminent nervous breakdown.
‘Mobile first’ approach
The mobile first approach makes perfectly reasonable sense and in my opinion should be your default starting point for a responsive design. Doing it the other way around as most designers were a couple of years ago will quickly see your CSS blossom to thousands of lines of redundant code, along with recurring nightmares about specificity and selectors as long as your arm, not to mention the well-documented performance issues with simply switching things off with display:none as the screen shrinks.
The biggest difficulty I had with the mobile-first approach is having the discipline to stick to it - Often I would find myself so keen to build out a piece of the puzzle at full-width that I would just start doing it inside my large screen media query block without thinking. Then of course you need to unpick everything you’ve done to split your CSS into its small-screen core styles that can cascade down into the large screen. Ugh, I must have made that mistake at least 5 times before learning the lesson: Mobile First - REALLY.
No standard breakpoints
Don’t forget that you’re not designing for different screen sizes or devices here - you’re designing for every screen size simultaneously, so a standard set of breakpoints just doesn’t make sense. The breakpoints you choose should be dictated by the design. Sure, there’s nothing wrong with optimising around a few common resolutions, but ultimately you’ll be fighting a losing battle. (The same goes for user agent sniffing).
Get cosy with your calculator
Just like poker, fluid grids are all about playing the percentages. And percentages are all about context. Every time you nest DOM elements the context changes. Whenever you hit stormy waters, ask the question, what is 100%? 100% of what? Depending on what layout techniques you’re using it’s not always an element’s direct parent that gives the context. I often find myself briefly setting an element’s padding or margin to 100% and then examining its layout in Firebug to see how many pixels it’s being calculated as so I can figure out where the context is coming from. I’ve found that cross-browser compatibility is still an issue here even in the most modern browsers (compare this fiddle in Chrome and Firefox).
I found that one of the most challenging parts of a responsive design is using identical markup across multiple breakpoints. Wherever possible we should strive to maintain the same markup, but it’s not always possible, and even where it is, the trade-off in layout complexity might outweigh the advantage of using two separate blocks of markup.
So for example viewing this article at fullscreen I have the date and some meta data in a side column. As the width reduces, the same information is displayed underneath the main heading - and in the case of the stylised date, the markup needs to change. Furthermore, regardless of where they appear visually, some of the sidebar data should semantically be described as an html5 header element inside the main article, whilst the remaining data would more accurately be described as an html5 aside. Dealing with these complications in multiple layouts using the same markup is extremely challenging.
So in that instance since there is relatively little impact on performance I’ve
accepted defeat and used two separate chunks of markup which get switched on and off appropriately.
However, for the main site elements, such as the login form and the logo and main navigation, these do use identical markup put through some radical transformations. The side navigation at the fullscreen view (which is somewhat counter-intuitively though accurately contained in a header element), is repositioned using the conflicting absolute positioning technique, which until now I had rarely used due to its general, uh, ickiness. In fact, responsive design has seen me indulging in bizarre absolute positioning techniques much more often than before, and I still haven’t quite made peace with that yet… getting flashbacks of Dreamweaver and its ‘layers’ or ‘AP Divs’. Ugh! Stuff of nightmares.
(Whilst I’m ranting about absolute positioning, be careful when declaring vertical percentages on absolutely positioned elements unless you’re dealing with a fixed height context (though remember a ‘fixed’ height can still be responsive). Just as with ordinary absolute positioning, the context for percentages relates to the dimensions of the first positioned parent - not necessarily the most immediate parent. For vertical absolute positioning this means that you are positioning the element relative to a percentage of the context element’s total height - probably not what you want if you’re using position:absolute for responsive tweaking.)
SVG - Embrace unitless measurements
With browser support for SVG improving, many wise soothsayers have heralded (er, re-heralded?) its imminent triumph. With this in mind I took the opportunity to try some SVG (via Raphael) on the home page, and I’m also serving up an SVG logo to retina screens. The amount of duplicate effort involved is a little annoying, but the results on the new iPad are quite amazing.
The subject of responsive embedded images has been conjectured way past breaking point by some exceptionally talented and incredibly patient people. I have nothing to add to that debate. If you’ve managed to read this far down I imagine you’ve probably also read all the ins and outs of the debate and understand that there really is no good answer to this problem yet. Hopefully it won’t be long before we look back on these dark days and wonder how we managed before picture or something like that was implemented…
Good luck and have fun.