Be an Expert (Or Play One on TV) – With SharePoint Introduction Webcast Materials

I’ve posted previously about the web casts that Andrew Connell and I are doing. I’m happy to announce that the materials that Andrew and I are using for these web casts are now available for everyone. Not only do you get the source code but you’ve got the slide decks as well (including a transcription of the web cast in the notes.)

Sidebar: We’re aware that the demos for my first two recordings are REALLY small. It looked fine when they were live. I’ll rerecord them in the next few weeks and will make a post to let you know that they’re fixed. Thanks for your patience.

How Best Are Your Best Practices

In my work with Andrew Connell on the Web Casts for Paul Andrew, we’ve been struggling to make sure that what we’re delivering in the web casts and in the hands on labs that will accompany them represents state of the art best practices. It surfaces in tons of little ways. For instance, you should always dispose SPSite and SPWeb objects you create yourself (and not those you get from SPContext.Current) so the sample code has using statements in it to make sure that the objects are properly disposed. We’ve also religiously defended against the possibility of using Render() or RenderContents() in a web part as dozens of demos have done. Why? Well, because there’s a consensus around using CreateChildControls(). The reasons are somewhat simple – because ASP.NET can work with CreateChildControls() to change the display for alternate devices (via ControlAdapters), post back values and event firing works, etc. Basically it’s a well behaved member of the family where as render and render contents are more ASP-Classic in their approach where you just write whatever you want.

Those are some of the easier ones to put a stake in the ground on. They’ve got clear cut advantages, disadvantages, and enough people willing to stand up for them. There are more subtle things that we’ve been defending as well. Things like building web parts instead of web pages in SharePoint – because the platform is about modular, reusable UIs. However, my point here isn’t to enumerate all of the things that I think are – or should be best practices. The point is that I think there’s a natural problem that we have in the industry that everyone needs to help solve. (Yes, I mean you reading this right now.)

First, let me quote James Bach who was speaking about software development methodologies “There is no consensus about what practices are best, unless consensus means ‘people I respect also say they like it.'” I believe our situation with SharePoint is not all that different. We’ve got a handful (or more) opinions about what a best practice is but little consensus on what the best practice is. I think that this is because that there isn’t one perfect answer. There isn’t in anything else either. We have suspension bridges, cable-stayed bridges, arch bridges, etc. Not one kind of bridge fits all. They each have different benefits. So while I can pretty definitively call out CreateChildControls() as a best practice, I find it much harder to persuade Todd Bleeker that my configuration based approach to loading user controls is better than his integrated project approach. I think that both can be best practices in the space. (I know I haven’t defined the details of the approach, ignore that for now, it’s not important to this discussion.)

However, there’s another problem – one that in my opinion is much more insidious. There’s a large gap between the State of the Art and in the State of the Industry. In other words, we know what to do but we don’t do it. I’ve been talking about this problem in the software development space for a long time. However, I think that the problem might actually be worse in the SharePoint space. A buddy of mine, Shane Young, recently posted a blog entry — What makes a “good” SharePoint Consultant. One of the things he is saying without directly saying is that he gets called in, like I do, to clean up a ton of messes that some SharePoint consultants are creating because – in this case – they don’t know what the product can do out of the box. I wish I could make as bold of statements as Shane can about needing to know a lot about SharePoint before doing any work on the platform. I can’t because it seems like I am still learning something new about SharePoint every week – given the amount of experience I’ve got, the problems I’ve solved, and the solutions I’ve created – that shouldn’t be the case but it is. I say shouldn’t because at some point you should know everything about a system. However, I’m realizing that it’s bigger than any one person (or team of people) can experience.

Back to my point, there’s a large gap between what we know to do and what we actually do. Ben Curry just posted a blog entry about quick performance tips for SharePoint. Most of us know that these are best practices, but how many of us do them when we setup a new server? My observation is very few. Ben and Bill have gathered a whole set of these Best Practices into a book Microsoft Office SharePoint Server 2007 Best Practices that will be out soon. Will their best practices be the best practices – or merely a best practice? I suspect a bit of both. However, knowing what to do as someone might after reading the book is only half the battle. When are we going to actually do what we say?

Need another example? How about the SharePoint Governance Checklist guide that Joel Oleson distilled from my SharePoint Governance articles (Part 1 and Part 2) and then added some additional content to? How many take the 20 minutes it takes to get through this content and answer the important questions that are raised? In my observation, very few folks – even those that know about the materials – actually take the time to ask the questions and figure out the answers before implementing SharePoint.

