A few weeks ago we launched the new Android and Me mobile site to almost unanimously positive reviews. The outpouring of support for my first major mobile build really got me excited and to return the favor I wanted to try to share some of what I learned.
This article is intended for those who already have a web or WordPress background. If you don’t quite understand how to put together your own templates, this might not be for you. For a long time we used the excellent plug-in WPtouch, which is a great solution for those uncomfortable with building from scratch. This isn’t a simple fix, we are going to get our hands dirty.
Let me start by saying that the following advice is a random collection of things I picked up while building the Android and Me mobile site. I’ll also start by saying I’m not a professional mobile developer. I do, however, bring years of traditional web and WordPress experience to the table and have recently been dropped head first into the mobile world. I’ve been enjoying it immensely. These are my findings:
Detecting mobile devices
The first step in creating a mobile site is detecting the devices trying to access your pages. The newest version of WordPress (2.9+) has made this a rather simple task with a new, built-in in conditional tag: is_iphone. Documentation on the function is hard to come by (it isn’t in the WordPress conditional tag list) but so far it’s proved to be an extremely elegant solution to selectively serving mobile templates to mobile users.
I found is_iphone on accident while digging through the WP core files and tested it on our development server and it returns true for Android as well (I’m guessing because it’s looking for the webkit browser agent). And using it is easy. The basic structure is like so:
<?php if ( $is_iphone ) {?>
// mobile template
<?php } else { ?>
// regular template
<?php } ?>
So, for example, if you wanted your single entry template (single.php) to check the device and serve the proper template, you could do so like this:
<?php if ( $is_iphone ) {?>
<?php include( TEMPLATEPATH . '/mobile/single.php' ); ?>
<?php } else { ?>
// entire contents of your regular single.php template
<?php } ?>
The above code is rather simple. If WordPress determines the browser is run on an iPhone (or Android device) it will know to use your specific mobile template (I’ve put all my mobile templates within a /mobile folder). Within your mobile templates you can use WordPress functions the same as you would in any other template. I’ve even got my mobile templates broken down into smaller pieces (as is customary when templating) like a mobile-specific header, footer, etc. In a regular template to call the header you can use the function:
<?php get_header() ?>
My mobile header is a completely different beast than the desktop header. It contains far less scripts and contains many key pieces needed to complete my mobile layout. So I created a new header, located within /mobile and within my mobile templates I can call it like so:
<?php include( TEMPLATEPATH . '/mobile/header.php' ); ?>
At the time, the is_iphone conditional seems to only return true for iPhone and Android users. Palm and BlackBerry users appear to be left in the dark. If that bothers you, there are many other ways to detect mobile users but for our purposes Android and iPhone cover our target audience. If that offends you as a Pre user, prove me wrong and show up in our analytics.
Also, since it’s an official WordPress function, hopefully they will expand it in the future to cover other smartphone platforms. In fact, I propose we change the tag’s name while it still fresh to is_smartphone.
Making things looks right
The great thing about designing and coding for a mobile device nowadays is just how awesome smartphone browsers have become. There are almost no differences between your markup for desktop and for mobile (with the exception of target device screen size). It’s the same site, only lightweight and smaller. Cut out whatever extra jazz you can, but for the most part the Android browser can handle the load.
The main concern is screen real estate. I’ve collapsed our three column desktop site into a single column for mobile. The site retains the same look and feel but is much more efficient on smaller screens.
Also with a small screen usually comes content that is much too large for the device, which is why smartphones have something called a viewport. The viewport is a screen sized looking glass that lays over a much larger page. Everything you see on the screen is within the viewport. Everything you can’t see is not.
With Android 1.6 came support for different screen resolutions (and thus different viewport sizes). To level the playing field we can add a custom meta tag to our mobile site’s header (/mobile/header.php)
<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; minimum-scale=1.0; user-scalable=0;" />
The viewport will be sized automatically to screen width (320px, 480px, etc) and will be zoomed to a scale of 1.0 (preventing the site loading waaaay zoomed out with everything very tiny). We’ve also set the viewport to not be user-scrollable, which will give our site a much more app-like feel. If you’d like the users to be able to zoom in and out, this would be the time to decide such.
When a phone is rotated and the orientation switches, the viewport resizes. Because of the ever changing screen widths, it’s important for your layouts to be fluid. When I first got my Nexus, I was worried the wider screen width would lead to odd layout challenges (images aren’t as easy to make fluid) but setting the scale and zoom to 1.0 makes the images appear the same size on all devices.
Here is where it gets really get confusing, though. On a Nexus (or Droid, for that matter), an image that is 300px wide will span the entire width of the screen. The result is a 300px image filling a space with considerably more pixels and you get a nasty upsampling effect (for lack of a better term). My layouts were rectified but my images on the high density screens just didn’t look good.
Luckily, the webkit image sizing engine came to the rescue. In the past (and on desktop browsers), if you rendered an image on-page smaller than it’s native size you’d see be able to tell. Images would get pixelated during downsampling. Not so on mobile devices. So for post images, for example, I call up a slightly larger image than I need and then downsize it right in-page (just using the width and height properties on the img tag). On the high resolution devices the result is a super crisp and properly sized image. I try to use this effect minimally though, on a page that lists a bunch of post thumbnails I just display an actual thumbnail at native size (the negative effect is less obvious on smaller images).
I’m sure calling up slightly larger images (less than 200px larger) will increase load times a tiny bit but I couldn’t live with launching a fresh new mobile site and having muddled images on the high res devices. And with ever-increasing network speeds I hope in the future it becomes even less of an issue.
Now we build
That’s basically it. Once you’ve got your conditional check in place and your viewport settings correct you can start the process of rebuilding all your templates on a mobile scale. Like I said, I put all my mobile templates within a single folder, /mobile. In the folder I’ve got any and all the files I need to make the mobile site tick (templates, images, scripts, etc).
To make a mobile page template (or archive template, for that matter), you simply open your current template and add the conditional at the top. Since a mobile layout tends to be much simpler, you can even cheat and use one mobile template to cover many desktop templates (on the mobile site I’ve got a single archive.php template that covers all my categories, tags, authors, etc, which I found much easier than creating a new template for each).
The thing to stress here is this isn’t some magical fix. We aren’t just changing a width here and there and calling it a mobile site. This is a ground-up rebuild that is creating new templates for mobile use. It’s a labor-intensive process but the result is more than worth it.
Bonus points
Along with making your layouts mobile-ready, there are numerous other tweaks you can make to enhance your mobile presence. In the header you can add a link to an apple-touch-icon (which will also be recognized by Android). When a user bookmarks the site and adds the link to the home screen, he will be presented with your custom icon.
<link rel="apple-touch-icon-precomposed" href="<?php bloginfo('template_url') ?>/mobile/images/home_icon.png" />
Setting an icon lets your site have a very specific and branded look on a user’s home screen. Icon are usually sized at 48×48 but again you can use a large image for a crisper result. Even Google does this, some of their icons are 57×57.
Another good practice is using minimal javascript touches to add native-looking functionality to your site. On the Android and Me mobile site I built a small menu that slides in and presents the user with navigation options (search, categories, etc). I’ve also done things like not display the comments by default, waiting to reveal them only when the user wants to see them.
The webkit engine also supports some new CSS properties I wasn’t accustomed to using at a production level. CSS3 makes it possible to generate drop shadows and gradients on the fly (whereas in the past you might have needed an image). Adding gradients is pretty easy and there are even online generators to make it even simpler. Using the new CSS properties at your disposal allows you to create a quicker loading and more dynamic layout (code changes are always easier than image changes).
So what’s next?
In addition to layout changes, there are some pieces of content that just don’t need to be displayed the same on the desktop and mobile site. One example are YouTube embeds. On the mobile site it displays a very large object that hangs way outside the viewport. To remedy the situation I’ve created a custom, mobile-aware shortcode. This allows our authors to add something like [vid id=”s8Uo0JErJXw”] and the site will automatically spit out a full YouTube embed on the desktop site and a neatly formatted link to the video on the mobile site. I’ve also done the same with market downloads. On the desktop site you get a QR for scanning, on the mobile site you get a link for clicking.
I’ll be taking a look at WordPress shortcodes in a future article but I wanted to check with you guys to see if there are any mobile-specific questions you want discussed in a future tutorial. Anything you see on the current site you want explained? See something I’m doing that could be improved? Let me know!
PS: I’ll be speaking tonite at the Austin Android Users Group meetup. If you are in Austin and interested in Android, come on by!
Related Posts
Filed under: Things I found in the Interwebs by Jeremiah |
No Comments »
Source: Android and Me
