Tag Archives: customization

Targeting multiple browsers and devices in SharePoint 2013 using Device Channels

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="MasterPagesGoogleChrome.master" Url="GoogleChrome.master" Type="GhostableInLibrary" />
   7:      <!-- Custom Master page for IE7 users -->
   8:      <File Path="MasterPagesIE7.master" Url="IE7.master" Type="GhostableInLibrary" />
  10:      <!-- Google Chrome Page Layout: Web Parts everywhere -->
  11:      <File Path="MasterPagesGoogleChromeWebPartPage.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.

The fine and elusive line between OOB, configuration, customization and coding in SharePoint projects

The challenge

SharePoint solves many problems but often introduces several new ones you hadn’t heard of. As a SharePoint expert your asset is the ability to tell the complex stuff in layman’s terms. One of these is the cumbersome distinction between an out-of-box (OOB) and vanilla SharePoint, a configured SharePoint, a customized SharePoint and a custom-built SharePoint.

These are phrases I often hear during meetings with companies using or planning on using SharePoint:

We don’t want any customization, just OOB. Oh, and can you add a few custom workflows too?

We need a custom feature for news/team sites/custom publishing/<insert functionality here>

The quick launch navigation should look a bit different

It shouldn’t look like SharePoint

How much time is this going to take? I was told it works after running setup.exe

What do you mean taxonomy and Content Types? We just want document management with metadata

Establish the road ahead: OOB (vanilla) SharePoint

I think this one is fairly obvious and self-describing: A customer need is tackled with a plain SharePoint deployment. It can be a small farm, a large farm or anything in between. It might include some language packs and there might even be multiple web applications or at least a few site collections. This is fertile proving ground for future services and increased productivity, since all (or almost all) features are readily available and mostly enabled. There’s the basic configuration for a publishing portal and team sites, My Sites are up and running and there’s even a simple user profile synchronization between Active Directory and SharePoint.

It’s a likable approach and less risky than the other options described later in this article. I think this fits the need for any company wanting to either evaluate SharePoint or not really needing anything custom-tailored. There’s nothing bad if you want a bulk SharePoint: You get good value for the money and there’s a lot of room for improvements when your organization grows to demand additional functionality. I’ll save you with the tired car analogies.

Commit & consult: Configured SharePoint

Some companies preemptively know their needs are beyond a vanilla deployment. They want stuff to be configured according to their specifications, needs and – sometimes – whims. Nothing wrong here. SharePoint is still the Swiss Army knife of collaboration and portal platforms, no harm done configuring things a bit further.

Here’s the hard part: What’s included in a configured SharePoint deployment? As I see it, there’s

  • Setting up Service Applications, instead of just deploying them in autopilot
  • Configuring search with intricate settings, keywords, best bets and so forth
  • Establishing a managed metadata taxonomy and/or folksonomy
  • Designing an information hierarchy, with some thought put into it
  • Fiddling around with navigation properties, page layouts and similar
  • Providing external services, such as extranets for third parties
  • Conforming to organizational restrictions, requirements and standards

On the other hand, these are not part of this approach:

  • Creating new master pages (with SharePoint Designer, Visual Studio or whatever tool you want to use)
  • Modifying any of the OOB files under SharePoint root
  • Trying to circumvent some artificial limitation, such as a default button in a view underneath _layouts
  • Fixing things to better suit your needs – hacking around the file systems and IIS
  • Inventing features that are not there but desperately needed

I always feel when I’m moving beyond a typical configured SharePoint deployment. You get requests that take a lot of time and effort to understand and internalize. You start opening application page files (the .aspx –files sitting underneath 14TEMPLATELAYOUTS) in notepad++ trying to understand how a specific functionality works, or if there’s a shortcut to do things differently. You download Reflector. You hope things will work since there really is nothing on Google or Technet or MSDN or some other discussion board to guide you. White papers fail to mention those small details you stumble on. You feel it’s time to move on to a customized SharePoint approach.

Invent, build and go wild: Customized SharePoint

This is probably my least favorite model when going deep with SharePoint. What it basically translates to is the fact that a lot of the requests you get are really specific and often quite vaguely described. It’s not because whoever is requesting these things for you to do is doing it just to be mean, but rather that they are not deep diving the technical and fundamental aspects of SharePoint. Nor should they have to, that’s why you were called in the first place.

