Partager via

Clarifications: Collaboration vs. Publishing

  • Article

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.

Lets compare…

First, lets look at the communication model that actually happens between the two:

Collaboration

Publishing
collaboration_people Peer based, bi-directional sharing of information publishing 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.

Comments

  • Anonymous
    November 20, 2009
    This was really great in helping me decide to set up individual departments as team sites.

  • Anonymous
    November 20, 2009
    Thanks Matthew... what was the conclusion you came to?

  • Anonymous
    November 23, 2009
    The comment has been removed

  • Anonymous
    May 10, 2010
    The comment has been removed

  • Anonymous
    July 06, 2010
    this is very good article helped me in understanding the templates in customer requirements.

  • Anonymous
    October 05, 2010
    Thanks for this, Chris.  One question: how would you approach a request similar but different to one you have in the article? “We want to build a knowledge base site for our STAFF. Some people (sometimes a few, sometimes many) will collaborate on, comment, and discuss content, and we want a review and approval process, then have it published as the final step for all staff to see and use as a "single source of the truth".  Since it's internal, there's no huge branding requirement.”

  • Anonymous
    October 13, 2010
    Hi Alan, My guess is that you're probably looking at a publishing site. I could imagine extending the "Article Page" content type to be "Knowledge Base Page" or something similar. All of your staff could have draft visibility... and only after there's general concensus and someone hits the "Publish" button does the actual approval start... the beginning of the more rigid approval process. Once an item is approved, it is visible to all. This also means that if a change is necessary (and it will be), your team can continue working on a draft version of the KB article while the rest of the world continues looking at the published version... until of course, the new draft also goes through the approval process and becomes the new published version. If the second option were chosen, I would say that you're talking about a publishing site... and now I'm going to contradict myself slightly. I said that Publishing sites shouldn't be used for collaboration... but there is one exception: If the focus of the collaboration is to create the published content. It is absolutely reasonable for a group of people to work together to draft, review, and publish content inside of a publishing site... that is what it is designed for... but if the focus is to manage work that lives outside of the portal, or if the focus is the creation of an artifact (a document, image, video, product) rather than words that will show on a web page... then we're back to a collaboration site (team site). You might also consider doing a wiki instead... if you focused instead on enabling the sharing of information rather than the control of it. In this model, you don't need to approve things because you're willing to accept that it might be wrong briefly... until someone with more knowledge comes back and fixes it and probably contacts the previous editor to help educate them. Good luck!

  • Anonymous
    February 03, 2011
    Hi Chris, many thanks for putting this together. It is not always very easy discussing this topic with customers when they started out playing with SharePoint's collaboration templates and creating a simple intranet. That an announcement isn't the same as a news page in a publishing portal takes a bit of clarification. Using your inputs, I've created a simple slide to "educate" customers. You can find it here: www.getsharepoint.ch/.../sharepoint-collaboration-versus-publication Again, many thanks!

  • Anonymous
    October 01, 2011
    Hi there.. Thanks a lot for such a "to the point" article. I am creating a sharepoint portal which will be used primarily as Document Management System. Which site template should i use to create root site i.e. portal site and i am assuming team site will be good enough for departmental sub sites? Thanks Again Dani

  • Anonymous
    October 04, 2011
    Hi Dani, I think your Document Management question gets the famous "It Depends" answer. I would suggest that except for the items we might otherwise categorize as "Records Management", ANY collaboration site, but it an intranet portal, a project site, or a team collaboration site, would be a "document management" site as they all use the basics of document management such as check in/out, versioning, metadata, etc. Elsewhere I advocate the use of a LOT more site collections than sites. In my perfect world, your Intranet Portal site collection would contain only Publishing sites (including the departmental sub-sites), and the only "collaboration" or "document management" activities that would happen in that site collection would be those revolving on managing the web content. ALL other "document management" activities would be in distinct site collections focused on their given topics, and those sites would contain numerous types of documents that would potentially need to be managed. To answer your question more directly, the root should be the Publishing Portal template (for the publishing/WCM features and default settings), and should have numerous sub-sites in it (also of the Publishing Site template) that contain additional web content that likely eventually links off to very specific service-oriented collaboration site collections where the real work gets done. Those collaboration sites are likely Team sites, or some derivitave thereof, and will not generally have the publishing features enabled unless appropriate for your purposes. (It's really difficult to give highly specific answers without knowing the details of the implementation... so I'm sorry if this is a bit wordy :)) Thanks! Chris

  • Anonymous
    December 01, 2011
    Chris, I hope this isn't too long. We have 3 purposes for our web presence. My interpretation of your comments above, as they apply in our context, are as follows. Does this sound right?

  1. PURPOSE: Market CompanyB products/services & allow customers to place orders. METHOD: Establish a publishing portal site collection for CompanyB, containing a publishing site for each dept, in which marketing team members in their respective depts would be active contributors. This site would be for the purpose of collaborating internally to create, stage, publish, & maintain public-facing web pages only. It would inherit a previously designed brand, & a limited, predetermined set of available templates & page formats.
  2. PURPOSE: Collaborate internally to produce products & services not specifically pertaining to our public web presence. METHOD: Establish a separate collaboration portal site collection for CompanyB, containing a team site for each dept, to which all dept members (& any other approved contributors) have access. This site would be for the purpose of collaborating internally to create & maintain non public-facing web work products. It would utilize the many collaboration functionalities (wiki, workflow, discussion, tasks, etc.) available in SharePoint & formatting would be less important.
  3. PURPOSE: Collaborate w/our customers vis a vis our ongoing relationship w/them & our continuous improvement initiatives. METHOD: Establish a separate collaboration portal site collection for CompanyB customers, containing a collaboration site for each logical function (probably not confined to specific depts since that misses the point of collaboration), to which the whole world(?) can have access. This site would be for the purpose of encouraging external collaboration to create & maintain publicly available work products, which, as a by-product, will serve to advertise our presence & expertise among members of our community of interest. It would inherit a previously designed brand, & a limited, predetermined set of available templates & page formats. It would also encourage the use of several collaboration functionalities (wiki, workflow, discussion, tasks, etc.), as appropriate. And BTW, THANK YOU MUCHLY for this careful explanation!
  • Anonymous
    December 07, 2011
    Hi Kay, Let me summarize, if I may :) 1: Public Internet - Yes, this should be a wholly dedicated and distinct Publishing site, typically a single site collection, that follows the exact model you outline. Through the use of content queries and good design, you can enable content authors to update content in their respective areas that can/will automatically appear as appropriate, even in areas they may not have direct access to (such as the homepage).
  1. Intranet - This is typically split into two pieces: The intranet "homepage" (or home site) that is a publishing site, is not used for general collaboration (beyond that necessary to maintain the intranet web content), and numerous additional site collections below that whcih are based on a team site template that are intended for actual collaboration on specific topics or areas. Your description is generally accurate, but do some research on site collections vs. sub-sites for your purposes. (blogs.msdn.com/.../new-medical-condition-sharepointea-sitecollectionfearophobia.aspx would be a not-so-bad reference ;) )
  2. Extranet - Your description MAY be accurate, but would require a bit more research, and security can become a critical concern. I would encourage a good conversation with a SharePoint expert before moving forward. Thanks for reading! :)

  • Anonymous
    October 21, 2012
    This was really great in helping me decide to set up individual departments as team sites.

  • Anonymous
    November 11, 2012
    Great article, just one mistake, in the text below this should be a Publishing Portal in bold, not Collaboration one :) “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."

  • Anonymous
    December 29, 2013
    Hi Chris, Very nice article. I had a question... currently I am using the non publishing website and do not see the Navigation link under the look and feel menu of site setting so I am unable to use the publishing features.. My requirement for using the SharePoint is to provide a helicopter view to the top management on where the current projects are in the team, what are various PM's doing to complete their project on time, document sharing among the team, adding drop down menus for each project etc... I understand for making a website Publishing one needs to purchase an external IP which will incur cost but there is one more solution without incurring the extra cost by way of forwarding & masking the SharePoint site as intranet.. Could you suggest what will be the best way to begin..??