Another thing (besides Ben and Bill’s book that’s focused on infrastructure) that may help drive us to the right place is the work that the Patterns and Practices team at Microsoft is embarking on now. Glenn Block posted on his blog that they’re looking for feedback. They’re trying to understand how people develop with SharePoint so they can provide some direction. They’ve put together a survey to try to get that feedback.

My only hope is that we can all settle on a set of best practices and actually start to use them.

Article: Office Space – From VBA Macro to Word Add-In


Become a SharePoint Developer Instantly, If Not Before

With all of the interest in SharePoint I sometimes think that people walk up to me and want to know how to become a SharePoint developer instantly. (Just add water, as they say.) If you read my MSDN Magazine End Bracket article “You Should Learn SharePoint” you probably already realize that it’s not quite that simple. However, Paul Andrew has been leading a charge that Andrew Connell and I’ve been a part of to get a good primer for SharePoint developers out there so anyone who has the desire to learn will have all of the tools they need to get started with SharePoint development. The first part of the campaign is ten (!) hour long web casts where we cover the things you need to know about SharePoint and some of the cool things to learn about SharePoint that can make building your solutions easier.

They are every Tuesday & Wednesday from 12p-1p EDT (GMT -0500) starting next week for the next five weeks. Here’s a break down of the schedule:

Date (all times EDT) Topic & Registration URL Presenter
Tues, May 20 : 12-1p Web Parts Rob Bogue
Wed, May 21 : 12-1p Data Lists Rob Bogue
Tues, May 27 : 12-1p Silverlight Andrew Connell
Wed, May 28 : 12-1p Event Handlers Andrew Connell
Tues, June 3 : 12-1p Site Branding Andrew Connell
Wed, June 4 : 12-1p Workflow Rob Bogue
Tues, June 10 : 12-1p Web Services Andrew Connell
Wed, June 11 : 12-1p Page Navigation Andrew Connell
Tues, June 17 : 12-1p User Management Rob Bogue
Wed, June 18 : 12-1p Content Types Rob Bogue

Special thanks to Paul for getting this ball rolling, and the awesome set of people participating both at Microsoft and external to Microsoft to make this happen. I’m excited to be a part of it.

Creating SharePoint Sites from Global Templates with the Object Model

I recently had the pleasure of delivering the first SharePoint Workshop for Bamboo Solutions in Chicago, IL. One of the cool things about the project was the ability to put together what I believe are some of the best workshop materials out there. I may be biased (and the pope may be catholic) but I believe that the common thread that runs between the labs can really help you understand how all of the pieces of SharePoint fit together.

One of the challenging parts of putting together the workshop was building a tool which could quickly create the individual user ids and site collections for each of the students. One particularly quirky part was creating the site from a global site template through the object model. You see when you upload a template to a site collection and you want to create an instance of it via code you use templatename.stp in your code to refer to the template. This is what most folks document when demonstrating how to do it. However, because I needed to create separate site collections for the students, I couldn’t upload the site template that way, I needed to use STSADM –o addtemplate to add the template globally.

When you upload a template globally, the template gets assigned an ID that starts with _GLOBAL_#0. The next template would be _GLOBAL_#1 and so on. None of this was new to me because I’ve used this format before. However, the interesting thing was that the code I wrote worked when I used one of the site definitions (STS#0) but not when I tried the template. In the end, I realized that the account I was using didn’t have access to the site. I had installed SharePoint with a service account and I was logged back in as the administrator. The administrator account didn’t have an entry in the Policy for Web Applications – once I put a policy entry in for the administrator the creation tool started working fine.

Instructional Design: One Quick Tip

I’ve received many comments about how easy the SharePoint Shepherd’s Guide for End Users is to use.  I was just editing some other material and I realized one of the reasons why.  It’s automatic for me but apparently not for everyone.
When doing step-by-step instructions you basically have two options for how to structure the step:
1) Select Option A in Field B
2) In Field B, select Option A
Any idea which one’s easier to read?  The second one.  Because you’re not forcing them to remember the value while locating the field.  It reduces what is called cognitive load.  In short, you’re requiring less brain power to be able to follow the steps.
If you’re thinking that it only applies to end user materials … um, no.  The less brain power consumed actually trying to follow the steps the more mental resources there are to be able to reach higher levels of understanding (see Bloom’s Taxonomy/Taxonomy of Educational Objectives)
The next time you’re putting together step-by-step instructions you may want to think about how you structure the steps.