Know your purpose. State it in a single sentence. Your Web site's purpose
might be, for example, "to sell our line of products." A good
purpose will be specific and represent a new activity that adds significant
value to the Web. Then state specific, measurable objectives that the site
What is the most common mistake Web developers make.
A lack of understanding of the audience for the Web site. Understanding
your audience means knowing their needs and expectations--what they do know,
what they don't know. For example, a common error is when some sites that depend
on an in-person visit (such as the Web site of a restaurant, festival, or real-world
store) neglect to identify the city and state in which the store or physical
event is located. The developers forget that the Web site is global.
Another common audience error is to assume that they know about the navigation
cues on a site. Having symbols, links on certain words, and modes of representing
the information based on clicking on links makes a site hard to navigate. The
audience needs to be able to find out the navigation scheme of a site. Ideally,
the scheme should be self-evident, even to a brand new user.
What should I look for in a Web developer
(or agency) I might hire.
Ask the developers, "How can our needs be met with Web-based communication." If
the developers can articulate issues such as identifying your audience, meeting
their needs, and taking advantage of the unique qualities of the Web for your
Web's purpose, consider them. If the developers start blabbing on about technology--how
want to pay for Web developers to play with technology, but rather accomplish
your communication objectives.
What is the difference between "Web development" and "Web
The way I look at it, Web development encompasses a whole set of processes,
and one of those processes is Web design. Web design, unfortunately, has come
to represent only page layout and graphics issues. I look at Web design as
encompassing far more than that--including issues such as hypertext navigation,
thematic issues that have to do with the Web's purpose, and organizational
issues about the Web site's file organization. I hope people who call themselves "Web
designers" understand this, but I think many do not.
Isn't Web development just a user interface
No. Because a Web isn't just an object without a rhetorical or social
context. Developing a Web site isn't just about screen layout, ergonomic optimization,
choosing the right colors, and labeling links and buttons correctly. I see
a total set of processes that include issues that one might call "project
management"--planning, analysis, design, implementation, promotion, and
innovation--but actually have to do with the ancient art of rhetoric and techniques
of human communication.
If I have a running site right now, what is
the best thing to do to improve it.
Get some outside feedback. Developers are often not trained in human
communication and make entirely too many assumptions about what an audience
knows about the site's content or navigation cues. Feedback from experts in
communication should help you. Definitely feedback from the audience can help--but
you have to understand that excellent communication is usually structured intelligently.
The structure shouldn't necessarily be run by a poll or a popular vote, or
based on audience members who may have a very incorrect idea about what the
site is all about.
What do you think are the best Web sites.
Those that unabashedly focus on their purpose and have a strong sense
of their audience. Yahoo.com's full coverage news area is absolutely fantastic--it
accomplishes a specific purpose using the unique qualities of the Web; it has
a clean layout and organization.
If you advocate a team/process approach in
developing a Web site, isn't that just design by committee.
If you have a project that one person can do
in their head, that is fine--no need for cooperation, a team,
or even a process approach. But in general, most professional
Web developers are in situations where projects are big and success
needs to be reliable.We think a person with no training and no
cooperation with others could produce a fantastic Web site. But
I think Web developers can be trained to do a better job more
reliably with a documented, process approach in which tasks and
products of those tasks are systematically identified.
To understand dynamic web pages you have to understand normal web pages. Typical
non-dynamic web pages do not change every time the page is loaded into the
browser, nor do they change if a user clicks on a button. The only change that
you will see in static pages is to see them load and unload, like what happens
when you click on a hyper link.
In a nutshell: static web pages (normal pages you build) always look the same
and the content never changes unless you load a new page or you change the
page yourself and upload the new version of the pages unto the server.
Dynamic pages do the opposite, they can change every time they are loaded (without
you having to make those changes) and they can change their content based on
what user does, like clicking on some text or an image. (I am not talking about
loading a new page!).
One of the most common types of dynamic web pages is the database driven type.
This means that you have a web page that grabs information from a database
(the web page is connected to the database by programming.) and inserts that
information into the web page each time it is loaded. If the information stored
in the database changes, the web page connected to the database will also change
accordingly and automatically without human intervention.
This is commonly seen on online banking sites where you can log in (by entering
your user name and password) and check out your bank account balance. Your
bank account information is stored in a database and has been connected to
the web page with programming thus enabling you to see your banking information.
Imagine if the web page holding your banking information had to be built traditionally
(that is by hand.) every time your bank balance changed! Even a thousand monkeys
working 24/7 drinking 5 cups of coffee a day, would not be able to keep up!
Hopefully you are starting to see why you would want a database driven site;
you would want it if your information changes very often, just like in a banking
site. Database driven sites can be built using several competing technologies, each
with it’s own advantages.
Some of those technologies/tools include:
I will be writing about these technologies in future articles and newsletters.
You now have them listed here for you to research on your own.
Learn about database.
Database driven web site programming can also be called (or characterized as): ‘server
side programming’. The reason it is so called is because the ‘action’ or
magic that allows the web pages to connect to the database is actually taking
place on the server. What happens is that each time a dynamic web page is about
to be sent to the browser, the server automatically builds the page and sends
a standard HTML page to the browser. The server knows how to build the page
by following the instructions provided by the programmer. This is different
in the web browser.
At this point many people are getting very confused, the confusion lies in
the difference between server side programming (database driven web pages)
The other type of dynamic web page: Client side (that is to say: in the browser)
or what is commonly called DHTML; dynamic HTML.
the web page change it’s own content (as far as the viewer is concerned)
without having to reload or load a new page. Examples of DHTML would include
drop down menu’s (check out the black menu bars at the top right hand
corner of http://www.microsoft.com) or a ‘floating’ text and image
http://www.studioweb.com. Look for the ‘floating’ image on the
left hand side of the page. As you scroll the image floats along side staying
in view. The above are just very simple examples of what you can do with DHTML
and if you look around you will find plenty on the web.
Just a final note on DHTML; it can be very useful (dynamic menus for example.)
but it can also be a lot of trouble. Sometimes you are much better off using
Flash or just designing your pages so that you don’t need to use dynamic
Hopefully now you have basic conceptual understanding of dynamic web sites,
DHTML and database driven web sites. I tried to present the information in
a non-geek way so as to not confuse. The down side of this simple approach
is that I am not being 100% precise. Some geeks out there may point out one
or two items that are not dead on, but don’t worry, my points are not
in any way wrong. Suffice it to say that this was an introduction to the topic.
Developing Information Content for the World Wide Web
With the expanding technical options for communication on the Web, developers
might be tempted to focus only on issues such as hypertext markup language
(HTML) syntax, page layout, or the latest and flashiest technologies. However,
Web developers need a broader, more process-oriented approach in order
to articulate the information content they wish to convey. Developers also
need to pay close attention to the characteristics and qualities of the
Web as a medium for communication so that they don't merely duplicate practices
intended for paper other other media.
Developing Web content involves shaping and negotiating meaning and making
many choices involving technical, aesthetic, and usability concerns. And, as
technical communicators know, developing information requires keen skills in
planning, analysis, and design in addition to Web-oriented skills in representing
information in a particular medium.
In order to develop a broader perspective of Web, developers can draw on many
existing concepts from technical communication and software engineering practices.
This article briefly describes the methodology for Web information development
that is process-oriented and which takes into account the unique characteristics
and qualities of the World Wide Web
An Information Development Methodology for the Web
Patterned after design and development processes similar to those used by many
technical communicators, writers, designers, and software developers, this
methodology involves six process and six elements. We base this methodology
on the characteristics and qualities of the Web and on the particular experiences
of Web users.
Our methodology involves six sets of information, which we call elements:
1. Audience information is a store of knowledge about the target audience for
the web as well as the
actual audience who uses the web.
2. The purpose statement defines the reason for and scope of the web's existence.
3. The objectives list defines the specific goals the web should accomplish.
4. The domain information is a collection of knowledge and information about
the subject domain the
5. The web specification is a detailed description of the constraints and elements
that will go
into the web.
6. The web presentation is the full description of the technical structures
(hypertext and other media) by
which the web is delivered to the users.
The communicator develops these elements while engaging in these six processes:
1. Planning is the process of defining and gathering information about the
web's audience, purpose,
objectives, and policies for information development
2. Analysis involves evaluating information consistency and correctness as
well as checking the
technical makeup of the web.
3. Design is the process of creating a map of the relationships among pages
of the web and the look
and feel of individual pages.
4. Implementation: is the process of creating files of HTML (and associated
software, such as Java
5. Promotion: involves providing publicity releases for general Web audiences,
potential users, and
6. Innovation is the process of continuously and creatively working for improvement
in the web to meet
You'll notice that this methodology contains many of the same elements as a
traditional information development process as well as shares a resemblance
to software engineering practices. However, since Web works often are very
dynamic and competitive, a web information developer should work on all these
processes continuously. There's no "final state" analogous to a ship
date for a paper document, software, or CD-ROM--every day is a new deadline,
and each day brings a new information environment.
In the first stages of the lifecycle of a web, your focus will be on the processes
of planning and analysis. In particular, you'll need to define the purpose
of your web and develop audience information. Audience analysis is key in many
technical communication tasks. This planning and analysis requires that you
ask and answer questions such as: Who will use this web. What will they gain
A useful method to generate audience information is to make a list of information
about the audience's background, characteristics, and concerns. This information
may not ever be complete, but developers can create and maintain a store of
information that can grow over time.
At first, don't try to reach too broad an audience (e.g., "everyone using
the Web"), but focus on a subset related to your purpose. For example,
if you are preparing a web for a company selling modems, you might define your
audience as "potential, current, and past purchasers of the modems." You
may have several audiences for the web. For example, in addition to modem buyers,
you could be also communicating to company stockholders, employees, or suppliers.
One useful technique is to create a diagram showing the audiences you will
reach in your web.
Another focus in the early phase of web development is to define your purpose.
It's a good idea to have
a written purpose statement available at all times
during web development. At first, you might state the purpose in general terms,
such as "to create a presence for our company in cyberspace." However,
it is best to make your purpose statement more specific even at first, such
as "to provide information about our company's products."
The purpose statement and audience information together go a long way toward
articulating what the web is about and are the key pieces of information to
develop early in the web's lifecycle.
Setting Objectives and Gathering Domain Information
Given an audience and a purpose, you can next focus on forming a list of specific
objectives, or goals, for the web to accomplish. For example, a web's purpose
statement might be "to provide information about our company's line of
modems" and this web's audience definition might be "prospective
The objective list for this web might be:
• List the pictures, prices, schematics of all of our modems.
• Provide ordering and service information.
• Provide background (domain) information about modems to interest prospective
customers and help
them user our products.
Once you have created a set of objectives, the next step is to gather domain
information that supports these objectives. The domain information is a collection
of knowledge and information about the subject domain the web covers. This
includes information that the users of the web will encounter and information
the web developers need to design or implement the web.
For example, a web offering modems for sale might draw on a variety of information
about the use, mechanics, principles, and specifications for modems. While
not all this information would necessarily be made available to the users of
the web, this domain knowledge may be helpful for the web developers so that
they can understand the vocabulary and concepts associated with the products.
Often, this domain information makes a good complement to the information the
web offers. For example, a modem manufacturer with a good collection of modem
facts might find that interested buyers visit that web for technical information
about modems and, in the course of this visit, be informed of a company's products.
Designing a Web
In designing a web you should take into account the web's purpose and audience.
A good designer knows how to achieve the effects called for in the most flexible,
efficient, and elegant way. To design a web, you should have a thorough grounding
in hypertext, multimedia, Java, and other programming possibilities as well
as knowledge about how particular web structures affect an audience.
Because of the porous quality of a web, you need to consider how a variety
of audiences might find different "ways into" your information. Hypertext
can provide alternate views of information and alternative routes for users
to follow based on their needs and interests. A good way to provide this flexibility
is to separate information into manageable page-sized chunks and then provide
cues for the reader about the web's information structure and contents, context,
and navigation. A Web designer thus creates an overall link architecture for
a web--specifying page contents and the hyperlinks among these pages to connect
information along the routes of user needs.
A web designer should also create a coherent and consistent "look and
feel" for the entire web. One way to do this is to use principles of page
layout and design and provide the user with a variety of visual cues. These
cues, consistently placed on pages of the web, help users navigate and use
the web's information. Because a web is characteristically bound in its use
context, these cues should help reveal that context, so that the user can find
related information and find how the web relates to other areas of knowledge.
After you've completed a web design, the next step is to implement the web
within the limitations on its technical makeup you may have defined in its
specifications. The initial implementation might be a prototype which is not
released publicly, but available for analysis as used by a set of representative
A web implementer creates hypertext markup language (HTML), Common Gateway
Interface (CGI) programs, and/or Java scripts and/or applets. The implementation
process resembles software development because it involves using a specific
syntax for creating hypertext structures in HTML or writing programming language
code statements in computer files.
Here are key implementation practices:
• At the outset, create a stable, extendible directory and file structure
to manage the web's files and/or
software components (including CGI or Java programs).
• Use HTML tools such as editors and authoring environments where helpful.
Note that some of these
editors are "translators" from authoring programs
meant for paper based publications and are not
always customized for hypertext
• Check the web's implementation in various browsers to ensure that the
HTML can be interpreted
properly. Use templates for supporting the consistent
look and feel defined in the Web's design.
Analyzing a Web
During analysis, you examine a web's elements to see if it is accomplishing
its objectives, to see if it is implemented correctly, and its domain information
is correct and up-to-date. The goal of this evaluation is to identify problem
Key analysis practices are:
• Observing representative audience members using your web (usability analysis).
• Evaluating the consistency and verify the correctness of the domain information.
• Checking the technical implementation of the web with HTML validation
The decision to publicly announce the release of your web should not be made
lightly. During the time immediately following its public availability, your
web will receive a great deal of attention from not only the audience members
it attempts to reach, but people involved in web resource indexing as well
as automated indexing software.
Once your web is ready, you can make its existence known to online communities
through publicity. You can also form relationships with other webs which reach
a similar audience or have been prepared for a similar purpose. Another way
to further promote a web is to use specific marketing strategies or business
models customized for the environment of the Web.
In doing this promotion, it is important that you follow online community norms.
You should avoid "spamming" (indiscriminately sending messages to
large numbers of mostly uninterested people) any communication forum with news
of your web's release. Instead, you should aim publicity to appropriate online
(and offline) mailing lists and promotion services.
Despite the linear description of the processes of Web development I've described
here, the work of a Web is never done. Because a web is a round-the-clock,
interactive service, developers should expect feedback from users and anticipate
their changing needs.
Key innovation practices are:
• Continuously and creatively work for improvement to meet user needs.
• Based on analysis, user testing, and focus groups, identify new user
• Identify new technologies that may help you meet user needs better.
Ultimately the goal of innovation is to continuously improve the quality of
a web by making sure that the processes of planning, analysis, design, implementation,
promotion, and innovation are ongoing. Developers can share information about
the web's elements and ensure that the information in the web meets user needs
in terms of both content and interface.
While the methodology outlined here for developing a web won't work flawlessly
in all situations, it can serve as a basis for approaching many of the issues
of web information development.
To a casual Web user, this formal methodology might seem an encumbering amount
of complication on what may seem to be only the task of "writing HTML" or
creating a "home page." However, identifying processes and elements
and focusing on them need not stifle creativity--in fact, a process approach
is a emphasis of many quality improvement programs 7. And, as many Web users
might attest, a well-developed web usually has a far greater value than one
that is hastily put together. In particular, a web intended for business or
professional communication needs to not only reflect a consensus of meaning
among the sponsors and originators of the information, but it must reach a
diverse audience and continuously change as user needs change.
1. Grice, Roger A. "Document Development in Industry." In Technical
Writing: Theory and Practice, ed.
Bertie E. Fearing and W. Keats Sparrow, pp.
27-32. New York: The Modern Language Association of
2. Nielsen, Jakob. Designing Web Usability. Indianapolis: New Riders, 2000.
3. December, John, "An Information Development Methodology for the World
Wide Web," Technical
Communication, (Vol. 43, No. 4, 1996, pp. 369-375).
4. December, John. "Web Development." Milwaukee: December Communications,
5. Booch, Grady. Object-oriented analysis and design with applications. Redwood
Benjamin/Cummings Publishing, 1994.
6. Anderson, Paul V. Technical Writing: A Reader-Centered Approach. 2nd ed.
San Diego, CA: Harcourt
Brace Jovanovich, 1991.
7. Deming, W. Edwards. Out of the crisis. Cambridge, MA: MIT Center for Advanced
Engineering Study, 1986.