The overall structure was to be a School home page, from which hyperlinks were to lead to each of the three aspects were accessed. The home page was to appear in the root directory of the WWW server utilised, with research and course materials appearing in their own distinct directories. As there are some 40 members of staff within the school, it was decided that individual staff pages would appear in one directory (/STAFF), and all graphics related to staff would appear in a GRAPHICS sub-directory (/STAFF/GRAPHICS).
There were three main developers - Gregg Boalch [HREF 3], Richard Potger [HREF 4]and the webmaster Don Griffiths [HREF 5], and during the course of the development three main development platforms were utilised. The finished project was to be loaded on an Intel-based server running Windows NTAS. All three developers had limited time to spend on this project as their educational, administrative, consulting and research demands remained constant, and no release was available.
This paper concentrates on the development and implementation of the staff profiles, as this involved the greatest effort to date and resulted in the majority of installed pages - some 60 to date.
The first issue to be addressed once the commitment was made to commence the project was the choice of development platform. The existing hypertext expertise within the school implied that a standard text editor would be appropriate, based on the premise that most of the text was already present in electronic form, and it required tagging to make it accessible via the 'Net.
The first phase of the project was via the standard text editor, by which all tags had to be manually specified and entered. After some priming in the HTML tagging format[HREF 6], development started on the School home page. The use of a standard text editor caused a number of problems, mainly in syntax errors introduced into the HTML document during entry. In addition, one had to launch a Web browser such as Netscape [HREF 7], Mosaic [HREF 8] or Cello [HREF 9] to view the result of the tagging on the text, and then continually transfer control between applications during development. This was further frustrated by having to clear the browser's cache each time so that changes were reflected.
The developers, using this approach, had to
Development time was significantly higher than was required by the project manager, and hence alternative development platforms were evaluated.
After some research via the 'Net [HREF 10], the developers gained access to a Windows-based HTML editor called HoTMetaL by SoftQuad. The unsupported, evaluation version was downloaded [HREF 11] and trialed, and was found to be a vast improvement on the use of a standard text editor . The package enabled a more streamlined entry process, in that tags could be introduced via a menu selection, as opposed to the physical entry of commencing and terminating tags. It also enabled structure and context views of the document and its links.
However, the developers found
The third factor was the most frustrating - this approach utilised a text editor with a graphical representation of the tags, but not providing a view of the end product. The developers started to look for a tool that would provide both tagging and display functions within the one product, and preferably one that did not have a steep learning curve.
Two of the developers were proficient in WP packages, and hence when they became aware of a third party add-on to one of these WP packages which enabled HTML development, the add-on was sourced, downloaded and trialed. It was called CUHTML [HREF 12], developed by the Chinese University of Hong Kong for Microsoft Word for Windows 2 and Word 6.
This package added macro's, styles and templates to the standard product which enabled local and URL hyperlinks, as well as the insert of graphic files, though only GIF files. It meant that the document was developed as a standard .DOC file, with preset styles assigned to text to denote headings, title etc. The development in this environment is WYSIWYG-WWW, in that the page appears similar to how it would look if viewed through a WWW browser. The document would first be saved as a normal WP document, and then could optionally be written as an HTML file with an HTM extension via a macro launched from a tool bar. One would watch as the document on the screen was converted to tagged text, line by line, prior to being written to the destination disk.
The limitations with this platform were
About this time, the developers became aware of software additions being developed by WP package suppliers along the same lines as the third party software mentioned previously. Serendipitously, the add-on for the package [HREF 13] used by the developers was made available via an Internet down-load. The file was then downloaded, unpacked and set up within the Windows environment.
The WP package had now become an HTML generator and WWW browser as well. This enabled developers to see the page in its final form as it was being developed, as well as being able to use the Net to access resources and incorporate hyperlinks. It also enabled people with a limited knowledge of HTML to effective develop quality pages, hence vastly reducing the learning curve as well as increasing productivity. In this particular instance, it also enabled the developers to utilise the knowledge they already had in the use of the package - it became just an extension of their existing, familiar IT toolkit.
Though the software was a beta-version, the only significant shortcoming found in this project was the way in which the graphics were represented - the viewer within the software was not of a comparable quality to those generally found with WWW browsers.
This paper was written via this platform, without once having to enter an HTML tag.
In the experience of the developers, the ideal development platform is a WYSIWYG-WWW product which enables the user to develop pages in HTML without having to manually insert HTML tags and hyperlinks. The WYSIWYG-WWW would also allow the developer to see how the page looks as it is being developed, and to search for the correct hyperlinks on the 'Net prior to their insertion within the page.
In our experience, this can mean the difference between spending an hour tagging pre-existing electronic text and literally spending 90 seconds. It not only improves the efficiency of page development, but also assists in the development of better quality WWW pages.
With the question of the development platform resolved, the focus was shifted to WWW page development. We had one sub-organisation, three foci and nearly forty staff to cover. The University has a home page [HREF 2], with hyperlinks to each of the four divisions [HREF 13] (Curtin Business School being one). The School of IS [HREF 1], being the only one of the six schools comprising the Curtin Business School to attempt WWW page development, decided to implement its own WWW server, so that access, security and control could be assured during the development phase. The server is a 486-DX66 PC running Windows NT-AS, and has a LAN of 4 workstations running off it.
Development was undertaken on PC's situated within the developer's offices, and these machines were able to access the server directly through the operating system (Workgroups for Windows). Pages were developed and tested locally, and then transferred to the server upon signoff. One developer undertook a majority of the development remotely (off-campus) telecommuting, and his work was isolated on its own server.
The home page was to lead on to teaching, research, consulting and staff information, all of which were to be hyperlinked together.
The teaching program was provided to the team by the University in electronic text form, which was subsequently imported into and manipulated by the WP package. This enabled separate pages to be "hived off" for undergraduate, honours and post-graduate programs, and from there streams and then individual units.
The research program has not as yet been implemented on the Web, due to the relevant School staff members' involvement in CeBIT'95.
The staff profiles were provided electronically, giving details on qualifications, memberships, publication history, research interests and contact numbers / addresses. One of the early difficulties encountered was the usage of staff photos. The School has a gallery in the School office, showing for most staff members a recent colour photograph (10cm x 15cm) and name to assist students in recognising staff for the first time. The developers utilised a 2400dpi colour scanner and photo design/production software to scan photos for inclusion on the WWW pages. When researching the use of photographic images on WWW sites, it soon became apparent that images had a significantly detrimental effect on the speed with which pages were loaded and displayed on the users' screens. The higher the resolution for a given image size, the greater the file size and thus the slower the download to the user; the lower the resolution, the less "life-like" the image. Though most people would only view these photos, some would possibly download and print.
After some experimentation, the following standard was adopted:
The developers felt that this combination gave the best compromise of quality and accessibility, especially in light of the variety of video cards and monitors used in the various PC's, Macintoshes and UNIX workstations accessing the 'Net. The files ranged in size from 5K to 25K.
In addition, a page style needed to be developed. Taking the design skills learned in the development of the School's CBL software, a style was developed that incurred minimal overhead on transmission and storage. The team wished to incorporate the Business School's logo [HREF 14] on all pages, but the logo has the words Curtin Business School within the image and as such there was a limit to which the image could be reduced and still have the letters legible. It was then decided to incorporate the image on the School home page and the staff directory page, but not on individual staff member's pages. The image would be stored in the appropriate directory on the WWW server, so that experimentation could continue on the optimum size / resolution for the logo. If a better image could be produced, it would be placed in the directory and hence all pages using the image would automatically be updated.
In addition, it was decided that the photo should not form part of a staff member's main WWW page, due to download speed considerations. It was decided that there would be a maximum of three hyperlinked pages per staff member
Each staff page would have a level 1 heading, followed by a horizontal rule and then the appropriate text. At the end of each page would be another horizontal rule, and a footer denoting who made that last change to the page and when. Once a better CBS logo has been developed, it would be incorporated in the heading of each staff WWW page.
In the development process, having a platform that incorporates WYSIWYG-WWW enables design issues to be identified and thus addressed immediately. This is true of heading choice, image size, text alignment and related issues.
When using a text editor, the team used both Netscape [HREF 7] and Mosaic [HREF 8] browsers in order to view the HTML files under development. These were also used during the HTML editor phase of the project. With the WP add-on's, viewers were used as a final check mainly for image presentation. This was necessary as both the vendor and third party add-ons produced displayed JPG and GIF images with a lower quality than the viewers utilised by the browsers. It should be noted that the vendor add-on is only a beta version, and perhaps the finished product will overcome this problem.
One of the by-products from this project has been the research undertaken in determining the cost of access. Until 1/1/95 there was no charge applicable for the access and downloading of information from the 'Net. However, since then a volume charge has been applied to all 'Net users in Australia - every time a WWW page is transferred from a WWW server to a user's machine, a charge is applied per Mb transferred. In order of size and thus bandwidth, text takes the least space, followed by hyperlinks, images, sound and video. The cost increases in two dimensions - currency cost and temporal cost (the time taken to access the information requested). The latter is important from the perspective of the person to whom the information is provided - the longer the delay in loading the information, the more likely the recipient is to stop the process and look elsewhere.
Hence, the project team aimed to provide to the user the most cost-effective access to the information offered.
We have now developed in excess of 60 WWW pages, utilising a number of experimental development platforms until settling on an augmented WP package. We believe this platform to be the most cost-effective to date, in that it requires a minimal learning curve, utilises skills and facilities already present, does not require a detailed knowledge of HTML tagging and enables development in a WWW-WYSIWYG environment.
The selected platform has enabled rapid development of WWW pages, and has also enhanced the design to incorporate access cost and browser factors.
AusWeb95 The First Australian WorldWideWeb Conference
![logo [HREF 14]](http://www.is.curtin.edu.au/staff/graphics/cbs.jpg){kind=link}