Damage Control

Mistakes will be made. The more people are involved in the development process, the more mistakes will be made. As mentioned earlier, it is never a question of if you will have problems; it is a question of what you will do when you have problems.

Effective damage control comes from a gentle balance of preventing mistakes, undoing mistakes, backing up the project on a regular basis, and, if possible, using some form of version control.

Preventing Mistakes

You can help prevent mistakes in a collaborative environment in many ways. These ways can be summed up as making effective use of the tools provided and working with intelligent people during the process.

The most common mistake made in collaborative Web design is a user editing or deleting a file he shouldn't have. This stems from a variety of problems, which include an improper understanding of what files and tasks are assigned to him and making simple mistakes. The remedy is preventing the user from being able to edit or delete the wrong file in the first place. This can be controlled somewhat through the use of the FrontPage document check in and check out process. Figure 33.10 shows the warning that FrontPage shows when someone attempts to modify a locked file.

Figure 33.10. A document that has been checked out quickly prevents an unauthorized user from modifying or deleting the file.

For more information on the document check in and check out process, see "Collaboration with FrontPage 2003," p. 615.

Another way to help prevent mistakes is to assign every document in the Web site to a specific user. Then you must ensure that users pay attention to the assignments and react accordingly.

You can also use the FrontPage 2003 security options. By making certain directories available to certain groups or users, unauthorized access is not permitted and mistakes are less likely to be made.

NOTE

The security options are maintained through FrontPage 2003, but require FrontPage Server Extensions on the server side to maintain. If you are working on a Web server without FrontPage Extensions, you will need to maintain the security and access issues through whatever means are required by your server.

Nothing prevents you from creating as many directories on your site as you want. Consider placing each user's work in his own folder so that he deals only with (and has the potential to damage) a small area of the Web site. Set the security permissions for each folder so that only the people responsible for the content are able to change/edit/create it.

Backing Up the Web

Backing up anything on a regular basis is always a good idea. Disk drives are prone to failure, and the constant accessing of files typical to a Web server puts a lot of strain on any drive.

Back up both your production and launch servers on a regular basis. Removable media that can be stored somewhere else. CD-ROM or tape drives, for example, provide ideal archiving capabilities.

TIP

Consider maintaining an archive of backups for your Web site. If you make your backups on the same media, you will have only the most recent backup to return to. Many times, a mistake made on a site isn't realized until a significant amount of time has passed. Without a series of different backups, you will be unable to get a backup as close to the mistake as possible.

Integrating with SourceSafe

Microsoft Visual SourceSafe is one way to provide version control and change management for your site. Version control is the practice of making an actual copy of every change made to a project; that enables any problems noticed in the future to be fixed. SourceSafe automates the entire process on any server on which it is running.

If you perform collaborative work in Visual SourceSafe, all changes made at any time to the site are recorded in an exhaustive database. If a mistake is realized anywhere in the process, the exact change can be tracked and the correct modifications made.

More information about Visual SourceSafe can be found online at http://sourcesafe.frontpagelink.com.

Working with Sharp People

The ease with which anyone can approach Web design is often confused with the idea that anyone should be allowed to do it. The skill set required to make a Web page is small.

It is also sometimes difficult for people to begin working together as a virtual team. Put those people in a room together, and they can accomplish almost any task. Place that same group in front of computers, and they are unable to perform because they're part of a group they can't see. Virtual teaming is hard for some people.

Collaborative teams are special groups of people. They must understand the need to be self-starters, realize their positions in a larger picture, and know how to work in a team environment in which they might never see the face of anyone with whom they are working.

Hiring a good team to produce your product is as important as any technology or platform decision you will ever make. People who are unable to take on the challenge often make mistakes that can have a disastrous effect on the entire group.

Troubleshooting a Team-Based Web Site

How do you troubleshoot a site that you haven't developed?

Troubleshooting on a team-based site is much more difficult than on one you developed yourself. Not only are there mistakes that might have been made, but also you might not be aware of them because you weren't part of their creation. Fixing a problem you didn't create, or know nothing about, is difficult.

In short, before you can effectively troubleshoot a team-based site, you first must view the thing before you can identify the problems to fix. This means every single page, like it or not. The role of the manager is to know the entire site so that troubleshooting it is possible.

If you are unable to view every page in the site, a few tools can help you with some of the biggest potential problems.

Viewing the site-wide reports discussed in the last chapter can provide a great snapshot of potential problems. This suite of reports points in the direction of many of the biggest problems with a site. If you are unable to review a site completely, at least run all the reports to identify the biggest problems.