There have been many talks, blog posts, books, twitter conversations and so on, about the best way of using "responsive web design".

I've been taking it all in, asking questions, and coming up with my own thoughts from my experiences using the technique as part of my own day to day professional service.

There are some great ideas and methods of implementation being championed, that should be taken on-board and considered. But, I will say this:

There is more than one way to skin a cat, and when it comes to design, nothing is ever as black and white as many well-intentioned developers seem to sometimes suggest.

This is how I see many of the hot topics currently being debated:

You say adaptive, I say responsive

This is actually quite a big thing. I've read many describing a site as being adaptive, when it is also responsive. Or calling a site responsive when it is actually merely adaptive.

Pedantic for me to pick up on naming semantics, perhaps. But I can't help thinking that when clients become a bit more savvy on the meaning of these techniques, they may pick-up on the differences - and if you've quoted to make a product responsive, and yet what you deliver is only adaptive, the client could come out and say "well, me no pay".

So what's the difference?

Adaptive is - in part - where a website adjusts in layout according to breakpoints designated by criteria such as width, height, orientation etc. It also incorporates other progressive enhancement techniques and thinking to address the needs of form and functionality at both a resolution and device specific level  - so not just CSS, but also mark-up and JavaScript considerations.

Responsive can also be everything adaptive, but is also the application of a fluid / liquid layout between the designated breakpoints - so essentially the design adjusts and re-sizes to any resolution, not just when specified by a break-point.

^ I'll be mainly referring to the layout layer of the above in the rest of this post, and not the other facets of progressive enhancement.

The Photoshop comp is dead? Long live the Photoshop comp?

I actually use Fireworks for laying out initial wire-frames and comps, but you get the idea.

Now, this is a subject that actually does annoy me slightly. There are a few who suggest that flat visual designs should no longer play a part in the process of web design. It is no coincidence that many of those championing such thinking are, I would say, more "developers" than "designers". Possibly the result of a more binary mindset. A standpoint of perhaps control over expression.

Now there are valid reasons for going straight to the browser when designing. They are:

1. The web is an environment where users can click, scroll, and interact, and this can't be demonstrated via a flat and static jpeg
2. Using Progressive Enhancement and Graceful Degradation techniques mean that what users see and experience can be different depending on the browser and browser version, and this can't be demonstrated via a flat and static jpeg
3. The web - more than ever - is a fluid environment, with different screen resolutions and devices meaning a different experience and layout under different circumstances, and this can't be demonstrated via flat and stale jaffa-cake

OK. Let's deal with each of the above in turn:

1. The web is an environment where users can click, scroll, and interact

So the point here is that a flat visual can not adjust to browser resolution, can't show dynamic effects on hover and click etc. You can't scroll and navigate around. Basically: surprise, surprise, a flat visual isn't a web page.

I agree that to demo the above criteria to the client, you would need to show them an actual work-in-progress web page. But that's not to say that anything that is created before this stage - outside of the browser - has no use in the design process at all.

I would counter the notion with the fact that flat visual designs are not for presenting a total solution for the final product. The same way that an architects drawing doesn't fully communicate the final solution of an actual sized, three dimensional solid building - filled with furniture, decor and moving people. The smell of a recent dinner in the air. Dog barking in the garden.

Process is not outcome. So in that sense:

Wire-frames and flat visual designs are a means to an end.

Graphical tools - be that a pen and paper or some design software - are quick and effective environments for dealing with certain aspects of a part of the design process.

2. Using Progressive Enhancement and Graceful Degradation techniques mean that what users see and experience can be different depending on the browser and browser version

So the point here is that your visual design may have all the shiny-shiny CSS3 included, only to look degraded, or at the very least: different, at the coding stage when your client views it in their nasty IE7 browser.

Should the solution to this be to design in the browser so that the client isn't given false expectations? Perhaps. Or could this also be achieved by communicating clearly to your client what the visual represents, and which areas are likely to differ based on browser?

I would suggest educating the client into understanding that the web is experienced in different ways on different browsers and media, is a better long-term approach than allowing the client to think that the big blue "e" that they click on their desktop is the Internet. But regardless of ditching comps or not, I would say attempting to help your client understand the environment in which the product they are paying you to create will exist, is only a good thing for all concerned.

