Publishing Standards for all
Research, Development, and Technology
Communications Material
Publishing Standards for RD&T Research
Reports
Purpose:
Research reports provide a permanent record of the research we have
conducted. These reports communicate research results to other researchers
and to those who are responsible for establishing standards and
policies. Research reports should provide a description of the study
objectives, research methodology used, data analysis, conclusions,
changes in existing procedures or practices, and any recommendations
for future research.
Technical Review:
The Contracting Officer’s Technical Representative (COTR) and the
Principal Investigator (PI) are responsible for the technical accuracy
of the material in a report. When the Statement of Work (SOW) for
a research study is being developed, the Technical Director and
COTR should discuss the content and format of the research report.
The SOW should include a separate task for preparing draft and final
research reports. This task should estimate a level of effort and
associated costs. Each SOW should include the specifications for
the final research report.
A peer review should be conducted for each research report before
it is published. This peer review could be done by members of the
technical evaluation panel, who review the proposals received in
response to the Request for Proposals (RFP); other professionals
in the field, such as members of Transportation Research Board committees;
or members of other professional organizations.
Each Office should establish their own process for reviewing research
reports from a technical, editorial, and policy standpoint. This
process should contain the necessary checks and balances to ensure
that the Office of RD&T continues to publish high-quality research
reports.
Research reports generated from staff studies should follow the
same standards as research reports generated by contractors.
Style:
All research reports developed shall follow the Turner-Fairbank
Highway Research Center (TFHRC) Quick Reference Guide dated May
1990 or later. Editorial reviews of the material will be provided
by the Office of Research and Technology Services (HRTM).
Reviews will be done electronically, please see the contract language
below for proper electronic format. (If reports are to be placed
on the Internet, electronic versions of reports shall be provided
in an HTML-coded format.)
The following language should be included in all contracts:
All documents developed under this contract (with the exception
of progress reports) shall be prepared in accordance with the latest
version of the Turner-Fairbank Highway Research Center Quick Reference
Guide.
Ninety days prior to the completion date of the contract, the
contractor shall furnish the COTR with 10 copies of the final draft
of the research report. The contractor shall also supply an electronic
version of the final draft on an 88.9-mm (3.5-in) diskette(s). Electronic
text files should be created in Word (6.0 or above). Graphics should
be created as separate elements and imported into the text file
for print reports. All fonts used in the document must be supplied
on the disk so the document will print as it appeared on the contractor’s
equipment. The use of 1 of the standard 35 fonts that are provided
with most printers is recommended.
Files must be included in the programs of origin, such as PowerPoint,
Word, etc., so these files can be modified or corrected and re-imported
into the full text document. Art must be produced in a program that
can export an interchange file format that can be imported into
the full text. Photos must be in TIF or EPS with on- screen preview
and with line screen appropriate for printing. Files should be provided
in a manageable size of 3 Mb or less.
HTML coded files should be coded to an HTML (3.2 or above) standard.
Any internal links should be relative, not absolute addresses. Graphics
should be either a .gif or a .jpeg file. Graphic file size should
be kept to 50 kB per graphic.
The Government shall review the draft of the research report
and furnish comments, including editorial comments, to the contractor
within 30 days of receipt of the report. The contractor shall revise
the draft research report to reflect the Government’s comments.
Thirty days prior to the completion date of the contract, the
contractor shall furnish the COTR with a printable electronic version
of of the final research report. The contractor shall also provide
10 copies of the final report to the COTR. The COTR shall approve
the report(s) in writing within 30 days of receipt.
All research reports should provide units of measurement using
only the SI (metric) system. The American Society for Testing and
Materials publication, Standard Practice for Use of the SI International
System of Units: The Modernized Metric System (ASTM E380-89a or
later) should be followed.
Policy Implications:
All reports should include the following disclaimer clause located
on the inside front cover:
This document is disseminated under the sponsorship of the Department
of Transportation (DOT) in the interest of information exchange.
The United States Government assumes no liability for its content
or use thereof. This report does not constitute a standard, specification,
or regulation.
The United States Government does not endorse products or manufacturers.
Trade and manufactures’ names appear in this report only because
they are considered essential to the object of the document.
The Federal Highway Administration (FHWA) staff in appropriate
offices should review research reports so that they are aware of
any policy implications before the reports are published. As indicated
in the section on Technical Review, each Office should determine
at what point the policy review should take place.
Timeliness:
Research reports should be reviewed, published, and distributed
within 4 months from the date the final draft report is submitted
to the COTR.
Publishing Standards for RD&T Specialty
Reports
Purpose:
Specialty reports serve more than just a technical purpose. They
promote our technical achievements, accomplishments, policies, and
plans to a broader, more policy-oriented audience. Specialty reports
are designed and written to be more visible and to impress their
audience. They are not typically project-specific, but apply to
programs comprising multiple projects of RD&T and FHWA.
The TFHRC annual Achievements Report and the Long-Term Pavement
Performance Roadmap are examples of specialty reports.
Technical Review:
The technical accuracy of the content of specialty reports remains
paramount to preserve the integrity of TFHRC as a research facility.
For publications initiated at or via HRTM primarily for public
relations purposes, the HRTM staff will provide advance notice
(at least 1 month prior to printing the report) to each Office Director
who has an interest in the publication. The Office Directors will
be responsible for determining the requirements for external or
internal technical review, and will provide an estimate of the time
required for the review. Once the text is received by HRTM, an editorial
review can be completed in 2 weeks.
For reports initiated by an Office, technical reviews will be completed
prior to submitting the text for editorial review. Because of the
high visibility of these publications, technical reviews must include
a peer review outside of the Office.
RD&T Style:
To create a publication, the group must hold a meeting to outline
its purpose, audience, content, design, and style. If the publication
is technically oriented, apply the TFHRC Quick Reference Guide;
if the purpose is promotional, apply a journalistic-style guideline.
Policy Implications:
In keeping with the high profile of these publications, reviewing
for policy implications is a priority. After the technical review
and first editorial review are complete, the offices potentially
affected by the report review the unformatted text while the layout
and final design are being initiated.
For an FHWA-wide publication, the HRTM staff will coordinate the
policy review with the Public Affairs Office. For TFHRC-wide publications,
each Office Director will conduct a policy review. The Office Directors
will also seek the review of offices as needed.
Timeliness:
Specialty reports tend to have long lead times, but short preparation
times. That is, the need or desire for the specialty report can
usually be identified well in advance, but the content is often
time-sensitive and last minute. Accordingly, contracted resources
are typically used for the writing, editing, designing, and printing
of the publication. Ten weeks is the target completion time from
the date the content is available to the date the publication is
distributed. To ensure that contractors are available in the HRTM,
Offices must provide notification of a specialty publication no
later than 4 months prior to the publication date.
Publishing Standards for RD&T User Guides/Manuals
Purpose:
A User Guide is the documentation associated with a computer-based
analysis or simulation program that provides an end user with the
guidance necessary to use the program. The level of detail in the
User Guide may vary depending on the level of on-line support available
with the computer program. A computer program that is very user-friendly,
with well-documented help features may not need as great a level
of detail as a computer program that is “non-intuitive” or difficult
to use.
Technical Review:
Technical review of the User Guide is the responsibility of the
COTR. The User Guide is usually produced by the same contractor
or researchers that developed the computer program. If the User
Guide was produced by someone else, then a member of the software
development team should review the User Guide. In addition, at least
one independent reviewer, who was not involved in the creation of
the User Guide or in the development of the computer program, should
review the User Guide. This independent reviewer should be a typical
end-user who is familiar with the analysis methods and topic area
covered by the computer program.
The review cycle of the User Guide should coincide with the prototyping
and beta testing of the computer program. Draft User Guides should
be reviewed with corresponding prototype versions of the computer
program. These prototype versions of the computer program should
be made available to all reviewers. For the review of the final
User Guide, the final version of the computer program should be
available.
Style: The User Guide should incorporate the same general
style guidelines as a Research Report. In addition, the User Guide
should be easy to use and should incorporate pictures and figures
(e.g., screen captures, flow diagrams, etc.) whenever possible.
The document should refrain from using jargon or acronyms that may
not be known by all users. Frequently, the length of a User Guide
may become excessive because of the need to serve all users. If
this is the case, the User Guide should be divided so that a user
is not intimidated by the size of the document. One option is to
divide the document into separate volumes. For example, one volume
could be a Guide for New Users and a second volume could be a Guide
for Advanced Users.
The User Guide should be organized into meaningful sections for
the end-user of the computer program. Although this may differ depending
on the computer program, some typical sections include the following:
- Introduction: General introduction and description of the user
guide and computer program.
- Requirements: Description of software and hardware requirements
needed to run the computer program.
- Installation: Instructions for installation of the computer
program.
- Features and Capabilities: Description of the abilities of the
computer program.
- Input Requirements: Description of the input data necessary
to run the computer program and the method for data input.
- Output Measures: Description of the computer program output
and how to interpret results.
- Utility Program Interactions: Description of any third-party
computer programs (e.g., input and output processors or off-the-shelf
programs) and their interaction with the main program.
- Application: Description of the problem applications that the
computer program can address.
- Example: An example(s) of some computer program sessions, including
input and output.
- Troubleshooting: Description of troubleshooting techniques,
error messages, and available technical support.
Policy Implications:
User Guides should contain a disclaimer stating that the Federal
Government and the developer of the computer program are not responsible
for implementation decisions (e.g., construction designs, traffic
signal timings, etc.) made based on the results of analyses performed
using the computer program.
Timeliness:
As stated above, the review cycle of the User Guide should coincide
with the review of the computer program so that draft User Guides
are reviewed with prototype versions of the computer program. The
User Guide should be available upon release of the computer program.
Both the User Guide and the computer program should have companion
version numbers so that any updates to one will result in an update
of the other.
Publishing Standards for RD&T Programmer
Guides/Manuals
Purpose:
A Programmer Guide is the documentation associated with a computer-based
analysis or simulation program that provides an end-user with detailed
information in order that he/she can fully understand the underlying
operation of the computer program. Typically, a Programmer Guide
is used by researchers or computer programmers interested in modifying
existing source code to test new algorithms, add new features, or
improve the structure or efficiency of a computer program.
Technical Review:
Technical review of the Programmer Guide is the responsibility of
the COTR. The same entity that developed the computer program usually
produces the Programmer Guide. If a separate entity produced the
Programmer Guide, then a member of the software development team
should review the Programmer Guide. In addition, at least one independent
reviewer, who was not involved in the creation of the Programmer
Guide or in the development of the computer program, should conduct
a technical review of the Programmer Guide. This independent reviewer
should be a typical end-user who is familiar with computer programming
and with the analysis methods and topic area covered by the computer
program.
The review cycle of the Programmer Guide should coincide with the
prototyping and beta testing of the computer program. Draft Programmer
Guides should be reviewed with corresponding prototype versions
of the computer program.
Style:
The Programmer Guide should incorporate the same general style guidelines
as technical reports. In addition, the Programmer Guide should be
easy to use and should incorporate pictures and figures (e.g., flow
diagrams, etc.) whenever possible. The document should refrain from
using jargon or acronyms that may not be known by all potential
users. The length of the Programmer Guide usually depends on the
size and structure of the computer program. Size and level of detail
also depends on the flexibility of the computer program to be modified.
The Programmer Guide should be organized into meaningful sections
for the end-user of the computer program. Although this may differ
depending on the computer program, some typical sections include
the following:
- Introduction: General introduction and description of the Programmer
Guide and computer program.
- Requirements: Description of software and hardware requirements
needed to run the computer program.
- References: References to other documents or computer programs
that are relevant to users of the Programmer Guide.
- Overall Program Description: Description of overall design of
program and software review. Description of file creation, file
organization, and file management.
- Utility Program Interactions: Description of any third-party
computer programs (e.g., input and output processors or off-the-shelf
programs) and their interaction with the main program and associated
file conversions.
- Main Program: A description of the main program, including a
structure chart of high-level program flows and sub-routine interaction.
- Sub-Routine Descriptions: Description of each of the sub-routines
of the computer program. Each sub-routine description should include
the name of the sub-routine, its function, and a description of
how it operates. The description of the sub-routine should include
a description of input and output, sub-routine calls, calling
sub-routines, error handling, and programming notes (i.e., description
of how the underlying theories were coded in the program).
- Structure Charts: For each sub-routine, a structure chart (e.g.,
flow chart, object relationship chart) should be included. This
may be included as part of the “Sub-Routine Description” or may
be in a separate appendix, or both, depending on the level of
detail (i.e., more detailed charts go in the appendix).
- Data Base: Description of all program input and output, all
variables and their formats, and a data dictionary. This may be
included as part of the “Sub-Routine Description” or may be in
a separate appendix.
Policy Implications:
Programmer Guides should contain a disclaimer stating that the Federal
Government and/or the developer of the computer program is not responsible
for implementation decisions (e.g., construction designs, traffic
signal timings, etc.) made based on the results of analyses performed
using the computer program.
Timeliness:
As stated above, the review cycle of the Programmer Guide should
coincide with the review of the computer program so that draft Programmer
Guides are reviewed with prototype versions of the computer program.
The Programmer Guide should be available upon release of the computer
program. Both the Programmer Guide and the computer program should
have companion version numbers so that any updates to one will result
in an update of the other.
Publishing Standards for RD&T Presentation
Graphics
Purpose:
Overhead transparencies, slide shows, PowerPoint presentations,
flip charts, etc. are used to enhance and support a presentation
and to highlight and reinforce the important points of a presentation.
Hard copies of the visual aids can be made as handouts to accompany
a presentation.
Technical Review:
The technical expert/presenter is responsible for developing the
material and ensuring that the information presented is factually
accurate and in agreement with management policy. At a minimum,
a technical review by at least one peer within the Office or program
working group is recommended. In addition, it is recommended that
the presentation be approved by the Office Director.
Style:
Presentation graphics can be developed and prepared in the following
ways:
- Within the immediate office. The presenter is responsible for
the appropriate technical review and for the presentation being
proofread for spelling and calculation errors.
- Through the HRTM, which offers editorial and graphic design
services.
- Through the TFHRC Graphics Center, which provides these services;
however, their primary mission is to provide services for the
Human Factors Laboratories and the Photometric and Visibility
Laboratory (these laboratories are given priority). All other
requests for presentation graphic services are on a first-come,
first-serve basis. See attachment for details on Graphics Center
services and procedures.
- Through a task order contract with a private company (budgeted
at the Office level).
When using PowerPoint presentations or overhead transparencies,
the graphics designer shall contact HRTM or Graphics Center for
electronic transparency templates that show the DOT/FHWA/TFHRC symbol.
These templates can be altered in color and style, but the symbol
should stay as an identifying factor.
It is best to include a headline and use only one idea for each
visual. Ideas and relationships should be simple. A balance of words,
charts, and graphics should be used to make presentations visually
appealing. The typeface should be large and readable.
Policy Implications:
If the presentation is dealing with policy issues, the Office Director
is responsible for making sure the implications are in agreement
with management policies.
Timeliness:
Timeframes for presentations developed in the presenter’s immediate
office should be negotiated between the presenter and the graphic
designer.
A 2-week delivery date should be expected when using HRTM or Graphics
Center.
Private company delivery timeframes should be stated in task order
contracts.
Publishing Standards for Public Roads
Articles
Purpose:
Public Roadsis the bimonthly magazine of FHWA. The magazine
features developments in Federal highway policies, programs, and
research and technology. Public Roads tries to represent
all of FHWA while maintaining a foundation in research and technology.
The magazine’s audience includes transportation officials and transportation
professionals.
Technical Review:
Every manuscript submitted for publication in Public Roads
is reviewed by FHWA experts to evaluate its merit and technical
accuracy. Manuscripts received from authors outside FHWA are submitted
to a review panel. Manuscripts submitted by authors employed by
Federal, State, or local governmental agencies must include a letter
of transmittal from the author’s supervisor that endorses the publication
of the article. In addition, manuscripts by authors within the Department
of Transportation must be endorsed by the applicable Office Director,
which supersedes the requirement for a review panel.
Style:
Public Roads follows the Associated Press Stylebook and
Libel Manual (AP) with a few minor exceptions. AP is fairly consistent
with composition standards taught in high school. Authors are not
expected to be AP experts; the magazine editors will “fix” any discrepancies
in grammatical style.
Public Roads communicates through a balance of text and
visual elements. An appropriate number of high-quality photographs
and/or illustrations with proper captions are an indispensable part
of an article. The emphasis of the article should be on the significance
of the project or subject, results of research and/or lessons learned,
and the applicability of these lessons learned to other States,
agencies, etc.
The specifications for manuscripts include:
- Hard copy and a copy on 88.9-mm (3.5-in) computer disk using
IBM-compatible Word (6.0 or lower version) (or e-mail on FHWA’s
e-mail network to fhrd4:bbryant).
- The manuscript should be typed using Times New Roman or a similar
typeface, 10-point type, and single-spacing with at least 25-mm
(1-in) margins on 216- by 279-mm (8.5- by 11-in) paper. About
600 words and a supporting visual element will fill a magazine
page.
- Authors should contact the Public Roads editor for more
detailed information regarding style.
Completed manuscript/illustration packages are to be submitted
to: Public Roads Editor (HRTM), Turner-Fairbank Highway Research
Center, Room F219, 6300 Georgetown Pike, McLean, VA 22101-2296.
Policy Implications:
Even though the magazine carries a disclaimer stating that “articles
written by private individuals contain the personal views of the
author and do not necessarily reflect those of FHWA,” Public
Roads, as the magazine of the agency, should never publish anything
that is inconsistent with agency policies or positions. If there
is concern in this area, the article will be referred to the Office
of Public Affairs for review.
Timeliness:
The magazine is distributed the first week of July, September, November,
January, March, and May. The deadline for manuscripts and illustrations
is 3 months prior — on or about April 1, June 1, August 1, October
1, December 1, and February 1, respectively.
Publishing Standards for RD&T Technical
Articles
Purpose:
Technical articles represent a method of publishing research results
or research program summaries through some technical organization
outside of FHWA. This outside medium enables researchers to reach
specific sectors of the technical community or industry. Technical
articles often appear as articles or updates in technical journals
and as papers submitted to various symposia.
Technical Review:
The specific level of review required for technical articles published
outside of FHWA is left to the discretion of each Office. At a minimum,
it is recommended that the content and forum of presentation (e.g.,
symposium or publishing body) be approved by the researcher’s Office
Director. In addition, technical review by at least one peer within
each Office or working group is recommended. When submitted to the
Office Director for approval, the peer reviewer should be indicated.
Style:
Style and formatting for technical articles will be dictated by
the publishing organization.
Policy Implications:
Authors should clearly indicate the nature of conclusions and recommendations
as results of specific research, author’s opinion, etc. In general,
policy issues should not be addressed in articles published outside
of FHWA’s authority. If there is a policy concern, the article can
be referred to the Office of Public Affairs for review.
Timeliness:
Technical articles are published on varying schedules depending
on the publishing organization. Most often, abstracts or manuscripts
are submitted 6 months to 1 year prior to publication or presentation.
Final editing and layout is often performed by the publishing organization.
Publishing Standards for RD&T Videos
Purpose:
A well-produced video tape can quickly communicate a message with
maximum impact to the audience. Videos are suited to a variety of
purposes: they can provide program overview, illustrate a process
that is difficult to communicate in a written medium, introduce
an organization, provide training, etc. However, because of the
high cost associated with this medium, prudent use is recommended.
In considering this option, ask the following questions:
- Is this for a large audience (is this the most cost-effective
way to reach a small audience)?
- Will it have a sufficiently long shelf life to warrant the expenditure
or will it be quickly dated?
- What is my message? Is this the best way to convey it (is this
a subject that is best learned by “seeing”)? Does it rely heavily
on visuals?
- Is there a better medium for my message? (Video does not handle
detailed material as well as printed matter does.)
- Do I have the resources for this medium?
Technical Review:
Once you have made the decision to produce a video, you need to
obtain the services of an executive producer or a scriptwriter that
will also take on the function of producer. This person will be
in charge of and coordinate the efforts of your other talent. Your
producer should have an initial meeting to: (1) meet key contacts
and outline the review process required for the script and film;
(2) find out video objective and audience, and discuss possible
content or approaches; (3) obtain a list of the subject matter experts
to interview and possible shooting locations; and (4) understand
the deliverables expected and other related components (budget,
quantities, due date, etc).
It is recommended that an RD&T contact who is familiar with
the subject matter be assigned as assistant producer. This person
would be responsible for coordinating the review process internally
and acting as the liaison between the executive producer and RD&T
staff. Typically, the initial script or film draft would be reviewed
by the assistant producer first, then by the designated review group.
It is advised that the review cycle be limited to Office Directors
and those in higher positions, with the scriptwriter and director
present. Too large of a review group will have difficulty reaching
consensus on the script and the presence of a scriptwriter and director
ensure that questions regarding content, approach, and effect can
be addressed on the spot — they can also address questions regarding
revisions (time, effort, cost, etc.). Generally, second, and occasionally
third, reviews are needed before a final version is agreed upon
by the review committee.
Style:
There is no set style for a video. The best results are obtained
when the production team (scriptwriter, film crew, and production
editors) has a fair amount of leeway to use their creative talents.
Attached is the SOW used for the 1996 TFHRC video, Focusing on Innovation.
The SOW is detailed and all steps may not be required for all projects.
However, it can be used as a starting point in the initial meeting
between staff and the executive producer.
Policy Implications:
In the initial meeting with the executive producer, the review process
needs to be outlined up-front. This includes how many reviews and
by whom. Video content will determine which offices need to review
the script or final draft product and whether the Office of Public
Affairs should be involved.
Timeliness:
Three months should be allowed for the video production schedule.
This is an estimate of the time it takes from the initial meeting
with the executive producer to having the final master in hand.
Having TFHRC staff provide research assistance to the scriptwriter
or having them locate existing footage can shorten this production
schedule. However, having numerous review cycles or a large review
group can lengthen the process. Setting up expectations, roles,
and timeframes can keep the production schedule on track.
Statement of Work
Task: Produce a 5- to 7-minute videotape (VHS format) program that
highlights the major research programs and facilities of the Turner-Fairbank
Highway Research Center. The videotape will be used to introduce
visitors to the center and will be shown at conferences and trade
shows to demonstrate the unique capabilities of the facility.
Target completion date is July 20, 1996, so that the tape is available
for showing at the National Research Advisory Council Meeting scheduled
for late July.
This task includes the following components:
- Script Development:
- Work with FEDERAL HIGHWAY ADMINISTRATION staff to develop
script in accordance with key messages/images, includes the
following:
- a. Prescript meeting.
- b. Research.
- c. Writing video treatment.
- d. Treatment presentation.
- e. Writing script and developing storyboard.
- f. Script and storyboard presentation.
- g. Script and storyboard revision.
- Pre-Production:
- Collect and review needed video footage. FEDERAL HIGHWAY
ADMINISTRATION staff will assist in doing the needed background
research and acquisition of materials (approximately 70%-75%
of the film can come from existing material, depending on
script).
- Develop shooting plan for original footage (as little as
25%-30% can be original footage, depending on script).
- Assemble film crew.
- Set up logistics for location shooting.
- Acquire props, talent, and equipment as needed.
- Production:
- Shoot original footage, such as filming the facility, key
projects, and staff.
- Post-Production:
- Work includes the following:
- a. Graphics and/or animation production (as determined
by script).
- b. Film editing.
- c. Developing soundtrack (professional narration; mixing
voice over, library music, and other sound effects as
determined by script).
- d. Developing optical effects, such as text and transitions.
- e. Revisions and edits as needed.
Provide a 25.4-mm (1-in) master tape and a super-VHS copy.
Publishing Standards for RD&T CD-ROMs
Purpose:
CD-ROM publishing provides a multimedia communications solution
that may contain components of audio, video, text, and animation
to anyone interested in viewing the CD. CD-ROM publications may
encompass educational material, archival data, or training courses.
CD-ROM publishing may be done to either supplement existing print
material or as a stand-alone product.
CD-ROM’s will store up to 650 Mb of information. CD-ROM’s hold
every type of electronic file; however, this will depend on the
type of authoring program being used to create your program.
Technical Review:
All material and CD-ROM production specifications should be reviewed.
Technical data should be reviewed by the responsible Office. The
CD-ROM production specifications, slipcover text and artwork, and
“read me” or help text should be reviewed by HRTM.
Before the final press of the CD-ROM, a copy of the CD-ROM should
be reviewed and tested by the Office. The testing should involve
a thorough review of links, graphics, and functionality of the CD-ROM.
The review should cover proofreading of the text. Testing and quality
control of any CD-ROM product is necessary and important. Thorough
testing includes an operational test to ensure that the CD-ROM operates
on all intended platforms (i.e., Windows 3.1, Windows 95, and Windows
NT), that all files are included, and that the product is complete.
Style:
Actual content style of the CD-ROM will vary based on the authoring
program used by the contractor. However, the following should be
included:
- FHWA triskelion displayed on the cover.
- TFHRC name should appear on the cover.
All CD-ROM’s need to have a complete “read me” or help file that
has been proofread and tested. The language in the CD-ROM should
be simple and direct. It should address installation of the CD-ROM,
any additional software needed, and any potential troubleshooting.
The installation text should address installation on all intended
operating system platforms (i.e., Windows 95, Windows 3.1, DOS,
OS/2).
Text on the slipcover should include hardware system requirements
(i.e., 486 DX, with at least 3 Mb of RAM, color monitor, and Windows
95). This should also be included in the “read me” text.
The “about” file should give a general overview of the purpose
and content of the CD-ROM, as well as any copyright information
pertaining to the software, trademark, or patent information necessary
to protect the CD-ROM or the programs used to create or view the
CD-ROM. The “about” file should include a contact from the Office.
All CD-ROM’s should include the same information on the slipcover.
All CD-ROM’s need a disclaimer statement regarding the merchantability
and fitness of the CD-ROM product. An example of such a disclaimer
follows:
Limited Warranty and Limitations of Remedies
This product is provided “as-is,” without warranty of any kind
— either expressed or implied (but not limited to the implied warranties
of merchantability and fitness for a particular purpose). The FHWA
and the distributor do not warrant that the functions contained
in the software will meet the end-user’s requirements or that operation
of the software will be uninterrupted and error-free. Under no circumstances
will FHWA or the distributor be liable to the end-user for any damages
or claim of any lost profits, lost savings, or other incidental
or consequential damages rising out of the use of or inability to
use the software (even if these organizations have been advised
of the possibility of such damages), or for any claim by any other
party.
Policy Implications:
The group responsible for publishing the CD-ROM should review the
information for any policy implications that the material may present.
A review by the appropriate Office Director is required. If there
is a policy concern, the material can be referred to the Office
of Public Affairs for review. All policy review should be complete
before a final version of the CD-ROM is created.
Timeliness:
CD-ROM publishing, like other publishing formats, requires ample
time for drafts, revisions, and testing. Because each Office is
currently contracting out most CD-ROM publications, the contractor
should be able to provide the best time estimate based on the work,
scope, and effort.
Publishing Standards for RD&T Web Site Posting
Purpose:
Web site publishing provides an electronic medium that adds dimensions
to normal publication routes. Web site publishing offers graphical
interface, instantaneous transmission, and multimedia presentation.
Web site publishing can be used as a primary route of publication,
a secondary source of publication, or as a supplemental source of
information, depending upon the use, audience, and intent of the
publication.
Technical Review:
To prepare a document for Web site publication, the document needs
to be coded in HTML (Hypertext Markup Language). This should be
done after consulting with the Web Manager/Publisher for information
on coding requirements and file size. If necessary, the Web Publisher
will create templates to allow for easier document coding.
Before the document is posted to the Web site, the following must
be done:
- Proper Office Director approval for Web site publishing.
- Document and coding review by Web Publisher.
Before posting, the Web Publisher should be aware of the status
of the document, whether it is a finished, edited, and published
document or a draft document that is being posted for technical
review. Also the Web Publisher needs to be aware of additional multimedia/programming
requirements. Each office should assign a liaison who is knowledgeable
about TFHRC Web publishing requirements, and is responsible for
delivering the correct pieces to the Web Publisher.
Once posted to the Web site, the Web Publisher will be reviewing
the document for flow and testing any hyperlinks. Technical content
will be the responsibility of the group submitting the document
to the Web site.
Style:
Web documents should be coded to an HTML 3.0 standard. Coders need
to follow proper meta text and coding requirements, which include
font and color schemes, to ensure continuity throughout the Web
site.
If a contractor is preparing the document for Web publishing, the
COTR should ensure that the contractor has received a set of guidelines
from HRTM. Any form or interactive mechanism that may require additional
programming should be approved by the Web Publisher. Any one document
or set of related documents that will require more than 10 Mb should
be reviewed by the Web Publisher for alternative publishing options.
Policy Implications:
The group or person responsible for publishing the material should
review the information for any policy implications that the material
may present. A review by the appropriate Office Director is required.
If there is a policy concern, the material can be referred to the
Office of Public Affairs for review. If an additional review is
needed, it should be taken care of before the document is reviewed
by the Web Publisher.
Timeliness:
The Web is an instantaneous form of publishing. Unless the
document involves higher level programming, creation of original
graphics, or revision by the Web Publisher, the document should
be published within 2 weeks. However, this is dependent upon the
size of the document and any additional work needed.
TFHRC Home
