Putting the SharePoint in SharePoint Designer


For those of you who have been with us for the long haul, you know SharePoint Designer (SPD) evolved from the FrontPage product. The result of this lineage was SPD 2007 largely focused on web page editing and added some SharePoint capabilities. In SPD 2010, we increased our investment in SharePoint capabilities and focused on exposing the power of SharePoint to both power users and developers alike. SharePoint has always been about the democratization of web development - think of SPD 2010 as furthering that goal.

Figure 1

Figure 1. SPD's new shell focuses more on SharePoint objects and less on the file structure and page editor. The UI is now much more intuitive and helpful with the Ribbon and navigation pane.

When you think about democratization, a few words come to mind: awareness, access, utility. If you're an IT shop, some other words might come to mind too: safe, supported, compliant, and dare I say governed? When we started our mission, we took these words to heart. We were more successful addressing some goals than others, but let’s be clear, we understand that it's not a good idea to simply empower every Tom, Dick, and Jane with a simple, powerful application building tool and just hope IT can deal with the explosion of applications.

So to that end we will start with the IT side of the equation:

  • Safe: Multi-tenancy is one of the huge strengths of SharePoint, but this often limits what users can do with the system. The shared nature of the system means users cannot add powerful server side code to the system. In this release we provide User Solutions, a server sandbox enabling users to upload their own code or code from a third party to complete their scenarios where that code runs in an isolated process. Even better, IT has control over the throttling and contents of the sandbox so shops can tune it for their level of comfort.
  • Supported: Historically when you put SPD in the hands of a user, despite best intentions, they broke things. And this resulted in support calls, lots of them. In this release SPD is Safe by Default. Users cannot simply edit the master page or delete a content place holder and bring down an entire site collection! This is a powerful IT feature that will require its own blog to explain in detail, but the gist is users cannot just open a site and break it before they even know what they’ve changed.
  • Compliant: Because we have locked down the capabilities in SPD, IT shops can now control which templates, master pages, and styles can be used in their orgs. This makes it easy to ensure sites comply with corporate policy.
  • Governed: In this release we did not only improve the supportability of SPD, we gave IT simple, granular control over who can use SPD on which areas of their farm.

Now that you know IT is going to bless the use of SPD, let’s dig into the end user aspects of the democratization of web development - awareness, access, and utility.

  • Awareness: We can make all the improvements in the world on this tool and it will be largely irrelevant if users are not aware the tool exists. To help address this issue and drive efficiencies we now directly link the SharePoint browser interface with SPD. Through these links we have significantly reduced the complexity of using SPD to edit specific, targeted aspects of SharePoint sites. This means users simply click a button in the browser and SPD is opened directly to the right spot. A future blog will cover all the links in detail but here is an example (Figure 2), cool huh! Yes, these links only show up if the user has permissions to SPD - remember what I said in the governance section?

Figure 2

  • Access: Many of you may not even know what SPD is or that it even existed, much less that this tool will help your organization get the most out of its SharePoint installation. There were two primary reasons for this lack of awareness, 1: due to its price tag many organizations opted not to buy only limited copies of SPD, and 2: because of its power, many IT organizations restricted the use of SPD on the network. This release our team worked hard to address these issues that blocked user access to SPD.

1. FREE! That is right, you heard me, FREE! SPD is now available as a free download.

2. Safe by Default, with this release it is very hard for users to shoot themselves in the foot. Look for a future blog on this - but suffice to say, it takes explicit permissions to unghost a page!

Figure 3

In addition to the UI there are a number of other features we have added to make the tool more useful for IWs:

  • Workflows have been dramatically improved with a new editor (Figure 4), reusable workflows, and even more powerful workflows that come out of the box. Look for several workflow blogs to come out soon.

Figure 4

Figure 4. Workflows are now easier and more flexible to create in SPD. The full screen designer incorporates the ribbon and other intuitive UI.
  • XSLT List Views are also a big investment for us. XSLT list views are now the default view for lists which means developers only have to learn one list technology! This standardization also let us deliver some great features such as Push Button Styles that enable styling and conditional formatting with the push of a button. Of course we will have a blog or two on this topic too.

I hope you enjoyed reading about the breadth of features coming from SPD this release and we would love to have you back soon to read about these and other features in detail. For now let me leave you with a parting thought: in this release we invested heavily in IWs to complement the functionality offered to developers and designers. Additionally you will see amazing stuff from VS and Expressions in forthcoming releases integrating with SPD and the best SharePoint has to offer. Of course, look for blogs on these topics in the coming months too.

Signing off for now –
Todd Haugen (SPD GPM)