One of the faces/capabilities of the SharePoint platform is that of Web/Enterprise Content Management System (WCM, ECM). When we architect and setup a WCM-enabled SharePoint (publishing) site, there are actually 2 different types of users to take into consideration:
- The end-users browsing and using the website;
- The content managers, who have the responsibity for maintaining the content on the website up-to-date
When designing the website, the primary focus is almost naturally on the end-users. Understandable, after all a site which does not attract and keeps the interest of end-users is in fact useless for the company. However, it certainly is also beneficial to give appropriate attention to the usage model for the content manager role. If they can do their content work in a more user-friendly and efficient manner, the site will most likely benefit from this by being more and more often kept up-to-date. Content management is a task difficult enough on the functional level, without the technical / usage model burden of SharePoint content management.
Content in a publishing website comes in various forms. Most known are of course the publishing / web pages, as the entities to which the end-user navigates. But there are more type of content-entities possible:
- downloadable documents (administered in document libraries)
- pictures displayed somewhere in the site (administered in picture libraries)
- data displayed somewhere in the site. Examples are news items, events calendar, links to related information (administered in SharePoint lists)
Wouldn't it be nice to apply a comparable usage model as for page-modification to non-page content items ? I thought so, and have realized it within various SharePoint CMS-projects. The basic usage model is:
- A contributor selects the Site Actions menu
This usage pattern improves the user experience for the content management role:
- The usage model for non-page content applies the same pattern as for publishing page content
- The navigation is direct, and orientated at functional level
- Lesser mouseclicks and page retrievals
- Contributor is shielded of from confrontation with the total collection of SharePoint lists and libraries in the site
At SharePoint technical level the following is done to enable this usage pattern:
- Entry on Site Actions menu: Provision via a feature a custom action, to add an entry to the Site Actions menu, with it's action set to navigate to functional CMS management page.
- Functional CMS Management page: Provision a web page with on it a Content Editor webpart (CWEP), and add htlm to render a list of the different content types. Each item in the list hyperlinks to the same edit page for editing the contents of the selected list. The listname is propagated via the QueryString.
- Editable list view: Provision a second web page with on it a ListView webpart. The ListView webpart is used to display the different items in the SharePoint list or library, and to enter new item or edit existent item. This web page is reused to display the contents of the different content lists and libraries. For this it is required to runtime connect the contained ListView to a specific list or library, following the selection the content manager made from the overview. The ListView webpart itself does not exhibit QueryString behaviour. Therefore a hidden technical webpart is added to the page which parses the QueryString to detect the requested list, and next runtime push this setting onto the ListView webpart on same page.