The Customizing the User Experience of SharePoint series aims to explain how the user experience works, from how the interface is built down to details on how columns in lists get created.

The series is also an exclusive preview of the topics from my upcoming book, “Building the SharePoint User Experience”, which deals with SharePoint user experience for 350 pages. Actually, as with this series, the book explains the SharePoint architecture from a user experience perspective.

Here is an article outline for the six parts:

Part 1: Overview of the default SharePoint interface from a technical point of view

In the first article we will look at how the default SharePoint interface is built. We will look at a site, going from top-down, explore some of the the default lists, the fields used to create the basic field types, which content types are available, and how list forms are rendered.

Part 2: Modifying the default experience

This article will show you which options are available for you to modify and improve the default setup. Learn how to override the default rendering of fields or forms without voiding your supported state.

Part 3: Lists and custom list forms

The third article will cover the basics of customizing lists using different views, custom list forms, and fields.

Part 4: Content types user interface

The next article will explore how you can utilize content types to display different input forms and display forms.

Part 5: Custom fields deep dive

Ever wanted to create a new field type? SharePoint enables you to do this and it is a very powerful tool for customizing the user experience.

Part 6: Fast track to feature generation

Writing custom lists with content types by hand can take a massive amount of time. In the final installment I will share with you some tools and techniques that makes list, field, and content type generation very fast.

And that is exactly what we’re going to cover today. We’ll explore how you can speed up development time using some simple tools and techniques that are freely available. So let’s get down to business, shall we?

Tools of the trade

Being an efficient developer is not about having the most tools, but about having the right tools. More importantly, it is about learning how to apply those tools in the right fashion. I’ll give you a few tips here, tips that enable me to create features, having complex columns, content types, and list views within minutes rather than hours.

I am going to assume that you have a copy of Visual Studio that you like. VS 2005 or 2008 will do, I’ll use 2005 here to make sure we support everyone. If you don’t have Visual Studio you should get that now, the Express versions will do.

Here’s what you’ll need in addition:

WSPBuilder

WSPBuilder is the coolest little tool for SharePoint developers. The main function of WSPBuilder, as the name implies, is to build WSP file. If you don’t know, WSP files are installable solution packages for SharePoint. What you should also know is that creating these WSP files is a **** ** *** ***.

WSPBuilder makes building WSP files a lot easier for us, but its true beauty lies in an extension that you can install to Visual Studio. Doing so gives you a set of tools which we will explore in a moment. For now, get the WSPBuilder and its Visual Studio extensions from the CodePlex link above.

SharePoint Manager 2007

SharePoint Manager 2007, or SPM for short, not to be confused with SharePoint Magazine, which is also SPM for short, is a SharePoint object model browser that allows you to inspect you SharePoint installation. Not just that, but SPM allows you to perform basic manipulation of your SharePoint sites, lists, content types, and columns.

Oh, and to make SPM even more perfect, it is absolutely free. Which is true for both usages of the abbreviation.

Let’s start learning how to utilize these tools to become a SharePoint development superstar.

WSPBuilder

Once installed you should get a few new project types in Visual Studio under the WSPBuilder node. Select to create a new WSPBuilder Project and name it something you like. The name here will be the name of the solution so pick something nice

Once your project is created you will see that you get a few items in your solution explorer. Most notably, notice that you have a 12 folder. This 12 folder will map to the [12] hive when you deploy your solution later. This in itself will save you a lot of time when deploying components that are not features, such as custom application pages, images, site definitions, and custom field types.

However, for our demonstrations here we will focus on creating features. After all, this is a fast track to feature generation, right?

Your first demonstration is to create a feature with an event handler attached. Of course, feature receivers requires you to deploy an assembly to the GAC, meaning you need to strong name your assembly, which entails setting the project to be signed, creating a new signing key, and building the assembly. Then, to tie the assembly to the feature receiver you need to build the feature.xml file, reflect on that assembly to get the strong name, and get the right class name before you past all that stuff into the feature.xml file. Then you need to build your solution, deploy the assembly to the GAC before you copy all your feature files into the 12 hive. Or you could build a DDF file and create a WSP solution file, which is about as fun as watching grass grow in real-time. An this is before you create your class file and remember which assemblies to reference and which class from which to inherit.

Or, you could simply right-click your WSPBuilder project, add new item, and select Feature with Receiver from the WSPBuilder node as your item type. Select which scope your feature shuold have, and optionally give it a nice name and description, and hit Ok. In one single and short operation you have created a new feature, configured your project to be signed, which, by the way, WSPBuilder did even before you added the feature, extracted the strong name from the assembly, written the feature.xml file, created the class file which inherits from the correct class, overridden all the right methods, and created an empty, ready-to-use, just-add-water elements.xml file.

