Responsive Web Design v Device Channels in SharePoint 2013

With the introduction of Device Channels in SharePoint 2013, and 2013 having been dubbed the ‘Year of Responsive Web Design’, the question is often posed which method is the right one to enable a mobile experience on your SharePoint-hosted public facing website.

This post will briefly explore what both options entail and run through some of the benefits and limitations of using either method. By the end you should be confident in choosing a road forward for your mobile-optimised implementation.

Responsive Web Design (RWD)

RWD at its core relies on grid layouts, media queries and CSS to alter the display of a web site based on the width of the browser accessing that site. Depending on the number of widths targeted via the queries, a web site’s display can be made to differ on large desktop screens, tablets and mobile devices so they render in an optimal fashion no matter the viewing platform.

The main benefit of RWD is that no matter what the device width, the site will display in its optimal (or nearest-to-optimal) form. Given the large number of device widths that already exist, and this likely to only exponentially grow in the future, the method can be considered largely future-proof.

The method is also search engine friendly. Search engines prefer a URL to always render the same HTML and utilising RWD achieves this.

RWD however does not come without its faults. Its biggest drawback is what enables that SEO-friendly approach – the fact that the HTML served is the same. This means that while images or sections may be hidden in the CSS, the resources will still be served to the device which is not an optimal approach when targeting low-bandwidth mobile devices. It also provides a less flexible approach to targeting a given device allowing less options for modifying the display.

On top of this, RWD can often be costly to implement in terms of the number of tweaks and regressions required when targeting different browser widths. Todd Baginski and Michael Sherman in their SharePoint Conference session SPC390 stated that they anecdotally noted that 25% of developer time was spent dealing with such requirements.

Device Channels

Device Channels in SharePoint 2013 rely on targeting the device accessing the page and serving up customised HTML based on the device which will be rendering the content. This ensures that you can provide a completely customised user experience depending on whether the user is on a desktop, tablet or phone. You could even go as far as serving up different content depending on the type of device (iPad, Surface, Android for instance).

This option therefore comes with a number of advantages. It negates the main drawback of the responsive designs – HTML can be served in a manner which completely optimises the page load for the device being targeted. A desktop version could be highly interactive and visual, serving large images where the mobile experience could be lightweight for improved performance.

It also offers far greater flexibility in terms of the designs you can render to the different devices. Rather than relying on the same HTML and grid-based flows, you have the opportunity to structure the HTML rendered in any manner you desire, providing the capability to have far more interactive experiences on the desktop compared to mobile devices.

The disadvantages of this approach again mirror the advantages of the responsive approach. As has been previously stated, search engines prefer the HTML being rendered at a given URL to be identical, however device channels serve up different content at the same URL for different devices.

There is also a limit to the number of devices which can be targeted, meaning the coverage of designs would be less compared to the potentially limited coverage of a responsive design.

Another drawback of the device channel approach is that it is even more limited when it comes to hosting public websites on Office 365. Only 2 device channels are available there, a default channel and a mobile ‘catch-all’ channel, meaning the flexibility to target different devices is reduced greatly.

For an example of how device channels can be used to implement a mobile site on SharePoint, view my previous post How my latest mobile-optimised site was built using SharePoint 2013.

Which is the best option for you?

As should be becoming clearer, there is no ‘best practice’ approach when it comes to making the decision between responsive designs and device channels in SharePoint 2013. There are advantages and disadvantages to both and a number of other factors may end up affecting the decision.

If you’re dealing with a design company to provide the site design, particularly if this process happens before the SharePoint team gets involved, the decision may be made for you. It is common for design companies to provide completely different HTML templates for standard sites and mobile-optimised sites and that immediately lends itself towards device channels. It could also be more cost effective to receive one responsive design from a design company rather than multiple device-targeted designs which could also impact the decision.

If you’re dealing with a team that will be responsible for both the design and implementation, then the decision may come down to the flexibility required for the site design and weighing up the approaches outlined above to choose the one that best suits the goals of the site.

