I just finished reading a write up of a SharePoint Designer Good Bad Ugly as “SharePoint Designer a definite Maybe” by Mark Rackley.  I think he makes some good points early in the document, but many of the conclusions which come across biased to structured deployments I don’t agree with as they relate to composite commodity and collaboration environments.  Some of the statements especially his conclusions are just too wide sweeping and come across as scare tactics.  Don’t let this come across as higher ground… I make the same mistake some times in my attempts to keep people from deploying custom site definitions due to their impact at upgrade, but that’s a different discussion.  Often it takes a good post to get the community stirred up to flush out the details…  I applaud Mark on making a stand.  Let me break down where I disagree with Mark’s conclusions. (Mark’s Conclusion Arguments as originally written are outlined in quotes below)

Argument 1: “Keep SharePoint Designer FAR away from your Production Servers”

SharePoint Designer can really be used in two what I’ll call “editing modes” 1) remote with portability (which supports dev, test, prod) and 2) In Place

1) Design your masterpage and your web parts to work with portability.  Design your themes, skins (ask Heather Waterman what a skin is), layouts, styles, CSS, Masterpages, and other CMS assets and then export and upload to the master page gallery and various galleries (MOSS only).  You might consider starting with the minimal masterpage.  With WSS 3.0 the only way to apply a master page without custom solution is with SharePoint Designer.  Hence if you want style applied in a quick way beyond the out of the box themes, you’ll turn to SharePoint designer.

For web parts you would simply design your web part and it’s connections for example using the dataview or dataform web part which essentially are not accessible in IE.  Complexity goes way up to try to do the same thing with Visual Studio.  You can connect to databases, web services, XML, RSS, and on and on.  The filtering, conditional formatting, and rich forms, otherwise extremely complicated to write yourself are extremely intuitive.  Once you like the way it looks you simply use the web UI to export the .DWP file which is a self contained web part file. 

2) In place editing and design has a place.  Let’s start with MOST SharePoint Deployments are collaboration environments.  These commodity applications run primarily out of the box and the business requr Consider the composite applications designed by the power users in the business.  Without designer, the development team becomes the bottleneck.  I’m not suggesting that SharePoint designer be installed on every desktop by any means, but it is important to understand the positive impact that Designer can have on building rapid applications.  While I wouldn’t encourage people to have free reign, I do see a place for designer in most deployments.

Understanding the out of the box webparts is extremely important to understand how the tools fit.

Content Editor web part – drop in essentially any client side code including javascript and flash includes to make magic happen.  Looking at Jquery you’d think there was nothing you couldn’t do with the content editor web part.

Content Query Web part – amazing when you see how powerful this webpart can be in pulling in list data from across the site collection all right through the browser!

Dataview/form webpart – The Swiss army knife of webparts which are NOT accessible via the browser alone.  With Designer this webpart can pull in data from various datasources and make your site become an application.  Not only integrate with your lists and integrate workflows, but much much more.  Take the Dustin Miller 3 hour tour, or listen and watch any of his building composite applications or dataview sessions.  In an hour he’ll blow your mind.  He does make Designer sing.  Not just Dustin, but Asif, WoodyW, and a ton of other people and who in your company can you turn into a SharePoint Designer super star?  It’s not just what you can do, it’s how much time you can save building applications in a commodity environment without having to add server assemblies, that’s the real key to winning over the server admins.

Given the tradeoff of server assemblies or someone using designer to create a dataview or create a workflow, almost all would choose the educated trusted power user with SharePoint Designer.

The argument about the impact of Unghosting is legacy and performance impact is unvalidated

Forget about the page being unghosted.  The page isn’t unghosted unless you actually edit the page itself.  In WSS 2.0 this wasn’t the case, but now only the particular items that are edited are customized or unghosted.  It’s important to understand when you edit an object whether a web part, a layout, or CSS.  It does store that in the content database.  If you avoid editing the page itself, you’ll find that the editing concepts work best when applied with a masterpage and no page unghosting is necessary at all.  The DWP file or webparts would get added into the content database no matter what tool you use to create them.

