Wednesday, 7 August 2013

Mobile Panel in SharePoint 2013

In my previous post on Device Channel, I explained how to create a device channel to target different devices. In this blog post, I will explain about Mobile Panels and Device Channel Panels and why to use them. I am going to explain a scenario which me and my friend worked on in order to have an understanding on the exact need for these panels.
There are times when you want to target only specific content of a page based on devices. Most of the times you might have noticed that many websites have a whole bunch of features when you have a look at the site in the desktop mode and have filtered set of features when viewed on mobile.
When it comes to SharePoint 2013, then Microsoft has came up with the concept of Mobile Panel and Device Channel Panel to provide a similar feature. These help in targeting specific content of a page layout on mobile and desktop. Mobile Panel allows content authors to target specific content for different devices. For example, mostly you have observed a banner image coming as a feature area on the sites. Now, this looks nice on the desktop version, but on mobiles, this does not seem much relevant. So, the requirement is to show this banner only is the user is in desktop view and not when in mobile view. Device Channel Panel is also a snippet that we can add to master page or to a page layout to control what content is rendered for the channels that we create. So for the above scenario, we want to have a single page layout which should be intelligent enough to show content specific to each of these channels.

Now, the main thing here is to create a page layout which could be shared across all mobile devices as well as the desktop view. In order to do that we need to make it device enabled using Mobile Panel. The normal way of proceeding on this is to have a region where all the common webparts both for mobile and desktop should go and another region where desktop specific should go. But this is not as simple as it seemed. We started with adding device channel for desktop and added a webpart zone there so as to add our banner webpart there which was meant to be visible only in desktop version. Then outside that device channel, we added webpart zones that will hold all the webparts that were common for mobile and desktop version. But to our surprise, this did not work. This logically correct solution was not showing the behavior that we expected from it.
Then we thought of creating two device channels, one for mobile and the other for desktop each having webpart zones and then we added all the mobile specific webpart to the device channel meant for Mobile and all the desktop specific webparts to the Default Channel(which is used for Desktop view). But the results were surprising again. In the desktop view, everything seemed correct but as soon as we switched to mobile view, we observed that the banner webpart, which we had only added in the desktop view and not in the mobile view, was visible in the mobile as well. On editing the page, we saw that in mobile view, edit page is showing the webpart but in wrong zone.
After some analysis, we found that the issue is that when a webpart is added to a webpart zone in one mobile panel and if that webpart zone does not exist in the other mobile panel then that webpart will automatically move to the next available webpart zone. Therefore, when we added the banner webpart to a zone in the Desktop device channel and when the page is viewed in mobile view, then because the banner webpart zone did not exist in the mobile view, the banner webpart got added to one of the webpart zones of the mobile device channel. So, after some drilling, we came to a solution that since the availability of the webpart zones is causing an issue, what if we design the layout in a way that the desktop device channel will have webpart zones in the mobile panel and the mobile device channel will have Publishing HTML fields instead to add the webpart. Therefore, if there will be no webpart zone in the mobile view, then there will be no zone available for the banner webpart to get added to. We tried this approach and Voila it worked. Below is the code snippet for what we actually did.

Now in the above code if you see, we have added two MobilePanels, one for the desktop and other for the Mobile. Both the MobilePanels have an attribute named IncludedChannels, which tells the panel which channel to target. "DEFAULT" is used for desktop view and "MOBILE" in our case is used for targeting mobile devices.
The above solution has however the following limitations
  1. User has to manually add webparts to the mobile device panel. You can however overcome this limitation by automating adding of webparts to the RichHtmlField.
  2. Two copies of the same webpart will be there on the page for the common webparts. However, for example say we have written a webpart whose business logic is written in a separate js file then this does not mean that the js file will be loaded twice on the page one for the desktop and one for the mobile view. The js file will be loaded only once for each channel. So performance wise, it will not impact.
This is how you can target specific content of the page layout for different channels using MobilePanels.
Please note here that the MobilePanels are now deprecated and instead we should use DeviceChannelPanels. DeviceChannelPanels are used in the same way as we used the MobilePanels above and they offer the same functionality. 

Hope this helps somewhere. :)


  1. Did you observe this issue that though the content search web parts render correctly in the appropriate device channel panel, but the search query of the web part fire from both the channels. To reproduce this issue, you can load the query asynchronously and see that the "processquery" will fire from both device channel panel - check it in Fiddler.

  2. Thanks for the post. I have just signed up for a free SharePoint 2013 site with