The Hybrid Approach – a better way forward

There is an option available which provides the best of both worlds and is particularly appropriate when hosting public sites on Office 365 – the hybrid approach. This involves utilising device channels to target particular devices, but ensuring the designs within them (or at least some of the smaller devices) are responsive for the different browser widths which may be encountered. It may not be the most cost-effective approach available however it would definitely be the most effective from a user experience point of view.


Note – As this post was written in a very different manner to my usual blogging style, I failed to properly work in the references I had read in researching this topic into the post itself. As such, i’ve included them below for prosperity:

Device channels v/s Responsive web design by Prashanth BS

Responsive Web Design vs. Device Channels by Jean Paul

Responsive vs. Adaptive Web Design – What about Device Channels? by Stefan Bauer

Digital Design Shift: From Mobile to Multichannel by SiteCore (must register)


How my latest mobile-optimised site was built using SharePoint 2013

About a year and a half ago now I wrote about How the Career Centre mobile site was built using SharePoint. Having recently worked on another large scale public facing website with the requirement for mobile-optimised capabilities the opportunity has presented itself to compare how far the product has come and offer up another technique to build your mobile-optimised sites in SharePoint. This post will be made up of 2 parts – the background information and decision making process which lead to the solution, and the solution itself. If you’re only interested in the latter then look for the heading ‘The Solution’ further down the page.

The Decision

Due to the site not yet having been released I’ve decided to keep the specifics of the site under wraps which is why this post will not include any screenshots of the design or links to view the site itself, however this should not detract from its content. Once the site does go live I may come back to this post and fill in the blanks.

The first thing that came to mind when faced with this requirement was Device Channels and Image Renditions. Whenever a new version of the platform comes out it’s spruiked as the saviour for a number of different use cases however in reality things tend to fall short when it comes to actually implementing them in the real world, so I was interested to see how it would go. I figured that seeing I had some success with the Career Centre site technique I could always fall back to that option if need be.

I started out as I usually do, looking for any and as much information I could find regarding building mobile optimised sites on SharePoint 2013. Surprisingly, content was fairly sparse. As usual with anything WCM related, Waldek Mastykarz was one of the first names I came across. His article on Optimizing SharePoint 2013 websites for mobile devices is one that definitely should be read when comparing the techniques of Device Channels and Responsive Designs. I’d also recommend reading his articles on Device Channels in SharePoint 2013 and Image Renditions in SharePoint 2013. For a bit of context or counter-argument then Shawn’s SharePoint 2013 and WCXM post should also be read.

Although its targeted at SharePoint 2010, Mike Hacker has written a good article on Mobile Access for SharePoint 2010 Internet Sites which provides a number of other alternate options for consideration.

As always when faced with a particular problem there are always some requirements which will dictate the solution. In this case there was a few. The mobile design was being provided with no consideration to the previous desktop design’s HTML, there would be a requirement to shift from the mobile site to the desktop site and vice versa (via the user clicking a link), all pages would require a mobile equivalent however the mobile site may contain many more pages or a different structure of pages depending on the content being displayed. Just to make it trickier, the exception to the ‘all pages require a mobile equivalent’ rule existed for a couple of pieces of functionality that needed to remain desktop-only.

Responsive layouts were immediately ruled out considering the designs had been created without consideration to the other – the original view was designed to perform reasonably on mobile devices, however we also needed to implement a completely mobile-optimised experience.

Altering the existing design using client-side technologies was also ruled out. This approach had been used by some colleagues of mine in the past however time was of the essence and I feared how long that would take to implement, let alone the complexity of customisation that would need to be maintained.

Device channels did not immediately look promising. The requirement to be able to switch to a desktop view immediately concerned me as I figured SharePoint would automatically take the mobile device to the mobile optimised page. The structure of the mobile site also differing concerned me a bit too seeing Device Channels appeared to be suited for a one to one mapping of pages. I’d also read a few other things which concerned me about Device Channels, particularly the lack of support for web part zones within Device Panels. The following quote was taken from How to: Add a Web Part zone snippet in SharePoint 2013.

