In a previous post I introduced the concept of contexts and the way contextual data & information is rendered through a dynamic page. This post extends the explanation and covers the way data or information contained in a standard list or library can be rendered in a custom way. I’ll take the example of a news list and display the news title in the place of the page title and the news body in the center of the page. Here is the news list:

And here is the way the page could look like:

Configuration of the dynamic page

1. Launch SPD and open your site
2. Create a new empty page
3. Insert a data view of the news list in the web part zone you wish to display the news details
4. In the Common Data View Tasks menu, select Edit Columns:
   
5. Choose Body as the only field to be displayed:
    
6. In the Common Data View Tasks menu, select Parameters and create the id parameter as follows:
   
7. In the Common Data View Tasks menu, select Filter and configure as follows:
   
8. For the PlaceHolderSiteName, click on Create Custom Content:
   
9. In code view, below <h1 class="ms-sitetitle">, delete the line starting with: <SharePoint:SPLinkButton runat="server" NavigateUrl="~site/" …
10. Go back to Design view; you should now have something similar to:
    
11. You are now ready to add a data view of the news list. Proceed as above and select Title as the only field to be displayed:
    
12. Configure the id parameter and create the filter as in steps 6 & 7; optionally, you may provide a Default Value for the id parameter so that you can see the output and further configure it:
    
13. Select Change Layout and select the one below:
    
14. You should now have something similar to:
    
15. Click on the news title field and display the Apply Styles Task Pane:
    
16. Click on .ms-sitetitle to apply that style to the news title field
17. Save the page

Configuration of the calling web part

Now, the web part displaying the news list needs to be configured to launch the dynamic page with the appropriate parameter. To do so, proceed as follows:

1. Open the web part page containing the web part listing the news:
   
2. Click on the news title field and on the attached menu, select Hyperlink in the Format as field:
   
3. Answer Yes in the next window; you should now have the window allowing to edit the hyperlink:
   
4. In the Address field, replace {@Title} with the full pathname of the dynamic page and append ?id={@ID} at the end to pass the ID of the news you want to display:
   http://sharepointserver/test4bernard/news.aspx?id={@ID}
5. Make sure that the Text to display field still contains {@Title}; manipulating the Address field also updates the Text to display field!
6. Save the page and… enjoy!

One of the essential piece of this implementation is the contexts list that records the characteristics of a context:

For each context, it contains the values that are required to filter appropriately the lists and libraries displayed on the page. But you may argue: why not doing that by simply passing the parameter values in the calling url? For the first context (aerospace), instead of launching the page with the following url: http://sharepointserver/test4bernard/home.aspx?context=aerospace
it would be:
http://sharepointserver/test4bernard/home.aspx?industry=Aerospace&contact=One

There are several reasons for not doing that:

• The most important one is to have url’s that are somewhat immune to organizational changes; in the example above, if the contact for aerospace has to be changed, only the contexts list has to be updated and not the url, which is quite important if the url is referenced from many other locations!
• Changes/updates are performed in one list only.
• If another list or library has to be displayed on the same page and if it uses different columns and/or different column values, a column can be easily added to the contexts list to accommodate to that new list or library.

Preliminary

The setup of the site columns, lists and libraries is very generic and does not require a detailed explanation.
A few items should be added to the lists to allow testing and viewing while building.

Context List

A context list similar to the one shown in previous article needs to be commissioned. To the minimum, it should contain the site columns that allow the characterization of a context. In our example, they are Industry, Solution and Keywords. In addition, a few other fields that may be useful on some of the pages can be added. In our example, they are Contact and Page Title. Contact allows a precise filtering of the contacts list to display only one leader on the context page while Page Title is simply used to assign the title of the page.

Dynamic Page

The template or dynamic page that will render the items relevant for the context selected needs to be built with SharePoint Designer (SPD). To do so, follow the next steps:

1. Launch SPD and open your site
2. Create a new empty page
3. Insert a data view for each of the lists and libraries you want to display on the page
4. In addition, insert a data view of the Contexts list and make sure it is hidden; your page should look like:
   