I challenge someone to actually do the performance test.  In my tests even in WSS 2.0 I found that unghosted pages were FASTER, than their ghosted untouched counterparts.  Why?  If you look at the query it was checking the database first then hitting the page on disk.  So comparing the two the unghosted one was a few milliseconds faster on a GET.  Upgrade in my mind is the reason not to touch the pages, so don’t touch the pages.  Use Masterpages, and use designer to work with workflows and webparts and we don’t even have to talk about ughosted pages.  The reset to site definition feature was introduced during the upgrade and remains available.  Let me reiterate, I recommend keeping the pages inheriting from the site definition.

Argument 2: “Don’t give your end users access to SharePoint Designer ESPECIALLY if you have multiple Web Front Ends”

SharePoint stores the files in a common content database.  This statement is unfounded.  There’s really no difference between 5 WFEs and 1 WFE as far as editing is concerned.  I do recommend sticky sessions, but despite the number of web front ends, the data is still stored in one content database, and any webparts, workflows, etc.. are only ran and processed from a single box at a time.

Argument 3: “Unless you truly understand SharePoint Designer and what it’s doing under the covers, DON’T TOUCH IT.”

This type of scare tactic may be efficient to an end user that hasn’t had the necessary training, but Designer has a legacy bad rap that has carried over.  Much of which today is unfounded and for which training and workarounds address most of the issues.  It is a powerful tool, I do highly recommend training and sandbox usage.  Touch it as much as you can in a non production sandbox site, that may actually even be sitting on the production environment, just not your production portal.  Collaboration and Project sites are the ideal place to train your power users and designers on the effective use of SharePoint Designer. 

Argument 4: “If you are aware of it’s limitations and keep them in mind, it is a wonderful tool.”

Too little too late.  You already lost your audience.  Some good points in the article, but it comes across as scare tactics rather than stating some workarounds and facts.

Conclusion:

1. Don’t deploy SharePoint on every desktop.  You should still work with a group of designers, and power users which create masterpages, CSS, dataviews/dataforms, and limited simple workflows.

2. Most of the assets around design can be created remotely to allow staged deployment.  Don’t worry about the impact of unghosting to performance when using Designer to create workflows, webparts, masterpages, etc….  even pages don’t create a measurable impact to performance, but I recommend  NOT editing the pages themselves with Designer (in most environments where you’d be concerned).  That design for the WCM site can still be designed with Designer and achieve portability!  It isn’t only an inplace tool.

3. Education/Training plus policies is the key.  You can decide who can do what.  Create a sandbox and help your power users get educated.  Not every user needs or has to know.  It is handy even for your trusted site administrators to learn how to use designer.  It’s the ONLY way to add a master page to WSS without deploying code, and the ONLY way to create dataviews and dataforms without code. While I hate to say Governance will solve this (alone it won’t)  problem for you, essentially setting out policies and roles and responsibilities along with enforcement, you’ll be much better off than using scare tactics.  People need to understand what is ok, and what’s not ok.

4. It is faster to create an RAD application with SharePoint Designer than it is with Visual Studio.  It’s not always the right answer to jump from the browser based solutions to visual studio.  Maybe that is the right answer with your WCM or .COM environment, but those one off little apps that with a tweak here or there…. Designer goes a long way to help biz dev scale. 

5. Create a Sandbox (demo/test UAT for trusted power users) for collaboration environments – if you don’t want people to do anything until they know what they’re doing, you need a sandbox.  You need an environment where people can learn, and they can see what happens if… What’s the worst that could happen?  Well, lets run that in the demo environment and see.

Totally ok with blocking access to SharePoint Designer (from SPD team blog) until you figure out your composite application plan around this… Few moving parts in the beginning is essential to understand what’s in the box.  SharePoint is a lights on experience!  Don’t forget you have backup/restore.  Do you have a quick way to restore a site or site collection?  Figure that out before turning on SPD or even Site Collection Admin access to ANYONE. 

<update!>

SharePoint Designer is now Free check it out in a Sandbox!

Q&A on License Change

</update>

@ferringer just produced a custom site def on codeplex.com that blocks SPD.  I don’t know what I think.  Not too excited about this being a site def.  Would much prefer a solution, but at least there’s now an effort underway to simplify a farm wide change to manage access by SPD.  I imagine in the future a solution or a web app policy that would allow you to manage the group that has access to the various SPD features at a more granular layer across the web app, then opts in at the site layer.