Neat, eh? Oh, you haven’t seen anything yet.

Note that, by default, WSPBuilder will create a class file that just throws an exception whenever you try to do anything with the feature in SharePoint, so your first order of business is usually to open the class file and remove the exception throwing from all four methods.

Of course, creating the feature is only the first part of the job. Next you need to actually deploy the feature. This, it is rumored, is a very complex operation, requiring you to master the art of DDF file building. With WSPBuilder, however, all you need to do is right-click your project, choose WSPBuilder->Build WSP and you suddenly have a WSP file ready to deploy. And if you can’t be bothered to actually install and deploy the solution yourself, WSPBuilder handles that for you as well, by simply giving you a Deploy menu item inside the Same WSPBuilder menu you used to build the WSP file.

You’ll also notice that you have several other options on the WSPBuilder menu as well. Upgrading and uninstalling your solution is quite a time-saver, but you can also very easily copy files to [12] or deploy your assembly to the GAC if you need to do these steps manually for some reason. Also, what really saves me time when debugging SharePoint code is the ability to quickly attach the debugger to the IIS Worker processes. I know, this is quite possible quite fast using the regular menu in Visual Studio, but I just like to have this option a bit more conveniently located.

The only thing I’m missing from this menu is IIS Reset. Some changes are not picked up by AppPool recycling alone, so Carsten, if you’re reading this, please add IIS Reset to the WSPBuilder context menu.

By the way, Carsten Keutmann is the fool that has made both WSPBuilder and SharePoint Manager. I’m saying he’s a fool, because he would rival Bill Gates in wealth if he charged you just a percent of the time you save using his products. But no, he goes around giving this away for free. Which is very honorable, but quite follish. He is a genius in writing his tools, though, so I guess he is the most foolish genius there is.

But wait! We were talking about developing features. Let’s move on.

Extracting feature CAML.

You may not know this, but most SharePoint objects, such as columns, content types, and lists, can export the CAML used the create them. To get this XML you would grab the contents of the SchemaXml property of the object using code. So, for instance, if you want to extract the XML used to define a certain column you would call SPField.SchemaXml, and for a content type SPContentType.SchemaXml.

This is very useful because it allows you to create an object, such as a column, in the web interface of SharePoint, and then extract the CAML and put it in your feature for later deployment.

And this is fine, but a little awkward because you need to write code to extract the code. Or, you can have someone create a program that makes this a lot easier.

Enter our overly generous Dane again, Carsten Keutmann. Now, know that I really love you man, in fact, I plan on naming my first two kids WSPBuilder and SharePoint Manager, but you have got to start at least taking donations for your programs. Think of the Danish economy, you would support a nation from the taxes alone!

For the rest of us, Carsten has created another nice program, the SharePoint Manager, which you should have downloaded by now. SPM allows you to browse your entire SharePoint installation and view all the properties of all the objects, which is exactly what we need. I’ll walk you through creating and deploying a custom site columns in three easy steps:

1. Start by creating a site column in any of your sites. Make it something a bit complex, such as a multi-choice column (checkboxes).
2. Using SharePoint manager, browse to your site where you created the column and open the Fields note to locate your column.
3. Copy whatever XML is in the Schema Xml tab of SPM, less the XML declaration, and paste into your elements.xml which you created earlier. Deploy and you’re done.

How much easier can you create a new column? I absolutely love SPM, and when combined with WSPBuilder, you got a killer duo that will save you hours of development time on every project.

You can do the same thing for other objects as well. However, some of the XML that you get is not deployable right off the bat. For example, for content types you need to change the Fields element to FieldRefs, as content types only contain references to fields. Doing so you also need to change all the Field elements into FieldRef elements, which also means removing a lot of illegal attributes. But still, this is incredibly much faster than writing one from scratch.

Now, another really useful object with which you can attempt this is for Views. Creating custom views in CAML can be a difficult task, as we saw in part 3 of this series. However, if you create a view on a list and you want that view added to a custom list template you can, still in SPM, go to the list where you created the view and get mostly usable XML in the Schema Xml tab. I say mostly, because there still are some things you need to do yourself. For example you will want to change the View Url to something that is list relative and not an absolute path, which is the default when you export a list’s XML, and you would also need to set the WebPartZoneId and the SetupPath, but all in all this beats writing 2500 lines of code any day.

So long and thanks for all the fish!

