As a new pagemaster you may be inheriting an existing site, or may be confronting the need to create a new site from scratch. Either way, you should resist the temptation to jump right in and put your fingers to keys and mouse. Instead, we urge you to start by thinking and planning, and only later move on to doing.
The exception to that advice would be if you have inherited an existing site that is outdated. In such a case, your first concern is to perform triage, deciding which, if any, outdated items should be removed (at least temporarily), which can be fixed by simple text changes, etc. That triage may well require consultation with others. You will have to learn the minimum basics about the existing site in order to make those changes, or recruit someone who already knows how to help you. Once you have done that, however, you should transition as smoothly as possible into long-term mode, with planning as your next step.
The overall total 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 starting writing. Keep the points discussed in the Web Page and Site Design section in mind throughout your planning.
There are four 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?
Separate your project into the individual pages. Since people will have to follow links between the 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. For example, the fundamental structure of this set of pages could be called the "wagon wheel": the table of contents functions as the hub, with the spokes being the links from it to the several pages and from each of them back to the topics list. The "back" and "next" (circumferential) links correspond to the rim of the wheel. The other common overall organization is sometimes called the "cascading star": the home page has a link to each of several intermediate layer navigational pages, and each of those navigational pages in turn has links to the content pages (you may find it helpful to think of this in terms of a Fourth of July fireworks).
Decide how your pages will be organized on the server: Will they all be in one subsite? Will they be grouped into multiple sub-subsites? If multiple sub-subsites will be used, what will they be called and which pages will go in which? Remember that sub-subsites are visible parts of the URLs of the pages.
Planning a Web page depends a great deal on what you are trying to accomplish. Because putting up Web pages for a department or office imposes additional requirements, we will bend the course towards this goal. There is still 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. Anyone who wants to make information available on the Web should be adept at retrieving it.
Once you are familiar with the Web in general, it is time to outline what types of information you want to make available and how much. 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 up, 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. This is all in addition to creating the pages themselves, which can also be time consuming. That is why we recommend working in teams of at least two people, if at all possible.
Two teams should be created to maximize the likelihood of making your Web page top-notch. One team should be responsible for the content, and one should be responsible for putting that content on the Web. 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 or CommonSpot and writing the actual Web pages. The two teams should collaborate on the design.
The team responsible for creating the Web pages 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. All Web pages are always under construction (or should be!), so this statement is unnecessary, and should be avoided.
Before you roll out your pages, let other people see them first. A lot of pages go straight from the "drawing board" in one person's mind, to implementation. All without anyone but the creator seeing it first. This is a bad idea. Put your ego on the shelf for a minute, go down the hall and ask someone, "Hey, what do you think of this?" Make sure your teammates get a chance to see the development and offer suggestions while you are creating the page. Nothing is worse than spending twenty hours constructing a page or set of pages, only to have everyone think what you have done is awful. Let people make suggestions while you are creating; it will make the whole process much easier, with the added benefit that your page will be better too. Nice, eh?
Have someone else read the text, too, and always run it through a spelling checker. It is sometimes a good idea to let someone else on the team do the spell check: it raises the odds that grammar mistakes will be corrected, too.
E-mail other people that you know have developed successful web pages. Send them the URL to your page in development and ask for their opinion; it couldn't hurt.
Make sure your boss sees the pages before they go live. If possible, hold meetings to show the pages to everyone in the department. Remember you will be representing them all, and you will be able to do a better job of that if you listen to them early and often.
Everyone just loves criticism. It's easy to do, and hard to accept. As a web page designer and creator, you will have to get very used to criticism from outside sources. People you have never met, who live in faraway places, will have no problem telling you exactly what they don't like about your pages. Sounds like fun, right? You can protect yourself somewhat by being critical of your own work, and letting people close to you do the same. Web pages evolve, they don't just pop up out of nowhere. Part of this evolution will come directly from the sometimes constructive, sometimes harsh, criticism of others.
When people provide criticism of your pages, you will likely find that their comments fall into one of three categories:
clearly correct critiques: will be easy to respond to, you just fix the problem.
bad ideas: you may immediately reject because they would, for instance, break a uniform design decision affecting multiple pages. In this case, it is often wise to ask the critic to describe the problem their suggestion was intended to fix. You may well discover that you agree with the diagnosis of the problem, even if you don't like their suggestion for how to fix it.
borderline suggestions: will present the most difficulty. Bear in mind that if you think it is borderline, their idea is probably better. Furthermore, even if you really think your idea is just as good, consider taking their suggestion anyway. The larger the fraction of their suggestions you take, the more likely they are to conclude that the effort of looking carefully at your pages was worthwhile, and therefore the more likely they are to look carefully and offer thoughtful suggestions the next time you ask.