Fail Forward Fast

Developer's Guide to Silverlight in SharePoint

What's in this article:

1. Building a Silverlight Web Part for SharePoint 2010
2. Accessing SharePoint Data from Silverlight Via the Client Object Model
3. Using Silverlight to access external systems like WCF and REST while inside a sandboxed solution
4. Deploying a Silverlight Web part for a Sandboxed Solution via a Feature
5. Debugging Silverlight Web Parts in SharePoint
6. A Faster Option: Piggyback on the HTML Bridge

DOWNLOAD Source code for the following...

My goal with this blog post is to take a 360 degree tour of where SharePoint and Silverlight technologies come together. Silverlight is undoubtedly a technology that is growing in popularity, and from a SharePoint perspective introduces some unique benefits that can't be achieved any other way. One such benefit is the ability to access external systems from Silverlight while in SharePoint Sandboxed Solutions. This is not possible with a .NET web part.

 

From a SharePoint data access perspective, there are several compelling techniques that I outline herein, such as using REST and the Client Object Model. Another important technique to understand is HTML bridging, whereby you can reduce server round trips and increase performance of your applications.

But before I get too dirty, I want to start off with a quick Silverlight/SharePoint 101... building a Hello World Silverlight web part...

 

1) Building a Silverlight Web Part for SharePoint 2010

To get started with our Silverlight journey, let's begin by building a simple "Hello World" Silverlight web part. To spice it up a bit, we'll add some animations, and color effects that show off the "brilliance" of Silverlight.

Building a Silverlight web part involves essentially 3 steps, 1) build the Silverlight application, 2) deploy that application into a SharePoint document library, 3) use the Silverlight web part to render the application. Steps 2 and 3 are pretty elementary, but for newbies, let's walkthrough how to build an application. Note - steps 2 and 3 don't necessarily represent the best practice approach to deploying your Silverlight application. Later in the article we'll touch on a better way, but for now let's keep things simple.

1. Create a new Visual Studio 2010 project using the Silverlight Application template (.NET 4.0 framework is OK):
   
   
   
2.  Next choose to create a new hosting site. This site will be used to unit test our Silverlight application before we bother getting it into SharePoint. Choose Silverlight 4 from the drop down (if not present, download the Silverlight 4 toolkit for Visual Studio):
   
   
3. If you double click on MainPage.xaml, you'll notice the Silverlight xaml surface where we can start building our application. Enter the following TextBlock to simply render our text onto the Silverlight application:
   
   <TextBlock x:Name="Text" Text="Hello World!" FontSize="50" VerticalAlignment="Center"TextAlignment="Center" FontFamily="Georgia" FontStyle="Italic" 
   FontWeight="Bold" FontStretch="Expanded">

   </TextBlock>

4. If you're impatient or nervous, you can test the application by first building the Silverlight project, then building the test project, and simply right click the HTML page and choose View in Browser:
   
   
   Pretty easy huh?
5. ​Well technically we've built our application, but it sure isn't "cool". Let's extend it a bit to change the font color, make it rotate when a user hovers their mouse over it, and make it fade in and out (opacity). First let's make the color a rainbow gradient by adding the following into the xaml just before the </TextBlock> tag:

   
   <TextBlock.Foreground>

       <LinearGradientBrush>

           <GradientStop Color="Red" Offset="0.0" />

           <GradientStop Color="Yellow" Offset="1.0" />

       </LinearGradientBrush>

   </TextBlock.Foreground>

6.  To make the text move around we need to add a Silverlight transform. Again, just before the </TextBlock> tag add the following xaml:

   <TextBlock.RenderTransform>

       <RotateTransform x:Name="spin" Angle="0" CenterX="200" CenterY="50" />

   </TextBlock.RenderTransform>
   
   This code define the transform the text block will use. Note it's name is "spin", which is another piece of xaml we'll need to add later. This xaml is more or less a pointer to "spin" which will define what actually will happen.

7.  Now let's add a storyboard and an animation named "spin" that will dictate the movement of the text block. Add the following xaml just above the <TextBlock> tag:

   
   <UserControl.Resources>

       <Storyboard x:Name="homeboard">

           <DoubleAnimation

           Storyboard.TargetName="spin"

           Storyboard.TargetProperty="Angle"

           From="0" To="360" Duration="0:0:5"

           RepeatBehavior="Forever" />

       </Storyboard>

   </UserControl.Resources>
   
   This xaml defines a storyboard named homeboard, with one animation named spin (a story may have many animations, etc). Spin instructs the object to rotation on its axis over a half second.

8.  The next step is to start the story  board. We want our story board to start when the user clicks on the text block. Add the following xaml as a property of the text block (similar to FontFamily, FontSize, etc):
   
   MouseLeftButtonDown="StartAnimation"
9. StartAnimation points to our custom event handled defined in the MainPage's code behind. Right click on MainPage in the solution explorer and click View Code. Next add the following code into the class:

   private void StartAnimation(object sender, MouseEventArgs e)

   {

       homeboard.Begin();

   }
    
   This code simply executes the homeboard storyboard.

10. The last thing we wanted to do was make the text fade in and out by changing its opacity. To do this, add another animation directly below the DoubleAnimation within the storyboard:

    <DoubleAnimationUsingKeyFrames Storyboard.TargetName="Text" RepeatBehavior="Forever"Storyboard.TargetProperty="(Opacity)" BeginTime="00:00:00">

        <SplineDoubleKeyFrame KeyTime="00:00:01.0000000" Value="0"/>

        <SplineDoubleKeyFrame KeyTime="00:00:02.0000000" Value="1"/>

    </DoubleAnimationUsingKeyFrames>
    
    Notice how we're targeting the "Opacity" property of the TextBlock, and it takes 2 seconds. The first second it fades out, and the second it fades back in.

Before we deploy into SharePoint, build the project(s) again and ensure all the animations are working. The next step is to upload the XAP file (project directory/bin/debug) into a document library in your SharePoint site (note, a more advanced approach would be to package the XAP in a feature and module to have it automatically deployed). Following this, find a page and drop in the Silverlight web part and set the URL property and point it to your XAP file. That should be it!

2) Accessing SharePoint Data from Silverlight via the Client Object Model

I doubt you'll ever build a web part for SharePoint that doesn't need to interact with data that is actually stored in SharePoint. This next section will extend the "Hello World" web part we built in the previous section to include a walkthrough on how to read the web parts text (Hello World) out of a SharePoint list. With a .NET web part this would be trivial. You'd simply do SPContext.Current.Web.Lists["ListName"].GetItemByID(1)["Title"].ToString(), for example. Well the bummer with Silverlight is we're not going to have the same typical Object Model experience. In fact, Silverlight is treated as if it were a client application, such as Word, Excel, etc, and we're going to need to leverage SharePoint's WCF web services to get at our SharePoint data.

