In case you haven’t noticed, recently we launched our new website. In the upcoming series of How we did it articles I will give you a glance under the hood and tell you how we built our site. In this first part I will tell you how we did the branding of our new website.
Branding SharePoint 2010 Internet-facing websites – the dilemma
SharePoint 2010 is a platform for developing web applications. Out of the box it ships with a rich set of functionality that can be used as building blocks for your solutions. While those building blocks accelerate the development process and standardize the solution, they also depend on some functionality. To put it simple: in order to use those components you have to include some prerequisites in your solutions.
Although it might seem a lot, you really need all of it in able to author content in SharePoint. The back-end functionality that provides the rich editing experience requires all of those components to work correctly so if you want to benefit of the rich content authoring capabilities that SharePoint 2010 offers, you need those core components.
The branding of Internet-facing websites has in most cases nothing to do with SharePoint. In fact, unless you look under the hood, you might even not be able to tell that the website that you are looking at is a SharePoint website. So if you don’t use the most of the core components on the public part of the website, do you really have to include it?
The truth is that there is no magic switch in SharePoint that would allow you to optimize your website for anonymous users. You can achieve a lot but you definitely have to know the platform and know what you are doing in order to provide a supported and maintainable solution to your customer. While building an Internet-facing website on the SharePoint 2010 platform you will spend most of the time on the trade off: whether to give in on the beautiful HTML delivered by the designer or to replace standard components with your own to support the semantic HTML.
Our site is no different than any other site built on the SharePoint 2010 platform and when we started we stood for the same choices as you do. However, instead of going on with the trade offs we chose a different path.
If you looked under the hood of our website you might have noticed that the rendered HTML is pretty neat. Also when looking at the page footprint, you might have noticed that we don’t load anything from the SharePoint 2010 framework at all. Does it mean we gave up on the standard functionality totally and we’re not using it at all? No, we didn’t. In fact, we didn’t change anything about the authoring side of our website.
We started building the branding of our website like we usually do: we translated the User Experience drawings into HTML. Paul did excellent job of creating semantic HTML, prioritizing stuff in source so that it’s optimized for accessibility and search engines. Then we chose to do things differently.
Normally, we proceed with implementing the HTML in SharePoint. We slice the static HTML pages into pieces which we then divide into Master Pages, Page Layouts, Web Parts and controls. In this tedious process we strive to stay as close as possible to the original HTML so that is as semantic and accessible as the original was. Although it’s more challenging than branding standard SharePoint components, it gives better results and delivers better experience to end users. As I mentioned before, this time we did stuff differently.
In the next part of this How we did it series I will tell you how we optimized our website for performance. Stay tuned!