Responsive Design, circa 2005

Innovation spawns from problems you didn’t know were problems in the first place.

This is how we built the first version of UX Magazine ( back in 2005.

A salvaged 2006 update I found in my file cemetery (

In 2005 there were no smart phones or tablets, just various screen sizes — and not that many of those either. So, to say we were designing for multiple screens and needed to accommodate our content for mobile and tablets is just an exaggeration. To be honest, it was just a cool “gimmick” we thought of adding to the design of UX Magazine because it just made sense to design for different screen sizes. I was on a laptop and Alex was using a desktop — so obviously we were looking at different things. We wanted to fix that, for everyone.

We did not actually stop and think of what we were doing. We never questioned the feasibility of the task. We just started doing stuff.

Back then, we didn’t have media queries or anything specifically describing this behavior. In fact, it was us against the browser war.

Keep in mind that I’m not a programmer, I’m just a designer that enjoys conjuring up solutions to problems I don’t have — which usually gets me in more trouble than I anticipate.

So, where did I begin? Of course I started with the tools I had…

Underlying stack

It was obvious from the beginning that I’d use Javascript to handle all the browser functions, in order to determine screen & browser widths. And I had also decided to implement separate CSS files for each state (narrow & wide). Not far from what we’re doing today with media queries, in fact.


My initial plan was to simply show and hide content depending on the width of the browser using specific CSS files for each of the two states. This meant that I’d have duplicate content in the HTML, but hey… I never said it would be elegant.

I created three CSS files, of which only two would be active at any given time. There would be a base.css for all the basic styling, the 1024.css for the wide version and of course the 800.css for the narrow version of the site.

Javascript would fire an onLoad & onResize script which in turn would detect the browser width and toggle between the 1024.css and 800.css files.


First issues

When I created the first prototype I ran into some issues I did not expect. For starters, when switching between CSS files, the whole site would flicker. Think of it like this: between the two states narrow & wide, the site would lose it’s styling entirely, and reload with the new CSS in place. Not very smooth, sir!

The initial prototype of — (

It took me quite some time before I discovered the culprit. Apparently, importing CSS with “@IMPORT” forced all the CSS to reload — slowly. Till this day, I still don’t know why this happened, but I solved it by simply using a LINK tag.

More issues

My second largest issue was that the site would load by default with the wide CSS, and if it detected your browser was narrow, it would toggle to the narrow version. For every page. For every click. Which of course was not ideal. I needed a way to remember the previous setting in order to load the next page with the right CSS, and avoid the visual clutter of having things move around all the time.

And that’s when I thought of cookies. Yeah, I did that.

Every time a page loaded, a script would run to check for a specific cookie which I stored the previous state. If there was a cookie, I’d read it and load the appropriate CSS, if not I’d check for browser width and so on…

Did it work?

Hell yeah! It wasn’t elegant or even efficient, but we were delivering a better experience to our visitors, no matter what they were viewing UX Magazine on.

Of course we never called it responsive design. I think Alex and I coined it as adaptive design. Patatos — Patatos.

Here’s a working copy of a 2006 update we did to the design. The underlying stack is all there…

I’m Constantinos Demetriadis, a digital designer based in Athens, Greece. I’ve been designing since 1998. Find out more about me at