If this sounds scary - don't worry! A new feature with SharePoint 2010 is the new client object model. With the client object model, you can access SharePoint data via their WCF services in nearly the identical way you would if you were using the standard OM. The client object model wraps the WCF services with classes that have that work in nearly the same way as standard OM classes work.

For example, the standard OM has a class called "SPWeb", which you are likely familiar with. The client OM has a similar class named "Web". This paradigm is true with other classes such as SPContext->Context, SPSite->Site, SPList->List, etc. The following is a quick example of how these classes are used (for more info, reference this MSDN article):

using Microsoft.SharePoint.Client;

...

using (ClientContext context = new ClientContext("http://intranet"))

{

    Web web = context.Web;

    context.Load(web);

    context.ExecuteQuery();

    string title = web.Title;

}

 

The first thing the code does is wrap the Context in a using statement pointing to the SharePoint site we want to get data from. Next the Web object is loaded, followed by calling Execute. When Execute is called, the Client OM will invoke the WCF services and take the round trip to get the data from SharePoint. Note, only the data that is loaded will come back not the entire site collection. If you ever had to use the web services in SharePoint 2007, you'll know how incredibly easy this is in comparison.

With this quick tutorial under our belt, let's extend our Hello World example to read a list item in SharePoint, and retrieve the Hello World text:

1. Add a reference to the Microsoft.SharePoint.Client.Silverlight DLL and the Microsoft.SharePoint.Client.Silverlight.Runtime DLL (TEMPLATE\Layouts\ClientBin).
2. Right click on App.xaml, and click View Code. Then, add the following using statement:

   using Microsoft.SharePoint.Client;

   using System.Threading;

    

3. Within the Application_Startup method, add the following line of code:

   
   ApplicationContext.Init(e.InitParams, SynchronizationContext.Current);

4. Just within the class, add the following global fields:

   
   ListItem item;

   Web web;

   ClientContext context;

5. Back at the MainPage code behind, add another using statement for Microsoft.SharePoint.Client, and paste the following code inside the constructor, bellow the InitializeComponent() call:

   
   context = new ClientContext(ApplicationContext.Current.Url);

    

   web = context.Web;

   context.Load(web);

   context.Load(web.Lists);

   List list = web.Lists.GetByTitle("Hello World Test");

   context.Load(list);

   item = list.GetItemById(1);

   context.Load(item);

    

   context.ExecuteQueryAsync(new ClientRequestSucceededEventHandler(success), null);
   
   Notice how the first thing you do is instantiate the context off the current Silverlight's application URL. Next we load the web, lists, and the list we want, in this case the list titled Hello World Test. Then we get the item we want and load that as well. The last thing is to call Execute which is what initiates the round trip to the server. The main difference with this example, versus the previous one, is this code works in Silverlight and the other doesn't. Essentially all calls in Silverlight must be asynchronous, hence ExecuteQueryAsync. The next step is to add the "success" method delegate defined in the Async Execute.

6. Below the constructor paste in the following success method:

   
   private void success(Object sender, ClientRequestSucceededEventArgs args)

   {

       Dispatcher.BeginInvoke(() =>

           {

               Text.Text = item["Title"].ToString();

           });

    

   }

   
   All we want to do in the success method is update the Text of our TextBlock. The trouble is the UI thread and the background thread (thread we're currently in), are just that... two separate threads. It's impossible for the background thread to update the UI, so the Dispatcher is what allows us to get our code block in the UI thread's queue. With this in place, we're DONE! time to test...

7. Build the project, upload the new XAP file into the doc library (override old one), and test your web part. This time it will read the Title field from the 1st list item in the list specified in code.
   
   NOTE: CLEAR YOUR BROWSER CACHE! If you are thinking you're not seeing your XAP changes taking hold, clear your browser's cache (delete cookies, etc), then close and reopen your browser. Thereafter you will see your changes.
   
   NOTE: if you get the following error, make sure that you have loaded **ALL** the objects before calling Execute, as well as use the Dispatcher to update the UI. If anyone tells you the XAP file has to be in the Layout\ClientBin directory, they're lying.
   
   Error:

Unhandled error in silverlight application invalid cross-thread access 

 

3) Using Silverlight to access external systems like WCF and REST, while inside a sandboxed solution

There are two MAIN reasons why I feel Silverlight is becoming an important asset in a SharePoint Developer's toolbox. The first is obvious... Silverlight gives a developer the ability to produce compelling user interfaces. Unfortunately the benefit of an improved user interface is very subjective, and a developer may have trouble convincing management that it's worth the time and money to build. However, the second reason Silverlight is becoming more prevalent is much less subjective... in fact it is the only viable course of action, given the right requirements. You see, SharePoint 2010 has a new featured called Sandboxed solutions. Sandboxed solutions allow you to deploy code into SharePoint that is isolated from the outside world. Essentially that code can only interact with the site collection that it is deployed into. Sandboxed solutions also allow code usage to be monitored. So for example, say an IT company has a charge back model to its business units. In SharePoint 2007, IT could only charge based on Disk usage, # of sub-sites, or number of site collections. If one business unit has more requests per second, for example, and put a heavier load on their infrastructure, there was no way to monitor that. Now with Sandboxed solutions, IT can monitor the usage of code, such as web parts, but monitoring CPU cycles, etc.

 

Another important reason sandboxed solutions are being adopted is because infrastructure teams want to keep their servers clean, and "out-of-the-box". Sandboxed solutions allow you to keep a vanilla infrastructure, but still deploy custom code such as custom Web Parts.

 

It is easy to see why a lot of companies are adopting sandboxed solutions, but here is the problem. What if you want the benefits of Sandboxed solutions, but you still need custom code that can access external systems, such as invoke a web service? Remember, a .NET sandboxed web part can only interact within the site collection that it resides in.

 

And here is the benefit of Silverlight that a standard .NET sandboxed web part cannot boast - it has the ability to access external systems, even when deployed inside a sandboxed solution! So you see... in SharePoint 2007, Silverlight was "neat" and "cool", but you didn't have a hard and fast reason that would necessitate it. But now in SharePoint 2010, there's a specific use case that brings Silverlight skills for SharePoint Developers into the limelight.

 

So now that you're convinced of the "why", lets get to the fun part, the "how".

 

