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.
Related
We're starting to use SharePoint 2013 to manage our department's process documentation and I have some questions about best practices for site structure. I'm a little surprised I can't find the answers via web search, since this seems like a basic question every new SharePoint user must deal with.
Moving from a file share environment, I'm trying hard to get out of that mindset and I understand the many benefits of SharePoint over file shares. I also understand why creating folders in SharePoint forces arbitrary divisions on files whereas one large set of documents with metadata lets you filter and group the files based on different needs.
What's confusing me is that I also read that it's better to have too many sub-sites than not enough. It seems like sub-sites can easily become pseudo-folders and I'm not sure where that line is crossed.
Here's an example.
We have a SharePoint site devoted to our department. We've create a sub-site dedicated to an application we developed to load data into our business systems. It mainly holds technical documentation about the application. This application supports many different data sources, each with its own set of user instructions for loading, its own schedule (calendar), contact lists, supporting files, etc. There's no compelling reason to separate them to restrict access. However, there doesn't seem like a lot of value in having them all in the same sub-site, either, since someone working on a job will only want to see the docs and supporting files for that data source. I just can't foresee someone wanting to view supporting files across all data sources, although, I could see someone wanting to see the schedule for all data sources combined.
My question is, should I create separate sub-sites under the application for each data source or do I just store everything in the application sub-site and use metadata and views to group things by data source? Putting all the items for a specific data source into its own sub-site seems to be much simpler to manage and present than having to specify metadata for every new file and creating a lot of views. However, I can't shake the feeling that I'm still using file share thinking. Or maybe I'm just missing some basic concept of SharePoint.
Any advice or links to good discussions of this topic would be greatly appreciated. Thanks.
I would recommend that you use metadata and views to separate data in one repository/site.
My reasons are as below:
In SharePoint, it is recommended to use metadata than "evil"
folders(or subsites in your case). Keep in mind that maintaining
multiple subsites requires big administrative efforts in long term,
for example, some sites will be inherited while others unique
permission.
As time passes by and people rotate, it becomes vague
that where the data was stored and where the new data should go to,
especially with large volume subsites.
Since confidentiality is not concerned in your case, keep data centralized and open to people working in related field increases sharing and collaborating phenomenon. In contrast, using subsites increases the possibility of data silos.
people are all lazy :). Taken me as example, I dont want to remember all those xyz URLs, I want to go to one place and be able to fetch everything that I need.
I am new to share point and still learning all the best practices, but I have a parent site called "Clients" and a sub site for the each of the clients i.e. Walmart, Kmart, Target. Is it a best practice to have a unique document library for each of the sub sites and the parent site. Or to use just one library for all of them. And if I were to use just one how would I set that up?
Thanks
Sites and Pages are not the same!!!
I wish that was more clear. In this case I want a SITE with the customers. Then each customer will have its own page. This way I can use the same apps across all the customers. I will probably need to learn how to create a customer template next.
to start with you need to answer few questions first, and these questions will help you to decide on an approach.
Do you have unique documents per client
will you control access to your users, that is each subsite will have unique permission, users for one client say for instance walmart should not access documents of Kmart
what would be tentative size of each documents and how much will that grow over the year
above are few question which will help you to get started, being said that, I will start creating a site and if the look and feel are the same for my other clients with little changes, then save the site as template.
This template will be my base for other client subsites/ sites.
will also create a global document library, which will store relavant documents which can be sharable across subsites
If required, each client will have their own subsites and own libraries for maintainabilty. this will also help to move subsite to its own site collection if there is hugh growth in data for a particular client.
You can also plan to use search, and webparts like content search query webpart to mashup data from subsites.
Another area to explore is metadata and Information architecture.
When you ask "Is it best practices" for the multiple Libraries or a single Library. From what you have described and Ramakrishnaraja was trying to say, you need to figure out what would work best for the situation. I don't know if you mean to have a different group called "customers" or if that is the same as "Clients" I'm going to respond assuming you mean both parties are the same.
Ramakrishnaraja points out that you have one central log on page "Clients- 'Main'" which leads to the other pages. If you want to the users to be divided into groups that have access only to the documents within their repective page then you should create multiple Document libraries. If you want the users to have access between the sub pages and use/edit files between the sites then best practices would be to have one Library for the Site.
I hope this helps you. Ramakrishnaraja makes a lot of good points and approaches it from a design overview rather than a specific response to your situation so try to use his post from that perspective.
I'm the IT Manager at a mid-size manufacturing company. We are getting our feet wet with SharePoint - so far we're got one blog in production use> It's the CEO's.
We have use cases for a couple of list-based "applications" with some simple workflow that will be implemented by one of our developers. We also want to give our users (at least the more tech-savvy ones) the ability to create and work with their own departmental sites.
We're concerned, however, that we might be starting something that could quickly get out of control if it's widely adopted (which would be a good thing). Since we don't really understand all the architectural trade-offs, we could end up with massive amounts of user data in a structure that bites us down the road.
Our biggest question is whether to have multiple sites for each use vs. a single root site from which everything else descends. Multiple sites would give us flexibility to make changes or develop new features without creating problems for all the users. However, multiple sites might be harder to back-up, search, and maintain user profiles/security. A single massive site seems to reverse the cost/benefits.
I'd appreciate any insight on the one vs. many trade-offs, or links to resources that discuss it. Links to general SharePoint "enterprise best practices" (sorry) would also be appreciated.
Thanks.
However, multiple sites might be harder
to back-up, search, and maintain user
profiles/security. A single massive
site seems to reverse the
cost/benefits.
I would consider this as incorrect. First we need to clarify when we say multiple sites, do we mean multiple site collections or multiple sites - they are two entirely different things.
Now even if they are multiple different site collections, in SQL database, they are just one database, since the database is created as web application level and not site level.
That was regarding backup.
Coming to search and user profiles, again your assumption is wrong. Search and User Profiles are Shared SErvices and they work fine as long as they reside in single Shared Services Provider. Both are farm level services.
A single massive site is (if you really mean site here not site collection) is a complete no-no and a bad design.
I would recommend having multiple site collections (something like Overall department in your company like HR, Finance , IT) and then have subistes under it. This way you have one database in SQL to manage and still you can scale by adding content database to existing web application.
Again here, I assume that you are creating your topology at company level. If this is at some lower level it needs to be refined.
Read some articles on taxonomy and site architecture on Technet before going ahead with any one.
Planning worksheets for SharePoint Server 2010
http://technet.microsoft.com/en-us/library/cc262451.aspx
Plan sites and site collections
http://technet.microsoft.com/en-us/library/cc263267.aspx
Sites and site collections overview
http://technet.microsoft.com/en-us/library/cc262410.aspx
Plan site navigation
http://technet.microsoft.com/en-us/library/cc262951.aspx
It purely depends upon your needs and requirements. even having a deferent web applications for deferent site i can provide you one citation taking backup as advantage. You might have few sites where data does not changes frequently like organizational policies, process documents etc. in this case taking regular backups/search crawling does not make sense(although you can opt for differential backup and incremental crawl but still in a week or fortnightly you have to take full backup). hence i would suggest carefully analyze your requirements and then take a decision. Microsoft has provided a good list of checklist and templates for planning purpose. few of the links are provided in madhur's reply and rest you can google upon.
My workplace will be starting to use Sharepoint internally during the coming months. I'm pretty excited about the possibilities of having more structured data on our intranet. A key part of this is allowing related data to be spread across the site hierarchy.
I'm currently experimenting with a list of Committee Members, with the idea that somewhere on the site you could see a list of everyone on every committee. Then in other parts of the site, you only want to see members of a single committee. From the various articles and blog posts I've been reading, it seems like there are three accepting ways to approach this:
Roll Up - Subsites have their own lists (optionally from a list template). Content types are used so the instances can be collected into a Data View Web Part on the parent site.
Pull Down - A master list is defined in the parent and each subsite contains a view of that list, filtered
Purchase or create a custom rollup webpart.
What are your experiences in different situations? What are the tradeoffs of these techniques and are there other (good) ways I've missed?
BTW, the committee members example is what I'm currently experimenting with to try out different possibilities. I'm more interested in the general tradeoffs, not necessarily specific to this example.
Having done this a number of times on different sites, for your situation, I recommend:
1.Roll Up - Subsites have their own lists (optionally from a list
template). Content types are used so
the instances can be collected into a
Data View Web Part on the parent site.
This gives more flexibility, not only can other sites in your site collection get this information, you can use the search query webpart to roll up the information in other site collections (the CQWP and DVWP do not work across site collections).
The only time I have used a Pull Down model is when there logically is only one list that I site collection will go to. Such lists for us have always been functional in nature, e.g. A list of content query definitions for a some custom functionality or a list of customers that ALL sites rely on and is used to populate an installed custom field control.
I would say that both will work equally well but the advantages of one over the other really come down to whats more convinent for how you'll have your intranet site collection structured.
You might also want to consider using the Content Query Web Part (CQWP) in combination with a complimentar site collection structure so that you can surface the committee member data.
With a little customization, the CQWP can do some amazing things - and it has been fully optimized under the hood by the product group team for managing all kinds of queries. It's easy to configure and use, and there are plenty of examples on how to use them on the web.
Our organization started on the SharePoint path about two years ago. Before that, we (the developers) wrote mostly asp.net front ends for SQL back ends. Now it seems like every time a new project comes up, we are asked to “make” it fit in SharePoint; and we have stuffed some things into SharePoint that probably should have been stand alone applications or web applications due to complexity and interactions with other technologies.
My question is: Where do you draw the line as to developing a project in SharePoint versus Web/Winform application, and how do you convince your manager(s) that SharePoint may not be the best solution for a particular project?
I sort of agree with you that this is sometimes a tough question. In general, though, I agree with the cliche that you just have to think about a sharepoint app a little differently. If your data can be considered as list-based, then SharePoint probably isn't a necessarily bad development framework. It may seem like more work on the surface, but IMO the challenges just move from one place to another. If you use things like custom field templates and web parts, you can relatively naturally handle all sorts of data. And you get the positive aspects of SharePoint for free (an already mature security framework, built-in searching, site and list templates/definitions, personalized page customizations, yada, yada).
I also I don't know what you mean by "complexity and interactions with other technologies" here, so it's hard to imagine what specific issues might be introduced when SharePoint is added to the mix.
If your dev team is relatively inexperienced with SharePoint and you care about quality and deadlines, I can definitely see your point. It's not an easy learning curve, but I think the SharePoint product is more naturally extensible than many people give it credit for.
There is, in some cases, a third option between a SharePoint application and an ASP.NET application. You can build custom site and application pages and deploy them to a SharePoint site. (The book Inside Windows SharePoint Services 3.0 gives a good overview of how to do this.) This will allow you to use ASP.Net and SQL Server within a SharePoint environment (which means you can also take advantage of things like SharePoint security). It's not as easy as developing a plain ASP.Net application, but it's a compromise.
Of course, this is sort of a technicality if they're wanting these new applications to be built on SharePoint technologies (lists, libraries, workflow, etc.), not just to be "inside" SharePoint.
One of the primary reasons why you might put an applicaiton in SP is when you want to take advantage of the building blocks SP gives you:
Security (share security with the site)
Data (store some or all of your data in lists)
Provisioning (if you want you app on multiple sites)
Some basic data UI e.g. Lists give you that and you dont need to build it.
One thing to consider when trying to 'integrate' a new app into the existing pool is whether there is any overlap in data (customers, inventory, etc) that would benefit from the merger.
There is also the benefit of being able to back up multiple applications and all of their respective data in one place.
Why are they asking for it all to go into SharePoint?
In my experience it is because the 'ole SharePoint intranet is being great as a portal to keep everything together and findable under the one information architecture.
Approach the issue from a uses perception of the application space in the organisation.
So long as the application looks and feels just like part of the intranet site and the user does not have to think about how to get to it (and how to get back out), you can pretty much take any architecture decisions necessary to get the best bang for the organisations buck when it comes to implementation and maintainence.
When we started thinking about the site less from SharePoint vs other stuff to the nice woolly concepts of Information Architecture, findability and usability, our decisions not to make it actually inside SharePoint, but still skin it like the Intranet became easier to sell.