I tend to do the bulk of my front-end coding directly in the browser via a combination of the Web Developer toolbar for CSS and Firebug for tweaking HTML. Not having to constantly switch between applications or save or refresh suits me wonderfully. (Though of course I need to flip back to my proper code editor for committing my changes when I'm happy). It's not a flawless workflow but I like it and it's super quick.

To help with responsive designs I threw together this quick responsive persona for Firefox which makes it really quick to instantly see roughly what width you're at, so I can happily code my CSS mobile-first and keep sliding the sidebar divider left and right to check everything works at all resolutions and spot where media query breakpoints should occur.

Try the persona on for size:

http://www.getpersonas.com/en-US/persona/469407

​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.

Branding

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.

I know of some lone freelancers whose websites are written to sound like they employ a small army of full-timers. Whilst this may inspire confidence with certain types of client, to me it's downright dishonest. 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.

Design

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).

Semantic Sacrifice

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 embraced pragmatism 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.)

JavaScript is no longer your dirty little secret

Responsive designs push the boundaries of what browsers are capable of. Heck, they even push the boundaries of the W3C HTML & CSS specifications. Where once it was rightly shameful to allow JavaScript anywhere near your layout techniques, in some cases it's becoming a necessary evil. Certainly everything we've learnt over the past decade about graceful degradation and progressive enhancement still applies, and JS should still be your last resort for layout fixes - but we need to embrace pragmatism and drop the stigma attached to using a few JS layout shims.

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.

Responsive images

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.

James

The flexibility of ExpressionEngine allows you to create just about any crazy URL structure you like for your site or app. Once you get a taste of that power it's tempting to scamper off with your new toy and plunge into schemes of pure lunacy.

Before you do, it might be an idea to make sure you're not missing out on some of the powerful URL interpreting that you get for free, or worse, painting yourself into a proverbial corner and having to use inefficient "advanced" conditionals to get yourself out.

Why bother?

The rather super ExpressionEngine documentation is replete with references to how URLs are interpreted, but let's face it: (despite having a section dedicated to the subject) those references are sprinkled all over the place like some kind of just-out-of-reach clove-studded honey-roast ham.

Here's my attempt at visually pulling together that information:

The ExpressionEngine URL schematic »

Sometimes it's fun to be a lunatic.

But please: be so on purpose.

Hopefully it'll make you pause before wasting an afternoon coding a brilliant and impenetrable set of templates that do exactly what related_categories_mode="on" does, or make you think twice before blindly installing third party add-ons to create old fashioned static pages and then coming up with ingenious workarounds to regain bits of what you've lost.

Beginners' luck?

If you're new to ExpressionEngine and haven't yet been caught out by the dynamic="no" parameter, or have no idea what it does, the URL schematic should also help you get your head around it. At the very least it should become clear that ExpressionEngine attempts to decipher 2 things from your URL:

• A template
• A set of entries from which to pull data, filtered to your whims (categories, dates and pagination)

Combined with some of these other ExpressionEngine resources you could be halfway to EE superstar status already...

War stories?

What URL approach do you usually adopt? The 'official' line from Ellislab -- that you should be using template_group/template -- makes for some pretty long urls and is not technically necessary. Take the shortcuts though, and you might regret it later.