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.).
Common questions to ask yourself
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:
- What is a mobile device?
- How can we classify a mobile device?
- By screen real estate?
- By capabilities?
- By browser fingerprint (user-agent)?
- By bandwidth (response time)?
- Where do we classify it?
- In the load balancer?
- In the cache layer?
- With server side code?
- With client side code?
- How old browsers should we support?
Multiple versions, single domain
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:
- How do we handle redirects between the versions?
- Do we enforce redirection, or should we allow the user to choose version?
- How does a user opt-in for a particular version?
- For how long will we keep this user preference?
- Where should we store the user preference?
- A logged in user account?
- How do we cache multiple versions of the same page?
- How will the search engines react on multiple versions?
- What version would you like the search engines to index?
- Will third party content, like ads or remotely hosted services like commenting or embedded content work for both versions?
- How will we setup the analytic scripts for data to be relevant?
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.
Multiple versions, multiple domains
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:
- Do we need to share sessions between domains?
- Do we need to shareÂ cookie data between domains?
- Do we need to make cross-domain requests?
- How do we set up the canonical ref?
- How do we handle redirects between the two domains?
- What domain should be used when sharing to social media?
- How will third party systems like Facebook Apps, Disqus comments, social sharing, ads and analytics work with multiple domains?
- Do we need to keep mobile and desktop traffic numbers in the same analytics report suite, or should they be separated or treated as two different sites?
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
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:
- Do we need to reduce page weight in some views?
- How do we reduce page weight in some views?
Should we design mobile first?
Should we implement mobile first?
- What view will older, incapable browsers get?
- Do we need any polyfills?
- What ad formats should we have?
- How will the ad formats be affected in various views?
- How will analytics work?
- Do we need or should we mix RWD with server-side output logic (RESS)?
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:
- How do we scale them well?
- At what point do we swap out one ad for another, because the format no longer suites the view?
- Do we load all ads, but only show a few?
- Do we load an ad when its needed by the view?
- What about ad analytics?
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.
- Do we lazy load images?
- Do we lazy load images to get the correct size?
- What happens if the view changes, do we load new image sizes or do we keep those we have?
- What about fall back for incapable browsers?
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):
- Internet Exporer 8, 9 + latest
- Google Chrome 25 + latest
- FireFox 3.6 + latest
- Safari 4 + latest
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.