SharePoint Designer: Useful Tool or Spawn of the Devil?

OK, so you know how I’m going to come down on this, but I got your attention, right? In fact, at almost every large client I work with, the latter seems to be the opinion.  The rules are usually: No SharePoint Designer use in staging and production.  Period.

This stems from a fundamental lack of understanding of what SharePoint Designer is and what it allows you to do.  It’s unfortunate, because as the middle tier option to development in SharePoint, it facilitates the development of everything from page layouts to full-fledged applications with custom forms, navigation, and reporting.

A little history is probably useful here. SharePoint Designer is indeed FrontPage all grown up.  When Microsoft released SharePoint Designer, it was the newest version of FrontPage and a part of the Office 2007 suite of productivity tools.  At the same time (or very recently afterward), Microsoft forked FrontPage into Expression.  Initially SharePoint Designer and Expression looked like they were identical products, but Expression didn’t have support for SharePoint and it was targeted at designers more than developers.  (It has since been enhanced to be even more valuable in that space.)

So the fact that SharePoint Designer comes from FrontPage is probably a part of the prejudice. It was certainly true that letting a random user loose on older server platforms could cause utter havoc for the IT folks.  Those platforms usually didn’t have the permissions layers that SharePoint provides, however, and FrontPage was probably too liberally given out.  Enter the guard rail mentality. (I just hit the right one, let me pull hard left and — oops, I just hit the left one, so let me pull hard right, and…  You get the idea.)  FrontPage was bad, so SharePoint Designer, as its older sibling, must be even worse.

Another contributing fact to this whole picture is the experiences with SharePoint 2003 (or even earlier versions like 2001, Tahoe, TPU, etc.)..  In SharePoint 2003, there were serious issues with pages becoming "unghosted" and being "moved into the database".  This *sometimes* caused performance issues.  If you edited a page in FrontPage, it became unghosted.  Again, not in itself a bad thing, but FrontPage was the "cause".  This is no longer the case with SharePoint 2007.  While pages can be customized away from the site definition, there is not performance hit and they can be reverted back to the site definition easily if needed.

So what’s the case for using SharePoint Designer on SharePoint 2007 (whether it be MOSS or WSS)?  Well, you can do a heck of a lot without a "real" developer with faster turnaround cycles.  Here are some examples:

• Customizing the master page and CSS — The master page drives the overall structure of a site’s pages. (It can be used at a single site level or at the Site Collection level.  Your choice.)  The master page is simply an HTML structure with a lot of SharePoint controls embedded in it.  The default master page is what exposes the tabbed navigation the welcome message, the search bar, etc. in the default site.  Because we’re in the 21st century, it, like most things, is all text.  (You can edit it with Notepad.)  However, SharePoint Designer "understands" all of the controls and gives you contextual menus and help to configure them.
• Creating layout pages — Page layouts define the structure of pages that are set to use them.  Wait, this sounds like the master page, but it isn’t.  Page layouts inherit the master page and then can provide additional internal structure and Web Parts.  (If there’s even a chance that you will use variations, get in the habit of using page layouts — you’ll need them.)
• Adding Data View Web Parts to pages — Data View Web Parts (DVWPs or Data Form Web Parts) are, as I’ve said many times, the Swiss Army Knife of Web Parts.  They give you total freedom over how you display content and can connect to many types of Data Sources.  You can (though you wouldn’t want to) edit the XSL for DVWPs through the UI, but again, SharePoint Designer is fully DVWP and XSL aware, so you really want to use it.  You can only add DVWPs to pages using SharePoint Designer.
• Workflows — There’s a middle tier of workflow development (between the UI and Visual Studio) where I would argue you can do 80% of what you’ll need.  And SharePoint Designer is the tool that you need to do it.  There is a nice If-Then-Else editor in SharePoint Designer that lets you do this very well.

Now all of these things (except workflows — they are in a class by themselves in many ways) can be edited through the UI if you are a Site Collection Administrator.  You simply navigate to the containing location (Master Page Gallery, Pages folder, or whatever), download the file to your hard drive, open it in Notepad, and edit away.  You can then upload the file, check it in, and approve it (where required) and you have a new version in place.  Odds are very good that it won’t work because there’s far too much room for error, but you’ve just edited a file without using SharePoint Designer.  If you are a masochist, maybe this is the way to go for you.

Keep in mind that in SharePoint, EVERYTHING — let me repeat — EVERYTHING is security trimmed.  If you don’t have permission to access something through the UI, you won’t be able to access it through SharePoint Designer, either.  So you can’t just open the root site and delete everything.  If you are a Site Collection Administrator, you have the choice to be this destructive through the UI or through SharePoint Designer, but the average user can’t even open anything if they have SharePoint Designer.

So what does prohibiting SharePoint Designer protect?  Not much, really.  A malicious user with permissions can wreak havoc.  An untrained user with permissions can wreak havoc.  And both of these statements are true without SharePoint Designer.  With SharePoint Designer and a bit of training, your users (and I wouldn’t suggest that you need more than a few people with SharePoint Designer and the permissions to use it) can build wonderful functionality.  They can’t touch anything on the server.  Nothing in the file system.  No server settings.

When you add these things up, does SharePoint Designer sound like a useful tool or the spawn of the devil?