—George Bernard Shaw

How do you handle content not contained within a file, not in a discrete unit? Not all enterprise content exists within a document; pieces of content can also be strings of text published on a web portal. In this chapter, I provide an overview of web content management (WCM) concepts and I walk you through how to configure WCM in a SharePoint 2013 publishing portal. I also discuss how to model and configure a publishing approval workflow and how to manage the content deployment settings and schedules.

After reading this chapter, you will know how to

• Explain web content management concepts.
• Analyze your web content management requirements.
• List web content management features in SharePoint 2013.
• Create and configure a publishing portal.
• Model and configure a publishing approval workflow.
• Manage content deployment settings and schedules.

Overview of Web Content Management

A popular way to publish content to a large audience is to post an article or a similar type of web page on a web site, such as an intranet portal or a company’s public web site—a process known as web content management, or WCM. This concept has been around for years, as organizations have maintained internal intranet portals to communicate with their employees, and external public web sites to communicate with customers, investors, and other stakeholders. Companies with products for sale have also maintained e-commerce sites with product catalogues, shopping carts, and credit card processing capabilities.

Over the years, these types of web sites have become both more sophisticated and more feature-rich. This has been partly enabled by the enhancements and technological advances in the underlying web technology and its supporting programming languages. It has also been fueled by the organization’s desire for competitive advantage through leveraging the technology along with custom application development, driven by creative ideas and solutions.

At its essence, web content management has always involved publishing a web page to a web server. Some web sites still post individual pages manually by copying an HTML file to the site’s directory on the server. Other sites include a system-managed or data-driven way to publish pages to the web server, especially with modern web applications and large sites. In either case, the process is the same: someone authors the content and then the content is published to the web server where users can access and consume the content. Figure 7-1 illustrates the process of web content publishing.

Whether done manually or through a system process, this is the essence of web content publishing. Not too long ago, it used to be so common for people to manually manage their sites and all its pages. So much so that I would often see sales and marketing material promoting web content management systems with concepts such as the ability to standardize page layouts and the publishing process, all with minimizing IT involvement while removing the need for specialized web designer skills to post content. This exciting transformation empowered regular users to manage web content for their own sites. As a testament to how quickly technological advances become commonplace, now rarely do I hear these benefits stressed.

Nevertheless, these end-user productivity and empowerment features are still beneficial, and they form the basis of any quality web content management system. Organizations have leveraged and built on each other’s ideas, ultimately evolving WCM into an industry with mature software products providing a platform for standardizing and automating many of the functions in a web content management solution.

Microsoft developed SharePoint 2013 to provide one of those platforms. As I mentioned in Chapter 2, one of its core capabilities is web content management. The product team solidified and matured this capability back in SharePoint 2007 when Microsoft retired Microsoft Content Management Server (MCMS 2002) and consolidated its capabilities within SharePoint, and the product team has continued to enhance this capability with each major release.

The tool exposes these page-editing features with a rich user experience, one consistent with the Microsoft Word text editing experiencing, including a ribbon with a range of formatting options. It also enables end users to select from a range of different page layouts available to manage the format and design of the overall page by simply selecting options in a drop-down menu.

SharePoint leverages its WCM capability to support a variety of features, including article and portal pages, welcome pages, and wiki pages. It also includes, among other WCM features, content deployment capabilities, which copy and deploy content from a draft state in an authoring environment to a published state in a production environment. Figure 7-2 illustrates a typical content deployment process involved in a SharePoint WCM solution.

Content deployment is useful because it separates the domains of content authoring from content consumption. Users who consume published content access read-only pages, while content authors collaborate on pages in a read-write site. This separation enables you to focus each environment on a variety of options that are specific to the content authoring and consuming experiences, including:

• Targeting high-performing hardware for the published content and its larger number of users.
• Processing a publishing workflow with steps such as editing reviews and approvals.
• Testing and validating content prior to making it available to a wider audience.
• Scheduling the release of published content.
• Managing content translation processes for each locale site with alternate languages.
• Segregating security for the content authors and draft content from the published content.

This last point on security is particularly interesting, especially if you have two different environments for your draft and published content. You can lock down your environment with read-only published content, limiting privileged access and adding an extra layer to defend against potential attacks since the farm would be a read-only copy of content authored elsewhere—an especially valuable aspect for public internet-facing web sites. Your authoring environment then can be behind firewalls in a more controlled and secured area of your network.

