Geeks With Blogs

News





The SharePoint Hillbilly Fewer Big Words... More Pretty Pictures...

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>

Posted on Sunday, March 29, 2009 10:19 PM | Back to top


Comments on this post: SharePoint Designer – A definite Maybe

# re: SharePoint Designer – A definite Maybe
Requesting Gravatar...
SPD free? Have you seen any official announcement?
Left by Christophe on Mar 29, 2009 10:49 PM

# re: SharePoint Designer – A definite Maybe
Requesting Gravatar...
I was told at SharePoint Saturday yesterday and saw it again from Matt Bremer today:

http://blogs.msdn.com/mattbremer/archive/2009/03/26/sharepoint-designer-available-as-free-download-after-4-1-09.aspx

Left by Mark on Mar 29, 2009 10:55 PM

# re: SharePoint Designer – A definite Maybe
Requesting Gravatar...
I don't understand the comments about Prototyping and "not developing on the server". Unless you have multiple SharePoint installations or VM environments, you're working on the Production server even tho you're doing it via SPD, right? Are you suggesting to somehow use SPD to demo a prototype that you haven't saved to your SharePoint installation?
Left by Ricardo on Mar 30, 2009 12:14 PM

# re: SharePoint Designer – A definite Maybe
Requesting Gravatar...
Awww... Dissension.. it's beginning to feel like a REAL blog!

GREAT comments John and I totally agree with what you are saying for the most part. It is my OPINION though that you keep SPD away from Production servers. The moment you open up your production site in SPD, make a change, and then save it you have just developed in your production environment. And I'm NOT in ANY way saying don't use SPD. I'm saying unless you understand what it does and how to use it, don't use it. There are WAY too many people new to SharePoint out there that will take hold of SPD and do some real damage (I was/AM one of those people).

Anyway... thanks again for the comments, much appreciated. I actually just got off the phone with Woody Windischman (GREAT guy, very helpful) and I will be making some updates today to the blog. I didn't mean for it to come off as negative as it sounds, I just REALLY want people aware of how to use it.
Left by Mark on Mar 30, 2009 12:33 PM

# re: SharePoint Designer – A definite Maybe
Requesting Gravatar...
Ricardo,

You REALLY should have multiple SharePoint Farms... especially a QA farm for just such an occasion. If you don't, you are going to be fighting a lot of issues when you start any sort of custom development on your VM. Don't connect SPD to your production farm and develop. Again... an opinion, but never a good idea to develop in your production environment.
Left by Mark on Mar 30, 2009 12:36 PM

# re: SharePoint Designer – A definite Maybe
Requesting Gravatar...
Blog updated... mostly clarifications and toned down parts where it sounded too negative.
Left by Mark on Mar 30, 2009 1:25 PM

# re: SharePoint Designer – A definite Maybe
Requesting Gravatar...
I too am concerned with it becoming free. SPD has it's uses but I fear our end users will grab it and royally screw things up.
Left by eric on Mar 30, 2009 1:27 PM

# re: SharePoint Designer – A definite Maybe
Requesting Gravatar...
John,

It depends who you ask I guess. There's always going to be topics of debate with some of this stuff and I don't have the raw data to prove what the impact would be. Maybe it's only an issue 10% of the time and I need to move it out of "The Ugly" section and move it to "The Bad", but I do think it is very important to know about because I'm sure most people don't know that's going on behind the scenes. And as soon as someone says something like "it's not worth mentioning" it's like inviting trouble. :)
Left by Mark on Mar 30, 2009 1:42 PM

# re: SharePoint Designer – A definite Maybe
Requesting Gravatar...
Thanks for taking the time to listen during our chat, Mark!

I just wanted to clarify on that upgrade point, that I didn't say there *are* issues with upgrading sites based on custom site definitions. I said that that there may be issues. (There were pretty major ones moving from 2003 to 2007).

While we don't know just what all of the upgrade issues can be, you might want to monitor this KB article:
http://support.microsoft.com/kb/960577

That article describes the things that the pre-upgrade tool will start flagging as issues for the 14/vNext migration. (Several of the individual sub-articles referenced therein appear to be offline at this time.)
Left by Woody on Mar 30, 2009 1:45 PM

# re: SharePoint Designer – A definite Maybe
Requesting Gravatar...
Another item for the "Good" section: Data Form Web Parts. Even if you are in the camp of "never use SPD because all changes should be done as features", you can quickly create dynamic content from SharePoint lists for both MOSS and WSS with a very easy to use design UI. Purists can then copy the web part from code view into whatever environment they are using to create their features (usually Visual Studio).
Left by AndyGett on Mar 30, 2009 5:55 PM

# re: SharePoint Designer – A definite Maybe
Requesting Gravatar...
Let me set a few things straight here:

1) Customizing a page in SPD *does* put all the content into the content DB. The assertion that SP checks the content DB before the disk cache is absolutely, unequivocally false - IIS and the MOSS cache are responsible for this operation and disk-based files are served first. Not only that, but anyone who asserts that a trip to the database to fetch an entire content page is more efficient than fetching from disk cache has no understanding of the way IIS or basic network transit protocols work. Local DAS is *always* faster - period. And this is especially true in SharePoint where the database is already getting hammered.

