LTGPublicWiki: Diff for "Frockle/FinalReport"

Final Report (Public)

Methodology

Following the project plan, we adopted an incremental and iterative approach to development. We produced an initial user interface within Bodington with place holders for the intended functionality. This was demonstrated to a small group of users to gauge requirements and initial response. We then enhanced the user interface and added further functionality, which we demonstrated to the WebLearn User Group.

Throughout the development process we used a standardised development environment consisting of Eclipse, Ant and SVN, in order to make development collaboration within the team and with external developers easier. We assessed the eProfile toolkit code, build process, repository and documentation on an ongoing basis and gave feedback to the original developers where appropriate. We also modified the Bodington installer as development progressed, in order to produce an easily deployable demo of the new functionality, including dummy data. We anticipated incorporating the code into the production VLE service progressively during the project.

Implementation

Initial work was to install and experiment with the eProfile toolkit components (which proved to be more time-consuming than we had planned for). We then looked at how the eProfile web service and TouchGraph applet could be incorporated into both Bodington and Sakai, and decided to mirror the class hierarchy of Sakai's existing profile tool, in order to ease later integration into Sakai. We developed the initial user interface in Bodington, following the Bodington community's decision to write all new tools using Spring MVC and JSPs instead of either of the Bodington custom templating schemes (thereby also improving the possibility of re-use).

We set up an SVN repository at the start of the project, and made use of SVN externals to pull the eProfile toolkit and Bodington (WebLearn) code in to the project, in order to ensure the code was up to date, and to avoid duplicating code held elsewhere. We produced Ant build files not only for the FROCKLE code, but also for the eProfile web service and eProfile applet, as well as JUnit tests for the eProfile web service, and contributed them along with any bugfixes and repository rationalisations we thought necessary. It became apparent that we'd like to make quite a few changes to the way the toolkit functioned, as well as needing a few modifications in order to make it suit our needs better, so, in agreement with the eProfile developers, gained additional funding and an extension from JISC in order for the eProfile developers to do the work. The additional work [1] included delivering the FOAF profiles from the web service in an XML format, allowing more FOAF fields in the profiles, some enhancements to the applet, and some suggestions for re-factoring. The additional work has been completed, and updated versions of the toolkit components will be integrated into the demo installation in due course.

Output and Results

Demo available at: http://flounder.oucs.ox.ac.uk:8080/frockle/

Download available at: http://downloads.oucs.ox.ac.uk/frockle/

FROCKLE repository:

https://svn.oucs.ox.ac.uk/projects/vle/frockle

eProfile repository (incl Frockle contributions):

svn://chimera70.essex.ac.uk/eProfileClient

svn://chimera70.essex.ac.uk/eProfileWebService

• Modified Bodington code, installer and Ant build file.
• Spring MVC based code and JSP pages suitable for re-use elsewhere.
• JUnit tests and Ant build files for eProfile toolkit.
• Contributions to eProfile SVN, and feedback to developers.
• Dissemination:

  • Demonstrated to users, WebLearn User Group.

  • Summary in Computing Services annual report.
  • Described in pre-conference seminar at Educause 2007.

Implications

• The software developed was not integrated into the production VLE service during the life of the project, due to time constraints and concerns about its maturity, but the work will be taken up again in the later stages of our migration of the institutional VLE from Bodington to Sakai.

Conclusions (optional)

• better not to try to produce outcome suitable for integration into production VLE service during project life, as time scales were too short, and it complicated development, would've been better to concentrate on a simple demonstrator to be enhanced after the project ended.
• would've been better to undertake a project where work was already underway, or there is an overlap with other work, as time scales are too short to go through full cycle of initial concept, execution
• applet not ideal, caused problems in some browsers
• FOAF not particularly widely used
• Uptake by users would probably be slow, as the potential benefits aren't clear.

Recommendations (optional)

[1] http://wiki.oucs.ox.ac.uk/ltg-public/Frockle/ToolkitEnhancementRequirements