Friday 28 September 2012

Wiki Pages vs Web Part Pages vs Publishing Pages for SharePoint 2010 Intranet Content Pages


SharePoint 2010 has three major options to create content pages – publishing pages, web part pages, and wiki pages.

As usual, to make proper architectural decision, I ended up documenting characteristics of each type of pages to allow me make final decision. Here are the high level characteristics of web part pages, wiki pages, and publishing pages.

Publishing Pages
  • Introduced in MOSS 2007 as web content management & publishing infrastructure
  • Publishing pages are designed for creating content pages in more controlled manner with consistent look & feel. These pages are based on page layouts and content types. Typically page layouts are designed by IT & page designers and publishing content pages can be created based on pre-defined page layouts by authors. This process is common for web content management systems.
  • Publishing pages has pre-defined content areas like web part zones & publishing field controls. This allows page designers to define page layouts and full control over how these page content can be rendered or different controls can be branded.
  • Publishing pages content can be versioned and and display history of changes. Publishing pages optionally allows passing articles through proper page approval and page scheduling life cycle.
  • Publishing pages are stored in Pages library. This library is available when publishing infrastructure is enabled on the site. There is only one pages library per site. You can enable multiple page layouts by enabling multiple content types to the pages library.
  • Publishing pages are created by site members or above security groups (contribute permission)
  • Publishing pages are edited by site members or above security groups (contribute permission)
  • You can access publishing infrastructure and create page layouts using Microsoft.SharePoint.Publishing APIs. Please note that you can’t use this namespace in Office 365 sandboxed solution. Alternatively in Office 365 and even on-premises, you can use SharePoint Designer to create page layouts.
Web Part Pages
  • Heavily used in MOSS 2007 and SharePoint 2003 days
  • All content on a web part page is displayed using web parts. Web Part pages are structured web part content including lists, libraries, and other collaborative content including rich media, other web pages, search results, and an aggregation of information. You can’t add text or image easily on web part pages – it requires web parts like content editor or image web parts. This is one of the major disadvantages of web part pages over wiki pages because adding simple graphics, images would require web parts or knowledge of content editor web part.
  • Web part pages provides ideal middle landscape where you still have semi-strict formatting control like publishing pages and partially-controlled collaborative editing capabilities like wiki pages.
  • Web part page has pre-defined content areas like web part zones where web parts can be added and moved as needed
  • Web part page content can be versioned with limited functionality. Please see Maurice Prather’s article – http://www.bluedoglimited.com/SharePointThoughts/Lists/Posts/Post.aspx?ID=305
  • Web part page layout and content configured for all users and optionally personalized for individual users
  • Web Part pages can be stored any document library. Mainly it stored in site assets, site pages, or any other document library you would like to use.
  • Web Part pages can be created by designers or above security groups (design permission)
  • Web Part Page can be edited by members or above security groups (contribute permission)
  • It’s easy to maintain web parts (add, update, remove) in web part pages programmatically using server side object model.
    • Programmatically add web parts to the web part pages by programmatically dropping web parts on web part zones using web part manager
Wiki Pages
  • Introduced in SharePoint 2010
  • Wiki pages consists of rich text editor providing WYSIWYG in-browser editing experience using Web Edit technology. It is designed to add free-form text & rich content including text, tables, links, images, as well as SharePoint lists and web parts anywhere on the page without any needs for web part zones like in web part pages or field controls like in publishing pages. e.g. it doesn’t require web parts like content editor or image web parts to add texts or images.
    • While you can easily add web parts on web part pages (requires advanced skills to use content editor web part for advanced customization), it’s much easier to add text, images, and links including web parts on a on a Wiki page. This would make wiki pages far more flexible to add contents compare to web part pages.
    • Wiki pages are easier to change than Web Part pages by end users with minimal IT dependency. This is major advantage of wiki pages over web part pages. On the flip note, because it’s easy to apply different fonts and styles on wiki pages content, web part pages would allow you better governance and control over standardization of presentation, formatting, and look and feel. It is important to note that advanced power users with SharePoint designer and HTML skills can easily apply different styles and look & feel in web part pages as well. Only way to fully control layout and style of the content in content pages are publishing pages without web part zones. Please note that even publishing pages with web part zones, advanced power users can add different web parts and apply different styles and look & feel.
    • One of the major issues of wiki pages is hidden HTML tags while editing the page in WYSIWYG editor. This might frustate end users who doesn’t have knowledge of HTML and how to remove those hidden tags and spaces. In most cases, you need advanced power user tools like SharePoint Designer to delete those troubled HTML tags like hidden paragraphs and DIV tags. Web part pages with fixed layout of web part zones & web parts would provide little bit better experience than wiki pages while adding content in more strict manner.
    • Another major issue of wiki pages are targeting specific section to brand wiki pages. Because wiki pages uses MS-RTE CSS classes to wrap most of the content tags like DIV, it’s hard to target specific section of wiki pages to brand. Web part pages can easily allow wrapping web part zones by DIV tags to target specific area using CSS.
  • Wiki pages have HTML zones where content can be added directly on the page.
  • Wiki pages can’t be personalized. It is designed to share information in collaborative way where multiple people can add content.
  • Wiki pages can be versioned and display history of changes.
  • Wiki pages are stored in site pages library
  • Wiki pages are created by site members or above security groups (contribute permission)
  • Wiki pages are edited by site members or above security groups (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.
Overall, if properly architected, in the bigger picture, I still see wiki pages are better option for intranet content pages because of end-user empowerment for content creation & IT non-dependency. In most cases, because of versatility of wiki pages, I personally prefer wiki pages over web part pages for intranet content pages. Some of the greatest benefits of the wiki pages are not only it’s flexibility to add all kind of contents easily but allows more intuitive experience for non-IT business users to create these pages easily without IT’s assistance to build their sites which may contribute into intranet adoption.
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 & feel issues especially on major department home pages. More formal editing experience makes web part pages 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.

In our client intranet environment, we ended up using all three types of pages for different scenarios.
  • Publishing Pages – Main Intranet Home Page – Since this page is main landing page for all employees, it required most structured content with fixed page layout making publishing pages ideal choice
  • Web Part Pages – Department or Major business area Home Pages – Since most of department home pages were maintained by department content owners, IT wanted to standardize the look & feel and layout of home pages across intranet. Web part pages were ideal choice for us to allow department content owners to add content in more controlled manner.
  • Wiki Pages – Intranet Content Pages and Team Site Home Pages – Because of it’s WYSIWYG in-page editing capabilities, this is ideal candidate for end-users to create and manage contents on their team sites in more flexible manner where content presentation and standardization of layouts is less important.
Additional Resources
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)