MobileMobile Sites: Choosing an Implementation Process & Strategies

Mobile Sites: Choosing an Implementation Process & Strategies

No matter your approach, the mobile landscape is a tricky, expansive space of uncertainty filled with twists and turns that would give even the most solid minded developer or site owner points to pause. Here’s a guide to help you go mobile.

The world is going mobile and with that so are our websites. Device and platform fragmentation are the new norm.


No matter your approach, the mobile landscape is a tricky, expansive space of uncertainty filled with twists and turns that would give even the most solid minded developer or site owner points to pause. So what to do?

Code Well – Don’t Worry About Mobile.

We’re borrowing this first step from Opera’s “Mobile Web Optimization Guide“, but it is really where every website should start no matter the approach.

Going Mobile Without Creating a Mobile Site

Going mobile can be a time consuming and daunting project, so what do you do if you cannot add mobile site creation to your current project plan?What do you do when a lack of time, budget and resources actually prevents you from creating a mobile site? What’s next?

Alas all is not lost. Clean code and a secret ingredient called the WCAG AA Accessibility Standards can take your site from hot mess to mobile ready in a relatively short time.

Will it be a perfect? No. However, it will give you a site that works in all devices and platforms fairly well.

The Secret Ingredient: WCAG AA Standards

Take your W3C valid and semantically compliant HTML, throw in CSS 2 and 3, add WCAG AA accessibility standards and you now have the basics of a site that will render in all feature and smartphones as well as tablets, laptops, and desktop devices (even better if you can use the HTML5 doctype!).

What is WCAG AA & How Does it Help?

There are three levels to the WCAG standard A, AA and AAA. These set the level of code and design compliance a site needs to follow to meet the needs of people with challenges such as blindness, dexterity or color.

This standard guides your website design and implementation in such as way as to make sure that your site is not dependent on your device functionality (say a mouse to click), or the user’s ability to interpret non-standard indicators (say color only to display links).

Code such as

  • Image Alt Text: Tells users what an image is, no need to wait for the download
  • onClick event handler: Replaces onMouse, so users do not need a mouse to interact with the code object.
  • Contrast ratios: Sets colors to proper contrast ratios, so foreground text can easily be seen on the site background.

As you can see what helps users with usability challenges, also helps your site’s usability for all users on mobile devices, tablets and feature phones. Plus the search engines like accessible friendly sites.

The bad news, the recipe of W3C compliant HTML + CSS + WCAG AA is not enough to make your site fully mobile capable, but if you are not able to do more this will help and if you are able to do more, well you should be doing this first anyway.

All sites should start from here, mobile or not.

Besides, studies show, your current code probably could use some cleaning up, so in this day of Panda, Penguin and site speed factors what do you have to lose?

Build Two Sites – M. Your World

Oh the often dreaded M. I could write a whole article on the how to’s and not to’s of the m. site, such as don’t force your users to such a site using such aggravating tricks as device detection redirects and not allow them to go to your standard site. But just why is the m. so controversial, why not just build two sites? Seems like the obvious answer right? Well not too fast.

M. Why the Fuss?

Well the idea of the m. is basically flawed. Generally, CMS systems have built in M. output. So while this may seem like a perfect solution for a difficult issue, M. sites have issues of their own.

The One Site URL Issue: Bing & Google

Bing will no longer index your m. site under their “One URL Per Site” policy.

OK well they will if it is the only site URL and you have quality indicators and you have traffic and you have links coming to it and well you get the idea. If your m. site is more valuable site than your standard www. site, it could, but would you want it to?

Google has never been as clear about its position on m. URLs as Bing, but given Google treats smartphones as desktop browsers (even with the new smartphone crawler) and your content rankings are not gaining any benefit from your shared m. links and..and.. well again, why would you want two domain URLs? Remember an is still a subdomain.

Multiple Content Delivery

With two sites comes two sets of content, there is a myth you need two sets of content one for desktop users and one for mobile.

Users are users. They come to your site with a task in mind and your content generally does not need to change because users come from different places.

If you need to revamp large portions of your content for your mobile users, chances are the lack of screen space just highlighted an existing content issue that you always needed to correct.

NOTE: Now don’t confuse different content, from content delivery. You may very likely deliver a geolocated-based page or ad to a mobile user that you would not to your desktop user. This is not what multiple content sets refers to, multiple content sets are when you create two vastly differing sets of content for users based on site type.


So extra time and resources, multiple content delivery and search engine issues, the M. site is an option that you should work to phase out if you have it and one to avoid if you are just getting started.

Responsive Design: One Site to Rule the World

“The mobile pundits got it right: sites should be minimal, functional, with everything designed to help the user complete a task, and then go. But that doesn’t mean that you need to make a separate mobile site from your normal site. If your normal site isn’t minimal, functional, with everything designed to help the user complete a task, it’s time to rethink your whole site.

“And once you’ve done that, serve it to everyone, whatever the device.” – Bruce Lawson

This is going to be the most difficult method to implement. No easy way to get around it. You will need HTML/CSS developers who are not reliant on Dreamweaver code assist and JQuery/Ajax junkies who know what to do with all things web to mobile.

That being said, once you have completed the Responsive Design process, you will breathe a sigh of relief because your site will not only work on all devices and platforms as the sites in Strategy #1, but it will appear as you want it to appear, work as you want it to work.