I also like having the ability to schedule the publishing of an article or web page. This alleviates the need to remember and make someone available to manually publish a page at a desired time. Many pages will be relevant right away, and so you will not have a need to schedule them because you are publishing them as soon as the page is ready. For those other pages, such as organizational announcements that you want to prepare ahead of time but schedule for release at a particular time in the future, then you can schedule a time to publish them as part of the content deployment process.

Another characteristic of web content management is the automatic management of navigational elements and the aggregation of content. Previously, a webmaster would have had to manage and update these links manually. Then eventually software began to offer easier or more productive ways to approach this, such as using templates or reusable widgets shared across several pages. As web sites became more and more data-driven, sites could also keep track of structures and relationships between pages, enabling pages to query this data to automatically show navigational menu items, all without requiring a webmaster to manually maintain a list of navigation items.

Although WCM is nothing new, it has grown increasingly sophisticated in its capability, particularly as the management of web content has become less and less centralized with users directly creating, editing, and publishing their own content. Despite the ease of content authoring, web content can and does still contain units of information that are just as relevant to archival, legal, and regulatory compliance requirements as the documents I discussed in previous chapters. You can organize and manage the different types of pages and their life cycle by treating them as yet additional kinds of content, managed through SharePoint content types.

Because you treat web content no different than any other piece of content in your enterprise content management solution, I am not going to repeat the details of those concepts I discussed in the previous chapters. It is just another unit of information that you can associate metadata, workflows, retention policies, and the like as part of your organization’s content life cycle. This is an important point and I am stressing it here because web content such as simple department article pages or ad hoc wiki pages are easy to overlook when analyzing an enterprise’s content life cycle.

Web content management is a concept, the essence of which is making content available for users to consume through a device over the network. A web content management system automates and simplifies a lot of those management activities while enhancing the experience for end users to author and publish their own content. As I already mentioned, a core capability in SharePoint is a web content management system, but before I cover its features in more detail, I want to look at how to analyze your WCM requirements.

Analyzing Your WCM Requirements

There are certain considerations to designing any web site, such as how to structure it, how to lay out the pages, what color palette and fonts to use, and the like. These are useful and worthwhile activities for SharePoint portals as well, and I have already discussed how to plan your site structure back in Chapter 4. Your portal site structure is just an extension of the content containers—the sites, lists, and libraries—to also consider the different pages that will display content and communicate information. I drive my structure and other design decisions based on my purpose for the portal site and the user experience that will support that purpose.

This is not a book on web design, so I will leave that to one of the many other books on the topic. However, a couple design elements are important to enterprise content management. In particular, I am thinking of the different web parts that you may include on a page to aggregate content, providing recommendations for related content or other content discovery scenarios. I discuss content discovery more in Part III, but for now, it is important to consider site pages for their content as well as the different page elements that you can add to the user experience, creating a sort of mash-up with feeds and other assets such as images and video.

Other elements that you can add to pages include reusable or catalog content. This allows you to use metadata not just for organizing the structure, but also for rendering the content itself. You can implement this through the SharePoint 2013 feature, cross-site collection publishing. I discuss this feature more toward the end of the chapter where I note how to configure catalogs and I share examples of web applications that you can create using cross-site collection publishing.

The elements on the pages and their relationship with each other represent the user experience in your design. For web content management applications, this represents a major portion of your design requirements. As you conduct your analysis, you can begin to identify different page elements in your requirements along with details about the source of the content. As I collect this information, I like to create diagrams or mockups to get a general sense of how a page functions and how the different elements interact with each other.

One tool that I find particularly useful for designing layouts of pages is Balsamiq Mockups. Without much designer investment, it offers a quick and visual way to lay out page elements, allowing you to experiment with different designs and user experiences with a low-cost and low-fidelity mockup. Not only can it communicate the essence of a given design experience on a page, but it can also link pages together to mockup the user experience between pages as well.

