EndUserSharePoint.com: In Defense of SharePoint Designer
Author: Paul Galvin
Web site: Paul Galvin’s SharePoint Space
SharePoint Designer gets something of a bad rap. Looking about at the many SharePoint blogs, you’ll find a lot of critical text thrown its way. Developer-focused blogs (that is to say, most of them) can be very harsh.
If you’re comfortable slinging HTML, XML and feel more at home in Visual Studio programming .NET applications than you do in Excel, odds are that you won’t like SharePoint Designer all that much. From the experienced developer’s point of view, SharePoint Designer is a broken toy as compared to Visual Studio. Their blogs show it.
SharePoint blogging is (today) dominated by an elite technical community. The rock stars of that community love the challenge of firing up their virtual machines and using the latest and greatest visual studio CTP to write C# code and create brilliant technical solutions with lots of bells and whistles. The SharePoint community is stronger for their efforts. However, I think it’s fair to say that the elites, frankly, disdain SharePoint Designer. I say “disdain” because it’s not an active campaign to discredit the tool. Rather, it’s more like the rise and fall of hats in America.
As the myth goes, President Kennedy didn’t care for hats. He stopped wearing them and it weakened the hat industry. He didn’t get up and tell the world, “Ich werde keine Hüte tragen.” Instead, he simply stopped wearing them.
We shouldn’t let this happen in the SharePoint community. We already face substantial challenges in learning a new tool (remember when you first started working with Excel)? We can’t let the dominant public voice suppress our interest even knowing that they aren’t trying to suppress it. We need to understand the point of view of SharePoint Designer’s detractors and take their opinions with a grain of salt. In other words, wear a hat if you want to, even if you’re afraid you look a little silly.
Over the coming weeks and months, I shall unashamedly write about how End Users can harness the power of this tool to craft quality business solutions. I’ll write about tips, tricks, traps and escapes we in SharePoint Nation need to know about the tool in the context of real world business problems that we need solve. It’s going to be easier and more productive that you might think.
Although I do have a master plan in mind, it’s far from a fixed path. The fundamental objective of this series is to provide useful real-world information of value to the SharePoint End User community (and interested developers). If you think I’m straying from that path or want to make suggestions, I’ll gladly adjust.
Next week: taking a small step back and looking at the big picture, describing all the options on the SharePoint dinner table and why SharePoint Designer is the best tool for End Users.
Paul Galvin
Paul is a Solutions Architect currently working most closely with Microsoft Office SharePoint Server 2007.
We use SharePoint Designer (SPD) primarily for adjusting the sizes/locations of web part zones and for Data Form (View) Web Parts (DVWP).
I like using DVWP’s and SPD because we do a lot of integration with external databases and SPD allows me to have non-programmers create database driven web parts.
But SPD is far from perfect – it has annoying bugs and can be quite slow. One suggestion I would have is to devote some blog postings to it’s shortcomings, so that perhaps the Microsoft team will get off it’s duff and make some significant fixes to it. When I get some time, I’ll list a few of the bugs we’ve encountered.
SPD definitely is a valuable tool, IMHO you can’t redesign a WSS v3 or MOSS site without it. And Joe’s right about its usefulness with web parts.
My frustration with it is probably more driven by the tool’s origins with FrontPage than anything else: it is not a top-notch web design tool. I recently completed a project for a customer where we redesigned their website (which was running straight HTML) and built it to use the content management functionality of MOSS. Our artistic team created a new look & feel for the site in Photoshop, then it was my responsibility to work w/ our HTML/CSS guru & port it to SharePoint.
After seeing what functionality he had available to him in Dreamweaver, I was honestly a little embarrassed to explain to him that we’d have to use SPD to finally implement the styling, even more so when he started using SPD. Dreamweaver has better artistic tools available, and is much more user-friendly.
That’s just my 2 cents though, I’m definitely looking forward to your series.
Thanks Paul!
John Ferringer
Part of the problem with SPD is that when it came out it had two big problems: it was considered the “next version of FrontPage” (a bad word in most circles) and it was, effectively, broken. What most consider its “quirks” (this word is too often associated with most of SharePoint 2007’s issues) are really features that just didn’t work. Did anyone backup and restore a site with SPD before SP1? No. Why? Because it didn’t work. There is no other way to say it. SPD was used (and probably still is) only for MasterPages, Page Layouts, and CSS given SPD was the only way someone could see into the SharePoint site structure.
Don’t get me wrong, it’s a good tool. Data View Web Parts are powerful, easy to use, but limited (try using one in a Variations site). But it, like MOSS, should have been released as 2008 products and shipped complete (i.e. “working”) and not rushed out 2007 products with flaws desperately in need of SP1. You compare it to Excel, but Microsoft would have been embarassed had Excel had the same bugs SPD did at launch.
Paul,
Looking forward to your posts on this often overlooked tool. I agree with Joe that there are some bugs with the tool, and it would be nice to be aware of some of those. However, when it comes to giving a powerful set of tools to a non-developer, there’s nothing out there that beats SPD.
Chris
SPD fills a crtical purpose in the spectrum of SharePoint Technologies and Services…between the UI and VS. And in defense of SPD, I recently completed a workflow application using SPD that far outperformed the application created by a contract “developer” using VS/C+. I did it in about half the time as well.
My point is simply that there are many tools within the toolbox of SharePoint Techhologies….all of which have value depending on the desired functional objective and the resources available for getting the work done.
I’ve also seen cases where a more thorough analysis of the requirements would have eliminated the need for custome developed code.
I’ve got several personal friends and associates that are very high calibre developer types, and have a great appreciation and admiration for what they do and for the contributions they make. The SharePoint community is just that…..a community – a continuum of skill sets, knowledge and experience. And it’s all positive.
Larry
Paul,
I have been using this tool for over 6 months now and had amazing results with numerous no-code solutions!
Never considered it an end-user tool, but that is exactly what it is! Can’t wait to see some of your posts.
Ryne
It’s worth mentioning that the “elitest” of the elite, at least that I’ve read recently, are perfectly willing to give the nod to SPD for the things it does well. This comes most often in the form of “build [something cool] easily in SPD, then pull it down into a feature/solution to facilitate deployability.” And of course deployability – crucial in development, maintenance, administration – is a primary concern for the “elite technical community” without whom there would be significantly fewer SharePoint sites to open in Designer to begin with.
The sense of disdain likely comes from two realities:
1) An untrained SPD user can do much more “damage” (hard-to-track breaking changes) than an untrained web user.
2) SPD is generally less stable and less consistent than VS and other environments used by the “elite”.
However, a third reality is often missed:
3) When SPD works as expected, it works well enough that issues only come up after SPD has left the picture.
So please spread the word about the powerful things that can be done with SPD. It will certainly help End Users, and it should help the “elite” as well. Just don’t be surprised if there are follow-up posts about how to harness that power in an elite-friendly way.
Or to continue the hat analogy: Wearing a hat for too long can leave hair in a mess only tamed by a thorough cleansing. For some, the hat might simply be a job requirement (end users), in which case hair could be kept shorter and less prone to disruption (governance, training). But those with longer hair (devs and admins) will prefer to wear the hat only when it’s most appropriate, leaving the hair easier to comb back into place.
Cheers ~
Keith
Paul,
I entirely agree with the lack of SharePoint Designer blogging. In fact, I devoted a post on my blog to the same idea last week.
Your post reconfirms my belief at a good time. I’m giving a presenation next week to group that contains a fair number of developers. I’m a little concerned they may take some of that negative approach to some of the Designer techniques I intend to demonstrate.
Looking forward to the new posts on the subject.
Tom
JoeD,
I hear you. I’m not a SharePoint Designer “fan boy”. There are certainly issues.
I’m going to take a very practical appraoch to those problems. I can’t control them but I can identify them and (to me, far more importantly) offer some ideas on how to work around them and solve whatever problem they cause. That’s the “escapes” bit of “tips, tricks, traps and escapes.”
I could rant about various SPD things (e.g. can’t easily move from dev->test->prod, way too many clicks on collect data actions, etc). However, that’s probably not all that helpful in the end.
I’m not going to sugarcoat it, but I’m focused on solving issues above all.
I don’t think the issue most folks have is with SPD, but, rather, the fact that there is no practical way to protect the MOSS Farm from anyone using SPD to break it.
As a back-end-admin, I can’t say only certain people can access the MOSS Sites via SharePoint Designer. I either have to let anyone with a copy of SPD in, or no one.
Hence the bad rap it gets.
I have used it for workflow, but then realized that VS.net is really the way to go with that.
I have used it for Masterpage customization and branding, but then realized managing branding farm-wide is impractical via masterpages and SPD.
So, in the end, I’m left realizing that SPD looks great on paper, but really doesn’t fit into the ‘enterprise’ landscape very well.
Now, if we’re talking about small shops, then I’d give it some credit.
D, I agree that the ability to restrict SPD is a major issue.
You can break sites with it. I’ve seen it happen – and it’s not necessarily because of user error. It’s happened to me – I was doing a presentation on Data View Web Parts at a SharePoint User Group and (of course) SPD crashed during my demo. It did something to the site and I could not get back into it – I had to reset it to the site definition to get it back. Not fun when you are in front of a room full of people…
(Ironically, at the end of my Powerpoint deck, I had a slide that said “Save often, SPD crashes” – I guess my point got across – a live illustration.)
Anyway, I don’t really look at it as “SPD is a great tool” vs. “SPD is a good tool” vs. “SPD sucks”. Because it’s really the ONLY tool you can use (without delving into the XML behind the scenes). I can’t really compare SPD to something like Dreamweaver, because it’s apples and oranges – Dreamweaver can’t edit SharePoint sites.
My hope is that the next version of SharePoint will eliminate, or severely reduce the need for SPD at all. If the web interface would allow the creation/sizing/positioning of web part zones, Data View Web Parts, workflow editor (ala Nintex or K2’s Blackpoint), and a few other things and I wouldn’t need SPD that much. I can only hope…
I aggree that SPD designer has its issues, but I prefer working with it rather than Visual Studio. My problem with SPD is usability and consistency. When a SharePoint administrator fires up Designer he should have faith that this product will achieve his objective without fail… unfortunately, this is not the fact. But, we work with what we have.
I run hot and cold on SPD. On the one hand, as a “former” developer now reassigned to project and customer management, I don’t have the time to really dig into code & develop sites with VS. So, SPD allows me opportunities to build effective (read: functional) sites in a limited amount of time. On the other hand, the program is, well, buggy. It crashes if you look at it cross-eyed. It’s also quite limited in this release, esp. in it’s more critical place of helping end-users develop workflows.
I train new users to use SPD in order to learn the ins and outs of Sharepoint, not because I necessarily think SPD is a great tool. Lots of shudders go through the room when I utter the “F********” word, but it does give you a better understanding of the organization, structure and possibilities of Sharepoint as an IW or development tool. Paul’s note about breaking: I always train my users to check out and save, not just save. I also relate stories of how easy it is to break a site (and you can’t just go back to a site definition, my friends, when your users ‘accidentally’ move all of the XML styles to a completely different folder – that requires intelligent reading of the SPD error messages). Moral: no matter what MS says, “Yes, you CAN break your site with SPD”!
All of this said, SPD has been absolutely AMAZING at forcing me (against my will) to become more proficient at coding in XSLT. I’m working on a program that is basically a job-posting and application management tool at a University. What’s been nifty is how I’ve been able to do things I only thought possible using C# (VB) – if anything, my work with SPD has really helped me understand the possibilities inherent *across* the language and tool spectrum, and helped me become more comfortable with things like LINQ and XAML.
End point: I will continue with use SPD as a development tool, despite the derisive comments that my developers make to me about my being reduced to “power user” status. For all its flaws and warts I think I’ve actually got a better “end user” picture of Sharepoint that anyone else on my dev team. Using it has shown me the enormous possibilities of Sharepoint as a development platform (note I said ‘possibilities’) once the platform matures just a bit more.
SPD features are usefull but the performance is realy a hindrance. Why big company like Microsoft ralease a product which is so slow to load? Pressure from shareholder? Quality should be always priority.
How would designer work quickly when loading the page is so slow?