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, rather than duplicating code held elsewhere.

• Made use of SVN externals to pull toolkit code in from external SVN repository.
• modified demo data and tools created by installer for demo
• modified Ant build to include applet
• Contributing feedback/code/updates/maintenance to original developers throughout project, and ...
• During the development process we made contributions to the toolkit code in the SVN repository made available by the original developers (including modifications to the 3rd party applet code, cross platform browser issue, auto-login facility).
• Received additional funding from JISC to contract original toolkit developers to enhance toolkit for our use. (FOAF profile delivered in XML format, more fields from FOAF schema handled, username as ID instead of email address)

Output and Results

Demo available at: http://flounder.oucs.ox.ac.uk:8080/wl-addon/

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

SVN repositories:

• FROCKLE: https://svn.oucs.ox.ac.uk/projects/vle/frockle eProfile (incl Frockle contributions):

• 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, OUCS annual report, Educause talk

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.
• Updated versions of the toolkit components and enhancements produced through additional funding will be integrated into the demo installation in due course.

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)