228 lines
17 KiB
Plaintext
228 lines
17 KiB
Plaintext
%META:TOPICINFO{author="RicardoPereira" date="1130858843" format="1.1" version="1.10"}%
|
|
%META:TOPICPARENT{name="CurrentWebsiteDocuments"}%
|
|
---+!! TDWG Website Requirements
|
|
|
|
%TOC%
|
|
|
|
---++ Introduction
|
|
|
|
This report provides requirements for an operational environment (called "The Website" in this report) for the development and communication of its standards.
|
|
|
|
Project scope and requirements are controlled by using the TAG.MoSCoW (Must, Should, Could, Won't) convention.
|
|
|
|
* _Please read TAG.HowToContribute for advice on how to provide constructive contributions. Feel free to add comments next to the appropriate requirement. Make sure you add your comments in italic, in a bullet item, sign and date it (just like this paragraph). The editor (Main.RicardoPereira) will address your comment and change text accordingly._
|
|
|
|
-- Main.RicardoPereira - 27 Oct 2005
|
|
|
|
---++ R1. Standards Requirements
|
|
|
|
---+++ R1.1. Comprehensive Standards Repository (Must)
|
|
|
|
The Website must serve and advertise its standards effectively. The Website must provide a comprehensive and up-to-date repository of TDWG standards. Users must be able to locate and download standard specifications easily, either by using regular website navigation or via search engines.
|
|
|
|
Standards have a better chance of being adopted if they are well advertised and accessible. Users will spend less time looking for standards if they are well organized and presented in a centralized repository.
|
|
|
|
---+++ R1.2. Standards Metadata (Must)
|
|
|
|
The website must provide accurate and up-to-date metadata record for each standard in the repository. Each metadata record should contain the standard name, version, publication date, type (such as Data Exchange, Controlled Vocabulary), editor (and contact information), current status, status change history, purpose, rationale, standard change history, previous versions, upcoming releases, relationship to other standards, reference implementations, and a list of projects and systems currently using the standard.
|
|
|
|
Team members carefully analyze several aspects of standards before adopting them, such as quality, level of maturity and deployment. Rich and updated metadata records that follow a standard profile facilitate the decision making process and thus are likely to increase adoption of standards.
|
|
|
|
Some standard metadata fields, such as name, document number, date, type, and editor, must not change in time (except in case of errors). Other fields, such as upcoming releases, related standards, relationships, reference implementations, and projects using the standard, must be updated regularly.
|
|
|
|
For requirements on the standards contents and formats, please refer to the companion document *"TDWG Standards Documentation and Software Requirements."*
|
|
|
|
---+++ R1.3. Configurable Standards Statuses and Types (Must)
|
|
|
|
Standards must have an associated status, which can change in time. The list of standards statuses shall be defined by the Process Subgroup. Statuses coincide with standard maturity levels present on the standards track. Adopted standards must take precedence over retired or superseded ones for presentation and accessibility purposes. The website should allow administrators to configure the list of standards types and statuses.
|
|
|
|
The status of a standard conveys its level of maturity and helps users to decide whether to adopt a standard or not. Over time, TDWG is likely to make adjustments to its standards development processes, thus imposing changes to the standard statuses. Similarly, new kinds of standards can be created, thus requiring the list of standard types to be extended.
|
|
|
|
---+++ R1.4. Relate Standards to Respective Subgroups (Must)
|
|
|
|
Standards must be easily related to the subgroup that produced it.
|
|
|
|
There is more information about a standard than that is found in its specification and metadata record. Additional contextual information can be gathered from the subgroup that produced it. Such information is helpful to users when deciding to adopt a standard or when they need to understand the reasoning behind a particular design decision.
|
|
|
|
---+++ R1.5. Stable Web Address for Standards (Should)
|
|
|
|
Standards specifications (downloadable file) and its information page should have stable web addresses regardless of changes in status to allow persistent references, book marking, and to preserve external linking. Each TDWG standard could be assigned a global unique identifier.
|
|
|
|
---++ R2. Subgroup Requirements
|
|
|
|
---+++ R2.1. Dedicated Area for Subgroups on Website (Must)
|
|
|
|
Each TDWG subgroup must have a dedicated area on the Website. This area must be easy to locate by users navigating through the website or coming from search engine results.
|
|
|
|
TDWG standards are developed in the context of subgroups. Gathering subgroup information into individual areas within the website improves subgroup operation and makes communication more effective.
|
|
|
|
---+++ R2.2. Subgroup Metadata (Must)
|
|
|
|
Subgroup areas must contain updated information about the group, such as purpose, scope, recent and upcoming events, activities, call for reviews, milestones, schedule, drafts, standards produced, related subgroups, documentation, other resources, list of members, convener, contact information, and instructions to participants (how to join, contribute, review drafts, for example).
|
|
|
|
Such information enables subgroup members and interested parties to identify subgroup status. Requiring subgroup information to conform to a fixed profile improves readability and makes it easier for existing users to locate relevant information, thus improving subgroup operation.
|
|
|
|
Subgroup conveners and secretaries are responsible for keeping subgroup progress and efficient operation. Therefore, the website should allow conveners and secretaries to edit information about their respective subgroups. It is in their best interest to keep subgroup information profile updated. If it is simple enough to use, the website can replace other non-standard means of communication convener use to publish news, advertise events and calls for review.
|
|
|
|
---+++ R2.3. Subgroup Statuses (Must)
|
|
|
|
Subgroups must be assigned statuses that classify them according to their level of activity and requirements in terms of progress, production and scheduling. Subgroup statuses can change in time. The currently defined subgroup statuses are three: Task Group, Interest Group, and Closed Group. More active groups must take precedence for presentation and accessibility purposes.
|
|
|
|
---+++ R2.4. Stable Web Addresses for Subgroup Areas (Should)
|
|
|
|
Subgroup home pages should have stable URLs regardless of possible changes in status (i.e. being retired) to allow book marking and to preserve external linking. Information about closed subgroups should be less prominent than active subgroups.
|
|
|
|
---++ R3. Subgroup Operation Requirements
|
|
|
|
---+++ R3.1. Flexible Document Development Tools for Subgroups (Must)
|
|
|
|
Standards are specifications – documents. The website must provide flexible tools to support collaborative and incremental development of documents.
|
|
|
|
---+++ R3.2. Documented Standards Development Process (Must)
|
|
|
|
TDWG website should support new standards development process by providing accessible on-line documentation and tutorials, and by automating repetitive steps in the process.
|
|
|
|
TDWG should provide guidelines and training materials for subgroup conveners and members. Guidelines should contain general recommendations on how to guide subgroup work, maintain openness, fairness, how to keep the subgroup progress, how to achieve and measure consensus while allowing for debate.
|
|
|
|
---+++ R3.3. Structured Review Process (Should)
|
|
|
|
TDWG should provide subgroups with effective on-line collaborative tools to assist with reviewing drafts and standards. Such tools will enable editors to break down the complexity of the documents being reviewed, guide reviewers through a structured review process, and facilitate synthesis of comments made into a refined draft. The tools should require contributors to author and comment drafts within a well defined time frame.
|
|
|
|
Current TDWG subgroups are not reviewing drafts. This appears to be because the work is not broken into manageable tasks.
|
|
|
|
---+++ R3.4. Defect Control (Should)
|
|
|
|
TDWG should provide simple mechanisms for users of standards to report problems and comments. Such valuable information should be incorporated into a subgroup's information system for subsequent evaluation.
|
|
|
|
---+++ R3.5. Traceability of Design Decisions (Should)
|
|
|
|
TDWG subgroups should document all changes in standards development and record the reasoning behind such changes.
|
|
|
|
Traceability prevents defects late in the development process and allows designers to trace the evolution from the original design requirements.
|
|
|
|
---++ R4. Website Design Requirements
|
|
|
|
---+++ R4.1. Ease of Use (Must)
|
|
|
|
The Website must be easy to use, intuitive, and therefore require a minimum effort to be learnt. Advanced computer users will benefit from ease of use and administration. Client-side requirements should be minimized, requiring only a moderately updated web browser.
|
|
|
|
---+++ R4.2. Ease of Maintenance (Must)
|
|
|
|
The Website must be able to be maintained with minimal administrative effort.
|
|
|
|
It is anticipated that TDWG resources may be limited. If so, any system developed to support TDWG activities must require minimal administrative effort to maintain effective functionality.
|
|
|
|
---+++ R4.3. Flexible Navigation (Must)
|
|
|
|
The website must allow administrators to change overall navigation structure with minimal effort. Administrators must be able to add pages to, remove pages from, and rename pages on the website through the administration user interface. Administrators must also be able to easily move an entire hierarchy of pages.
|
|
|
|
TDWG organizational structure and goals will change over time and so the navigation structure must be capable of change as well. Changes to website navigation might require changes to content to maintain consistency.
|
|
|
|
---+++ R4.4. Separation of Contents and Presentation (Must)
|
|
|
|
The Website graphical design should be decoupled from its contents. In other words, it should be easy to change the Website look without requiring rewriting of any content items. The Website should be driven by templates and style sheets.
|
|
|
|
Flexible navigation and separation of contents from presentation together allow the website to be completely rearranged to follow organizational changes without much effort.
|
|
|
|
---+++ R4.5. Efficient Communication (Must)
|
|
|
|
The website must provide communication facilities to boost member activity and to keep interested parties updated. The website must use a combination of "push" and "pull" technologies to achieve that goal.
|
|
|
|
As one TDWG member put it, people need to see action to take action. Push technologies must be used to notify members of relevant events and to request action. The notifications should target appropriate parties as much as possible to avoid disturbing other members. Members must be able to subscribe or unsubscribe for individual notification streams easily.
|
|
|
|
On the other hand, the website must be often updated to reflect latest news and developments regarding standards and subgroups activities.
|
|
|
|
---+++ R4.6. Cross-Browser Cross-Platform Compatibility (Must)
|
|
|
|
To reach a broader audience, the website must be rendered properly in wide range of browsers across several platforms, such as Windows, Mac, Linux, and other flavors of UNIX. List of compatible browsers should be presented on the website. Browser compatibility must be tested.
|
|
|
|
Slight differences in page rendering across browsers are allowed as long as they do not disrupt any website functions or disarrange its layout or graphical design.
|
|
|
|
---+++ R4.7. Search Engine Friendliness (Should)
|
|
|
|
Many users find a website for the first time through search engines such as Google and Yahoo.
|
|
|
|
Therefore, the website must be designed to optimize search engine indexing, to ensure good positions in search engine results.
|
|
|
|
---+++ R4.8. Fast to Load (Should)
|
|
|
|
Website pages should be fast to download and display. The time it takes to display a page includes both dynamic page rendering and download times. Download times are determined by the bandwidth available for both client and server, while page processing and rendering times depend on server performance, its load, and web application optimization.
|
|
|
|
Users are willing to wait for pages to load for a certain amount of time. After that they give up and go away. For that reason, web pages should take no more than 5 to 10 seconds to display, which would allow up to about 50KB to be downloaded in standard dial-up connections.
|
|
|
|
---+++ R4.9. Ability to Track Usage (Should)
|
|
|
|
The website must record usage and inform the user about it. The website must also describe how this information will be used (see requirement R5.1).
|
|
|
|
Analysis of detailed website usage information allows the discovery of usability problems and uncovers common usage pattern. Such information is fundamental subsidy to guide website enhancements.
|
|
|
|
---+++ R4.10. Compliance to Web Standards (Should)
|
|
|
|
The Website itself should also comply with web standards, such as W3C CSS, HTML, and accessibility standards.
|
|
|
|
Conformance to current web standards improves accessibility and user experience, reduces website development and maintenance costs, and maximizes compatibility with current and future web browsers.
|
|
|
|
---+++ R4.11. Content Migration (Must)
|
|
|
|
The creation of website content, especially standards specifications, is a significant investment and may be risked if the technology used to deliver the content fails or becomes obsolete.
|
|
|
|
The Website should provide mechanisms to support migration of contents to a new platform, in full, without loss of content or requiring rewriting of artifacts.
|
|
|
|
---+++ R4.12. Internationalization (Could)
|
|
|
|
English is the official language of TDWG website. However, the Website could be able to accept and present content in other languages as well.
|
|
|
|
---+++ R4.13. No Broken Links (Could)
|
|
|
|
The website should not contain any broken links. They could be detected by automated tools made available to website administrators.
|
|
|
|
Broken links are an annoyance to users. They reduce trust of user on the website and on the organization as a whole.
|
|
|
|
---+++ R4.14. Shared Maintenance
|
|
|
|
Different users should be responsible for maintaining specific pages on the Website. Subgroup conveners or secretaries should have appropriate privileges to update and modify content items on their own subgroup areas. Content managers should be able to modify web pages and post news items. Users responsible for organizing annual or subgroup meetings should have access to modify the respective website sections. Administrators should have control over the entire website.
|
|
|
|
Users and administrators should be able to manage the Website remotely.
|
|
|
|
Website administration should be redundant to avoid bottlenecks.
|
|
|
|
---+++ R4.15. Security (Must)
|
|
|
|
The Website must be immune to attack of malicious users and software. Administrators must have a clear strategy to keep themselves up-to-date with latest security threats and to address these threats properly.
|
|
|
|
Although TDWG may not present the profile of heavy targeted systems, there is enough malicious software on the Internet that can attack and bring down the website, disrupting members work and eroding users trust.
|
|
|
|
---+++ R4.16. Look and Feel (Should)
|
|
|
|
The website should look and feel good. Nice look and feel make users them wish to return to the website.
|
|
|
|
---++ R5. Content and Documentation Requirements
|
|
|
|
---+++ R5.1. Process Descriptions, Tutorials and Guidelines
|
|
|
|
The website should provide good quality documentation about its processes.
|
|
|
|
Having well documented processes speeds up standards development and other subgroup related operations. Members spend less time thinking about structure and more time writing content.
|
|
|
|
---+++ R5.2. Privacy Policy (Should)
|
|
|
|
The website should describe which user information is recorded and how that information is used. Users should be able to locate and read the privacy information page easily.
|
|
|
|
---+++ R5.3. "How to Use This Website" Page (Could)
|
|
|
|
The website could provide an overview on how it is organized to guide new users, i.e., provide a "how to use this website" page.
|
|
|
|
---+++ R5.4. Relationship with Other Standards Organizations (should)
|
|
|
|
The website should describe the relationship between TDWG and other standards organizations, such as GBIF, OGC, ISO, and CODATA.
|
|
|
|
---++ R6. Requirements Outside the Project Scope (Won't)
|
|
|
|
The following requirements are outside project scope, thus will not be addressed by the Website.
|
|
|
|
---+++ R6.1. Website Will Not Support Software Development (Won't)
|
|
|
|
The Website will not provide any tools for software development, such as version control, defect tracking system (except for standards specifications). There is a number of websites offering such services. TDWG will not be able to match their service quality and level of support and will not have enough resources to maintain such services.
|
|
|
|
-- Main.RicardoPereira - 1 Nov 2005
|