2

I am going to be redesigning some SharePoint 2010 sites (basic content, primarily).

In the process of research, I have found there is a free tool called SharePoint Designer which presumably allows you to do this outside the web interface only.

My difficulties lie in trying to determine if SharePoint Designer is valuable enough to warrant investing the time to learn. However, I have not been able to find a good explanation of "when should I use SharePoint Designer?"

So my question is:

  • When designing a SharePoint site, when is using SharePoint Designer instead of simply the web interface appropriate?
Improve this question

4 Answers 4

Reset to default
6

As you see from rjcup3's and PirateEric's answers, there are two kind worlds: ones who prefer SPD and ones who prefer VS.

I preferred VS for 5 years until I had to learn SPD. I'm happy it happened, as I learned the difference between the two.

Short answer:

Use browser until there comes a requirement you cannot fulfill using browser. Then see if it can be done using SPD. Only after that consider using Visual Studio.

Long answer:

If you have only one environment (=production) and you don't need to have strict version control of each feature and whatnot you create into SharePoint, feel free to use SPD. It's quick and easy. In this scenario VS might bring too much overhead compared to benefits.

If you have multiple environments (dev, test, production, etc.) and you need to have some sort of application lifecycle management in place, you will quickly learn to appreciate VS and SharePoint solutions (WSPs). If you would use SPD in this scenario, you'd have to document all changes you make and redo them manually in every environment. Using WSPs, you have version controlled code (possibility to have it at least), and you can deploy changes in coherent manner across environments. All this works beautifully on MSDN documentation, but in practice...well.

Do note that using VS will usually require more time and more effort when developing compared to using SPD. It's because VS is more powerful and learning curve is steep. VS is for enterprise class application development, and that control and all enterprise application development requirements come at a cost.

But you can also mix the two: use SPD to create most of the site, then perhaps create custom features/web parts/web templates using VS. For small scenarios with some custom requirements, this is the way I've preferred.

Improve this answer
2
  • +1 for the middle ground answer.
    – RJ Cuthbertson
    Feb 27, 2013 at 21:01
  • +1 if it's things you will only be doing once, do it from SDP if you can. If you need to do it many times, and want it to be easily repeatable, use VS and create a solution. VS is harder to learn, and will take longer, but will save time if you make a change over and over (and again 3 years later for a new site...)
    – Grant
    Feb 27, 2013 at 21:05
0

Maybe it's just me, but I'm going to have to disagree with PirateEric on this one.

I never use SharePoint Designer except to "look" into a site hierarchy or list for support type work.

Granted I don't do workflows (or rarely do them), I've never found much of a viable use for SPD.

If I need to develop, I have Visual Studio for that. The few workflows I have done were state machine in VS. Master pages? Visual Studio. Intellisense? Visual Studio.

I think SPD (dangerously) opens up development on the site to "power users" who probably ought not be developing.

If you are just building out site content, the UI provides you with the tools to do that. If you need development work, Visual Studio gives you all the right tools. SharePoint Designer is the bastard child of both (in my humble opinion).

Improve this answer
6
  • 1
    Disagree. SPD can be controlled to be available only to users with sufficient training. That takes care of "dangerous". VS is absolute overkill in many situations. Say you just want to do some conditional formatting on a list view. Or create a DVWP. Or slightly change the layout of a CQWP. VS would create a huge overhead for simple tasks like these, and I would not want to deploy a solution on the farm for simple things like that.
    – teylyn
    Feb 27, 2013 at 20:44
  • I would agree with you that VS would be overkill for these tasks, and maybe you do more of this type of work, but I've never done any of them aside from learning, and thus don't see real value from it in my work day. My only interactions with SPD in the wild have been: me resetting files to the site definition through SPD (because it's quicker than whipping up a console app, and there's nowhere to do this in the UI), and dealing with end users crying when they ghosted their files by editing with SPD and they can't figure out what happened ("dangerous"...). There's two sides to the coin.
    – RJ Cuthbertson
    Feb 27, 2013 at 20:59
  • I've done a complete intranet redesign on SP 2010 with only OOB features, SPD, InfoPath and jQuery. These tools are very powerful and a LOT can be achieved without a single line of VS code. I see many cases where VS developers jump into writing code because they simply don't know what SharePoint can do, and a lot of wheels are being re-invented, creating hard to maintain and costly solutions.
    – teylyn
    Feb 27, 2013 at 21:08
  • I think Microsoft would disagree (look at SPD 2013). Bjorn Furuknap gets it: blog.furuknap.net/… (miss that guy's sarcasm on here... haven't seen him in a while). And using SPD as a workflow development tool is great and all... until you have to make a real workflow. threewill.com/2007/03/sp-workflow-limitations
    – RJ Cuthbertson
    Feb 27, 2013 at 21:28
  • Reading through the comments of Bjorn's post and you're on there vocalizing your love for SPD (and disdain for "developers") as well... your views on (bad) "developers" are just like my views on (bad) "power users". Looks like Bjorn already made my argument for me on there though.
    – RJ Cuthbertson
    Feb 27, 2013 at 21:43
0

If you want to do workflows, you need SharePoint Designer.

If you want to create new page layouts, you need SharePoint Designer.

If you value Intellisense when creating content, use SharePoint Designer.

If you want to create custom web parts or XSLT stylesheets for content query web parts or dataview web parts, you'll want to use SharePoint Designer.

If you're creating any type of javascript or using jQuery, using SharePoint Designer will help.

If you want to create new master pages, you need SharePoint Designer.

Improve this answer
0

We jokingly refer to it as "SharePoint Destroyer" at my work.

If you are doing branding work, we find it better and more manageable to work in Visual Studio, and create WSP solution packages that install the branding. The benefits are many, you can use source control, you can deploy the branding to multiple site collections, you can retract the branding and revert the site to its original state. With a WSP package, you can deploy the branding assets to the _layouts directory, and the files can then be served straight off the file system, rather than coming out of the content database. However, you can also deploy to the Style Library as well (for sandbox solutions).

We use SharePoint Destroyer mostly for troubleshooting, and for quick and dirty branding work (for example branding that will only ever be applied on a single site collection). We also use it sometimes for proof-of-concept branding work, as it is quick and easy to get going. If we like what we see, then we can port over the assets to a Visual Studio project later.

It's certainly a tool in your tool belt to become familiar with.

It's worth noting that its value is somewhat diminished in SharePoint 2013, as it has lost the Visual Design surface (only code view now), and is less relevant for Publishing sites (due to the introduction of the Design Manager).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.