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.
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.
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.
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("/");
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">
<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">
<%-- 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:
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.