11/12/2007 11:30 PM Web Style Guide: PROCESS

Page 1 of 15 http://www.webstyleguide.com/process/print/process.html
PROCESS
In the long run men hit only what they aim at.
Henry David Thoreau
THE FIRST STEP in designing any Web site is to define your goals. Without a clearly stated mission and
objectives the project will drift, bog down, or continue past an appropriate endpoint. Careful planning and a
clear purpose are the keys to success in building Web sites, particularly when you are working as part of a
development team.
BEFORE YOU BEGIN
Planning a Web site is a two-part process: first you gather your development partners, analyze your needs
and goals, and work through the development process outlined here to refine your plans. The second part is
creating a site specification document that details what you intend to do and why, what technology and
content you'll need, how long the process will take, what you will spend to do it, and how you will assess the
results of your efforts. The site specification document is crucial to creating a successful site, as it is both the
blueprint for your process and the touchstone you'll use to keep the project focused on your agreed goals and
deliverables.
Planning
Web sites are developed by groups of people to meet the needs of other groups of people. Unfortunately,
Web projects are often approached as a "technology problem," and projects are colored from the beginning
by enthusiasms for particular Web techniques or browser plug-ins (Flash, digital media, XML, databases,
etc.), not by real human or business needs. People are the key to successful Web projects. To create a
substantial site you'll need content experts, writers, information architects, graphic designers, technical
experts, and a producer or committee chair responsible for seeing the project to completion. If your site is
successful it will have to be genuinely useful to your target audience, meeting their needs and expectations
without being too hard to use.
Although the people who will actually use your site will determine whether the project is a success,
ironically, those very users are the people least likely to be present and involved when your site is designed
and built. Remember that the site development team should always function as an active, committed
advocate for the users and their needs. Experienced committee warriors may be skeptical here: these are fine
sentiments, but can you really do this in the face of management pressures, budget limitations, and divergent
stakeholder interests? Yes, you can because you have no choice if you really want your Web project to
succeed. If you listen only to management directives, keep the process sealed tightly within your
development team, and dictate to imagined users what the team imagines is best for them, be prepared for
failure. Involve real users, listen and respond to what they say, test your designs with them, and keep the site
easy to use, and the project will be a success.
11/12/2007 11:30 PM Web Style Guide: PROCESS
Page 2 of 15 http://www.webstyleguide.com/process/print/process.html
easy to use, and the project will be a success.
What are your goals?
A short statement identifying two or three goals should be the foundation of your Web site design. The
statement should include specific strategies around which the Web site will be designed, how long the site
design, construction, and evaluation periods will be, and specific quantitative and qualitative measures of
how the success of the site will be evaluated. Building a Web site is an ongoing process, not a one-time
project with static content. Long-term editorial management and technical maintenance must be covered in
your budget and production plans for the site. Without this perspective your electronic publication will
suffer the same fate as many corporate communications initiatives an enthusiastic start without lasting
accomplishments.
Know your audience
The next step is to identify the potential readers of your Web site so that you can structure the site design to
meet their needs and expectations. The knowledge, background, interests, and needs of users will vary from
tentative novices who need a carefully structured introduction to expert "power users" who may chafe at
anything that seems to patronize them or delay their access to information. A well-designed system should
be able to accommodate a range of users' skills and interests. For example, if the goal of your Web site is to
deliver internal corporate information, human resources documents, or other information formerly published
in paper manuals, your audience will range from those who will visit the site many times every day to those
who refer only occasionally to the site.
Design critiques
Each member of a site development team will bring different goals, preferences, and skills to the project.
Once the team has reached agreement on the mission and goals of the project, consensus on the overall
design approach for the Web site needs to be established. The goal at this stage is to identify potential
successful models in other Web sites and to begin to see the design problem from the site user's point of
view.
Unfortunately, production teams rarely include members of the target audience for the Web site. And it is
often difficult for team members who are not already experienced site designers to articulate their specific
preferences, except in reference to existing sites. Group critiques are a great way to explore what makes a
Web site successful, because everyone on the team sees each site from a user's point of view. Have each
team member bring a list of a few favorite sites to the critique, and ask them to introduce their sites and
comment on the successful elements of each design. In this way you will learn one another's design
sensibilities and begin to build consensus on the experience that your audience will have when they visit the
finished site.
11/12/2007 11:30 PM Web Style Guide: PROCESS
Page 3 of 15 http://www.webstyleguide.com/process/print/process.html
Content inventory
Once you have an idea of your Web site's mission and general structure, you can begin to assess the content
you will need to realize your plans. Building an inventory or database of existing and needed content will
force you to take a hard look at your existing content resources and to make a detailed outline of your needs.
Once you know where you are short on content you can concentrate on those deficits and avoid wasting time
on areas with existing resources that are ready to use. A clear grasp of your needs will also help you develop
a realistic schedule and budget for the project. Content development is the hardest, most time-consuming
part of any Web site development project. Starting early with a firm plan in hand will help ensure that you
won't be caught later with a well-structured but empty Web site.
Developing a site specification
The site specification is the planning team's concise statement of core goals, values, and intent, to provide
the ultimate policy direction for everything that comes next. Designing a substantial Web site is a costly and
time-consuming process. When you're up to your neck in the daily challenges of building the site, it can be
surprisingly easy to forget why you are doing what you are, to lose sight of your original priorities, and to
not know on any given day whether the detailed decisions you are making actually support those overall
goals and objectives. A well-written site specification is a powerful daily tool for judging the effectiveness
of a development effort. It provides the team with a compass to keep the development process focused on
the ultimate purposes of the site. As such, it quickly becomes a daily reference point to settle disputes, to
judge the potential utility of new ideas as they arise, to measure progress, and to keep the development team
focused on the ultimate goals.
At minimum, a good site specification should define the content scope, budget, schedule, and technical
aspects of the Web site. The best site specifications are very short and to the point, and are often just
outlines or bullet lists of the major design or technical features planned. The finished site specification
should contain the goals statement from the planning phase, as well as the structural details of the site.
Goals and strategies
What is the mission of your organization?
How will creating a Web site support your mission?
What are your two or three most important goals for the site?
Who is the primary audience for the Web site?
What do you want the audience to think or do after having visited your site?
What Web-related strategies will you use to achieve those goals?
How will you measure the success of your site?
How will you adequately maintain the finished site?
11/12/2007 11:30 PM Web Style Guide: PROCESS
Page 4 of 15 http://www.webstyleguide.com/process/print/process.html
Production issues
How many pages will the site contain? What is the maximum acceptable count under this budget?
What special technical or functional requirements are needed?
What is the budget for the site?
What is the production schedule for the site, including intermediate milestones and dates?
Who are the people or vendors on the development team and what are their responsibilities?
These are big questions, and the broad conceptual issues are too often dismissed as committees push toward
starting the "real work" of designing and building a Web site. However, if you cannot confidently answer all
of these questions, then no amount of design or production effort can guarantee a useful result.
Avoiding "scope creep"
The site specification defines the scope of your project that is, what and how much you need to do, the
budget, and the development schedule. "Scope creep" is the most prevalent cause of Web project failures. In
badly planned projects, scope creep is the gradual but inexorable process by which previously unplanned
"features" are added, content and features are padded to mollify each stakeholder group, major changes in
content or site structure during site construction are made, and more content or interactive functionality than
you originally agreed to create is stuffed in. No single overcommitment is fatal, but the slow, steady
accumulation of additions and changes is often enough to blow budgets, ruin schedules, and bury what
might have been an elegant original plan under megabytes of muddle and confusion.
Don't leap into building a Web site before you understand what you want to accomplish and before you have
developed a solid and realistic site specification for creating your Web site. The more carefully you plan, the
better off you will be when you begin to build your site.
One excellent way to keep a tight rein on the overall scope of the site content is to specify a maximum page
count in the site specification. Although a page count is hardly infallible as a guide (after all, Web pages can
be arbitrarily long), it serves as a constant reminder to everyone involved of the project's intended scope. If
the page count goes up, make it a rule to revisit the budget implications automatically the cold realities of
budgets and schedules will often cool the enthusiasm to stuff in "just one more page." A good way to keep a
lid on scope creep is to treat the page count as a "zero sum game." If someone wants to add pages, it's up to
them to nominate other pages to remove or to obtain a corresponding increase in the budget and schedule to
account for the increased work involved.
Changes and refinements can be a good thing, as long as everyone is realistic about the impact of potential
changes on the budget and schedule of a project. Any substantial change to the planned content, design, or
technical aspects of a site must be tightly coupled with a revision of the budget and schedule of the project.
People are often reluctant to discuss budgets or deadlines frankly and will often agree to substantial changes
or additions to a development plan rather than face an awkward conversation with a client or fellow team
member. But this acquiescence merely postpones the inevitable damage of not dealing with scope changes
11/12/2007 11:30 PM Web Style Guide: PROCESS
Page 5 of 15 http://www.webstyleguide.com/process/print/process.html
member. But this acquiescence merely postpones the inevitable damage of not dealing with scope changes
rationally.
The firm integration of schedule, budget, and scope is the only way to keep a Web project from becoming
unhinged from the real constraints of time, money, and the ultimate quality of the result. A little bravery and
honesty up front can save you much grief later. Make the plan carefully, and then stick to it.
THE SITE DEVELOPMENT PROCESS
Every significant Web project poses unique challenges, but the overall process of developing a complex
Web site generally follows six major stages:
. 1 Site definition and planning
. 2 Information architecture
. 3 Site design
. 4 Site construction
. 5 Site marketing
. 6 Tracking, evaluation, and maintenance
Developing a large Web site is a process that may have far-reaching budgetary, personnel, and public
relations consequences for an organization, both during the development of the site and long after its
successful deployment. Too many Web sites begin life as ad hoc efforts, created by small interest groups
working in isolation from their peers elsewhere in the organization and without fully considering the site's
goals within the context of the organization's overall mission. The result of poorly planned, hasty
development efforts often is an "orphan site," starved of resources and attention.
As you consider the development process outlined below, note that the construction of the pages that make
up the Web site is one of the last things that takes place in a well-designed project. Consider each step in the
process, and its impact on your developing site specification plan. Think before you act, and make sure you
have the organizational backing, budget, and personnel resources you'll need to make the project a success.
Site definition and planning
This initial stage is where you define your goals and objectives for the Web site and begin to collect and
analyze the information you'll need to justify the budget and resources required. This is also the time to
define the scope of the site content, the interactive functionality and technology support required, and the
depth and breadth of information resources that you will need to fill out the site and meet your reader's
expectations. If you are contracting out the production of the Web site, you will also need to interview and
select a site design firm. Ideally, your site designers should be involved as soon as possible in the planning
discussions.
Site production checklist
11/12/2007 11:30 PM Web Style Guide: PROCESS
Page 6 of 15 http://www.webstyleguide.com/process/print/process.html
Not every site will require consideration of every item below. Developers within corporations or other large
enterprises can often count on substantial in-house technology support when creating new Web sites. If you
are on your own as an individual or small business, you may need to contract with various technology and
design vendors to assemble everything you'll need to create a substantial content site or small e-commerce
site.
Production
Will your site production team be composed of in-house people, outside contractors, or a mix of the
two?
Who will manage the process?
Who are your primary content experts?
Who will be the liaison to any outside contractors?
Who will function long-term as the Webmaster or senior site editor?
Technology
What browsers and operating systems should your site support?
Windows, Macintosh, UNIX, Linux
Netscape Navigator, Internet Explorer; minimum version supported
Network bandwidth of average site visitors
Internal audience or largely external audience?
Ethernet or high-speed connections typical of corporate offices
ISDN, or DSL medium-speed connections typical of suburban homes
Modem connections for rural, international, or poorer audiences
Dynamic HTML (HyperText Markup Language) and advanced features?
JavaScript or vbscript required
Java applets required
Style sheets required
Third-party browser plug-ins required
Special features of the UNIX or NT server environments required
Special security or confidentiality features required
How will readers reach the support personnel?
Email messages from readers
Chat rooms, forums, help desks, or phone support
Database support?
User log-ins required to enter any site areas?
Questionnaires required?
Search and retrieval from databases needed?
11/12/2007 11:30 PM Web Style Guide: PROCESS
Page 7 of 15 http://www.webstyleguide.com/process/print/process.html
Audiovisual content
Video or audio productions?
Web server support
In-house Web server or outsourced to Internet Service Provider (ISP)?
Unique domain names available (multihoming)
Disk space or site traffic limitations or extra costs
Adequate capacity to meet site traffic demands?
Twenty-four-hour, seven-days-a-week support and maintenance?
Statistics on users and site traffic?
Server log analysis: in-house or outsourced?
Search engine suitable for your content?
CGI (Common Gateway Interface), programming, and database middleware support available?
Database support or coordination with in-house staff?
Budgeting
Salaries and benefits for short-term development staff and long-term editorial and support staff
Hardware and software for in-house development team members
Staff training in Web use, database, Web marketing, and Web design
Outsourcing fees
Site design and development
Technical consulting
Database development
Site marketing
Ongoing personnel support for site
Site editor or Webmaster
Ongoing server and technical support
Database maintenance and support
New content development and updating
Appoint a site editor
A site that is "everyone's responsibility" can quickly become an orphan. A maintenance plan should specify
who is responsible for the content of each page in the site. To maintain consistent editorial, graphic design,
and management policies you'll also need one person to act as the editor of the overall Web site. The site
editor's duties will vary according to how you choose to maintain your site. Some editors do all the work of
maintaining site content, relieving their coworkers of the need to deal directly with Web page editing. Other
editors coordinate and edit the work of many contributors who work directly on the site pages. If multiple
11/12/2007 11:30 PM Web Style Guide: PROCESS
Page 8 of 15 http://www.webstyleguide.com/process/print/process.html
people contribute to site maintenance, the site editor may choose to edit pages after they are created and
posted to avoid becoming a bottleneck in the communications process. However, high-profile public pages
or pages that contain very important content should be vetted by the editor before public posting.
In addition to ensuring editorial quality, a site editor must also ensure that the content of the site reflects the
policies of the enterprise, is consistent with local appropriate use policies, and does not contain material that
violates copyright laws. Many people who post pictures, cartoons, music files, or written material copied
from other sites on their own sites do not understand copyrights and the legal risks in using copyrighted
materials inappropriately. A site editor is often an institution's first line of defense against an expensive
lawsuit over the misuse of protected material.
Information architecture
At this stage you need to detail the content and organization of the Web site. The team should inventory all
existing content, describe what new content is required, and define the organizational structure of the site.
Once a content architecture has been sketched out, you should build small prototypes of parts of the site to
test what it feels like to move around within the design. Site prototypes are useful for two reasons. First, they
are the best way to test site navigation and develop the user interface. The prototypes should incorporate
enough pages to assess accurately what it's like to move from menus to content pages. Second, creating a
prototype allows the graphic designers to develop relations between how the site looks and how the
navigation interface supports the information design. The key to good prototyping is flexibility early on: the
site prototypes should not be so complex or elaborate that the team becomes too invested in one design at
the expense of exploring better alternatives.
Typical results or contract deliverables at the end of this stage could include:
Detailed site design specification
Detailed description of site content
Site maps, thumbnails, outlines, table of contents
Detailed technical support specification
Browser technology supported
Connection speed supported
Web server and server resources
Proposals to create programming or technology to support specific features of the site
A schedule for implementing the site design and construction
One or more site prototypes of multiple pages
Multiple graphic design and interface design sketches or roughs
Site design
At this stage the project acquires its look and feel, as the page grid, page design, and overall graphic design
standards are created and approved. Now the illustrations, photography, and other graphic or audiovisual
11/12/2007 11:30 PM Web Style Guide: PROCESS
Page 9 of 15 http://www.webstyleguide.com/process/print/process.html
standards are created and approved. Now the illustrations, photography, and other graphic or audiovisual
content for the site need to be commissioned and created. Research, writing, organizing, assembling, and
editing the site's text content is also performed at this stage. Any programming, database design and data
entry, and search engine design should be well under way by now. The goal is to produce all the content
components and functional programming and have them ready for the final production stage: the
construction of the actual Web site pages.
Typical products or contract deliverables at the end of this stage could include:
Content components, detailed organization and assembly
Text, edited and proofread
Graphic design specifications for all page types
Finished interface graphics for page templates
Header and footer graphics, logos, buttons, backgrounds
Detailed page comps or finished examples of key pages
Site graphic standards manual for large, complex sites
Interface design and master page grid templates completed
Finished HTML template pages
Illustrations
Photography
Functional and logic components
JavaScript scripts, Java applets designed
Database tables and programming, interaction prototypes completed
Search engine designed and tested
Templates
Whether you develop your site on you own or hire a professional Web developer, you should develop page
templates for your new Web site. It's much easier to add new pages if you can start from a page that already
has the basic navigation and site graphics in place. If you share page development with other people, you
will also want to be able to give your team members templates to use, along with instructions on how to
handle page text and content graphics according to your standards. Popular Web site development software
packages such as Macromedia's Dreamweaver offer powerful templates and standard reusable libraries of
site graphics and HTML that make it easy to create new pages and maintain your site.
Accessibility
11/12/2007 11:30 PM Web Style Guide: PROCESS
Page 10 of 15 http://www.webstyleguide.com/process/print/process.html
For many organizations, providing equal access to Web pages is institutional policy, if not a federal
mandate. It is critical, therefore, that you validate your designs and page templates and the content of your
site throughout the development process to ensure that your pages are accessible to all users. To check the
accessibility of your pages you can use a tool like Bobby (www.cast.org/bobby). Bobby is a free service
provided by the Center for Applied Special Technology. After you supply the URL (Uniform Resource
Locator) of your page, Bobby checks the page against the Web Accessibility Initiative guidelines and flags
potential barriers for users with disabilities. Bobby also recommends changes that will improve the
accessibility of your pages. Check your designs at every development milestone to avoid time-consuming
and potentially costly revamping efforts.
Site construction
Only at this mature stage of the project are the bulk of the site's Web pages constructed and filled out with
content. By waiting until you have a detailed site architecture, mature content components, and a polished
page design specification you will minimize the content churning, redundant development efforts, and
wasted energy that inevitably result from rushing to create pages too soon. Of course, you will always learn
new things about your overall design as the prototype matures into the full-blown Web site. Be prepared to
refine your designs as you navigate through the growing Web site and discover both weak spots and
opportunities to improve navigation or content.
Once the site has been constructed, with all pages completed and all database and programming components
linked, it is ready for beta testing. Testing should be done primarily by readers outside your site development
team who are willing to supply informed criticism and report programming bugs, typographic errors, and
critique the overall design and effectiveness of the site. Fresh users will inevitably notice things that you and
your development team have overlooked. Only after the site has been thoroughly tested should you begin to
publicize the URL address of the site to a larger audience.
Typical products or contract deliverables at the end of this stage should include:
Finished HTML for all Web pages, all page content in place
Finished navigation link structure
All programming in place and linked to pages, ready for beta testing
All database components in place and linked to site pages
All graphic design, illustration, and photography in place
Final proofreading of all site content
Detailed testing of database and programming functionality
Testing and verification of database reporting features
Testing of site reader support procedures, answering email, etc.
Archives of all site content components, HTML code, programming code, and any other site
development materials
11/12/2007 11:30 PM Web Style Guide: PROCESS
Page 11 of 15 http://www.webstyleguide.com/process/print/process.html
Maintainable code
Most business or departments in larger enterprises will contract with a Web development group to create the
initial site design and to build all the pages in the first version of the Web site. They then assume
responsibility for the site, doing some or all of the day-to-day maintenance and updating content as needed
to keep the site current.
Often not until the practicalities of site maintenance come up do customers realize the importance of
understanding the details of how the Web developer generated the HTML and other code that makes up the
Web site. Although all HTML is much the same to Web browsing software, how the HTML is formatted
and what Web authoring tool the developer used can make a huge difference in how the code looks to a
human reader. Consider the two code examples below:
Example 1
<! START OF SCHEDULE TABLE ======= >
<table summary="Human Investigations Committee II schedule, FY 2001." border="0" width="100%"
cellspacing="0" cellpadding="1">
<tr valign="top">
<! =============================== >
<td width="50%">
<p class="tabletext">
Deadline for Submissions</p>
</td>
<td width="2%">
&nbsp;
</td>
<td width="48%">
<p class="tabletext">
Meeting Dates 2001</p>
</td></tr>
<! =============================== >
Example 2
<table summary="Human Investigations Committee II schedule, FY 2001." border="0" width="100%"
cellspacing="0" cellpadding="1"><tr valign="top"><td width="50%"><p class="tabletext">Deadline for
Submissions</p></td><td width="2%">&nbsp;</td><td width="48%"><p class="tabletext">Meeting Dates
2001</p></td></tr>
Which example do you find easier to understand? These code examples are exactly equivalent to Web
browser software, but most people would find Example 1 significantly easier to read and understand. If you
contract with a developer to build your site, it is crucial to understand how the developer writes code, what
state the code will be in when the site is delivered, and whether the software used by the developer is
compatible with what you will be using to maintain the site after delivery. Some Web development software
produces HTML code that is nearly impossible for a human to read without significant (and expensive)
11/12/2007 11:30 PM Web Style Guide: PROCESS
Page 12 of 15 http://www.webstyleguide.com/process/print/process.html
produces HTML code that is nearly impossible for a human to read without significant (and expensive)
reformatting. Other programs (such as Macromedia Dreamweaver) produce HTML code that is easy for
Web programmers to read, which can make a huge difference if you decide to change Web developers or if
you decide to edit HTML directly in maintaining your site. If you hire someone to create your Web site, be
sure to ask what tools he or she will use to write the HTML and any other code. Ask to see examples of
HTML code written for other clients. Check the code to be sure the developer inserts explanatory comments
and dividers for legibility in the code. Be sure you understand whether there will be any problems or
conflicts in using your favorite Web tools to edit the HTML code your Web developer produces.
Site marketing
Your Web site should be an integral part of all marketing campaigns and corporate communications
programs, and the URL for your site should appear on every piece of correspondence and marketing
collateral your organization generates.
If your Web site is aimed primarily at local audiences you must look beyond getting listed in standard Web
indexes, such as Yahoo and Infoseek, URL and publicize your URL where local residents or businesses will
encounter it. Local libraries (and schools, where the content is relevant) are often the key to publicizing a
new Web site within a localized geographic area.
You may also find opportunities to cross-promote your site with affiliated businesses, professional
organizations, broadcast or print media, visitor or local information agencies, real estate and relocation
services, Internet access providers, and local city or town directory sites. Your organization could also
feature local nonprofit charitable or school events on your Web site. The cost in server space is usually
trivial, and highly publicized local events featuring a Web page hosted within your site will boost local
awareness of your Web presence. Site sponsorship might also interest local broadcast media as an
interesting story angle.
Your home page URL should appear in all:
Print advertisements
Radio and television advertisements
Lobby kiosks in high-traffic areas of your enterprise or in local libraries, schools, or other suitable
venues
Direct mail campaigns
Business cards
Stationery
Bills and statements
Product manuals and product packaging
Response cards and warrantee cards
Publications and promotional materials
11/12/2007 11:30 PM Web Style Guide: PROCESS
Page 13 of 15 http://www.webstyleguide.com/process/print/process.html
Press releases
Posters and billboards
Tracking, evaluation, and maintenance
An abundance of information about visitors to your site can be recorded with your Web server software.
Even the simplest site logs track how many people (unique visitors) saw your site over a given time, how
many pages were requested for viewing, and many other variables. By analyzing the server logs for your
Web site you can develop quantitative data on the success of your site. The logs will tell you what pages
were the most popular and what brands and versions of Web browser people used to view your site. Server
logs can also give you information on the geographic location of your site readers. The usefulness of your
site logs will depend on what you ask of the server and the people who maintain the server. Detailed logs
are the key to quantifying the success of a Web site. Your Webmaster should archive all site logs for long-
term analysis and should be prepared to add or change the information categories being logged as your
needs and interests change.
A number of popular software packages are designed to produce easily readable site traffic reports, complete
with data graphics and charts to aid in data analysis. As a service to customers, site hosting companies often
offer reports from popular site analysis programs like WebTrends, often free of charge. Before contracting
with an Internet Service Provider (ISP) for site hosting services, always ask about site analysis services. If
your ISP or corporate Web site does not offer a good site traffic analysis package, ask whether the
Webmaster can give you access to a monthly server log of your account. Basic versions of traffic analysis
programs like WebTrends cost about three hundred dollars, and you can run them on a personal computer if
you can gain access to the raw Web server log from your ISP or corporate Webmaster.
Maintaining the site
Don't abandon your site once the production "goes live" and the parties are over. The aesthetic and
functional aspects of a large Web site need constant attention and grooming, particularly if a group of
individuals shares responsibility for updating content. Someone will need to be responsible for coordinating
and vetting the new content stream, maintaining the graphic and editorial standards, and assuring that the
programming and linkages of all pages remain intact and functional. Links on the Web are perishable, and
you'll need to check periodically that links to pages outside your immediate site are still working. Don't let
your site go stale by starving it of resources just as you begin to develop an audience if you disappoint
them by not following through it will be doubly difficult to attract them back.
Backups and site archives
The site editor should be sure that the Web site is regularly backed up onto a secure and reliable storage
medium to ensure that a catastrophic hardware failure in your Web server does not wipe out your Web site.
Most Web servers maintained by information technology professionals or commercial Web service
providers are backed up at least once a day. If you don't know what your particular backup schedule is, ask
11/12/2007 11:30 PM Web Style Guide: PROCESS
Page 14 of 15 http://www.webstyleguide.com/process/print/process.html
providers are backed up at least once a day. If you don't know what your particular backup schedule is, ask
your Webmaster or Web services vendor. Human error is the most common reason you may want quick
access to a backup copy of your Web site. Unfortunately, it's easy to accidentally overwrite an old file (or a
whole directory of files) over a newer version on the Web server, to delete something important in error, or
to inadvertently wipe out someone else's work when updating a Web site. A recent backup (ideally no more
than twenty-four hours old) can often be a lifesaver in correcting a mistake.
If your site is successful, it will quickly become an important record of your enterprise's work, your
accomplishments, and a valuable record of the "state of things" as the site evolves over time. Unfortunately,
too little attention is paid to this aspect of Web sites, and we are collectively losing huge pieces of our
history because no one thinks about preserving permanent records of a Web site. Unless your Web site is
prohibitively large, your Web site editor could arrange to collect and store the files of the site periodically or
contract with your Web service provider to set aside a backup version at regular intervals so that it can be
stored for long-term use. We take for granted the "paper trail" of history left by conventional business and
work practices. Without a plan for preserving our digital works, our collective history may vanish without a
trace.
REFERENCES
Development process
Burdman, Jessica R. 1999. Collaborative Web development: Strategies and best practices for Web teams.
Reading, Mass.: Addison-Wesley.
Dobson, Michael Singer. 1996. Practical project management: Secrets of managing any project on time and
on budget. Mission, Kans.: SkillPath.
Frenza, J. P., and Michelle Szabo. Web and new media pricing guide: A business and pricing guide for Web
sites and related digital media. Indianapolis, Ind.: Hayden Books.
Friedlein, Ashley. 2001. Web project management: Delivering successful commercial Web sites. San
Francisco: Morgan Kaufmann.
Graphic Artists Guild et al. 1997. Graphic Artists Guild handbook: Pricing and ethical guidelines, 9th ed.
Cincinnati, Ohio: North Light Books.
Reiss, Eric L. 2000. Practical information architecture: A hands-on approach to structuring successful Web
sites. Reading, Mass.: Addison-Wesley.
Siegel, David. 1997. Secrets of successful Web sites: Project management on the World Wide Web.
Indianapolis, Ind.: Hayden Books.
Veen, Jeffrey. 2001. The art and science of Web design. Indianapolis, Ind.: New Riders.
11/12/2007 11:30 PM Web Style Guide: PROCESS
Page 15 of 15 http://www.webstyleguide.com/process/print/process.html
General reference
Meyer, Eric. A. 2000. Cascading Style Sheets: The definitive guide. Sebastopol, Calif.: O'Reilly.
Musciano, Chuck, and Bill Kennedy. 2000. HTML and XHTML: The definitive guide. Sebastopol, Calif.:
O'Reilly.
Niederst, Jennifer. 1999. Web design in a nutshell: A desktop quick reference. Sebastopol, Calif.: O'Reilly.
Powell, Thomas A. 2000. Web design: The complete reference. Berkeley, Calif.: Osborne/McGraw-Hill.
Spainhour, Steven, and Robert Eckstein. 1999. Webmaster in a nutshell: A desktop quick reference, 2d ed.
Sebastopol, Calif.: O'Reilly.
From Web Style Guide
www.webstyleguide.com
Copyright 2002 Lynch and Horton