SharePoint Designer 2010 as part of a ALM process

SharePoint Designer, and its predecessor FrontPage, has been much maligned by professional developers. Forced to step outside their comfort zone (Visual Studio), they resent the fact that they have to use a tool which is clearly targeted to Power Users, and not professional developers. Aside from various stability issues and missing functionality in previous versions, SharePoint Designer doesn’t even play lip service to the idea that you may not think it is a good idea to develop directly onto production systems. You might say that the tool’s designers completely missed that use case.

SharePoint Designer 2010 does go some way to fixing this. By changing the focus of the product to be more of a management tool, and providing high quality tools embedded within Visual Studio, developers will find that they will not need to use SPD much for development. Despite this, I still see a number of key scenarios where SPD will be used:

  1. As a Proof of Concept / Rapid Application Development tool. SPD has always been good at this scenario, but SPD 2010 is even better. The ability to create and manipulate content types, lists (including external lists) and other SharePoint assets in the same tool is fantastic for developer productivity. It is a huge step forward, and this will be a key mechanism to hit the ground running.
  2. To use the wizards and tools to build custom XSLT. SPD has some fantastic tooling for this, and if you lack the will to get your hands dirty playing with raw XSLT, SPD provides some killer productivity improvements. These tools are not available in Visual Studio.
  3. As a workflow creation tool. SPD 2007 had some key weaknesses for developing workflows, not least a lack of reusability once you had built your workflow. SPD 2010 solves this by introducing reusable workflows, and the ability to save workflows out as WSPs.
  4. As a way of increasing end user self-service. A tricky one this; giving end users the ability to mess up your deployment gave us issues when it came to governance and management. I’ve seen instances where there were 15,000+ customized web part pages in a single SharePoint site collection. Thankfully, 2010 brings us new ways of controlling this – and the best one is the ability to lock it down so that the end users can make use of the features of SPD where they need, but cannot, for example, go into the Advanced Edit screens. This increased granularity of control will make it more likely that SPD will be allowed to be used on production environments.

There are still some issues, though. The integration between SPD and Visual Studio is weak, and once you have moved from your SPD world into VS, there isn’t a clean way to move back into SPD. Furthermore, there is no integration with source control systems or continuous integration systems in SPD, so at some point on a professional project you should end up moving fully into Visual Studio.

Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: