Differences between revisions 6 and 7
⇤ ← Revision 6 as of 2007-11-08 18:00:07 →
Size: 5032
Editor: ColinTatham
Comment: Fleshed out Implementation, added eProfile SVN URLs
← Revision 7 as of 2007-11-09 12:19:08 → ⇥
Size: 5653
Editor: ColinTatham
Comment: Added dissemination list, fleshed out Implications a bit
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
=== Final Report (Public) === === Final Report ===
Line 11: Line 11:
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). 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 also researched the possibility of using Ruby on Rails for prototyping, and RSF (a templating scheme based on JSF, in use in the Sakai community) but decided that there wasn't sufficient time in the project.
Line 13: Line 13:
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. We set up a publicly accessible 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, we 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.
Line 37: Line 37:
   *Demonstrated to users, WebLearn User Group.
   *Summary in Computing Services annual report.
   *Described in pre-conference seminar at Educause 2007.		    * Website: http://frockle.oucs.ox.ac.uk/
   * Wiki: http://wiki.oucs.ox.ac.uk/ltg-public/Frockle/
   * Blog: http://frockle.blogspot.com/
   * Demonstrated to users, WebLearn User Group.
   * Summary in Computing Services annual report.
   * Described in pre-conference seminar at Educause 2007.
Line 43: Line 46:
 * 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. All of the code produced is available in the FROCKLE and eProfile repositories. The Frockle repository does depend on the eProfile repository being available, so it is arguable that we should keep a local snapshot as a backup. 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 during the current migration of the institutional VLE from Bodington to Sakai.
Line 47: Line 50:
 * 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
Line 52: Line 53:
 * lots of interesting research
 * 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

Final Report

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 also researched the possibility of using Ruby on Rails for prototyping, and RSF (a templating scheme based on JSF, in use in the Sakai community) but decided that there wasn't sufficient time in the project.

We set up a publicly accessible 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, we 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

Implications

All of the code produced is available in the FROCKLE and eProfile repositories. The Frockle repository does depend on the eProfile repository being available, so it is arguable that we should keep a local snapshot as a backup. 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 during the current migration of the institutional VLE from Bodington to Sakai.

Conclusions (optional)

  • 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.
  • lots of interesting research
  • 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

Recommendations (optional)

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

LTGPublicWiki: Frockle/FinalReport (last edited 2013-05-20 11:29:48 by localhost)