= Persistent identity pilot discussion area =
Feel free to discuss ideas for this pilot in this space. These ideas can be formalised before moving them into the pilot template on the previous page - this discussion area is also the place to agree or disagree with peoples thoughts, but don't forget to add a reason as to why you agree or disagree!
[[BR]][[BR]]
Don't feel you have to stick to the titles below, let your imagination go wild...
[[BR]][[BR]]

 = Background = 
Prior to the Ithmus project TALL already had a number of issues that needed to be addressed regarding the following:
 * The way that the student community operates within the short course programme. 
 * Access to forum entries and material on courses students have studied previously
 * Access to blogs created whilst on other courses.
 * Student retention
At present the Conted 10 week courses are exactly that, the students are enrolled at the start of their 10 week course, along the way they create their own profile, take part in forum discussions, write a couple of assignments and add to their own blog. Towards the end of the course the students are asked to complete and evaluation. Once the course is completed the courses are archived to another site, the online course Moodle VLE is rebuilt. The term starts with new student accounts for everybody and the process begins again. The students don’t have access to the archived courses and if they don’t return to study a further course then we as a department loose contact with them.
Further the act of archiving, whilst vital, is a time consuming process for a resource that is kept for a year before being cleared.[br][br]
 = Objectives = 
The objectives of this part of the project are:
 * to consider how to give the students a persistent identity that can be used across courses across multiple terms.
 * To create a community of students who may or may not be actively studying an online short course at any one time – especially across holiday periods when the short courses are not running.
 * To give access to previous courses studied.
 * To give access to course studied such that they may be referenced to, from external sources, i.e. Facebook etc.
 * To allow tutors and staff who work on the development sites to have Single Sin On to all the sites involved with course development/production and the live sites.
 * To create the possibility of doing all of the above and keeping the expense within a reasonable boundary (if running all the above means that we have to cap the courses at a level below that which we could ordinarily handle then is it a financially viable model?)
Issues surrounding the objectives
Process and activities so far
Initial investigations
The idea of creating a student community with access to archived courses has been on “To do list” of the Systems Administrator for a longer time than the isthmus project has been running and as such a number of ideas have been considered.

Fairly early on it was apparent that the idea of creating a single Moodle site that will host the live courses and the archived ones plus an ever increasing number of students was dismissed as the menu system would soon become clogged with old courses when we were considering running 20 courses a term. This problem was magnified when we are considering upwards of 40 courses per term, quite simply nobody would be able to find a course. Further when we had to consider an upgrade of the Moodle software then it would be become extremely tricky as the more courses that are the site the longer it takes and the greater the risk of the move failing. 

Thereafter we started looking at an LDAP (Lightweight Directory Access Protocol) solution; we considered 2 slightly different ideas:

The first idea was to utilise the LDAP that Microsoft Active Directory uses. As we use MS AD in the department for controlling access to the facilities the staff use it wasn’t a great leap to see if this was viable. We soon established that the necessary info could be extracted and that the system should work OK. However the major snag was cost, having got ourselves to the point that we were using Open Source software to run our VLE (Ubuntu OS, Apache web server, MySQL database, PHP the scripting language and Moodle for the VLE) in order to save a large amount of budget by cutting software licensing fees to an absolute minimum, it made no sense to then stack our system against a Microsoft system that would then require licensing for all the Client Accessing Licences CALs. Therefore the idea was abandoned.

The other variation was to use OpenLDAP an open source offering that would do exactly the same as the MS AD but without the investment in CALs. A brief look at OpenLDAP did seem to indicate that it would solve our problem. The downside was that we would have to learn about the software and get ourselves up to speed before we could roll the program out. The major problem was that this probably wasn’t going to be straight forward moreover we would probably have to write scripts to run procedures to do the admin tasks, all of which necessitates the need for skilled personnel to be engaged in administering the system.

The OpenLDAP solution was being considered carefully and would probably have been investigated further if it hadn’t been for the fact that Version 1.8 of Moodle introduced Moodle networking. The idea being that as before one Moodle installation would hold the login accounts of all the users but the courses would be run on another Moodle site. This introduced the possibility of each term’s courses running on a new (up to date) installation of Moodle, and then at the end of the course the whole site is archived as it stands. This would mean that we didn’t have huge unwieldy sites that were difficult to upgrade, archived courses no longer had to be moved at the end of a course further we could operate the site where the logins were kept as a portal for the rest of our courses, meaning that we weren’t constrained by running all of courses on just 2 production sites. It also gave the benefit that it was reasonably straight forward for other members of the team to work with Moodle as opposed to a command line driven system.

= User case studies = 


 == First trial == 
Having come to the conclusion that Moodle networking was the best solution to the problem a test bench was created using 2 servers running Ubuntu 6.06 LTS, with all the other components necessary to make up a LAMP environment. Thereafter Version 1.8 of Moodle was installed on both servers and the networking element set up, such that users registered on one Moodle site (Identity Provider) and should be able to gain access to the course site on a different installation (Content Provider). However the connection could not be made, checking the Moodle Issue Tracker revealed a couple of critical issues with the networking element, this effectively blocked all progress.

We returned to Moodle Networking when version 1.8.3 was available. The old Moodle sites were cleared and the new version installed. As the Moodle network facility now appeared to be working after creating test users who could access test courses. Thereafter the TALL modifications were applied to both IP and CP without any problem. As there were no problems getting from IP to ‘courses’ setup on the CP, we moved o to the next part.

A number of courses were placed in the Content Provider (copied over from the development environment), after which access was granted on the CP giving permission to certain users to access the courses. On checking back in the IP it was found that the remote courses were linked to and the links worked automatically when traversing for the entry point on the IP to the course site.

