TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
<I have been assigned the task of creating an intranet site for our development team. . . . The users of the site will be our team members as well as a business team - a group of people who will benefit from our project. . . .
I am trying to get some direction and figure out the scope for this site. . . I will be using FrontPage 2000.>
The team I am part of has recently finished an Intranet site for the project we are working on. Our audience is primarily the business users, but we also have an area for the developers. The best advice I can give you is to plan, plan, plan. We reworked pages so often that some pages have been recreated 5 and 6 times. Others, which we spent lots of hours to create, were found to be unsuitable for the site. The steps I recommend:
1. Decide on what information each audience needs? For example: technical specifications, implementation phases, overview of the system, history of the project, help, frequently asked questions, etc.
2. Decide on a style for your pages. Use cascading style sheets if necessary.
3. Storyboard your pages. Get content approval on the storyboards. It is much easier to change the storyboards than the web pages.
4. Have one person control the web development and the changes to each page. This can be a nightmare if you have more than one person developing the site.
5. If a high level manager is keen about some web function he or she has seen in the past, put it in the site. One manager liked the animated way MSWord demonstrates how to do things. We added an .avi file that demos the login process. It was a feather in our hats!
6. Establish a completion date. Whatever can't get done by that time moves into the second release of the site. It is very easy to always find something more that should be added or changed. This way, the site gets published.
7. Finally, test your links, test your links, test your links, test your link, etc. When you think they are all OK, test them one more time!
We had a lot of fun putting together our site and learned a lot from our mistakes. Our team is ready for the next web project which will be better than our last!!
