A Tale of Three Pages in SharePoint 2013

An important decision that SharePoint 2013 administrators need to make when planning and implementing a Web Content Management (WCM) system is which type of web page is most appropriate to the task at hand. The decision to employ a WIKI Page, a Web Part page, or a Publishing Page can impact the effectiveness of your communication. It might be useful to delve into the characteristics of these three different content types provided by SharePoint 2013 to determine which would be the most appropriate in any given situation.

Publishing Pages

  • Designed for creating content pages in a controlled manner with consistent look and feel, these pages are based on page layouts and content types. Typically, page layouts are created by web page designers and publishing content pages can be created based on pre-defined page layouts by authors. This is a common scenario for Web Content Management (WCM) systems.
  • Publishing Pages have pre-defined content areas similar to Web Part zones. This allows page designers to define page layouts and impose full control over how page content can be rendered.
  • Publishing Pages content can be versioned and maintain a history of changes. Publishing Pages optionally allows for introducing page approval and scheduling life cycle.
  • Publishing Pages are stored in Pages library. This library is only available when publishing infrastructure is enabled on the site. There can only be one page libraries per site. You can enable multiple page layouts by enabling multiple content types to the pages library.
  • Publishing Pages are created by Site Member level or above security groups (requires Contribute permission).
  • Publishing Pages are edited by the Site Member or above security groups (requires Contribute permission.

Web Part Pages

All content on a Web Part page is constrained to display in individual Web Parts. Web Part pages are structured Web Part content objects including lists, libraries, and other collaborative content including rich media, web pages, search results, and an information aggregation via Rollup. Users can’t easily add text or images to Web Part pages – it requires Web Parts like the Content Editor Web Part (CWEP) or image Web Parts. This can be a deciding factor in choosing WIKI Part pages over Web Part pages because adding simple graphic images would require Web Parts and knowledge of the Content Editor Web Part (CWEP) implementation and configuration.

  • Web Part pages are a middle of the road choice.  The page author still enjoys semi-strict formatting control like Publishing Pages and partially-controlled collaborative editing capabilities like WIKI pages.
  • Web Part pages have pre-defined content areas like Web Part zones where Web Parts can be added and moved as needed. This adds a structured presentation of the page.
  • A Web Part pages layout and content can be configured for all users or optionally personalized for individual users.
  • Web Part pages can be stored in any document library, though traditionally stored in Site Assets, Site Pages, or another Document Library.
  • Web Part pages can be created by Designers or above security groups (requires Design permission).
  • Web Part Pages can be edited by Members or above security groups (requires Contribute permission).

WIKI Pages

  • WIKI pages consists of a rich text editing environment providing WYSIWYG In-Browser editing experience using Web Editing technology. Users add free-form text & rich content like tables, links, images, as well as SharePoint lists and Web Parts anywhere on the page without the limitation of Web Part zones. WIKI Pages do not require Web Parts like the content editor or image Web Parts to add texts or images.
    • While you can easily add Web Parts to Web Part pages, this requires experience with the Content Editor Web Part (CEWP) for advanced customization. It’s much easier to place free-form text, images, and links including Web Parts on a WIKI page. This makes WIKI pages more flexible, faster and easier to develop than Web Part pages.
    • WIKI pages are easier to manage than Web Part pages. End users need minimal IT support. This is a major advantage over Web Part pages. Conversely, because it’s so easy to apply different fonts and styles on WIKI pages, Web Part pages allow better governance and control over the presentation, formatting, and general look and feel. More advanced users with SharePoint designer permissions and HTML5 skills can easily apply different styles and branding elements in Web Part pages.  One way to fully control the layout and style of the content in content pages are Publishing Pages without Web Part zones. Please note that even advanced or power users that are Publishing Pages with Web Part zones can add different Web Parts and apply different styles for a consistent look and feel.
    • A major issue of WIKI pages is the presence of hidden HTML tags encountered while editing the page in a WYSIWYG editor. This can be frustrating for the user who doesn’t have knowledge of HTML and are concerned with how to remove those hidden tags and spaces. Power Users employ tools like SharePoint Designer to manage HTML tags such as hidden paragraph and DIV tags.
    • Another issue with WIKI pages is targeting specific sections to brand WIKI pages. Because WIKI pages uses CSS classes to wrap most of the content tags like DIV, it may be a challenge to target specific sections of a WIKI page for branding. Web Part pages allow wrapping of Web Part zones with DIV tags to target specific areas with CSS.
  • WIKI pages have HTML zones where content can be added directly on the page.
  • WIKI pages can’t be personalized. They are designed to share information in a collaborative way, allowing multiple contributors to add and update content.
  • WIKI pages support versioning and maintain a history of changes.
  • WIKI pages are stored in the site pages library.
  • WIKI pages are created and edited by Site Members or above security groups (requires Contribute permission).
  • All the content added to WIKI pages are added as HTML markup. There is no direct API available to programmatically maintain (add or remove) Web Parts on the WIKI pages.

Generally, WIKI pages are the best option for Intranet content pages by virtue of end-user empowerment. WIKI pages deliver the flexibility to add diverse content easily while allowing a more intuitive experience for non-IT business users.

Some may argue that ease of use may be one of the biggest concerns of WIKI pages over Web Part pages, which further cause content governance or uneven content look and feel issues especially on major department home pages. More formal editing experience makes Web Part pages an ideal candidate for home pages for department or major business areas where IT would like to balance standardization of page layout and agility to allow business owners to manage content on the home pages.

The final implementation of a well-designed web presence will most likely employ all three of these web page variations.

  • Publishing Pages – Main Intranet Home Page: Since this page is the main landing page for all users, it usually requires the most structured presentation with a fixed page layout making Publishing Pages the ideal choice.
  • Web Part Pages – Department or Major business area Home Pages:  Most department level home pages are maintained by department level content owners. In order to standardize the look and feel and the layout of home pages across an intranet, Web Part pages are considered the ideal choice by encouraging department level content owners to add content in a more controlled manner.
  • WIKI Pages – Intranet Content Pages and Team Site Home Pages: Given the WYSIWYG in-page editing capabilities, WIKI pages are an ideal vehicle for end-users to create and manage content on team sites.

To learn more about Directions and our course offerings, please visit our website at www.directionstraining.com or call us at 855.575.8900! We look forward to fulfilling your training needs!