Responsive web design is the latest buzzword in the web world. Everyone is making haste to learn about conditioning through media queries, flexible grids and so on and so on. However responsive design as it’s used at the moment is a negative trait and should be avoided at all costs. The reason is, that it’s a negative term by definition.

You are confused a bit, right ? How can it be negative when you’ve seen all those great examples of websites that scale according to your device’s resolution. It seems to work in real life. Well I doubt that. And to throw our beloved responsive design showcases away, and get along with our post, just remember that all those great examples are simple content sites. And to make a long story short, simple content websites don’t justify the time needed to produce a great responsive design. Most of the times a wordpress with a mobile device detection plugin and a great mobile theme does the trick far easier.

For all other cases where you have a more complex website or a web application, where extra time and research is justified, responsive design still won’t do. And this because responsive design destroys the “device scemantics” (I just made up the term). This means that we use devices for a reason. Each device has a purpose and meaning, a reason why we bough it and why we use it.

For example, say I just landed from a plane and want to find quickly the phone number of Hotel X. I got my luggage in one hand, my coat on the other and can’t hold my phone near my face. If you show me a responsive design of the hotel’s website with lots of pictures and small text you’ve just made me angry. I already had trouble typing your website’s URL in the browser and just need a huge link labeled “Contact details” so I can call you and make sure my reservation is ok.

Of course the same is true not just for content but for apps as well. A form might be reasonably large when viewed from a desktop computer but way too big for a tablet or phone. I will want to store a PDF with an printable application form on my computer but will prefer the HTML version in my iPad.

Each device has it’s own natural time and space in our lives, we can’t just serve the same content and functionality everywhere just because we find it easier to have only one version of our website. Each device type has it’s own context and purpose and it’s our duty as web professionals to serve that purpose. Just because your layout doesn’t break on a smaller resolution, does not mean that you provided the functionality your visitor expected.

The way I see it, responsive design is an ugly workflow hack. And as such, it will not improve your long term strategy, whatever device type you consider your priority. Mobile web and tablets are way too important to be left in a hands of a few divs that collapse below each other when the resolution changes. Oh! and three wireframes simply will not do.

Responsive web design techniques should be used as an assistant to overcome different device specifications of the same type. Use these techniques to make sure that your website displays correct across all mobile phones but don’t take the same website to another type of device. If you plan to deploy on mobile and tablets, do yourself a favor and do it properly, with the right amount of planning and research.

Yesterday I was traveling from Athens back to my hometown. I woke up in the middle of the night cause of the endless snorring of one of the guys that shared the cabin with me. As I walked dizzy in the hallway trying to get a grip as to where I am, (and most of all, which floor) I reached the stairs and saw two large numbers right between the two floors. I immediately realized that I was in deck 8 and headed down to grab a coffee. It’s was really great to notice that instead of the millionth boring advertisement, someone thought that huge deck indicators were the way to go.

In the end of the day great user experience is quite simple. All it takes is walking in your user’s shoes. The rest comes quite naturally.

One of the biggest drawbacks of a framework is the absence of built in theming functionality. CodeIgniter is no exception to that rule. Although there are quite a few libraries out there which aim to provide theming support, they don’t feel like being part of the framework. I was annoyed with having to use anything which looks like an ugly hack so I created a library which supports themes in CodeIgniter in a native style.

First of all let’s see how this baby works:

Using themes:

$this->load->theme('demo');
$this->load->view('home');

Loading CSS and Javascript files from within your views:

$this->load->css('/themes/demo/css/styles.css');
$this->load->js('/themes/demo/js/javascript.js');

Yes that was all. It is that simple.

Structure of your files

In the same path as your application folder create a theme folder and inside it a folder with the theme’s name. Also create a folder with the theme’s name inside views.

Inside the download you will see how the demo theme is structured.

/application/views/demo/...    (Your views go here)
/themes/demo/css/...           (CSS files)
/themes/demo/js/...            (Javascript files)
/themes/demo/theme.php         (The theme file itself)

Bonus: Caching control

Have you noticed that sometimes when you update your css or javascript files the changes don’t take effect until the browser empties it’s cache ? This library supports a suffix for all css and javascript files which allows you to control the caching of your files by the browser. Inside the config folder you will find a file mainframe.php. Make sure you autoload it and set a version for your files.

$config['cjsuf'] = '0.1';

When you change that version to say 0.2, browsers will be forced to reload them since they think it is a different file.

Inside the download there is a demo theme to get you started

Download it here

As I’m creating the mobile version of deskhot as well as some new accompanying apps I came across the need to have a single multisite codeigniter base where I can do all the development instead of multiple installations.

What I needed and what this post covers:

• Multiple web applications running from a single codeigniter instance.
• Each application must have it’s own subdomain. For example deskhot.com, m.deskhot.com, pilot.deskhot.com and so on.
• When a user logs in, in one application, he must be logged in, in all applications. So all applications must share the same session data.
• Only one codeigniter system folder so upgrades can done once for all applications/subdomains.
  But also having the flexibility to have a certain application using an older system folder if I see fit in the future.

So let’s get into action

1. Add the subdomains in your hosts file

