Business Catalyst Blog

Introducing tablet & phone support for sites

Marius Andreiana Thursday, June 09, 2011

The rapid proliferation of web-enabled devices is an important trend for online businesses.

As businesses look to extend their reach beyond the desktop and onto consumer devices like iPad, iPhone and other smartphones/tablets, the demand for optimized experiences on these devices will rise. Web developers will be called upon by clients to deliver a multiscreen web presence (as opposed to a single web site) and will be faced with the challenge of producing different user experiences on different devices.

There is no single "right" approach to multiscreen development and a combination of techniques is what often yields the best results. Some techniques, like using CSS media queries to invoke different CSS based on screen resolution, can be easily implemented with client-side code in the browser. Others, like redirecting to another URL or serving different markup based on the requesting user agent, require server-side processing.

Our goal with Business Catalyst is to ensure that you have several implementation options at your disposal. We're still in the early days of multiscreen web development. New techniques and practices are sure to emerge in the months/years ahead so, overall, we want BC's multiscreen support to be flexible and extendable.

With that in mind, here is the first step from the planned multiscreen features offered in Business Catalyst.

Device classes

BC detects server-side the device used to access a page and maps it to one of these device classes:

desktop 
tablet 
phone

The mapping is done based on user agent strings and some internal rules. If the device cannot be determined by its user agent or it does not fall in any of the existing device classes, the "desktop" device class will be used.

The module {system_visitorDeviceClass} renders the device class value (e.g. "phone") corresponding to the device used to browse the site. This module won't be counted against the current 25 modules limit per page.

Tips & tricks

Here is what you can achieve today by using {system_visitorDeviceClass} module.

Device-specific styling

You might want to increase the link & button sizes for phones and tablet. This can now be easily done by including device-specific stylesheets:

<link rel="stylesheet" type="text/css" 
href="/css/{system_visitorDeviceClass}.css" />

This will include desktop.css, tablet.css or phone.css.

Redirect visitors to a mobile site version

Using javascript, you could test for specific device class values and performs custom actions. For example, a site homepage could redirect phone visitors to a focused mobile web application/site:

<head>        
<script type="text/javascript">          
if ('{system_visitorDeviceClass}' == 'phone') {
            window.location = 'http://mysite.com/m/';
          }       
</script>     
</head> 

Device-specific content

If you'd like to serve device-specific content today as part of a template or page, without waiting for the full planned implementation, here's how to do it:
1. generate the device class value in an HTML comment, to workaround the current limitation of having modules in modules. This value will be cached and used for further occurrences.
2. use it as part of a content holder name

<!-- {system_visitorDeviceClass} --> 
{module_contentholder, name="home_{system_visitorDeviceClass}"} 

The above snippet will include one of these content holders: home_desktop, home_tablet, home_phone

Please discuss and share more tips and samples on Content Management forum.

Best practices

Here are some articles outlining best practices when building multiscreen sites:

Technical details

Choosing what device class is used is done by the following criteria, in priority order:

  1. URL query string parameter, if set (e.g. ?visitorDeviceClass=phone). This will also set a cookie with the specified value. ?visitorDeviceClass=auto will clear the cookie and enable again auto-detection.
  2. device class cookie, if set
  3. user agent string auto-detection and defined device classes capabilities (1st matching device class will be chosen)
  4. default content (if none of the above worked or specific templates were set by Jason)

What's next?

We'll continue implementing multiscreen features throughout the year, discussing details on prerelease. Next step is having templating support for desktop, tablet and phone. Meanwhile, look out for upcoming tutorials at BC Gurus and Kiyuco.

Looking forward to your thoughts, feature requests, tips & tricks and showcases on Content Management forums.

Marius Andreiana, CMS Team

blog comments powered by Disqus