News and activities

Whilst it was not fully appreciated at the time the project proposal was written, adopting WebPA as a case study is providing some interesting insights into the issues surrounding adapting existing learning applications to support LTI.  For a variety of reasons, the project has taken on the additional challenge of updating the WebPA source to make it more compatible with an LTI-compliant tool; for example (cf. posting on 2-Feb-11):

1. the user permission models adopted by WebPA and a typical VLE are different: WebPA assigns a single role to each user for access to all modules within the system, whilst a VLE can typically assign users a different role for each course/module.
2. the ownership rights model adopted by WebPA and a typical VLE are different: WebPA assigns ownership of assessments to the user who creates them, whilst a VLE would typically give all staff with access to the course/module access to all objects created within it.
3. the group assignment rules adopted by WebPA and a typical VLE are different: WebPA allows groups to comprise students from more than one module, whilst a VLE would typically restrict groups to members of a single course/module.

These are important issues when trying to add LTI support.

In my mind the most seamless way of integrating a learning application (such as WebPA) with a VLE is to use the VLE as the sole access point for content which relates to a course within the VLE.  To provide alternative routes into the application would mean that users can bypass the security checks applied by the VLE; for example, to check that the user is still enrolled in the course and retains the same role/privileges.  If the VLE is the only available route to the content, then each launch will confirm to the learning application the user's details, including their current role.  If they have not accessed the application before, their account can be safely created based on the data securely passed from the VLE; if this is a return visit their details (such as name and email address) can be updated to reflect any changes.

Having provided access to the external learning application via the LTI launch from within the VLE, it is important then for the learning application to appreciate that this "contract" from the VLE relates solely to the individual context from which the launch was made.  Thus, it should not be possible for a user to stray beyond the confines of the current context because their access permissions to other contexts may have changed within the VLE and this will only be known by the user launching the appropriate link within the VLE.  Restricting the freedom to access other contexts (e.g. modules) can be achieved in at least two different ways:

1. ensure the application itself removes access to options for changing the current context for users accessing via LTI;
2. create separate user identities for each context so, for example, an individual user would have a different user account in each context identified by a unique ID made up of a combination of both the user ID and the context ID, thereby meaning that each user account only has access to a single context anyway so there can be no way of changing

The current plans for WebPA are to adopt option 1 because there is an opportunity to adapt the application code to enforce this.  It also keeps the user database simpler and smaller.  However, adopting this approach also means that it should be possible to assign users a different role for each context (see 1. above).  At the same time the ownership of forms, groups and assessments is to be changed to the module (i.e. all staff/tutors with access to the module) rather than limiting access to the creator.  The issue of groups extending beyond the boundaries of a context has been opened up for discussion across the WebPA community to identify how much it is used; there are other potential ways of achieving the same end result, such as:

• creating a new module comprising the appropriate population of students;
• using LTI to "map" different contexts into a single destination.

This will be the topic of a future post.  In the meantime an updated version of WebPA has been made available to the community to test and provide feedback on.  Whilst making these changes, the opportunity was also taken to add new requested functionality for non-LTI access to the application, such as:

• ability to add new users and modules
• ability to delete existing users and modules
• separation admin and tutor user types
• assignment of limited admin privileges to tutors to manage users on, and generate reports for, their own modules
• separation of objects into module-specific areas with an option to change between modules (thereby allowing users to have different roles/options within each module)

Hopefully, the changes made to allow WebPA to support an LTI integration more easily will also have provided benefits to those continuing to use WebPA as a standalone application.  To comment on these changes to WebPA please either respond to this post and/or reply to the message circulated to the WebPA mailing list on 3 November.