It’s been a long week, and a lot of hopefully useful information for you. I’m going to stop for now and just recap what we have seen in this series.

We’ve explored a SharePoint site down to a fairly low level, leaning how the architecture of SharePoint really works and how you can use that knowledge to create a user experience that is much more in tune with your needs than the default out-of-the-box experience. You’ve seen how sites are built, how lists and list templates are created, how View CAML is not really so bad after all, you’ve seen how to create custom site columns as well as learned at least that you can create your own custom field types, although we didn’t get to explore this nearly as deep as we could.

Finally, I hope this article has shown you some tips on how you can create all these things very rapidly, utilizing the SharePoint web interface and some nice free tools to speed up the development of new features.

Thanks for reading all this, and please, if you like it tell your friends about SharePoint Magazine. If you don’t like it, well, you don’t need to tell anyone.

.b

Hey, what about the bonus article?

Oh, yeah, I nearly forgot. The topic of tomorrow’s article will be DelegateControls. I mentioned these briefly earlier, but since they are so powerful I felt I needed to elaborate a bit more on their use.

Also there will be a special surprise available only to the first readers of that article. Subscribe to the SharePoint Magazine RSS Feed and you will be notified as soon as the article is out. The early bird catches the worm, you know…

This is the fourth article in a six-part series on ASP.NET Master Pages and SharePoint.

1. Introduction to Master Pages.
2. Examining the out of the box Master Pages in SharePoint.
3. Developing a custom Master Page for SharePoint.
4. Deploy a Master Page for a production ready system.
5. Customizing the Application.master Page.
6. Incorporating a Master Page into a SharePoint site definition

In the previous article of this series we discussed how to build a customized master page in SharePoint Designer. At the end of the previous article we discussed that making the modifications directly in SharePoint Designer is not the most deployable solution for production life cycle environments.

This article will discuss the other option to customize and deploy a master page for a production ready system.

Features

Features are SharePoint’s way to activate and deactivate certain code on particular site and/or site collection, within a SharePoint website. Features can contain things like – what webparts should be available, what lists should be available, what actions should be on list menus, etc…

Features can also deploy master pages to the master page gallery of a SharePoint site and/or site collection. Using a feature to deploy the master pages gives us reusable files that can be deployed to any SharePoint environment through SharePoint commands. This means that we can create build scripts to deploy our master page to a master page gallery. This is much better than the copy and paste method of SharePoint Designer we showed in the previous article.

Features contain two main files:

1. Feature.xml -When a feature is installed SharePoint looks for the feature.xml file to determine how to deploy the feature. The feature.xml file defines the feature and provides the paths to the other files involved in deploying the feature.
2. Elements Manifest – this file is referred to from the feature.xml. This is the file that determines what the feature should do when it is activated.

Features can be installed to a SharePoint environment through stsadm commands. Stsadm is the command line tool for SharePoint and is used for multiple administrative and development operations in SharePoint.

Once a feature is installed on a SharePoint machine, it can be activate or deactivated on a particular SharePoint site or site collection. Every feature.xml file contains a “Scope” attribute. If the scope of a feature is “Web”, that means that the feature can only be activated at the SharePoint site level. If the scope of a feature is “Site”, that means the feature can only be activated at the SharePoint site collection level. Site Collections contain all the sites in a SharePoint tree, thus if a feature is activated at a site collection, it is activated for all the sites in the site collection. If a feature is activated at a site, it is activated for that site only.

To activate a feature you can go to a site and/or site collection and then go to the Site Settings. In the site settings you will see a link for “Site features”. If you are on a top level site in the site collection, you will also see a link for “Site collection features”.

When you click on the “Site features” and/or “Site collection features” link you will go to the feature activation page for the site and/or site collection respectively. From this page you can activate or deactivate sites for the site and/or site collection.

Custom Master Page file

To customize a SharePoint master page with a feature, you need to create a custom master page file. This file gets uploaded to the master page gallery in SharePoint through the feature.

There are multiple ways to create your own master page files. Here are a few techniques I recommend:

1. Copy Technique:
   • Copy the default.master from %Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\Global.
   • Make your changes directly to the html (in the copied file).
   • Make sure the copy file has a different name than default.master.
2. Designer Technique
   • Make your changes in SharePoint designer as described in the previous article: http://sharepointmagazine.net/technical/customisation/developing-a-custom-master-page-master-pages-and-sharepoint-part-3-of-6.
   • Do not save these changes against your site – you can do this against a test site to make things easier.
   • Copy the html out into a custom master file and give it a unique name.
