Sites verses Areas Verses Topics Verses Whatever
This is most commonly asked question with no definitive answer.
As Bob Mixon says, it would depend on the exact requirements.
An "Area" is a SharePoint Portal Server page. Areas are organized in a hierarchial manner which ultimately constitutes your Portal solution. SharePoint Portal Server (SPS) Areas have features that are unique to them, including specific types of content, audience and security. For example; all content associated with an Area has the same security as the Area itself.
A Site, also referred to as a WSS Site, is much more of what you may know as a conventional web site. A WSS Site can consist of one or more pages and sub-sites. WSS Sites are used for many needs such as a place for team to collaborate. The security abilities of a WSS Site are much more robust.
Bill English, in his interview answered this one in a great manner.. I found it after a long time. So I’m reposting it. Take a look..
Home, Topics, Sites and News. All give you already a robust portal that is capable of disseminating static, public and company-wide information. But at the portal level, the collaboration tools are nearly non-existent. For example, the document library in a topic area lacks *any* of the collaboration features that is has when it is placed in a site. Whereas WSS Site is full of collaboration tools and totally empty of any method to implement taxonomy.
The portal is there to aggregate, present and organize information. The sites are used for collaboration.
if you need to collaborate on the information, then place that information in a site. If you need to present static information, then place it in a portal or in a site list that is submitted to a portal area.
Sites vs. portal is not primarily about departments vs. divisions vs. enterprise, though it is easy to see how we can think along those lines. The sites vs. portal are all about collaboration vs. presentation.
If you're looking to offer departmental level sites for teams, then you can consider WSS as that delivery mechanism. The SPS portion comes into play when you want to aggregate the view of those sites together in a more unified portal view of the world. While you can create areas at the SPS level till the cows come home, there are a couple of caveats.
First, security is applied to the area level not the list level. In a WSS site I can give everyone access to the site and restrict access in many ways (for example a read-only document library or manager only list). In SPS I have to create sub-areas to do this.
Second, there isn't a clean way to create content in an area without having to put it on the same page. In WSS I can create 10 lists and only expose the most important one on the home page but users can find all 10 lists in the navigation tree. In SPS I create the 10 lists and users have to go into the Manage Content link (assuming they even see it, readers don't) and find the list.
WSS sites should be used for contained content (document libraries, lists, etc.) where many people can collaborate on their own in a focused manner (say a project or team) with many contributors. At the SPS level, use areas for specific content that's targeted at groups where it's more of a push of the information with very few contributors and more readers.
This definitely helps !!
Parag Sinkar
posted by Parag Sinkar @ 1:16 AM
43 comments
