The future is mobile: Part II

This is the second part of a two-part series on designing for mobile.

Today, I’m going to cover SEO, server-side tweaks, and conditional tags. I’ll also look at how to deal with javascript and multimedia. I’ll be posting a short follow-up on accessibility soon. Check back for more.

Thank you to everyone who downloaded the free theme I made for WordCamp Montreal. If you have any suggestions on how to make it better, please let me know in the comments. And now on to the geeky stuff.

SEO

Because the method I’m using relies on modifications to an existing site, search engines will treat both the mobile version and the desktop version as the same site. This means that the Search engine optimization at the code level will be affected by both versions.

To me, this makes perfect sense. Although I sometimes remove extras, the main content of the site stays the same.

What some people do it generate an entirely separate mobile site with a  different url (http://example.mobi might be the mobile version of http://example.com). This is a great solution of your mobile and desktop content is substantially different. However, if you content is similar, you could run the risk of search engines interpreting the two sites as duplicate content.

Another thing to take into consideration, is how you will be serving your mobile site. What some sites do is put into place a server-side redirection method using user agent (UA) strings, sometimes called browser sniffing. In theory this sounds great. The server would detect that a user is using a mobile device by matching the content served to a signal sent by a specific browser.

Practically, this can be problematic for the following reasons:

• There are a lot of strings to keep track of and they change all the time. This makes maintenance time-consuming.
• Server-side browser sniffing can’t easily be done on shared hosting.
• Browsers often spoof or cloak their UA string and imitate another browser, rendering the technique ineffective. They can even be spoofed with browser plugins.
• It contravenes the W3C guidelines and prevents graceful degradation.

But another important reason is SEO. Browser sniffing is sometimes used by blackhat SEO agents to serve specific content to search engine spiders in an attempt to boost search results and for phishing scams.

Search engines don’t necessarily assume that browser sniffing is the same as blackhat activity. Google even offers advice on how to correctly configure UI strings. But if you get it wrong, the penalty can be severe.

Instead I use client-side media queries to serve browser specific CSS. The HTML and the content don’t change. Of course this will only be possible if you are using semantic code and carefully using HTML for content and structure and CSS for presentation.

The best way I’ve found to use media queries for mobile design is with Andy Clarke’s hardboiled CSS media queries with a small tweak.

These allow you to serve different stylesheets based on both viewport dimensions  and device orientation.

By targeting these client-side, you avoid any problems with SEO.

Other server tweaks

Another thing to keep in mind is that you will need to reduce your file sizes as much as possible in order to accommodate the small cache limits of mobile devices.

These limits vary by device but the Yahoo User Interface Blog recommends keeping HTML pages below 25 kb, and CSS and js under 1MB. If your audience uses only certain devices, there may be a little more flexibility.

Of note is the fact that gzip, a common server-side file compression tool, can be tricky or ineffective with mobile devices.

Another thing to keep in mind is font formats. In order to use @font-face rules in your stylesheets and serve pretty fonts to your users, you’ll need to use the SVG file format with iOS devices. Font Squirrel has a great @font-face generator, but there are others as well that can transform your font (licence permitting) into this format.

Font Squirrel also provides you with the CSS to add your fonts to your stylesheets.

The best way to add the fonts toyour site (if you aren’t using Font Squirrel’s CSS, is with Ethan Dunham’s Bulletproof @font-face Syntax.

If you’ve done this and uploaded the right file formats to your server and it still isn’t working, you may need to add the SVG mime-type to your .htaccess file.

Conditionals

WordPress does have a conditional tag that can be used to target mobile devices. “is_iphone” is a tag that will target iOS devices and android phones only. However it is poorly documented, and will cause errors when WordPress debugging mode is activated. (Which will also keep your theme from passing the WordPress Theme Check.)

Also, it won’t allow you to target tablets independently from phones which limits it’s usefulness.

Javascript and multimedia

Because I’m making my layout entirely fluid, I also need to reset all my images at a percentage of the width of my container div. On phones, I often just use 100%. But this won’t always work with images presented with javascript. Sometimes the javascript uses containers that don’t have any classes or ID’s and this can make it difficult to target them using CSS rules.

If you are implementing a slider, for example, you may need to tweak the code or try another javascript in order to make everything work.

Another tough area is video. Luckily, if you use a lot of YouTube videos, Chris Coyier of CSS-Tricks has a great javascript that allows you to serve fluid-width YouTube videos.

I’ll be posting a short follow-up on accessibility soon. Check back for more.

Have something to add? That’s what the comments are for. Contribute to the discussion.