5. For the Contexts data view, define the context parameter as follows:
   
   note: the Default Value is not required but may sometimes help when building the page
6. Filter the Contexts data view as follows:
   
7. For each of the data views on the page, define parameters as follows:
   
8. Then filter as following:
   
9. Finally, for each of the data views, establish a web part connection with the Contexts data view. Follow the normal procedure and make sure you select Get Parameters From in the following window:
   
   and on the next window, map the relevant fields together as follows:
   
10. Accept all other defaults values
11. [Update: if you find that the next steps do not provide enough information, you may want to read another post where I detailed this extensively]
    To use the Page Title from the Contexts list and display at the top of the page, allow custom content in the PlaceHolderSiteName content place holder, replace the default data with a data view of the Contexts list and configure Page Title as the only field to be displayed
12. To filter and display the appropriate Page Title, you can either add another web part connection as explained above or retrieve the context directly from the url; in such case, add the context parameter as follows:
    
13. and filter the Contexts data view as follows:
    
14. Select the Page Title field and, in the Apply Styles task pane, select .ms-sitetitle as style:
    
15. Save your page and test it with some of the contexts defined by using an url similar to:
    http://sharepointserver/test4bernard/home.aspx?context=aerospace

What’s next

In the next article I’ll explain why I’m using a Contexts list instead of providing all parameters in the calling url.

In the previous articles, I briefly shared some of the reasons to deploy one or more site collections, the advantages and disadvantages of using sites, lists/libraries or columns to group resources and the overall approach we use to power communities from a collaboration and publication perspective.
In this one, I will introduce the concept of contexts. This is the way I work to group related resources and display them together through dynamic pages.

Scenario

The following example shows how to handle and display items (news, resources, contacts) that are relevant for several contexts (industries, solutions).
A company ABC sells solutions that are applicable for several industries. In addition, it runs initiatives or programs that span across those industries and solutions. News, documents and contacts are respectively stored in one announcement list, one document library and one contact list (for the sake of simplicity). They are all tagged by means of site columns values that allow to categorize them by industry, solution and keywords (used for initiative here).

The page below displays news, resources and contacts that are relevant for a specific industry:

Other visitors might not be interested in the industries and want to concentrate on one of the solutions only:

Or they might look for resources than span across all industries and solutions and that address a specific domain:

Overview

The following summarizes how this is achieved:

1. industry, solution and keywords (for generic use) site columns are created
2. lists and libraries for news, resources, contacts are configured with those site columns
3. items are added and tagged with site column values
4. a context list is created and used to store context definitions; it looks like:
   
5. a web part page containing a data view web part for each of the sections to be displayed is used; it also contains a web part of the context list that is hidden and connected to all other web parts. The context web part retrieves the context value from the url, filters the context list based on that value, and, via the web part connections, filters the values of all the other lists (news, resources, contacts). Here is how the empty web part page looks when there is no context assigned:
   
6. by invoking this page with the desired context, it renders the resources according to the context definition. For the first screen above (Aerospace), the following url is used: http://sharepointserver/test4bernard/home.aspx?context=aerospace
   This is the link that is used in the left navigation to access the Aerospace page

What’s next

In the following articles, I will enumerate the reasons for using such context list and explain some of the technical aspects of the implementation.

Introduction

Within a site collection, many choices exist to group resources together:

• documents and presentations may be stored in separate sites because they are managed by different people, are presented differently to the users or require completely different metadata
• or they may be stored in separate libraries within the same site
• or they may be grouped together via distinct column values within the same document library

There are several reasons to choose one approach instead of another and, keeping in mind recommendations made by Microsoft (see Plan for software boundaries on Microsoft Technet), I’d like to share some of the advantages and disadvantages I’m looking at when selecting an approach.

Sites

The main advantages of managing distinct resources in separate sites include:

• a total flexibility for the look and feel, the lists and libraries, the columns, the content types, etc…
• the availability of some of the site administration features to control and monitor access to the resources

The disadvantages include:

