Thursday, October 20, 2011

Build for the end user

I attended a session at the European SharePoint conference today about building public facing websites using SharePoint. I respect the effort that the speakers put into their session and I agree that they had a nice looking web site created. However I strongly disagree with the methods they demonstrated and was disappointed to see these methods demonstrated as good practices.

There were two specific methods that I strongly disagree with demonstrated at the session:

  1. Hiding the ribbon for anonymous users with CSS.

  2. Using web part zones and web parts like the Content Query Web Part on public facing page layouts.

Both of these techniques are a symptom of what I call building for the editor. As developers we often work very closely with the editors when developing the site, and we thus tend to focus on making the site in such a way that the editor has a very easy life. This is not necessarily bad, but it comes at a cost. If we look at the big picture, the ultimate reason for the website being built is to be consumed by the end users. Editors are an important part of the picture, but we should be building the site for the end users. So why would that be different than building for  editors? Simple answer: page weight.

Why care about page weight? The days of large bandwidth and low latency are over (if they were ever here). Many users these days are accessing your site via networks that are not gigabit LAN, but instead are  3G networks or something similar and will notice when your home page is 300kb and sends another 300kb of JavaScript and CSS along. There are real costs attached to this in money, battery life and time spent waiting.

The good news is that there is a solution. In a previous blog post http://jcapka.blogspot.com/2011/08/public-facing-sites-using-sharepoint.html I introduce a webtemplate that includes a very lean masterpage and serves as a good starting point for building public SharePoint sites.