You can use Balsamiq Mockups or a similar tool to start laying out ideas and to verify design assumptions early on in the process, when making changes is cheap and even encouraged to fine tune and reveal the best design. I use this mockup tool for any user experience I am designing for an application, and especially for portal applications. Figure 7-3 shows an example of a SharePoint portal page mockup with video page elements. As you can see, I have the gist of the page mocked up where users can get the sense for what will be on the page and how it works together. It is not an exact representation, and visually, it looks quite a bit different from a SharePoint page; nevertheless, I bet it looks familiar to you as a SharePoint page. It has enough of the elements there to communicate the design and gather feedback without over-investing in the design activity.

I like to start with analyzing any existing sites and portals. This review gives me a sense for how my clients have organized their portals in the past and the types of content they publish there. I keep an eye out for both things that have worked well and things that have been more problematic. This can reveal clues about what the new portal should continue to build upon and what it should improve. Some questions I like to ask during this review and analysis include

• What are the different areas within the portal?
• What types of pages are in those areas?
• What kinds of content do those pages contain?
• Who authors and publishes content?
• Are approvals required, and if so, who approves content?
• Is content regularly updated?
• What areas are the most popular?

From an enterprise content management perspective, you will also need to consider how to classify the web content if a classification system does not already exist. A classification system includes metadata from your enterprise taxonomy and keyword metadata in a folksonomy, where appropriate. This can help you design how to organize your pages in a similar fashion as I discussed for documents, but it can also help with designing your web content’s life cycle.

As you analyze the content life cycle for portal pages, you need to identify their retention and disposition requirements. You may have completed this as part of the content inventory I discussed in Chapter 3, but if not, it is important to start grouping web and article pages into common content types just as you would for other kinds of content. This allows you to generalize and manage metadata, workflows, and other policies for groups of content rather than for individual pages.

Ultimately, as with any application, you want to answer the question of what purpose does it serves. What is the main goal the portal seeks to achieve? What is its vision? Shaping your requirements around a higher-level purpose will steer your designs toward delivering the value that relates to the purpose.

Rather than looking at product features and finding ways to enable them, I always like to start with requirements and make feature and implementation decisions from them. With a general idea about the web content management application’s purpose and design structures, you can begin to consider what aspects and features in SharePoint can support your portal. Let’s shift now to look at those WCM-specific features in SharePoint.

SharePoint 2013 WCM Features

Along with all of its collaboration features, SharePoint 2013 also includes a rich feature set for publishing web content, whether for internal intranets or for public web sites. Web content can include rich media assets, such as video or images, the same as collaborative content. It also includes text-based content, which has traditionally made up the bulk of a web site in the form of HTML pages. SharePoint can store and host entire HTML pages in a site, but much more commonly, it stores the text for the page’s body content and it merges the text with template-like files to render the resulting page output.

By separating these into multiple files, SharePoint separates the content from the layout and design. The page itself includes the body content and any other header or metadata information. SharePoint then merges the page content with a page layout, which specifies the layout on the page for content and any web parts. SharePoint also merges an ASP.NET master page, which specifies the overall page structure. Figure 7-4 illustrates the relationship of these page elements in rendering a publishing page.

Page rendering is the core publishing feature in SharePoint. Indeed, posting pages with web content on the network for users to access and consume is the essence of web content management, as I have mentioned. But SharePoint does not stop there, as it also includes a bunch of additional features to enhance the user experience, including:

• Navigation: A global navigation that can infer the navigation nodes from the site structure or a site administrator can customize the menu items through the site settings. You can also configure managed navigation for a site, which associates a site’s navigation nodes with a managed term set and allows you to manage navigation structures from a centralized location.
• Pages library: A site library the portal site uses to store and manage web pages and their content life cycle.
• Site columns and content types: Special site columns are added to support publishing features, such as Page Content, Scheduling Start Date, and Scheduling End Date. Special content types are added to support creating publishing content, such as Page Layout, Article Page, and Wiki Page.
• Design Manager and design packages: This enables designing and editing custom design assets in HTML and then having SharePoint convert them into SharePoint resources. The design manager provides an interface for managing all aspects of branding your site. Figure 7-5 shows the Design Manager option to select a preconfigured look.

• Template files: Master pages, page layouts, and display templates all allow you to customize the overall behavior and appearance for the site. These elements represent the core of the implementation details for your site branding assets. Figure 7-6 shows the ability to manage master pages through the design manager.

