It’s very important to make decision when planning a Web Content Management (WCM) application that which type of web page is suitable for the given task. We can create a WIKI page, a Web Part Page, or a Publishing Page. In this blog, I would be discussing that which page would be most appropriate in any given situation.
- 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.
Web Part Pages
- 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. 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 have pre-defined content areas like Web Part zones where Web Parts can be added and moved as needed.
- 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 ideally stored in Site Assets, Site Pages, or another Document Library.
- 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.
- 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 mark-up. 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. WIKI pages deliver the flexibility to add diverse content easily while allowing a more intuitive experience for non-IT business users.
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.