Best Practices of using SharePoint Designer in an Enterprise Farm

 

Many of my customers asked me about some kind of basic guidelines for their end users for using SharePoint designer in a large enterprise farm. Unfortunately, there is not much out there except scattered information, so I decided to put one myself to help SharePoint community.

Purpose

SharePoint designer (SPD) is a very powerful tool for designing and customizing SharePoint sites. However, understanding of proper usage of SharePoint designer is very important especially if the sites are hosted in an Enterprise environment with large number of users. This document provides some of the guidelines and various best practices of using SharePoint designer in a shared environment.

 

Guidelines

Generally, SharePoint designer is ideally suited for business analysts, designers and power users. End users must be restricted using SPD. For SPD access, site collection administrator is responsible for providing access to these users on various sites. No tool is better if it’s used incorrectly.

Followings are various best practices and guidelines for using SPD, which are as follows:

 

1. Data Form Web Parts

Data Form web part (DFWP) allows connecting to various data sources and surface data on SharePoint sites.

Best Practices:
It is best practice to avoid using DFWP which returns large number of list items or data items in a shared environment. Simple reason behind this guideline is, when loading large number of data using DFWP, SharePoint runs queries in background to fetch data which most times affect other users. Large custom queries affects performance of the SharePoint farm and sometimes it has potential to bring entire SharePoint farm down; therefore it is very important to use DFWP with simple and lite amount of data. Secondly, if the page (where DFWP is hosted) is constantly being requested at the same time by large number of users, then that can also affect overall performance of the SharePoint sites.

 

2. Customizing Pages

There are primarily two ways SharePoint pages can be customized 1) using SPD and 2) using Browser.

Best Practices:
Avoid creating pages using SPD as long the page can be customized using Browser. The reason behind this is when pages are customized using SharePoint designer these pages will be now served from the back end database instead of a disk file on a front end web server. Therefore, every time page is requested the page is loaded from database which is in slower than loading from disk file from web front end server. Also, note that these customized pages are difficult to upgrade for next version of SharePoint.

 

3. Branding

Designers can change various look and feel of SharePoint sites, such as modifying Master pages, page layouts and Cascading style sheets.

Best Practices:
For a large enterprise, it is best practice to have a consistent look and feel throughout entire SharePoint farm especially for intranet based portal sites. In general, one must avoid changing master pages, page layouts or CSS for for collaborative sites such as Team sites. In an Enterprise farm, usually there is a branding or design team who should be responsible for overall design. For consistent branding it is recommended to use developer based solutions instead of using SPD. The use of SPD for branding should be limited to designers only.

4. Workflow

With SPD, one can design custom workflows that add no-code application logic to your SharePoint sites.

Best Practices:
Avoid creating complicated workflows for a simple process. In general, it is best practices to allow only Business Analysts to create custom workflows using SPD as they understand business process well and can simplify business processes. However, in cases where SPD based workflow is too complex to design then it is usually a good idea to involve developers who may be able to create using code.

 

5. Using jQuery

jQuery is a very powerful JavaScript library which allows easier modification of elements on an HTML page without page refresh. In other words it uses Asynchronous JavaScript and XML (AJAX) based technology to communicate with server. Usually, this library can be used with Content Editor web part.

Best Practices:
Avoid using jQuery for complex and large list items queries. Basically, this is the same guidelines as mentioned before which relates to DVWP. Avoid running large queries in background in a shared environment which affects performance of the entire farm and hence affecting other users. Another guideline is to avoid uploading jQuery to conventional document libraries, if one is already available in _layouts folder. This will avoid duplicate scripts all over the farm uploaded by various users and also jQuery in _layouts folder can be cached and loaded faster than one in a document library which in turn is loaded from the database.

Cheers.