SharePoint Designer (SPD) is a nifty tool to use to customize SharePoint sites. It is very powerful and allows us to quickly make style, organizational, functional, and content changes quickly and easily. Today, I ran across a post from Joel Oleseon where he shared his professional opinion in response to another post about the tool from Mark Rackley which was motivated in response to Microsoft’s announcement to make the tool available for free. There really is nothing new about the debate as it deals with the advantages and disadvantages of empowering an end user with all of the power the tool has to offer. It has just resurfaced since the tool will be freely available.
So… if the debate is not new, what’s all the fuss about?
Regardless of the stance that you take about allowing SPD to be used in a production SharePoint deployment or not, the real cause of concern is how SPD can impact production environment when used by untrained/uninformed users with appropriate rights. This reminds me of the quote – with great power comes great responsibility… or something like that. I don’t see the need for huge concern. That is assuming people with those rights have already been trained and informed. For the most part, people with contributor or higher permission role assignments can already do plenty of damage to a production environment with only the web browser at hand. Hence, the need and argument for appropriate training, content approval (and publishing) planning and enforcement, and governance plans (especially in Extranet/Internet facing deployments).
Okay… so what should we do?
There shouldn’t be too much to do (assuming training, content approval, governance, etc. has already been addressed). Professionally, I will be making sure to emphasize the role of SPD in SharePoint projects. I will also make sure to encourage the inclusion or addition of SPD training for existing and new SharePoint users (especially “power” users), administrators, and developers.