-
-
- Because Web page HTML files are just ASCII (text) files, you can create and revise them with any word processor or text editor, including SimpleText on the Macintosh or Notepad on Windows. This has the profound advantage of permitting you to learn HTML without forcing you to learn a new fancy HTML-editor software package at the same time.
- As soon as you have saved your work to disk, you can examine the results by using Netscape or Microsoft Internet Explorer: both have an "Open File..." choice on their File menu. If you have used the correct format for your cross-references within your HTML anchor and image tags, then you will be able to preview and test your entire collection of pages directly from your disk drive, in total privacy, without showing them to anyone else.
- When you first are building your department home page, the question that must be answered is, "Is this draft better than having nothing?" Bear in mind that initially the correct answer to that question will be "NO!" As soon as the answer is "Yes!" you should upload the current version to the server and let people know that it is ready to be listed on the University Home Page.
- As you continue to work on your page, the question to ask is, "Is this version better than the version on the server?" Again, often the answer to that question will be "No." Whenever it is "Yes," you should upload the improved version to the server.
When you are working on an official page, be very certain that you know who has the authority to answer these questions!
You and your supervisor should develop a clear understanding as to the nature of modifications you should make and upload immediately without seeking approval (to correct spelling and punctuation errors, for example) and what kinds of modifications require formal approval in advance.
- Once you are satisfied with the current cycle of revisions, you upload all new and modified files from your disk drive to the Web server, placing them in the folders that correspond to the folders they occupy on your disk.
- It is possible for files to be corrupted during the upload process, either through program bugs or operational mistakes. Therefore, you should immediately examine each of the files, to verify that it has been correctly transferred. Corruptions are likely to be quite visible, so just scroll right down through each page, scanning to make sure that the embedded graphics are displayed correctly. Sometimes, when uploading files with some software to some servers, only the first 95% of a file will transfer, so be careful to check the very end of each file for completeness.
- Depending on the nature of the changes you have made, you may well want to login to a system that runs LYNX, so as to verify the appearance of your pages when viewed by people using that browser.
- If this is to be the first public version of your pages, there will be no links in place yet pointing people to those files, so your next step is to tell all of the people who should review the pages, so that they can examine them from the server. You will need to tell them the URL, so that they can open that location.
- Once they have reviewed the pages, and any necessary changes have been made and uploaded, you will need to inform the people who are responsible for updating the various pages onto which links to your new pages should be added. You will also need to decide whether any further publicity effort is appropriate.
- If these are revisions of pages that are already public, you will need to consider the nature of the revisions and decide whether it is appropriate to simply upload them in place, or whether to upload them to a special test folder, and have other people review them before uploading them to their final destinations.
-
- I cannot emphasize enough the importance of a good layout and design for
keeping interest in your web pages. If you want to create web pages for
your department or office, the best thing to do is to talk it over with
the people you will be representing.
A solid, well designed web page is the ultimate first impression. Hundreds
of thousands of people all around the world will see your page.
Your page will not only reflect upon yourself and your department, but also
on your institution as a whole.
The long-term effort will be less if you invest some time in planning your web pages in advance, tempting though it may be to just jump right in and start writing.
There are five stages to your planning effort, all of which are paper and pencil tasks:
- Storyboard each document: What will appear on the page? How should it be organized? What types of information do you want to make available? How much information do you want to include?
These can be difficult decisions. Many departments and offices have a plethora of information just aching to be put on the web. Many departments have brochures and advertisements that would lend themselves perfectly to the web. It can be a difficult job sorting through all of the available materials and choosing what should go on the Web, and what should not. Making the decisions as to what should be changed, what can be enhanced, what can be directly copied, etc., can take a long time.
- Separate your project into the individual pages. Since people will have to follow links between those pages, and wait for them to load, this separation is a significant design choice.
- Decide on the basic link structure: What will be connected to what? From where?
You don't need to include all the links that will seem appropriate as the project progresses, but you should plan out the links that define the overall organization of the pages, and which, therefore, provide people with the feeling that they know where they are going as they navigate through your pages.
For example, the fundamental structure of this set of pages is what I refer to as the "wagon wheel": the Roadmap functions as the hub, with the spokes being the links from it to the several pages and from each of them the "CONTENTS" link back to the Roadmap. The "BACK" and "NEXT" (circumferential) links correspond to the rim of the wheel.
- Decide how your files will be organized on disk: Will they all be in one subdirectory? Will the image files all be lumped together in their own subdirectory? If multiple directories will be used, what will they be called and which files will go in which directory?
- For large projects, identify phases that can be made public prior to overall completion. This is another way Web that publishing differs from hardcopy, where you don't want to pay for printing anything less than a perfect job. It is easy to enhance an existing page incrementally, especially if you have planned for that.
-
- Use filenames or folder names that are legal on all platforms. You will have to choose filenames that are legal on the personal computer you use to maintain your Web pages and on the server you use to publish them. Being careful to choose names that are legal on other platforms will give you the freedom to migrate to another environment in the future with minimal effort.
This is especially important for departmental or other organizational Web pages, where you should presume that someone else will eventually be responsible for maintaining the pages.
Following the rules of thumb, given below, for robust filename choices has the added advantage of producing URLs that are compact, and therefore easy to type when your reader is called upon to do that.
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 for 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 (on the Macintosh) or subdirectories (on the PC), but limit the depth of nesting of folders within folders within folders, etc. In particular, do not create more than six levels of subdirectories or folders for your web files.
- Give your files and subdirectories names that are "short" but understandable.
- Filenames and directory names must not include any space characters.
- The underscore character ("_") is legal, but it requires extra effort to type, and so should be avoided.
- Capital letters are also legal, but they require extra effort to type, and on some servers are not distinguished from lowercase letters, so use only numerals and lowercase letters. If you already have filenames and links between them that specify mixed case letters, you need not change them for use on case-insensitive servers, unless there are two files whose names differ only by the case of one or more letters.
- If you think there is any chance that responsibility for maintaining your files might be assigned to someone who uses Windows 3.1, keep the filenames DOS-legal: the part before the period being at most eight characters, the part after the period being at most three characters.
- Do not give your folders or subdirectories names that include periods, use only letters or numerals.
- File names may have at most one period ("."). Some web servers can tolerate more than one period, but many cannot. The filename's "type" or "extension," the part after the period, should be chosen conventionally (e.g, ".htm", ".jpg", or ".gif"), because the web server software uses 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 on some servers.
-
- 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 Netscape's File menu.
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 any shared collections of image files on the server. If your reader has recently seen any of the pages that use a shared image that you also 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.
Planning a web page depends a great deal on what you are trying to accomplish. There
is a diverse set of choices to be made, and anyone developing a web
presence must be aware of these choices. The easiest way to understand what
is, and what is not possible on the web, is by surfing it yourself. Just as good authors and poets are often voracious readers, anyone
who wants to make information available on the Web should be a frequent Web surfer.
-
- Two sub-teams should be created to maximize the likelihood of making your
web page top-notch. One team should be responsible for assembling or writing the content,
and one should be responsible for the HTML to format that content. By dividing the workload
this way, the team that is in charge of gathering the content can focus
on doing just that, and the other can focus on learning HTML and writing the
actual web page source. Both teams share responsibility for design.
The team responsible for writing the HTML should make it very clear to
the other team what is, and is not possible for them to do. Start simple,
things can always be enhanced later on. You will see many pages that have
"under construction" on them. I believe all web pages are
always under construction, so this statement is both trite and unnecessary, and should be avoided.
-
- Your team will not be able to do its best work in isolation. It is important that the members of the team seek advice from each other frequently, and that they seek advice from others nearly as often. There are few things so frustrating as realizing that you have just spent fifteen hours of your life polishing the details of a Web page whose basic design is not acceptable to your boss's boss!
As you receive feedback from others, their comments will fall naturally into three categories:
- Ideas whose brilliance is immediately evident. No debate is needed in order to decide how to respond to these suggestions.
- Ideas that you find immediately and compellingly repulsive. Be sure to ask why that suggestion was made. Often you will discover that your critic has correctly identified a shortcoming with your pages, even though you do not agree with his or her suggested solution.
- Ideas that seem to you to be about as good as your own. If that is the way they seem, they are probably better than your own ideas. You may choose to go with your original design, particularly to remain consistent with other work, but in general, you should take as many of the suggestions in this category as possible. You want to positively reinforce the time and effort expended by your critic in thoughtful examination of your page, because you will have other pages in the future that will benefit from such attention.
