One of the interesting comments I heard yesterday after I sat on both an information worker panel and a developer panel at the SharePoint Best Practices Conference in San Diego was that getting two MVPs (or experts) in a room and getting the same answer is sort of like getting two economists in the same room and getting the same answer. The implication of this is that two SharePoint experts won’t agree on the best practice. Having been involved in many situations where two experts are commenting, I’d say that the appearance is that the two may be in disagreement — but the truth is they aren’t.
In my work with the advisory board for the Patterns and Practices team’s SharePoint Guidance we ran across the topic of Site Definitions and Site Templates. I’m not saying there’s 100% agreement on this topic — but when we initially covered it, it sounded like we were worlds apart. Ultimately we settled on some relatively simple principles that most could accept…
- Use a Site Definition if you need to have a specific ID that you can target later
- If you create a site definition, don’t put anything in it directly, create features that you activate via dependencies or via stapling.
- Don’t use site definitions to customize business problems — use globally deployed site templates for that.
Sure, not everyone who is a SharePoint “expert” (MVP or not) agrees with these principles — but most do. When we were talking about who should create a site definition the answers ranged from everyone to no one. But the trick to that was we were evaluating situations from our experience — instead of getting to the core guiding principles. So on the surface it looks like we’re disagreeing wildly — but in truth, we just had different experiences.
The example I like to use is branding. If you go back in time you’ll see that we’ve had 5 or so stops on what might be the best practice for branding. Same thing, there are some that will disagree but mostly we’ve settled on:
- Site Definition to create a unique ID (that we can staple to)
- Custom Master Page (deployed via feature)
- Custom Theme (deployed via feature)
- Theme references a page in _layouts (so we don’t run into the customized file problem)
- Page Layouts should be about the arrangement of metadata not branding
For the most part, if you talk to someone about SharePoint Branding, you’re likely going to get an answer similar to this. If you ask a slightly different question you can get radically different answers. “How do you START branding SharePoint?” For me, it’s a theme because that cuts a wide path. I can then go back and fine tune with master pages. Other folks start with the master pages (and site definitions) and do themes later — if at all. We agree on the principles just not always the approach.
Why does this matter? Well, it matters within the context of what’s the right answer for an organization. In the IW panel we were asked how one might find a good SharePoint consultant. The answer was hire another one to audit. (Financial people have been doing this forever.) What we didn’t cover is what happens if the auditor disagrees with the primary consultant?
I get into this reasonably frequently because I do a ton of these sorts of audits of projects, approaches, etc. Invariably we’ll have a disagreement about something. From my perspective that’s completely fine. All we have to do is talk about the core principles and figure out what’s the best answer for the customer (and if a change is worth the cost.)