Responsive Web Design - Getting started

Responsive Web Design, how it all started?

 

We started our online project bestbars.in to list best bars, pubs, and cocktail lounges from all around the world. Everything was fine until we faced the reality - mobile web. At that point we realized that our website is not really mobile friendly.

So we (being software developers and not super advanced in terms of SEO) thought that we had following options:

1. subdomain (like m.bestbars.in)
2. subfolder (like root/mobile)

We had some compilations with our hosting provider when tried to implement first option, since we had to buy extra addons and we did not want to invest more money into the hosting.
So we chose option number two and started happily implementing mobile version, pretty much duplicating existing functionality. We used URL rewrite to translate requests like bestbars.in/mobile/pagename into bestbars/m/page to minimize the URL and were pretty happy with the result...

 

That was until we had a business meeting with our good friend and future partner of GPTeam V.O.F. Luke Miller, the SEO guru. Luke explained to us some basics of SEO and advantages of having one destination page for both full and mobile version. The logic is pretty simple: let's say you have a page with mojito recipe and a copy of this page for mobile devices, something like this:
domain/mojito and domain/m/mojito
To search engines these are two different pages. Let' say you have 10 links to a full version and 10 links to a mobile version. It total you think you would have 20 backlinks, but in real life you have 10 and 10. Let's say if there is another website awesomerecipes.ccc/mojito with 12 backlinks, it would appear in search results before you simply because 12 is more then each of 10 links you got for each page individually. If you had one page that looked perfect on any device you would have 20 links and would be above awesomerecipes.ccc.

 

So here we are, googling where to start with responsive web design. There are quite a few very nice web sites out there.
We started our journey from html5rocks.com which we found very useful.
Basically the main idea is to have content driven HTML code to which you apply different css styles depending on your client's browser and device type.

 

What is content driven HTML? Well if you ditch all the styles on your website and look at it again you will see nothing but plain text. This is how search engines see your web site.

So drawing from an endless list, the essentials you must ensure are:

1. Your content is properly structured
2. You are using h1, h2,... tags
3. You have alt attributes on your images
4. Your most valuable content appears on the page at the top
5. Less important after that, as you work down the page.

So this is the standard thing you find when start searching for some tips on how to improve your website so it is more visible on the web.

 

Then we started thinking about how to split our css files so we don't have to duplicate lots of properties in multiple files for full version, mobile version, and old browsers etc.

We decided to have 3 style sheets:

1. Style sheet with all the beauty bits, fonts, colors, boarders etc.
2. Style sheet with all containers with positioning specified for users running on IE below version 9 (this is when @media tag is not supported and everything looks ugly)
3. Style sheet with styles for mobile version, and tablet version.

We also learned what is called breakpoints. These are points when your website's appearance will adjust to the device width and change style and layout to suit.

 

We did some research on how to define those breakpoints. Initially we wanted to have a fixed layout on desktops (when browser doesn't support any HTML5). So we fixed min-width on body tag to 62.5em (1000px) in second css file:

body
{
    min-width: 62.5em;
}

 

So pretty much if you are using IE8 on a stardard laptop/PC the page will look correct, but if you open our website when your screen resolution is 800x600, you would have scroll bars all over the place.. but to be honest, it is your own fault. This is our breakpoint for desktops - 62.5em.

 

Next stop is tablets, everything with slightly smaller screens. We don't want to have lots of information our users just cannot read because it's so tiny. We also want to keep links usable by touch and prevent it being too crowded, so we adjust our layout for tablets.
Usually you would get recommendation to set up breakpoints for tablets between 480 and 768 pixels, but we were lazy and did not want to alter our layout between 768 and 1000 so we decided to extend it up to 1000px. And the lower boundary is 480px (which is 30em).

 

Anything under 30em (480px) would be our smartphones, this we can also keep the layout simple and even less crowded, while still encorporating the touch functionality used within tablet layout.

 

Btw, here is a nice resource to do you conversion from pixels to em and vice versa: PxtoEM

 

Okay, let me finish with this post, since it is already too long. We'll jump straight to CSS and HTML in one of the following posts. So don't go too far :-)

 

Cheers,
Your GPTeam