WSS 3.0 navigation structure

I'm a beginner in WSS 3.0 and I'm having some problems with the navigation setup. I can't find any documentation that clearly recommends best practices in this area.

I'm trying to create an intranet, custom look and feel, that should have a structure similar to:

Company - News - News type 1 - News type 2 - Organogram - ...

Employees - Employees 1 - Employees 2 - Employees 2_1 - .开发者_如何学编程..

How to properly set this up? Company, News, are sites/subsites? And News type 1 and 2 are pages within a site?

I created as described above and in the master page of the main site I added some scripts that will be used by web parts, like jquery. The subsites will have their own master page and will not recognize the scripts, I need to add them there which is annoying.

Any recommendations? Or some resource that provides best practices setting up these structures?

Thx in advance

I can't recommend the best way to do this, but there are really a few considerations on how to break things up:

Most Important: Read up on the Microsoft SharePoint Best Practices Resource Center. It has tons of good information, and way more than can realistically be covered here.

First, the basic unit of storage on the backend is a content database, and it is generally considered a best practice to have one site collection per content database. In your case it might make sense to have two or more site collections - one for Company and one for Employees (and anything else).

Second, security. Most things kind of inherit down the tree from the site, but I could easily envision needing to provide a different set of permissions for the Company and Employee sections, and possibly even the Employees 1 and 2 (taking at stab that they might mean things like HR, Facilities, etc.). Ideally, it would be nice to lay things out in some way that logically follows your company hierarchy or process.

http://Server/Company/News
http://Server/Company/Blog
http://Server/Employees/HR
http://Server/Employees/Facilities
http://Server/Divisions/IT
http://Server/Divisions/Sales
http://Server/Divisions/Management

In the above layout, you would create "Managed Paths" in the Central Administrator tool for Company, Employees and Divisions, then create Site Collections for News, Blog, etc...

Third, do the sites need to share information? It is slightly harder to share information across site collection boundaries - though certainly not impossible. While it would help you to better scale up and outward, it might not be worth the additional effort.

Fourth, the Publishing features are something you should definitely look into to get the content on the site. It enables a bunch of nice features that allow end-users to easily contribute content to get published, attached to a workflow for approval and you can even specify time you want the new pages to go live (though that might be a MOSS only feature).

This really depends on the organisation, what you want to use your sites for, how your security structure will be, etc. so there is no single answer. Any best practice will only go so far for your unique situation.

Just a wild stab in the dark, I'd make everything subsites except:

• Anything that is a self contained site, like a 'project site' -and- can grow really-really-really large (like their combined total would exceed 40-50GB) or really needs its own complex security structure. I'd create those as their own site collections.
• The news. You can create 1 News subsite and add different types of news using a different content type (and page layout). Unless you have 2 groups of users adding this news, in that case I would make a separate news subsite for each group.

You can add .js or .css to every page using a delegate control. See this post.

I would make every topic a site, News, Company, etc.

But instead of makes 100 pages, classify them in their own site. Like so:

Employees: Department (Human Resources): SubDepartment(Payroll): Employee1_page

News: Local News: May2010: Local_News 1_page

News: Market News : February2010: Market_News 1_page

Have a local top site masterpage, and apply the master page to every site, assuming they will be the same. You can use SP Designer to copy/paste masterpages for extra frustration as a last resort, but of course that is bad practice.