There are some tools I don’t hand my son. He’s five and frankly there are reasons why I don’t want him working with chain saws.

I occasionally need a chain saw to cut down a tree or cut up a fallen limb. But it’s not a tool I’d ask him to use.

I feel the same way about SharePoint Designer (SPD) — in the hands of some and in the right circumstances it can be a powerful tool capable of saving organizations money.

However, in the hands of others, it can be a disruptive influence that makes it harder for organizations to have a well governed and used system.

In this article we’ll walk through a high-level summary of SPD’s features and how these features should and should not be used.

At the end of this article you should be able to identify those situations where SPD can be helpful and identify situations where using SPD may be more of a hindrance than a help.

HTML Design

Perhaps the most obvious feature of SPD is seen from the perspective of its Front Page heritage. Even the product’s predecessors were HTML designers.

They were designed to make the process of editing HTML more usable for the masses. Over the years the tools have “grown up” to include professional-quality editing support.

While there are competing products in the HTML editing space, SPD (and its sibling, Expression Web) has a solid set of tools for editing HTML.

Within the context of SharePoint how does this help? SharePoint is built on top of the ASP.NET 2.0 framework and includes both a maser pages and web form pages.

Master pages provide a way to develop a consistent look and feel across the site. The individual web pages allow for different layouts and structures to support the needs of the content.

SPD is a capable editor of both of these two core file types in SharePoint.

When you’re using Microsoft Office SharePoint Server (MOSS) there’s a terminology change to be aware of. MOSS includes a feature called web content management (WCM).

In this feature, there are page layouts to consider. These page layouts are the templates that content is put in.

They are — in essence — the same web form pages that you might edit directly. The key difference is that they contain content placeholders into which content will be inserted by the WCM subsystem.

So pages in Windows SharePoint Services (WSS) — and non WCM MOSS sites — are essentially the same as Page Layouts for WCM.

In addition to HTML editing, web site design today is controlled by cascading style sheets (CSS). SPD is a good editor of CSS sheets as well.

In the SharePoint world CSS is very important because much of what is displayed is styled with CSS sheets.

A great deal of customization of the look and feel can be done without ever editing a master page or a page itself.

From the perspective of working with SharePoint, SPD’s key feature is probably its direct integration with SharePoint.

It understands the APIs and what to do in order to get pages and content and how to return them safely to SharePoint. In this integration, there are, however, some hidden concerns.

Ghosting, Unghosting, Customized, And Uncustomized

SharePoint works more than a little bit of magic in order to provide users with an easily customizable platform to do work.

It leverages both files on the file system and data in a database to virtually create many sites most of which share the same files on the file system.

The net effect is that SharePoint gives the appearance that it’s many files when in reality it’s a relatively small number.

This is accomplished by a technique that used to be called Ghosting. SharePoint contains database entries for each site and each page in the site.

By default these entries refer back to a file on the file system. The result of this is that there’s good performance and the ability to impact changes on a massive scale just by changing one file.

Since every site refers back to that one set of files making a change there has a global impact.

When a change is made with SPD, it cannot make a change directly to the file system. Instead it instructs SharePoint to maintain a copy of the file in the database.

This process used to be called unghosting but in SharePoint 3.0 the preferred term is customized. Ghosted would be referred to as uncustomized.

The impact of this is that pages edited with SPD are specific to the site or site collection that is being used and therefore won’t take effect over the other sites that might be based off of the same files on the file system. In short, if you want to make a system wide change to the look and feel — you won’t be able to.

Said more succinctly, using SPD to edit pages may lead to inconsistency issues since the changes that are made in SPD don’t always take effect everywhere.

Site Collections and Sites

Some of you may be aware that there is a distinction within SharePoint between a regular site, what a developer is more apt to call SPWeb, and a site collection, what a developer is apt to call SPSite.

The difference is that a site collection is a boundry object. It defines boundaries for different APIs and for storage as well.

A site collection may only be stored in one content database. A site collection is the boundary for many APIs — for instance, quotas, content querying, etc.

This is important when speaking about the impact of customizing pages because the impact of customizing pages can be observed at either the site collection or site level.

In the case of a WSS site or a MOSS site without the WCM functionality turned on the changes that you make to a web form page or master page are seen within that site.

In the case of a WCM enabled MOSS site the changes are seen across the site collection — but no further.

This is because WCM references master pages and page layouts from the root web of a site collection, rather than from the current web.

This helps to ensure consistency and can be a great help when making changes with SharePoint designer.

The net effect is that if you have a WCM enabled web site with a single site collection in your environment — which is possible for some WCM enabled sites designed to interact with the outside world, you may not be able to see an effective difference between having customized pages in SharePoint and having customized the pages on the file system.

Note: You would want more than one site collection in order to break apart the content databases into reasonable sized recovery chunks.

Right now the guidance is ideally for 50 GB or smaller content databases. Since a site collection must exist solely in a single content database that means that when you get 50GB or more of content you’ll need to split the site collection.

Having Your Cake And Eating It Too

It may be that you don’t have one site collection or you’re not using the WCM functionality in MOSS — but you still want to use SPD to do your editing because it is a good editing tool.

There is a way to fit the pieces together to get the benefit of SPD without losing the global nature of changes to the files on the file system.

The answer is to use SPD to do your editing but instead of doing a save back to the site, do a save as to the file system somewhere and then move this file into the correct location on the server.

Even if you decide to (or accidentally) save files back to the server, you can right click on the file and revert the file to the state that it’s in on the file system — after you make a backup of course.

This provides solid flexibility to test your changes out in a safe playground area before trying to apply them to all pages.

Workflows

Up until this point in the article we’ve been focused on web editing. That’s certainly the feature that comes to mind most quickly when people think of SPD but it’s not — by far — all that SPD can do.

One of the other important features in SPD is the ability to create workflows. While configuring the out of the box workflows is easier than even developing a workflow with SPD, building SPD workflows is more flexible than the OOB workflows.

However, the ease of use that comes with the ability for SPD to create workflows comes with a cost.

The SPD developed workflows are not able to be transferred from one list to another. They are created with internal GUID identifiers for lists which make them difficult to move.

So while developing workflows with SPD is good for prototyping and one-off scenarios, it doesn’t work for a workflow that you need to use over and over again.

Advanced Data Queries

The DataViewWebPart — which can only be created through SharePoint designer is a great tool for integrating and displaying non-SharePoint data on a SharePoint site with minimal effort.

Often times it’s the only way to get the results you need without writing code. In fact, this feature alone — a design surface for creating data view web parts — often can justify using SPD.

The downside, which is relatively minor, is that pages tend to get customized while developing the DataViewWebPart.

The solution is to develop the web part on a scratch page, export it, import it on to the page you want it on and delete the page you created it on.

The result is a data view web part with what you want — without the mess of having customized a page.

Summary

Of course, SPD has many other features which haven’t been covered here. The Microsoft Office site for SPD allows you to explore the complete list of features.

The point here is that SPD has a great set of tools if you’re willing to accept their limitations. You should feel very comfortable unleashing SPD for your pilot — it’s a great tool for rapid prototyping.

You should feel less comfortable if you’re designing the corporate intranet and you need the entire site to have the same look and feel.

But by using techniques to minimize the amount of customized pages that are being created, and accepting the limitations, SPD can be a welcome addition to your toolkit.