WP9 - Educational content reengineering

From KeyToNature
Jump to: navigation, search


  • To design a blue print for building quality biodiversity eLearning tools
  • To make biodiversity teaching and learning more user-friendly (beating the books!)
  • To reengineer existing educational contents, to develop learning products

The deliverable of the work package is:

  • D.9.1 Improved eLearning product demonstrator (month 36)

Several Key to Nature tools are being being developed on the IBIS-ID SourceForge repository:

Actions in next period (mo 18-24)


FLEX-based single access key player

Rationale: The eLearning portals require a player that can run inside their environment, embedded in other content (not opening in a separate page outside the eLearning navigation context). The design of the player must be neutral, or preferably adaptable to the design of the eLearning system (skinable).

Specifications: ETI and JKI to develop a FLEX Single-Access key player, capable of:

    • Running media-enhanced single-access keys in all variants (dichotomous, polytomous, with reticulation and backlinks) in a friendly user interface.
      • The user interface should follow existing Dryades or ETI concepts, showing one couplet (decision step) at a time.
      • Supported media should include still images and sound, optionally movies.
    • Data can be read from Linnaeus databases via web services or AMHPHP.
    • Data can be read from Wiki pages (if formatted using the template method).
    • (Where "data" is:
      • the basic structure of a single access key,
      • a list of taxa to filter a longer key into a shorter one
      • general configuration options like interface language settings.)

Tasks: Work to be distributed between JKI, ETI, and BIKAM, and UTCN

  • BIKAM creates php-based media file and wiki-template-to-xml adaptors (???)
  • UTCN creates basic read/write code to wiki (???)
  • ETI creates database adapter to Linnaeus database
  • JKI works on data structure (collaboration with Javier)
  • ETI and JKI jointly develop the core player, based on the existing prototype created and demonstrated by Edwin in Berlin.

Milestones: Demo version finished by End of June, final version finished by beginning of September. The second deadline is suggested by Bob Press. He is preparing a key to urban trees for which another project would need a finished player by September.

Design notes: The player should have an improved history features (steps so far) and markers on doubtful decisions (suggestions Sonia).

Outlook: while preliminarily using a simple taxon name list to filter large keys to smaller keys, in the future web services such as the UK postcode or dutch plant distribution database should be supported.

See the IBIS page for further information.

Single Access key editor (php/mysql)

Rationale: The ETI needs a tools to split their large database-driven identification tools into small custom keys. Based on the existing Oracle SQL code from FRIDA, an open-source database-php driven key editor and filter will be implemented.

Specifications: The editor should be based on a simple model, following the existing Dryades editor. It should incorporate the functionality to filter a large key based on a list of taxa into smaller keys. The filter should support both a positive ("only these taxa") as well as a negative ("all except") mode.

  • storage will be exclusively in database formats
  • will a player, for viewing and testing the edits be part of the development?
  • will there be any data exchange formats - which?
  • how will user-management (login, editing rights, ownership of keys) be integrated - external users, or self-developed user management?
  • will an deployment package (based on XAMP?) be part of the development?
  • How much documentation will accompany the development?

Milestones: TO BE DECIDED

Single Access key editor (FLEX)

Rationale: According to the working groups in London, the educators desire and easy-to-use and adaptable user interface for their keys (see report Veronica). While an editor and filter-by-taxa function is available for Dryades, less functionality is available for Wiki- and Linnaeus based keys. Implementing this functionality in FLEX would:

  • allow to harvest synergies by reusing components and data structures from the FLEX based player (testing a key is an essential element of any editor)
  • allow to concentrate on the difficult part - the user interface, while supporting various storage strategies, among which are:
    • file system based storage (plain text file, either SDD/xml or Wiki-template format)
    • Linnaeus database storage
    • Wiki-template based storage directly on the wiki.

The data adaptors to storage strategies can be estimated to account for less than 10 % of the total development effort (FLEX supports xml natively, and the wiki-template format can easily be converted into an xml-format).

Specifications: The editor should be based on a simple model, following the existing Dryades editor (but without the need for page-reload cycles). It should incorporate the functionality to filter a large key based on a list of taxa into smaller keys. The filter should support both a positive ("only these taxa") as well as a negative ("all except") mode.

Milestones: TO BE DECIDED

NOTE: ETI decided to develop this FLEX tool for their own Linnaeus III development alone, without support for the Wiki. The Wiki support must therefore be implemented independently.

In-Wiki player and editor

Most wiki-keys are presently available on the German national key to nature site: http://www.species-id.net/naturwiki/

For English-language examples see Wiki key examples.

The wiki keys can be used interactively through the use of javascript enhancements, see JKey (JKey Player, JKey Editor).

Dryades support for Wiki-generated keys

Rationale: To support a large community of educators (teachers in schools at different levels as well as universities) that desire to modify and adapt existing keys, we need a potentially self-governing platform able to support many users without unsupportable administration costs. The current Dryades/FRIDA-system scales to very large keys, but requires login and object administration for this. Wiki-based keys can be expected to support a much larger self-governing community. Keys modified directly on the Wiki need similar usability support as Dryades or ETI keys.

Step 1. Providing keys to Wiki users

  • A prototype of a Dryades to Wiki export format already exists, although without proper handling of images (linking instead of showing). This will be improved by making most images also available on the Wiki (Stefano in collaboration with Gregor)

Step 2. Providing school-relevant functionality to Wiki users (PDA and CD-ROM)

Whereas the FLEX single-access player would provide a player usable on the Wiki as well as against databases, support is lacking for:

  • Creating stand-alone CD-ROMs for school use without online connection
  • Adapting existing keys so they can be either dynamically used on mobile phones and PDAs, or downloaded and used on these platforms without connection charges.

Both functions can be achieved by adapting Dryades to read the data from Wiki-based single-access keys temporarily into the Dryades database and generating already fully functioning Dryades output.

In addition, this may provide the Dryades database-editor to edit Single-Access keys.

Milestones: Modified wiki-export format finished by XXXX, option made available in the user interface of Dryades (together with the SDD export). Prototype of CD-ROM and downloadable PDA generation finished by End of August (without automatic user management). Full version to be finished in next period.

ETI mobile key

Can the mobile key be deployed as a service according to the following


Milestones: TO BE DECIDED

Long Term goals