SharePoint Designer – A definite Maybe

Originally posted on: http://geekswithblogs.net/SoYouKnow/archive/2009/03/29/sharepoint-designer-ndash-a-definite-maybe.aspx

Good news!  Starting April 1st SharePoint Designer will be free!

Bad news! Starting April 1st SharePoint Designer will be free!

I have a love / hate relationship with SharePoint Designer, but I have always been quick to defend it to those developers out there who think it is Satan’s offspring.  Although I’m sure some of Dark Lord’s minions had their hand in designing some of SharePoint’s quirks, I’m fairly certain SharePoint Designer is not quite that evil.  It does however attempt to spread mayhem. 

I had some great conversations at SharePoint Saturday in Tulsa with Eric Shupps, Steve Walker, and Becky Isserman who helped me understand some of the more not-so-obvious SharePoint Designer limitations that everyone should be aware of, especially now that it is going to be free to the world. 

The more I learn about SharePoint Designer the more I firmly believe that it DOES have a great role to play in SharePoint Development, but it is so important that you don’t give just anyone site owner access and free reign with SPD.  I’d also highly recommend that one of the things you discuss in your Governance committees (which you do have, don’t you???) is what role SPD plays in your organization and who should have access.  

Okay.. okay.. so, apparently some parts of my original post were a little overly dramatic, but seriously SharePoint Admins, when someone comes to you and asks for site owner access and SharePoint Designer be completely aware of the ramifications. Okay?

The Good

SharePoint Designer does have some great qualities that at first glance get you really excited about using it.  I could make some analogy here likening SharePoint Designer to an attractive girl you meet at a bar and before you know it you wake up in a bathtub full of ice missing a kidney, but I’ll refrain.  So, what’s good about it?

Don’t have to develop on a the server

Probably the most awesome thing about SharePoint Designer is that you don’t have to develop on the freaking server!  This is phenomenal for those developers who have to get SOMETHING done and they don’t have access to the necessary development tools.  This was my ONLY option for development for the first 6 months that we were using and learning about SharePoint.  You do however need to be a site owner on the site in question.

Modifying ASPX files, Master Pages, and CSS

SharePoint Designer is great for modifying and maintaining your ASPX pages, Master Pages, and Cascading Style Sheets.  It especially is useful in browsing through and learning SharePoint’s massive CSS files.  SharePoint Designer has a pretty good WYSIWYG editor (What You See Is What You Get) as well which can really help when designing and creating themes. 

Prototyping

SharePoint Designer is great for throwing together a quick Prototype on your development servers and getting it in front of people to build some excitement about SharePoint and show what SharePoint is capable of.

SharePoint Designer Workflows

The second best thing about SharePoint Designer are the SharePoint Designer Workflows. SharePoint Designer comes with quite a few workflows that can be connected to a SharePoint List and can be set up to be executed manually, when an item is created, or when an item is changed.  Some of things you can easily do with these workflows are:

  • Send emails, including emails to individuals who created a list item or executed the workflow
  • Do simple business calculations and store those values in your lists
  • Create lists
  • Update lists

The Bad

SharePoint Designer Workflows

Yes, they are great, but they are limited.  One of the biggest limitations of SharePoint Designer Workflows is when you want to update multiple list entries based upon a matching field value.  You must write a custom workflow to do this. 

Another bad thing about SharePoint Designer workflows is that they have a tendency to break when you restore a backup or publish them to a separate site.

Maintenance

Wow, this is pretty bad.  If you want to modify a SharePoint Designer Workflow for an application in production you have a couple of options:

  • Make changes in production (NEVER DEVELOP IN PRODUCTION!)
  • Backup your production application and restore it on a development farm, make your changes and then redeploy in production (This may sound great, BUT when you backup the application it carries all your list data with it!  So, while you are making changes in development, users are still using the application in production meaning all of their changes will be lost when you re-deploy the application with your changes.)

The Ugly

Breaking List Views

You have to very careful about what you are doing in SharePoint Designer or you can break your site.  We learned this the hard way when we deleted the default web part on one of our list display forms (DispForm.aspx).  We didn’t want to use the default web part, we wanted to hide some of the fields.  Well, apparently when you delete the default web part it BREAKS the display view for your list AND YOU CAN’T GET IT BACK!  We had to delete the entire list and re-create all of our work.  We did this three times before we figured out what we were doing wrong.  DON’T DELETE THE DEFAULT WEB PARTS ON THE DEFAULT LIST PAGES!

Disabling IIS compression

Maybe you knew this?  I just found out from the guru (and future drinking buddy?) Eric Shupps yesterday that when you modify a page in SharePoint Designer it ‘customizes’ the page and stores the entire page contents in your content database thus turning off IIS compression for that page!  This may not be a big deal if you have a small farm with little traffic, but this can cause performance issues for larger farms.

Multiple Web Front End (WFE) Issues