Up until this point we really haven't seen anything that a standard .NET web part can't do (albeit, the animations would be hard in .NET). Let's change the pace by taking changing our Silverlight app to call a WCF service to get it's text. Again, this is not allowable in a Sandboxed solution.

 

Just like newbies for Silverlight, I'm going to assume I may have some newbie for WCF, and we'll quickly walkthrough how to create a WCF service that returns the string "Hello WCF". We'll then add another TextBlock, but this time it'll read it's string out of the result from the WCF call.

 

1.  Start by adding a new project into our existing solution. Use the WCF Service Application template.
2. Paste the following service method above the auto-generated GetData method:

   public string GetSilverlightString()

   {

       return "Hello WCF!";

   }

3. in the service interface, IService1.cs, paste the following above the GetData contract:
   
   [OperationContract]

   string GetSilverlightString();

4. Rename IService1 to "IHelloService" and rename Service1 to "HelloService" - use right click, rename. Also rename the .cs files in the solution.
5. Build the WCF project and right click, then click View in Browser. You'll then be taken to the Directory listing page. Click on HelloService.svc, and then copy the address URL.
   
   
   
   
6. With our HelloService built and ready to test, we can now add a reference to our Silverlight project. Go back to the Silverlight project and right click References, and choose Add Service Reference. Then, Paste the URL of the HelloService service and click Go. Lastly, click HelloService under Services, change the Namespace to HelloService, and lastly click Ok:
   
   
   
7. With our service reference in place, we can now invoke the service in our Silverlight application. Go back to your MainPage.xaml, and just before the end of the constructor paste the following code to invoke the service:

   HelloService.HelloServiceClient hs = new HelloService.HelloServiceClient();

   hs.GetSilverlightStringCompleted += new EventHandler
        <HelloService.GetSilverlightStringCompletedEventArgs>(hs_GetSilverlightStringCompleted);

   hs.GetSilverlightStringAsync();

   
   This code instantiates the service, and sets up another asynchronous call by registering the Completed method. Then, we call the Get-Async method to invoke the service, and thereafter our "hs_GetSilverlightStringCompleted" method is called with the result of the call. All the following method to update our TextBox text with the result of our service call:

   void hs_GetSilverlightStringCompleted(
       object sender, HelloService.GetSilverlightStringCompletedEventArgs e)

   {

       Dispatcher.BeginInvoke(() =>

           {

               Text.Text = e.Result;

           });

   }

    

8. TEST! Build your Silverlight app and update your XAP (either by overriding XAP in document library, or by deploying as described in section 6 of this article). After you update your XAP you'll see that your Silverlight web part is now... BROKEN!
   
   
   

   Webpage error details

   User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET4.0C; .NET4.0E; .NET CLR 3.5.30729; .NET CLR 3.0.30729)
   Timestamp: Sat, 22 Jan 2011 01:56:59 UTC

   
   Message: Unhandled Error in Silverlight Application An exception occurred during the operation, making the result invalid.  Check InnerException for exception details.   at System.ComponentModel.AsyncCompletedEventArgs.RaiseExceptionIfNecessary()
      at HelloWorldSilverlightApp.HelloService.GetSilverlightStringCompletedEventArgs.get_Result()
      at HelloWorldSilverlightApp.MainPage.<>c__DisplayClass2.<hs_GetSilverlightStringCompleted>b__1()
   Line: 1
   Char: 1
   Code: 0
   URI: http://dev.farm.com/default.aspx

   
   SO WHAT GIVES????? The problem is with cross-domain access. You see, Silverlight applications can only access resources in their current domain, eg, if your SharePoint site's URL is http://intranet, but your WCF service is on http://extranet, you'll get this annoying "making the result invalid" error. The there's a easy fix! What you can do is tell your WCF service to ALLOW cross domain access! To do this you  drop a clientaccesspolicy.xml file at the root of your WCF service directory. This xml file specifies what domains are allowed to connect to the service. If you use a "*" asterisk, all domains are allowed. Note - this is a huge topic, that I can't do justice in this article, so I recommend reading up on Network Security Restrictions in Silverlight, as well as Making a Service Available across Domain Boundaries.

9. So then to get past this error, our last step is to create our clientaccesspolicy.xml file. In Visual Studio, inside your WCF project, add a new XML file titled clientaccesspolicy.xml and paste in the following xml:

   <?xml version="1.0" encoding="utf-8"?>

   <access-policy>

     <cross-domain-access>

       <policy>

         <allow-from http-request-headers="SOAPAction">

           <domain uri="*"/>

         </allow-from>

         <grant-to>

           <resource path="/" include-subpaths="true"/>

         </grant-to>

       </policy>

     </cross-domain-access>

   </access-policy>

    

10. Now with this policy in place, simply go back to your Silverlight web part and refresh... and presto!!!!
    
    
     

4) Deploying a Silverlight Web part for a Sandboxed Solution via a Feature

To be perfectly fair - up until this point you've been working out of a document library with the out-of-the-box Silverlight viewer web part, which is fine. However, not all your web parts are going to be Silverlight web parts. You'll likely have standard .NET web parts along side Silverlight web parts. Why deploy them in 2 different ways? Let's consolidate by having one standard approach. Plus - you'll see in section 7 this deployment approach is very much a necessity.

So to summarize, you're going to create a new SHAREPOINT project. Along side that project, you'll going to create a new Silverlight project in the same solution. In the SharePoint project you'll create a feature that deploys the XAP file into a gallery, and instead of the out-of-the-box Silverlight reader web part, you'll going to create our own reader so end users won't have to bother with the URL property - simply drag-n-drop the web part!

Much cleaner approach, huh? I think so...

1. To get started, create a new Visual Studio project titled Contoso.SharePoint.WebParts, and leave the project as a Sandboxed Solution when prompted. With this selection, when we deploy the WSP package will be deployed to our site collection's solutions gallery, rather than the farm gallery in Central Administration.
2. Straight away, add a second project in the same solution. User the Silverlight Application template like before. Name the project Contoso.SharePoint.PictureApp.
3. Now - to keep things simple and since in section 1 I already went through a lengthy example, I'm just going to replace the Grid in the MainPage.xaml with a Image:

   <Image x:Name="CatPic" Source="http://www.katzy.dsl.pipex.com/LOLCats/lolcat-i-question-the-general-assumption-that-feli1.jpg" />

