Ramana Lokanathan

Random Ramblings of a Techie


Responsive Web Design (RWD) – Part 2

Since last year, I have been reading about Responsive Web Design (RWD). I believe it is an important and timely paradigm shift to deal with:

In this blog, I wanted to spend more time on the nuts and bolts of RWD. For Starters, I recommend reading this formative article by Ethan Marcotte that explains the need for Responsive Web Design succinctly.

Then check out this site to get a visual grasp of RWD principles.

At the core of it, the RWD is about the following the three fundamental concepts:

  • Fluid Layouts
  • Media Queries
  • Flexible Media

The recent advancements in HTML5, CSS3 and JavaScript languages have made the development of responsive websites a bit easier. Lets look at these concepts briefly:

Fluid Layouts:

Responsive websites use Fluid layouts that work seamlessly in multiple device screen & orientations.

Using “Viewport” meta tag is an effective way to control the layout for many screens. Here is a short example of how to control the Viewport:

1. Using viewport meta tag (or)

  <head><meta name="viewport" content="width=device-width, initial-scale=1"></head>

2. @viewport CSS rule

  @viewport {
    width: 480px;
    zoom: 1;

Learn more about Viewport here, and about the Syntax here.

Check out this site that demonstrates fluid layout beautifully.

We also need to understand how pixels work in various devices. For example both iPhone 3 & iPhone4 have the same screen size of 3.5inches, but iPhone3 has 320×480 resolution whereas iPhone 4 has 640×960. How do we make a picture (or text) look the same in a screen that has twice the resolution of the other? Thankfully, CSS provides this feature called “reference pixel” (aka CSS pixel) which establishes an optical standard for the length of the pixel which is independent of the “hardware pixel”.

Learn more about Hardware Pixel and Reference Pixel here

Flexible Media:

Using Vector images instead of Bitmap images gives you more flexibility, as they are resolution independent. Keep in mind that Vector file sizes are larger. Also, Vector images get re-drawn with each refresh. Use it as circumstance permits. You can learn more about Vector graphics here, and here.

Another way to control images is by using CSS based Graphics. These are ideal for Buttons, Background images, etc.

Media Queries:

Media queries allows you to write styles that respond to different styles or orientations. The “media” tags have been around since CSS 2.x, but CSS3 has extended its features in a meaningful way.

Here is a short example:

<link rel="stylesheet" href="global-small.css" media="screen and (min-width: 480px) and (max-width: 767px)">

Media queries allows us to create “break points” not just based on width, but also based on (device-)width, (device-)height, orientation, color, resolution, etc.

We can also use media query to surround a specific style, as shown below:

@media only screen and (max-width: 480px) {
        div.swapimg { background: url(&#8220;lowres-bg.png&#8221;); }

The above method allows us to use a specific background image for any screen less than 480px, and also to download it only as needed (as a background image).

The W3C Media Queries Doc is an excellent reference for advanced features. I also recommend reading this article.

While I mentioned just the basic concepts above, there is lot more to Responsive Design, and especially when it comes to making the design work effectively in various browser/os/screen/device combinations. I am no way an expert on CSS or Responsive Design techniques, but I have learned a lot. My perspective is that, there are many valid use cases where forking the main codebase to create a native Android, iOS, and Blackberry app becomes expensive to build and maintain. And in many cases, that might not be enough (iPad, Kindle, etc). In comparison, a well thought out responsive website will go a long way in meeting the business needs in a cost effective way.

I am not advocating that every website should quit developing native Mobile Apps and should go the responsive Mobile Web design route. Facebook famously decided to build native apps for each Mobile OS, after they realized that the Mobile Web site was not meeting their needs. Each business use case is different, but for majority of the Long Tail use cases, a Responsive Web site will do magic.

I recommend checking out my favorite sites to take note on good responsive design techniques.

My Favorite Responsive Sites:

Hope it helps!


How to move WordPress to its own Directory?

By now you know that I am a big fan of WordPress. These days, I run multiple websites using WordPress, all using one Web Hosting service. When running multiple WordPress sites, a requirement is to move each WordPress site under its own directory under your “www” directory. The WordPress site has a nice article on how to get this done. Check it out here.

The steps in that article works mostly except one part where we need to copy the .htaccess and index.php file to both the website root dir and your WordPress dir. Assuming your website root is /home/user/www and your WordPress home dir is /home/user/www/blog/, then here is how the .htaccess in both those did should look like below:

For your: /home/user/www/.htaccess file :
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$&; &#8211; [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
For your: /home/user/www/blog/.htaccess file :
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /blog/
RewriteRule ^index\.php$&; &#8211; [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
# END WordPress

Once you make the above minor changes to the .htaccess file, you will be all set. Your site http://yourdomain.com/ will now display the WordPress blog from http://yourdomain.com/blog

Hope it works!

While we are on the topic of .htaccess file, you should know by now that when we deal with hosting providers where we don’t have our own web servers and root access, then, the .htaccess file is the only way to deal with making Apache web server configurations. This site provides some basic directives that you can add to the .htaccess file for bread-and-butter configurations such as URL Re-writes, Cache-Control, Directory Browsing, etc.

Have fun.


My evolution from building custom Personal Web Sites to using WordPress

Back in the mid 90s, I used to create my personal website from scratch. It was lot of fun! Since I was a student, and since we had access to servers, it was a great way to learn.

When I got out of school, there was no cost-effective way to host my own website. In those days, there were not many fancy website building platforms. The closest thing to having your own site without too much time and money was to use GeoCities. Yes, i tried that too for a little while…

In early 2000, I settled on using my own Windows Desktop to host the site (with just Apache web server and CGI). Since I did not have a static IP address, I used one of those free Dynamic IP services to point my domain name to my Windows desktop. As you can imagine, the IP address changed very often, and hence my website will go down frequently. It was not fun.

Around that time, Broadband internet became affordable, and Linux became popular as a server. This led me to experiment with running my own web server using Linux box and a Static IP. It was great! I used Debian Linux, Apache, CGI, PHP, and MySQL. I also installed my own MovableType instance for Blogging. I learnt a lot from this experience. But, it turned out to be more expensive and I wasn’t making any good use of it.

So around Mid 2000’s I started looking into hosting providers and found them to be relatively cheap. For about $10/month, you get your own hard disk space, Linux, Apache, MySQL and PHP (LAMP), and many other site building softwares. I ended up moving my site to a hosting provider. It worked out very well, i.e., I was abstracted from the pains of day-to-day site management. This approach allowed me to use all the good softwares I like, with some minor compromises on Security, Computing Space/resources, and root privileges.

I was still creating my own web pages from scratch…

I did not like the fact that my site got stale, and that it took time to make any serious site updates (changing layout, adding new features, etc). I looked at some of my friends’ websites, and liked the simplicity of using a blog as a primary web site. After all, the purpose of a website is to share things with the world.

So, recently, while I was looking into cheaper hosting companies, I decided to look at using blogging softwares as my primary website. I played with WordPress.com, Blogger.com, etc., and quickly realized that I need my own Blogging software to do all those fancy customizations, and to fiddle with the code. As a tech geek, I felt too restricted using a hosted blog platform. After reading few reviews, I quickly settled on WordPress software – the swiss-army knife of Blog softwares. I found a web hosting company that is cheap ($4/month), and provides ready to install WordPress software, among others.

I have been using WordPress for couple of weeks now, and it is fun! It is very easy to change themes, add pages, and update content. I am now rejuvenated to Blog again! I wish I had done this early on. I plan to stick with this approach until I move to the next step, which is hosting my site using Amazon EC2 (more on it soon…).

So friends, TWO THUMBS UP for WordPress.Org. I highly recommend setting up your own instance of WordPress software and use it as your Personal Website.


My First Post!

Hi All,

I just moved my domain to a new ISP.  Please bear with me while I setup my blog.  Thank you and please visit again.