My hopes were high when Microsoft shipped the “Design Manager” with SharePoint 2013. It was touted as a tool for designers to simplify the process of converting HTML and CSS into SharePoint master pages. Unfortunately it never lived up to its expectations. In this post I’ll share three reasons why you should pause before using the Design Manager for your next SharePoint Online project.
1. A design package cannot be uninstalled once it’s deployed
Once a design package has been imported into a site collection, there is no way to unpublish it. In theory you could go to each file in the Style Library and the Master Page Gallery and restore them back to the original version, but it’s impractical to do so since there is no documentation from Microsoft which defines which files are included in the design package. This limitation is not a huge deal as future design changes are typically deployed using a subsequent design package (v1.2 etc.) However in certain cases it can cause major frustration (see reason #3).
2. A design package includes the master page, even when it’s not customized
The concept behind the Design Manager is that it will pick up the files that you’ve modified and package them for deployment. The official msdn article states that “In SharePoint 2013, only customized files are included in design packages. The packaging process will not export most of the default non-customized system files”. Unfortunately the master page is one of the few design files that gets included regardless of whether or not it has been customized. As of right now, there is no way to specify which files get included in the package. So in practical terms, every time you deploy a design package you are creating a new custom master page.
3. The modified master page included in a design package forces the page to render in IE10
Here is where things get interesting. First, there is a discrepancy between the default seattle.html file and the seattle.master files.
If you open a generic SharePoint Online Team Site that has not been modified in any way, it will open in the current version of IE you are using. For example, if you have IE11 installed, the page will render in IE11. Makes sense, right? This is because the seattle master page does not include a meta tag specifying which version of IE to render the pages in.
However if look at the seattle.html file included in that same generic site collection there is a meta tag, and it points to IE10.
Second, if you review the contents of a design package, you will find the seattle.html file, but you will not find the seattle.master file. Why is this relevant? Well, because any time you make a change to the seattle.html file, a new seattle.master is automatically generated. Therefore, based on the design packaging process, each time you deploy a design package it will create a new version of the master page, even if it has not been modified.
Now let’s put all these pieces together to see how the Design Manager forces pages to render in IE10:
- You develop a custom design that includes CSS and display templates, but does not include a custom master page
- You create a design package using the Design Manager
- The Design Manager picks up the default seattle.html file and includes it in the package
- You import the design package to your target site collection
- The seattle.html file gets uploaded to the Master Page Gallery, prompting a new seattle.master file to get created
- Since seattle.html includes the meta tag for IE10, the new seattle.master file get overwritten
- The new version of seattle.master now includes the meta tag for IE10
Rendering your pages in IE10 may not reduce functionality now, but it certainly could in the future. If and when that happens, the only option you would be left with is creating your own custom master page that includes the proper meta tag, or removes it altogether.
For an on-premises SharePoint design project with custom master pages, the Design Manager may fit the bill. For SharePoint Online you should consider an alternate deployment approach to branding.