You cannot insert a Web Part zone inside a Device Channel Panel. If you want to allow authors to add Web Parts to a page, and if you are not concerned about the page weight for mobile devices, you can add a Rich Text Editor page field to a Device Channel Panel, and then instruct authors to add Web Parts there. You can add Web Parts directly to a Device Channel Panel (without a Web Part zone).

That seemed like a deal-breaker, as this was a highly complex site and web parts were used throughout. It seemed I was left with the Career Centre option but I was going cold on that one too – I had concerns around redirecting the user (this was primitive in the previous implementation and only worked at the site’s root URL – not something I wanted to repeat or even could repeat given I was using friendly URLs). I had misgivings around the manual maintenance of pages, ‘mobile links’ and the client side code which altered content links and rendered the popup warning the user about non-optimised pages. I decided to bite the bullet and push on with Device Channels and see how I could make it work regardless of its shortfalls.

The Solution

Where there’s a will there’s a way. The mobile experience for the site was successfully implemented using Device Channels in SharePoint 2013.

The first piece of the puzzle was being able to immediately target all mobile devices by default, seeing we weren’t going to go down the path of optimising for each individual device. The user agent string $FALLBACKMOBILEUSERAGENTS; came in use here, you can read more about how it works in Waldek’s Device Channels post linked above.

The concern around not being able to switch between a mobile and desktop view was also countered. It is possible to override the device channel in a number of different ways. For testing purposes, specifying ?DeviceChannel=channel is a great way to achieve it, however you can also use cookies for a more permanent and lasting result. I placed a link in the footer of both the mobile and desktop master page linking to the other, which when clicked ran the following code (Default or Mobile depending on the current state):

Response.Cookies["deviceChannel"].Value = "Default";

This was wrapped in an UpdatePanel so that the post back and redirect didn’t appear to the user to be 2 separate things, however its probable I could have also achieved this solely using client side code. The redirect was necessary as the link event is handled too late in the page lifecycle for it to take affect in that load.

The differing structure between the mobile and desktop sites was also easily remedied. Firstly, the mobile-only pages were created and given managed navigation nodes with friendly URLs, however were removed from the Global and Current navigations. This ensured that the links would only appear where they were specifically placed on the mobile version. To counter the user going back to the desktop from one of these mobile-specific pages I added the following code to the redirect code above:

string rawUrl = Request.RawUrl;

// Some of the mobile specific pages don't have equivalent desktop versions - so we need to manipulate the redirect to the base location
if (rawUrl.Contains("xxx")) Response.Redirect("/parent-of-xxx");
else if (rawUrl.Contains("/m/aaa") || rawUrl.Contains("/m/bbb") || rawUrl.Contains("/m/ccc")) Response.Redirect("/");
else Response.Redirect(Request.RawUrl);

The web part zone issue was actually not as limiting as you’d first think. The main issue is that when a web part exists in a web part zone, but that zone does not exist in the other device panel, it will automatically be moved to the next available web part zone. This as you can imagine causes havoc to your layouts. The solution of adding the web parts to a rich text zone (or the Publishing HTML zone by default) is all good and well if you want that web part displaying on both the desktop and mobile versions – however this particular site often had significantly different displays (and HTML) for the same list-driven content and thus 2 separate web parts were required.

The solution was actually quite simple. The web part zones CAN be placed within a device panel – just place them in one (the default panel). You can place all your desktop-specific web parts there. I included 2 extra Publishing HTML fields in the mobile channel to serve as psuedo-web part zones for the mobile channel, and all mobile specific web parts were placed there. The final resulting layouts looked something like this:

