inner geek Education your technology Career Business About Us
 
Update your knowledge and master your skills
 
Geek of the Week
Community
About GirlGeeks
 
 

Search Keywords

 

Subscribe!
Enter your email to join GirlGeeks today!

HTML
Text
AOL



DownloadPlayer


Planning a Database Driven Web site

  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

 
 
 
 
 


Home|About Girlgeeks|Contact Us

GirlGeeks.org: All Rights Reserved.
GirlGeeks is a registered trademark; any unauthorized use is prohibited.