Now, to be clear, SP actually does both - loads the file from disk (if available) AND loads the web parts and publishing controls from the content database; however, if the MOSS cache already has the page on disk it will be served from there first. Under no circumstances would going to the content DB first make any kind of sense from a performance perspective. IIS compression is simply responsible for taking often requested items and making their footprint smaller for transmission; it cannot do this with files that reside off-disk.

If you have never run into the issue of customized files causing performance degradation then you simply haven't scaled your tests high enough; conduct more comprehensive load testing and you will plainly see the difference between disk-based cache for ghosted files and DB queries. Why do you think MSFT created the whole ghosting methodology in the first place? Why do you think they use it for all the out of the box files in every out of the box site definition? For good, solid, demonstrable performance reasons, that's why. I'm sorry, John, but whoever told you that there is no appreciable performance difference is just plain wrong. They just haven't seen it yet because they haven't scaled that big.

2) The whole issue about touching files on each WFE likely arose out of a misunderstanding from my presentation. In comparing SPD customizations to custom site defs, I pointed out that post-deployment customizations can be batched using features and WSP's in site defs but must be made manually in every site collection where SPD has been used *not* every WFE (sorry if I wasn't clear on this point). This is a fact - "unghosted" or "customized" pages break the relation to the underlying disk object; they must be manually modified in each master page gallery (whether they are master pages or layout pages). This is a far less efficient update mechanism than the feature-based approach.
Left by Eric Shupps on Mar 31, 2009 12:27 AM

# re: SharePoint Designer – A definite Maybe
Requesting Gravatar...
[The server wouldn't take my whole comment so here's the second half]

3) Stop the FUD regarding site defs and upgrades. 2003 -> 2007 was a one-time process made painful by the sweeping changes in the underlying framework. If the feature framework is used properly there is NO reason to believe that your custom site defs won't upgrade just as well as MSFT's from 2007 -> 2010. C'mon, Woody - you should know better.

4) SPD is both good and bad. From a performance and manageability perspective it's very bad. From an ease of use perspective, very good. You have to decide what's best for your organization. I warn you, though - Mark is right. Letting this tool loose for free to the user community is going to become an administrative nightmare because it lacks even the most basic security framework. We simply don't have enough control over the use of this tool in MOSS/WSS. I've seen many a "power user" destroy a portal because they did something stupid with SPD that they didn't mean to or weren't advised against.

5) Finally, the staged deployment model is an absolute best practice *if* you can afford it in your environment and *if* your various teams are geared to support it. SharePoint as a whole does a very poor job on supporting staged enterprise environments and SPD is only a symptom of the overall problem. Features and WSP's are much, much better in this scenario and a good rule of thumb is never to edit content in production but we all know that's a pipe dream. Until SPD can package everything you do into a WSP then there's no other option. Be aware of it, implement the proper controls, make sure your users are prototyping in a dev environment, creating stand-alone web part pages for DVWP's and saving the final output to the site gallery, etc. and that's about the best you can do.
Left by Eric Shupps on Mar 31, 2009 12:28 AM

# re: SharePoint Designer – A definite Maybe
Requesting Gravatar...
One more note...Todd Klindt pointed out that IIS dynamic compression on Server 2008 does a better job of handling inline compression and this is true, even for customized pages. What happens is that IIS gets the request first and checks it's disk cache; if the object is resident then it serves it without ever having to touch MOSS and compresses the HTTP Response stream on the fly. If not, the request is handed off to the MOSS pipeline (the inefficiences of which are a topic for a whole 'nother discussion). MOSS checks its own cache then, if the object doesn't already exist or has been flushed, compiles the content and delivers it.

The compilation process (I'm sure there's a better term for it) is the crux of the problem. If the page is uncustomized then MOSS need only grab the dynamic page elements not already in the cache from the DB - web parts, publishing controls, etc. If it has been customized, it has to grab the entire page - master, layout, controls, everything - from the DB, pass it through the safe mode parser, then return it. This is obviously far less efficient than if the page were ghosted.

For WSS the story is even worse, as the MOSS cache is bypassed altogether and all page content is via web parts. You can really see the performance hit on customized pages in WSS. IIS 7 is better at this than IIS 6 but, in the end, ghosted is still more performant than unghosted.
Left by Eric Shupps on Mar 31, 2009 9:48 AM

# re: SharePoint Designer – A definite Maybe
Requesting Gravatar...
Joel wrote a great counter-post on his blog
"SharePoint Designer – More than a Maybe"

http://www.sharepointjoel.com/Lists/Posts/Post.aspx?ID=204

Hey, getting put in your place by Joel Oleson is kinda like having Jimi Hendrix show you the right way to play the guitar... The fact that he noticed means your doing something right.

I'm going to have to write controversial blogs more often!
Left by Mark on Mar 31, 2009 11:00 AM

# re: SharePoint Designer – A definite Maybe
Requesting Gravatar...
Hi Eric,

