As you'll recall from last month's "Making Sense of SharePoint Portal Server Architecture," InstantDoc ID 93082, Microsoft Share-Point Portal Server comprises several basic elements, including sites, portal areas, document libraries and lists, and portal listings. I also discussed the features of portal listings and how they let you display information consistently within and across portal areas. Another important part of SharePoint is its visual elements, which include Web Parts and views. Here I'll explain SharePoint's information-presentation features, specifically the List View and Grouped Listing Web Parts, and how you can use them and portal listings to aggregate information and provide a more comprehensive and intuitive UI for your users.
Web Parts and Views
SharePoint Web Parts are customizable components that form the foundation of SharePoint Portal Server's content framework. Each page in a SharePoint portal includes multiple Web Parts, which the portal's users see as sections of content of various types (e.g., text, a button to launch an application). Web Parts generate all the lists and views that make up the portal. A view is basically a feature for customizing the appearance of a Share-Point Web page.
As mentioned in "Making Sense of SharePoint Portal Server Architecture," lists are an essential part of SharePoint content. A list view lets you customize how list information is displayed to a user—for example, by limiting the fields displayed, filtering list items by a set of criteria, sorting items in a particular order, grouping list information according to list data, or displaying subtotals. In both Windows Share-Point Services and SharePoint Portal Server, you can create any number of public and personal views for a list.
List View Web Part
When you create a list in SharePoint, SharePoint (i.e., Windows SharePoint Services) creates a List View Web Part to display that list. The List View Web Part is the primary means for displaying list information on a SharePoint Portal Server portal area or Windows SharePoint Services site page.
You can place a List View Web Part only on a portal area where the list itself is defined. If you want to display a list's content on a different portal area, you have several choices for doing so: You can either buy or download a free third-party Web Part, you can develop your own custom Web Part, or you can use Microsoft Office FrontPage 2003 and the Data View Web Part. If you're looking for third-party Web Parts, I recommend doing a Google search on "SharePoint Web Part Products." Also take a look at the SharePoint Products and Technologies Web Component Directory at http://www.microsoft.com/sharepoint/downloads/components/default.asp, which is a good source of free Web Parts and other SharePoint components. You might want to consider developing a custom Web Part because it gives you the most flexibility, especially if have an experienced .NET developer on staff. To find more information about developing custom Web Parts, I suggest starting with SharePoint Products and Technologies Web Part Programming Tasks in the MSDN library (http://msdn.microsoft.com/library/default.asp?url=/ library/en-us/spptsdk/html/SPPTWPFProgTasks_SV01072932.asp). Also check out Andy Baron's MSDN article "A Developer's Introduction to Web Parts" (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odc_sp2003_ta/html/sharepoint_north windwebparts.asp).
If you're unfamiliar with the Data View Web Part, I recommend that you use FrontPage 2003 to access and use this part. Using FrontPage 2003 with SharePoint is a controversial subject because of the impact it has on portal areas and Windows SharePoint Services sites. This topic is outside the scope of this article, but I recommend you do an in-depth review of benefits, features, and negative consequences before using FrontPage 2003 with SharePoint.
Grouped Listing Web Part
Unlike lists, which have only one associated Web Part—the List View Web Part—several Web Parts are available for displaying portal listings, which you can choose from depending on your specific requirements. The primary Web Part for displaying portal listings is the Grouped Listing Web Part, which has many powerful features and provides a number of options for displaying listings.
When you place a Grouped Listing Web Part on a portal area, the listing source will be set to the current portal area by default. However, you can change the default portal area to any area on your portal. This in itself is a very powerful feature not found in other Web Parts, such as the List View Web Part. By using this feature, you've just fulfilled two significant business requirements:
- the ability to manage a set of listings on a portal area where the content has different authors from the area where these listings are displayed
- the ability to display one set of listings on multiple portal areas, which avoids the creation of duplicate listings
To illustrate how the Grouped Listing Web Part works, I've created a sample portal area named Quick Links. I need to display the set of links to other sites or documents contained in Quick Links on more than one portal area. I'll give a small group of users content-authorship permissions to Quick Links. Here are the steps for selecting the listings you want to display through the Grouped Listing Web Part:
- Create a portal area named Quick Links. If you don't want to display this new portal area, exclude it from navigation in the settings page.
- Add a few listings to this new portal area by selecting the Managing Content Action option and clicking Portal Listings.
- Navigate to another area on your portal and add a Grouped Listing Web Part.
- Select Modify Shared Web Part from the drop-down menu. You should now see the Web Part Properties panel at the right of your browser.
- In the Current Area Override section, click the Change Location link.
- Next, a dialog box is displayed, which contains the complete structure of your portal. From this dialog box, you can choose the source of the listings to be displayed in this Web Part. Choose the new Quick Links Portal Area you created in step 1 and click OK.
- Change any other properties you want to for any other Web Part; when you're finished, click Apply or OK at the bottom of the Web Part Properties panel.
You can also use the Grouped Listing Web Part to manage content authorship of your portal areas. As explained in "Making Sense of SharePoint Portal Server Architecture," SharePoint Portal Server permissions are less granular than those of Windows SharePoint Services. All content associated with a portal area assumes the permissions of that portal area, as Figure 1 shows. But as Figure 2 shows, you can use the Grouped Listing Web Part in a portal-area structure to manage content that has various permissions requirements.
Flattening Your Navigation Structure
You can use SharePoint Portal Server portal listings to aggregate information and improve site navigation for your users. Aggregating information will reduce the number of clicks a user must make to see specific content; this is called flattening the depth of your portal navigation structure.
You can use audiences (custom groups who can view specific content targeted to that group), portal listings, and aggregated portal listings to reduce the depth of portal navigation for users. I'll demonstrate how to do so by using a simple portal-area structure for managing a set of common FAQs and a set of FAQs that are specific to regions in your organization.
If you didn't use SharePoint's audience feature, a UK user would have to click through the Support page to see FAQs that are common to the organization, as Figure 3 shows. If that user wants to access FAQs specific to the UK, the user would have to click again to display the UK FAQ Area page.
Figure 4 shows the same scenario using SharePoint's audience feature. By using audiences, you reduce the navigational depth of your portal and the number of clicks a user is required to perform and provide a single holistic view of all relevant FAQs.
Implementing the solution that uses audiences in this way can have some limitations, depending on your content-authorship requirements. If your requirements let you combine FAQ content authors into a single group of individuals, each having the permissions to modify all FAQs, then this method should work well for you. But if you're required to have content authors for Common FAQs, another set of content authors for US FAQs, and a third set of content authors for UK FAQs, you'll need to use a different approach. One method is to hide both the US FAQ area and UK FAQ area from your portal navigation and simply display three Grouped Listing Web Parts on the FAQ area, as Figure 5 shows.
This method uses three Grouped Listing Web Parts, one for each of the three sets of FAQ portal listings. The first (top) Web Part displays the Common FAQs and doesn't specify any target audience. The middle Web Part displays the US FAQs and specifies the US employee target audience. The bottom Web Part displays the UK FAQs and specifies the UK employee target audience. This design and UI approach ensures that a US or UK employee will see only two Web Parts on the page. The Grouped Listing Web Part target audience feature will hide what the current user isn't targeted to see.
This method of using the Grouped Listing Web Part with audiences isn't a true aggregate of information; it's a typical "middle-ground" implementation that I see used often. The aggregation is done at the UI level, and the employee still has a minimum of two Web Parts that contain FAQs.
A Better User Experience
SharePoint Portal Server's Grouped ListingWeb Part and portal listings form a powerful combination for improving your site's usability. I've outlined several techniques that you can apply in your own organization to manage content from multiple authors on different portal areas and flatten the depth of your portal's navigation structure, to let users access the information they need more efficiently.
