Columbia Web Style Guidelines

1. Have "about" files with owner of data and contact if different
   The only "requirement" that AcIS asks of departments and student groups to whom links are made in ColumbiaWeb is that one person takes responsibility for the data. This means ensuring the data adhere to AcIS Policy, University Policy, and federal law such as copyright and other restrictions on data transmissions. This policy has some benefits, such as attribution for work accomplished and contact information both internally and externally. If the contact for the group is different from the data "owner," then this distinction should be made clear, perhaps in an about file (see for example, Office of the Provost).

2. Use title fields
   The title field (e.g., <title>My Title</title>) is important for navigation (used in hot lists), for orientation (always at the top of browsers; crucial for long documents), and particularly for searching, since the search function of all Columbia files was released (cf. http://www.columbia.edu/search.html).

3. Use lowercase, short directory and file names, and numbers where appropriate.
   For example, we chose "/cu/hr/" as the home page for Human Resources. "/Columbia/HumanResources/" might have been more elegant, but four letters are easier to remember and type. Furthermore, because UNIX is case-sensitive, always typing file and directory names in lowercase alleviates the difficulty of remembering when the distinction was made. Finally, when used as a convention, numbers have definite advantages. For example, the University Record's Calendar is always of the form "record volumenumber issuenumber.12.html" Thus, for the University-wide events calendar, only one digit must be changed every week (e.g., "record2520.12.html" to "record2521.12.html").

4. Date all data
   Old data can be quite problematic from many perspectives. This is particularly crucial for departments and schools publishing course information. It is not enough to publish only the semester in which the courses are offered, but the exact date when the data was last updated. Thus, a Bulletin may be May 1 for the coming year, whereas the on-line schedule of classes is updated daily and a department publishing course descriptions may update weekly.

5. Check links
   It's very easy to make typos when constructing hypertext links. Check all links as the last step in publishing. Periodically check links to outside data.

6. Announce to groups or people when making links
   Collaboration is best when both sides have some input. Obviously, we would not want to be notified when authors link to Columbia. However, for any kind of academic project, interdepartment initiative, University-wide effort like course data, events, etc., it is important to maintain in contact with data providers. The result will be uninterrupted service if data are moved or changed.

7. Get approval when using data owned by others
   Most data falls under copyright. Almost all data fall under an individual or institution's "intellectual property." It is more than just polite to ask before using others' work, in many cases it is illegal not to get permission. Ignoring such issues can have serious repercussions, not to mention violating the golden rule.

8. Cite others' work
   Even if data are in the public-domain, owned by your institution, or you receive permission to use them, please cite others' material when using it. To not cite it is equivalent to plagiarism.

9. Scrutinize your work
   The following excerpt from the original ColumbiaNet style guidelines (1993) applies more than ever:

         INTEGRITY--ColumbiaNet is read worldwide and operates as a 
         significant public relations vehicle for the University. Editorial 
         integrity that may be deemed appropriate for a casual internal 
         audience may not be as readily acceptable by those judging 
         Columbia by ColumbiaNet. Therefore, there should be a stricter 
         scrutiny of text for spelling and grammatical errors. ColumbiaNet 
         text should always be the latest and best version of the text. As 
         it can be changed at any time, text should be reviewed one last 
         time as it is going on-line.
   

10. Don't add unimplemented links
    While it is tempting to complete one's index to a service and then fill out the links, it is not much more troublesome to leave the links inactive until the files are ready. Having the user receive a "file not found" message should be taboo; it wastes their time and falsely builds expectation.

11. Test work in other browsers
    This caveat should not be disregarded. If your browser forgives a typo (as some do liberally) and someone else's browser does not, the result for that user could be disastrous. The plain-text browser 'lynx' tends to be particularly unforgiving and is accessible to anyone using a browser like Netscape. Ideally, one would test pages on X-terminals, Windows, and Macintosh platforms with Netscape and Mosaic.

12. Warn of large images
    Since large images can take a long time to access, forewarning users with a note like "detailed image" or "large image," or indicating file size (1.2M) is a kindness.

13. Use trailing slashes in URLs ending with a directory
    Some browsers will return an error message or certain relative links may be inaccessible when trailing slashes are left out of URLs pointing to a directory, e.g. http://www.columbia.edu/ is preferable. Don't use trailing slashes after a file name.

14. Use alternate text in image references when they contain important text data or for thumbnails pointing to services
    For example, <img alt="Columbia University in the City of New York" src="low.gif"> in the Columbia home page is for plain-text browser users. Likewise, plain-text users accessing thumbnails pointing to other images would have to download the image to know what it looked like.

15. Use the latest version of the most popular browser for your platform
    The "Web Wars" should only intensify. To keep up with the general user population, use the latest browser with the most diverse set of formatting tools. This will feed your own creativity and will offer the highest level of service to the high-end user.

16. Consider other html tags
    The following tags may be useful in some contexts: <html> <base> <head> <body>, etc. Please consider them in implementing your services. In most cases, however, they are currently not necessary.