4. The next thing to do is get the XAP file generated in this project deployed by our SharePoint project. To do this we need a feature and a model. On the SharePoint project, right click the Feature folder and choose Add Feature. Then, right click the project and click Add->New Item, select the SharePoint tab, and select Module. Name the Module PictureAppXAP:
   
   
5. The next "trick" we need to do is tell the module to include the output of the Silverlight project. Right click the Module, and select Properties, and then click on the Project Output References collection property. This will load a popup. Click the Add button to add a new reference and change the reference project to be your Silverlight project. Lastly, change the Deployment Type to be ElementFile:
   
   
   
   
   Credit: I first saw this tip on Andrew Connell's blog.
   
   After you click OK, your module will have a new File in its XML. You'll want to change the URL property of the file to the URL of a Document library that the XAP file should be deployed into, for example:

   <?xml version="1.0" encoding="utf-8"?>

   <Elements xmlns="http://schemas.microsoft.com/sharepoint/">

     <Module Name="PictureAppXAP">

       <File Path="PictureAppXAP\Contoso.SharePoint.PictureApp.xap" 
            Url="Documents/Contoso.SharePoint.PictureApp.xap" />

     </Module>

   </Elements>
   
    

6. Before we go too far, let's test our deployment. Right click the SharePoint project and click Deploy. Then, go to your SharePoint site and check the library and ensure the XAP file was deployed on your behalf. Alternatively, you can build the project, and then right click and click Package. This will generate the WSP which can be uploaded to the solution gallery manually, and thereafter you can manually activate the feature.
   
   Note - Sandboxed solutions must be enabled in Central Admin. If you get the following error, from Central Admin, services on server, start the "Microsoft SharePoint Foundation Sandboxed Code Service":
   
   Error occurred in deployment step 'Activate Features': Cannot start service SPUserCodeV4 on computer 'DEV01'
7. With our XAP getting deployed properly, it's now time to create a standard web part to render the Silverlight application. This will allow our users to simply drop the web part on the page, without having to worry about entering the XAP URL. To get started, right click the SharePoint project and choose Add->New Item->Web Part (not Visual WP) and name it PictureAppWebPart.
8. Within CreateChildControls of the new web part, add the following code to render the Silverlight application (make sure to update the URL to the XAP):

   StringBuilder o = new StringBuilder();

   o.Append("<object data=\"data:application/x-silverlight-2,\" 
                     type=\"application/x-silverlight-2\" width=\"100%\" height=\"100%\">")

       .Append("<param name=\"source\" value=\"/Documents/Contoso.SharePoint.PictureApp.xap\" />")

       .Append("<param name=\"background\" value=\"white\" />")

       .Append("<param name=\"minRuntimeVersion\" value=\"4.0.50826.0\" />")

       .Append("<param name=\"autoUpgrade\" value=\"true\" />")

       .Append("<a href=\http://go.microsoft.com/fwlink/?LinkID=149156&v=4.0.50826.0\ 
                        style=\"text-decoration: none\">")

       .Append("    <img src=\http://go.microsoft.com/fwlink/?LinkId=161376\ 
                        alt=\"Get Microsoft Silverlight\" style=\"border-style: none\" />")

       .Append("</a>")

   .Append("</object>")

   .Append("<iframe id=\"_sl_historyFrame\" 
                 style=\"visibility: hidden; height: 0px; width: 0px; border: 0px\"></iframe>");

   Controls.Add(new LiteralControl(o.ToString()));
   
   note - This code is a bit ugly, but since we're in a sandboxed solution we can't use the Visual Web Part, otherwise it would've been slick to stick this HTML into the ASCX.

9.  That should be it! Deploy your project again, and that will deploy the new web part into the sandboxed solution. Then, drop the web part on the page and you should see you Silverlight Image app!

 

5) Debugging a Silverlight Web Part in SharePoint

Debugging a Silverlight app is pretty straight forward - when SharePoint isn't in the equation. Before you deploy to SharePoint, try to do as much debugging as possible in the Silverlight project, because it is easy to set a breakpoint and hit F5.

 

When you get into the context of SharePoint you'll need to do a few more things. First off, you MUST deploy your XAP via a feature, thus following the steps outlined in section 4 of this article. Also a must - your breakpoints will never hit until you tell your SharePoint project to debug Silverlight. Right click your project and click the SharePoint tab. Then at the bottom check the Enable Silverlight debugging checkbox:




Now, simply open your SharePoint site to the page that has you Silverlight application on it. Then, click Attach to Process... and select your browser's process. Make sure to select the one with the Type of Silverlight, x86:

 

That's It!

 

6) A Faster Option: Piggyback on the HTML Bridge

 

Silverlight can be chatty. When a browser does a GET, the server then POSTs the page back to be rendered. It's at this point that Silverlight loads, after the first round trip to the server and back. This is also the point when Silverlight calls your custom code, such as invoking a service or using the Client Object Model. When your Silverlight app runs this custom code it is taking a second round trip to the server. These subsequent round trips is an areas we you may able to be more efficient.

The basic strategy is to build a standard .NET web part that sticks the data that the Silverlight web part needs on the page in hidden fields. Then, the Silverlight app can access the page's DOM and retrieve the data off the page, and skip the trip to the server. This is what's called the "HTML Bridge", or piggyback. More generally, you can do some of the following things (among others) on the bridge:

• Access DOM from SL
• Call JS from SL
• Call Silverlight code from JS
• Send and receive types from JS/SL

This is a significant topic and I recommend reading this MSDN article for further study. However, that article is kind of an abyss of information, so my goal in this section is to demonstrate the most common scenario of accessing the DOM from a Silverlight app. What we're going to do is create a standard web part that renders a hidden field which stores a url to an image. This URL is pulled from a SharePoint List. Then, our Silverlight app will look for this hidden field, rather than do a round trip to the server to lookup the URL from the SharePoint list... aka one less round trip and a faster load time.

In section 4 of this article you built a Silverlight web part that was deployed via a feature. This silverlight app simply rendered a Image of a cat. Instead of hardcoding the image url, let's stick the url in a hidden field and change the web part to look at the hidden field. To render the hidden field, paste the following code at the end of CreateChildControls:

SPWeb web = SPContext.Current.Web;

SPList list = web.Lists["CatPics"];
SPListItem item = list.GetItemById(1);

 

string imageurl = item["Title"].ToString();

o = new StringBuilder();

o.Append("<input type=\"hidden\" id=\"SharePointData\" value=\"" + imageurl + "\" />");

 

Controls.Add(new LiteralControl(o.ToString()));

This code simply reads a SharePoint list and pulls the url out of a title column in the first list item. Then, it sticks that url in a hidden field, which is rendered via a LiteralControl.

