Establishing a Chain of Command and Developing Site Guidelines in HTML Creating Commercial Websites

Establishing a Chain of Command and Developing Site Guidelines in HTML Creating Commercial Websites, 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.

Developing Site Guidelines

 

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:

  • WWW mission statement (the overall goals and objectives of the site)
  • HTML formatting standards (what code to use, and what not to use)
  • Navigation standards (maps, links, cross-referencing, and so on)
  • Information standards (how to place text, tables, and so on)
  • Layout standards (headers, footers, graphic placement, and so on)
  • Size (no pages larger than ??bytes)
  • Graphic standards (formats, sizes, color palettes, and so on)

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.

Leave a Reply

Your email address will not be published. Required fields are marked *