The trend has been going on for quite a while and it will continue. That is, the usage of mobile devices in various sizes are increasingly being used to browse the web for every day that goes by. For most, but not all, a mobile friendly view of a company site is a must. I been fortunate enough to be able to work on three different paths to get there and seen some of the good and bad in them.
Getting a mobile friendly version of a web site is not just about graphical design and how to implement it in HTML and CSS. A broader view is required to take an informed decision on how we can get from a concept level of “an optimized web site for various screen sizes and capabilities” to actually getting there. What I am referring to is the fact that your hosting environment will play a big part in what approach to take when solving specific problems. Application layers such as load balancer, cache and the number of web servers play a big role in what can, and cannot be done. Or perhaps, what can be done good, and what can be worked around.
If you are in a situation where the environment is already set. You will have to adapt to it. In a way, it could make your decision on what path to go easier since you are inside of this square box and the rules are already set. If you are lucky enough to be able to change or build a new environment that suites your particular need, there will be a lot more to think about and consider. But in the end, if you play your cards right, you will end up with a sleek solution that is more likely to be optimized for your needs. However, getting there might take some time.
So what are these paths I am writing about? I am referring to the domain usage, and going responsive or not.Â Lets assume that you want your web site to have this typical desktop view that you have today, and in addition to that you want to be able to serve up a more mobile optimized view that is more friendly to the capabilities of mobile devices. Please note that this is not the same as scaling down functionality, in fact, mobile devices typically have more capabilities than a standard desktop browser to make a site “context aware” (GPS, gyro, camera, etc.).
Assume that you have a website. Going there with a desktop browser would result in a desktop view/version, while going there with a mobile device would result in a mobile view/version. Sounds easy enough, does it not? A few questions to think about that is typically common for all three paths I am about to describe are:
So you have your site at www.domain.com. You go to that domain with a desktop browser and it will show the desktop version. Entering the exact same domain on a mobile device would get you the mobile version.
In addition to the common questions, you need to ask yourself:
The positive things about this solution is that it is fairly easy to implement. You know that when you are serving the mobile version, you have your separate versions of images, scripts, ads an so on. They can be cached separately and optimized for each version of the site. No cross-domain requests, cookies can be shared and so on.
A mistake that I seen some people do, and this applies to all three paths, is that the mobile version is optimized for a particular device. That makes me truly upset. If you are targeting a specific device, then just go and write a native app instead and get it truly optimized.
Having a desktop version at www.domain.com and a mobile version on mobile.domain.com is another way to go. In addition to the common questions to ask yourself, all the questions for the previous version still applies and in addition to those, comes a few more:
As you can see the questions count increase. And for sure there will be more as the project progress. These questions all add to the complexity of your solution. The choice between this path and the previous typically boils down to how your environment is setup, how your CMS works, and in some cases its about the analytics since it has economical aspects.
Responsive Web Design (RWD) is working better and better as the web browsers and the HTML standard evolves. Having the same version delivered to both mobile and desktop browsers and then adjust the view depending on capabilities and properties of the browser/device introduces a whole different set of questions. But it all depends on how far you are willing to go.
In addition to the common questions you need to ask yourself:
Should we design mobile first?
Should we implement mobile first?
And of course, you will not be targeting specific devices, you will target capabilities and properties. Right?
RWD is can be great fun, and dreadful at times. It certainly introduced a lot of challenges that we have not face prior to RWD. To point out a few of them the ad perspective is one of those areas where the end result has long term economical aspects. Some issues with ads are:
Since many ads are implemented using iFrames, Flash or a mixture or all kinds of implementations, scaling and loading can get really tricky, specially on old Internet Explorer versions.
Another area in need for some though are images. I recently visited a responsive blog weighing in at just under 78 MB due to usage of wrongly sized images.Â Having the right resolution showing up for the right view can be tricky.
It certainly puts some requirements on the editor as well depending on your CMS or implementation. In some cases you will need to rely on the fact that the editor is aware of how to create content, and how choosing image size will affect the outcome and overall performance of the site. So it does not matter how great solution you provide, if the editor does not use it right, your screwed.
The final area I would like to address is testing. Traditionally you have your fixed sized page that should look the same in all browsers. Lets imagine you would like the site to work perfectly in a few desktop browsers (just example versions):
So in this fairly traditional testing scenario we have 9 browsers to visually and functionally test manually. If we only test them on one OS. In our brand spanking new RWD site we need to test all viewports. Lets assume we have 3 major views of the site so we end up with 3 * 9 = 27 visual/functional test scenarios. And remember, we have not added any mobile devices yet, so lets say we add three mobiles (iOS/Android/Windows) and three tablets (iOS/Android/Windows) just to keep it “minimal”. All of them of course have both portrait and landscape views. So these Â mobile devices add an additional 6 * 2 = 18 scenarios leaving us with a total of 27 + 18 = 45 scenarios to visually and functionally test. THAT costs money. Of course these requirements are made up, you will need to calculate testing scenarios for you own requirements to see the real difference.
You care about those, right? I like RWD, its great fun, but it certainly does not work well for all sites. Its challenging, it needs some HTML standard refinements in some aspects and it requires a lot of testing. This site is responsive, its because I am the one setting all the requirements. Having a site targeted towards developers mean I can skip silly thing like supporting Internet Explorer 8 for example. It saves a lot of time and I do not use ads either.
If I were to choose between the first two paths, single or multiple domains with two or more versions I would most certainly go for the single domain path every day of the week, if possible. Its just so much more simple to work with. As you can see in the list of question you need to ask yourself, having two domains just add to the complexity. The multi domain path could however be justified if it for some reason works better with the underlying CMS, or if the analytics or SEO people claim that this is the true path to choose. In that case, you will need to deal with the added complexity.
Feel free to leave a comment using the form below.