Check it out

http://heathersolomon.com/blog/articles/446.aspx

Some more info...

It isn't about areas  vs. sites  so much as it is about Portal vs. WSS.

Portal is meant for large audiences and static content. A portal is a
gateway to information and provides a search functionality that is
powerful enough to index the entire enterprise.

WSS site  is meant for small audiences, short term content and team
collaboration. They are meant to be created, used and potentially
thrown away (because the content is short lived, like a project or a
meeting). WSS sites are great for teams to share docs, info, events and
tasks.

So for example, if you have HR policies that need to get pushed out to
all your employees, that's better suited for a portal. But if the HR
team needs to work on new versions of policies or collaborate on
corporate procedures, that's better suited for a WSS site.

I’m clear on what the differences are, I’m just working on trying to develop some more concrete guidelines  for some clients on what they should be making into areas  and what they should be making into sites  – and when to do both.

I generally describe Areas (and Portal itself for that matter) as a communication tool and sites (WSS) as a collaborative environment. However, this is very abstract and doesn’t provide a workflow type approach that I think that some end users  (and help desk) staff need. I’m trying to distill the key questions into that flow chart type thing so that they have some good guidance on what to do.

This far, I believe that I need to ask about:

1) The ability to target content to subsets of users.

2) Is the information available for everyone to see?

3) Is there the need for varying levels of security within the site/area?

4) Is the site/area going to be used primarily to communicate or to collaborate?

I am trying to kick around order – and what questions I am missing.

Can We come out with a sample solution. which can
demonstrate this. may be at some community server.

Can we take a typical problem scenario and work on it?

Oh yeah then go check out my questionnaire.

Big determining factors are search, audience and permissions.

One thing, your question # 4… I could see where that may get confusing because technically when you collaborate, you are communicating. Maybe it could be worded as one way vs. two way communication.

I also wouldn’t use the term “site/area” in your questions or flowchart. I would focus on words like content and users. You don’t want them to get hung up on the technical terms.

I have dealt with this a lot. I would be happy to help if I can.

Actually, search isn’t a criteria because you can put portal search in the sites  … I look at that as a design/layout issue.

I agree re: site/area. Just trying to keep it simple.

I keep dealing with this issue too, that’s why I want to distil it down into guidance. What would you do if you are only asking where to put things and not talking about the decision to purchase/use portal? i.e. Assume portal is present so you can leverage services from it.

Actually in my mind search is a criterion because the WSS search is not as powerful as portal search and portal search can feed off benefits like shared services and search multiple portals. OOB WSS search will only index that WSS site, which can be an issue for some clients.

I try to never bring in words like “portal”, “WSS”, “team site”, “area”, etc. into conversations with clients when doing requirements gathering. You tell me what you want and answer some basic security and existing content questions, and I will decide what is best for you. As for where to put things, to me it goes back to the basic who is the audience (large vs. small) how frequently is the content updated (static vs. short-term), and how secure does your content need to be. Additional items are how powerful of a search do you need, and does your content structure run deep (WSS sites  don’t handle deep content hierarchies very well IMHO).

Once those questions are answered you can determine portal or WSS, then you can look to see if you have an existing site  that the content would be a good addition to, or if you need to create  a new area  or WSS site for the content. And a lot of that depends on the internal structure and the purpose of the site. That is getting into usability and content organization and only someone with knowledge of the internal structure can determine.

Unfortunately I don’t know how much of this can be canned into a flowchart, unless your environment is already setup with buckets for sites and areas  so you could go through one line of questioning and the end answer would be, it needs to be an area in this XYZ portal. If this is a site by site decision, someone with knowledge and understanding of not only SharePoint but of the environment would have to be used at least at the final decision level.

In my discussions, I like to use "Presentation" for Portal (including search)
and "colaboration" for WSS. If one wants to find information, either browsing or
searching (without regard to location), use Portal. If one wants to work on
items alone or with others, use WSS.

In my summit class, I discuss the age-old question of when do we create  new sites  vs. new areas  vs. new portals. I’ve learned through experience that there are some benchmark factors of when to do each. Here goes:

I. Create a new site  – this shouldn’t be on the radar screen of a portal admin. End-users will manage this and they will create new sites within a site collection when needed. Don’t forget this is a distributed administrative architecture. Portal admins don’t create new sites. Instead, portal admins create A) new stand-alone site collections via a new virtual server, B) new portals and/or C) extended and mapped virtual servers to existing content. For the most part, portal admins, IMHO, should not be focused on creating new site collections that are embedded in a managed path of a virtual server. To be sure, some environments require this level of granular administration, but I think this can be managed by power users  or even end-users themselves. I’m happy to discuss this point more if there are objections to this.

II. Create a new area: the reason that we create new areas is to help do the three things that portals do best: aggregate, organize and present. If an area  helps us do one or more of these three things, then a new area is probably needed.

III. Create a new portal: this is more tricky because we can probably accomplish most of what a new portal will accomplish via new areas within an existing portal. So, here are the judgement calls for creating a new portal:

a. There is a unique taxonomy that requires a separate portal

b. There is a large enough and unique enough audience that a separate portal is necessary

c. There is such a different set of information that needs to be consumed and it is a large enough set that a new portal is probably in order

d. The customer (internal stakeholder) is willing to “pay for it” – meaning they will permanent devote both $$ and human resources to help manage the portal

e. Politics – what manager isn’t going to say “Yes” to this question: “wouldn’t you really rather be the master of your own portal?” Politics drives a lot of sharepoint designs today

These are all shades of gray on a continuum and sometimes, one criteria will drive the decision whereas other times, a balance between the criteria will drive a different decision. I personally like to see clients genuinely understand this and then move forward with their own decisions as opposed to me making their decisions for them. I’d rather teach them how to fish than catch the fish for them.