|
|
System maintenance is a rather broad subject. A simple system may require little maintenance, whereas maintenance on a large, multiple-author system can be a full-time job. Whether it takes you 5 minutes per week or 50 hours, there are steps you can
take to help facilitate effective system maintenance and time management.
Your primary goal will obviously be to keep the site's links current and make sure that no files have become corrupt. While there are specific software programs that can help with this (InContext WebAnalyzer, for instance), you can also simply go
through the system on a weekly basis to make sure everything's running and loading correctly.
The fact that "nothing should go wrong" is little help when something does go wrong. So, even if you're contracting out everything—including the HTML design, site administration, and the whole ball of wax—check
your system regularly.
After you've got your site up and running, and have come to understand the concessions you've made, you will be in a better position to reassess the long-range goals of your site, based on your original ideas and the obstacles you've found along the
way. This reassessment will continue as you see what works and what doesn't, and should never really be set in stone, but can act as a benchmark of sorts as your system continues to evolve. Some of the key issues you will want to address are
For example, you might say that the communications objective of a site is to create public awareness; that the look and feel will incorporate a certain page layout, color scheme, and text treatment; that you won't create pages over 50K for bandwidth
considerations; and that you will include a site-wide navigation bar on all pages.
Now, this won't mean that you will have to restrict your creativity to meet these standards, but that you will have something to go off of as you assess new additions to your site. If you are the only author for a system, you can keep these standards
in your head. If, however, there will be several sources providing pages, guidelines and standards will become necessary.
Marketing wants to post a product demo, sales wants to be able to update prices weekly, customer service wants an ongoing FAQ (Frequently Asked Questions) page, technical support wants to post updated diagrams, and the CIO wants everything to mesh
seamlessly. What a nightmare!
If you are the webmaster for a large corporate site, you may find it beyond your ability to meet everyone's needs yourself. Or, if you are heading a design team, you may need a way to guide all of the different designers. Either way, managing multiple
authors requires some special considerations, and there are some things you can do up front to make life a whole lot easier for everyone.
Your first goal in designing or implementing a multiple author site is to achieve continuity. You don't want your site to look piecemeal, even though it is. Viewers should be able to navigate through the site easily, using the same navigation tools
throughout. They should be able to know that the information they're looking for will be available in a certain format, and that charts, links, and tools will be laid out in some standard. Most importantly, someone should be able to access your site at any
point and know that they're on your site.
This requires that you set standards of authoring that specify exactly how a page will be laid out. This may sound like your site is going to lose some of its pizzazz, since you are trying to make each page look like the rest, but don't worry about it.
The point is not to make your site generic, but to make each page work within the structure. You can set whatever standards you want, as long as those standards can and will be met by each page on the system.
When you start getting into sites with hundreds or even thousands of pages, the concept of individual creativity starts to lose its appeal. Your focus should be on making the entire site an effective communications tool—not to make each page
sizzle. In short, don't lose sight of the forest for the trees. Now, to keep control of that big picture, you will need to set up some kind of authoring pecking order.
Your first step in managing multiple authors is to set up some sort of managerial system. The reason for this is simple: you don't want just anyone accessing your WWW directories. Early on, many large site webmasters gave authoring privileges to
anybody who wanted them. Not many people knew or wanted to deal with HTML, and page ownership wasn't an important issue.
It wasn't long before some of the largest systems on the Net began suffering from too many cooks spoiling the broth. One person wanted to set up their pages one way, someone else another. WYSIWYG editors and HTML converters screwed things up even
further by making pages with sloppy code, self-serving <META> tags, improper formatting, and the like. Pretty soon, webmasters began pulling the plug on open access.
As it now stands, most if not all large systems have a structure set up for document submission, testing, and page ownership. While security is obviously a factor, the main reason for this type of protocol is to keep people from submitting mistakes and
to make those who do responsible. If you are working with multiple authors, you too will want to implement a protocol of this type.
You will probably want to have no more than one approved author for each department. While others can work on the HTML, only the author will have the clearance to post. You can password protect the upload directories on the server to enable you to
track access, and thereby give ownership to each file. It's also a good idea to separate the directories for each author (for example, /sales, /custserv, /product1, /product2) so as to allow for even better control—keeping the root directories for
yourself.
Be warned—you are likely to face some opposition. However, no matter how much of a pain it might be to set up some sort of chain of command, it will never compare to the problem of having 20 different people screwing around with your system,
updating links, deleting each other's pages and the like.
As was mentioned in "Keeping on Track," establishing guidelines for a site not only helps to keep things in control, but it allows a site to evolve more effectively. Now, a few simple rules may assist you in working on a small or
single-author site, but for a large commercial site, detailed guidelines will be a necessity.
If your company has an intranet, your first option is to set up an internal site that gives precise guidelines on content, formatting, colors, acceptable sizes, procedures, and even hints. You can also use an intranet to set up a mirror site. This site
can have the exact same structure and content as your public Web site, and can act as a testing area for new pages (better to find a bad link before it goes public).
If you don't have the luxury of an intranet, you may have to produce some kind of printed or electronic manual to act as a reference. Regardless of the medium, your site guidelines should include:
Each of these topics should be addressed in detail, with examples and hints where necessary. As you can probably imagine, this manual can get pretty lengthy. You also have probably come to understand that there may be several ways to use HTML code to
achieve the same effect in many instances. So, in an effort to keep things as simple as possible, and to assure the best success of a multi-user site, you may want to rely on templates.
With templates, you can give your authors a starting point, but you stay in control of the major issues. Furthermore, by having standardized HTML code across all pages, you can easily make sweeping changes to the entire system without changing each
page's code. You can also use robots to search/replace code across standardized files, to implement even more drastic changes on a site.
First things first—you'll need to nail down a format for each page, as well as a root directory structure. Once this has been accomplished, you can begin structuring your templates. For the purpose of example, we'll make a basic master template.
Let's suppose that we want a master graphic, a standard page background, a navigation map, a standard title and headline scheme, a main supporting graphic placement scheme, and a standard copyright and mail footer. Our objective is to make a
fill-in-the-blanks type of template. Here's the code:
<HTML> <HEAD><TITLE> +++++++++ENTER TITLE HERE </TITLE></HEAD> <!-- begin Standard Header—do not alter or remove --> <BODY BGCOLOR="#FFFFFF"> <A HREF="/main/main.map"> <IMG SRC="/main/header.gif" BORDER=0 ISMAP ALT="[XYZ navigation]"></A> <!-- end Standard Header --> <H1><CENTER> +++++++++ENTER PAGE HEADLINE HERE </CENTER></H1> <BR><HR> <!-- insert main graphic between quotes below --> <IMG SRC="graphic.gif" ALIGN=RIGHT> +++++++++ENTER CONTENT TEXT HERE <!--begin standard footer—do not alter or remove below this line --> <P> <HR> © Copyright 1996, the<A HREF="mailto:cs@xyz.com"> XYZ Corporation</A>, all rights reserved. </BODY> </HTML>
You'll notice that the code here is pretty straightforward, and that we've used carriage breaks to help set the editable areas apart from the standard areas. We've also used comment tags to give instructions and warnings. The resulting page would look
like Figure 25.1.
Figure 25.1. Our template viewed through a browser.
You'll notice that this is a case where we didn't specify the size of the header graphic, and that we used an externally referenced map. This is so that we can replace this header with whatever we choose, without having to change the code. This is one
of the nicest features of using standardized templates (or standardized components); you can make system-wide changes immediately.
Seasoned HTML authors would be able to pick up on the structure of this template and could build very extensive pages based on this simple design, while preserving the basic, system-wide elements. HTML novices, on the other hand, can see this as a
paint-by-numbers project—place the graphic here, type the title there, lay in the text, add a few formatting commands, and voila!
Obviously, people using WYSIWYG HTML editors will never see the comment tags and can very easily do something to compromise the code. While you can possibly go over each individual's software application and make sure that it is customized to work
within your code structure, who wants the hassle? Our philosophy on this subject is simple: If you can't write pages in a text editor, you aren't an HTML designer, and you shouldn't be working on a commercial site.
Where to go from here is up to you. You can make a master template, or you can make individual templates for each type of page you foresee on the system (like product info sheets, ordering forms, section pages). What you choose to do will depend on the
system, its goals, and whom you're working with.
Even if you're the only author, you might find templates a great tool—especially for crash-and-burn projects, where something needs to be posted within a matter of hours. You might, for instance, make a press release template, as shown in Figure
25.2.
Figure 25.2. A template for press releases.
Using a template like this, you could convert a press release to HTML in a matter of minutes. The point is that a standard template will help keep you and others on track and will give you a good start on page production. They are great tools that you
won't want to do without.
No matter how thorough you try to be, using guidelines, templates, threats and the like, someone is going to mess things up. Whether it's accidental, or the result of someone getting a wild, creative hair, your code and standards will become
compromised. Because of this, you will need to check your pages.
There are ways you can make programs to automatically check for specific components. You can even simply run a search for text strings that match your template header, for instance. The truth of the matter, however, is that there's no substitute for
just opening the file and taking a couple of minutes to check the format.
Don't be a hard-nose. Remember that your site should continue to evolve, and it's easy to get in the habit of the lazy manager who won't accept anything that's the slightest bit out of the norm. Other authors may have some great ideas that won't
detract from the overall system, even though they stray from a template.
There may also come a time where the template(s) won't work with some feature of a page (like a standard header in a channel-background page), and you may need to help set up an alternative. You'll need to carefully track these aberrations so you can
change them individually as the system changes, and the more there are, the more difficult it can be to make changes.
Let's suppose that you've developed a 50-page system with multiple authors. Let's also suppose that you've used templates, standard navigation headers, strict guidelines, and the like. You've taken care to assure the broadest compatibility of your
system, and the simplest system-wide editing. Now, you have an entirely new plan for the system's front end, and you want to change all of the supporting pages to match.
If your new scheme will stray only very slightly from the current system, you can probably make some universal changes without many problems. For instance, if you are just replacing the navigation header in the previous example, you may run into no
problems at all. If, however, you are making drastic changes, you may run into some tremendous problems.
We'll make an example of a page designed on the earlier template. Let's suppose that one of your authors got a little creative and wanted to use a drop-cap effect (see Figure 25.3) with a little text graphic.
Figure 25.3. A drop-cap effect before changes.
Now, this page is still very simple, and hardly deviates from the standard template. But we want to make system-wide changes that will affect this and every other page. To make these changes, we'll be using a new main header image (and corresponding
map), and we're going to change the background and text colors. To accomplish this, we are simply going to change the header section of each page from this:
<!-- begin Standard Header—do not alter or remove --> <BODY BGCOLOR="#FFFFFF"> <A HREF="/main/main.map"> <IMG SRC="/main/header.gif" BORDER=0 ISMAP ALT="[XYZ navigation]"></A> <!-- end Standard Header -->
to this:
<!-- begin Standard Header—do not alter or remove --> <BODY BGCOLOR="#000000" TEXT="#FFFFFF" LINK="#00FFFF"> <CENTER><A HREF="/main/main.map"> <IMG SRC="/main/header.gif" BORDER=0 ISMAP ALT="[XYZ navigation]"></A></CENTER> <!-- end Standard Header -->
This can be done manually, by search and replace, or can be accomplished with a spider (robot) automatically. Either way, this should be fairly simple, right? Well, as you can see in Figure 25.4, even the smallest, least noticeable things can cause
problems.
You'll notice that the drop-cap now just looks like a blob. Had it not been antialiased, it wouldn't show up at all. Oops! Now, had we tried to do a more subtle change, like using a light-colored background, for instance, this problem would not have
been as noticeable.
This is a very simple example. Just imagine what it would be like if many authors had relied on a white background/black text design for their graphics, table backgrounds, and so on. Many graphics and even entire pages might need to be redesigned.
Since the nature of HTML requires designers to use creative tricks (like using a transparent GIF to create a drop-cap), design elements may depend on the overall page layout. Drastically changing the page layout can and will have adverse effects on
these "tricks," and will therefore affect the system as a whole.
So, regardless of how well you set guidelines and stick to templates, making major changes to your system will require that you and your team go over everything at least twice. First, you will need to try and anticipate problems, so that you can make
changes in either the pages or your revision plans. Second, you will need to go over the pages after the revision, to find the trouble spots you missed earlier (and you will miss some).
As a rule, the more sweeping and profound the change, the more problems you'll run into.
In this chapter, we've addressed some of the techniques that can help to control the expansion and evolution of a site—especially a site with multiple authors. We've also discussed problems associated with the implementation of sweeping changes on
a large system, and ways to avoid some of these problems. Our main goals have been to
In the next chapter, we discuss some of the ways to market your newly acquired Web skills.
