and like us on FB

In another article (“How Important is Your Mobile Optimised Website?”) we looked at numerous issues associated with optimising your mobile website experience. This article will expand upon the question of how to bounce your users back and forth between both sites (assuming you’re using a separate m.website and not a responsive design). We’ll also look at basic principles you may use to tailor specific content for different types of users.

The complexity of devices used to view content means that we have to think of alternate and clever ways of accommodating all devices in a way that enhances the user experience… and this article seeks to look at just a few different ways we can deliver on that expectation.

The following is discussed in brief:

  • Bidirectional, Unidirectional, and No Redirects – To redirect or not redirect? That is the question.
  • Fixed Footer with Redirect Link – simple footer link that provides the option of bouncing between desktop and mobile devices.
  • Detecting Screen Width with JavaScript.
  • Detect Mobile Browsers with a (User Agent) Regex.
  • Redirections with .htaccess.
  • CSS Media Queries.
  • Conclusion.

Bidirectional, Unidirectional, and No Redirects

You can set up your sites in numerous ways; redirect your mobile users to a mobile version when requesting the desktop website, or visa-versa, or you may request desktop and mobile users both ways depending upon the platform from which they’re making the request. While the redirects are easy to implement, we’ll focus on no redirects. From personal experience, I prefer to see the website that I request. Desktop designed sites are easier to navigate around large amounts of content – particularly on a tablet. In consideration of the user experience, sometimes providing a choice is the better option.

Fixed Footer with Redirect Link

The first lot of code is based upon the fixed bar code we previously shared. It’ll simply render an unobtrusive fixed bar at the top or bottom of your page and provide a link to the alternate site. It’s based on either identical permalinks (easy to do with WordPress) or with an alternate URL stored as a post option. The example link at the bottom of this page to would bounce the user between m.beliefmedia.com and the desktop site. A cookie or session option should be provided to remove the bar completely.

The platform making the request is identified by the WordPress wp_is_mobile() function. It’s a conditional tag that checks if the user is visiting using a mobile device and returns a Boolean TRUE or FALSE. The function, located in wp-includes/vars.php identifies the device by testing the $_SERVER['HTTP_USER_AGENT'] string. It’s a basic function and WP make the point that it does not consider resolution, window width, or any other factors. They state that it shouldn’t be used for themes (instead referring developers to the Mobble plugin that’ll detect devices with is_iphone, is_mobile, and is_tablet).

It’s virtually impossible to provide a universal example because it’s unknown how you’ll be setting up your site with relation to database access.

So, as an example, here’s code that’ll conditionally provide a mobile or desktop redirection link based on the current permalink.

While you can easily determine the URL of an alternate m.site, you could optionally record the URL of the other website using get_post_meta() – particularly if the URLs are differed or weren’t based off the same permalink.

We generally write inline CSS to negate the need and overhead associated with adding CSS to another file (or adding it to a custom plugin). However, a* links form part of the selector (outside the wiggly brackets) which is implicit to the current element, or div – while inline styles only have rules. So, if you’re like me and your default link text conflicts with the color of the fixed redirect bar, you must upload the following CSS to the CSS file attached to your custom functions plugin to style the message bars links.

I had some issues with some mobile browsers rending the CSS. To remedy that, I saved the CSS as UTF-8 and put the following line at the top of my style sheet.

If used on an actual mobile site the fixed bar would look as follows:

Mobile Design Considerations with WordPress and PHP

When you squeeze up your responsive design as if it were viewed on a mobile, you can see there are elements that might be best removed. In my case, the Twitter button, Facebook share buttons, fancy date, and featured image might be best left excluded from rendering. This can all be accomplished with wp_is_mobile(), although you might only remove it for mobile handsets rather than all tablet-type devices. While Mobble makes serving the conditional content easy, you might also consider JavaScript.

Detecting Screen Width with JavaScript

JavaScript isn’t overly effective for the purpose of the redirect, and a user agent string is almost always more efficient. However, you can use JavaScript as follows:

You can optionally detect specific mobile phones, or various ranges of resolution, and redirect them as appropriate. It’s not uncommon for those with a big budget to create a mobile, tablet, and a desktop version of the same website. For example, I can detect the dimensions of your device. . Knowing the dimensions of the majority of major devices, or grouping them by size, we can conditionally redirect them to alternate websites.

Incidentally, I used the following shortcode to print the dimensions of your device to your page:

Detect Mobile Browsers with a (User Agent) Regex

Chad Smith has written a fairly comprehensive regex that, not unlike WordPress, redirects by virtue of the HTTP_USER_AGENT. It’ll detect most mobile browser and redirect to a mobile source. In reality, you would want to conditionally check for smaller devices like mobile phones, and tablets, and redirect them appropriately.

Used in a shortcode, and assuming you’re reading on a mobile device, I can render your browser as “desktop“…. although you could use a modified regex to check for desktop browser types as well. Here’s Chad’s regex that’ll redirect to a mobile website.