• the need to build consolidated views if some of the distinct resources need to be presented together
• the need to hide or simplify the navigation through the more complex structure
• the need to provision the sites for each of the resource types

Libraries

The main advantages of managing distinct resources in separate lists or libraries include:

• a simplified data entry due to a reduced set of columns (in comparison with a single library requiring assignment of column values to differentiate items)
• the possibility to use different columns, columns values and content types
• the possibility to populate via mail (which is also possible with a single library but requires manual intervention to categorize items)
• the possibility to apply different permissions and management features

The disadvantages include:

• The need to build consolidated views if some of the distinct resources need to be presented together
• The need to provision the lists or libraries for each of the resource types

Columns

The main advantages of categorizing distinct resources in one list or library include:

• only one location to handle resources
• views can be easily created
• permission and management from one location

The disadvantages include:

• less flexibility with columns and content types
• the same permission and management for all items

Conclusion

Depending on the needs to use same/different presentation, columns, content types, permissions and management features balanced with an effective navigation and an effective way of handling the resources (documents upload, editing or download), I will go with one of the approaches and, sometimes, a combination of those might be the best way to go.

In the next article, I will introduce contexts. This is the way I work to categorize related items and display them together with dynamic pages.

Ideally

In the scope of a community, the preferred choice would be to work with one site collection because of the many integration possibilities available and the simplified administration. Within one site collection, it is easy to:

• Manage resources in separate sites, lists or libraries while being able to easily display them together
• use similar metadata and content types across all sites, lists and libraries
• control the look and feel from one central place

At the same time, one single site collection provides simple administration by allowing users and permissions, galleries, settings, reporting and logging to be controlled from one place.

Such choice is also driven by IT constraints and should carefully be planned by taking those into consideration. In a nutshell, they include: database size, backup and recovery and capacity planning. Several excellent articles are available about this specific topic, and I can only recommend you to look at Tips on Site Collection Sizing by Joel Oleson and Plan for software boundaries on Microsoft Technet.

In practice

In reality, there are chances that site collections supporting similar communities may already have been deployed in another group or geography. They may provide a subset, a similar or quite different list of the resources planned in your new community. People in your group may be aware of this community, already use some of their resources, and, as your role is to help leverage data and information across the company, you probably have no other choice than providing some level of integration with those existing site collections.

So, instead of spending too much time in carefully designing your site collection, taking into account its space consumption usage, its backup and recovery constraints, etc… I would rather recommend to concentrate on the possibilities your site collection will have to integrate with other site collections. This will avoid endless discussions because, sooner or later, due to an organizational or people change, you will have to reconsider your original design and, either split the resources managed or on the contrary, consolidate with other resources.

Conclusion

Site collections provide numerous possibilities to manage community resources together while still allowing the possibility to handle and present them in separate contexts via separate sites, lists, libraries and pages. You should use those as much as you can, but do not expect to support all possible scenario’s. Integration with other site collections should be part of your original design to allow a flexible and adaptive architecture. In addition, that will help when you will have to integrate with repositories or tools that are not running on SharePoint.

See also

• Determining Between SharePoint Site Collections and Sub-Sites by Steve Goodyear
• Determine sites and subsites needed on Microsoft Technet

At the highest level, they are:

• the sites provisioned for a group, business unit or a geography
• the lists and libraries used to store resources (documents, presentations, videos, …) containing data and information
• the pages and web parts used to consolidate and display resources

To support our strategy, there is a need to use specific features to display context dependent resources that are stored inside or outside the SharePoint community home site. Out of the box, many exist, but here are the ones we currently use:

• email enabled lists to automate and facilitate content contribution
• columns or metadata to tag and display items
• content types to handle different types of resources
• views to support the browsing experience
• search to support the search experience
• managed properties to reconcile or workaround different naming
• filtering to display context relevant resources
• data view web parts for specific and custom displays
• rollup web parts and linked lists to display related resources stored in the same site collection
• search core results web parts and web capture web parts to display related resources stored in other site collections
• RSS and web services to access resources stored in other vehicles (repositories, platforms, …) 
• distribution lists and discussion boards to support threaded discussions

