Establishing a Workflow

A Web site is an entirely different entity from a traditional document (or any other traditionally linear work). Multiple items within a single document are linked at various locations, and the final product might be the result of many people, including (but not limited to) a graphic designer, copy editor, page layout director, and programmer. Because a change in any of the elements can have an immediate effect on the complete document, establishing a set of rules and project etiquette is necessary.

Blending the provided technology with a firm understanding of the project is the key to successful collaborative efforts. It might seem that because FrontPage 2003 provides such powerful collaboration tools, developing workflow would be easy as well. This is not the case. The workflow for any project might be many times more complicated than the development of the project itself.

Establishing workflow is a three-step process consisting of developing a site goal, designing the project flow, and assigning duties to the team in charge of the project. After these three things are complete, workflow has been established and the site development process is both well under way and on a path to success.

A number of computer programs are available on the market today that can help with the design and establishment of a project workflow. If you are looking for one, make sure that the program assumes multiple participants in the project, not a single user. Microsoft Project 2002 is one such powerful tool and can help in the workflow process. More information about Microsoft Project can be found online at http://project.frontpagelink.com.

Determining the Site Goal

All too often, technology gets in the way of the task at hand. The desire to jump right into a project, embracing the forgiving nature of Web design, is a powerful draw. It might seem obvious, but a very clear site goal should be developed and communicated to all team members before the site's first page is designed.

An effective Web site goal takes into account the user and platform base, aesthetic requirements, team assignments and responsibilities, and a growth and maintenance schedule. The Web site your team is building might be viewed on various platforms (different browser versions on different operating systems) and on various devices (handheld devices, WebTV-type machines, computers, and cell phones). This new presentation paradigm requires a level of attention that simple print projects have never required. The user and platform base is very important when working with a team. A technology restriction must be put into place if the site is to be viewed by users without the latest technology. Everyone must understand what to do with technology that might not be supported or understood by the user base. Questions to ask about the use of such technology include

• Should it be utilized at all?

• Should there be alternative pages for users without the technology?

• Should the site provide information for users on how to download and install the latest technology?

• Do you want to provide technical support to users who try to use the technology but are unable to do so on their own?

• Do potential viewing platforms, such as handheld devices or television set top browsers, have an effect on the technology that will be used?

For more on making sure that your FrontPage Web site can be accessed on as many browser types as possible, see "FrontPage's Accessibility Features," p. 235.

Aesthetic requirements are especially important when working with a team because all members must understand, and be able to reproduce, a specific look and feel for the entire site. Questions to be asked include the following:

• Will this be done with the use of FrontPage themes? CSS? Will Dynamic Web templates be used?

• Does your team understand how to design sites so that the sites can be effectively managed and updated by using any of these FrontPage technologies?

• Will you use Web page templates?

• Will you require that everyone use them?

• Who will design them?

• What will the color scheme for the site be?

• Where will the graphic library come from?

• Do your graphic designers understand the graphic and color palette issues specific to Web design?

Team assignments and responsibilities must be carefully understood and communicated from the very beginning. Everyone needs to know what is expected of him in the site development (and maintenance) process:

• Who is in charge of proofreading and editing?

• What sections of the site should be legally approved before publication?

• Who has the authority to change look and feel, colors, or themes?

• Who is responsible for providing links to newly added pages?

• What will be done to ensure that your site is accessible?

• What steps will be taken to ensure that these decisions are followed?

What happens after the site is up is always very important. A Web site is usually a constantly changing entity that requires an upkeep schedule. The Tasks view mentioned earlier works only when team members go to FrontPage to view their tasks. Everyone on the team needs to understand what is expected of him in terms of site maintenance and upkeep and should also know what type of update schedule he is required to follow.

Designing Workflow

After the site goal questions have been answered, the workflow design must be created. Workflow is best described as the specified order in which projects are completed, reported, and verified. In what order are the elements of site design going to come into play, and who is going to be responsible for what? If one element takes too long to complete (or is completed early), how does that affect the project? How much has to be done before the first page is designed, and how much effect on the site does any one page or user have?

The elements of workflow include content development, structure development, establishment of site look and feel, publication, alpha testing, beta testing, and maintenance. Although not all sites will contain all the elements listed, the workflow elements that will be used need to be put into place.

The workflow design should be simple enough to fit on a single page that can be distributed and communicated to the entire team so that they know what is expected.

TIP

Consider adding a special section to your site, which is accessible only by the team, that clearly states the site goal and workflow requirements. Ask your team to refer to this section on a regular basis so that they are reminded of the project requirements. You also can update the area as things change, and your team can automatically be updated when such changes occur via the use of subscriptions.

Content development is one of the more important issues in Web design. A popular catch phrase in the world of Web design is "content is king." If the project you are working on has a team of writers attached to it, the source for your content is clear. If (as is often the case) your team does not contain professional writers, the source of your content won't always be so. Don't automatically assume that everyone on your team has the skills required to write for the Web.

After the content is completed (or at least started), the content presentation and linkage structures must be determined. Documents that are hard to find and documents offering too many choices can create unnecessary confusion at the site. If utilized, the Navigation view is a powerful tool for determining structure development.

The site's look and feel is extremely important because it dictates how content is to be imported into the Web site. If the site will use themes, templates, or CSS, it is especially important that the team uses similar style tags so that all pages look the same. If style tags aren't used and the site theme is changed, the result could be awkward. If templates are used, the templates' sources, the templates' numbers, and the final templates' approval need to be determined as well.

For a further discussion of the use of FrontPage themes in Web design, see "Using Themes," p. 133.

Issues of site publication include

• How often is the site going to be published?

• Who has the authority to publish the site?

• Should any elements of the site be prevented from being published?

A publishing schedule and rule set must be established in the workflow design.

Alpha testing is the process of bringing in external users to examine the site's basic flow before it is completed. A shell must be put into place before alpha testing can take place, but site usability can be examined after this has been done. If the initial alpha testing team determines that the initial flow or feel of the alpha site is ineffective, a restructuring plan can be put into place without requiring a remake of the entire site.

Beta testing is the process of bringing users to the final site before it is open to the public (or specified audience) to catch bugs and problems that are seen much more easily by someone who has not spent hours on the project. The results of the beta test can range dramatically from simple bug fixes and content edit to large overhauls of issues missed during the design process.

Maintenance is key and sometimes more complicated than the rest of the issues mentioned earlier because it determines the life of the site after it has been published to the initial audience. Understanding and communicating who is in charge of each level of maintenance ensures that the site is updated as required.

Assignment of Duties Through the Tasks Feature

After the purpose of the site has been determined and the workflow process has been established, the next step for the manager is to assign duties to the team.

Select Edit, Tasks while in Tasks view to assign a generic task to a Web. Enter the task name, who it is assigned to, the priority for the task, and a short description. To associate a task to a specific document, have the document selected in Folder view before you create the new task.