• Device channels: This allows you to target rendering a particular user experience for different devices (such as iPhone, Android, or Windows Phone) or to groups of devices (such as all smartphones).

• Publishing web parts: This includes web pages to support the display of publishing-related data and portal-related user experiences, such as Content and Structure Reports, Content Search, Content Query, and Taxonomy Refinement Panel web parts.
• Variations for multilingual sites: This supports creating multilingual experiences by targeting content to specific audiences on different sites. You can use machine translation to translate page content or another translation service, including human translation processes.

• Approval workflows and publishing scheduling: Approval workflows enable you to route content to stakeholders for review and approval before publishing it to the portal. Scheduling functionality allows content authors to create content and schedule its release to the portal for a future date and time.
• Caching: The page output cache stores page outputs and frequently accessed content in memory to improve processing performance and load times for pages by reducing the amount of content SharePoint needs to retrieve from the database.

All of these features work together to provide a rich user experience with cohesive WCM publishing capabilities. I wanted to provide you with a highlight of the key WCM features in SharePoint to give you a sense of what is happening in SharePoint publishing sites. Now you are ready to create a publishing portal.

Creating and Configuring a Publishing Portal

Publishing portals are SharePoint sites with publishing features activated. Activating the necessary publishing features will equip your publishing site with those features I noted in the previous section. The product team has made this easy for you by offering a few site templates on the Create Site Collection page, as shown in Figure 7-7. You can create your publishing portal with one of these templates and SharePoint will activate the required publishing features for you.

The three built-in templates for publishing sites are:

• Publishing Portal: A portal site with the SharePoint publishing features activated and an approval workflow enabled. You can use this site collection as a starter portal and then add custom branding to customize the look and feel of this site.
• Enterprise Wiki: A wiki site with easy content editing and co-authoring to capture and publish knowledgebase articles.
• Product Catalog: A site with list or library catalog data to share for cross-site collection publishing and administrative pages for managing faceted navigation for catalog items.

The Publishing Portal template provisions a general publishing site. Figure 7-8 shows an example of the default welcome page for a site created based on this template. This welcome page is meant to guide you through setting up your publishing portal with links to the most common tasks. After you create and configure a site based on this template, you should edit this page’s content to make it more appropriate for end users.

Of course, you do not have to start with any of these templates in order to create a portal site. As I mentioned earlier, every site is merely a team site with additional features activated, and a portal site is no different. You can create a portal site out of a default team site template by activating the following publishing features:

• SharePoint Server Publishing Infrastructure (site collection feature)
• SharePoint Server Publishing (site feature)

After those features are activated, either manually on a regular site or as part of a site provisioned based on one of the publishing templates, then you can begin to publish portal pages. As I mentioned, one element involved in rendering a portal page is a page layout. You can select the page layout from the ribbon while editing the page, as shown in Figure 7-9.

You can also edit the metadata to include in a publishing page’s HTML head section. Click the Edit SEO Properties option in the Edit Properties menu on publishing tab of the ribbon to open the SEO Properties page as shown in Figure 7-10.

Publishing pages have several other configuration options available on the ribbon that I will leave for you to explore and experiment with. They can help you enhance or fine-tune the publishing experience for your portal, but one in particular is especially useful for supporting publishing processes: the Publishing Approval workflow.

Configuring a Publishing Approval Workflow

I first mentioned SharePoint workflows back in Chapter 2, and they are certainly common in publishing portals. The most common workflow requirement for publishing portals is approval workflows, so much so that the product team included a built-in Publishing Approval workflow to meet this requirement.

Publishing workflows can grow to be quite complex, depending on your publishing process and other needs. For example, a publishing process might include a series of editorial and copyediting reviews before an article is ready for approval and publishing. You could create a workflow or edit an existing workflow template using SharePoint Designer 2013 to include these additional steps in the workflow.

To illustrate the workflow capabilities and configuration options, I will walk you through the steps for the default Publishing Approval workflow in SharePoint. Although this is a basic workflow template, it does handle the vast majority of approval requirements for publishing sites, particularly for those new publishing sites that have not had any workflow capabilities in the past. In only a few steps, I will walk you through how to configure an approval workflow to handle the process illustrated in Figure 7-11.

