It’s the final part of the “Customizing the User Experience of SharePoint” series. This day we also celebrate the third day of SharePoint User Experience week here on SharePoint Magazine. One full week, focusing only on understanding SharePoint architecture from a user experience point of view. I couldn’t be more happy on drugs.

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…