By parallel site, I mean building a second, wholly separate website, distinct from your current site, highly optimized to accommodate mobile traffic. Rather than go to example.com, you are instead redirected to m.example.com (or similar) when you visit on your smartphone. Your core content remains the same (or should), but extraneous material is removed and the presentation of your content is slimmed down to basics, with usually a sleek, minimalist design.
The technological way you achieve this may vary – hopefully you aren’t actually posting content to two distinct websites. It could be that your content management system responds to the URL that is requested with different markup and styles. You might use a service like GoMobi or Dudamobile to automatically convert your site’s content to a ready-made mobile version that’s hosted with the service.
How does this stack up against our goals (which we laid out in part one)?
A mobile user should be able to access the same content as a desktop user
Access to content will vary on your approach and dedication to the goal. For example, Onswipe uses RSS feeds to pull content from your site to display in your mobile experience. Similarly, at the top of this page, you’ll see that Dudamobile mentions in tiny type, in parentheses, that “we gather content from your current URL to create your mobile site.” The problem with this, of course, is if you don’t have all your content accessible via RSS or it changes constantly – how do these services keep your content fresh if it changes? Some content may slip through the cracks.
If you’re going to use your CMS to manage your mobile experience, then this is conceivably less of a problem – all your content is already in your CMS. If you’re building a separate website, then the opposite is true, and you’ll have to come up with a way to keep content synched between the two sites (how about RSS?).
Mobile users should not have to wait much longer than a desktop user for a page to load
This is the biggest pro of a parallel site: you can optimize the heck out of it! Serve up smaller images, eliminate unnecessary content, slim down on third party widgets, and you should have a smooth and fast mobile experience. I recommend consulting a developer if you’re managing a mobile experience via your CMS.
Interaction and navigation should be simple
Another big pro of a parallel site: you can slim the design down as much as you want without affecting the full site at all. Take advantage of this to optimize the experience for a mobile user. Keep in mind how you will shuttle your users between your full and mobile site though: how will you know if a user is mobile or not? Will you offer your mobile users the ability to switch to the full site if they wish? If so, how will you link up pages between your mobile and full sites?
All or most major devices should be supported
If you’re using a third party service, they should be taking care of this part for you. If not, you still have more control over the experience for new devices than using other methods. Again, I recommend consulting a developer.
Aside from our macro-level goals, there are a few other things you should consider if you’re looking at a parallel site, and they vary depending on what method you’re using to build your parallel site.
The largest, most glaring problem with going this route is the fact that, of course, you have a second site to worry about. Related to that, you’ll have to keep duplicated content in mind so you don’t accidentally wreck your SEO (although Google claims that you shouldn’t be penalized in instances like this).
If you’re relying on a third party service to generate a mobile site for you, how much will it cost you? How much control do you have over the design? What if you want to customize it? What if content changes? What kind of visibility will you have into the site’s usage?
If your CMS will support a parallel site for you like this, make sure you understand its approach and limitations before embarking – do some googling to see if other people have attempted the same thing with your CMS and get a feel for the kinds of issues people ran into. Hiring a developer to help you with a CMS-based solution isn’t a bad idea.
Your mileage may vary. You may go with a third party service and be very happy with the results; you may use your CMS to create a second user experience and be pleased with the amount of control you have. Whatever you do, do your research before committing. If you’re already on a CMS that might support a parallel site, I think that’s the best direction to go. If you can, talk to associates that have been through this and see if you can learn anything from their experiences.
If you have experience with building a parallel mobile site, please speak up! Share your experience and any caveats and issues you ran into. And of course, feel free to ask questions!