Another plus. as more devices come to market adapting to those will be as simple as adding more code to style sheets to change what appears on the screen.

Responsive Design not only gives you greater control, but also helps to “future proof” your site.

“Future Proof”

Future Proofing your site is the task of using standards and processes that allow whole site changes to be implemented in strategic ways with segmented layers of functionality, presentation, and structure.

Responsive Design – Stepping Forward Into the Future

As mentioned before the HTML5 doctype and clean, compliant, accessible, code is the very first step into your new future proof, responsively designed, semantically correct, progressively enhanced and yes, accessible website.

Don’t skip this step!

Many articles will ask, do you create for web or mobile first. First you create a site framework that has semantically correct W3C compliant HTML and CSS utilizing WCAG AA standards. This is your basic mobile site. It is also code for a good desktop site. See no decision needs to be made it does both.

What is Responsive Design?

Responsive Design is just what it sounds like. A site that is responsive to the devices (and platforms) you use.

With the endless creation of new mobile and tablet device types, eventually there was just no way to code for each and every one, so sites had to become flexible. Like a type of byte contortionism, sites have had to become as flexible as plastic wrap to account for them all.

Responsive Design accounts for these changes by making changes to the layout, flow or display of a site based on what device it is presented on. Screen size, device type, browser etc. is accounted for by utilizing code that is not based on browser / platform detection, but feature detection. These are called Media Queries and are part of the CSS 3 specification.


Media Queries

Media Queries simply put, control how your styles are applied based on the device being used. We have been using print style sheets for years, media queries are similar and allow you to control what a user sees by using the inheritance property in CSS combined with the CSS3 mobile attributes.

NOTE: Make sure to check your media query support, before implementation to save yourself time in browser fixes after site testing.

Media Queries are great for turning off items you don’t wish to load into the browser. This is not the same as the CSS values “display: none” or “visibility: hidden”.

In these cases the items are still loaded into the background, with Media Queries the code or images are never downloaded and save the user time and possibly money, by not downloading what they don’t need.

Media queries can also turn off resource hungry CSS such as shadows, transitions and transformations, making your site users happier, especially those in countries where they pay by the byte.


We can’t have a discussion on mobile sites without some mention of viewports. Viewports are simply how you present your site when the user loads it.

For example on a smartphone, without a viewport setting the user will see the site, full screen much like on a desktop computer. The user can then zoom in and out to read the site contents.

The viewport allow the user to received your site already at a set zoom settings, so you can deliver your content in a more controlled method. This is commonly used for apps, but can also be used for websites that have removed design elements and are delivering straight content.

Progressive Enhancement

When making the move to universal design, there is one tenet of website design that will have to be completely removed from your team’s vocabulary: Pixel Perfect.

There is no more pixel perfection. The plethora of devices and user experiences now make the concept one that only will cost you time, money and most likely your sanity.

Progressive enhancement is the concept that you let the content be your site’s guiding force and some of your design details differ as browsers fall out of majority. It doesn’t mean that if you have X% users on IE8 you just stop supporting it and leave those users with a poor user experience, so you can move on the “shiny stuff”.

What it does mean is you can’t waste a week in design and implementation to put image based rounded corners on a site because X% of your users still use IE7. They just get square ones because you have decided it makes more sense to use CSS to round your corners.

So let’s review. If you practice Responsive Design and allow for Progressive Enhancement some of the benefits for your site are:

  • Future Proofing
  • Lowered costs in time, resources, support and development.
  • One content set to maintain
  • Better SEO value and increased site speed
  • Decreased download time for mobile users
  • Retained inbound site links when share links all point to one URL
  • Avoiding one URL issue
  • Potential increased market base with addition of accessibility enhancements
  • And a site that works on ALL Devices and Platforms

Very Important Note: Your website is not an app. Don’t make the mistake of confusing your mobile website for an app.

  • Website/mobile users are task based (goal and explorer functions), while application users are goal focused.
  • Don’t think your mobile site is an app, don’t make it into an app, don’t make it look like an app, and always make sure you have a link to your full site on any mobile version.

Be Like Apple (Or Google)

Apple does it, so does Google. Yes, both companies serve one URL, one site, one set of code and one set of content. They don’t think that mobile users are different users.

While Apple and Google may create a slightly altered experience based on the device their user uses to access their content, they aren’t creating secondary sites or secondary content sets. (Some content may be differently delivered. This is different than maintaining different sets of content.)

So in these days of endless platforms and multiple device creation, it is time to move away from the outdated concept of two-site methodology. It is time to create one site – one to rule them all.

Embrace universal (responsive) design. Do it and learn to love it, because device fragmentation is here to stay and being a website contortionist might decide who thrives and who dies, figuratively of course.

Responsive Design Resources.

The topic of responsive design is very detailed and would need far more than one article to cover to the implementation level, so here are some excellent resources to help you.


Semrush Keyword Difficulty

whitepaper | Analytics Semrush Keyword Difficulty

Searchmetrics Core Web Vitals Study

whitepaper | Analytics Searchmetrics Core Web Vitals Study

The Ultimate Guide to Forum Link Building in 2020

whitepaper | Analytics The Ultimate Guide to Forum Link Building in 2020

Top 5 SEO Mistakes

whitepaper | Analytics Top 5 SEO Mistakes