Creating a framework for portals

Portals have become a vital tool for delivering information about a single subject or for a specific audience.

Developing a portal in the federal government context involves organizing often-disparate groups of people and technology to deliver a new capability to your customer base (usually the public).

The first step in developing a portal is to organize a team whose key role is to contribute and edit its overall content and structure. Teams usually include representatives from many agencies, so the portal becomes a mechanism for bringing together people to share ideas and practices. Portals will grow and change as the community grows and changes, so the work of developing a portal never truly "ends" in the classic sense.

Once the portal team is formed and regular meetings are planned, the next step is to write a charter that addresses the vision for the portal as well as its customers, stakeholders, partners and members. The charter also should address approval processes, content management, funding, project management, technology management and marketing management (or outreach). It also should identify key issues (such as privacy, security, cookies, etc.) and organizational matters.

Once the charter is in place, I recommend developing a taxonomy to help organize content. A taxonomy can serve as a tool for team members to begin developing the common themes in a portal and build a consensus regarding terminology. Each agency has its own language and culture, and even such standard terms as "agency" and "bureau" can have significantly different interpretations. Even more differences can occur regarding the content for the Web site.

The look and feel of a site can be a volatile issue, but some trends are surfacing to guide developers. For example, the design of FirstGov.gov is emerging as a sort of standard, and federal Web pages are becoming primarily text-based.

Because users often access information via dial-up modems, which can be quite slow, care should be taken when adding images to your Web pages. Pick a simple and compact logo that is quick to load. (Don't forget to trademark the logo, because they often develop significant economic value.) And a carefully chosen banner can provide an artful look without weighing down the loading time of the Web page.

When it comes to making content decisions, many policy issues intervene. These policy concerns include security, privacy, children's privacy and the Freedom of Information Act. The portal team shouldn't write a policy document, but I do recommend that the team make a list of key issues that content providers should be aware of.

The portal team must also address the practical matter of e-mail head-on. The potential to create an unsupportable environment in regard to e-mail interactions occurs early in the life of portals. It is not uncommon for electronic mailing lists to grow in size to 100,000 e-mail addresses.

I recommend limiting interaction until you can determine the size and scope of interest in the portal. Create a moderated list that people can join, but don't let them post to the mailing list. Use the list as a substitute for a "newsletter" and only send outgoing e-mail from the portal. If there are many subscribers, there probably won't be enough resources to respond individually to e-mails.

If it's important enough, request funding to support e-mail interactions. Planning figures of $5 to $15 per e-mail response are not unusual. This assumes the portal is structured to minimize e-mails through facilities such as search engines and indexes of frequently asked questions.

Kellett is founder of the federal Web Business Council, co-chairman of the Federal WebMasters Forum and director of GSA's Emerging IT Policies Division.