<asp:Content ContentPlaceHolderID="PlaceHolderMain" runat="server">
    <WebPartPages:SPProxyWebPartManager runat="server" id="ProxyWebPartManager">
    <PublishingWebControls:MobilePanel runat="server" IncludedChannels="DEFAULT">
        <div class="html-structure-has-been-removed">
	    <webpartpages:webpartzone runat="server" id="WebPartZoneCentreTop" title="Webparts Centre Top" partchrometype="None">
	    <PublishingWebControls:RichHtmlField ID="PublishingPageContent" FieldName="PublishingPageContent" runat="server" />
	    <webpartpages:webpartzone runat="server" id="WebPartZoneCentreBottom" title="Webparts Centre Bottom" partchrometype="None">
    <PublishingWebControls:MobilePanel runat="server" IncludedChannels="Mobile">
        <div class="html-structure-has-been-removed">
            <%-- Need to use publishing fields rather than web part zones so existing web parts don't automatically
                 move across into the mobile display --%>
            <PublishingWebControls:RichHtmlField ID="MobileContentTop" FieldName="MobileContentTop" runat="server" />
            <PublishingWebControls:RichHtmlField ID="MobilePublishingPageContent" FieldName="PublishingPageContent" runat="server" />
            <PublishingWebControls:RichHtmlField ID="MobileContentBottom" FieldName="MobileContentBottom" runat="server" />

Ensuring particular pages were desktop-only was also relatively simple. All that was required was to have one or more page layouts which were dedicated to those pages specifically which overrode the Master Page setting for that layout. This can be achieved with the following code snippet in the page layout:

<script runat="server">
protected override void OnPreInit(EventArgs e)
    this.MasterPageFile = "DefaultChannel.master";

While I mentioned previously that separate mobile-specific web parts were created to generate the mobile-specific HTML, it wasn’t the only customisation required. Mobile-specific display templates were also created to ensure any content-by-search or search-result web parts rendered out the correct mobile-friendly HTML. These steps wouldn’t have been as necessary if the original design was based on a common HTML structure.

The last piece of the puzzle was handling image functionality for the mobile version of the site – either large images which appeared on the page within content or an image carousel web part. The latter I decided to only include in web part zones rather than within page content to ensure they wouldn’t display on the mobile version (this sometimes resulted in also having to maintain the page heading in a content editor web part and separately in the top mobile content zone to achieve the right look and feel). The former is where I figured image renditions would come in.

Image renditions have been touted as a great feature for mobile-optimised sites, as have Device Channels, so I would have assumed they’d work perfectly together. Unfortunately, they don’t. As the image renditions are displayed via a query string value in the source link stored in content, this is not adjustable out of the box depending on which device channel is being displayed. This was hugely disappointing in my opinion and it seemed like a great opportunity had been missed – in the end I just decided that smaller, web optimised images could remain in content and any large images could exist within web part zones so they didn’t appear on the mobile site. Waldek has actually provided a work-around for this issue with his Responsive Image Renditions with SharePoint 2013 functionality however its something I decided I could do without.

So overall the approach I was able to take in SharePoint 2013 to build a mobile-optimised site in my opinion ended up being miles ahead of what I managed to achieve in MOSS 2007. The amount of time it took to implement the entire site was minimal compared to the impact it has – the majority of mobile-optimised web parts only required changing the HTML rendered in ASP.NET repeaters and was able to leverage the same cached data as the desktop site, meaning performance is good. While there were some hurdles to jump, a number of these would have been easily mitigated if both the desktop and mobile designs were based on the same HTML structure – a happy medium between a fully responsive design and two completely separate sites.

If you’re tasked with building a mobile optimised version of your public facing website I’d definitely recommend looking into Device Channels to implement your solution and hope that some of the techniques listed here help you on your journey.

How the Career Centre mobile site was built using SharePoint

I’ve recently had the pleasure of working on a large public facing portal solution for the Career Centre. I came onto the project midway through so inherited a lot of branding and functionality, however early enough to create a number of components from scratch, having an input into the design and implementation decisions along the way. One such piece of functionality was the mobile site which can be accessed on your phones by clicking the link above, or in your browsers by accessing the mobile site directly.