To add a publishing approval workflow to your publishing site, follow these steps:

1. Activate the Publishing Approval Workflow site collection feature.
2. Navigate to the Pages library settings page.
3. Click Version Settings and select the option to require content approval. Click OK.
4. Click Workflow Settings and then click Add A Workflow.
5. In the Workflow section, select the Publishing Approval workflow template, as highlighted in Figure 7-12.

   

   Figure 7-12. The Add A Workflow page with the Publishing Approval workflow selected

6. In the Start Options section, check to start the workflow to approve publishing a major version. Click Next.
7. Enter the Approvers for the workflow by entering a user or a SharePoint group to the Assign To field, as shown in Figure 7-13.

   

   Figure 7-13. The workflow details page for the Publishing Approval workflow

8. Configure the other fields as desired and check the option to Enable Content Approval. Click Save.

When authors create a new portal page and submit it for approval, they will see a status on the page similar to Figure 7-14.

The workflow will create a task for the approvers to review and approve or reject the submitted page. Figure 7-15 shows the task details for an approver to review. The task links to the page itself for the approver to review, and it includes a place for the approver to add additional comments. Approvers have the option to approve or reject the page right from the task details screen, and they can also request changes to the submitter or reassign the task, all as part of the Publishing Approval workflow.

Workflows enable you to automate processes involved with publishing content to a portal site. However, in some cases you may want to author content in an isolated site collection with limited access and then publish the content to another site collection for general access. SharePoint manages this scenario through a feature referred to as content deployment.

Managing Content Deployment Settings

You use content deployment to deploy content from one site collection to another site collection. This deploys a copy of all the content selected in the source site collection to the destination site collection, and optionally a copy of any security settings. The source and destination site collections can be in the same farm or in different farms.

Two key concepts for configuring SharePoint content deployment are paths and jobs:

• Paths: A content deployment path defines the relationship between a source and destination site collection. You need to create a path first, and then you can associate a job with the path to schedule the content deployment.
• Jobs: A job defines the specific content in the source site collection that you wish to deploy to the destination site collection. It also includes the content deployment schedule settings.

To enable and configure content deployment for a site collection, follow these steps:

1. Activate the Content Deployment Source Feature site collection feature on the source site collection where you want to deploy content from.
2. Navigate to the SharePoint Central Administration site on the destination farm and click the General Application Settings section link.
3. Click the Content Deployment Settings link.
4. Select the option to accept incoming content deployment jobs. Click OK.
5. Navigate to the SharePoint Central Administration site on the source farm and click the General Application Settings section link.
6. Click the Configure Content Deployment Paths And Jobs link.
7. Click New Path to navigate to the Create Content Deployment Path page shown in Figure 7-16.

   

   Figure 7-16. The Create Content Deployment Path page

8. Enter a name for the path and select the source web application and site collection.
9. Type the URL of the destination SharePoint Central Administration site. This can be for the same farm or for a different farm. Click Connect.
10. Select the destination web application and site collection. Click OK.

     Important  The source and destination site collections must exist in different content databases.

11. On the Manage Content Deployment Paths And Jobs page, click New Job.
12. Enter a name for the job and select the relevant path. Check the option to run the job on a schedule and enter the desired schedule.
13. Click OK to return to the Managed Content Deployment Paths And Jobs page, where you should see the newly created path and job listed similar to Figure 7-17.

Content deployment takes a copy of the content and deploys it to another site, which is great in many publishing scenarios, but in some cases you just want to reuse content on different sites. SharePoint enables content reuse through the cross-site collection publishing.

Configuring Cross-Site Collection Publishing

The cross-site collection publishing feature provides you with the ability to use one or more authoring site collections to author and store content that one or more publishing site collections can then display the content. Where authoring site collections are responsible for the content itself, publishing site collections are responsible for the UI and site design to display the content.

Cross site-collection publishing works through the SharePoint search service. The search crawler will crawl the content in the authoring site collection and include it in the search index. Once search indexes the authoring site collection content, then it is available for the publishing site collection to query and display the content in a web part on its page. Figure 7-18 illustrates the relationship of content in cross-site publishing using two separate SharePoint farms (although they could be two different site collections in the same farm).

