Printer Friendly Version

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:

• Click New Document on the document library toolbar
• On the New Web Part Page form, complete the form as detailed below.
  • Name: End-User Content
  • Choose a Layout Template: Header, Left Column, Body
  • Click Create

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.

Page 2: Organizing Web Part Pages