The reason for this post is that it hasn’t been done exactly the way one would imagine. I thought I’d take the chance to explain the decision process behind the implementation and potentially open the lines of discussion on whether the decisions made were valid, based on false logic or whether there was a better solution available. For the purpose of context the Career Centre portal was developed on MOSS 2007 Enterprise Edition.

We’ll start with the requirements. The mobile site design had been provided to us so barring some minor tweaks, was not something that required a large amount of attention. The content of the site was to be a sub-set of the live site; a combination of landing pages which were to differ from the live site, content pages which mirrored the live site exactly, content pages which either differed from or didn’t exist in the live site, ‘multi-part’ content pages (based on a custom page layout) and functional aspects of the site (including but not limited to various search capabilities).

My thoughts were that with a custom master page, mobile-specific page layouts and mobile-specific controls and web parts, the majority of requirements would be easy enough to satisfy, and that largely turned out to be the case. My main concern was with content and ensuring the most efficient solution without resorting to content duplication, and the thought process behind that is what will form the basis of this post.

I had a fair understanding already that the ‘best practice’ way of implementing a mobile site in SharePoint was to leverage the variation capabilities of the product. Some initial research I performed backed up that presumption; the most impressive post I personally found for the topic was Jamie McAllister’s discussion on Exposing your MOSS WCM to Mobile Devices. I’d had some brief exposure to SharePoint variations from my time at TourismWA on There, variations were used for the purposes of multi-lingual sites (the complexity of that implementation is definitely worthy of a post on its own!). I was therefore already hesitant to embrace this functionality for my purpose.

Some extra research I did around variations did little to calm my nerves. Some of the more relevant posts I read include Jamie McAllister’s Do MOSS Variations really SUCK, Alex’s Common Problems with MOSS Variations and Jeremy Jameson’s Dumping MOSS 2007 variations Part 1, 2 and 3. There were a bunch of other negative posts I read that escape me now. For the sake of balance, Stefan Goßner’s series on the Variation Feature should also be read.

My main concern however was that changing a page’s layout from the initial site’s to the mobile-specific layout would cause a variation and hence no longer receive content updates; funnily enough, this proved a non-issue. Through my experimentation however I did come up with a raft of other concerns including;

  1. A variation required the source to be a sub-web of the root – which means we couldn’t have, it would have to be or something to that effect. The varied site would then also be a sub-site like This may seem like a small issue – but the URL of the site definitely was no small issue for the client.
  1. You can set up variations initially so that they auto-populate the varied site when new sites/pages are created, or you can set them up so they do not. We would have needed to turn that off considering the mobile site was to be a small sub-section of the main site. Problem being, once that feature was turned off we would then have to manually build up any new site structure to match. Once the variation hierarchy has been created automatically it can’t be done again.
  1. When I automatically created this hierarchy, it seemed to pick and choose which pages it recreated. I noticed only 2nd level sub-site pages where being brought across. I also noticed that for each site brought across, instead of recreating the default page it created a new default welcome page. This was obviously a huge concern, and would amount to a fair degree of manual labour to get it all up and running initially.
  1. Lists don’t get brought across and can’t be considered linked-up varied content. That means all the lists (that we needed for the mobile site) would need to be created in the mobile site manually and a process set up to copy content across in the event it was added or changed. This was more programmatic work that we were trying to avoid due to time constraints. (If this is a concern of yours have a read of another of Jamie’s posts)

For these reasons along with the research I had conducted and my own prior bias, rightly or wrongly I decided to turf the idea of using variations and proceeded to investigate an alternate solution.

Thanks to a huge degree of good fortune I had only days before been playing around with the Content Query Web Part along with CommonViewFields and styling with ItemStyle.xsl. I decided to leverage this functionality and the result was instant. I exported the Content Query Web Part and redeployed it under a different name to include the CommonViewFields of PublishingPageContent,HTML; and all fields associated with my ‘multi-part’ page layout. Important to note is that when used on the page and after pointing it to the relevant Pages library the page to copy exists in, an additional filter of Title equal to the current page’s title needed to be set – in hindsight I could have created a new web part overriding the content query web part to set this filter and the CommonViewFields automatically.

