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.

2 comments:

sympmarc said...

Joe:

I'm curious why you would say that CQWPs are bad for a public-facing site. Could you explain more about your thoughts on that?

I can understand your point about hiding the ribbon with CSS. It just shouldn't be there at all unless some of your external users will be using it. (It all depends on what your external-facing site if for, of course. There's no one-size-fits-all-answer.)

M.

Joe said...

Hi Marc,

Getting web parts to work generally requires a few components that I like to keep off of public facing web sites when possible. Web part zones generate junk HTML for instance, and if I am not mistaken, the web part manager also generates some inline script. There are times when this is an acceptable side effect, but this should be a conscious decision one makes. 

The talk I went to was simply using a CQWP because it was easy to do, and they were presenting this as a good practice. The solution they implemented could just as easily been handled with a simple user control that would result in a much smaller page weight.

I completely agree with you that there is no one right answer for all problems. I just wanted to alert people to the downside of such an 'easy' solution. Too many SharePoint devs don't ever look at page weight or the HTML their sites generate, and this is a necessity when exposing sites to the wild.

Btw, Waldek has some great info on using web parts in a lean way. 
http://blog.mastykarz.nl/web-parts-in-content-with-master-pages-without-the-form-tag-no-problem