Combining and using all those allows to create community portals where relevant resources are displayed together. This can be summarized in the figure below where the Sub Site 1 visitors can access resources located on Sub Site 1, 2, 3 and Other Platforms through the View 1, 2, 3 and 4 respectively.

In the next articles, I will describe in details how we use each of those features to reach our goals and, more specifically, I will start with the choice between one or more site collections.

Understanding the need to share information, the diverging characteristics of communities and the many different natures of people we work with, our approach balances a global strategy with an acceptance and support of local or group initiatives and this, for the following reasons:

• some people are early adopters or have such specific needs that you cannot include them in the planning phase of your project
• technologies may be in place already or land in the company after an acquisition
• the knowledge assets community members handle may be a mix of official assets stored in corporate repositories and temporary assets stored in project workspaces
• there is always a need to communicate and collaborate beyond borders, even in such disparate environments

Before diving into more details let’s have a look at the following diagram that summarizes the way people access information:

It helps agreeing on a terminology and understanding where we can have an impact within our organization:

• for the reasons listed above, many of the vehicles are a given in our case; SharePoint was also a given, but due to the good relationship we have with our IT partners, we still can have an impact on the way it is deployed and configured
• the functions is really where we spend most of our time. Using the vehicles as a set of building blocks, we assemble or build functions that power the communities
• the resources are not in our hands, but we have a role to inform, educate, motivate and support people handling those
• the information is the responsibility of the knowledge workers

In practice, the following areas are where we produce most of our deliverables:

• interface with corporate tools and group workspaces
• maintenance and publication of a minimal common vocabulary
• aggregation and presentation of community specific assets

The next article will list the principles and techniques used to support our strategy before addressing more specific aspects.

With this post, I’d like to introduce a set of articles where I will share my observations, the tools and techniques we deployed to improve communication and collaboration within our group. It should not be considered or perceived as a set of standard rules for the company I’m working for, but rather as a set of experiences that worked within our group and that may be valuable for other groups or companies.
By documenting those experiences, I not only hope that other people will benefit from the lessons learned but I also hope to get feedback or reactions on the information provided. That would allow to confirm the content by capturing similar observations from other groups or, on the contrary, introduce other approaches or techniques that may be better suited. Hopefully, as a consumer of the information, you would benefit from the experience of several people instead of just one individual.

Background

The many years I spent in the role of knowledge management lead in an international company learned me to live with, support and improve the many different ways people communicate and collaborate. In a big company, this is a given, because people are:

• at different maturity levels when it comes to information technology usage : some can just use email while some others embraced Web 2.0 technologies from the beginning
• talking different languages, using different vocabulary or simply naming the same things differently
• in a different level within the company, meaning they may care about global aspects or on the contrary, concentrate on local (region, country) aspects only
• simply not able to devote a lot of time to communication and collaboration because overloaded or understaffed

In addition, the group they are part of and that need to collaborate with other groups may:

• have different business objectives or measures
• have different rules in terms of communication and collaboration
• use different repositories, tools or technologies

Role

Since those many years, my role has been and still is to design and deploy a collaborative environment that help groups reaching their business objectives by giving them the tools to:

• work collaboratively on content
• capture valuable assets
• publish best practices and official information
• reach or engage with all community members
• access data and information relevant for their group but contained in other repositories

Such role implies a continuous dialog with business leads, subject matter experts and knowledge workers. That is only possible by attending regular group meetings, working on real projects and prototyping solutions addressing their issues and objectives.

Scope

The articles will cover SharePoint design and deployment aspects from a “business” point-of-view and not an IT point-of-view. This means that I will explain the features and technologies we deploy to fulfill our users needs but not the ones that may be of interest for an IT audience. Topics like site collections choices, aggregated views, columns and content types, discussion boards, etc… will be addressed while IT topics like installation, database design or server farm configuration will not be covered.
In the next article, I will introduce the scope of our work and the overall approach used.

See also

SharePoint: the backbone of your information architecture by Rob Koplowitz and Leslie Owens in KMWorld.