If you would like to see a comprehensive list of all supported devices and user strings, download the list here ZIP Image.

Your User Agent is: CCBot/2.0 (http://commoncrawl.org/faq/). It’s this string we read to make a determination of what device you’re using.

Included for your reference only, I’ve used the following simple shortcode to display your user agent sting:

If we were to modify Chad’s regex slightly to just include only the first preg_match (for simplicity), we could make a determination of what device our visitor might be using and conditionally direct them to a specific website. The user string is rather complex and generally an inefficient means for detecting a device (it detects a browser, or software agent ), however, while imperfect, it’s still extremely reliable by design. The W3C recommends creating HTML markup that is standard, allowing correct rendering in as many browsers as possible, and to test for specific browser features rather than particular browser versions or brands.

Following this paragraph is the shortcode I used to print the mobile useragent match to your screen. While the purpose of this article is to discuss redirects, the code could be used to offer a download for a specific application from either the App Store or Google Play. You could alternatively simply deliver different content to different users… or product accessories that you know the visitor has (why sell an iPhone cover to an Android user?)… knowing the device your visitor is using offers interesting ways of split-testing. Given that iPhone owners apparently make an average $85,000 per year compared to Android’s 61,000 per year, and armed with a location that you can easily obtain, you might be able to tailor advertising that is more likely to convert. It’s interesting to think of how little bits of knowledge like this can be used.

The same device-specific redirects can be accomplished less efficiently with JavaScript.

Using WordPress wp_is_mobile() Outside of WordPress

The wp_is_mobile() function can be used in any application.

Usage:

While it’s an imperfect function, we can modify it slightly to identify specific types of browsers based on the user agent (instead of returning a Boolean). This gives us some of the features of Chad’s function in that our code may return an identified device (however reliable). Again, it’s just a modified version of the WP function so shouldn’t be used for important applications.

Redirections with .htaccess

You might also consider applying redirections at the server level before headers are served. Here’s an example .htaccess file that’ll redirect on identifying an iPad.

A 302 redirect is used (temporarily moved) rather than a 301 as per Google’s guidelines. The same code applies to identifying Android devices.

Here’s a good solution to .htaccess redirects that I found on StackOverflow a few years ago:

From what I can tell so far it works quite well. While server based redirections are fraught with potential danger (they’ll force a redirect even if the user chooses against it), this code provides for an option in the query string &m=0 (and a Cookie will be set) to ensure that you can escape the redirect measures.

Redirect Before Content is Served

In all cases where you’re redirecting from one page to another, you should provide for a header redirect before any content (including spaces) are sent to the screen.

In PHP, you’ll generally use something as follows:

Note the 302 redirect (as recommended by Google for mobile redirects). If the status code is not specified, header(‘Location:’) should default to 302.

When using WordPress, a good action to use before any content is rendered to your page is template_redirect . While PHP’s header("Location: .. is acceptable, WordPress have their own wp_redirect function. It differs from PHP’s default function in that it sanitises URLs, applies filters, and corrects redirects on some server setups. All header redirects used in templates and other code must be run before get_header() (we use template_redirect for an upcoming article on under construction pages, and it works well).

CSS Media Queries

Media Queries are a CSS3 module allowing content rendering to adapt to conditions such as screen resolution. It became a W3C recommended standard in June 2012 and is the cornerstone technology of responsive web design.

This is a demo paragraph. Scale the screen size and it’ll change color at 500 pixels. Scale your browser and try it out.

For those that can’t see it, this:

Mobile Design Considerations with WordPress and PHP

… becomes this:

Mobile Design Considerations with WordPress and PHP

I’ve used a simple media query as follows:

… and my HTML looks like this:

Mobile Design Considerations with WordPress and PHP

Media queries mean that you can load CSS conditional on the device used, and you can seriously alter the design based on how it’s viewed. It’s a client-side solution to rendering conditional content that could be used, for example, to hide the interstitial advertising that Google will now penalise mobile websites for displaying. For example, here’s a fairly crude example of a paragraph that will display content based on the device you’re viewing it on (or the browser width). If you’re on a desktop, you can scale your browser and the message will change as it gets narrower:

Content for a desktop device…

Content for a tablet device…

Content for a mobile…

The paragraph will conditionally display a message that says “Content for a (desktop|tablet|mobile) device”. I’ve plucked the dimensions from nowhere so they mean nothing; it just worked for the example. Think about how this might be used to display social links, newsletter subscriptions, advertising, and so on.

The CSS to accomplish what I’ve demonstrated:

… and the HTML:

Read more about CSS Media Queries here .

Conclusion

All the subject matter on this page was nothing more than a cursory introduction for those that are looking at venturing into the world of mobile design. The customized user-experience will yield better results than a generic one-size-fits-all approach. Fortunately, WordPress and other CMS platforms or frameworks provide a basis from which we can build.

This article was originally published on Internoetics in 2015. It may contain content that is a little outdated.

If you’re looking to enhance your mobile experience, get in touch with us.

Shortt URL for this post: http://shor.tt/1QLt