Authoring and publishing site collections work well with managed navigation. Term sets you use for tagging content in an authoring site can also be pinned to the navigation term set used by the publishing site. With this setup, you can display relevant content based on the navigation node a user selects. This adds to the dynamic and data-driven aspects of your published site and is one of the primary uses of the managed navigation feature in SharePoint 2013. Cross-site collection publishing benefits to your portal site designs by:

• Providing a range of site and information architecture options.
• Separating content authoring from branding and rendering.
• Allowing for content reuse across user experiences.
• Sharing content across site collections, web applications, and farms.

You can author content in one environment and then create a data-driven publishing site to display the content using metadata filters and managed navigation. The following lists some possible scenarios and applications for using cross-site collection publishing:

• Product catalogs to show product information based on metadata
• Job catalogs to show details for available job postings
• Contact catalogs to show individual contact details
• Policies and procedures catalogs to show policy articles
• Knowledgebase catalogs to show knowledgebase articles
• News and announcement catalogs to show news articles
• Case study catalogs to show case study articles
• Location catalogs to show building and office information

By sharing specific lists and libraries as catalogs, you can then reuse the list items on one or more publishing sites. You can share every list as catalogs, but you cannot share every library as catalogs for cross-site collection publishing. The reason for this is because the feature relies on search to crawl and index text and HTML content, rather than BLOBs. The following lists the specific lists and libraries that you can share as catalogs:

• Pages library: A pages library can store any HTML content for reuse in publishing site collections. Storing content in this library also enables you to use the approval workflow for list items.
• List: A list stores any type of list item that you want to store in a list rather than a pages library.
• Asset library: An asset library can store files such as pictures, audio, and video files that contain content to display on the publishing site. These files are stored in the BLOB cache, not the search index, which means that the publishing site will not display them in the same manner as other content. Publishing site users will also need read access to the asset library.
• Document library: A document library can store files such as Word or Excel documents that. Because these files are not HTML content, you treat document libraries in the same manner as asset libraries.

Before you can reuse content in a list or library in publishing site collections, you first have to share the list or library for use as a catalog. When you share a list or library as a catalog, you can choose to enable anonymous access to the content, which fields uniquely identify the catalog items, and a managed metadata field to use as a navigation term in the publishing site collection. You must add at least one item to the list or library before you can share it as a catalog.

To enable cross-site collection publishing, you must activate the Cross-Site Collection Publishing and Cross-Farm Site Permissions site collection features. Then you can navigate to the desired list or library settings page and click the Catalog Settings link to navigate to the Catalog Settings page, similar to Figure 7-19.

Once you have shared the catalog in the authoring site, you can configure a catalog connection in the publishing site collection to consume the catalog. When configuring catalog connections, specify the catalog to use to display content from, the term set used for tagging, and how to construct the category item URLs. You can then display the content using category pages and catalog item pages, which are page layouts used for showing structured catalog content consistently across a site. You can display the catalog content in several ways, including:

• Adding the Catalog-Item Reuse web part to a page and then configuring the web part properties with a custom search query.
• Adding a publishing page using one of the Catalog-Item Reuse page layouts.

Wrapping Up

Web content is a unit of information just like a document is, and as such, you treat it the same as any other piece of content when analyzing and designing your enterprise content management solution. Web content management is a subset within the larger scope of enterprise content management, making it important to include in your ECM initiative to prevent any gaps in your content life cycle requirements. In this chapter, I described WCM as the process to author and publish content on an intranet portal or public web site, whether this is an automated or manual process. I then listed the main WCM features in SharePoint 2013 and I provided guidance on planning and configuring a publishing portal. Finally, I discussed specific publishing topics related to approval workflows and deploying content.

Portals contain a significant amount of content beyond the reports and other types of documents that one might typically think of when considering enterprise content management. Articles and other types of information posted on a portal also participate in your organization’s content life cycle, and so they need to be managed with appropriate policies and workflows. Similarly, your organization may contain paper or electronic forms to capture information and support a business process, making these units of information critical to consider and include in your enterprise content management solution. In the next chapter, I focus specifically on designing and managing electronic forms using InfoPath, using which can open new possibilities to replace paper-based forms and processes with an electronic form solution integrated with your ECM platform, SharePoint.