Having managed to do this we were feeling confident to roll this out to our full short course programme. However it was around this time that we hit a major problem. On entering the site one day we found that all the courses had disappeared from view, on closer view it appeared that the sites had been removed from view from all including the Administrator, further investigation concluded that it was not clear how to return these courses to view. Probably the best conclusion if this had been a production site was to recover from a tape backup, however as this was a test site and the system was clearly unstable we refrained from running the pilot for the term starting in Jan 08.

The test environment has at March 08 been set up with Version 1.8.4 … no results at present.

 = Second trial = 
The second trial began in April using Moodle Version 1.8.4, this time instead of the whole short course programme we decided to run the pilot with 4 courses which equates to around 116 people with tutors included. Prior to starting adding students it was realised that we could not use the current system of allocating the login based on the users last name as we had no way of identifying whether a username had already been used and therefore had to consider a number based system that then could be stored on the student record system. Once the login process was resolved and the student began to be added it was found that the process coped much better with students who take more than one course per term, as we didn't have to hunt down accounts that had been refused due to duplication of login.

This time around the system has behaved as it should and there haven't been that many problems. The biggest problem is that users create bookmarks from the CP however when they come to login the system refuses access as they have to login via the IP, this has caused an amount of emails to IT support. However it was felt that with better documentation in the joining letter that the students read and a change to the CP front page we can get around these problems.

It has also been found that the students are very enthusiastic to know that the course will not 'disappear' at the end of the course and that they will be able to reread material and discussions again. At this stage it is not known if this translating into the better experience but there is less email being generated to IT Help about saving various parts of the course to offline use before the course closes.

It has been found that IT Support time has been greater than previous runs of the course as expected:

|| Course || Course run before trial || || The trial || ||
|| || No of Calls || Time taken to resolve || No of Calls || Time taken to resolve ||
|| Critical reading || 3 || 25 minutes || 37 || 310 minutes ||
|| Philosophy of Religion || 10 || 80 minutes || 18 || 125 minutes ||
|| Learning to Look at Modern Art || 7 || 50 minutes || 11 || 110 minutes ||
|| Contemporary British Fiction || 6 || 60 minutes || 11 || 85 minutes ||

It should be noted that Critical Reading was the first course to be launched and a couple of problems were found:

 * emails sent from the content provider, which caused a lot of students to try and login directly to the CP - we cured this by temporarily switching off email for remaining launches.
 * password changes - students tried and failed to change their passwords in the CP and failed - no cure or work around but better documentation for subsequent courses on the trial.
 * links to a secured reference site were not available in the CP - this was an oversight of not providing a the host with a new referrer URL - cured with temp access to another site that did have access.

Nearly all of these problems were resolved or had a work around by the time we came to launching the remaining courses, so hence there support time whilst more than the previous run on the old system was not so disparate as Critical Reading.

The archiving process was where we envisaged making a saving of time to off set the slightly greater set up time, and we saved 1/4 of an hour per course by not moving it to and archive site, so we saved and hour of time for the courses trialled. However, as stated these courses remained open after the courses finished, a look at the logs (08/09/08) for the pilot courses, at the students who went back after the course had closed to have a look around:

|| Course ||  Students starting the course || Students revisiting the site after the course closed ||
|| Critical Reading || 32 || 7 ||
|| Philosophy of Religion || 24 || 8 ||
|| Learning to Look at Modern Art || 18 || 5||
|| Contemporary British Fiction || 20 || 6 ||

During the next term we will look at the use of the archived sites and see if greater use is made of them by students who are studying another course.
 
 = What is next =
 == Michaelmas2008 == 
Having had a success with the second trial and realised that there is a potential for significant amounts of time to be saved, the next step is to roll out the persistent identity for the Michaelmas 2008 term. For this terms courses, improved documentation in the form of more detailed joining instructions, additions to the "Course Website Explored and Explained" document and a couple of forum postings will be made to help the students handle the slightly different environment and thereby result in less IT support time.

 == Hilary2008 ==
If the Michaelmas term runs OK then there will be need for a tool to help in the admin of enrolling students from the Portal site onto the specific courses in the CP.

 = Issues that need contemplation: = 
 * Blog entries appearing against the student for courses that are nothing to do with the present one.
 * How long do we retain ‘archived’ courses?
 * How long does a student retain an identity when they aren’t studying courses will the department, could they possibly pay to retain their identity if not on a course?
 * If a student violates the rules of engagement for a course do they forfeit the course or the course and their identity?
 * Will the enrolment at the start of the courses create an unsustainable amount of extra work sorting out of existing accounts and creating new where necessary?
 * How do we identify existing students when they book for courses?
 * Will the change of URL actually cure the problem of email emanating from our systems as spam?
 * Will the effective retention of the whole site mean that stats are retained?
 * For the pilot we will use 3 courses, the students who do more than one course means there is a good possibility that a student may well be doing a course delivered via V1.8 and portal.conted and one via V1.7 and online.conted. This also means that there is a ramification for next term as the student will only have the archive of one of the courses.
Ideas from CK
 * Where a student offends and is removed from a course? Swap them to read only mode (yellow card) thereafter red card and they are removed from the system.
 * Blog entries appearing against the student for courses that are nothing to do with the present one – How about folders or an archive within the blog system that allow previous blog entries for old courses to be self archived.
 * The idea of the community and how it all works needs to be explained carefully to the students possibly in a CWEE maybe as part of the joining instructions.
 * How long does a student retain an identity when they aren’t studying courses will the department, could they possibly pay to retain their identity if not on a course? Paying is probably a non- starter as the cost to the student would probably be swallowed by the admin process in sending out the reminder and processing the payment. Student studies short course in term 1 allow 2 & 3 off, Yellow card for term 4, removed (red card) prior to term 5.

[wiki:PersistentIdentity Return to Persistent identity template]