Last changed 16 March 1998 ............... Length about 1000 words (6,000 bytes).
This is a WWW document by Steve Draper, installed at http://www.psy.gla.ac.uk/~steve/HCI/WWW.howto.html. You may copy it. How to refer to it.

How to author web pages

(Up to main page for HCI module)

Contents (click to jump to a section)


by
Stephen W. Draper

Preface

These notes on using the WWW are written for MSc. in IT students in 1998 at the University of Glasgow, and refer to the computing environment they currently have. (Netscape Navigator 3 on Macs; BBEdit; AUFS file sharing; no personal machines.) (Up to main page for HCI module on that course.)

A. Getting set up

1. Initialisation

2. Editing environment

You can use Unix and vi to edit web files. But alternatively, you can now use BBEdit to edit web files in one window, while using the browser (Netscape) to view the result. Remember to do Save in the editor, and Refresh in the browser before expecting changes to appear.

B. Standard procedures

3. Web file copying

You can copy web source files around very conveniently.

Use this ability to fetch copies of web pages in order to:

4. Saving your browser state

Browsers have many settings, but these are lost when the lab machines reboot. To build up and save your settings, practice the routine of:

The Mac directory you have to find is:
BO720:System Folder:Preferences:Netscape f

The files to copy to and fro are (if you have them all):

Browser settings I myself set and preserve include:

5. Bookmarks

With a little practice, using bookmarks is one of the best features of the browser. Of course this only works if you are saving and restoring your files every session as in (4) above. Every page you like the look of, you can save a pointer to with a single keystroke (<cmd>D).

6. Copy and paste URLs

Whenever possible, copy and paste URLs, rather than type them in. They are long, and errors are very frequent. Get friends to email you URLs, so you can just copy and paste (<cmd>C then <cmd>V) from the email program to the browser. URLs are mostly very long; the font in the browser is the smallest available, thus increasing the error rate; it is not possible to know what errors matter (for instance some servers don't mind whether the URL ends in a slash, while others insist it is one way or the other; sometimes capital letters matter, sometimes not, ....).

C. Page design and structure

7. HTML syntax

The basics are simple; you can copy examples from the web; you can find reference sources. I simplify my authoring by:
  1. a) Having a standard skeleton file, and start new pages by copying the skeleton
  2. b) I have a reference page of my own to remind me of HTML constructs I use. It is at http://www.psy.gla.ac.uk/~steve/demo.html
    (Of course I have a link to it on my launchpad.) It's a bit sloppy as it is for private use, but it shows me the effect of each construct on the browser I'm using while reminding me of the HTML code.
  3. c) I use the "View Source" command frequently to look at the HTML code behind other people's web pages.

8. Labelling pages

The WWW is a hypertext: users arrive from anywhere at all. This is not like books. You cannot read a page from a book without having seen the cover. If you observe users, you very frequently see them mistake pages. But users cannot interpret a page sensibly without knowing: who wrote it, whether it is fact or fiction, polished work or a casual note, up to date or left over from last year's course, complete or being constructed. Until better practices emerge, I think we should heavy-handedly label the top of every single web page with all this information; particularly:

D. CGI scripts and forms

9. CGI scripts ...

The basic solution, as you may have partly discovered, is (if your login name were "mclayg"):

  • 1) in your web page, with forms you will have a bit like this:
    <FORM Method="POST" Action="http://www.dcs.gla.ac.uk/scripts/personal/mclayg/ex4.3.cgi">
    that includes the file name of the script or other executable software.

  • 2) This must be in a place that the web server will allow itself to look for executables (restricted for security). Here, the arrangement seems to be: you have a web directory, pointed to by ~mclayg/public_html but actually at
    /local/www.stud/personal/mclayg
  • 2a) You create a subdirectory there for your scripts, perhaps called "scripts".
  • 2b) Support creates a symbolic link that points to your new scripts subdirectory, called "mclayg" i.e. the symbolic link has the full file name of /local/www.stud/scripts/personal/mclayg

    The URL http://www.dcs.gla.ac.uk/scripts/personal/mclayg/test would now execute a script called "test" in your scripts subdirectory.

  • 3) The script has to return HTML text, including starting with a MIME header "Content-type: text/html" followed by a blank line (i.e. 2 linefeeds). The following perl line would do that:
    print "Content-type: text/html\n\n";

    Examples can be found in:
    /users/it/staff/steve/student/mclay
    or by snooping beginning in: /local/www.stud/scripts/personal