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 being "one of the famous ones," and also 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."
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 proof of concept"). At the very least though, your proof of concept should involve building out 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 the purposes of 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?" The more complex the site, the more complex these decisions can get, Jon said. 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 then 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, whereas the wiki just looks like regular team site.
Jon then shifted back to the Developer Tool to help figure out which parts of the HTML belong in the 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 that you'll want in the 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 nightanday.master is applied by default. Jon cautioned that you not pick the Blank Master Page and simply press on, as it will end up generating 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 up 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 the 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 over to Visual Studio, but he's "found it to be worthwhile." Jon said that 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 to only 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 which 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 was present when it wasn't desired. Back to the Developer Tool to begin debugging, where Jon found the PlaceHolderSearchArea in the 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," and 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 keep doing this [debug and test] iteratively" until you achieve the desired result.
Read our complete coverage of Microsoft TechEd North America 2011:
- 'Applying Branding from an Existing Website to Microsoft SharePoint 2010' with Jon Flanders
- 'Creating Self-Service Analytic BI Applications with Microsoft SharePoint 2010' with Peter Myers
- 'The 10 Immutable Laws of Microsoft SharePoint Security' with Rick Taylor
- 'Integrating Microsoft SharePoint 2010 and Microsoft Dynamics CRM Online' with Girish Raja
- Daniel Benson & Mark Stone on 'Creating Great End User Experiences with Fast Search for SharePoint 2010'
- 'Claims Identity in Microsoft SharePoint 2010' with Paul Schaeflein
- Chris Mayo on 'Developing Collaboration Solutions in the Cloud with Microsoft SharePoint Online'
- 'Creating Custom SharePoint Service Applications 101' with Todd Bleeker
- Aftab Alam & Chris Hopkins on 'IT-Centric Dashboards in Minutes with Microsoft SharePoint 2010 Using Microsoft Visio/Visio Services'
- 'Plan and Deploy My Site for Microsoft SharePoint Server' with Chris Gideon