Choosing between publishing and team sites for your SharePoint intranet

I have noticed, that the tech oriented SharePoint architects tend to prefer team sites over publishing sites for practically any purpose. I cannot remember the reason, and frankly, during my years of building SharePoint intranets I have not come accross any real reason for this - more like on the contrary. An intranet built with team sites causes more problems than not, in most cases. Let me explain.

Team sites have a much more dynamic usage philosophy behind them than publishing sites. Team sites are meant to be virtual team workspaces, where a bunch of people collaborate, manage documents, manage team tasks, chat etc. The content is highly dynamic, based on lists and document libraries rather than text and images on web pages. Thus, the need to edit pages is ususally quite small. The owner creates lists and libraries, sets up the workspace and the content starts to live.

As for the informative intranet? This is not how it works! The content is highly static - text and images on pages, maybe some centrally managed documents that are published on for the large reader audience of the pages - I say pages, for even if the intranet is built with a site hierarchy, like it most commonly is, what users see and use, are pages. 

True, that you can do the same with team sites too. Nobody says that team sites must be collaboration sites. However, using team sites to build traditional intranet sites creates a series of issues for the content managers and designers of the intranet. Issues, that the more technically oriented architects never see, since they rarely step into the boots of the end-user.

Quite many times, I as the UI "guy" and the content management "guy", am called into these situations where someone, some tech person, has built the intranet for a compnay, a Site Collection created as a team site, created a hierarchy of team sites. the customer has started to build their intranet with the blocks they have been given and they run into issues.

1) "I  made changes to this page, but they disappeared". Most of the time the publishing features have been turned on in the site collection of team sites that are meant to act as the intranet. This results in a very strange hybrid situation, where one can edit a page without checking it out, but someone can also check it out and result in loss of data. 

2) "I was trying to edit this web part, but I get this message about checking out." Even when the check out is required for the pages, the whole editing and check out is occasionally quite confusing for the content editor. In some situations, the page allows you to edit it to an extent, until it suddenly hits the editor with the "Hey, you need to check this page out first!". Again, data may get lost in the process. 

3) "Pages or Site pages and what is the welcome page of the site?" When publishing features are activated for the site collection and for the sites in it, each site has two libraries for the site pages. The Site Pages library (originial for the team site) and the Pages library (created by the publishing feature). Now, this creates another funky situation there. 

If indeed pages are created within sites, they may be in each different library, depending on how they were created. And they function a bit differently when editing, not to mention that the whole page architechture is different. More confusion for the content editor. The deafult page of the site can either be the Home.aspx from the Site Pages library or the default.aspx from the Pages library. You need to choose, and set the welcome page in the site settings.

4) "But... this page layout is not consistant and we want it to be something like this [drawing]." When using simply the welcome page of each site in the intranet site collection, the issue that the HR, PR, marketing etc. department raises when getting involved with the intranet is the layout of pages. 

True, not an issue for all companies, but a whole lot of them. There is a need to create a consistent layout for the pages and while text layout offers some options, it rarely truly fullfills the needs here. Publishing pages with the page layouts options are required. All of a sudden you find yourself creating new welcome pages as publishing pages and building them all over again with the content that already was on the home page, the wiki type page of the team site.

So in order to avoit these hybrid versions of sites and the confusion of the people who actually need to work with the pages and manage the content of the intranet, I highly recommend creating the informative intranet hosting site collection using the publishing site template. Seriously, that's why it is there! If you need blogs or wikis or even team sites within, it is all still possible. If you need calendars etc. that are not orginally part of the publishing site, the team collaboration lists feature can be activated. 

This said, if your intranet is not a traditional informative publishing intranet but a collaborative dynamic intranet instead, or if you prefer the wiki type content management, please do use the team sites to get the most out of that scenario! There is nothing to lose and a lot to gain  to actually use the most suitable SharePoint site template for each specific purpose instead of going with the idea that one glove fits all. It doesn't! All it needs is a little bit of planning and understanding the actual use case scenario of the site collection at hand.