As I said before, editing a page in SharePoint Designer customizes it.  The moment you make a change to a page in SharePoint Designer that page is now entirely stored in your Content Database.  “So what” You may think. So what?  Well… if you have multiple web front ends you must make sure to update the same page on EVERY web front end.  Still not a big deal?  If those pages were originally set up as part of a feature, they will no longer be updated when the feature is updated.  SharePoint will continue to use the copy stored in the Content Database.   If you still think this is not a big deal then it has to be because you only have one Web Front End and will only ever have one Web Front End and you aren’t deploying your site definitions/master pages/themes as features (shame on you!).

<UPDATE>

Woody Windischman talked to me this morning and set me straight on the multiple WFE issue.  I didn’t remove the original content completely because this is apparently a very common misconception.  So, when you hear people talking about it I want you to know what they mean.  So, here’s the update.

When you save a page in SharePoint Designer it DOES customize it and save it in the Content Database.  HOWEVER according to Woody it is absolutely not true that you would have to go to all your WFE’s and make the same changes.  When SharePoint goes to serve this page it hits the content database and sees that it is a customized page and serves that page, no matter which WFE you hit.  SharePoint always goes to the Content Database first, even if the page is NOT customized.  So, the whole multiple WFE issue is a myth.  There is apparently even some debate that customizing a page can be more efficient because you don’t have to make an extra trip to the WFE to get the un-customized page.  NOT trying start a fight here, just presenting all sides.  🙂

It is true however that if a page was part of a feature and you modify it in SPD any modifications to that feature will not be reflected in that page.  Something important to keep in mind when modifying pages.

Another point that Woody brought up is that there are potential conversion issues if you use custom Site Definitions and you try to convert when SharePoint 14 comes out.  Just trying to keep you guys informed.

</UPDATE>

So, When the Heck Do You Use SharePoint Designer?

Okay, so after reading all of this you may wonder when is best to use SharePoint Designer?  I mean, with those limitations should I just avoid it all together?  No, you should not.  As John down there it my comments does a good job pointing out, it IS an essential tool to the developers toolkit. So, here is where I see SharePoint Designer having the greatest impact for an organization.

Learning About SharePoint

SharePoint Designer is great to help you learn about SharePoint Lists, Workflows, Web Services, etc.  It’s also invaluable in helping you understand SharePoint site structures.

Sometimes you don’t have a choice

When we first started developing in SharePoint we were not given access to resources to develop on the server or set up a VM.  We had applications to create and deadlines to meet.  Our only option for development was SharePoint Designer, and it saved our butts.

Design and Development

SharePoint Designer is great for developing your Master Pages, Style Sheets, and ASPX pages.  HOWEVER, copy these files to your feature solutions in Visual Studio, don’t publish your SharePoint Designer pages to your SharePoint Farms.

Prototyping

If you need to throw together a prototype and get a PROTOTYPE in front of someone quickly, SharePoint Designer is a great tool.

Non-Developers may need to Develop (I’m sorry if this is the case for you)

If your organization has SharePoint maintenance and development to do but no real SharePoint Developers then SharePoint Designer is a great tool for those people as well.  Just please get them properly trained, and please don’t throw insults at me for saying people who use SharePoint Designer are not “real developers”.  That’s not what I mean (although you’re not…  kidding! )

What’s the Bottom Line?

I really think you should keep SharePoint Designer FAR away from your Production Servers. The minute you open up a site from you Production Server and make a modification you are “developing in production”.  Don’t give your end users access to SharePoint Designer, and know the ramifications of what it’s doing behind the scenes.

Unless you truly understand SharePoint Designer and what it’s doing under the covers, don’t just dive in and starting writing applications (that’s what I did, and we are still paying for it with one of our most used apps).  If you are aware of it’s limitations and keep them in mind, it is a wonderful tool.

Hope I cleared up some of the noise and misinformation from the original post.  Thanks again guys for the great comments and feedback.

<update>

Here’s the link:  SharePoint Designer 2007

</update>

Families in Germany who are facing divers soundness problem, such persons can buy drugs from the Web without prescription. With the market flooded with divers web-sites selling sundry medicaments, purchasing medicines from th WEB is no longer a trouble for common man. Certain medications are used to treat infections caused by dental abscesses. Of course it isn’t all. If you’re concerned about erectile heartiness problem, you probably know about Xenical and Hoodia. Probably every adult knows about Garcinia. (Read more PhentermineXenical). The symptoms of sexual soundness problems in men include impossibility to have an hard-on sufficient for sexual functioning. Certain medications may add to sex drive difficulties, so its vital to cooperate with your heartiness care professional so that the prescription can be tailored to your needs. Preparatory to grab Levitra or other medicament, speak to your dispenser if you have any allergies. Talk to your health care provider for more details. Preparatory to ordering this remedy, tell your doc if you are allergic to anything.