All operating systems have a hosts file which helps map ip addresses to domains. Of course you should add all the subdomains in your hosts file. Here is the location of the hosts file for each operating system.

This is how my hosts file looks like

127.0.0.1        deskhot.d
127.0.0.1        m.deskhot.d
127.0.0.1        pilot.deskhot.d

2. Add a server alias in the apache config

The next step is configuring your virtual hosts so you can have apache know about your subdomains. In my system the vhosts file is located in /apache/conf/extra/httpd-vhosts.conf. This will be different in your system so just do a search and you’ll find it. There will be some default configuration for localhost already there.

Add the following in the end of the file:

<VirtualHost *:80>
    DocumentRoot "/path-to-your-document-root/your-domain.tld"
    ServerName domain.tld
    ServerAlias *.domain.tld
</VirtualHost>

For example my vhosts file looks like this (in a windows system)

<VirtualHost *:80>
    DocumentRoot "/Users/Username/www/DemianLabs/Deskhot.com"
    ServerName deskhot.d
    ServerAlias *.deskhot.d
</VirtualHost>

As you have guesses I access my development version through http://deskhot.d. You need to change the path and domain in the above lines to suit your own configuration.

3. Create your applications

Grab a fresh CodeIgniter and drop it in the folder where you would normaly do your single site development. Then make a copy of application folder for each of your subdomains. A tidy way to name all those application folders is to follow the patern application_subdomain. So for example my folders look like this:

/application                  // for the main site: deskhot.d
/application_m                // for m.deskhot.d
/application_pilot            // for pilot.deskhot.d
/system                       // the system folder
/user_guide                   // the user guide
/index.php
/license.txt

Once again change deskhot to your desired domain.

Next we need to tell CodeIgniter which application folder will be active depending on the url. To do that, open the index.php file and find the line containing $application_folder = ‘application'; and replace it with the following code:

switch ($_SERVER['HTTP_HOST']){
        case 'm.deskhot.d':
            $application_folder = 'application_m';
        break;

        case 'pilot.deskhot.d':
            $application_folder = 'application_pilot';
        break;

        default :
            $application_folder = 'application';
}

Once again change deskhot to your desired domain.

4. Configure all applications to share the same cookie domain

In each application folder find the file config/config.php and find the line $config[‘cookie_domain’]    = “”;. It’s around line 260.

Replace it with something like this depending on your domain:

$config['cookie_domain']    = ".deskhot.d";

Notice that this must be the same line in all config/config.php files in all application folders. This will ensure that all applications will read the same cookie and therefore use the same session data.

5. Specify a different system folder for each application (optional)

We can do the same trick we did in step 3 for the system folder as well. So for example we can have the following folders:

/system             // The latest CodeIgniter
/system_201         // Version 2.0.1
/system_202         // Version 2.0.2
.... and so on

To do that open index.php again and delete the line (around 65) $system_path = ‘system';

Then change the code we used in step 3 to look like this:

switch ($_SERVER['HTTP_HOST']){
        case 'm.deskhot.d':
            $application_folder = 'application_m';
            $system_path = 'system';
        break;

        case 'pilot.deskhot.d':
            $application_folder = 'application_pilot';
            $system_path = 'system_201';
        break;

        default :
            $application_folder = 'application';
            $system_path = 'system';
 }

In this example all applications use the system folder except pilot, which is using system_201. This way you can upgrade CodeIgniter to a new version only for a specific application and leave the other ones using an older version. This can be handy when you want to do your post-upgrade testing in stages.

If you have any comments or questions I’d be glad to hear them on twitter or google+.
In a few days I’ll be writting a new post about how you can make all the applications share some common resources like helpers.

When you’re about to start a new project it’s the right time to move to something new. Sometimes it’s a new CSS or Javascript framework, sometimes it’s a new version control system, in my case it was moving from PHP/CodeIgniter to Ruby/Ruby on Rails.

I started out in my windows 7 laptop and came across a myriad of problems. The first time there was encoding problems. Google came to the rescue. Then I had to configure the system PATH variable a few times since there was no documentation to tell me what to configure. It worked out fine. After a lot of hours I reached the point where I have a working Rails 3 installation but no virtual hosts and of course no sub domains. Unfortunately Passenger doesn’t work on windows and it’s developers don’t plan a release anytime soon. So since I can’t find documentation on virtual hosts with ruby and I’m quite tired of googling I gave up on the idea.

Next stop was Ubuntu. The Rails version in the latest Ubuntu is still 2.x. There are no official repositories to give you a Rails 3 installation out of the box so the most reasonable option is RVM. To make a long story short, after a few hours of trying, it didn’t work. I’m quite well aware that other people have had more success than me but unfortunately for me things didn’t work out the way I wanted them to.

In PHP/apache world there are installers for windows that just work out of the box. In any Linux distribution things are even better. So since I don’t own a mac and I can’t spare any more time things are quite clear. The way I see it deployment for Rails is still lacking in options. Maybe Rails is a great way to build web applications and maybe it could save me time in the long run. But the way things are now, it just waists me time. So I’m sticking with CodeIgniter and I’ll revisit Rails next year when it will hopefully be more mature.