Writing by Peter Hilton

The Solution to Intranet Web Publishing

A low-cost intranet web publishing solution that separates non-technical content authors and web publishers.



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

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.


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: 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.


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.


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.


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.

Share on TwitterShare on LinkedIn