NPT Mindmaps

An interactive mindmap is available for all to visualize a series of components of the future NPT. The mindmap mainly focuses on the requirements, and front/backend functionalities of the Toolkit. As usual, comments and feedback are more than welcome!

Requirement 15: Exploration of APIs

Availability of APIs and Web Services. The design and creation of Application Programming Interfaces (APIs) that expose NPT functions should be explored to allow third parties to use NPT functionalities. Web services should also be explored.

Requirement 14: Sustainability

Sustainability embedded at each stage of development.  The developers of the NPT should be mindful of the strategic implications of development choices to the long term sustainability of the NPT in a number of key areas: underlying hardware and software; development tools and frameworks; level of effort for system administrators and portal managers; level of interest and engagement of users, including researchers, data providers and other interested visitors.  

Requirement 13: Simplicity

Simple to maintain. Maintenance in terms of user interface configuration, user rights management, and data source(s) customisation should be done at the management level with visual tools. The installation, operation and maintenance at the system administrator level should be well documented and administrator manuals and guidelines should be carefully provided. 

Requirement 12: Discoverability

Discoverable through search engines. The NPT should have appropriate html metadata tags that allow the portal itself to be discovered through search engines. Those metatags should be populated with metadata that allow portals to be distinguished from each other, for example as they deal with distinct themes, regions, or countries. Metadata made available to search engines should aim primarily at making the data easily discoverable through e.g. Google. 

Requirement 11: Tracability

Capability to efficiently track portal usage and database content statistics. Both end-users and portal managers should be able to view statistics about the portal usage. Statistics can include number of hits, number of occurrences, number of new records monthly, number of queries, number of downloads, total number of downloaded records. In the case of data downloads, there should be brief metrics collected on how the data are used. 

Requirement 10: Community-driven

Community-driven. By including opportunities for user feedback, the system should evolve by iterations and respond to user (NPT manager and end-users) needs. User interactions can also happen by using stored queries. The implication of the community is a core requirement for the NPT, and the objective is to ensure that the tool has enough buy-in for it to be allowed to evolve in the future.

Requirement 9: Collaboration

Open collaborative development. The development of the application should be consistent with open source, allowing the core code and any modules developed to be improved over time. 

Requirement 8: Documented

Documentation and code maintenance. A clear and standard practice for the maintenance and documentation of code should be set in place, agreed and communicated as a best practice.  Any features developed outside the core of the NPT should follow that practice. Environments such as Google code should be used to support this collaboration. Where needed, other environments can be adopted to ensure all players have access. Regarding non visual tools, procedures and routines for installation, configuration and maintenance can be accepted if they are well documented and guidelines provided all the way down to the simpler operation. Upgrades should be made as simple as possible: the possibility to have them ran automatically should be examined.

Requirement 8: Friendliness

Intuitive and friendly end-user interface. The interface for end-users and to a lesser extent portal managers should be relatively intuitive and easy to use, without requiring extensive technical assistance, support or off line user guides. For portal managers, such guides may be needed to explore advanced functionalities, but those advanced functionalities should be as intuitive as possible.  

Requirement 7: Configurability

Configurable. The NPT should be configurable in terms of features, data sets, modules and be able to plug in various layout designs and on different CMS (Content Management Systems). In the beginning, the NPT should at least provide support for popular CMS, such as Drupal and/or Zope. It should include provisions to add other CMS support at a later stage of development.

Checkout the NPT mockups

Want to have an idea as to how the NPT user interface will look like? Take a sneak peak at the NPT mockups here!
Don't hesitate to comment, or send us your ideas!

Requirement 5: Extensibility

Extensible. The NPT development and implementation should follow design principles that will enable future growth, both in terms of the addition of new functionality or through modification of existing functionality. In addition, NPT developers should provide the possibility to consume services and functions that are created elsewhere. Examples might include taxonomic data sources or mapping functions or web map services. 

Requirement 6: Multilingual

Multilingual. The user interface at the front end should support multilingualism. At the backend, the primary interface language should be English. 

Requirement 4: Robustness

Robust. The NPT should be thoroughly tested to ensure robustness on three fronts: (1) the NPT should be able to cope (without crashing) with a wide range of stress situations, and it should perform reasonably under important workload (queries and data discovery). User experience, both front end and back end, should be as intuitive and friendly as possible; any errors should be trapped and not seen by users, but systematically addressed as priority requirements or issues; (2) it should also allow the management of dependencies on external services (for example, external data calls). 

Meet the NPT GoogleCode site

For those of you following the developments of the NPT project, a googlecode site is available. The website includes documentation, downloads, resources, a wiki, issue tracking and information about the NPT. In the near future, the site will give access to source code.

A concept for building the content of the NPT

NPT meets ViBRANT

Burke and Bruno recently met with the ViBRANT team (Vincent Smith and Simon Rycroft) at the NHM, in London. With GBIF’s involvement in ViBRANT project and NPT as a part of Work Package 8, the purpose of this trip was to discuss with ViBRANT team about the possible synergies between the ViBRANT developments (in the continuity of the Scratchpads project) and some of the components of the NPT. The idea was to explore the potential of certain Drupal components to serve as a basis for the NPT. It was found that most of the backend requirements identified by the Advisory Group were already available from the core Drupal components. It was also found that some Drupal modules seem to be fit for our use for the NPT. This approach might be fit for the development of the NPT, especially given the technical competences of some core developers, and the proof of concept of using a combined framework (Drupal + OpenGeo), as adopted for the new iOBIS (Ocean Biogeographic Information System) webportal.
The ViBRANT team has agreed to take part in the developments of the NPT.