Compared to a book, the web is a highly non-linear medium. Moreover, as rich as it is, users are forced to view it via a very small window. While it has great potential for the effective delivery of courses—the production of pedagogical material for the web is not easy. The more one tries to take advantage of its unique capabilities, the more difficult this authoring becomes.

In tackling course development, it was decided very early on to separate the scaffolding from the actual content. From the first, the site was intended to serve multiple courses, indeed to serve the whole C/C++ / Java student community within the Faculty of Engineering at Memorial without regard to whether a student was still formally associated with a programming course or not. Multiple courses implies multiple authors, with instructors from different courses lending their particular expertise. Ultimately, in order for that to be successful, content writers have to be allowed to concentrate on content and the scaffolding has to get out of the way.

Initially that conception was something of a set-back, in that the scaffolding took on a life of its own. Indeed, it has now become a small authoring system, hence the name WebWriter++. When its initial development was under way, very little content was created. Over the past few years we have been able to focus on content, using the tool to produce two complete courses—Engineering 3891, Advanced Programming and Engineering 2420, Structured Programming, as well as parts of others

In the best tradition of incremental development, that experience led to a complete reworking of WebWriter++. Some things turned out to be problematic or were simply not useful and were removed. A number of features have been added. The tool was and is experimental. It evolves practically every time it gets used so that a manual is at best a snapshot. Here is the latest one.

## Technology

The authoring system is based on the following technologies:

1. HTML 4 is the basic markup language. The strict compliance model is being used.
2. Cascading Style Sheets(CSS-2) to control the appearance of pages
3. Dynamic HTML (DHTML) for automatic generation of HTML on the fly.
4. JavaScript produces the necessary DHTML as well as providing most of the scaffold's toolset. Version 1.5 or greater is assumed .
5. Java, the language in which the Teaching Machine (and several smaller applets used in the scaffold) are written.

## Browsers Supported

We have moved to so-called fifth-generation browsers and the site has been extensively tested on Explorer 6 and FireFox 1.5 and some testing has been done on Safari for OSX.

Earlier browsers have been categorically abandoned. We are focusing on the teaching of a very high technology topic (C/C++ & Java programming). All our students have access to powerful computers running Windows or Linux and a number of fifth generation browsers are readily available, free. Thus, access should not be a problem. The features available in these browsers really allow us to deliver a much better product. Nor do we have the resources to develop alternative pages/scripts targeted at less capable browsers.

At this point, Firefox is the recommended browser. It works on both PC's and Mac's (as well as on Unix). Moreover it is far more stable than IE 6.0 which Microsoft constantly patches to fix it's security problems, sometimes breaking Java or JavaScripts on the way by. Although IE 7 is now out, it has not been tested. Given the problems with IE6 and Microsoft's enmity of Java, it is hard to generate any enthusiasm to test it.

Whichever browser is used, it must be set up to permit JavaScripts, to allow JavaScripts to invoke Java (an ability sometimes called live connect), and the Java Runtime System must be installed on the local machine. See the TMSetup page included in this manual. It is recommended the TMSetup folder be installed on any website using WebWriter and /or the TM, exactly as it is in this manual.

## Frames

Be warned. WebWriter++ uses frames. A very serious effort was made in the winter of 2006 to remove them but was defeated by FireFox. The navigationBar that occupies the top frame also holds all the Applets. If it wasn't there, all applets have to be reloaded every time a new page is loaded. While IE handled without a blink, Firefox would sometimes hang. A week's intensive investigation of the problem could turn up no solution and so frames are still being used.

The navBar frame holds a `ww_one_time.js` script that is loaded one time only. Most of the active code is in the `web_writer.js` script that is attached anew to any document loaded into the content frame. Since it has to be there, the `navBar` frame also holds the site dictionary.

## Browser Detection

Browser detection is implemented in the `ww_one_time.js` that is invoked from the WebWriter toolbar in the `navBar` frame.

It attempts to detect whether an appropriate fifth-generation browser is being used (IE 6 and up or Gecko—that is Mozilla—1.4 and up) as well as whether Java is enabled. As the top level frames are only loaded once, the non-compliant warning is only given once.

Individual pages simply detect whether or not the browser is IE based. Dependencies upon that are kept as few as possible. Unhappily, even in strict compliance mode, there are still some unavoidable differences.