Virtually every project that comes through our door includes a mobile component, a mobile optimized site, a native app or considerations for new mobile channels (iPad, Kindle, etc.). We recently worked on a project in which we were challenged to:
- Support every major mobile platform via a comprehensive mobile optimized site.
- Build and stream content to native apps for the iPhone, Android and Blackberry.
- Build a flexible content API that could be leveraged for future devices.
- Extend the “author once, publish everywhere” concept to social networks and other channels.
This post will briefly outline the business goals of the project, describe some of the implementation details and provide some best-practice guidance for implementing a comprehensive solution.
Strict Separation of Content from Presentation
In our solution, there is a strict separation of content from presentation. Authors enter content, construct articles, assign appropriate taxonomy and perform traditional authoring tasks. When the content is published, it is immediately rendered for the Web, mobile optimized layouts, native apps and a variety of diverse content formats (RSS, HTML Newsletters, etc.).
In this way, authors are never exposed to the complexities of varying display and interaction models across platforms and devices and never manage the mobile channels directly. From an author’s perspective, they simply construct, review and publish content, and it immediately becomes available on the Web and across all mobile channels, automatically optimized and formatted for the appropriate device.
Exposing Content to the Mobile Web and Native Apps
The CMS our client selected enabled us to expose content for the mobile optimized display. This was fairly straightforward using the CMS’s concept of device detection and conditional renderings. The real challenge came in exposing site content to the native apps -- one for each of the major platforms (at time of launch): iPhone, Android and Blackberry.
We wrote a custom API that exposes content necessary for each of the mobile apps. This API is accessed by each mobile app at launch-time, and the latest content is streamed as an XML feed. Each of the native apps were built to consume the content from this single, common API, which allows us to rev the apps (and the API) at the same time and keep the code-base and feature set common across all of the apps.
Special Considerations: iPhone, Android, Blackberry
While we keep the mobile content API and the native app frameworks as homogenous as possible, there are inherent differences in the platforms, or features we want to exploit, that we need to accommodate. For example, we found older Blackberrys to be extremely finicky with less-than-perfectly formed HTML, so we filter the content before we stream the data for those particular legacy devices.
There are many device-specific rules we are using to ensure a similar, cross-device experience for all users of the native apps and the mobile optimized site, but to keep long-term support efforts within reason, watch how far you extend these rules. The more divergent they get, the harder it will be to test and maintain broad coverage of a large (and growing) mobile landscape.
Rapidly Changing Device Identifiers
Just a brief note on this: Getting device detection right is critical, particularly if you have custom displays for specific devices (iPhone, Android, Blackberry, etc.). You can detect devices at a high level by broadly parsing the user agent, such as showing all iPhones the same layout, all Blackberrys the same layout, etc. Given the rapidly changing landscape, we wanted more granular control over particular devices and versions. We are using the mobile device detection database and API provided by Device Atlas. It totally works, and I highly recommend it.
Author Once, Publish Everywhere
While not strictly part of our mobile implementation, we extended the “author once, publish everywhere” concept to social networks. We built custom controls within the CMSauthoring environment to allow any content item to be pushed to Twitter or Facebook. We fully automate the process of creating short URLs for Twitter and leverage the Twitter and Facebook APIs to push content into these channels.
One thing to account for when publishing to these services: the Twitter and Facebook APIs go down often and change without notice! This can cause real headaches for authors when the content fails to publish. Error messaging at publish time and a close watch on the changing Twitter/Facebook landscape is critical.
CMS as the “Connective Tissue” Between all Publishing Channels
When selecting a system, remember to choose a Web CMS that enables you to build complex, highly dynamic websites. The CMS we chose was the central hub for all of our publishing needs. We are now working on a project for a major international publishing group that leverages the CMS as the central publishing and workflow hub for their digital publications AND their print publications. Implemented correctly, the CMS you choose should be the optimal platform for this kind of single-sourced, central hub for a diverse ray of publishing needs.
Editor's Note: You may be interested in reading the following articles: