Why would a site admin or designer use a Web Part Page instead of a new sub-site/sub-site collection?

Question

I am a site owner, and up until now, I have always created sub-sites instead of using basic pages or Web Part pages. I would like to understand what advantages Web Part Pages have over just adding a new sub-site.

So far, the biggest difference I think I see is that Web Part Pages don't allow the admin to control the access the same way as with a sub-site, which, to me, is a disadvantage. The other difference is that Web Part Pages are stored in a library. Are there advantages to storing pages in a library?

What other differences are there? Why would I choose a Web Part Page over adding a new sub-site?

The description of "Pages" from the Microsoft site is very basic. I guess "Pages" means all three types of pages? It seems that a site can do all that a Web Part Page can do and then some. Why would I choose to use a Web Part Page? On the MS site Introduction to sites, workspaces, and pages says:

"What is a page? A Web page in a site can display lists of information, enabling team members to organize the information any way they want, such as by subject, due date, or author. For example, you can do the following:
- Filter the content to see only the set of information that applies to you
- Hide information that doesn't interest you
- Change the order in which the information is listed
- Set up customized views to make it easy for your team members to focus quickly on pertinent information "

Does someone have examples of when to use a Web Part Page instead of a sub-site? For example, does a Web Part page use significantly less space on the server? Does it load faster? Is it easier to retire when it's no longer needed? What problem was Microsoft trying to solve when it created Web Part Pages?

Answer 1

Web Part Pages are advantageous when you want to display information within your site in a different manner. They can be viewed very similarly to sub-sites because you can add them as links to your quick launch just like sub-sites however, they do not require you to create an entirely new site (which could contain new security groups, possibly pre-created lists or libraries, and other things). They are often used to create dashboard type pages within a site.

Web Part Pages can be looked at very similarly to the publishing pages in that they are pages within a single site which generally have the same security needs as the rest of the site, and are usually within the same type of topic. For example, if I had a team site that was the finance team site and on the main page, I have the documents list, a links list, and maybe the calendar for my team, I might also have a link to a page that would display the balances. This page could be a web part page that contains data view web parts that connect to databases that show balances. I would not need to create an entirely new site for this to be able to just display this data.

Answer 2

A very odd question :)

For me, comparing SPWeb (subsite) to page, is like comparing book to bookshelf. Yes, you can perform same operations with a site, but web part page is just a little possible part of the site. Actually, site can contain hundreds of web part pages, but with the same success it can contain none of them. Site is just a "box", a container, with some predefined content including several web part pages.

So, sites exist for grouping several objects in one entity. That is their main purpose. If for you a meaning of a site is concentrated in a single page, and you don't intend to add another pages or lists or libraries or whatever to it, you'd better create a page.

Indisputable, web part page will use less space on disk.

The next point, I would not say, that access control capabilities for a web part page differ from same for a site. You can easily break role inheritance for the particular page, and modify permissions in any imaginable way.

And yes, pages can live outside of document libraries. For this, they have to be either deployed with Visual Studio feature, or to be created with SharePoint Designer.

For instance, in SharePoint Designer, you can achieve this, performing following steps:

1. Open SPD
2. Go to [All Files]
3. Navigate to SitePages document library (not obligatory SitePages, it could be any document library)
4. Select particular page, and copy-paste it a root folder

Also, there is a button "Web Part Page" on the SPD ribbon, so you can create new pages the same way you are doing that through the GUI.

Actually, you can even just create a blank new ASPX page (right-click => New => ASPX), and then add web part zones into it and modify it as you wish (but it will need a little bit more input and knowledge).

So, creating a single page instead of a site, you could get a bit more fancy urls.

Drawing a line, I don't see any reason of using sub-sites, if you quite satisfied with a web part page functionality.

Answer 3

Web Part pages belong to a site. On a page, you can display and combine views from different lists or libraries that exist in the site. SharePoint offers a variety of options to sort, filter, connect views.

If you add a new sub-site, the SharePoint interface doesn't allow you to display in the sub-site content that belongs to the parent site.

I use Web Part pages all the time. Some examples:

• dashboards
• content based on user profile: for the same tasks list, team members go to a page that shows "My Tasks", project managers go to a page that shows "My Project Tasks", and managers go to a page that shows... overdue tasks!

You are also correct, a simple Web Part page is much lighter than a full sub-site.

Answer 4

Web Part Pages live in Document Libraries. The default page in a new site may not.

• When you create a Web Part Page or a Wiki Page you are creating a document in a special type of Document Library. When you create a site or subsite, it has to have a page by default, but often that page is not in a Document Library.
• A page in a Document Library gains all of the benefits of other items in lists or libraries. For example, you receive the ability to version the file. What happens when you accidentally delete a web part on your page created with a Site Library? Are you able to revert to the previous version or do you have to add the web part again and set all the properties to configure the way it was before? Versioning, check-in, check-out, drafts, library permissions, list item permissions are all properties unavailable to pages that live outside of document libraries.

Page deletions go in the Recycle Bin. Site deletions may not.

Before Service Pack 1 for SharePoint 2010, SharePoint did not include a Recycle Bin for Sites or Site Collections out of the box. By default, a page deleted accidentally from a Document Library can be recovered through a 2 stage recycle bin process. First, it is available to the user who deleted the page. Then, after it is cleared from the user recycle bin, it is available to the administrator recycle bin. A site, once deleted, in most cases is not recoverable.

Other Considerations

• Large amounts of pages are easier to manage than large amounts of sites.
• Creating a page within a site provides context to the other content in the same site.

Answer 5

Pages(basic or webpart pages) themselves are inherently part of a site(or sub-site in your case) collection in SharePoint. They inherit their permissions from the site that the page gets created in.

Here is a quick overview of pages vs sites: http://office.microsoft.com/en-us/windows-sharepoint-services-help/introduction-to-sites-workspaces-and-pages-HA010021413.aspx

Answer 6

• Sub-site: A sub-site (or a site) is like a box with a lid. What you put into the box stays in that box. You cannot mix what is in that box with material from another box (site or sub-site). For example, if there is a sub-site A and a sub-site B. You will notice that a webpart (e.g. a library) set up in sub-site A cannot be added to sub-site B. They are separate boxes and their contents cannot be mixed.

• Webpart Page: A webpart page is a little different. These are more like setting up temporary fences or windows into the information within a site. Let’s say we create 3 libraries at the top level of our SharePoint Site – A Lib 1, New Lib 2, and Old Lib

We could:

• Display all of these on the “home” page, but that would clutter things up a lot and only some people are interested and only sometimes.

• Display each of these only with a link in the navigation bar either on the left or at the top – this is an option, but still a little fragmented. The three are related, but alphabetically they might get separated or reorganized on a list.

• Create a Page called Resources. Within that page we can display all three libraries, so that whenever you call up the Resources page you will see all 3 libraries at once. Meanwhile, you don’t have to display navigation links on the home page except to the Page.

• Let’s say that later I am working with a new team who needs to see information in A Lib 1, but not in New Lib 2 or Old Lib 3. Let's also say that they need to establish a new library for the new development work they are doing, Dev Lib. I would create a new page that displays the same A Lib 1 (no need to create a new library and copy the materials over) and add a new library, Dev Lib, for the new material. This reuses something we already have but displays it for a different group of users, along with some different materials that they will need. It keeps the user groups focused on what they need to do their job and doesn’t distract them with clutter from other peoples’ work.