The next step is to change the Silverlight app that was created in section 4 to use this url in the hidden field, from the hard coded url in the Image Silverlight control. In the PictureApp project, go to the code view of the MainPage.xaml and paste the following code into the Initialize method:

HtmlDocument doc = HtmlPage.Document;
HtmlElement field = doc.GetElementById("SharePointData");
string source = field.GetProperty("value") as string;
CatPic.Source = new BitmapImage(new Uri(source, UriKind.Absolute));

This code uses a HtmlDocument object to access the Silverlight's page's DOM to grab the hidden field called "SharePointData". The value of the hidden field is then retrieved, and the Image source property is updated, thus updating the UI.

So you can see that this process of HTML Bridging is very easy, and is a great way to make your Silverlight applications perform faster.

Hello World Silverlight Web Part – Part 2 (Animations)

A little bit ago I wrote a post on how to create a "Hello World" Silveright web part and deploy it into SharePoint. Well since then I gave a presentation at a SharePoint Saturday event on the subject, but I added a few more "zingers" into the mix to make it a bit more interesting. Firstly, I added a transform onto the text to make it spin on its axis, and secondly I added a DoubleAnimation to make the opacity of the text fade in and out, forever. Read along if you're curious on how to implement these fundamental Silverlight techniques.

 

 

Prerequisite: Start by working through the steps in this post: http://blog.philwicklund.com/fff/2008/05/hello-world-silverlight-web-part-for-sharepoint-introduction-to-silverlight-development.html, to learn the first steps on creating a basic Silverlight application. Then, after you've created the new visual studio project and built the Hello World app that looks as below, proceed through the rest of the steps found within this post…

 

 

