Logo 
Search:

Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Site design opinion

  Asked By: Ricardo    Date: Jan 03    Category: Sharepoint    Views: 715

I am trying to figure out the best way to organize a site. Here is the
situation. We are building a divisional intranet using SPS v2. There
will be 9 departmental sites off of the root site and multiple topics
associated with the information stored on the site. Therefore, someone
could browse to the root site and either navigate down to the subsite
they want, choose a topic to browse through, or search for information
they need.

Here is the dilemma - it seems that I can either create the subsites in
the "sites" directory in which case I get to add a theme and choose a
type of site (project, meeting, etc) and can drop in web parts such as
discussions or announcements or I can create a subarea which gets listed
in the Sites topic, is stored at http://sharepointsitename/subarea
(instead of http://sharepointsitename/sites/subsitename) and I get the
Actions/Topics menu on the left side instead of the Quick Launch menu
and cannot easily change the theme or add the same types of webparts.

Ultimately I want to ensure ease of navigation and searching, but am not
sure what the difference between a subarea and a subsite is to
Microsoft.

Any thoughts on how to build this thing?

Share: 

 

4 Answers Found

 
Answer #1    Answered By: Virendar Chaudhari     Answered On: Jan 03

All sites  you create  (team sites, document, personal, etc.) are
basically kept under the <servername>\sites\<sitename> structure. Unless
you're creating a subsite  in another site, everything ends up there
regardless of how it's organized in the portal. Categories (now called
Areas) and Sub-Categories (Sub-Areas) are just ways to organize  these
sites (as well as other content in the portal). The topics section is
just another list (similar to sites) and lets you categorize your
content whatever way you want.

In the end (areas, topics, sites) are all just custom lists. Sites (by
default) has some extra fields for extra grouping but otherwise they're
the same.

It's pretty confusing and I've asked MS a few times to try to explain it
but basically there are several ways to slice up your content
(documents, sites, lists, etc.) in whatever way you want. I've been
working with SPSV2 long enough now to understand it, but I still can't
articulate it very well. If anyone is really stuck feel free to email me
privately or call me.

For your dilemma  I suggest just creating all the sites under the Sites
section. Even if you create a new site  as a sub-area somewhere else, if
it's a site it ends up here. You can modify the list in that area if you
want to add/remove more choices to the region/division stuff that comes
out-of-the-box. You can add  your own fields or change  the ones there as
well. All of these form an organization structure within the site pages.

So the structure can be something like this:
Portal
-Site
-Subsite
-Subsite...

And your site navigation  structure in your portal can be whatever you
want with the sites and subsites  being classified in topics that make
sense.

Any content (document, site, etc.) can be categorized somewhere in your
topic (area) structure. When you add a document there's an option to add
it to the portal somewhere, which will bring up a tree like view of the
portal where you can select (multiple) areas and sub-areas where you
want your content to appear. This is the same for a site as well which
is similar to configuring the site structure in the settings menu. This
also includes content you create way down in tree so if you have a
department that is considered global (say Security) and they have a
policy document library or something you can actually have it in your
site structure tree while it actually lives down in a sub-site.

Yeah, clear as mud I know.

 
Answer #2    Answered By: Mitchel Villarreal     Answered On: Jan 03

The decision I ended up making
was to create  the structure using areas, as they seem to be more
featured than sites  and do not reside in the sites directory. In
addition, when I create a sub-area the hierarchy it automatically gets
added to the Area Contents Webpart, which makes for a useful
navigational tool for each division of the intranet.

We're still a bit up in the air on how to use the sites feature. So far
I have not seen much advantage to them except for the fact that they can
be created ad hoc without risk of mucking up the hierarchy and making
browsing confusing. They are a great way to simply collaborate on
documents or meetings quickly as well without having to mess around with
setting security on an area or library to meet changing needs. I think
MS refers to this use of sites as "workspaces".

I'm also encouraging content developers to submit their content to the
portal so that they can associate it with multiple
topics/areas/sites/etc. as they build  it. This is pretty powerful in
terms of cross referencing data and preventing redundancy.

Every once in a while I feel as though the mud is thinning....

 
Answer #3    Answered By: Ranu Badhan     Answered On: Jan 03

This brings to light a question that maybe someone can answer (again I'm
hoping my MS people are going to provide feedback to this). If I can
have security, audiences, views and content for an area what's the
advantage (or point) of having a site? I mean, I can create  an area (and
sub-areas) and have it auto-insert itself into my heirachial list of
areas I can't see a purpose for a site  (other than the fact that the
page won't have the Portal elements on it). I can create an area that
contains all the same contents as as site would (doc libraries, task
lists, etc) and have the added bonus of being able to reuse any list
anywhere (without having to resort to adding it to the central template
list via command line).

Bryan's idea of using Areas and Subareas seems to be a good solution. I
tried playing around with a trove type categorization of software for a
project portal using the site directory  list. I customized the list but
you can only get two levels with this (and it's a pain to maintain).
Plus I can't secure an individual area (say Financial) other than
securing the entire site, not the listing of it. With areas I get both.

The only disadvantage I can see is that I can't ripple security down
from an area to it's subareas like I can with sites  and subsites. Or am
I missing something here?

 
Answer #4    Answered By: Irene Moss     Answered On: Jan 03

I'm struggling with whether to use areas or sites. I'm leaning towards
areas, but finding some disadvantages:

Areas seem to have the following disadvantages: They do not allow for
security at the list/document library level while sites  do. Event lists
in an area will not allow for the creation of attached workspaces. The
members webpart does not work in areas.

 
Didn't find what you were looking for? Find more on Site design opinion Or get search suggestion and latest updates.




Tagged: