Your Online Presence > Strategy & Development

Planning a database driven website

By Eric Leyland, TechSoup

This article in collaboration with TechSoup provides some guidance on planning a database driven website.

For an introduction to database driven websites see the article Database driven websites - an introduction.

Introduction

The wider and deeper a voluntary organisation 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 Manager: 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 (projects, outreach, etc.) This team should include the organisation'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 organisation (often the office manager, administrative assistant or receptionist).

Often this team will include a 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 organisation?

Web projects may actually be a strategy for achieving only some of the goals derived from your agency's mission. For each website goal, identify the strategies used to achieve the goals, and where the website 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 website will provide, and these linkages provide 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 that have specifically developed web database projects of a similar scale of, as they will be able to provide the most constructive insight into your own organisation'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 website 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 favours a certain audience segment.

If you have not done so 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 website. 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 voluntary organisations. 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 has a fast (broadband) connection to the internet".

Develop a persona for other segments of your audience, and walk each persona through their experience visiting your website. 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 website. 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 website, 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, mailing lists, subscription pages, discussion forums, online donations, site personalisation, web content management, site keyword search boxes are all examples of functions that combine with your content and structure at various intersections.

For a database driven website, 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 organisation 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 functional or interactive elements into different clusters. Ask yourselves questions - Do we want to arrange content by issue, by intended audience, by author, by agency projects, or in multiple presentations?

Decisions on site structure form the basis for the navigation tool you will provide visitors to your website. 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 member organisations together with their project title and location, then allow the user to click on a link to get the full profile of just one member organisation. 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 website. Graphic design should not detract from the substance and navigation of your site. Repeating the site navigation design graphics and colours, along with major components of the page header (organisational 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 webites 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 customised 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 (software on your computer for viewing web pages), 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 appear. 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 website is one example. Changing the colour 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 requirements document and invitation to tender (ITT).

Skills, prices and experience vary widely in web consulting, so it is critical to shop around for the best match. A strong ITT 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 ITT should also identify critical dates affecting the development process. The ITT should lay out specifically the information you need about the consultant or web developer.

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? Are they the primary contractors, or will they subcontract out portions of your project? Do they recommend using an Application Services Provider? (a technology company that delivers web-based programs that provide specific functionality such as e-mail, calendar, file storage, etc. over the Internet.  For more information see the Knowledgebase article Application Service Providers).

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.

Conclusion

Database driven websites can really help to increase the opportunity for users to interact with your website and hence your organisation. Web databases can also provide powerful tools for helping to manage website content. There are many issues to consider so a systematic and thorough planning process will help you make the most of the advantages that a database driven website can provide.

Further Information

This article has focussed on planning a database driven site.

For more information on getting a website and content management systems see the Knowledgebase articles: 

• Database driven websites - an introduction,
• Web content management systems
  
• Web Monkey's Information Architecture Tutorial

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)
• The Elements of User Experiece (Jesse James Garret, New York: New Riders, 2003)