SharePoint Designer: Use With Caution
Overall Satisfaction with SharePoint Designer
Our company uses SharePoint Designer for ad-hoc customizations to its SharePoint 2010 intranet. My team, which is the web development team, is the only group allowed to use Designer in the production environment. Anybody who requests it can use it in the test environment. We have a deployment tool that facilitates deployment of sites from test to production.
- Designer is great for creating and applying custom master pages to sites. A custom master can be created anywhere, uploaded to a site, and applied to individual pages (rather than to an entire site).
- Designer is also really easy to use when I need to apply conditional formatting to a list, such as color-coding items needing attention.
- If you're not afraid of XSL, Designer is also a decent environment for customizing a page's layout by altering XSL templates.
- I also use Designer for building quick one-off workflows. The workflow building interface is easy to use and very powerful - much easier than getting into Visual Studio workflow and then deploying it.
- Most people don't choose whether or not to use SharePoint Designer - we are somewhat of a captive user group. If you want to customize SharePoint pages without building custom solutions every time, then Designer is your only option.
- Designer can be unstable. There is not a lot of room for error in playing around with the XSL it creates -- errors will often cause the application to crash. The code view is not particularly good at dealing with XSL either -- it doesn't group by tag, and XSL error messages are not informative. I have taught myself to look closely at the line numbering -- If I make a change to XSL, refresh the Design view, and get a vague XSL error message, having a line number reference to my last change saves me a lot of hunting, because Designer will not tell you where the error is.
- Designer has a variety of bugs, some more annoying than others. For instance, it gives you the ability to create a data source from SharePoint's web services (very handy for referencing data in a separate site collection), but the data source seems unable to use Windows authentication, and I am forced to hard-code an account name and password. Certainly not ideal.
- Positive impact: End users love the custom look of their sites after I have used Designer to spice it up a bit.
- Negative impact: Other end users now want *their* sites to be spiced up similarly. More work for my team is a good thing, but each time I work in Designer, I am afraid that I am adding another impediment to our eventual upgrade to 2013.
As I said before, I didn't select SharePoint Designer per se, but I did (and will continue to) elect to sometimes use Designer rather than create deployable solutions in Visual Studio.
Designer could be called the lazy person's tool for modifying SharePoint. Solutions created in Designer are not replicable, and possibly not upgradeable. Designer deploys directly into our production environment, so it could be a real issue trying to modify currently live sites.
So, I continue to use Designer in 2010, and will no doubt continue to use it when we move to 2013. But I will also continue to heavily restrict its use in the production environment.
Designer 2010 is a huge improvement over Designer 2007. I'm just now installing Designer 2013 for my next upgrade environment, and I hope it is similarly improved. Given that there aren't any easy alternatives to Designer, it is worth putting up with its idiosyncrasies in order to get quick results for my end users.
But it is a powerful tool, so I will not make it available to the various power users who have requested access to it in production. We can restrict what site(s) Designer users can change, but within those sites, everything becomes up for grabs. Since my company wants to (a) maintain consistent user interfaces, and (b) restrict the number of unghosted pages overall (for performance reasons), we opt to let users from outside my team create their designs/customizations/workflows in the test environment, then we vet them before moving them to production.