One of the truly great and new features in SharePoint 2013 (Preview) is Device Channels. In a nutshell, Device Channels provide a model for content editors, site admins and developers to provide content manipulation for different browsers and devices based on their capabilities.
The old way of doing things
In SharePoint 2010 the official browser support is fairly clear, and you can see the full table of supported browsers here. For comparison, have a look at the full table of supported browsers for SharePoint 2013 here. In essence, Internet Explorer 7, 8 and 9 are supported for SharePoint 2010, assuming you are using the 32-bit version. Google Chrome and Mozilla Firefox are also now supported, whereas Internet Explorer 6 is totally not supported.
For public-facing sites the typical approach was to create one Master-page, and inject or replace the linked CSS-files depending on browser version. In reality this meant that if anyone was still using IE7, we’d inject some CSS hacks as to not break the site visually or functionally. Simple HTML would do the trick:
1: <!--[if IE 7]>
2: <link rel="stylesheet" type="text/css" href="/_layouts/JussiOnSharePoint/IE7hacks.css"/>
3: <![endif]-->
While highly effective and simple to use, it also caused a lot of issues. One being that we’d easily end up doing multiple if-decisions to detect all possible browser versions, and point to different CSS-files. It was also hard to target specific browsers based on their User-Agent strings, such as IE7 with specific capabilities. URL Rewrite module for IIS gave us a somewhat working solution but required some tinkering with IIS and one had to tinker with the regular expression-based rules to catch all browsers, combinations and options. Even then SharePoint’s support for detecting different browsers was limited at best.
Device Channels to the rescue
Device Channels are used to detect which browser a visitor is using, and to replace the Master page to a more suitable one. This means we can use Device Channels to detect mobile device users, tablet users, desktop users and differentiate between these channels and the capabilities each device’s browser has. As an example, we might choose to not differentiate iPad users from desktop users, since essentially iPad-users tend to have a rather good resolution and the built-in Safari browser supports most capabilities we might already be using.
Device Channel functionality does not remove the need to fine-tune CSS or HTML to provide hacks for specific browser, but gives a nicer way to approach the problem space.
The requirement to use Device Channels is that your Site collection has to have Publishing features, so enable that if it’s not yet enabled in your Site Collection:
Make sure to also enabled the Web-scoped Publishing Feature:
The SharePoint Server Publishing Infrastructure Feature, which is scoped for the Site Collection, also depends on the hidden Publishing Mobile Feature. By this time, you should also have the Publishing Mobile Feature enabled. You can verify this with PowerShell:
Configuring Device Channels
Now that Device Channels is enabled through the Publishing features, we should be able to create channels for our target browsers. You can choose to target mobile and non-mobile browsers. In Site Settings | Device Channels, you should see the list for all the channels. You’ll have a Default channel, which is used by default or when any of the previous channel rules do not match.
I’ve added two more channels – one for Google Chrome-users, and one for Internet Explorer 7 users. The reason I’m interested in IE7 users is that it’s officially not supported in SharePoint 2013.
For Google Chrome users, the alias that I’m using is ChromeDesktop – thus, I’m planning to target desktop users of this fine browser. In Device Inclusion Rules for this channel I’ve included my User-Agent string:
To find out your User-Agent string, go here.
For IE7 users, the Device Inclusion Rules are similar but targeting the IE7 User-Agent string:
I’m using Windows Server 2012 (RTM) as my development platform, so to check what the User-Agent string for older IE versions is simply change your browser mode to IE7 via the Developer Tools (F12) in IE:
And reload the whatsmyuseragent.com page.
Now we have three channels: ChromeDesktop, IE7Desktop and Default. Let’s set different Master pages for each by going to Site Settings | Master Pages:
By default all channels are using the same v15.master Master page, which you can now change to any other Master page you have deployed in your Master Page Gallery. When users access your site in Google Chrome or IE7, they’ll be given the same content with a different master page. All others get whatever you’ve set for the default channel.
Custom Master pages, Page Layouts and Device Channels
You can now create your customized Master pages and Page Layouts to better target and manipulate content for different channels. I created a simple Visual Studio 2012 project as a delivery vehicle for my customized Master pages and Page Layouts. It’s exactly the same as what you would do in Visual Studio 2010 when you target SharePoint 2010.
I’ve added one module as a container for my two custom Master pages, GoogleChrome.master and IE7.master:
I’ve also added a GoogleChromeWebPartPage.aspx Page Layout in case I want to fine-tune content layout for a given channel.
The Elements.xml is very simple and minimal:
1: <?xml version="1.0" encoding="utf-8"?>
2: <Elements xmlns="http://schemas.microsoft.com/sharepoint/">
3: <Module Name="MasterPages" Url="_catalogs/masterpage" Path="">
4: <!-- Custom Master page for Google Chrome users -->
5: <File Path="MasterPages\GoogleChrome.master" Url="GoogleChrome.master" Type="GhostableInLibrary" />
6:
7: <!-- Custom Master page for IE7 users -->
8: <File Path="MasterPages\IE7.master" Url="IE7.master" Type="GhostableInLibrary" />
9:
10: <!-- Google Chrome Page Layout: Web Parts everywhere -->
11: <File Path="MasterPages\GoogleChromeWebPartPage.aspx" Url="GoogleChromeWebPartPage.aspx" Type="GhostableInLibrary">
12: <Property Name="Title" Value="Web Part Page Layout for Google Chrome devices" />
13: <Property Name="ContentType" Value="$Resources:cmscore,contenttype_pagelayout_name;" />
14: <Property Name="PublishingPreviewImage" Value="~SiteCollection/_catalogs/masterpage/$Resources:core,Culture;/Preview Images/BlankWebPartPage.png, ~SiteCollection/_catalogs/masterpage/$Resources:core,Culture;/Preview Images/BlankWebPartPage.png" />
15: <Property Name="PublishingAssociatedContentType" Value=";#$Resources:cmscore,contenttype_welcomepage_name;;#0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF390064DEA0F50FC8C147B0B6EA0636C4A7D4;#" />
16: </File>
17: </Module>
18: </Elements>
The Feature is Site-scoped, and has no code:
After deploying the solution, I should be able to go back to Site Settings | Master Pages to verify that I can now select the corresponding Master pages for each channel:
The final configuration for each channel looks like this:
In my Visual Studio project I can now change any relevant portions of the UI via the targeted Master page. Let’s change the icon for both Master pages – the Google Chrome Master page will get the nice Metro Windows 8 Modern UI Style-themed icon, and IE7 will get the old but familiar icon:
To replace the site icon, just change the line that points to SiteLogoImage:
1: <SharePoint:SiteLogoImage CssClass="ms-siteicon-img" name="onetidHeadbnnr0" id="onetidHeadbnnr2" LogoImageUrl="/_layouts/15/MobileUI/chromeicon.jpg" runat="server"/>
I’m including the two icons in my solution package and deploying them to /_Layouts/15/MobileUI. I could also change the relevant CSS-files, provision my own custom logic or add custom code to better differentiate between browser versions. Device Channels essentially give me a path, and it’s up to the developer to decide what happens then.
Regular users will now see the default channel. This is the view when accessing my site with IE10 on Windows Server 2012:
By switching the browser mode to IE7 (via Developer Tools), I get the new site icon:
You’ll also see that the Edit Links-control has moved a bit. This is because the Master page I’m using as a template is from a different one than v15.master, which the default channel is using.
Google Chrome users are also feeling the love:
Page Layout is the same for all channels, there’s no built-in ability to change that on the fly. What is needed is some logic in my Page Layouts to decide what to show and what to hide based on the channel.
In my custom Page Layout, which was part of the small solution package I deployed, I’m using a Device Channel Panel, which is part of the Publishing functionality. This allows me to include or exclude certain parts in my Page Layout, such as HTML-tags. I need to use my Device Channel naming inside the Page Layout, so it’s probably a good idea to keep the naming simple and short. Specify a channel (or channels) in the IncludedChannels-property:
1: <PublishingWebControls:DeviceChannelPanel runat="server" IncludedChannels="ChromeDesktop">
2: <b>This is for Google Chrome users only</b>
3: <img src="/_layouts/15/MobileUI/chromeicon.jpg" border="0" />
4: </PublishingWebControls:DeviceChannelPanel>
When I replace my Page Layout for the landing page to my custom Page Layout, I’m seeing the same content with IE10 and IE7 as before. When using Google Chrome I see additional content:
Additional reading
There’s some good content on Technet for mobile device support and capabilities for SharePoint 2013. Other than that, not much officially available from Microsoft yet.
September 19, 2012 at 10:01 am
Thanks Jussi,
Great write up and exactly what I needed this week!!
September 19, 2012 at 11:20 am
Thanks Jussi,
In your solution you provision your master pages, and then setting MANUALLY the corresponding Master Page for each chanel. Is it possible to automate this process defining those in Site definitions for example?
Quick question, maybe I missed that part
September 19, 2012 at 12:14 pm
Hi Ivan,
Sadly, at least with the current beta bits that are publicly available, there doesn’t seem to be a way. There’s a really sweet looking class within Microsoft.SharePoint.Publishing.Mobile called DeviceChannel, which has an Add() -method. Unfortunately that’s both sealed and internal, so one probably shouldn’t use it for now. I couldn’t find anything through Powershell, or anywhere else for this, so I’m assuming for now that it’s meant to be set manually.
There’s a list where the Device Channel configuration is stored (called DeviceChannels) which you essentially manipulate through Site Settings normally, so simply inserting rows in that list might be a way, but I don’t think it’s a good idea.
September 19, 2012 at 12:43 pm
Thanks!
September 28, 2012 at 4:24 pm
Thanks for the post! Considering the amount of user agents today, what’s your best bet for coming up with a manageable solution. Is it possible to group UAs, based on the form factor for instance?
October 16, 2012 at 1:21 pm
Hi Antti,
Several options for this. First, you can have more than one devices in a single device channel. A user agent string typically does not give you the device capabilities such as width or height, so you’d have to do the classification manually. Let’s say you end up doing two device channels – one for all Nokia-based devices (including Lumia, Symbian-based phones etc), and one for all Android-based devices (tablets, phones etc).
You could then pass a querystring as part of a page call, that selects the correct device channel. The querystring can be freely named to a friendly name, such as NokiaMobileDevices and AndroidMobileDevices. This is a somewhat manageable solution in my opinion.
Second option would be to default all mobile devices to your .browser-file(s), and do the tinkering there. Create a device channel there with the magic string $FALLBACKMOBILEUSERAGENTS; – see details here: http://msdn.microsoft.com/en-us/library/ms228122(v=vs.100).aspx
Third option would be to have some sort of logic in your master page to query device capabilitieS (jQuery mobile perhaps?) and pass that on as a querystring to the correct device channel.
October 12, 2012 at 7:01 pm
Hi Jussi
this is very useful as we have a site we are close to deploying in SP15 where the client has today come back showing that 29% of their users are still on IE7 (grrr…).
Have you had any success in creating a menu system in a masterpage targeted at IE7 via Device Channels? As far as we can tell the standard global menus are deeply broken under IE7; a solution to this could remove a whole bunch of pain in the market.
October 16, 2012 at 1:06 pm
Hi Simon,
Thanks for the comment. I haven’t bothered creating anything against IE7 anymore, since IE7 is officially not supported on SharePoint 2013. So even if you’d get it running in an intranet/extranet-type scenario it would still fall out of the scope in terms of support and future upgrades that might break things. I do realize that IE7 is still widely used, so for now I’m recommending to my clients to either upgrade to a newer IE, or if that’s too time consuming/not possible, avoid using such features that do not work with IE7. For public-facing sites that’s not such an issue since you’d still be building custom interfaces, and could handle any IE7-type of issue through your customizations (such as CSS and Javascript).
November 30, 2012 at 1:27 pm
Please could you post a link to the visual studio 2012 project to check the elements.xml file information (the image is not complete.
Thanks
December 4, 2012 at 9:30 am
Hi Jose,
Copy-pasting it here didn’t work, so here’s a PasteBin.com capture of it: http://pastebin.com/ckcuyYHY
April 18, 2013 at 7:31 pm
It looks like you cannot place a WebPartZone within a DeviceChannelPanel. Is this true and if so why? What is the recommended way to target content at specific device channels?
April 21, 2013 at 5:33 pm
Hi Mike,
It’s true, that you cannot place a WebPartZone within a DeviceChannelPanel. There’s a workaround blogged by Waldek Mastykarz here: http://blog.mastykarz.nl/inconvenient-conditional-web-parts-sharepoint-2010/
It’s not the most obvious workaround but at least there’s a way.