Sunday, August 24, 2008

SharePoint Designer Considerations

I had this drafted some time ago and never got around to finishing it.

Internally at RDA we had a fantastic discussion on using SharePoint Designer and some best practices around it. First you must understand the primary target audience of SharePoint Designer. It is meant to be a tool for power users who aren't comfortable writing code. If they are not technical and have not resources at who can use Visual Studio, SharePoint Designer is an acceptable choice. However if there are people who know .Net on staff using Visual Studio is more preferable. We have seen a tendency in power users or developers shy away from using Visual Studio because it can become a little complicated to package up and deploy things correctly if you do now know what you are doing. We still recommend that using SharePoint Designer should be kept to a minimum.

A client had some thoughts on SharePoint and was looking for our opinion on it. Below are the questions and paraphrased responses to them.

1) Con: Code stored in database - although there is caching, performance might suffer

Fact is pretty much everything is stored in the SharePoint database, so there really aren't any performance issues. This was a little bit of an issue with SharePoint 2003 but not an issue with SharePoint 2007.

2) Con: No real deployment path with presentation, content, and code mixed together

SharePoint Designer does not facilitate deployment across different environments at all. This is not because the content is all mixed together; it is because SharePoint Designer changes are saved directly to the database. You cannot package things up as a solution or feature and then deploy it to another environment. As well, the changes are not re-useable. Now there are ways of getting around this however they are not supported out of the box and probably not supported by Microsoft.

3) Pro: Good for creative design for styling masterpages

SharePoint Designer is a good tool for making changes to themes/css/master pages and being able to visually see the changes. Remember that the changes to themes/css/master pages can be easily lost when switching between themes or reverting to a definition.

As well, when using SharePoint Designer for master page development you will only be to do this on a site by site basis. Remember that the master page is now customized (unghosted) so the change will have to be applied to each and every site collection which can become painful.

For those who do not know what customizing (unghosting) means, basically there are files that are located on the server where SharePoint server is install (commonly referred to as the 12 hive). Files that can be found there are features, templates, master pages, user controls, etc. When a page is referenced by a user the master page definition on the file server is meshed with content from the database and then displayed. After a master page has been modified by SharePoint Designer, the master page from the 12 hive is copied into the database with the modifications. Then when users reference the SharePoint page, the master page in the database will be meshed with content instead of using the master page on the 12 hive.

It is highly recommended to use Visual Studio for master page development.

4) Pro: Good for prototyping

Yes, SharePoint Designer is a great prototyping tool. It is great for trying to figure out how all the little attributes are working with each other CAML. It is great to use in a development environment.

5) Con: Does not scale well as functional complexity increases

SharePoint Designer does not suffer from scalability challenges; it is just limited in what you can do. It is scoped to doing simple workflows, DataViews, and page layouts, for instance.

6) Pro: Power users can use it

I mentioned this earlier as power users can use this tool to make tactical changes to SharePoint if technical resources are not available to do something in Visual Studio. SharePoint Designer is packaged as part of Office and is the replacement of Microsoft FrontPage.


SharePoint Designer does have its place; however because of the limitations are deployment and re-usability of its solutions, we highly recommend staying with Visual Studio. There are some challenges learning how to deploy web parts from scratch but once you learn the internal workings of how to do these sort of things, you will much better off in the long run.

We also do not recommend giving SharePoint Designer access out to every day users. One of the biggest challenges we have seen with SharePoint migration is heavy Front Page changes which made migration difficult. Do we expect this to be a problem with future SharePoint migrations, hopefully not. However we believe that if you cannot successfully package and deploy something across development, staging and production environments, it should probably not be deployed at all.

No comments: