Web Presence Requirements

From Filtered Push Wiki
Jump to: navigation, search


This page describes the essential requirements for the Filtered Push Web Presence. It uses the method of Gause & Weinberg (1989) to model the requirements in terms of the primary users of the Filtered Push web site, the main functions the web site should provide, and the attributes the site should exhibit.

Users

  • Collection managers – Manage specimens in natural history collections and related information. Will ask: What FP tools can I apply right now? When will more tools be available? What will these tools do for me? Why would I use them?
  • Data consumers – Researchers applying natural history data to taxonomic, ecological, and other scientific questions.
  • Technologists – Experts in information management problems and the technical approaches currently being applied to them, in the context of managing natural history collection information. Will ask: What use cases does FP address? What technologies does FP employ? What data standards does FP apply, favor, or propose?
  • Research organization administrators – Managers of related projects, funding agency program officers, and university administrators. Will ask: Who are the members of the FP project? How are they qualified? Do they have a solid track record? What is the nature of their funding? What other projects are they involved in? Is this project sustainable?
  • Members of the public – May have followed links from other projects such as eBird and EOL. Content for these users must not be overly technical or use much jargon.
  • FP project members – Individuals funded by Filtered Push and their direct collaborators. Use the web site for communicating with each other, and may update the outward-facing portions of the web site. All other users of the web site are considered visitors.

Functions

  • Summarize FP mission and technical approach. One or two paragraphs on the main page should provide a unified description of the project appropriate for all site visitors.
  • Position FP with respect to related projects. Enable visitors to answer questions such as, “How is FP different from project X?”
  • Report current status. Breaking news, latest project developments, and upcoming milestones should be immediately apparent.
  • Establish credentials. Site should identify the FP team members and highlight their experience and qualifications.
  • Credit contributions and funding, as well as related work, projects, and literature.
  • Distribute production-grade software and documentation.
  • Complement oral presentations and elevator pitches. Site should be the next stop for anyone who has heard a 15-second summary of FP. Conference attendees often refer to corresponding web sites while listening to presentations—the FP web site should enhance this experience.
  • Provide contact information for project personnel. Include a point of contact for site visitors who would like more information about FP and how to apply our technologies.

Attributes

  • Memorable. The URL for the main FP project page should be easy to remember and to enter directly into a web browser.
  • Branded. Page style, layout, and graphics should distinguish FP from closely (and distantly) related projects and activities (including ETaxonomy.org), and emphasize that all FP web pages belong to the same site.
  • Easily navigable. Information of interest to visitors should be accessible via easily found links on the main page. The full content of the web site should be semantically navigable via category hierarchies, property values, and queries.
  • Outward-facing. Content on main page and those pages directly linked from the main page should be targeted at visitors (non-project members). These pages should be professional in appearance, well-edited, and complete. Pages with incomplete content, works in progress, and content meant for internal use should be clearly designated as such and require following at least two links from the main page.
  • Open. Content should emphasize the open nature of the project. While not immediately visible from the main page, detailed project information should not be hidden.