In SharePoint-Land there are two concepts that people have a hard time separating out: “Collaboration” and “Content Management”. A lot of people like to blend them together, use methods, features, technology, or processes… but the truth is these are separate capabilities, and should be separately managed.
First, lets look at the communication model that actually happens between the two:
Peer based, bi-directional sharing of information
Generally unidirectional, leader-based communication of information.
When we’re collaborating, we’re all sharing information with others in our group, and those people have an equal opportunity to share information as well. In publishing, there is usually a small group of people communicating to a much larger group of people. Think of it as the difference between working with your peers in a conference room, all working together to get the job done, and your CEO doing an announcement to the entire company.
For example, in a publishing site (such as your company’s “www” site), how you say something matters nearly as much as what you say. It’s all part of one larger message. So the layout, the display, colors, pictures, and functionality are all a reflection of the primary message. In collaboration, we’re not worried about how much the site matches our homepage or that the colors fit with our marketing message… these things have no impact on our ability to share information, exchange ideas, update status, or publish documentation.
Microsoft Office SharePoint Server 2007 has numerous site templates to serve varying needs, but the three that tend to matter the most are the Team Site template, the Collaboration Portal template, and the Publishing Site template.
- Team Site template – a simple site template designed to help a group of people (a team?!?!) work together to exchange information and ideas. It’s usually lightly branded (themed), but overall looks and acts like “SharePoint” should.
- Portal Templates –
- Collaboration Portal – Usually used for an intranet, it supports things like content staging and heavy branding, along with ways to gain access to the additional collaboration (read: Team Sites) site collections below it.
- Publishing Portal – A publishing template similar to the collaboration portal, but more “blank slate”, designed to be customized to your heart’s (or MarCom director’s) content. This is usually the starting point for building your internet site, which will be published to a read-only SharePoint environment accessible through or on the other side of the firewall, and accessed by your customers.
The big problem I see is people using Team Sites for publishing, and publishing sites badly.
So, how do you know what kind of conversation you’re having, site you’re being asked for, or template you should use? Here are some sample requests:
- “The CEO needs a site where they can communicate to the rest of the company.” – Collaboration Portal… it’s one person talking to many people. That’s publishing, so a publishing template is appropriate. The CEO will likely want a lot of branding too.
- “Our team needs an area to share documents for our project.” – Team Site… it’s a group of people sharing information together. They don’t care about branding, they care about their documents and delivering the project on time.
- “We want to build a knowledge base site for our customers. We’ll need anyone to be able to create content, have a review and approval process, then have it published as the final step.” – Publishing Site with a staging environment… the internal site will be used for all of the content generation processes and workflows, and the external site would be read-only and available to all users. The heavy branding and content deployment features would be supported by the publishing features.
- “We want our intranet to be collaborative and to provide a seamless experience for our employees.” – Collaboration Portal with collaboration site collections… keep reading…
The last item is one of the most common… and we need to be clear. Yes, we do Web Content Management, including supporting “collaborative” intranets… but we have to reiterate that SharePoint isn’t just a simple website… it’s a complete web application. Would you consider heavily branding Outlook? Does your OS have your branding all over it (except maybe your background image)? Are your ERP, Training, Travel, or HR systems heavily branded? Probably to various degrees… and SharePoint Team Sites can be too… to a certain degree.
Ultimately we need to clearly understand what features we need for publishing vs. collaboration, and what we can and should do to support those needs. Publishing needs heavy branding, high performance read-only access (caching), staging and deployment, while Collaboration needs clear functionality, ease of engagement, consistency between sites and high performance read/write access (no caching, fast servers).
When you talk to your stakeholders, try not to think about how you can bend the product to their whims, but rather how you can effectively translate what they’re trying to accomplish into something SharePoint can support directly. A stakeholder may say “I want the intranet to support collaboration directly.” One approach would be to create one massive site collection with heavy branding throughout… but you don’t really need that. Chances are a main intranet with separate collaboration site collections beneath it (beneath the site directory for example) would be just fine… and if we need to blur the lines a little, search web parts can present content from across the intranet on one page.
…and if you really need to blur the line, you can always custom write something… but that should be your option only after the built in capabilities have been exhausted… and usually they’re not.
So, use team sites for team collaboration… and portal sites for web content management. The less you try to make one act like the other, the happier you and your customers will be in the long term.