Explaining Publishing Site vs. Team Site?

 I am struggling to explain to others the different uses of Publishing Sites vs. Team/Collaboration Sites. I am not talking about the design-based differences, but the differences in end use- why would a business choose one over the the other in planning site collections? Are there any general "best practices" type articles that don't bog down in tech-speak that can clarify this issue?

Hi Nancy,

IMHO, governance and requirements should drive decision that 100% of the time.  Let me give you some examples...

If you are referring to the managed documents section of your portal, i.e. sites where managed corporate ip is stored and consumed, I believe a consistent look & feel is imperative to the findability of that information.  In most cases, I find it best to use the Publishing Site template for every site in these collections and the site provisioning process is highly governed.

If you are referring to the management of projects and initiatives, I also believe you will find the need to govern the provisioning of sites and content placeholders.  Don't just allow anyone to create sites in this space for many reasons.  Some of these include security, finability, and the need to produce consistent roll-up of information in the future.

If you are referring to the creative/ad hoc/collaborative space, then initially provide them with a small list of site types to choose from during the reqest process.  Initially remove them from the need to understand the technology difference and use names such as Social Event Site, Collaboration Site and Meeting Site.  The Intranet Implementation team will have previously chosen which SharePoint Site Templates will be actually used for each of these.

In short, try and remove the business user from having to make the site type decision based on technology.  Allow them to tell you what the business need is and a site is consistently provisioned for them.

I understand- and I am definitely a proponent of the "Theory of Lockdown."

I think what would help me is language along the lines of, "If you want the site to _____, it's best to use the Publishing type. If you want to accomplish ______, it's best to use Team sites."

One drawback as I read more on Publishing sites is that it seems extremely development-heavy. I am not a developer and don't write code. I don't even work in the IT department yet!

Right now, the SharePoint "staff" at my company consists of me and one other person who helps with the back end side when he has time left over from his "real" job.

If I promote use of Publishing sites (which I think will be valuable for us over time), there won't be resources to write custom code or anything  beyond strictly OOTB functionality. Will this be enough to give us a satisfactory product?

Understood... it is important to understand that there are really only 2 major categories of site types in SharePoint; a regular site (single page) and a publishing site (multiple page).  When you break it down to this simplistic analogy, the decision becomes will you ever need more than one page on your site?  If so, use the publishing site; and, if not, use the blank, team or meeting site.

Some general guidelines would include; for Departmental Sites, basically all sites in the managed (or controlled) information repository, I recommend you always use publishing sites.  There will become a point in time you need to deliver information, on the same site, to different consumers in different ways; hopefully you are planning for this now!  The publishing site lends itself to this.

If you are working with the confines of a project center or collaboration center, you may want to put a stake in the ground initially where your team only allows for the provisioning of blank sites or team sites.  Keep the level of education down.  Since you are not planning on any level of customization, it will be in your best interest to use less site types to reduce the amount of education.

Meeting Sites
I also recommend to customers they initially start with a single meeting site style.  For example, use the multi-page meeting template for all meeting site requests.  This will help reduce the amount of education.

Bob Mixon:

... it is important to understand that there are really only 2 major categories of site types in SharePoint; a regular site (single page) and a publishing site (multiple page).  When you break it down to this simplistic analogy, the decision becomes will you ever need more than one page on your site?  If so, use the publishing site; and, if not, use the blank, team or meeting site.

Nancy - Bob states it nicely. By determining the need of the End User who is requesting the site, you can help drive the decision of what type of site would be most appropriate. Asking the End User for the type of site needed is like asking your Mom "Which type of operating system would you like on your computer?". Response from Mom: "Huh? Operating what? I don't know. Just get me a computer."

In SharePoint terms, the question on the request form doesn't ask "Do you need a Team Site Template or a Publishing Template"? That is a solution request before determining the need. The needs can be more clearly determined with more open ended questions: "What is the purpose of your site?" "Will your site be used as an information resource or a place to store documents?.

I understand your problem from a site collection administrator perspective... how do I help my "clients" decide which template to use for their base site. The interesting answer is, you don't need to discuss various templates. You talk with the people who will be using the site, define what type of content will reside in the site, find out what the business problems are and then work out the Information Architecture based upon the business problem. In general, I think you'll find that if the need is for an information repository of individual pages, a Publishing site works well.

Mark
EndUserSharePoint.com