The Solution to Intranet Web Publishing

Contents

• Introduction
• Design summary
• Functional design
• Technical design

Introduction

This article describes a solution to a recurrent problem in intranet web publishing: a large organisation wants all of its members to be able to publish documents on the intranet, but the barriers to entry are too high for non-technical staff.

Typically, in this situation, the IS department has made Microsoft FrontPage available to staff who identify themselves as 'web authors', which they should use to write documents in HTML documents and publish to the web server. This fails because FrontPage, which seems to be desiged for authoring jazzy content-free pages, is an inappropriate tool for the job - writing. Ironically, staff prefer to use the more complex but more familiar Microsoft Word.

A better approach would not require writers to learn about the techical aspects of web publishing, without imposing a large burden on the web masters.

Design summary

In this solution, writing and publishing are separated , and performed by different people.

First, writers use an HTML-aware news client to write their documents and post them to a newsgroup on an internal news server. This, in itself, is already an improvement on the conventional web publishing approach because

• news clients such as Outlook Express and Netscape Collabra are much simpler than HTML editors such as FrontPage, so more people can publish in practice
• documents posted to the news server are already available to all staff, using standard news clients
• news clients automatically include basic meta-data: subject, author and date
• writers can use the news server for version control, by posting updates to each others documents in replies to the original posting, which are automatically stamped with the new date and author.

Secondly, web publishers use a simple web interface to edit documents on the news server and then transfer them to the web server. This web interface could be implemented on almost any web server platform and would make publishing existing documents a quick easy task that requires minimal skills.

Functional design

Write page. First the writer posts documents to the news server, as described above. Then the web editor publishes a document to the web server, using the web-interface, as follows.

1. Choose newsgroup posting. The publisher selects a news group from a list of internal news groups. The publisher then selects an individual posting from a list of postings in the chosen newsgroup.
2. Edit document and meta-data. The publisher then sees a web page form that contains the content of the news posting. There are separate fields for the author's name, date, subject/title and document body, which the publisher can use to edit any of the content. There may be additional fields for the web page URL, publisher's name, choice of HTML page template, choice of HTML or plain text document format, and any other required meta-data.
3. Preview document. After submitting the previous form the publisher is shown a preview of the document, in HTML format. At this stage the publisher can go back and re-edit the document or post the new document to the web server.
4. View new web page. After submitting the new page the publisher sees the new page immediately.

Notes.

• The dynamic page that fetches the posting from the news server and displays the Edit document and meta-data page should pre-process the posting to clean up the HTML, removing FONT tags for example.
• Step 3 previews the part of the document's body that contains its actual content, separate from the final HTML page template.
• When the document is saved to the web server it could either be combined with a static page template, by inserting the document content inside the template's BODY element and inserting the meta-data in the appropriate places inside the document's HEAD element. Alternatively, the document could be inserted into a dynamic page-templating system.
• The views for steps 1. and 2. above, for a given newsgroup posting, should have a unique URL.
• As pages for steps 1. and 2. above have URLs, a web view of the newsgroups could include 'publish this page' links for authorised users.
• Similarly, previous published web pages could include 'edit page' and 'delete page' links for authorised users.

Technical design

Once the document to be published is on the news server the editor will use a web interface to publish the document on the web server. This section defines the implementation of that interface, in terms of its four URLs.

For each URL the following information is given.

• Title: the title of the page generated by the URL.
• Purpose: the purpose of the page or program.
• Parameters: names and values of query string parameters.
• Input: input to the script other than the query string parameters, such as data sent to the URL using HTTP POST, or user input in forms
• Output: a description of the output HTML page.
• Actions: side-effects of the program or form actions.
• Notes: further information about the implementation.

document-select.html

Title: Select Document.

Purpose: Allows the editor to specify a newsgroup posting to publish to the web server.

Parameters: s (optional) - the name of the news server.

Input: The news server name and the posting message ID, entered by the editor.

Output: An HTML with text input fields for the news server name and posting message ID.

Actions: Uses HTTP GET to request document-edit.html?s=servername&m=messageid, where servername and messageid are the values input by the editor.

Notes: The optional news server name parameter is used as the initial value of the corresponding text input field on the form.

This URL could be implemented with varying levels of sophistication. Instead of the simple HTML form described here this could be a full web-based search/browse interface to the news server with generated hyperlinks to document-edit.html for each posting. Alternatively, these hyperlinks could be added to an existing web-based news client.

document-edit.html

Title: Edit Document.

Purpose: Allows the editor to make changes to a document's meta-data and content.

Parameters: s - the name of the news server.
m - the newsgroup posting's message ID.

Input: The document's content and basic meta-data, retrieved from the news server using NNTP; additional meta-data entered by the editor, web server URL stub and the editor's name.

Output: A generated HTML form that has text input fields for each of the meta-data items and the content.

Actions: The form submits the document to document-preview.html using HTTP POST.

Notes: The additional meta-data could include a named template to apply to the document.

Since this page is completely specified, for a particular posting, by its URL and query string it can be bookmarked or used as the destination of a generated 'Edit this document' hyperlink on a published web page.

document-preview.html

Title: Preview Document.

Purpose: Displays an HTML preview of the document's validated meta-data and content, which can then be published on the web server.

Parameters: None.

Input: The document, by HTTP POST, with values for the following control-names: author, title, date, content, url, editor, newsserver, messageid, and (optionally) template.

Output: An HTML preview of the document.

Actions: A form, with the data encoded in generated hidden INPUT elements, submits the document to document-publish.html using HTTP POST.

document-publish.html

Title: None.

Purpose: A non-displaying page that publishes the document on the web server.

Parameters: None.

Input: As for document-preview.html.

Output: An HTTP redirect response, specifying the URL of the new web page.

Actions: Writes the document to web server storage, then redirects the browser to the new web page.

Notes: The web server storage might be an HTML file on the web server's file system, a relational database or some kind of XML store, for example. Note that the meta-data might be stored separately from the document itself.

When the document is written it might be stored as a static HTML page, with some template applied, or it could be integrated with an existing dynamic page templating system.