SharePointlessness Rotating Header Image

A Guest Blog Post – So you want to use Modernizr with SharePoint?

A good friend of mine and fellow SharePoint User Experience person, Bryan Gulley, asked if I would be willing to post a guest blog post for him since he doesn’t have his own blog yet. 

One of my favorite things about the SharePoint Community is learning from each other and helping other people out. So I have no hesitation in posting for you guys Bryan’s post below. He is a great resource for me and I know he has valuable information to share with others.

About Bryan Gulley:

bryan_gulley_hsBryan is a User Experience and User Interface designer working for Slalom Consulting in the Chicago metropolitan area with extensive experience in architecting and developing custom branding solutions and frameworks for SharePoint 2007, SharePoint 2010, and Office 365.

@UXJester


How to make Modernizer and other libraries compatible with SharePoint

Bryan Gulley Monday July 2nd 2012

A couple of months ago I discovered that Modernizr breaks the wpadder.js file in SharePoint. You can guess by its name that wpadder.js is the JavaScript file that provides the web part adder menu when a page is in edit mode. Steve Ottenad found that IE has issues with extending the Array Prototype detailed in his post here http://labs.steveottenad.com/type-mismatch-on-wpadder-js/

Obviously Modernizr and several other libraries extend Array Prototype. Doing this causes the Type Mismatch error and won’t let wpadder.js load and as a result you can’t add a web part. So just throw Modernizr and all other useful libraries and shims out the window right?… WRONG!

While working on another project I was making use of the Edit Mode Panel to apply different CSS styles to the page when it was in edit mode. I figured I would try to apply the same sort of principle to loading scripts like Modernizr that have conflicts with SharePoint scripts. The result did not disappoint. You can see my code (added to the head of the master page) for the Edit Mode Panel below. The h1 tags are in there for testing so you know which mode you are in. If you are familiar with how SharePoint works in edit mode then you can remove these and just use the page status bar for reference.

<!– Edit mode panels provided to prevent modernizr and other JS library conflicts with SharePoint OOTB JS files –>

<PublishingWebControls:EditModePanel ID=“EditModePanelEdit” runat=“server” PageDisplayMode=“Edit”>

<h1>You are in EDIT mode</h1>

</PublishingWebControls:EditModePanel>

<PublishingWebControls:EditModePanel ID=“EditModePanelDisplay” runat=“server” PageDisplayMode=“Display”>

<h1>You are in DISPLAY mode</h1>

<SharePoint:ScriptLink language=“javascript” name=“~sitecollection/Style Library/Framework/js/libs/modernizr-2.5.3.js” OnDemand=“false” Localizable=“false” runat=“server”/>

</PublishingWebControls:EditModePanel>

OK great. We can add Modernizr and other feature detection libraries to SharePoint. Now what? Well I took it a step further and decided I wanted to use the header tag (<header></header> for those unfamiliar with HTML5). This tag does not render in IE8 and below. What to do?… Edit Mode Panel to the rescue.

<PublishingWebControls:EditModePanel ID=“EditModePanelHeaderEdit” runat=“server” PageDisplayMode=“Edit”>

<div id=”header”>You are in EDIT mode</div>

</PublishingWebControls:EditModePanel>

<PublishingWebControls:EditModePanel ID=“EditModePanelHeaderDisplay” runat=“server” PageDisplayMode=“Display”>

<header>You are in DISPLAY mode</header> </PublishingWebControls:EditModePanel>

Now I’m guessing several of you are sitting there excited to try this out. One word of caution; you do not want to write Edit Mode Panels for headers, footers, sections, asides, etc. It would just take too much time. If you have the time then good on you; feel free to create Edit Mode Panels to your heart’s content. If you don’t have time fear not; there are several other things you can do with the Edit Mode detection. Take hiding the ribbon for example.

I am constantly frustrated by the ribbon and how it can really mess with a design, so I decided to strip out the site actions and welcome menu and hide it in display mode. This lets me have a good looking site that doesn’t look like SharePoint and still allow contributors to edit pages and have access to the ribbon.

<script type=text/javascript>

$(document).ready(function(){

var inDesignMode = $(‘#MSOLayout_InDesignMode’).val();

var wikiPageMode = $(‘#_wikiPageMode’).val();

if (inDesignMode == “1″ || wikiPageMode == “Edit”){

$(‘#s4-ribbonrow’).show();

}

else {

$(‘#s4-ribbonrow’).hide();

}

});

</script>

Final thoughts. If we can’t make use of feature detection libraries like Modernizer without creating a twin element using a div while the page is in edit mode why use them at all? Simple. It’s in the name of the type of library. With the mobile device zombie apocalypse upon us and practices like responsive design becoming more common place we will need feature detection. It is far easier to ask a browser if it supports a feature than a device. Besides, who wants to maintain that kind of device library? I know I don’t.

One Comment

  1. Thomas says:

    Thanks Bryan for sharing your thoughts on Modernizr compatibiliy with Sharepoint. Bruce Bowman of Adobe has gone on the record as saying Modernizr is an “indispensable tool”, checking out some of it’s features I can see why.

Leave a Reply