TechEd: ‘Applying Branding from an Existing Website to Microsoft SharePoint 2010’ with Jon Flanders

TechEd: ‘Applying Branding from an Existing Website to Microsoft SharePoint 2010’ with Jon Flanders

by | May 16, 2011 | SharePoint 2010

Bamboo Solutions | Ohio Tobacco Use Prevention and Control Foundation Selects Bamboo Solutions Grant Management Software

Following frustrations such as a delayed flight and an eventual arrival in Atlanta only to be told that my hotel was overbooked, but they’d made arrangements for me to stay elsewhere (Seriously?  I’ve heard of being bumped from a flight, but bumped from a hotel?  Whatever happened to Southern hospitality?), things began to look up when I made it just in time to Jon Flanders’ session on Applying Branding from an Existing Website to Microsoft SharePoint 2010.

Jon’s stated agenda was that attendees would “Learn the techniques to create a SharePoint 2010 website from an existing branded website.”  Discussing public-facing SharePoint sites, Jon referenced the oft-cited Ferrari as “one of the famous ones.” Also, he mentioned Hawaiian Airlines and Recovery.gov as examples of noteworthy branded SharePoint sites.  Asking the question, “How do we make a SharePoint site look like a public site?”  Jon answered by saying, “It’s not as difficult as you think,” and explained that in his demo, he would go through steps “to create a proof of concept site.”

Before diving into his demo, Jon showed a couple of slides. On the first of them, he outlined the skills necessary to apply branding from an existing site to a SharePoint 2010 site, including An understanding of SharePoint 2010 Master Pages, Page Layouts, and other Web Content Management (WCM) capabilities; Web design skills including HTML, CSS, JavaScript, XSLT, and any other client technologies used on your customers’ websites; Understanding of ASP.NET is a plus; and image manipulation skills (Expression, Photoshop, Fireworks, etc.) are also helpful.

The first step in the process is to “pick what website to build,” and Jon cautions that you not overcommit and that you keep it as simple as possible (i.e., “Don’t try to recreate the whole [existing] site as part of the proof of concept”).  At the very least, your proof of concept should involve building a homepage and a subsection with several pages inside that section.

Shifting into demo mode, where he remained until a few minutes of Q&A at the end, Jon mentioned that all of the code he was to demo would soon be posted on his blog.  Using an existing (though not public) “Blue Yonder” HTML site for his branding demo, Jon began by creating a New Web Application in SharePoint 2010, noting that “You probably want to select Claims Based Authentication” for security purposes.  Jon chose to allow Anonymous Access, ticked a few additional options, and left most of the defaults in place.

While SharePoint was working, Jon shared a look at the existing site’s HTML in order to figure out, “What HTML do I want in my Master Page, and what do I want in the body?” Jon said that the more complex the site, the more complex these decisions could get.  At this point, Jon plugged the IE Developer Tools, or the “F12 tools” as they’re commonly known, noting the built-in tabs for CSS, HTML, Debugging, Network, and more.  Jon recommends keeping the Developer Tools open in a window side-by-side with the existing site.

Jumping back to SharePoint, where the new application had been created, Jon created a site collection at the root.  You’ll want to pick one of the available publishing templates because WCM features are already enabled on those templates.  Publishing Portal or Enterprise Wiki are the two options, and Jon selected Publishing Portal since that one already has a design applied to it. In contrast, the wiki looks like a regular team site.

Jon then shifted back to the Developer Tool to help figure out which parts of the HTML belong in Master Page and which belong in the body.  Jon showed that this task is made easier by choosing “Select by element” to identify individual page elements on the existing site and their associated HTML, and noted that the header and footer are typically things you’ll want in Master Page.

With a new top-level site created in SharePoint (a WCM site), we have our starting point,  but first, we need to get a Master Page in place, so it’s off to SharePoint Designer we go, where Jon showed that the night and day. Master is applied by default.  Jon cautioned that you did not pick the Blank Master Page and press on, as it will generate an error (as he demonstrated).  Instead, select the Blank Master, immediately delete all the existing code, then paste in the code from a recommended Starter Master Page, such as one of Randy Driscoll’s Starter Master Pages.

Or, to avoid all of the “copy and paste garbage,” Jon said that he likes “to bring all SharePoint artifacts into Visual Studio [because it] does a bunch of work for me in terms of packaging stuff up that I can later deploy.”  As a result, Jon has “created a Project template that maps to the Master Page folder … and I have a feature receiver that deploys Master Page as a Starter Master.”  Having done so, it’s as easy as opening in Visual Studio and right-clicking to deploy.  The only downside Jon noted to this approach was that things in SharePoint Designer need to be moved to Visual Studio, but he’s “found it worthwhile.”  Jon said this automation “can also be done through PowerShell scripts” but stressed that “you should have some process.”

Jon explained that he had a SharePoint Style Library-mapped path in Visual Studio (including images, CSS, etc., that have been pre-packaged in a folder to be added) and then delved into the Master Page code.  Adding his custom CSS code to the SharePoint site (After=”corev4.css”), Jon then said that there are two main ways to hide the Ribbon when you don’t want it present: Wrap it in a special, security-trimmed SharePoint control, or set it only to show up when you’re in edit mode (which, by default, requires permissions).  Jon prefers the second method and showed the helpfully commented Ribbon area of Randy’s Starter Master Page code, adding his preferred get-rid-of-the-Ribbon code in the process.

Now it was time to get the body HTML in place.  Removing some menus by making visible= false, Jon first added the header code above asp:ContentPlaceHolder, and the footer beneath that same PlaceHolder line of code.  Next,  Jon copied and pasted the existing, body-identified content here.  To deal with images that are now in a folder inside the Style Library, it’s necessary to slightly alter the img runat code (refer to the source code to be posted on Jon’s blog for details) and Deploy.

After refreshing the demo site, Jon noted that it’s “not perfect, but we’re getting there.” Problem areas included not being able to scroll the body and the default search box being present when it wasn’t desired.  Back to the Developer Tool to begin debugging, where Jon found the PlaceHolderSearchArea in Master Page, set visible=false, and hit Deploy.  Refreshing again, the search box was now gone.  “Start turning off SharePoint things and turning on your things” describes this part of the process.  Jon explained that hiding the Ribbon “doesn’t mean that other SharePoint CSS isn’t being applied,” Further debugging showed that “SharePoint is making it so that the body can’t scroll.”  Getting rid of overflow: hidden enabled the body content to scroll as seen on a refresh, at which point things were “Starting to look good… the idea is to keep doing this [debug and test] iteratively” until you achieve the desired result.

Read our complete coverage of Microsoft TechEd North America 2011:

Get a Demo
Contact Us
Newsletter Signup