I then edited the ItemStyle.xsl file to include templates for all the fields listed in CommonViewFields:

<xsl:template name="PageHTMLOnly" match="Row[@Style='PageHTMLOnly']" mode="itemstyle">
    <xsl:variable name="DisplayTitle">
        <xsl:call-template name="OuterTemplate.GetTitle">
            <xsl:with-param name="Title" select="@Title"/>
            <xsl:with-param name="UrlColumnName" select="'LinkUrl'"/>
    <xsl:value-of disable-output-escaping="yes" select="@PublishingPageContent"/>

Only 2 issues remained; firstly, all in-content links pointed to the non-optimised pages regardless if a mobile-optimised page existed and secondly, users weren’t being warned if they were being taken to an un-optimised page within the site. jQuery to the rescue.

To ensure mobile-optimised pages were linked to appropriately, I included the attribute class=”mobilelink” on all hyperlinks that needed it. The following jQuery took care of the rest:

$('.mobilelink').attr('href', function (index, val) {
  var returnVal = val;

    returnVal = '/mobile/careerplanning/pages/knowingyourself.aspx';
  else if (val.toString().toUpperCase() == '/PAGES/CONTACTUS.ASPX')
    returnVal = '/mobile/contactus/pages/contactus.aspx';
  else if (val.toString().toUpperCase() == '/HOWWECANHELP/PAGES/HOWWECANHELP.ASPX')
    returnVal = '/mobile/pages/howwecanhelp.aspx';
    returnVal = '/mobile' + val;

  return returnVal;

It would have been a little neater had the mobile site structure mapped more accurately to the live site structure, but never mind.

To ensure users were warned if they were about to enter a non-optimised page, jQuery Dialog was harnessed:

<div id="dialog" title="Confirmation Required">
  You are about to leave the mobile-optimised site.<br /><br />
  Would you like to continue?
  modal: true,
  bgiframe: true,
  width: 280,
  height: 185,
  autoOpen: false

$("a").filter(function (index) {
  var theHREF = $(this).attr("href");
  return theHREF != undefined &&
  theHREF != null &&
  theHREF != "" &&
  theHREF.toUpperCase().indexOf("JAVASCRIPT:") == -1 &&
  theHREF.toUpperCase().indexOf("/MOBILE/") == -1 &&
  theHREF.toUpperCase().indexOf("TEL:") == -1 &&
  theHREF.toUpperCase().indexOf("MAILTO:") == -1 &&
  theHREF != "#" &&
  theHREF.charAt(0) != "#";
}).click(function(e) {
  var theHREF = $(this).attr("href");
  var target = $(this).attr("target");

  $("#dialog").dialog('option', 'buttons', {
    "Confirm" : function() {
      if (target != undefined && target == "_blank")
      {, target);
        window.location.href = theHREF;

    "Cancel" : function() {


The end result was a mobile site that needed to be created manually initially (but with little effort – my experimentation with variations concluded that I would have had to do the same if not more to get that working initially) but would largely be set and forget assuming the mobile site structure didn’t need to change. Content updates would be instant rather than relying on the synchronisation process between the source and varied page. We were also able to maintain the ‘root’ URL of by not requiring the source variation site to be created.

The last remaining problem was getting there. Seeing we hadn’t harnessed variations, we didn’t have the VariationRoot page to direct browsers to the mobile version of the site. Instead I ensured the default page of the root site had a web part on it that contained the logic to perform the redirect courtesy of Detect Mobile Browsers.

So there we have it. A result not particularly conforming with stated best practices however one the client is stoked with and should prove easily maintainable and effective. I’d be particularly interested to hear about other ways in which mobile sites have been created in SharePoint and anyone’s experience using SharePoint variations for that purpose.