Connecting you with Australian culture online
This screen aims to provide a basic introduction to presenting existing paper-based documents on the Web. For some additional information, see the previous screen(1).
Rather than merely transferring the document from word processor files to the hypertext markup language (HTML) files needed for Web delivery, consideration should be given to the differences between the two media (paper and Web), and the material modified accordingly.
If faithful reproduction is required, then about the only real option at the moment is to create portable document format (PDF) files using
Adobe's(4) Acrobat software: this can be used to create a facsimile of the original document, maintaining fonts, layout and graphics, by converting word processor or page layout files into electronic files that can be read on screen by users with Adobe's
free Acrobat reader software(5). The PDF files can also be printed out using the same software to give the user a paper facsimile of the original document.
Converting existing documents from word processor formats to HTML is technically a simple process. There is a number of ways of doing this: Yahoo!, for example, has a list of links to
tools for HTML conversion(6).
There are, however, a number of things to consider before simply saving existing word processing or page layout documents in HTML.
Since people read screens in a different way to the way they read words printed on paper, documents destined for the screen should be more concise and structured than the paper-based alternative. People are more likely to print out a screen's content if it is more than half a page long, and read it on paper. Use descriptive subheadings and frontload information(7).
Break long documents down into individual files that each represent the equivalent of one or two A4 pages of information. A good rule of thumb is that if a screen contains more than about 20kb of text it is probably too long. A screen that contains more than about 50kb overall of text and graphics is also probably too long: it will take too long to download and may be confusing to read on the screen. These are rules of thumb only and each unit of information, or file, should be considered on its merits.
If your document is a long one and you have it in HTML form on the Web in reasonable sized chunks, it is also a good idea to have the whole document somewhere so that people can download it to their own computer to read it or print it out at their leisure. Not everyone is comfortable reading long documents on screen, and most people pay for their connection to the Internet in timed increments.
It may be that you supply the whole document as a Word document, a PDF file or whatever. Find out what suits your users best and try and provide the document in that format, or provide a range of formats which will suit everyone.
To realise these benefits, you will need to ensure that:
(a) Your Web server supports searching.
(b) The documents are properly indexed.
(c) The hypertext links, cross-referencing, contents list, headings and so on are in place when the document is served to a user.
Hypertext links make it possible to display information differently in an HTML document to how it might be displayed in a printed document. For example, in an HTML document footnotes and references can be hypertext links to the actual content referred to. This content can be stored on any computer with an Internet connection.
Additional explanations, definitions, diagrams, details of graphics and other additional material can be linked easily to any part of the HTML page, even linked to original source material if the material is available somewhere on the World Wide Web.
Contents lists and indexes can be 'hotlinked' directly to the relevant chapter or item.
Care must be taken with hypertext links. Too many will render a screen difficult to read and confusing, and when users follow the links they may get 'lost' in a document, not knowing where they are or being unable to get back to where they were before following a link.
There are a couple of ways you can approach this - firstly, you could use standard footnoting conventions. Make your link within the screen to a footnote at the bottom of the screen. Or secondly, you could 'clump' your links into a list at the bottom of the screen, possibly with subheadings or short descriptions.
As a Web author you must make sure your users know where they are in your site - for example, display screen names, screen numbers and ranges, provide navigation buttons, menus, tables of contents, and links to major features in your documents.
M/C electronic journal(9) is experimenting with a way of publishing scholarly articles in Web format and is worth having a look at for that reason.
Provide enough information on each screen so that if a user comes directly to that screen from another site they will know where they are and be able to navigate around both your document and your site.
Provide a sitemap one click away from any screen to take users to an overall view of the site so they can easily return to known territory any time they feel lost. A sitemap also gives users a sense of the scope of the site, the electronic equivalent to gauging the size of a printed document by just looking at it and flicking through it.
|
5 of 9 |
If you can see this message, you are probably not seeing this site in the way it was designed. This site uses cascading style sheets (CSS2) to control the way in which elements are displayed on the page.
You will still be able to access everything in this site, but we do recommend you upgrade your browser to a more recent, standards compliant, browser.