⇤ ← Revision 1 as of 2007-11-07 12:09:07
Size: 206
Comment: Initial layout for final report
|
Size: 3221
Comment: Saved current state in case of browser falling over...
|
Deletions are marked like this. | Additions are marked like this. |
Line 5: | Line 5: |
'''Project plan:''' * Adopt an incremental and iterative approach to development * Produce mock-ups of user interfaces to aid requirements analysis. * Focus initially on simple software deliverables, with a view to future expansion '''Execution:''' * Standardised development environment (Eclipse, SVN) * Used prototypes of user interface which evolved as functionality was added/enabled. * Modified Bodington installer as features were added, in order to make deployment/demonstration simpler. * Made use of SVN externals to pull toolkit code in from external SVN repository. * Concentrated initially on development in Bodington, but based design on both Bodington and Sakai integration. * Developed code with intention of incorporating outcome into production VLE service. * Contributing feedback/code/updates/maintenance to original developers throughout project. |
|
Line 6: | Line 19: |
Initial work was to install and experiment with the EProfile toolkit components. We then looked at how the web service and applet could be incorporated into both Bodington and Sakai, and decided to model the implementation on Sakai's existing profile tool, in order to ease later integration into Sakai. An initial user interface was developed in 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. Spring MVC and JSP pages adopted Bodington policy to switch over to Spring MVC and JSP instead of the original custom template format. 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). Received additional funding from JISC to contract original toolkit developers to enhance toolkit for our use. |
|
Line 7: | Line 30: |
''Demo available at:'' http://flounder.oucs.ox.ac.uk:8080/wl-addon/ ''Code downloads available at:'' http://downloads.oucs.ox.ac.uk/frockle/ ''SVN repository:'' https://svn.oucs.ox.ac.uk/projects/vle/frockle * 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. |
|
Line 8: | Line 44: |
* Work will be taken up again in later stages of our migration of the institutional VLE from Bodington to Sakai |
|
Line 9: | Line 48: |
* 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. * 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. |
Final Report
Methodology
Project plan:
- Adopt an incremental and iterative approach to development
- Produce mock-ups of user interfaces to aid requirements analysis.
- Focus initially on simple software deliverables, with a view to future expansion
Execution:
- Standardised development environment (Eclipse, SVN)
- Used prototypes of user interface which evolved as functionality was added/enabled.
- Modified Bodington installer as features were added, in order to make deployment/demonstration simpler.
- Made use of SVN externals to pull toolkit code in from external SVN repository.
- Concentrated initially on development in Bodington, but based design on both Bodington and Sakai integration.
- Developed code with intention of incorporating outcome into production VLE service.
- Contributing feedback/code/updates/maintenance to original developers throughout project.
Implementation
Initial work was to install and experiment with the EProfile toolkit components. We then looked at how the web service and applet could be incorporated into both Bodington and Sakai, and decided to model the implementation on Sakai's existing profile tool, in order to ease later integration into Sakai. An initial user interface was developed in 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.
Spring MVC and JSP pages adopted Bodington policy to switch over to Spring MVC and JSP instead of the original custom template format.
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).
Received additional funding from JISC to contract original toolkit developers to enhance toolkit for our use.
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 repository: https://svn.oucs.ox.ac.uk/projects/vle/frockle
- 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.
Implications
- Work will be taken up again in later stages of our migration of the institutional VLE from Bodington to Sakai
Conclusions
- 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.
- 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.