3. The web - more than ever - is a fluid environment, with different screen resolutions and devices meaning a different experience and layout under different circumstances

So how can we possibly design flat visuals for all the different breakpoints and in all different environments - each displaying the final product in slightly (or sometimes quite drastically) different ways?

We can't. But we can use our tools to solve certain problems. Again, a means to an end.

I would suggest that as things stand now (and of course this can, and will change) we have the situation where there could be many potential breakpoints in a design, but actually only two or three possible key breakpoints when considering a standard web project as a whole.

Below is how I see the basic scale at present (I'm aware there are resolutions higher than 1920 btw):

So essentially you have two differing areas (A and B on the diagram) which are regions that have the potential to be dramatically different from one another - based on them being either side of a possible "hard" break-point, and their position at either end of the scale.

They are, of course, A) the hand-held-small-size-probably-touch-screen experience, and B) the desktop / laptop experience.

You have that fuzzy area in between where there can be both kinds of experiences (small laptops sharing resolutions with tablets and such).

Overall - regardless of resolution - you apply general fluidity on appropriate elements, and also other minor breakpoints placed as and when things get "funky" in your design on re-size < so yes, here are some perfect regions and stages where working "in the browser" is probably your best approach.

But I still feel it totally effective, and often necessary, to be designing outside of the browser for those core resolutions at - or around - points A and B on the diagram.

I don't need HTML and CSS to show me that 2 boxes I've scribbled side by side on a piece of paper will need to re-size and sit on top of each other if the paper then becomes a third of the width.

Browser first? Brain first. If you understand the web environment, you're brain is a much more powerful tool than the browser. And thank goodness for that.

The need to write HTML and CSS to create an element that you don't even know should be in that position - or even on the page at all - is a waste of production time. It's borderline technical posturing.

It's oh so quiet, it's oh so still ...

Here's another thing to consider:

Once you've opened your browser, re-sized your window, clicked around, searched, dragged, scrolled, you get to a point where you have reached your intended destination. Where you have reached the content you wish to consume. And at this point, what is happening on screen?

Nothing.

It is at these points in the user experience where a design tool (software generated visuals; hand rendered sketches) for dealing with these "quiet" moments where everything is still and not being interacted with, is entirely useful and appropriate.

By suggesting you limit the methods by which you can plan and solve a design project - web or other - will only narrow your output. It will de-tool you at a time when I think we need all our tools - old and new - to get to grips with an ever demanding array of design problems. HTML and CSS - although the final output of your design - is a medium not known for enabling artist, expressive creation. It's not an environment where you can make wild emotional brushstrokes that lead to unexpected and positive mistakes. Of course it's not, and it's not intended to. My point is that you are designing. HTML and CSS coding is predominately the production stage of the design ideas.

The same way a car designer isn't stood in the middle of the motorway welding metal when coming up with initial ideas for a new car, why do you need to be immediately in a websites final environment - the browser - when going through an initial design process? You need to understand it, but not necessarily be in it.

Also, on a side note, you should check out Robbie Manson's talk at the 2012 New Adventures in  Web Design conference: "The Mindful Designer" (particularly about 4 minutes in, to about 13 minutes in - although the whole talk is very good). He puts across his points much more eloquently that what I can haz :)

But moving on ...

Fixed on liquid-only?

I would agree that it makes perfect sense to try and apply fluid / liquid elements wherever possible. When you consider all the variations in device widths and heights we have to deal with, adding %s and ems covers a lot of bases, and allows content to fill spaces without the need for an unmanageable number of breakpoints and extra code.

But I wouldn't dismiss fixed values entirely. I think in doing so you are almost limiting the flexibility that media queries can offer, in that you can mix and match liquid and fixed values to address the needs of a design under different circumstances.

Perhaps you have a liquid design that - when viewed at a hi-res desktop level - looks overly stretched, with content not flowing nicely. Perhaps the design would benefit from the aesthetic "breathing space" and a controlled order that a fixed width design brings. In this case you can include a media query that perhaps sets a fixed width container above a certain resolution, and liquid below. Perhaps some areas remain fixed and others flow. Perhaps some grow larger in overall relative terms, while others remain the same. Perhaps. Perhaps. Perhaps. Let the content and / or the needs of the project dictate.

