Microsoft SharePoint Portal Server builds on Windows SharePoint Services' ability to create team sites by letting you construct a central portal that comprises several different types of sites, links the individual team sites, and lets users share information across them. If you're responsible for implementing and administering your organization's SharePoint Portal Server project, to ensure the project's success you'll need to be familiar with SharePoint essentials: the basic architecture of a SharePoint portal, SharePoint portal area permissions, portal listings, Web Parts, and how to manage the information that's shared through the portal. I'll start here by explaining key aspects of SharePoint's portal architecture—in particular, portal listings and how you can use them to flatten your SharePoint site's navigation structure and aggregate and display information consistently across portal areas. Then, in the upcoming part two of this article, I'll delve into more detail about the visual elements of SharePoint, such as Web Parts, and how to use them to build a SharePoint site's UI. (If you're just beginning the planning phase of your portal, see the sidebar "Planning Your SharePoint Portal," for some planning guidelines.)

SharePoint Architecture
If you're new to SharePoint Portal Server portal design, you'll need to know the following key terms.

Site. A SharePoint site is a Web site that's enabled by SharePoint Web Parts and Windows ASP.NET–based components and contains collaborative content (e.g., documents, discussion groups) for a team. (For more information about SharePoint sites, see the sidebar "Types of SharePoint Sites" in "Making Sense of SharePoint Search," September 2006, InstantDoc ID 50623.)

Portal area. A portal area is generally a special type of one-page, self-contained site that SharePoint Portal Server controls. Multiple portal areas comprise a site. Portal areas are created in a manner that will produce a hierarchical navigation structure (i.e., by using a taxonomy). Generally, administrators and subject matter experts create portal areas. So, for example, the administrator might create a top-level portal area for the HR department, then permit a named individual in HR to create subareas such as Compensation, Vacation, and Procedures.

Each portal area contains various information containers, such as document libraries, lists, and portal listings, which are geared toward the users of that portal area. An individual portal area can maintain only one portal-listing list. (I discuss lists and listings in more detail in the Portal Listings section.) You can target a portal area to specific audiences (an audience is a custom group who can view specific content targeted to that group) who will view the content in that area and set permissions to limit portal-area access to certain users. You can also designate a portal area as hidden from navigation (regardless of the permission settings for that area) as well as whether or not it—and its content—are searchable.

In addition to serving as a site that includes the information containers mentioned earlier, a SharePoint Portal Server portal area can itself be an information container. By placing a Content Editor Web Part on a portal area, you enable that area to become an information container. (I'll discuss Web Parts and other visual elements in SharePoint in part two of this article.)

Document libraries and lists. If you've worked with Windows SharePoint Services, you should be familiar with document libraries and lists. Document libraries and lists are the foundation for maintaining information, such as Microsoft Office files, links, contacts, events, issues, and tasks, on a SharePoint site. A document library contains a collection of documents shared with SharePoint site members. A list is an element of a SharePoint site that contains a collection of items that aren't documents, such as contacts or tasks. (For more information about document libraries, see "Office 2003 and SharePoint: Better Together," December 2004, InstantDoc ID 44156.) Lists are a powerful component of SharePoint and include many features for maintaining fields in a list, such as text, Rich Text Format (RTF), drop-down lists, lookups from other lists, and calculations (e.g., sum, total).

Portal-Area Permissions
Permissions for SharePoint Portal Server and its associated content are less granular than permissions in Windows SharePoint Services. The granularity of permissions derives from the manner in which Microsoft designed each product to be used. Windows SharePoint Services is designed as a secure collaborative environment for managing "work in progress." SharePoint Portal Server is designed to manage published content and provide a single UI containing a holistic view of aggregate information specific to the current user's need—that is, a portal. Portal users have an unlimited view of and access to the portal area, whereas on a Windows SharePoint Services team site, only team members can access the site.

In SharePoint Portal Server, you define portal-area permissions for the portal area itself, and all content associated with that area assumes the same permissions. You set portal-area permissions via the standard Manage Users option that's available for any administrator of a team site or portal area. You can't set specific permissions on a document library or list as you can in Windows SharePoint Services.

Permissions are an important consideration when designing your information structures and determining where they will be physically located. Because permissions are at the portal-area level, you need to be careful when deciding what content goes into what portal area, since anyone who has write access to the portal area will have write access to all content in that portal area. Therefore, you might want to look at your content and group it together by access permission—for example, a portal area for all content that's readable and a portal area for content that's writeable.

You might be tempted to try to circumvent SharePoint Portal Server permissions. For example, some SharePoint administrators have used an unsupported technique published on the Internet that lets you manage the permissions of a specific document library or list within a portal area—that is, it lets you give a list a different set of permissions than those of the portal area. I strongly recommend that you avoid such unorthodox solutions because they can have unpredictable results and Microsoft doesn't support them.

Portal Listings
Portal listings are available only in SharePoint Portal Server, so you might not be familiar with them if you're new to the product. A portal listing is simply a special type of list that's available only on a portal area. Portal listings are a vehicle for displaying information inside a portal area, such as a piece of news. Listings are at the core of information aggregation; they reduce data-entry duplications and provide a consistent presentation layer for your users. Portal listings include the following features:

• Each portal area contains one, and only one, portal-listing list—a list of all the portal listings. That is, the portal-listing list is the container, and the portal listings are the items in the container.
• The content of a portal listing can be either a URL or an RTF document.
• Portal listings can be grouped.
• Portal listings can have an associated image and icon.
• Each item in a portal listing can be filtered from view by using SharePoint's audience feature.
• Each item can have defined publishing dates, so that the item is removed from display in the portal area after the item's expiration date.
• You can set portal listings so that new items must be approved before they're displayed.
• Listings from one portal area can be displayed on any other portal area by using different Web Parts, depending how you want to use them.

As I mentioned, portal listings let you target a specific audience for each item in a listing. When you add a new portal listing to the portal area, you need to choose the audience(s) to target. Be aware that an audience's main purpose is to filter items only; an audience isn't equivalent to security permissions.

For each portal-listing item that you create, you can either reference an existing document reference (i.e., by a URL pointing to the document's location) or enter the RTF document itself. SharePoint Portal Server search will index only the portal-listing information, not any document reference. (For in-depth information about SharePoint's search capabilities, see "Making Sense of SharePoint Search," September 2006, InstantDoc ID 50623.) When you add a new portal-listing item to the portal area and your intent is to reference a document, it's a good practice to enter a description of that reference. Note that search results don't honor audiences.

Unfortunately, portal-listing items are more difficult to remove from a portal area than to add to it. For example, when you create a new Windows SharePoint Services site, you have the option to create any number of portal-listing items in any portal area you have permissions to. If the Windows SharePoint Services site containing these portal-listing items is deleted, the portal listings aren't automatically removed; you need to delete them manually. This situation applies to all portal-listing items that use a reference. If the reference is no longer valid, the portal listing item isn't automatically removed.

Moving On
As you've seen, SharePoint Portal Server incorporates the basic elements of Windows SharePoint Services within the larger framework of a portal area. Becoming familiar with the concepts of portal areas, portal permissions, and portal listings will help you take your first steps in planning and putting together a SharePoint portal for your organization. You'll also need to get a handle on SharePoint Portal Server visual elements, such as Web Parts, and the essentials of developing a navigational structure—which I'll cover in my next article.