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.
I jump into SharePoint Designer whenever a one-off customization to an intranet site is requested, such as adding conditional formatting to a list view, or making visual adjustments to a form. I also use it for creating workflows, adding Javascript to a page, or creating custom CSS for a specific site.
- 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.
On the other hand, Visual Studio is only installed in our test environment, and the solutions it creates must be deployed to production. Deploying a solution from test to a live production site that already has data can be tricky. Designer can be used to modify an existing site in production. Similarly, using Visual Studio just to create custom CSS or JavaScript, like I often do with Designer, would be overkill.
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.