Skip to content

good practice and innovation
about us infoKits Tools & Techniques Publications Events
You are here: Home » Case Studies » e-Portfolios Case Studies » e-Portfolio Case Study - myWORLD » myWORLD Case Study: Technology Used

e-Portfolios

Technology Used

What technologies and/or e-tools were available to you or did you seek to develop?

The main aim of the PETAL 2 and myWORLD project was to develop, test and evaluate the use of the Open Source OSPI e-portfolio in range of post compulsory education settings by building on the work of PETAL 1.

In terms of the methodology, the software development followed an iterative developmental cycle:

  1. take the current OSP tools, make a local instance
  2. trial with users/requirements gathering
  3. update and refine based on initial user experience
  4. install updated software
  5. re-trial and re-gather new requirements

PETAL 1 went through three iterations of the cycle with OSPv1.5, adapting the tool to serve the need of ALT's Certified Member of ALT scheme (CMALT).

myWORLD went through two iterations with a larger trial base.

  1. Case Study leaders were provided with a "vanilla" OSPv1.5 based on the PETAL 1 project software
  2. Case study leaders were to evaluate and gather localisation requirements to adapt the database to the needs of their particular learning situation
  3. Localisation of the User Interface (UI) and hierarchy
  4. Use with trial groups and gathering further requirements
  5. Revision of UI and development of output templates
  6. The continuation project developed and tested PETAL 2 based on the OSP 2.x version

Case study leaders were asked to develop a hierarchy for the local implementation of the software. This revealed a number of difficulties which underlay the OSP tools including issues with changing the data structure. Another problem was that, although the OSP e-portfolio tool was supposedly generic, it became clear that the taxonomy had a very US, undergraduate focus. In addition, the data hierarchy could only be edited by an administrative user giving it an institutional rather than learner focus. Hosting multiple instances proved difficult and substantial input from developers was required to resolve this. Generally the set up was not as easy as hoped and required advanced system administration and web deployment skills.

There were also version application issues based on functionality (e.g. customizing the hierarchy) and pedagogical assumptions (lack of adaptability to apply to different educational contexts). Although some of these were resolved in later releases of the software, significant issues remained.


Bookmark and Share
If you can read this text, it means you are not experiencing the Plone design at its best. Plone makes heavy use of CSS, which means it is accessible to any internet browser, but the design needs a standards-compliant browser to look like we intended it. Just so you know ;)