(note: if you don't see the "Silverlight" project, go here [http://tinyurl.com/4nrb44] to download the extensions for Visual Studio 2008 SP1)

 

Step 3.1: Adding a Silverlight RenderTransform to make the text spin

 

Add a UserControl.Resources tag into the Page.xaml file, containing a double animation to make the "Hello World" text spin 360 degrees:

 

<UserControl.Resources>

    <Storyboard x:Name="homeboard">

        <DoubleAnimation

            Storyboard.TargetName="spin"

            Storyboard.TargetProperty="Angle"

            From="0" To="360" Duration="0:0:5"

            RepeatBehavior="Forever" />

    </Storyboard>

</UserControl.Resources>

 

This Storyboard contains a DoubleAnimation that will make the text block spin from 0 degrees to 360 and will continually repeat every 5 seconds (duration). Now, the spinning won't start yet until the Storyboard is initiated. What we need to do is call the "Begin" method on the homeboard storyboard object. To do that, let's wire up an onclick event, so when the user clicks on the text, we'll handle the click event and call begin to initiate the spinning.

 

In the properties of the TextBox, add "MouseLeftButtonDown="StartAnimation"" and theTextBlock.RenderTransform:

 

<TextBlock

    x:Name="Text"

    Text="Hello World!"

    FontSize="50"

    FontFamily="Georgia"

    FontStyle="Italic"

    FontWeight="Bold"

    FontStretch="Expanded"

    VerticalAlignment="Center"

    TextAlignment="Center"

    MouseLeftButtonDown="StartAnimation">

    <TextBlock.Foreground>

        <LinearGradientBrush>

            <GradientStop Color="Red" Offset="0.0" />

            <GradientStop Color="Yellow" Offset="1.0" />

        </LinearGradientBrush>

    </TextBlock.Foreground>

    <TextBlock.RenderTransform>

        <RotateTransform x:Name="spin" Angle="0" CenterX="200" CenterY="50" />

    </TextBlock.RenderTransform>

</TextBlock>

 

The MouseLeftButtonDown will "hook up" an event handler into our code behind so when the user clicks the text, the Storyboard will initiate. Go into your Page.xaml.cs file and paste in the following method:

 

 

private void StartAnimation(object sender, MouseEventArgs e)

{

    homeboard.Begin();

}

 

Notice the RenderTransform. This ties the TextBlock to the Storyboard. The DoubleAnimation's Storyboard.TargetName property is set to this RenderTranform which has the coordinates (x,y) specified which is the axis the rotation revolves around.

 

Retest your application (right click the aspx page, and do "view in browser"), and thereafter you can click the text it will be spinning!

 

Step 3.2: Making the text fade in and out

 

To make the text fade in and out, we want to add another DoubleAnimation into our story board, but this time lets use the DoubleAnimationUserKeyFrames object to specify precise times to fade in and out. Paste the following into the story board:

 

<DoubleAnimationUsingKeyFrames Storyboard.TargetName="Text" RepeatBehavior="Forever"Storyboard.TargetProperty="(Opacity)" BeginTime="00:00:00">

    <SplineDoubleKeyFrame KeyTime="00:00:01.0000000" Value="0"/>

    <SplineDoubleKeyFrame KeyTime="00:00:02.0000000" Value="1"/>

</DoubleAnimationUsingKeyFrames>

 

Notice the Storyboard.TargetProperty="(Opacity)", this DoubleAnimation is going to be effecting the Opacity of the TextBlock. The AplineDoubleKeyFrame elements within the DoubleAnimation specify two milestones in time. The first milestone is at one second, in which case the TextBlock will have disappeared (opacity equals 0). By the second milestone ending at the second second, the TextBlock will have reappeared (opacity equals 2).

 

Pretty simple – below is my visual studio project if you want to see the source code…

 

Phil

   

Best Practices for Branding SharePoint 2007(Part 6 of 6)

It's been many months since my last branding post back in June, so I figured I ought to renew my efforts to get this 6 part series published. I left off with best practice number 6, which I will now reveal is "Use SharePoint Solution Packages to enforce consistency across all the web front ends in the farm".

 

Now, I'm not going to beat the horse dead on this point because this is a highly documented feature within SharePoint, both the why and the how-to. But I will say that Solutions MUST be in a top 10 branding best practice list!

 

In an average SharePoint engagement where I'm doing some UI customizations, I'd say I end up deploying around 50+ files into the 12 hive. Without solution packages, you're forced to manually copy/paste those files which opens yourself up to mistakes and inconsistencies. Understanding how to use solutions is a MUST for any SharePoint developer.

 

Phil

Consolidating Master Pages Customized By SP Designer

<update 9/11/08>

 

Corro'll Driskell posted a counter post to my "SharePoint Designer Blues" that I feel is a good read. I admit my disdain for Designer in this post is too sweeping, and isn't even a holistic expression of my views on Designer, which are much warmer than I made them out to be. Anyways, check out his post at:

 

http://mindsharpblogs.com/Driskell/archive/2008/09/11/8427.aspx

 

Be sure to check out my comments to his post that clarified my original hastiness. Enticing dialog at its best 

 

</update>

 

I hate Designer for SharePoint Master page development. My biggest issue is that after you start customizing master pages with Designer, 6-12 months later you realize you have a huge mess on your hands. You end up maintaining hundreds of copies of the same file. Say you need to make a minor change to a master page, you'd have to go back and crack open every site, one at a time. This could take hours. Also, you may not even know the places that need the change, or you think you changed them all, but turns out you missed some. Designer means inconsistency and costliness in the long run.

 

So, off the soap box, what if you're down this road and want to get back to a better practice? Here are the steps:

 

BUILD & INSTALL A MASTER PAGE FEATURE

 

The key to consolidating your master pages is to have one page on the file system (12 Hive) that is the central page for all sites everywhere that need the master page. The best approach to this is to use a feature that you can activate on the sites that need the master page. Paul Stork (MVP) has a great article on how to build this feature.

 

Download a master page from one of the SharePoint sites that has the latest code for you to use as the template within the feature.

 

REVERT TO SITE DEFINITION AND ACTIVATE FEATURE

 

Under site settings look and feel, click reset to site definition. This will disregard all your SharePoint Designer changes. Thereafter, active the feature to start using the customized master page again. Repeat this step on every site that you want to use the central copy of the master page on the file system.

 

Now all your sites that have that feature activated will be using ONE copy of your code. Edit that master page ONCE, and that change will get propagated EVERWHERE! This will save you a lot of time and money in the long run!

 

DISABLE DESIGNER SO THE MISTAKE WON'T HAPPEN AGAIN

 

This step is optional, but highly recommended. Designer can be suicide for your power users, because they can easily break your sites and cause inconsistency in your farm. If you want to be certain your sites are using YOUR master page, and won't get customized by someone not in IT, you should consider this step. The only downfall is that you won't be able to build workflows with Designer, but you should use Visual Studio for that anyways (check here if you're not convinced on how easy it is).

 

You disable designer at the site definition level. For every site type that you don't want people using designer in, you'll need to edit its ONET.XML file.

 

Inside the project tag, add the DisableWebDesignFeatures tag, and specify wdfopensite to prevent all sites using this site definition from opening them with designer:

 

 

Save the file and do an IISRESET. Repeat this process on other site definitions in your farm, and on each web front end.

 

 

Good luck!

A Picture is worth 1,000 Words: Achieving Good SharePoint Usability

One common situation I see with many clients I interact with is that their SharePoint sites are loaded down with wordiness. It's my opinion that sites that are overly wordy can kill usability fast, and it seems to me that SharePoint lends itself easily to be an extremely wordy application. This to me is the biggest issue that faces the SharePoint user interface (UI). Why don't people like SharePoint's UI? Too Wordy!

 

When you start dragging those ListViewWebParts on your pages, you quickly become a very textual site. For example, a few months ago I wrote a blog post about implementing a better Announcements web part because the one that comes out of box is SOOOO wordy and takes up a ton of real estate. See below:

 

Out of box look and feel:

 

Customized Look and Feel:

 

I think the difference is striking. The out of box one is so wordy, you don't know where to start, whereas the bottom is clear and articulate, allowing for the user to quickly scan through the information. Most of the out of box SharePoint web parts are overly wordy like this in my opinion, that is why I suggest you don't clutter your pages with too many web parts! This is especially true for things like calendars, documents, and discussion boards. As soon as you start dropping those on the page, end users are lost in a wordy mess and will have a harder time finding information. The trick is that you NEED to make it EASY for them to find stuff.

 

Instead, I suggest a approach that leverages the left navigation to drive users to content, especially for calendars, documents, and discussion boards and other built in lists/libraries. Those three especially should never be on main landing pages. Rather, link the user straight to the library or list itself. The user is less likely to glaze over information because there's only one type of information on the page and that makes it easier to know what they are looking at.

 

Another big area that people need to pay attention to is using graphics, not words, to drive users to the main areas of the site. Like I said earlier, people glaze over text and it is rarely ever even read! So don't rely on it! However, people's eyes connect well with graphics, which draw their attention much more easily. Use graphics, not words to drive navigation and highlight main areas/features of your sites.

 

The image below features a site I put together for a company (logo and name of company removed) that uses graphics to help drive end users to the main areas of the site. Rather than cram a ton of info on one page, I'm using the left nav to link to all the activities and content, as well as using graphics in the main area to call out "featured activities". This is a much more usable approach because users are drawn to the graphics to tell them what they can do, and are not bogged down with a wordy page that they won't read (in which case they'll feel lost and get mad).

 

(click image for full size)

 

With just a few seconds of looking, a user can quickly identify the value of the site and what they can do with it. If you have an overly wordy and overly crowded SharePoint site, it won't be used or adopted, and it will leave a bad taste in your end user's mouths. This is because they can't quickly find what they want and they give up. Do you remember what first attracted people to Google, amidst notable competition? Less is more.

 

I believe the same is true for your SharePoint sites. However, that is "just my 2 cents" .

 

Phil

Using Delegate Controls to Implement Minor Brand Variations in SharePoint

The Problem

 

A problem that I have often seen in the SharePoint world is the common request to have a consistent brand across your entire farm, but therein it is required to have minor variations of that brand for various sites within the farm. A frequent use case for this is the banner image/logo. Maybe the main landing page for the intranet has a certain logo, but as you start drilling into the sub-sites, the logo should change (or other brand variations). Logos for different departments like IT, HR, Sales, etc. are often requested. Now, typically inside the master page would the HTML image tags for these logos be found, however, it can be extremely cumbersome to maintain multiple instances of a given master page, especially when the differences between these master pages is small. Also, you as the developer may not know when when/where these variations need to be implemented, thus you need something intuitive for end users to be able to customize the look and feel of these sites. So what other options are available to you when you need these small brand variations in your SharePoint sites?

 

The Solution

 

A good solution for this is the use of delegate controls. You can place these controls within your master page, and at design time (via activating/deactivating features), replace them with actual controls that live in the LAYOUTS directory. What will be demonstrated in this post is using a feature to toggle the banner image on the SharePoint Site. Other use cases I've seen for using delegate controls are:

 

• Placing code on a page to do something (see my Site Creation Workflow).
• Wrapping the top navigation with a delegate control to replace the current web's navigation with some custom navigation at design time.
• Replacing the out of box bread crumb with a custom bread crumbing system.
• Changing the layout on a web part page after instantiation.
• Adding/removing meta tags on the page for search result tweaking (google, live, etc.).
• Many more good uses…

 

Note: the example being displayed in this walkthrough is the ability to change the logo on different sites, however, it should be known that this can be done out of box through site setting. The reason for my choice of this particular example was that the logo for a given client I was working at was not sized well to fit into the out of box mechanism to change the logo (the logo was too long). Either way, this example serves to demonstrate the concept of maintaining small brand variations, which can be of any kind of sort.

 

The "How"

 

On the master page of a SharePoint site, there is a content place holder called "PlaceHolderSiteName". This place holder contains the logo and site name for all SharePoint sites. Within that place holder I removed all the contents and replaced them with a delegate control:

 

 

I actually left the SPLinkButton because I still wanted the user to be navigated to the home page when the click the banner. Also, you'll notice I removed the site name, because the image itself served to communicate that.

 

Anyways… within that content place holder is now a delegate control that you can start dumping controls (.ascx files) into at design time (via a feature demonstrated shortly).

 

In my visual studio project, I built out four features and four control templates, one for each banner image that I may want to rotate between on my SharePoint sites:

 

 

Inside the elements of each feature, I have a control element. The ID of the control element corresponds to the ID of the delegate control on the master page. Therefore, when this feature is activated, it will take in this case the CustomerBanner.ascx control and dump it into the "Banner" delegate control on the master page:

 

 

The code for the CustomerBanner.ascx control itself if trivial:

 

 

When all four features are installed and activated, and the controls are deployed into CONTROLTEMPLATES, you'll see the logos available to be toggled within site features:

 

 

When one of these features is active, the site will show the corresponding logo! Pretty neat if you ask me!

 

Phil

Best Practices for Branding SharePoint 2007 (parts 4 & 5 of 6)

My next two best practices that are a part of my 106 part series, are going to be combined in one post because they are closely related. What's more is that I've already blogged about them, so it doesn't make sense to labor over something twice.

 

These two best practices are detailed out in my post titled:

 

How to Effectively Manage your "12 Hive" SharePoint Customizations and Deployments (Part 1 of 2): Keeping your Developers Honest and your Investment Secure with Source Safe

 

In that post, I discuss the prevalent bad practice of editing SharePoint's files directly within the 12 Hive. Bad! Bad! Bad! Don't do it! If you do, you'll run into all kinds of issues like your customizations don't get backed up regularly, your developer's are overwriting each other's changes, and inconsistency and incomplete deployments across your web front ends. These issues are especially significant if you have a large team.

 

 

 

 

 

 

If you read through that post, you're certain identify two best practices therein. One, never make changes directly to the 12 Hive on the file system, and two, make sure all 12 Hive customizations are in source control in a way that requires developers to use it.

 

 

 

 

 

Phil

Best Practices for Branding SharePoint 2007 (Part 3 of 6)

This next best practice in my top 6 list is definitely a matter of opinion on my part. The best practice revolves around SharePoint themes, and my inability to understand how they can be a benefit to someone. The reason why I struggle to see the value with themes is that every company that I have ever consulted for has always wanted to have their brand consistently applied throughout their entire farm. In their case, themes propose a problem because any end user that has full control anywhere can apply a theme on their site and in effect mess with the company's brand. Now I am fully aware that not all companies, especially small ones, are always terribly nit-picky about their brand. However, I do feel confident that from what I've seen, most are. Most companies desire a consistent and professional experience for their end users. I'm not a usability expert by any means, but my guess is that variations in the look and feel on an intranet cause more confusion than it does excitement and pleasure. Whenever I bring up the concept of themes to various organizations they all almost unanimously ask how to disable them even before I can tell them that it is even an option.

 

Themes as the Vehicle to branding SharePoint Sites

Who of you out there in SharePoint land actually utilize themes as the vehicle to brand your sites? I don't know of many that do, and I have tried myself but I found it too cumbersome. I've always fell back to customizing a master page, rather than building a custom theme. To me, editing a Master page and using a custom CSS file (through setting the AlternateCssUrl property on a web) seems to work really well and is really intuitive. However, I am open to feedback on the strengths of themes if anyone has any to offer. I suppose the obvious strength is that if you have a business requirement to have your end users be able to apply a customized "themes", going with themes is the most natural inclination. However, you can still do that with features as I discussed in my second best practice.

 

Conclusion

That being said, if you utilize themeing as your branding vehicle, you're still stuck with the problem that end users can change your theme. Therefore, my third of ten best practices is that if consistency is important; don't let end users toggle the themes on their SharePoint sites.

 

The "How"

Because this is a short post, and the "how" is relatively trivial, I figured I should include the steps on how to disable your end user from changing the themes on your sites.

 

• Within SharePoint Central Administration, under the Application Management tab, clickUser permissions for Web application within the Application Security Group:
  
• Scroll down until you see the Site Permission group of permission levels. Uncheck Apply Themes and Borders.
  
• Click OK. Thereafter, nowhere in that web application can anyone apply a theme. If you have multiple web applications, you'll need to run through this process for each.

 

Phil

Best Practices for Branding SharePoint 2007 (Part 2 of 6)

In the last post of mine, I discussed certain implications that come with using SharePoint Designer to brand your SharePoint sites. This post will discuss the prefered alternative to SharePoint Designer, building custom site definitions. However, I must start by saying that this philosphophy is by no means a SharePoint standard. Andrew Connell, who's probably one of the most well-known and respected SharePiont MVP's ever, begs to differ. Check out this powerful comment on one of his blog posts:

"I still do everything I can to avoid creating site definitions. They are too big and cumbersome making it hard to debug when problems arise. Most importantly, they are very inflexible; once one a site has been created off a site definition, it should never be directly changed." – Andrew Connell

 

That's a very strong statement indeed! And coming from an MVP causes a peon such as myself (notice descriptive image to the right) to consider it carefully. However, with that said, my question still lingers. How can you enforce a custom brand across your entire farm, including all web applications, site collections, and sites (or conversely, cherry picking large sub-sets of those)without editing Microsoft's pages? I see custom site definitions as the easiest approach to this question for the following reasons:

 

1. As I mentioned in my first post, SharePoint Designer can only scope a brand across one and only one site collection, not many site collections and/or web applications.
2. All SharePoint sites by default inherit from one master page, Default.master in the GLOBAL site definition. It is NOT a best practice to edit this page because you run the risk of service packs overriding it, and you lose your warranty with Product Support. Therefore, a better approach is to create a copy of this page and use your own, but how do you assign ALL the webs across a broad scope to use this copy?

 

There are ways to programmatically set a master page. Maybe you have a feature that when activated, deploys a master page to the master page gallery, and thereafter sets the MasterUrl property of the Web to be that of that new master page (Paul Stork has a good example of this). But what if you have thousands of Webs? You certainly don't want to manually go to each one. You could write another feature or console application that crawls your entire farm and sets the property to be that of your custom master page, but again, what about new sites? I suppose a combination of both those two solutions would do. But that seems like a lot of work, and if you're not a developer, an impossibility (this would be a good Codeplex download, anyone?).

 

The Benefits to Site Definitions

 

Here's the bottom line with Site Definitions. When it comes to branding, there's not many better ways to do it. Much like when you edit the Default.master page in the GLOBAL site definition, any changes to your master page that is specified in your custom site definition will propagate to all sites everywhere that use it. You have the power to know for certain that all your sites are consistent, because all your sites use one master page, not copies that are strewn about the database. That, and you won't need to void your warranty.

 

Therefore, even know it may be controversial, I will conclude nevertheless with stating my second of ten best practices: Build custom Site Definitions if you need to enforce a custom brand across your entire farm. It is very likely that Andrew wasn't thinking along these lines when he wrote that post, because to be honest, I fundamentally agree with his premise. I just don't see a silver bullet with this issue. To me, the benefits to site definitions seem to tip the scales as they say… thoughts?

If all this went over your head, in my upcoming whitepaper I plan on documenting how to build site definitions from scratch that utilize a custom master page (in 10 easy steps naturally). So stay tuned!

 

<update 06-11-08>

After thinking through this post and receiving some feedback, I have come to see the light in Andrew's concept. I see now how using features to enforce a brand across an entire farm is possible and even the preferable option over creating a custom site definition. Just as I mentioned above how there are programmatic options through feature stapling, if you have the wherewithal it is the most dependable option. Here's those options restated:

 

First, I would implement Park Stork's example as I mentioned earlier, and have that feature auto-activate upon creation of each site. You would have to edit all the SharePoint site definitions and include that feature as one that is by default activated when the site is created (this is what I failed to see earlier). If you do this, every site everywhere that is created will use your custom mater page, and thus your brand will be maintained. Now for sites that have already been provisioned, I would write another feature scoped at the web application, that when activated would crawl the entire web application and any webs that are not using my custom master page, the program would set them to use it. With the combination of these two features, you can account for all new and old sites in your farm.

 

Now if you're not a strong developer, this may still not be the best approach for you, however, I will still agree that it is the preferred practice than creating a custom site definition. Thus, I will restate my second best practice as follows: Use a custom master page deployed via a feature on all your sites to extend your company's brand across an entire farm.

</update>

 

Thanks ALL!!! I look forward to your feedback.

 

Phil

Best Practices for Branding SharePoint 2007 (Part 1 of 6)

This series of posts is border line ridiculously long, but I hope it is a fruitful endeavor nevertheless. In my vast journey's around the great world of SharePoint, I have drawn many conclusions on what is good to do and what is not so good regarding SharePoint branding. I started documenting my thoughts in what will become a whitepaper on the subject, but it became clear to me early on that the whitepaper will be quite lengthy, and since I still have a day job, I figured it best to break it up into a series of posts with the paper serving as a supplemental and combined read when it is finished. My goal in this series is to outline the best practices and major concepts, the "what" when it comes to branding, and to outline the "how" and detailed steps in the whitepaper that will follow. Hopefully I will have the 6 posts done within the next 4 weeks (among posts on other subjects I plan on doing), with the whitepaper to follow 2 weeks thereafter.

Additionally, my desire is that these posts will generate feedback, enough so that the community can help shape the outcome and depth of the top 6 list. I will also use such feedback to help shape the contents of the whitepaper. Feel free to leave a comment if you want to contribute or raise concerns around my conclusions. Also – be sure to check out Bill & Ben's new book on SharePoint best practices, that book is sure to be a hot seller.

Branding SharePoint Best Practice #1:

The very first tool that comes to most people's minds when it comes to SharePoint branding is SharePoint designer. SharePoint designer is a power tool that interfaces directly with SharePoint sites, and enables you to customize the look and feel of those sites even without writing code. However, there are some special considerations that need to be taken into account regarding Designer, and in many cases if the implementation of this tool is not thought through, undue hassle can easily arise.

The main issue with Designer is also its greatest strength. The phrase "Wild, wild, west" helps translate the issue, in that the ease of use that the tool brings to the table can lead to an uncontrolled and inconsistent environment. The purpose behind the tool is to give SharePoint end users the ability to do things that typically only developers can do, which is good, but it also makes the environment feel like a "sandbox". The information technology department spends thousands building a brand for the home page, but as you drill lower, that brand starts to dematerialize. Some sites are pink, and some are blue. Some are even broken entirely because a user didn't know quite enough to not delete a particular control. The key here is brand consistency. With Designer enabled it is impossible to force brand consistency across an entire farm, because of its prevalence to end users. Designer is a powerful tool, but with anything, power is only a good thing in the right hands.

The solution to this isn't just to not give Designer to the masses, because any ambitious soul could pick it up from their favorite software retailer and they would be off to the races on any SharePoint site they have full control on. A better option is to disable the use of designer across your sites entirely. You can do this by making changes to the 12 Hive file system on each web front end in the farm (See appendix A for more details in my upcoming whitepaper). However, this isn't right for everyone. One reason you like Designer is its workflow capabilities. A savvy end user can build workflows themselves, saving the IT department valuable resources. If you disabled designer, end users won't have access to this workflow functionality. Also, designer can maintain brand consistency across any given site collection. If a given brand is only going to be applied onto one site collection, all sites within that collection can be made to use that brand (See appendix B in my upcoming whitepaper on how to configure this). In that case, Designer can be a helpful tool. However, most companies have hundreds, if not thousands of site collections, which raises this consistency concern. If you're a developer and you need to change a logo, you're not going to want to edit one thousand copies of a master page. This in turn leads to the drawing of the first of ten best practices for branding SharePoint sites, to only use Designer to brand sites when the scope of the customizations will never need to grow beyond a single site collection. That and to disable it all together if possible.

The recommended alternative to using SharePoint designer to brand sites is to build custom site definitions that are controlled and maintained by a SharePoint team within IT. The next post in this series will discuss this concept in detail.