First, I need to clarify that I absolutely was NOT talking about the CACHE in my discussions with Mark. Only the original page construction process. The bulk of our conversation was to clarify the "change every WFE" issue, and we really didn't talk about caching at all.

In any case, the final performance of serving pages depends upon a lot of factors, and customized vs non-customized is definitely one of them. Whether it is the critical path in any given case is an open question.

The 2003-2007 upgrade issues are absolutely a worst-case scenario. I state in many forums (including my book) that while Microsoft has certainly learned from it, we won't know until it happens exactly what customizations will cause 2007-vNext issues, what those issues will be, or what we can do to mitigate them.

Fortunately, Microsoft is trying to be more proactive in letting us know about potential migration issues as they are discovered. Hence the KB article I linked to in my previous post.

With regard to "I should know better", all I am doing is advising prudence, and only changing those things you need to change. If you don't need to build a site definition to achieve your goal, you shouldn't. If you don't need to customize individual pages in SPD, you shouldn't. If you use SPD to build Data Views, as long as you have them in Web Part Zones, you can revert to site definition once you're done and have the best of both worlds. (In a perfect world, just changing Web Part Zone contents wouldn't be breaking the SD connection in the first place, but that's a different issue...) :)
Left by Woody Windischman on Mar 31, 2009 11:02 AM

# re: SharePoint Designer – A definite Maybe
Requesting Gravatar...
Eric,

Now that I'm not trying to run out the door to make a 3 hour drive, I want to add that I really think we're agreeing more than not. Rather we were simply talking about different facets of this huge beast called SharePoint.

- Woody -
Left by Woody Windischman on Mar 31, 2009 4:45 PM

# re: SharePoint Designer – A definite Maybe
Requesting Gravatar...
Re the IIS compression discussion.

I have not found that whether the page is ghosted or not has any impact on compression (at least for Windows Server 2003, where I have done extensive testing of IIS compression, IIS caching and blobcache in MOSS). I think people are confusing IIS static compression and IIS dynamic compression.

IIS looks at the extension of the file requested to decide whether to do compression. Extensions like .txt are "statically" compressed, where it keeps a compressed copy of the file on the local disk to save compressing it again for the next request.

Extensions like .asp are "dynamically" compressed, where IIS compresses the output to send to the client but doesn't keep a copy on disk because it is likely to need to be different for the next user.

By default, .aspx is not compressed at all unless you add it to the list for dynamic compression (which you have to do with a script, since there is no UI). On a modern server, the performance overhead of compressing is very small, and far outweighed by the benefits of shorter data streams.

But, the compression behaviour is controlled by extension, not file location / ghosting.

Caching is another story. For "static" items on the physical file system, including ones in virtual paths like _wpresources, you can control caching settings through IIS. For items in the SharePoint database, you have to rely on Blobcache, which is limited to published items in document libraries. This excludes (for example) components of themes in the _themes virtual directory in a site, so the browser re-requests these on every page load.

For caching dynamic items, you have the output cache, which also has quirks.
Left by Knox Cameron on Mar 31, 2009 8:52 PM

# re: SharePoint Designer – A definite Maybe
Requesting Gravatar...
Looks like SharePoint Designer 2007 is now FREE! chk out http://microsoft.com/spd/
Left by Kanwal Khipple on Apr 02, 2009 6:09 AM

# re: SharePoint Designer – A definite Maybe
Requesting Gravatar...
"Let's say you've got an admin who wears all the SP hats in an org and his boss wants him to add more functionality - you want him writing code? I sure don't."

Hi, I am that Admin, and I would be up the proverbial creek without SPD. So here's a shout-out from a person who loves it and couldn't live without it.
Left by Nancy on Apr 03, 2009 3:28 PM

# re: SharePoint Designer – A definite Maybe
Requesting Gravatar...
Mark, Eric, I tend to agree with Knox Cameron regarding the fact that for IIS to compress, what matters is the exention, not the file actual location.
Can you elaborate a bit more on you findings? Thanks!
Marc
Left by Marc Lognoul MVP on Apr 20, 2009 8:38 AM

# re: SharePoint Designer – A definite Maybe
Requesting Gravatar...
Nancy, I am one of those Admins too! I have just downloaded the free SPD and now I am scared to death to do the install! It just seems like everything I want to do on my site requires SPD. I look up in "help" how to do something and it refers me to SPD!! What's a girl to do?
Left by Carmen on Apr 21, 2009 4:34 PM

# re: SharePoint Designer – A definite Maybe
Requesting Gravatar...
Anothe item for the "Good" section: Data Form Web Parts. Even if you are in the camp of "never use SPD because al changes should be done as features", you can quickly create dynamic content from SharePoint lists for both MOSS and WSS with a very easy to use design UI Purists can then copy the web part from code view into whatever environment they are using to create their features (usually Visual Studio).
Left by kidney stones symptoms on Oct 16, 2009 4:31 AM

Your comment:
 (will show your gravatar)


Copyright © Mark Rackley | Powered by: GeeksWithBlogs.net