There are three goals in organizing and naming your files, all of which lead to similar conclusions:
You want the resulting filenames and URLs to be easy to type.
You want the filenames (and therefore the references to them in the documents) to be usable without change on as many different servers as possible, so that you can migrate to the most appropriate server at any time with minimal effort.
You want the filenames (and therefore the references to them in the documents) to be usable without change on as many different personal computers as possible, so that the responsibility of maintaining the files can be assigned to someone else at any time with minimal effort.
The following rules achieve those goals:
Organize your files into folders, but limit the depth of nesting of folders within folders within folders, etc. In particular, do not create more than six levels of folders for your web files.
Give your files and folders names that are "short" but understandable.
Filenames and folder names must not include any space characters.
The underscore character ("_") and the hyphen character ("-") are both legal, but both require extra effort to type, and so should generally be avoided.
Capital letters are also legal, but they require extra effort to type, and on some servers, including ww2, are not distinguished from lowercase letters, so either:
use only numerals and lowercase letters, or
keep the case of all letters for the file and folder names on your personal computer exactly matched to their cases in your HTML, including HREF and SRC attribute values.
If you already have filenames and links between them that specify mixed case letters, you need not change them for use on ww2, unless there are two files whose names differ only by the case of one or more letters.
Do not give your folders or subdirectories names that include periods, use only letters or numerals.
File names should have exactly one period ("."). Some web servers can tolerate more than one period, but some cannot. The filename's "type" or "extension," the part after the period, should be chosen conventionally (e.g, ".htm", ".html", ".jpg", or ".gif"), because the web server software may well use that part of the filename to tell the browser what kind of file it is, so the browser can figure out how to display the contents. The file type must not be "DIR", because that would falsely identify it as a subdirectory (folder) on some servers.
File and folder names should have no spaces, nor punctuation marks, beyond those discussed above.
There are several issues to attend to when organizing your web files on your hard disk. The first principle is to establish a collection of folders on your hard disk that exactly correspond to the folders for your Web files on the server: identical names, nested within each other in the identical organization. This makes it possible to test your files from your hard disk, by using the Open File choice from your browser's File menu. It will also make it possible for you to effectively test your files using the staging server, which we will discuss in more detail later.
A second principle is to help the browser's cache to provide the greatest possible advantage. You do this by using exactly one copy of each image file. Then, every time it is called up, the browser will know that it already has a copy in its cache, and will not ask the server to send it again. This applies not only to your own image files, but especially also to the collections of image files we maintain on the server for shared use. If your reader has recently seen any of the pages that use an image that you reference, it will already be in the cache the first time it appears on your page. This reduces the load on the server and on the network, while speeding up the display of your page.
In order to see the full layout while testing from your hard disk, including all images, copies of the shared image files need to be on your hard disk in places exactly corresponding to their location on the server. This is therefore specific to the configuration of each server. We have configured ww2 to use the shared graphic image files according to the scheme outlined next.
We suggest that you create your directory structure according to the following plan:
Create an HTML directory (or folder, we use the two terms interchangably) in a location that is easy to navigate to (e.g., at the top level of your hard disk, or at the top level of your "Documents" folder).
Inside that folder, create a folder for each separate subsite you write web pages for (your own personal web pages, and any official department or organization pages you write). In the illustration below, we have called those folders "myfiles" and "ourdept".
The HTML folder corresponds to the "ww2.ohio.edu" folder on the server (but the folder on the server contains a folder for every subsite, while you only have folders for the subsites you work on). Inside the subsite folders, you will create folders and files whose names exactly match those you create inside the corresponding folder on the server.
Also inside your HTML folder, but not inside any of the subsite folders, create a folder called "www".
Inside the www folder, create two folders:
One folder called "ougifs"; you will save copies of the older shared image files (GIF and JPEG format) from the server into this folder. In the illustration, there is only one such image file, link.gif.
Another folder called "images", next to the "ougifs" folder. This folder will receive your copies of the newer shared image files, to be used, for example, when matching the look and feel of the Front Door.
This will produce a structure on your hard disk that can be diagrammed as illustrated on the left portion of the figure:
The right portion of the figure shows the organization of your files and folders on the servers. The red line shows the transfer of your file to the production environment, ww2.ohio.edu. The blue line shows the transfer of your file to the staging environment, wws2.ohio.edu. A more detailed discussion of using the staging environment for your personal testing is included later in this chapter.
The advantages of organizing your hard disk files as shown on the left are that you can use an identical relative URL to point to any of the shared graphics, in the ougifs folder or in the images folder, whether on your hard drive or on our servers, as discussed in Visual Issue 9, below.
There are essentially two kinds of files you will be working with, text files and binary files. The former includes HTML files (which contain the text to be displayed, links to other files and resources, and pointers to binary files). Binary files contain any images, sounds, videos, etc., to be displayed. Preparation of the binary files is outside the scope of this guide, but Chapter III does include instructions on how to transfer them to the server.
You have many choices for preparing your text (HTML) files. The simplest is to use a standard word processor on your personal computer and save the result as a text file. Specialized HTML editors are available for both Macintosh and Windows computers (some free or shareware, others commercial). These will involve some initial learning, and may make false assumptions about the server configuration or about your readers' browsing environment, but will permit you to use your mouse to take advantage of their special features.
Current versions of Microsoft Word, for Windows and for Macintosh, can import and export files in HTML format. This is potentially valuable for publishing documents on the web that are based on documents that already exist as word processor files. The primary difficulty with these word processing programs' HTML capabilities is that their HTML export features routinely attempt to replicate the appearance of the hardcopy document, rather than its structure, producing Web pages that are fragile. This subject is addressed in some detail in Appendix VI. Another difficulty with current versions of Microsoft Word on both Windows and Macintosh is that it cannot be used to edit HTML files without causing unintended modifications of the HTML.
On Windows machines, Notepad can be used to edit HTML files directly, with no unintended side-effects. There are a few tricks to be aware of:
When you first save an HTML file, set the format to Plain Text and enclose the filename in quotes (" not '), including the .html at the end (e.g., type "index.html" as the filename); this is necessary in order to prevent Notepad from adding ".txt" after the ".html."
Within each editing session, you can save multiple times without having to re-specify the filename.
When you open an existing file to update it, you will have to select "All files" in order to be able to see the HTML files, because their names do not end with ".txt."
On the Macintosh, TextEdit can be used to edit HTML files, also with no unintended side-effects. In order to edit HTML files gracefully, you may need to change your Preferences settings; the following have worked well for the past several versions of the Mac OS and TextEdit:
Format - Plain Text;
Do not check (at the bottom) Smart quotes, dashes, or links;
Do check smart copy/paste and text replacement.
Open and Save:
When opening a file, do check Ignore rich text commands in HTML files;
When saving a file, do check Delete the automatic backup file;
When saving a file, do not check Add ".txt" extension to plain text files.
You can use any browser to test your web files on your personal computer, before making them public. In the File menu, the choice Open File (or Open Location, depending on browser version) will permit you to examine any HTML file you have created, and any files it links to, provided that the links specify URLs that translate correctly on your system. This means that it is less typing effort for you in creating the links, and is easier to test and maintain, if you place all related files in the same subdirectory, and specify them in the links by filename only, without protocol, IP address, or path. If the scope of your project requires organizing the files into multiple subdirectories (or folders), then you should use relative path names instead of absolute URLs. Examples of relative path names are included in section G, part 2, below. Using relative path names in all your URLs will also make your life easier if at some time in the future you should decide to migrate your files to a different web server.
Some testing of new portions of your web materials will require that the files be placed on the server along with the related files. If there is no link anywhere that leads to your file, you can do this "concealed" testing by just opening the specific URL for your new file, and following the links it contains, to verify that all is well. This technique does not work very well for replacements of existing files (to which there will already be many public links and private bookmarks in place), but is useful for brand new parts of the web. Using the staging server, wws2, for server-based testing is described in the next sub-section.
If you are testing locally on a computer that is not connected to the network, such as at home, your web browser software may object, and references to images that are on the server but not on your personal computer will fail, even though they would succeed if your page were on the server.
The Front Door servers have been configured to provide for on-line testing of new Web pages and especially of re-organized Web sites. This has been arranged by running two servers: files uploaded to the production server, ww2.ohio.edu, will be seen by the world only with URLs starting with http://www.ohio.edu/; files uploaded to the staging server, wws2.ohio.edu, will be seen with URLs starting with http://wws2.ohio.edu/.
Testing from your hard disk is not possible for pages using the generic e-mail script (see Appendix V). Web pages using that feature can only be tested from the server. On-line testing also permits other people to review your pages from their own computers, before you go public with the new pages. This makes it easier to gather feedback about new designs, and therefore will improve the overall quality of your Web site.
Files uploaded to the staging server, wws2, will be displayed with the same URL that your regular files use, except for the substitution of "wws2." instead of "www."; for example:
Because these are test sites (and likely to be left with outdated information when testing is concluded), we do not want any of the pages to be included in any keyword search index, such as Google or Yahoo. Therefore we have configured the entire wws2 server to be password-protected (but any valid Ohio ID and password will work). That is also why the URLs in the table below are presented as simple text, not as clickable links. Type the test URL into your browser once (or use copy-and-paste), to open the page, and then set a bookmark to it.
(Files uploaded to server "ww2.ohio.edu")
(Files uploaded to server "wws2.ohio.edu")
For most people, we believe the best approach to populating your folder on the staging server is to upload the files from your hard disk, just as you have done with the production server. If you have so many files and folders that this seems unduly burdensome, please contact OIT (email@example.com, or 593-1222) for assistance.
We have prepared separate notes on the procedure for managing the transition from staging to production for a new Web site or a massively revised Web site. For small changes, just upload the files to their production locations, as soon as testing is completed.
The server does not have an infinite amount of disk space. If you keep in mind the fact that part of your audience has only dial-up connections to the internet, and consequently keep your files of reasonable size, you should encounter no problems. Remember that sound and video files are generally quite large, and that modern digital cameras will happily take photos that require major reduction before placing online. Please make a point of removing files that are no longer part of your site (particularly large files). If you run out of disk space, please contact OIT (firstname.lastname@example.org, or 593-1222) for assistance. Be sure to let us know the URL of your home page, so that we can increase the correct quota!
Both the production and staging servers should be up and running all of the time, except for brief outages installing routine software updates. Such updates will be done without prior announcement only during OIT's regular "service windows" of midnight to 6 am on Wednesday and Saturday mornings. If you ever experience sustained misbehavior, or repeated transient misbehavior, of either the production or staging servers, please call the OIT Service Desk, at 593-1222, to inform us, so that we can fix it. When you upload a file that replaces an existing file, the new version will be displayed promptly, but not immediately, because the production and staging servers reduce time waiting for disk access by keeping recently accessed files in RAM. The delay should be at most two minutes.
The files that you use during on-line testing should require no modification in order to be placed into production, when the time comes. Just be sure to follow these rules:
All image tag SRC attributes for any of your own images, or for any of the shared images from the /www/ collection, should specify the graphic image file with a relative URL, using "../" as needed to navigate among folders. If you have organized your hard disk's Web files as outlined in Part A of this chapter, you will be able to view your pages with the graphics displayed correctly from your hard disk as well as after uploading to the staging server, including the shared graphic images in the old "ougifs" folder and in the new "images" folder.
All anchor tag HREF attributes for links among your own pages should specify the target with a relative URL, using "../" as needed to navigate among folders. You will be able to test these links from your hard disk, too.
If you are responsible for multiple first-level URLs, do not use "../" to get from one to the other, use either of the methods presented in points 3 and 4.
All anchor tag HREF attributes for links to Front Door pages in other subsites should specify the target with an absolute URL, starting with "https://www.ohio.edu/" and including the full path and filename.
This is a change from our previous recommendation!
If the link is to the subsite's home page, so that leaving off the filename will still bring up the page you want, you should leave off the filename. This will permit the link to continue to work even if that subsite moves between the static-page server, CommonSpot, or the new CMS: the filename extension is different on those three servers, so a link that includes the filename will break or require special coding.
All image SRC attributes and all anchor tag HREF attributes for links to other people's pages and images should specify the target with an absolute URL, starting with "http://" or "https://" and including the full path and filename (with the exception for home pages, noted above). Those links should be to the production version of their Web site. These links will work from your hard disk, if your computer is connected to the network.
When you re-organize a Web site, please do your best to avoid frustrating people who follow links from other sites and from search engines. In particular, it is a good idea to follow these guidelines:
Whenever your new site has a page whose contents correspond closely to those of a page from your old site, make sure that the new page has the same name and is located in the same folder, so that it has the exact same URL as the old page.
Whenever your existing site has a page for which there is no single corresponding page in the new site, create a replacement page, which will have the same name and be located in the same folder, so that it has the exact same URL as the old page, that contains links to your new home page and also to any other pages in your new site whose contents closely correspond to the various parts of the old page.
If you really want to "retire" a URL, create a replacement page such as described in the previous point, with the body containing text warning that it will be removed in the future, and containing a link to the single best new page. You should also use META tags in the HEAD of the page to automatically jump to the new URL (see technical content standard 6, below) -- with any luck the search engines will recognize that they should not index that page, but only the replacement page.
If you decide to re-organize your site in a way that results in an entire second-level subsite going away, please consult with Web Services: we may be able to adjust the configuration of the server to redirect browser requests for the old resources, without you having to create individual replacement pages for each of them.
These comments are intended to promote a basic degree of consistent look and feel to Ohio University's presence on the web, while still leaving opportunities for creativity by each pagemaster. We expect that this list will continue to evolve on the basis of experience and suggestions, and we request that you provide us with feedback in person (379 West Union Street Office Center), by telephone (593-1017), or by e-mail to email@example.com.
The Information Resources Council 1996 statement on Ohio University World Wide Web Guidelines is available on-line.
Our experience confirms that of many others: You and your viewers will find the results to be more satisfactory, easier to maintain, and easier to use, if you thoroughly plan ahead of time the organization of your web presence. Those plans should include not only the division of your content among the several pages, but also the organization of the content within each page, the primary links among the pages, and the files' locations within the folder structure on the server.
For discussion, we organize the content standards into three groups, realizing that many items do span two or all three.
Eventually, each official Ohio University Web page will contain at least three reciprocal links back to the Ohio University Front Door: one using the signature logo graphic in the header, one using the logo graphic in the footer, and one as part of the copyright notice, as illustrated in the footer of this page and as described in the on-line style guide at https://www.ohio.edu/brand/web/.
Each personal or organizational home page should have a link back to the Ohio University Front Door, and personal home pages should have a link to the individual's department home page, if there is one. We certainly permit, but do not expect, that other personal or organizational pages would have reciprocal links.
For reciprocal links other than the copyright statement and the logo graphic, a text link would be the minimal approach; a graphic link such as the following would be a step better:
On the static-page server, that can be achieved with HTML such as the following:
SRC="../www/ougifs/fdreturn2.jpg" ALT="Ohio University Front Door"
ALIGN=middle HEIGHT=24 WIDTH=175 BORDER=0></A>
On other servers, that can be achieved with HTML such as the following:
ALT="Ohio University Front Door"
ALIGN=middle HEIGHT=24 WIDTH=175 BORDER=0></A>
You can take a look at the images that are available in the shared image folders:
Consider including a page of external-to-Ohio University links - a "hotlist" of resources likely to be of interest to people who would explore your pages. Do not delay creation of your other web pages - publishing your own real content is more urgent. Keep the following points in mind as you work on your hotlist:
Do not put your hotlist on your home page, but you might well choose to have one link on your home page that points to the hotlist page. Many people viewing your page will be coming in from outside with an interest in what Ohio University has to offer on that subject. We should therefore avoid cluttering our home pages with links to items that they have probably already seen. At the same time, many people within the University are looking for external resources, so having a centralized, departmentally maintained hotlist is a valuable service to provide.
All external hotlist links should be verified by the person responsible for the page's contents, on a regular basis, and corrected as needed. Automated tools can verify that something is there to link to, but cannot be counted on to detect pages that display "This page has been moved" messages, or worse. This expectation of regular review should motivate the person responsible to keep only the better links on the page, pruning out the less important ones.
Every page should provide a mechanism, such as an e-mail link, to communicate with the web maintainer for that page, for sending suggestions, comments, and questions. The visible text for this link should include the E mail address itself, for the benefit of those whose browsers or network connection prevent them from sending e-mail. An example e-mail link can be found at the end of this file.
For personal pages, for example, the e-mail address you should specify in the link is your own internet address, such as: "firstname.lastname@example.org" (generally, without the quotes).For departmental pages it should not be the personal e-mail address of any department employee, because this address will be embedded in many files, and will therefore be a major pain to revise. If job assignments change (or the web maintainer goes on vacation), it should be possible to easily arrange for someone else to deal with the messages. This will happen if the e-mail address you specify in the link is the departmental shared-inbox address, such as: "email@example.com"; for details, see https://www.ohio.edu/oit/email/learn/departmental.cfm.
Requests to create such departmental shared-inbox addresses, and requests to change the list of people with access to an existing shared-inbox address, should both be sent to firstname.lastname@example.org.
To prevent the viewer from feeling stuck, every page should have at least one external link, besides the e-mail for comments. Usually that link will point back to the page from which the current page is most likely to have been reached. If in doubt, pick one arbitrarily, or provide links "back" to more than one likely origin. Long pages should have those backlinks at both the top and bottom. You may want to include also a direct jump back to the departmental home page for those pages that are more than one or two levels down.
Every page should be critically reviewed from Chrome, FireFox, Internet Explorer, and Safari, and any other web browser you can use (or recruit someone else to use on your behalf). This critical review should include at least one Windows-based browser and at least one Macintosh-based browser. Many browser-specific HTML features look dreadful in other graphical browsers. You should also adjust your browser window to a variety of widths while looking at your pages: not everyone has a screen the same size as yours, and even those who have a larger screen may well choose to devote only part of it to their browser's window.
The page at https://www.ohio.edu/demo/static/width-test.html includes a horizontal rule that is the same width as the whole screen of an iPhone 4 -- not the smallest mobile screen, but one that still has many people using it. You should certainly test down to that size, or smaller.
A more complete discussion of these issues is included in Appendix VI.
When a page becomes obsolete, as opposed to a whole subsite or sub-subsite is removed (e.g., the page is retired, you move it to a different directory, the content is re-organized and split between other pages, etc.), do not immediately delete the old page. Instead, create a modified file of the same name to replace it. The contents of this "replacement page" should state that the page is now obsolete, and provide appropriate guidance to the reader. Have a live link in the file leading to the new page, with the anchor tag's HREF being either
the relative URL to get from this page to the new page, if it is part of the same first-level subsite of the same server; or
the absolute URL of the new page, if that page is not part of the same first-level subsite of that server.
The displayed, selectable text for the link should include the complete, absolute URL of the replacement page. You may also choose to state that this forwarding page will be removed in the future, and you may choose to invite people to notify the maintainer of the file containing the link they followed to get there.
You may also choose to include a tag of the following form in the HEAD of your HTML, which will cause the page to automatically transfer to the new URL for those readers whose browsers can and are configured to support page refresh directives in this style:
<META HTTP-EQUIV="refresh" CONTENT="10;URL=newURL">
The newURL, shown in bold, red, above, for those with graphical browsers, should be the same as that used for the HREF in the anchor tag, discussed above. The number, shown in bold, green, above, for those with graphical browsers, is the duration in seconds before the transfer takes place; it should be long enough for the person to read the page, and it should be long enough for the person to click the browser's "back" button. This "replacement" page should have minimal text and no or minimal graphic images: your readers will be frustrated enough that the link they followed did not lead to anything interesting; don't add to their pain by taking the time to load extended text or any unique graphics (standard header graphics that are likely to already be in the browser's cache are OK). The TITLE tag should give a clear indication that it is a retired page, so that if it comes up on search engines, people will know not to bother following it.
The following example illustrates such an approach to this situation:
<TITLE>RETIRED PAGE - Information Technology at Ohio University</TITLE>
<META HTTP-EQUIV="refresh" CONTENT="10;URL=https://www.ohio.edu/oit/">
The Information Technology pages have been re-organized. The new home page is:
If your browser does not automatically jump to that page in ten seconds, or if you don't want to wait that long, just choose the link, above, to go there right away.
Whenever possible, use relative path names for links among your own files (see section G, part 2, below; the HTML I seminar notes; and section A, part 2, above). This will simplify typing and testing now, and will make it easier for you to migrate your department's files to another web server if you decide to do that in the future.
Documents that contain relative path references should NOT have a "<BASE>" tag in the head of the document (even though that is a "legal HTML" tag; see Aronson, 1994, page 27; Graham, 1995, pages 86-88). This tag would need to be changed if you were to move your files to a different server or subdirectory, and in the meanwhile it would prevent testing of the file and its related files from a local disk drive or from the staging server. (The currently published files would be displayed, from the server, according to the "<BASE>" tag specification, rather than the revised files from the local disk or the staging server.)
Even though the browser will re-wrap your text for display to suit itself, you should format your raw HTML files for easy readability, if your editor permits you to control that.
Avoid lines longer than 80 characters
Place paragraph, horizontal rule, table, table row, and break tags on lines of their own
No line breaks inside URLs (neither for anchor HREF nor for image SRC)
Put tags' keywords consistently in all lowercase letters, or consistently in all uppercase letters (e.g., <HEAD> or <head>, but not <Head>)
This is especially important for the sake of your assistant, who may have to modify files in your absence, and for the sake of your eventual successor.
Each HTML file should have a <HEAD> ... </HEAD> section that contains a <TITLE> ... </TITLE> block. The text of the title will be displayed by many browsers (for example, Internet Explorer, FireFox, and Safari all put it in the window title bar), and it is used by a number of automated web search and indexing procedures, including the keyword-searchable index of Ohio University Web pages available from the "Search" feature on the Front Door. Your pages will be easier for people to find through these search engines if you make the title descriptive of the contents, using the appropriate keywords that people who would want to find it might search on, and with no acronyms that have only local meaning. The title is also routinely used as the visible name for any bookmark your user sets to that page, and many browsers display a limited number of characters of the bookmark title in the "Bookmarks" or "Favorites" window or menu, so it is considerate to have the first dozen or two characters be especially revealing as to what the page is about.
Linked images: if you have an in-line image (thumbnail logo, or whatever) that is clickable, and you have adjacent text that is also clickable to get to the same location, then the image and the link text should be part of one anchor tag, by placing the <IMG> tag inside the link, along with the link text.
Including the graphic inside the link, causes the ALT string to be part of the link text when viewed from Lynx. This also has the result that in Lynx a single down-arrow keystroke will move past that link, instead of requiring two keystrokes. Consider whether to include a space character or non-breaking space (" ") between the <IMG> tag and the rest of the link text. For example, HTML such as the following:
<A HREF="http://www.ohio.edu/oit/"><IMG SRC="../www/images/sgar.gif" BORDER=0
ALIGN=MIDDLE ALT=""> Go to the Office of Information Technology Home Page</A>.
will produce the following:
Clicking on the icon functions identically to clicking on the highlighted text of the link, and with many graphical browsers there is no "dead" space between them where clicking accomplishes nothing.
The URL listed above for the image source is a relative path name that will work if the reference occurs within a top level file, such as your home page, on ww2. If you want to use the reference from a file that is in a subdirectory, you would need to pre-fix the given URL with an additional "../" for each level farther down. Using this form of relative URL for a graphic in the server's central collection makes it possible to preview the page cleanly on your local hard disk, by copying the graphic file into an appropriately named and located subdirectory (or folder) on your hard disk.
The complete URL for your page should appear visibly near the bottom of the document, for example in the routine "[name] revised this page ([URL]) on [date]." text that is the topic of Content Issue 1. This is for the benefit of those who print pages from browsers that do not automatically include complete identifying text in the printout.
The keyword-searchable index of Ohio University Web pages, accessible through the "Search" feature on the Front Door, identifies the pages in the search results display by using the text contained within the <TITLE> ... </TITLE> in the head of the page. In order to avoid having different pages appear to your readers to be duplicates (which might lead them to not bother checking that link), be sure that every page's title is both unique and descriptive.
The keyword-searchable index of Ohio University Web pages, accessible through the "Search" feature on the Front Door, may contain duplicate entries (and therefore will both respond more slowly and also provide less-useful results) if the same page is referenced in more than one way. This is an issue both in the anchor tag HREFs and also in imagemap data blocks (see Appendix III). This leads to the following rules of thumb:
For default, index, or welcome files, which the server will permit you to leave off the end of the URL, always be very careful to consistently include the filename in full, or consistently exclude the filename (e.g., you could use "https://www.ohio.edu/lookup/" or "https://www.ohio.edu/lookup/index.html", but not both). Including the filename has the advantage of working correctly while checking files from your hard disk; excluding the filename has the advantage of working even after a change of server (e.g., CommonSpot home pages are index.cfm, but ww2 home pages are index.html, and the new CMS will likely have yet another filetype).
Because some Web servers are case-sensitive in the path and filename part of the URL, search engines often presume that pages found by following URLs that differ only by case are in fact distinct. Since ww2, wws2, and people2 are not case-sensitive, any case combination will work when browsing pages on those servers; therefore we urge that you consistently use the one that is easiest to achieve: if manually typed, all lowercase, if selected through software dialogs, exactly matching the case of the file and folder names on your personal computer's disk drive.
Following these rules of thumb will have the added advantage that browser caches will not waste space on duplicate copies of the referenced files, thereby reducing the time to display your pages and reducing the load on the network and the server.
[The item that was previously in this place has been rendered obsolete by technical developments over the years, and is therefore withdrawn.]
Each HTML file should have appropriate keywords and description <META> tags in its <HEAD> ... </HEAD> section. These tags should indicate the nature of the content of the page. This is especially important for your home page and any other navigational pages, which will contain little or no content, and might therefore not show up in search engine results. More details are available in the keywords META tag section of the HTML Tags Summary.
Every page that contains information (as opposed to primarily navigational pages that are mostly "just" links) should display the revision date and the name of the person responsible for the information (who may be someone other than the departmental web maintainer). The more volatile the information, the more prominently the revision date should be displayed.
It is important for the viewer to be able to estimate the validity of the displayed information. This is not an issue for links, since they fail quite visibly if they are not valid! Displaying the date and author is especially important for information that may be cited by students or scholars who have learned something from that page. Displaying the name of the author raises the odds that he or she will take seriously the responsibility of keeping the information accurate and up-to-date.
Official (as opposed to personal) pages, in particular, should be reviewed periodically. After you decide how often a page should be reviewed, document your decision and keep track of the most recent review's completion date.
Departmental home pages (and many others) should also have postal address and telephone contact information, including ZIP and area codes.
See Technical Issue 9, about <HEAD> and <TITLE> tags.
If you "borrow" HTML or graphics from someone else, or base your work on something someone else has done, be sure both to visibly acknowledge that fact and also to seek permission from the original author. This is a legal as well as ethical requirement. Once you have their permission, copy the file to your server, so that your traffic does not load their server, and so that they can be free to modify or remove the original without concern for the impact on you. Failure to work from your own copy does also leave you vulnerable to a wide variety of unpleasant pranks if the original author takes offense.
If you have a roster of department members, use a consistent format and display each individual's e-mail address as a clickable "mailto" link. If any of the individuals has a personal home page, make their name in the roster a link to their personal home page. Consult each individual before publishing his or her e-mail address or linking to his or her web page.
For most of your audience, you can "pre-load" the Subject of the e-mail by specifying the link as shown below:
When you do this, you must include the quotes around the entire HREF value, and therefore you may include spaces and punctuation marks within the pre-loaded Subject. Your reader may choose to edit the subject, but most often will not. If nothing better occurs to you, specifying the path and filename of the web page will surely help you establish the context for whatever they have written.
If you have a roster of students, use a consistent format and display each individual's e-mail address as a clickable "mailto" link. If any of the individuals has a personal home page, make their name in the roster a link to their personal home page. Consult each individual before publishing his or her e-mail address or linking to his or her web page.
Special considerations apply to students (including both undergraduate majors and graduate students in the department), because they have the right, under Federal law, to require the University to conceal their presence as students at the University. At any given time, about 100 students at Ohio University have active requests for such privacy. There is a standard form that students fill out and submit to the Registrar's Office, to exercise this right. The Registrar's Office staff then mark that student's records in the SIS system.
Any web-visible roster of students must have a prominently displayed revision date. That revision date must not be changed without confirming that none of the listed students has requested privacy. That confirmation can be done directly using SIS, or indirectly using the people search feature found at the top right of many Ohio University pages, because the people search system is regularly updated from SIS, and all students whose SIS record indicates that they have requested privacy are concealed by the people search.
For training in using SIS, contact the Registrar's Office. To use the people search for this purpose, go to the Front Door, https://www.ohio.edu/, click on search icon (magnifying glass) in the upper-right, click in the search box, type the student's name, select "People" instead of "ohio.edu," and click on the "Search" button. If you find the student, all is well. If you don't find the student, remove his or her name from the displayed list unless you can confirm directly with him or her that he or she still wants to be listed.
Another Ohio University web author may want to provide a link into a particular spot within your document. Please consider accommodating requests to provide an anchor tag for them to link to (<A NAME="id"> ... </A>) at specific locations. If such a request seems unreasonable, please discuss the issues with the requester. Unresolved questions should be brought to the attention of the Web Team.
Please consider requests from other Ohio University web authors who wish to have links added to your document, pointing to particular items of theirs. If such a request seems unreasonable, please discuss the issues with the requester. Unresolved questions should be brought to the attention of the Web Team.
Do not re-invent the web! Link to central resources.
Do not re-create information that duplicates information provided by others.
Do not re-type anything that is already being published.
One of the daunting aspects of the world wide web is the responsibility for revising and updating all that information. In cases where there is a department within the University (e.g., Registrar's Office, University Publications) that is responsible for hardcopy publication of information you want to have on-line, please contact that department to make arrangements for on-line publication.
As the University improves its web presence, there may well be situations where people want information to be on-line that the responsible party is not yet prepared to place on-line. When that happens, please contact the Web Team, so that we can coordinate the various projects that are in progress.
By working with the party responsible for the information that you want to have linked with yours, you can ensure that the proper tags are inserted in the on-line version of their documents, too.
Unresolved issues (whether of content or timetable) should be brought to the attention of the Web Team.
See Technical Issue 5, about using multiple browsers to check the appearance of your pages.
See Technical Issue10, about the use of in-line images that are parts of links.
Bullets and other small graphics that are not clickable parts of links they are adjacent to should not be blue, because that is the default color of clickable links in many browsers. Likewise, they should not match any non-default color coded for links in that page.
See Content Issue 4, about the display of department employee rosters.
See Content Issue5, about the display of department student rosters.
Separators: it is better to use horizontal rules (tag <HR>) than short, wide graphics, but beware the tendency of many readers to stop scrolling when they encounter a horizontal rule. Using horizontal rules instead of graphics speeds up display, reduces network traffic, works reasonably in Lynx, and works as intended when the user sets a graphic display to a width outside the range you tested. For variety, you can use the SIZE and WIDTH attributes inside the tag. For example, <HR SIZE=15 WIDTH=60%>, produces the rule below this paragraph:
For "large" documents (which probably should not include your home page):
Include a Table of Contents near the top with internal links down to the various sections.
Use appropriate header tags for the titles of the sections that are important enough to rate Table of Contents entries.
Consider whether or not to provide a "Return to Table of Contents" link, set off with white space above and below it, every two or three screens.
Depending on the lengths of the individual sections that rate Table of Contents entries, it may be appropriate simply to provide one return link at the end of each section. If a section is very long, you should consider placing one or more "extra" return links in the middle; if a section is very short, you should consider placing return links only every two or three sections.
Consider whether to split the document among several files, so that each one loads more quickly, or to keep it as one file, so that a single print or save command will permit your user to grab a complete copy.
Use large graphics with care - they slow down the display and of course don't help the Lynx user or those using speaking browsers. Consider placing large graphics on subsidiary pages, rather than on the first page of a group. If you must use large graphics, consider saving them with more aggressive data compression, but don't overdo that: there is no point in a large, ugly image. You may well be able to reduce their size by half without significantly degrading the image quality. See also Visual Issue 17.
If you use any of the standard images (large or small), do not work from a copy in your own web directory. Instead, reference the copy stored centrally on the server. Using the central copy will cut down on server disk space usage all the time. It will also cut down on network traffic and on server load, and will speed up display of your page, whenever the browser already has a copy in its cache from a previous display.
A number of standard graphics are available on the Front Door servers (through "https://www.ohio.edu/www/"). These are the complete absolute URLs, and as usual we strongly advise that you use relative URLs. There are two relative URL forms that you might choose to use:
This form, relative to the page it is in, has the advantage that you can copy the images you use into the appropriate folder on your hard disk (as described in Part A), and then have it be visible to your browser while checking your work from your local hard disk, without having to run a server on your personal machine. If you do choose this approach, you will need to pre-fix another "../" for each level down that the referring HTML file is located within your directory structure, and you would therefore have to revise each IMG tag referring to such central GIFs if you move an HTML file up or down a level in the directory structure.
This form, relative to the server the page is on, has the advantage of working identically from all levels of subdirectories on either server. It is therefore especially appropriate at the beginning, when the organization of your files is most likely to change significantly. You will not be able to preview the complete file, with all graphics, from your local hard disk, unless you are running properly configured server software, which uses disk space and CPU cycles, and might display the files to the world at large before you were ready!
Newer versions of HTML provide options for controlling the colors of background, links, etc. Except as noted here, please exercise these choices with caution.
Individual browsers can be, and often are, configured to ignore the color directions in the HTML files, so you cannot count on your colors being used.
Background images that show pale on your monitor may display so darkly on other machines that your text cannot be read. (This has been observed even with both machines running the same browser!)
If you feel you must do something different from the default, you will probably not encounter any nasty surprises by specifying a background color that is paler than the default gray, especially if you go all the way to white, by using HTML such as:
The choice of a white background is especially appropriate, because it increases contrast, and therefore enhances the readability of the text.
Please do not specify any of the TEXT or LINK colors: people become subconsciously attuned to the colors that their browser uses by default. Your reader has been building up an intuitive feel for the meaning of various colors, based on the default behaviour of his or her browser. When you try to override that, you are discarding the reader's intuition. This is so far from being "user friendly" that it deserves to be called not merely "user-hostile," but perhaps even "user vindictive."
See also Appendix VI.
Transparent GIFs are often a nice touch, especially if your site includes pages with more than one background color.
On the web, unlike hardcopy publishing, type faces are controlled by the browser. Lynx uses fixed-pitch fonts for all text, because Lynx works with displays of 24 rows of 80 characters each. Internet Explorer, FireFox, and Safari usually use two type faces, a proportional-spaced font and a fixed-pitch font.
Use the typewriter (<TT>) and
(<PRE>) tags to force graphical browsers to use a fixed-pitch font. Pre-formatted text also preserves space characters and line breaks -- there is no re-wrapping. With some browsers, the <PRE> and </PRE> tags also each force a paragraph break (your browser is doing so if the "pre-formatted" appears above on a line of its own). Beware the tendency of graphical browsers to use a smaller-sized font when displaying fixed-pitch fonts; the examples above have explicit <FONT SIZE="+0"> tags inside the <TT> and <PRE> tags, to force a readably large display in some versions of Macintosh FireFox; with other browsers or on other plaforms, other results may be observed.
Use the <STRONG> tag for emphasis, rather than the <B> (bold) tag: Lynx and other browsers that don't know about <B> will ignore it, leaving no emphasis at all!
Use the <I> (italic) and <CITE> tags very sparingly, if at all (and never for emphasis): they are both displayed by many browsers with italics, and so are routinely illegible or very challenging to read on-screen, even though they may print nicely. The primary use would be only in bibliographic citations where failing to follow the conventional typography is inappropriate.
Use the <ADDRESS> tag very sparingly, if at all: it is also displayed by many browsers with italics, and so is routinely illegible or very challenging to read on-screen, even though it may print nicely.
Use the <FONT SIZE="-n"> tag very sparingly, if at all: most people adjust their browser to display text with a default size that is as small as they can comfortably read on screen, because that provides the maximum amount of interesting information on the screen at any one time. Even going down one step in font size will make it much harder to read. If you use a FONT tag that specifies sans-serif faces (such as the Ohio default: FACE="verdana,arial,helvetica,sans-serif") then a SIZE="-1" is appropriate: sans-serif faces are readable at a smaller size than serif faces, such as Times Roman.
Use the underline (<U>) tag very sparingly, if at all: it may create confusion with links.
DO NOT PUT LARGE BLOCKS OF TEXT IN <B> OR <STRONG> OR ALL UPPERCASE. IT MAKES YOU FEEL LIKE YOU ARE BEING SHOUTED AT, DOESN'T IT?
See also Appendix VI.
Do use header tags (<H1>, <H2>, etc.) to define the structure of your document so that the browser can display it appropriately, but avoid header levels 5 and 6, because many browsers display them with a type face that is smaller than the standard size, and is therefore difficult to read.
Do use list structures whenever sensible, and nest lists within lists when appropriate (creating an outline-style format). Feel free to put <BR> or <P> tags within or between list items to force extra white space.
Using lists for a set of links, rather than embedding them in a paragraph, has the advantage that Lynx users will be encouraged to use the down arrow key to get from one item to the next, the correct method. If the items are in a paragraph, a Lynx user might type, for example, the right arrow, which will take them into the current link, rather than moving over to the next link. The list format therefore helps to avoid frustrating your reader!
If using a <UL> list structure for a set of links, be sure to force extra white space between lines, so that there is dead-space between the links. You can do that with <BR> or <P> tags; another approach is to have each link end with code such as the following:
... </A><FONT SIZE="+2"> </FONT>
or start with code such as the following:
<FONT SIZE="+2"> </FONT><A HREF= ...
This approach has the advantage of using less space between items, so that more items will be visible at any one time without scrolling.
When using a Definition List structure, some browsers will complain if there is a <P> tag between the <DT> and the <DD>, but the same visual effect will be achieved by placing the <P> immediately after the <DD>.
Be very careful using tables. They provide control over the placement of items on your page, and look really nice in graphical browsers for those users whose screen size is comparable to yours, but they often create displays that are utterly confusing in Lynx, present major challenges to speaking browsers, and force users of hand-held devices to scroll back and forth and up and down. Cascading Style Sheets ("CSS") appear to promise an alternative approach that will be more robust. Remember that Lynx displays at most 80 characters on a line. You may find by experiment that a particular table arrangement does work acceptably in Lynx and nicely in graphical browsers.
Any "Go Back" or "Return" link should include or be adjacent to visible text that says where it will take you back to! (You don't know what link or bookmark your reader actually followed to get there.)
A single "larger" graphic, or a pair of them side-by-side is appropriate as a "masthead" at the top of the first screenful of a home page, or, for official pages, immediately below the standard university header. For content-rich pages, such a masthead should be at most 672 pixels wide and at most 200 pixels high (preferably less than 130 pixels high). The limitation on width is in order to be able to see the entire graphic in the window, even for users with small screens, and in order to be able to print the page in portrait mode (as opposed to landscape mode) with any browser, printer, and platform. Home pages and other navigation-intensive pages, on the other hand, being less likely to be printed, can reasonably be wider -- up to perhaps 760 pixels. The limitation on height is to ensure that some meaningful content, such as the shortcut links (Visual Issue 18), will be visible on the first screen of the page, even for those using small displays. If a pair of graphics is used, then for official pages, the one on the left should be the University logo, unless the logo is already at the top left, and the logo should be linked to the Front Door.
A set of terse text links near the top, such as can be found in the upper-left segment of this page, or the alphabet across the top of the Administrative Offices home page.
If you use this approach, your readers will appreciate the extra space, which makes mouse pointing seem less challenging, if you use a <P> tag between lines, and increase the separation between items on each line by using (which forces two non-breaking spaces).
A set of terse text links near the top, positioned by using TABLE tags, with a Definition List inside each data cell of the table to format the short explanatory text, such as can be found on the Policy home page. This approach works quite well when viewed in Lynx.
A set of small graphic buttons near the top, such as can be found on the Athens Campus map and tour building pages, such as http://www.ohio.edu/athens/bldgs/arc.html.
In each of these, the link from the text or graphic is directly to the location of interest: they do not function as a table of contents for the page they are on.
For your home page, consider providing a more detailed explanation of what will be found on the pages linked by the primary links. One method is illustrated by the second of the three pages linked above. Another method is to use a <DL> list structure for the whole page, instead of within each data cell of a table, with the <DT> items also being tagged as headers of the appropriate level (typically 2, 3, or 4) and being links. Be careful about the correct nesting of your tags! For example:
<DT CLASS="H2"><A HREF="alpha.html">Alphabetical Index</A>
<P>Links to pages, sorted alphabetically by page title.</P>
In order for this to work gracefully, the first line of your HTML file should be:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
and the HEAD section should include the following two lines, specifying an appropriate CSS file that defines the "H2" (or H3 or H4) class to have a suitably large and bold face:
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" >
<link rel="stylesheet" type="text/css" media="all" href="subsite.css">
The <DT> items in the main body of the home page may be adorned with a thumbnail graphic.
If so, please be consistent in locating the <IMG> tag either inside of or outside of the <A HREF= ...> tag that defines the link, with a space character or a non-breaking-space code between the <IMG> tag and the first character of the link text. See Technical Issue 10.
For quickest loading, use the same thumbnail graphic for each item.
For variety, you may choose different thumbnail graphics for each item, but make sure that
They are all the same size, so that the several headers line up with each other.
That size is reasonably small. Remember that the size of the graphic file, and therefore the time required to download it from the server, depends on the product of its height and width: a 50 x 50-pixel graphic requires four times as much space as a 25 x 25-pixel graphic. Do not make the thumbnail so small that no interesting features can be seen when viewed on-screen.
Include HEIGHT and WIDTH attributes inside the <IMG> tag, so that modern graphical browsers can complete the layout and display of the text without waiting for the image itself to be completely downloaded.
Keep in mind that pages with more than a half-dozen different graphics will load more and more slowly as the number of distinct graphics increases.
Your users will perceive a sense of continuity in your design, and the server and network loads will be reduced, if you can re-use those thumbnails, either on the page for whose link they appear in the home page, or at other places in your pages where you have a link to that page.
An image that is located within an ordinary HREF anchor tag can be clicked to follow the link, but you follow that same link no matter where within the image your mouse pointer was when you clicked the button. An image map is a single image that provides multiple links: the result of clicking in the image depends on the precise location of the mouse pointer at the time it was clicked.
Some servers support image maps by using CGI scripts ("server-side imagemaps"), with resulting restrictions on the location of one or more of the component files. The web server software on people2 and on ww2 supports only browser-side imagemaps: all of the geometric and destination data is included in the HTML file, so that the browser knows where to go as soon as the mouse is clicked.
The procedure for preparing the required files is straightforward, but several parts of it can be tedious. It is discussed in detail in Appendix III.
On the CommonSpot Front Door, you can also control access to your pages based on Ohio ID. For details, see the CommonSpot Advanced Pagemasters discussion.
On ww2 (and wws2, of course), you can also control the access to your Web pages based on Ohio ID. There are two requirements: that the server configurations be correctly adjusted, and that you create and maintain a text file with the required information. Very similar methods work on people2 for personal web pages, as documented separately for that server. For ww2 and wws2, please follow these steps:
Send an e-mail to email@example.com, identifying the subsite or sub-subsite that is to be password-protected.
When the servers (and the load balancer) have been re-configured accordingly, you will be notified by e-mail.
Login with SFTP to wws2, and upload into the subsite or sub-subsite a home page (e.g., index.html) and a text file named "ht.access" that has the appropriate content (see example and discussion, below).
Attempt to access the home page at https://wws2.ohio.edu/subsite/ — and observe that you are challenged for your Ohio ID and password.
Give your own personal Ohio ID and password. If your ht.access file grants you access, then you will see the page; if not, then you will be re-challenged.
Repeat the above three steps with ww2 if your subsite is already in production.
Upload your real home page and all other files for that subsite. If this is the initial migration, upload them to wws2; if you are already in production you may choose to use wws2 as a staging server, again, or you may choose to upload the files directly to ww2.
As the list of people who should have access to the pages changes, revise the ht.access file and upload it to ww2 and to wws2.
There are three ways you can specify who has access:
everyone who has an Ohio ID and password (this is approximately 225,000 people, including all prospective students who have formally applied for admission, but does not include any search engines);
those who are on a list of specific Ohio IDs; or
anyone who is in an "Active Directory group" maintained by OIT (e.g., the group of people who are authorized to update your subsite). We can, and sometimes do, specify that one of the members of an OIT-maintained group is an AD group maintained by your department, but such nested group membership will not work for browsing access control, even though it does work for authoring access control.
If you use more than one of the three, the server will combine them with a logical "OR": a person need only match any one (or more) of the specifications to get access.
If you want to grant access to a large group of people, so large that maintaining the list manually would be a significant burden, please contact us by e-mail to firstname.lastname@example.org, and describe the group you are thinking of. Perhaps OIT will already have that group in place, or be planning to maintain it for other uses, either manually or automatically.
The server will ignore any lines in your ht.access file that start with pound signs ("#"), which permits you to leave comments in the file that will jog your memory or assist the next person who inherits responsibility for that subsite. Generic comment lines should be removed from the ht.access files that you use, in order to reduce server overhead parsing through them: the ht.access file is read and parsed for each access to any resource in the subsite and all contained sub-subsites. That said, we do urge that you keep comment lines that will be helpful to you or your successor!
You may want to copy and paste the text below, or you may just type in the parts you want to use. We do recommend that you include the group specification for the subsite pagemasters for your subsite. They can all see the files anyway, by SFTP, but this will let them inspect the files immediately after uploading, to make sure that they are displaying properly.
BEWARE: some browsers will truncate the longer lines in the following model ht.access file, but will provide a horizontal-scroll control after the last line:
#This is a model ht.access file
# To permit everyone with author access to the subsite to see the pages in the subsite,
# uncomment the following line and replace the "subsite" (highlighted red) inside the cn
# value with the actual name of your subsite, in all-lowercase letters:
# Require ldap-group cn=OIT-WEBSVC-subsite-admin,ou=WEBSVC,ou=OIT-AIS,ou=OIT,ou=Ohio,dc=ohio,dc=edu
# To permit everyone with a valid Ohio ID and password to view the pages
# in this subsite, and no one else to see them, uncomment the following line:
# Require valid-user
# To permit specific individuals, and no one else, to view the pages
# in this subsite, uncomment and include one or more lines of the form:
# Require ldap-user user1 user2 user3
# To permit only a specific individual to see a particular file, uncomment and
# include blocks of the following sort:
# <Files "filename.html"> # Require ldap-user user1
# the "ldap-" may be omitted;
# replace each "userN" above with the appropriate Ohio ID;
# multiple users and multiple lines of this form are combined with a logical OR
It is safe to place the ht.access file in the same folder on the server with your published documents, because the web server is configured to refuse to serve any file whose name ends with ".access".
The URL path specification is directly translated from the location and name of the file on the server: for example, a file named "index.html" that is located in the folder named "athens" that is in the folder for the entire site (named "ww2.ohio.edu" on the production server's E: drive, and named "wws2.ohio.edu" on the staging server's E: drive), has the URL
on the staging server, and will be seen by the world at
when it is in production. You use the standard URL punctuation of a "/" to separate subdirectories in a path, instead of the Windows notation of back-slash ("\") separators or the old MacOS notation of colon (":") separators. For another example, the file on the production server named "columbus.html" that is located in the travel folder inside that athens folder, has the Windows file specification:
and has the URL
If a URL specifies a subdirectory, but has no filename, the ww2 web server is configured at this time to search that subdirectory for the following files, displaying the first one on the list that it finds:
If the server doesn't find any of those default files, it will create an index on its own, listing the files it does find.
The last three default files in the list above are included for the time being to assist subsites that are migrating from the old VMS Front Door server, where all four worked. We have not yet decided whether or not to continue indefinitely to include them in the list of possible default filenames. If we decide to remove the last two or the last three from the configured list, we will update this page and we will inform all ww2 pagemasters by e-mail of the planned change's effective date. If you are building a new subsite, or a new sub-subsite within an existing subsite, please use only "index.html" as your default page.
As a result of the default file processing, the following two URLs function identically:
This feature of the server simplifies the typing that your users have to do when they open the link explicitly, and reduces the typing you have to do whenever you specify a backlink to the home page of any subdirectory, provided that you use one of the default filenames listed above as the filename of each directory's home page. Although many browsers do not need the terminal slash ("/") on such a URL, some do, so it is best to include it.
As mentioned above, using relative paths for links will reduce your typing now and will make it easier to migrate your web files to another server in the future if you should decide to do so. Relative path names are a standard feature of HTML (see, for example, pages 27-28 of Aronson, 1994; pages 79-82 of Lemay, 1995; pages 167-168 of Graham, 1995). Let us consider some examples based on the files and folders shown in the following illustration:
Working down from the top, those files would have the following absolute URLs, when seen from the production server:
The simplest case occurs with two files in the same ("parent") folder; in that case (a link between "siblings"), the relative URL is just the name of the other file; for example, a link leading from the second page to the third in the above list could be specified as:
<A HREF="columbus.html">Getting here from Columbus</A>
When the target file is in a folder that is in the same folder as HTML file, the folder name is given first, followed by a slash, and then the filename; for example, a link leading from the first page to the third in the above list could be specified as:
<A HREF="travel/columbus.html">Getting here from Columbus</A>
To link to a file in an outer folder, the relative URL starts with "../"; if the target file is two layers out, then the relative URL starts with "../../"; and so on; for example, a link from the fourth page to the first on the list above could be specified as:
<A HREF="../index.html">Map and Tour Home Page</A>
A more complex situation occurs when we build a relative specification from one page to a "cousin" page; for example, a link from the third page to the fourth on the list above could be specified as:
<A HREF="../parking/index.html">Parking When You Get to Athens</A>
All of the above examples illustrate specifications that are relative to the page containing the HTML in question. There is another usage of the term, "relative URL," that you will sometimes encounter: that is a URL that starts with a slash character ("/"). Such URLs are relative to the server on which the page containing the HTML in question is located.
Further commentary and examples may be found in the discussion of Anchor Tags in the HTML I Class materials.