Intranet Journal
The online resource for intranet professionals
Enabling Users to Maintain SharePoint Content
Paul Schaeflein
6/23/2005
|
|
Editor's Note: More Microsoft SharePoint content can be found at the series home page: http://www.intranetjournal.com/sharepoint/.
When SharePoint is installed as a corporate intranet, there is a considerable amount of effort involved in maintaining the content to keep the site relevant. As we discussed in the first few parts of this series, SharePoint has many built-in features to reduce the burden on the site administrator.
Some areas of the site usually contain less-dynamic information. Internal memos and corporate policies are common examples of this information. One option for this information is to post these documents in a document library. Documents in a library are often stored in a few different formats: Word, Acrobat (PDF), or HTML. Each of these formats has its drawbacks.
When a document is opened from a document library, the end-user's computer uses the program associated with the file type. Word documents, when opened from a library, can be confusing since they appear to be editable to the end-user. This is opposite of the expectation for documents on an intranet. If the permissions on the document library are not set correctly, any site visitor can overwrite the document. If the permissions are correct, then visitors can click the Save button, and Word responds by requesting log-in credentials.
| Discuss this article or ask your Microsoft SharePoint questions in the Intranet Journal Discussion Forum |
In most cases, end-users do not expect to change an PDF file. However, the user experience is degraded while the Acrobat program is opened. In addition, creating Acrobat files can be time-consuming, depending on the user's desktop configuration. HTML files usually provide the best experience, and are easily created with Word. When they are stored in a document library, however, they are processed identically to Word files.
Using a Content Editor Web Part
SharePoint has the ability to solve this problem. The Content Editor Web Part on a Web Part Page provides a rich-text editor that is familiar to most end-users. (We first used a Content Editor Web Part in Part 1 of our series.) In fact, when text is copied from Word and pasted into the Web Part, it will retain its formatting.
Web Parts must be used on a Web Part Page. The default home page is a Web Part Page. In addition, Web Part Pages can be created and stored in a document library. Assuming you have been following along with the earlier articles in this series, create a new Web Part Page in the "Web Pages" document library:
The new page will be displayed in design mode. Drag a Content Editor Web Part from the gallery list onto the page. Inside the Web Part are directions for opening the Rich Text Editor.
As you can see in the image above, the Rich Text Editor has a toolbar with the most popular text-editing functions. Any end-user who is familiar with Word will feel completely at home inside the Rich Text Editor.
Organizing Web Part Pages
Over time, the number of these Web Part pages will grow. It is possible to organize related "documents" into separate document libraries — similar to folders on a network or local drive. As the number of pages and document libraries grow, the need for some type of navigation increases.
The default home page has a Quick Launch bar that can display links to each of these document libraries. A property setting of the document library is used to identify which libraries are displayed. The Quick Launch bar does not provide any "deep links" to the individual documents; these must be created in some other fashion.
Using FrontPage 2003, programmers can create additional link bars. However, these link bars must be manually updated. To make the site administration easier, it would be helpful if a property could be set on each document to identify which documents to display. To implement this idea, I created a DocLib Quick Launch Web Part that displays links to the individual pages within a specified library. This Web Part, in combination with additional properties on the document library, allows end users to choose which pages have links displayed.
In the image below, the DocLib Quick Launch has been placed into the left column. At the bottom of the Tool Pane, the Web Part is configured to display links from the Web Pages document library.
The document library requires an additional column titled SortOrder. Since Document Libraries are similar to lists, custom columns can be added. (Click on Modify settings and columns at the bottom left of the All Documents view.) Add the column to the default view. Then, update the recently added page (called End-User Content in this example) to have a sort order of 10.
Since it is possible that a document library may contain documents that need not be shown in the Quick Launch, the Web Part only displays links for documents with a sort order greater than 0. The Web Part will display the name of the document library and links to the documents.
Next Steps
In the next article in this series, I will review the DocLib Quick Launch Web Part in detail — including source code. This Web Part can provide navigational links for a document library with very minimal effort.
Combining the Content Editor Web Part (and other Web Parts) on a page template will provide almost everything that an end-user requires. Starting with an MSDN article on customizing the page templates, (http://msdn.microsoft.com/library/en-us/odc_sp2003_ta/html/sharepoint_creatingcustomwpptemplates.asp) we can create a complete solution for end-user content editors. Look for more details in an upcoming article.
About this series
This series of articles on SharePoint is intended to help you understand the capabilities of the product, as well as provide tips and tricks, development ideas, information from Microsoft, information from the community, and perhaps some samples. Like many other series on IntranetJournal.com, I plan to include how-to articles that can help you with your deployments — ways to customize a page; deployment scenarios; content management; etc. With such a diverse product, there is no lack of topics for this series of articles. What would you like to read?
About the author
Paul Schaeflein is a developer with more than 20 years experience. Paul has been developing dynamic and interactive Web sites since 1996. Paul has worked on all of the versions of SharePoint and has worked with the .NET framework since its debut. You can reach Paul through his blog at http://www.schaeflein.NET/blog/.
Intranet Journal's Tutorials |
|
Managing Editor |
Jupitermedia Corporation has two divisions: Jupiterimages and JupiterOnlineMedia
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Tech Jobs | Shopping | E-mail Offers