To SPD or not to SPD, that is the Question
SharePoint Designer (SPD) has been free from Microsoft since April. In those two months, some lines have been drawn in the sand. Some users are of the opinion that it should be completely locked down and not allowed in the organization. Others have the view that it makes everything better. Still others aren’t even sure what value it could possibly bring. It is free, so you get what you pay for, right? Not always!
SharePoint Designer is one child of FrontPage. Remember FrontPage? The same functions that were in FrontPage are available in SPD, along with some more functionality specific to SharePoint. Yes, you can use SPD to make SharePoint look, well, not like SharePoint, but you can also do so much more!
Using SPD, you can create Data View Web Parts (DVWP). This in and of itself doesn’t seem like much, but once you learn what a DVWP can do, you have a powerful resource at your finger tips. DVWPs can expose data in different ways than SharePoint lists and libraries. You can use a DVWP to expose not only data within SharePoint, but also external data from databases, files, web services, the Business Data Catalog and other sources. For more information on the DVWP, Laura Rogers has an ongoing series that can be viewed here.
You can also use SPD to create web forms and custom solutions using the FrontPage functions that still reside in the application. You can create HTML and ASP.NET forms, using the drag and drop tools from the task panes. You also have the ability to customize the forms used in SharePoint for lists and libraries.
Workflows in SharePoint 2007 are great, but limited. SPD gives these workflows more flexibility and allow you to build custom workflows related to specific lists and libraries within a site. While these workflows are somewhat limited in that they are not easily moved or replicated, these workflows do provide a great deal more functionality than the out of the box workflows. There has also been some excellent work done on taking these workflows and moving them into Visual Studio.
Some Administration is also possible with SPD. Reporting is one of the better features of SPD. While you can configure and view usage reporting within SharePoint, SPD gives a greater detail. There is also the ability to build your own custom reports and export these reports for your use. Some of the administrative functions provided are beneficial as well as controversial. You have the ability to backup and restore data, save templates, and create and delete sites using SPD. These functions are often what cause administrators to choose not to allow its use. An inexperienced user can easily delete sites, lists, libraries, and other content causing panic and administrator frustration.
While every organization is different, there are many things to consider when it comes to SharePoint Designer. The tools are very powerful, and some policies should be put into place before rolling it out to an organization. First, consider who should be using it. Power users: should they receive SPD in order to create their own workflows and content? Should it be locked down to only Site Collection Owners? Or should it be restricted only to IT professionals? Another important consideration is how to provide guidance and training on using the tool? Will you allow only those who have been properly trained to use the tool? What about those power users, again? Once they start using it and playing with it, will they want to teach their co-workers how to use it? Who will monitor this training?
If your organization decides to allow the use of SharePoint Designer, these policies should be clearly defined and easily enforced. There are ways to ensure that the use of SPD is restricted. One way is group policy, you can place restrictions on the users to prevent or allow SPD. Another way is restricting the use through SharePoint. The SharePoint Administrator has the tools to allow or restrict the use of SPD; even the Site Collection owner has the ability to restrict its use. No matter what decision is made, be flexible. As SharePoint grows within your organization, you may see a greater need for SPD or even a need to restrict it further.
Guest Author: Lori Gowin, See the Point
Lori Gowin is a SharePoint Administrator/Designer. Since 1999, she has been supporting and managing Microsoft products and technologies. The last four years have been focused on SharePoint and the Microsoft Office Professional Suite. She has created InfoPath and SharePoint solutions in both the healthcare and education industries. In June of 2006, Lori received her MCSE.
Lori lives in Birmingham, Alabama with her husband and two sons. When not working with SharePoint, she enjoys reading, travelling, and watching sports.
Hi Lori,
nice article and I agree with what you wrote. There are some negative points of SPD as well, why didn’t you mention some of those? Like its performance, it is very slow to work with. And I hate it when SPD adds content to my code, or rewrites my code (like adding in front of my tags for example). So annoying.. I still use it, but keep waiting for a new release which fixed those ‘features’.
I wrote: Like adding a non-breakable space ( & nbsp ; ) in front of my H1 tags.
Very interesting read Lori, and I do agree that SPD should be locked down in your environment.