3. Minimal Master technique
   • Make a master page file with the minimal master html code found here: http://msdn.microsoft.com/en-us/library/aa660698.aspx
   • The minimal master html is a master page with all the content place holders that you will need for SharePoint. This is a good starting point if you want to start from scratch in creating your master page. You should become familiar with what all the content place holders are for when using this technique.
   • Save this file as a new master file and give it a unique name.

Create the Feature

Features are created in Visual Studio and then moved into the SharePoint 12 hive %Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES. After the feature is in the 12 hive, stsadm commands can be used to deploy the feature to the SharePoint environment. Then the feature needs to be activated on the SharePoint site.

Steps to create a feature for Master Page deployment:

Note: We will not be using any tools like Visual Studio Extensions for WSS or WSPBuilder for this walkthrough. However, I recommend using these tools to wrap the features in solutions. We will talk more about this in the last article in this series.

1. Open Visual Studio
2. Create a New Project
3. Choose a Class Library project (for this walkthrough I am referring to a C# class library, but the steps are the same for other types)
4. Call it DemoMasterPageFeature
5. Delete Class1.cs
6. Add a new folder to the project and call the folder “12″
7. Add a new folder to the “12″ folder, call it “Template”
8. Add a new folder to the “Template” folder, call it “Features”
9. Add a new folder to the “Features” folder, call it “DemoMasterPage”
10. Add a new folder to the “DemoMasterPage” folder, call it “MasterPages”
11. Add a new master page file to the MasterPages folder
    • There are multiple ways to create this file
      • You can copy the one from SharePoint
      • You can copy a modified one out of SharePoint Designer. If you have been following this series you can go to article 3 {insert link here} and use the html we modified in SharePoint Designer for your new master page file.
      • You can start with a minimal master page http://msdn.microsoft.com/en-us/library/aa660698.aspx
    • We are going to use the technique of copying the one from SharePoint
      • Go to %Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\Global.
      • Copy the default.master
      • Paste it in the MasterPages folder (in the Visual Studio project)
    • Rename the file demomasterpage.master
12. Add a feature.xml file to the DemoMasterPage folder.
    • This file tells SharePoint how to install the master page
    • It must be called “feature.xml”
    • Put the following xml in it

    <Feature Id=”95F25D4A-D256-4158-96FE-010F599149CC” Title=”Demo Master Page”
    Scope=”Site” Version=”1.0.0.0″ Hidden=”FALSE” DefaultResourceFile=”core” xmlns=http://schemas.microsoft.com/sharepoint/ Description=”This Feature contains the demo master page”>
    <ElementManifests>
    <ElementManifest Location=”elements.xml” />
    <ElementFile Location=”MasterPages\demomasterpage.master” />
    </ElementManifests>
    </Feature>

    • Notice the following:
      • Scope – this tells SharePoint where to install the feature. Our scope is “site”, thus we want to install the feature at the site collection level. This is because our master page gallery lives at the site collection level. If we wanted to install the feature at the sub-web level, it would say “web”
      • ElementManifest – this tells SharePoint the other files involved in creating this feature. Remember, SharePoint only knows to look at the feature.xml file when installing a feature, so the feature.xml file must tell SharePoint about the other files involved.
      • Id – this is the unique GUID for the feature. It must be unique. So, if you create multiple features, make sure you use a unique GUID here. This is also how we can reference the feature when we start building solutions.
13. Add an elements.xml file to the DemoMasterPage folder
    • This file tells SharePoint what to do with this feature. For example: we want to deploy our master page to the master page gallery. This is the file that will tell SharePoint to do that.
    • It doesn’t have to be called elements.xml. But, it does have to be called whatever you put as the ElementManifest Location in the feature.xml file. I like to use elements.xml when I create these files
    • Put the following xml in it

    <Elements xmlns=”http://schemas.microsoft.com/sharepoint/”>
    <Module Name=”DemoMasterPage” Url=”_catalogs/masterpage” Path=”MasterPages” RootWebOnly=”FALSE”>
    <File Url=”demomasterpage.master” Type=”GhostableInLibrary” />
    </Module>
    </Elements>

    • Notice the following:
      • Url – this is how we tell SharePoint to put the file in the master page gallery. _catalogs/masterpage is the location of the master page gallery when dealing with site collections. We know we are dealing with site collections because the feature.xml file has a scope of “site”.
      • File – this tells SharePoint the name of the file it is going to put at the master page gallery. The type is “GhostableInLibrary” – this means the file is still going to be on the 12 hive and SharePoint is going to keep a Ghosted reference to the file. Please refer to article 3 http://sharepointmagazine.net/technical/customisation/developing-a-custom-master-page-master-pages-and-sharepoint-part-3-of-6 for more information about Ghosting.
14. Build the project in order to save your changes.

The final folder/file structure should look like this:

Deploying the Feature

There are 2 steps to deploy a feature:

1. Copy the contents to the 12 hive.
   • Copy the folder “DemoMasterPage” (this is the folder we created in the Visual Studio solution in the last section). Be careful to only copy the “DemoMasterPage” folder, not all the folders we created.

   
   Also, you probably won’t be able to copy from Visual Studio. So, go to windows explorer to do the copy of the folder.

   • Paste the “DemoMasterPage” folder in %Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES.
2. Run stsadm commands to install the feature
   • Open up a command prompt
   • Enter the following: cd C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN.
     Note: this assumes you installed SharePoint on your C drive. Please change the install path if otherwise.
   • Enter the following: stsadm -o installfeature -name DemoMasterPage -force
     Note: do not copy and paste. Sometimes copy and paste into command lines won’t work. Please retype in your command line
   • Enter the following: stsadm -o activatefeature -name DemoMasterPage -url http://mysitecollectionpath -force
     Note: do not copy and paste. Sometimes copy and paste into command lines won’t work. Please retype in your command line
     • The string after “name” is the name of feature of your feature folder.
     • The url is the url to your site collection root. You can copy it from your browser, but don’t keep the “default.aspx” on the path

What’s wrong with this picture?

Any developer will say this is not correct. Developers don’t want to copy files manually and paste them in a folder. Yes, I understand this. I am showing this technique to lead up to the last article in this series on solution deployment. The solution will take care of moving the files to the 12 hive and running the commands for you. However, it is important to understand what solutions do before jumping right into them. Thus, I am showing you this manual way so you can get an idea of what the solution is doing behind the scenes.

Set the new master page

The feature we just created placed the new master page in the master page gallery. However, it did not tell SharePoint to use this new master page on your SharePoint site. There are multiple ways to do this including: custom site definitions, programmatically setting the default master page, using SharePoint Designer, or using the MOSS master page selection page.

If you are using WSS, please refer to article 3 in this series http://sharepointmagazine.net/technical/customisation/developing-a-custom-master-page-master-pages-and-sharepoint-part-3-of-6 in order to see how to set the master page in SharePoint designer.

If you are using MOSS, you can go to your site collection and then go to site settings. Then under “Look and Feel” click on the “Master Page” link. You can now choose the demomasterpage.master to be the master page for your site collection.

Making Changes to the Master Page

Now the Master Page has been installed to the SharePoint farm and activated on the site collection. So, what if you want to make further customizations to the master page? Do you have to go through the process of re-installing and re-activating? The answer is no. Here comes the power of ghosting. Please refer to article 3 http://sharepointmagazine.net/technical/customisation/developing-a-custom-master-page-master-pages-and-sharepoint-part-3-of-6 for more information about Ghosting. Since the master page is ghosted, the SharePoint site keeps a reference to the 12 hive version of it. So, if you want to make a change to your master page, all you have to do is update the demomasterpage.master file in the feature folder of the 12 hive (%Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEA)TURES.

Deactivating the Feature

Sometimes there are changes you need to make to a feature that are not ghosted. Examples of these types of changes are things in the feature.xml file. You cannot change the id of a feature.xml file and expect to be able to just re-install and re-activate the feature. Instead, you have to deactivate the feature and uninstall the feature first. Here are the commands to do this.

1. Open up a command prompt
2. Enter the following: cd C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN.
   Note: this assumes you installed SharePoint on your C drive. Please change the install path if otherwise.
3. Enter the following: stsadm -o deactivatefeature -name DemoMasterPage -url http://mysitecollecitonpath -force
   Note: do not copy and paste. Sometimes copy and paste into command lines won’t work. Please retype in your command line
4. Enter the following: stsadm -o uninstallfeature -name DemoMasterPage -force
   Note: do not copy and paste. Sometimes copy and paste into command lines won’t work. Please retype in your command line

Conclusion

Using features to deploy the master page to the master page gallery is a reusable way to deploy master pages in SharePoint. However, there are still manual processes involved (including copying files to the 12 hive). Thus, using features is not the complete story when dealing with SharePoint deployments. In the last article in this series we will discuss SharePoint solutions (WSPs). WSPs are basically CAB files that wrap up features in SharePoint for easy deployment. The WSP file will move the feature files to the 12 hive for you. However, I think it is important to understand how this is done before jumping into creating WSP solutions. Plus, we can reuse the feature we created in this article when we build the WSP solution out in the final article of this series.