The challenging part of a customized SharePoint is that a lot of your time is spent troubleshooting, guessing and wondering how things should be built, instead of designing the optimal way of crafting the outcome. I’m not going to go into different aspects of project delivery models here, so suffice to say that this seems to happen with all widely-used approaches.

Many a developers I’ve had the chance to collaborate with over the years often despise this approach. They feel it’s not real coding, and it’s a mishmash of both good and bad practices. “Fiddling with tiny xml bits, meh”, they say. It’s like you’re given permission to go wild and forget about the rules and principles of proper craftsmanship and just do it on the go. Keep adding more and more features until you don’t really know what you’ve added and what should be removed.

What should be in a customized SharePoint deployment? This:

  • Quite liberal usage of SharePoint Designer with a consistent mindset
  • Custom site templates/site definitions/templates in general
  • Third party tools to solve tricky issues – these often work, but quite often fail too
  • Custom (declarative) workflows
  • Custom InfoPath-forms, no code-behind, but rules and views
  • Clever mashups and innovations around Access Services, Office Web Apps and other “new stuff”
  • Custom Content Types, Site Columns and other SharePoint building blocks
  • Sometimes small amounts of custom code, either neatly packaged or just xcopy’d 

What shouldn’t be in a customized SharePoint deployment:

  • Overwriting default files on the disk
  • Some code you found googling and copy-pasted in CONTROLTEMPLATES, but you don’t really know what it does or why it needs to be there
  • Custom functionality that require a plethora of support overhead. Think custom workflows requiring a custom timer job that is executed through a Powershell script from a logged-in console session. Or some similar abomination.
  • Inconsistent results with consistent effort. Something is fishy here
  • Immovable functionality from development to any other environment (QA/test/production etc)
  • Consulting-by-clicking: Spending hours clicking through the interfaces and SharePoint Designer to replicate something that’s been done before

SharePoint deployments often sneak their way from OOB or configured models to a customized approach. The problem to tackle is the fact that most stakeholders still feel it’s a “basic” approach while you are left to solve colossal problems with minimal budget, time and resources. After all, it’s probably something you encounter every day.

Design, develop, deploy: Custom-built SharePoint

This is a tough one. Combining the benefits and wisdom of traditional software projects with the OOB features and restrictions of SharePoint. The recipe for disaster is already there while the opportunity for great wins is written all over it.

The “DDD”-approach is for companies who have been exposed to SharePoint early on and are experienced users. They know tweaking and fine-tuning is allowed, and they can (or at least should) deliver requirements and needs in clear and concise specifications. Regardless of the project methodology being used it all boils down to an iterative approach: Define, refine, test, discuss, refine more, test again, finalize, move on.

I know I’m probably incorrect in assuming that all customers would prefer this option combined with the easiness and cost-effectiveness of the OOB approach.

What should be in a custom-built SharePoint:

  • Neatly arranged packaging scheme for all customizations and artifacts
  • Tested and working scripts for settings up the infrastructure
  • Source control repository (think: TFS)
  • Automated tests
  • Continuous Integration
  • Built-in support for multilingual environments
  • Almost anything can be customized, when deemed reasonable and cost-effective: Master pages, Page Layouts, the overall UI, workflows, templates etc.
  • Versioning and roadmaps – we’re here, we are getting there and this is what’s going to happen next
  • Readable and good documentation. Not necessarily hundreds of pages but something that tells the unitiated reader the what, why and how.

What shouldn’t be in a custom-built SharePoint:

  • Anything that can be achieved with SharePoint Designer
  • 25 installation packages. You know you are doing it wrong
  • Quick hacks to circumvent built-in functionality – either you shouldn’t be doing it, or you are approaching the problem incorrectly
  • A lot of clicking. I know some consultants prefer the mouse and the sound of clicking but still, this is more about developing and crafting ingenious solutions than dragging and dropping things on the canvas
  • Fully custom-built ASP.NET applications hosted inside SharePoint. The benefit of SharePoint is lost, and all effort goes to maintaining wires between the two systems