SharePoint 2013: Does it finally crack the code of WCM?

Ever since Microsoft began adding Web content management (WCM) capabilities to SharePoint in 2007, customers have been asking themselves when Redmond would get serious about providing a platform suited not just for intranet use cases, but for marketing-oriented websites as well.

With the advent of SharePoint 2013, it’s time to reassess functional improvements, and evaluate whether Microsoft has truly expanded the product’s target scenarios for Web publishing.

Below I’ll describe the implications for changes in SP 2013 in some key areas:

• architecture,
• development,
• content authoring, and
• visitor engagement.

There’s more to add, of course. For a complete evaluation and competitive comparison, you can consult Real Story Group’s Web CMS Report. But these four categories will give you a decent sense for where Microsoft has gone with respect to WCM.

Architecture

SP 2013 brings some new twists with an updated architectural approach called “cross-site publishing.” The name implies a solution to the old SharePoint problem of the inability to share content across site boundaries easily; in fact—for better or worse—it is much more than that. Using this approach, you separate authoring and publishing into different collections; content authored goes into an indexable “catalog,” and then you use FAST to index and deliver dynamic content on a loosely coupled front end.

It’s important to understand how cross-site publishing works, because—although it’s generally optional—it’s definitely required for certain new approaches you may see in SP 2013 demos for services like personalization, localization, metadata-driven topic pages (like you find in Drupal) and more. The reference case for it is a genuine product catalog in an e-retailing environment, but Microsoft wants to extend the paradigm for nearly all dynamic content more generally. Note that cross-site publishing is not available in SharePoint Online.

Here’s how it works. First, you designate a list or library as a “catalog.” FAST then indexes that content and makes it available to publishing site collections” via a new “content search Web part” (CSWP). Microsoft has put some good thought into creating and customizing CSWP instances, including some browser-based configurations. In theory, runtime queries should execute faster against the FAST index than against a SharePoint database.

There are several downsides to this approach:

• Serving dynamic content via the search index has been controversial in the CMS world, mostly because it can require advanced knowledge of your search subsystems and associated security, metadata and performance settings, and it engenders greater unpredictability with various moving pieces.
• As just one example, there are bugs and inconsistencies in the FAST indexing process, such as overriding explicit metadata with implicit values, which leads to unexpected results in the presentation tier.
• There is no readily apparent way to override or reorder dynamic lists in the delivery environment, which is an increasingly important content curatorial feature.
• Preview, testing, publishing and caching can become a fraught process due to various latencies. By default, the FAST crawler runs every 15 minutes. Some customers have bumped it to every minute, but that will surely have performance implications on larger collections. You cannot push content to FAST; it needs to come to you. There is no “immediate publish” in this scenario; to be fair, it can present a challenge in competing systems that also do batch publishing jobs.
• Binaries need to be stored in a single, separate location in the delivery tier. In other words, there’s no separation of concerns with this class of content, and no notion of publishing. You need to wire that carefully into your authoring and delivery interfaces, with appropriate security and access controls, as well as naming and directory schemes, which should be planned in advance.

Development and templating

Notions of templating still begin with a “master page,” an ASP.NET construct that defines the basic page structure—headers and footers, navigation, logos, search box and so on—essentially the chrome of your site. Traditionally, this is where things got tricky in SharePoint, because master pages tended to contain a lot of cruft by default, and “branding” a SharePoint publishing site was somewhat of a dark art.

In SP 2013, Redmond has certainly improved things, most notably via a new “Design Manager” module, which is essentially a WYSIWYG master page/page layout builder. Design Manager is essentially an ASP.NET and JavaScript code generator. You upload HTML and CSS files that you create and preview offline. After you add more components in the UI (like specialized Web parts), Design Manager generates the associated master page. Page layouts get converted to SharePoint-specific JavaScript that the platform uses to render the dynamic components on the page.

You can generate and propagate a “design package” to reuse designs across site collections. That’s handy, though not as object-oriented as other, more nested templating subsystems you find in nearly all other products at this tier. There is a notion of template snippets that enable you to apply layouts within a design package, but they are not reusable across design packages.

This process is certainly more straightforward than the previous approach, but it still would likely involve a developer, and could prove clumsy when making small tweaks to existing designs. Moreover, it still tends to commingle business logic with display logic, which makes it harder to separate concerns (and skills).

Contributing content

First let’s return to the cross-site publishing feature. It could significantly improve your content reuse capabilities by enabling you to publish to multiple different endpoints. However, the new service may prove tricky to manage and could lead to unexpected results and behaviors. In particular for editors, it could slow the publishing process and make high-fidelity preview a major challenge.

With SP 2013, Microsoft has also figured out how to enable contributors to add more complex, non-Web part elements like embedded code and video that doesn’t have to be based on a specific Web part (think an object tag for a Flash element). Called “embed code,” the feature resembles what you would see in many competing tools. Just note that if you are using cross-site publishing with its search-based delivery, widget behavior may prove finicky and could lead to problems that require support.

Beyond basic content contribution, Microsoft does provide solid metadata and tagging services. With SP 2013, Redmond improved and simplified the term store, although you may find some more advanced taxonomy management features still wanting. For example, there’s no versioning, version control or workflow for terms; they’re not really managed content. Be careful.

Perhaps the biggest improvement is that using FAST, you can leverage metadata in the delivery environment much more readily than you could in previous editions, and specifically you can:

• employ metadata-based navigation structures (as opposed to folder hierarchies), which is a big improvement, and
• deploy automated, Drupal-like category pages and link lists based on how items are tagged.

Unfortunately, getting it to work properly is tricky, and it won’t always produce expected results. For example, the JavaScript-based renditioning does not always behave properly. Simply adding a new page won’t alter the navigation—unless you also add a new term to the term store. Moreover, at a time when other vendors follow the “content strategy” wave to allow for post-query automated page and link curation, Microsoft has turned the whole operation over to FAST, far away from the discriminating eyes of your editors.