We are lucky in that we have an ever increasing set of tools at our disposal to solve these problems.You could increase the overall scale of things, so rather than, say, a fixed font size filling a liquid container, the font itself increases along with the container, so the "relative" size of things remains constant. But, again, there may be circumstances that at a certain point this begins to look odd.

We are constantly juggling the manageability of the code, the accessibility of the content, and how aesthetically pleasing everything comes together. I guess we've always been doing this, but now on a different level, as we're not just looking at it all on one canvas with a more and less constant method of user interaction. We're adjusting down to 780 and assessing. Then 480. 320. So on. And all the points in between. And all the time we are assessing all the points that come with designing for the web.

Liquid / fluid approaches will be a great friend in these new times, along with items changing position and elements that scale. But we're going to need all our tools to get things right in different circumstances, and that also means fixed values. So a responsive design doesn't mean you have to be entirely fluid. It just means it is "responding" to it's environment, and how you do this will be different based on the challenges of individual projects, the elements therein, and under what circumstances they are being viewed and interacted with.

Fixed values will be needed - perhaps not as much, but don't feel you are failing if you have to use them in some circumstances. Sometimes a fixed element will work better than a fluid one - even with a bit of scrolling here and there.

I like my phone more than you

Now, depending on what you read, mobile first can mean one thing, or another, or both. Or not mean any of them. Confused? I am. And I'm not. I'm messing. Let me explain:

Firstly, there is mobile first in terms of "design thinking"

So the designer thinks about a solution for mobile first before regular desktop considerations, to help focus their attention on core elements and the importance they have on the screen and to the user. It also means you are putting "latest technology" and an "emerging market" first in your thoughts. A very progressive way of thinking.

I would suggest this is an intelligent angle of approaching a project, but there is the argument of why a developer isn't adopting this kind of - what I would call - "content first" thinking into the project regardless of device and resolution

The boundaries of mobile devices and desktop computers are blurring as it is. Many handheld device processors far outperform those of desktop PCs, and more and more people lounge around at home using their devices on WiFi to browse and do many of the things they used to do on their computers and / or laptops. I know I do.

So whilst I support the idea that these new devices will open a developers mind to new technology and ways of thinking, I don't necessarily think you have to start at mobile to achieve a focused, content led solution that has the right elements, in the right place and at the right size - regardless of resolution. This kind of thinking is about content, and not really about device or resolution.

Secondly you have mobile first in terms of which styles you choose to deliver in your CSS first

This is where I'm still undecided.

I tend to style global rules first (rules that apply regardless of resolution and such), and then use media queries to feed the relevant styles to the relevant resolutions.

Now, this would mean that the fallback for browsers that have no support for media queries would only be the global "soup" styles - and therefore things will look a bit of a mess.

A solution to this is to use respond.js or similar to plug the lack of support and deliver the styles as if supported. Or - as I am doing - use if statements to feed desktop styles to IE8 and under. I like this approach, as at desktop level - IE or not - a mobile resolution layout is not a well considered solution. IE8 at 1280 with a "mobile" layout displaying just doesn't feel like a graceful fallback to me.

But then what about the browsers that aren't IE that have no support for media queries ? They'll only be able to render global "soup", and that's bad.

This is where I think it's a close call. The main on-radar browsers that have no support for media queries (bar IE8 and less) are: Firefox 3, Safari 3, Opera 9 and Chrome 3. The user stats for these combined are going to be close to under 1% and falling. Part of me wants my code to be organised without the need for a worse case scenario fallback, yet part of me doesn't want to deliver a soupy mess regardless of user statistics. Swings and roundabouts. The jury's out.

To conclude

Um. Yeah. What I've said above. But in less words :)

I've not even touched upon debates about on-page HTML data (the <picture> tag etc.), or the application of resolution dependant JavaScript. I'm not going to touch upon them either, as this post is far too wordy.

But I know you have comments for me. Letsby Avenue.