|
A step-by-step guide
By Eric Leland
Source: TechSoup.org
What are the steps you need to
follow to go from the idea of a database driven Web site to
actual design, development, and implementation? Eric Leland
of Leland Design & CompuMentor not only lays out these steps
but helps you understand the features of advanced database
driven Web sites. Anyone working on a Web site project will
want to read this article.
Introduction
The relationship between nonprofits
and Web technology has evolved a great deal since the dawn
of the Internet. In the beginning the brochure Web site dominated
where nonprofits used the Web to display basic information
about available programs, services and how to get in touch.
These sites typically were creatively and technically managed
by a lone Web master, often working only a few hours here
and there to keep the site up. Now the Web is not so new anymore.
The number of Web users has grown dramatically, and increasingly
nonprofits are considering how best to build online tools
to engage their audience in more substantial, targeted and
interactive ways? and the lone Webmaster is feeling just a
bit overwhelmed.
Why build a Web
database?
The Problem: A foundation plans
to present information about its grantees on the Web site,
arranged by their issue area and location. The foundation
has 400 grantees that cover 10 issue areas and are located
in 39 states across the USA.
-
Possible Static Solutions: Develop 403 pages. The first
two long list all 400 grantees grouped by location and the
other listing grantees grouped by issue area, a third page
to contain the links to the two long pages, and 400 pages
for the full profile of each grantee. Or develop 450 pages,
one for each of the 39 locations, one for each of the 10
issue areas, one page to contain the links to each individual
location and issue area pages, and then 400 pages each containing
the full profile of each grantee.
-
Database Driven Solution: Develop three pages. The first
lists all the issue areas and locations available in the
database for the visitor to select. The second page then
lists all the grantees names pulled from the database in
a list according to the visitor's selection from the first
page. The third page provides all the profile information
from the database for the grantee the visitor selected from
the grantee list.
Simple
"database driven" Web sites allow you to view data, first
in pre-determined ways and then through interactive mechanisms.
The key benefit to a Web database is the separation of the
data from its presentation. This separation makes it possible
to focus on managing the content of the site without spending
time designing and redesigning its presentation. By using
the same Web page for the grantee issue area and location
lists, and another one Web page for the grantee profile, the
design of the Web page is kept the same while the data on
the page changes depending on what the visitor chooses.
Databases
provide a great tool for managing large amounts of information,
and for managing frequently changing information requiring
less staff time. In the example above, information about grantees
can be changed from a database window separately from any
complicated Web code, and the changes will automatically and
immediately be revealed on the Web site. The same benefit
applies to the design of the Web pages themselves. If the
foundation wishes to make a visual change to the presentation
of the grantee information, they only need to edit a maximum
of three Web pages, not 400+.
Databases
enable the same information to be repurposed for a variety
of needs and presentations. In our example above, if the foundation
needs to present grantees according to the year each won the
grant, this information can be readily retrieved from existing
data in the database (presuming the foundation recorded this
information) and presented to the visitor using the existing
three Web pages. No need to redesign any of the Web templates,
just filter the database information differently.
Databases
can be used in a variety of ways to help engage an audience.
Database driven Web sites can allow users to interact with
the data - they can search and view database information,
and more advanced applications allow users to add, delete,
and modify the data in appropriate ways. Last year, the Ploughshares
Fund planned to put its grantee information onto the Web site.
The information was stored in an access database that functioned
very well in-house, but was not connected to the Web site.
Instead of maintaining the same information in two places,
Ploughshares staff decided to build a set of database driven
Web pages that would allow visitors to pull the grantee information
directly from their access database. The Web site now offers
a "grants search" feature that provides visitors several options
for filtering the list of grantees by different categories
and by keyword. Since the grantee information changes only
periodically throughout the year, the agency simply makes
the changes in their Access database as usual, and the staff
Webmaster moves a copy of this database to the server whenever
the site needs updating.
Advanced
database driven Web sites
More
and more consultants and Web design firms are offering "Content
Management Systems" (CMS) to organizations looking to expand
their Web sites. CMS commonly refers to software that separates
Web site content from its design for an entire Web site. CMS
is typically focused on providing tools for staff to manage
Web site content without extensive knowledge of Web development.
We
have already discussed simple examples of custom CMS systems
- the foundation Web sites discussed above provide a level
of content management for a specific portion of the site.
Advanced content management systems frequently provide tools
for managing all content on the Web site, and provide staff
additional content process tools, such as workflow coordination
by providing a tool for content creation, editorial review
and approval with various levels of staff access.
Forefront
has developed a custom content management system that allows
staff to manage both public as well as member only content
via a set of content administration pages hosted online. The
site gives public visitors the option to view each member's
profiles by name, region and country, or to customize their
results by searching for a keyword. Each individual member
profile also lists links to other profiles from the same region
or country, providing the public with an intuitive system
for exploring members sharing similarities. In addition, Forefront
members have secure access to a "members only" resource providing
Web pages that access private newsletter content stored in
the online database. Each member profile and newsletter content
is stored in the same database, and the information can be
administered and modified via a secure staff-only section
of the Web site. Forefront staff can simply browse the member
profiles or newsletters online, choose one to edit, and then
make any additions or modifications to the content itself.
Once the changes are submitted, the content is then immediately
available on the Web site.
Since
content management systems typically focus on providing easy
tools for staff content developers to maintain online content,
the benefits to the Web site audience, although large, are
mostly invisible. Idealist and Taking IT Global provides examples
of discussion forums and user personalization (MyIdealist).
Planning
a database driven Web site
The
wider and deeper a nonprofit chooses to interact online with
their audience, the more players should contribute to the
online planning process. Debating the merits of databases
and other technology for a project is premature without having
discussed resources and commitment, goals and objectives,
information management and architecture and support issues.
Implementing an expansive Web project, whether partially database
driven, fully driven using a content management system, or
static, requires important choices before considering databases
and other technology tools.
Step
1: Resources and commitment
Start
by gathering all the interested parties and discussing the
available resources for carrying out the planning and implementation
of the project. Is there management/board support? Is there
a budget? Are there staff hours to devote to planning? Answers
to these questions will help determine your agency's readiness
for Web database development.
Step
2: Identify a planning Team
A
successful planning effort will be driven by an interdisciplinary
team of participants. The core team should be driven by two
roles:
- Project
Lead: Responsible for sign-off on key decisions, providing
project steering and maintaining relationships with outside
stakeholders (board members for example).
- Project
Coordinator: Responsible for keeping the project on schedule
and within the budget, and maintains communication between
other team members.
Other
team members should include representatives from communications,
development, and other major content stakeholders (programs,
outreach, etc). This team should include the organization's
most technology proficient staff member, as well as the person
or person most involved with the daily flow of information
within and outside the organization (often the office manager,
administrative assistant or receptionist). Often this team
will include a Web consultant to provide a smoother transition
from planning to implementation.
Especially
for Web database projects, the most important stakeholder
is the audience for your agency's services. Developing an
"advisory committee" composed of a diverse representation
of your audience will not only help in the formulation of
the goals, needs and priorities for the project, but will
also entice your audience to participate in and contribute
to the resulting system, as they too had a stake in its development.
Step
3: Project mission and competition review
Answer
the question: How does the mission of the project differ from
the mission of the organization? Web projects may actually
be a strategy for achieving only some of the goals derived
from your agency's mission. For each Web site goal, identify
the strategies used to achieve the goals, and where the Web
site fits into each of these strategies. Understanding how
the Web will map to each strategy helps to see linkages between
the information and interactivity that the Web site will provide,
and these linkages provides the basis for developing a database
structure for the site.
Use
the project mission to inform a search for similar efforts
by other agencies. Look for agencies having specifically developed
a similar scale of Web database projects, as they will be
able to provide the most constructive insight into your own
organization's needs. If similar efforts are found, evaluate
their effectiveness, possibilities for collaboration and your
agency's niche. Talking directly with the core persons involved
in similar Web projects can provide valuable insight into
potential pitfalls facing your agency's project.
Step
4: Audience review and scenarios
Who
will the Web site serve? Why will people come? Often the answers
to these two questions are in opposition - an agency may plan
for the site to serve the whole audience, but on examining
why they would come, discover that the site predominantly
favors a certain audience segment. If you have not already,
now is a great time to involve your advisory committee in
these decisions. Do not forget to consider your staff as one
audience; this is especially important when building a content
management system for staff administration of the Web site.
Once
the audience is determined, it is useful to develop scenarios
that represent each component of your audience. A typical
scenario will start with a character described with the demographic
characteristics of the audience group:
"Bill
is a sole proprietor, 35 years old, working as a management
consultant for nonprofits. He lives outside of a major city
and travels several times a year for business. He uses the
internet and email frequently in his work, and enjoys a high
bandwidth connection to the internet?"
Develop
a persona for other segments of your audience, and walk each
persona through their experience visiting your Web site. What
are they looking for? How do they try to find the information
on your site? How long do they spend looking? Are they encouraged
to come back? Building in as many details as possible into
the persona of your character helps the planning committee
to develop a deeper understanding of who the character is
and how they will respond to the Web site. Scenarios provide
practical examples of the content and interactivity visitors
will look for and participate in on the site, which will help
to define database content structures and presentation strategies
later. It is important to continue to run through new scenarios
with the same personas as you progress through the remainder
of the planning.
Step
5: Content
Content
decisions flow out of decisions on the target audience groups
and persona/scenario development. Identify content needs of
the site. Identify the source and resources required to generate
each piece of content - is the content already produced in-house,
does it come from outside, or is it a new project altogether?
How much staff time does it take or will it take to manage
the content, from drafting, editing, reviewing to posting
and maintaining over time?
Think
about each content piece as an assembly of separate content
parts. If the plan calls for putting the newsletter on the
site, get a copy of a few newsletters and identify the common
elements in each - headline, author, date, sub headline, content
body, copyright, etc. Identify these content parts for each
type of content that is planned for the site, as this information
will be the basis for defining the fields and structure of
the Web database.
Discovering
the content needs of the site should involve all staff with
any stake in the Web site, as well as the advisory committee.
The database lead and coordinator can work to gather the content
needs, and develop a summary and priority content list. It
is very helpful to have the technical staff or Web consultant
focus at this point at helping to define the content parts.
Step
6: Function and interactivity
What
do visitors do when the come to your site? How do they talk
to staff, to each other, or to outside resources? What content
do they view, and what do they contribute to or modify? Interactive
functions typically offer the visitor the ability to contribute
some content. Online feedback forms, polls, listserv subscription
pages, discussion forums, online donations, site personalization,
Web content management, site keyword search boxes are all
examples of functions that combines with your content and
structure at various intersections.
For
a database driven Web site, it is important to identify what
portions of the visitor's input you will capture and store,
and who will have access to this information. For example,
you may capture visitor's name and email addresses in order
to send them your e-newsletter, but you want to limit access
to this information to only staff, not the general public.
In another example, an organization might want to collect
visitor's yes/no answers to a series of questions in an online
poll, and desire to display only the sum total of yes/no votes
for each questions, but not each visitor's answer. Descriptions
of interactivity around content will help to define site access
levels and security for the Web database system.
Step
7: Structure Try arranging the content and function/interactive
elements into different clusters. Ask yourselves questions
- Do we want to arrange content by issue, by intended audience,
by author, by agency program, or in multiple presentations?
Decisions on site structure forms the basis for the navigation
tool you will provide visitors to your Web site. However,
a wise consideration is to allow for multiple paths through
your site, as your chosen site structure will likely not be
the best way for each and every member of your audience to
find information on your Web site. Providing a keyword search
feature and a site map is invaluable to creating a positive
user experience.
Especially
important for database driven Web sites is to consider what
content "chunks" are needed. For example, you may want to
provide a list of all grant recipients together with their
project title and location, then allow the user to click on
a link to get the full profile of just one recipient. The
first list requires that the project title and location are
stored as separate "chunks" from the rest of the profile information,
enabling you to present that information in two separate views.
Step
8: Visual design
A
visual design should enable a greater comprehension of the
content and functional elements of your Web site. Graphic
design should not detract from the substance and navigation
of your site. Repeating the site navigation design graphics
and colors, along with major components of the page header
(organizational logo for instance) and footer (copyright,
contact and help links for instance) help visitors to focus
on the content while maintaining an understanding of how to
drive the site, and to where they have already driven.
Database
driven Web sites are desirable in large measure because they
use relatively few Web page templates to present a large amount
of content. Keep in mind that the more customized designs
planned for the site, the more Web pages will be created for
your site and the more complicated the content management
system becomes. Clearly define the design differences required
to house each type of content, as this will determine the
number of templates necessary to use on the site for displaying
database content.
Large
graphic files require users to wait longer for the content
to appear in the browser, animations and video files often
require many minutes before they can be viewed. As a general
rule, visitors will give up waiting for Web pages that require
more than three seconds to load. At seven seconds, the majority
of visitors will have left the site. Unless the content must
be represented as a large graphic or animation, keep all graphics
very small in file size.
Visual
cues can be used to inform visitors where they are located
within a site. A different icon used to represent different
section of a Web site is one example. Changing the color of
the link in the navigation that refers to the page the user
is viewing is another cue describing site location.
Implementation
and consultants
A comprehensive planning process should provide all the information
necessary for developing a complete Request for Proposal (RFP).
Skills, prices and experience vary widely in Web consulting,
so it is critical to shop around for the best match. A strong
RFP will mirror the information gleaned from the planning
process, and will specify in as much detail as possible the
content and functional requirements for the project.
The
RFP should also identify critical dates affecting the development
process. The RFP should lay out specifically the information
you need about the consultant. How long have they been in
business? How many staff do they have? What references can
they provide to similar projects? What technologies do they
recommend? How do they document their work, and do they provide
training and ongoing support? Will they give you access to
the code they generate? Do they recommend using ASP services?
Are they the primary contractors, or will they subcontract
out portions of your project?
A
strong consultant proposal will first answer every question
you asked. Attention to detail is a requirement for any database
project, and evidence of this lacking in the proposal is a
sign of more inattention to come in the database development.
An implementation plan should provide multiple points for
review of the system. The first point of review should be
agreement on the project specifications - this should occur
before a contract is signed. A proposal should also outline
a minimum of two testing periods, and two feedback opportunities
on the graphic design. A strong proposal will provide references
to projects that share similarities to the one you are developing.
The consultant should provide a detailed timeline and task
list for development, along with the roles and responsibilities
of your agency and their consultancy. Finally, a strong proposal
provides a detailed breakdown of costs, hourly rate, billing
procedures, policy for project changes, and a stable project
leader throughout the implementation.
Additional
information:
Web sites:
WebMonkey Information Architecture Tutorial
Web Site Planning by Terry Grunwald
List of CMS systems
and basic features
Another list, broken down into categories
CMS product reviews
Books:
Collaborative Web Development: Strategies and Best Practices
for Web Teams (Jessica Burdman, Boston: Addison-Wesley, 1999)
Information
Architecture for the World Wide Web (Louis Rosenfeld & Peter
Morville, Cambridge:O'Reilly, 1998)
CompuMentor
Technology Consultant Eric Leland has worked with nonprofit
advocacy organizations to develop their internet strategy
for more than eight years, and offers Web and database design
through his company Leland
Design. CompuMentor is a nonprofit providing community-based
organizations and schools with a range of technology assistance
services including consulting, deeply-discounted technology
products, and an online information resource.
Back to Top
|