Lecture capture – doing it well and at scale

A couple of weeks ago, QMUL hosted a a one day event, Lecture capture – doing it well and at scale, run by the Association of Learning Technology (ALT).  Unfortunately, I was unable to attend, but through a combination of watching the #altlc tag on Twitter, and the odd live stream via Adobe Connect (thanks to Matt Lingard and Eoin McDonnell), I was able to catch much of the day remotely.

As such, and rather than doing a detailed run though of all the sessions I attended over the course of the day (as I’d do normally), I’ve instead decided to think of the day more and five Take Home Messages (THM) related to:

1. How I might enhance my own practice going forward, with particular reference to supporting academics in supporting the student learning experience.
2. How I might work to enhance of the practice of those academics, and users of our Panopto lecture capture platform at the University of Bath.

Any text in italics below are my thoughts on the thoughts put forward by the speakers.

THM #1 – Kris Roger, London School of Economics

There is a feeling that lecture capture is beginning to form an expected part of the student learning experience. To counter this however, there is a worry that students are becoming over reliant on recordings, with a feeling from lecturers that they are spoon feeding content to learners. How might we mitigate against this? Can or should lecturers be persuaded only to release selected portions of their lecture rather than all of it?

Research also shows that some lecturers feel under pressure to record. Is this departmental or institutional pressure? What are the implications if a member of staff refuses to be recorded?

THM #2 – Neil Berry, University of Liverpool

Lecture capture should not mean lecture replacement. The idea should be provide the recording a supplementary resource to the “traditional lecture” to aid learning. Any students missing the face-to-face session will miss out on the opportunity for interaction and feedback.

Students learn in different ways, and the use of technologies such as these, are likely to lead to maximising the potential of student engagement. Students who have revisited a portion of the lecture are doing so for the following reasons: “found challenging”, “lecturer going to quickly” and “further annotate notes”.

THM #3 – Juliet Hinrichsen and Amanda Hardy, University of Coventry

“People approach lecture capture support based on their own interests”. The JISC funded ELTAC project, based at the University of Coventry, has developed and made available a number of interesting and innovative resources to support lecture capture. These can be found at http://cuba.coventry.ac.uk/lecturecapture/ and could be used to good effect for any related staff development related activities that I lead on.

THM #4 – Clive Young, UCL and John Conway, Imperial College London

Everyone needs to understand the pedagogical side of lecture capture. This helps to justify the existence of the service to relevant stakeholders.

That includes managers and support staff, Teachers, Students as well as Learning Technologist. At the University of Bath, our 5 Reasons to Capture Your Lecture document has, without a doubt, captured the imagination. Further work developing this strand over the course of the next academic year. 

THM #5 – Graham McElearney, University of Sheffield

Copyright and IPR related issues in the lecture capture sphere are confusing. There simply isn’t a one statement covers all recordings-type sentence. There seem to be caveats, caveats and more caveats related to this.

The JISC Legal Recording Lectures: Legal Considerations document goes some way to addressing the common issues, but isn’t aimed at end users. Perhaps, something needs to be worked on here. A short one page document aimed at practitioners?!

Thanks to all those involved with organising and hosting the event!

Writing Frequently Asked Questions (FAQs)

I’m currently in the middle of writing a number of staff facing Frequently Asked Quesstions (FAQs) to support some work integrating Moodle with Turnitin.

The process of developing clear and consise instructions for end users took me back to some thoughts I drafted some time ago related to good practice for writing FAQs. This advice follows below.

Background

An FAQ is essentially a Frequently Asked Question.”FAQs are organized “collections” of valuable information that usually comes from questions (and their corresponding answers) for the most common issues raised by users, on various topics.” [1]

Since mid-2008, the e-Learning team at the University of Bath has successfully utilised the open source application phpMyFAQ to power its Moodle FAQ database. With tens of thousands of FAQs views so far, it has proved to be a useful resource, not only for staff and students but for the wider Moodle community.

In light of this success, the e-Learning team are launching a new FAQ database focused on a range of complementing learning technologies during early 2010.

Tips for writing FAQs

• Write from the point of view of the person reading the FAQ. What do they need to know to complete a given task, and why?
• Less is more: don’t use twenty words, when five will do. Be concise in your explanations.
• If your text explanation is lengthy, break it up into paragraphs. Use section headings if they make the content easier to break down.
• Bulleted or numbered lists always make instructions easier to follow. If appropriate, divide these lists up into small lists as illustrated at: http://go.bath.ac.uk/hvx2. Within lists, you may wish to embolded key terms (e.g. the text of buttons or links)
• If possible, avoid using screenshots as these often have to be updated when the application software is upgraded. Instead, use directions instructions – for example, “click on the Turn Editing On button near to the top right hand corner of the page”.

More information

Further details on writing a good FAQ can be found at: http://www.avangate.com/articles/writing-faq_89.htm

Making Choices: Moodle-Turnitin integration

Over the last couple of months, my colleagues and I in the e-Learning team at the University of Bath have been considering the merits of integrating Moodle with Turnitin, the plagiarism detection service.

We’re currently supporting a variant of Moodle 1.9, though any decisions made would need to also consider Moodle 2.0 (or 2.1, 2.2…) which we’ll most likely be moving to in summer 2012.

Our Moodle-Turnitin integration was first mooted for investigation within the Moodle Development Plan 2010 that I developed in January of that year, but due to to technical difficulties at the time, we temporarily abandoned the idea.

One year on, online submission of work using the Moodle Assignment activity continues to rise. Additionally, and in light of a review tothe QA Statement for Examination and Assessment Offences, it was timely to review the integration, with a view to having something in place by the beginning of the 2011/12 academic year.

I’m currently in the throws of testing our chosen integration, but whilst waiting for things to happen in the background, I thought that I would take a few moments to reflect on our evaluation process and the decisions taken.

After some initial investigation, it was clear that two competing integrations, both with the respective pros and cons, would need to be considered before a decision was made as to which one to go for.

First up was the Catalyst integration aka ”Dan Marsden’s code”. Further information on this particular integration can be found at: http://drgn.in/k5fYrQ

This integration has the key advantage of being integrated with the existing Moodle Assignment activity in Moodle 1.9.  Importantly, this integration works  with Moodle 2.0 core code and takes advantage of the new Plagiarism API.

Whilst this integration does not currently include an interface for GradeMark, Turnitin’s e-feedback software, hooks into this functionality are planned for the Moodle 2.0 version.

If enabled (see options below), any supported file (the two popular file types, .doc and .pdf, are supported) submitted to the Assignment activity is automatically submitted to Turnitin whenever a side-wide cron job is called or is run.

The Turnitin related options within the Assignment activity.

The similarity score is returned when the cron job runs again, but this can be delayed depending on how busy the Turnitin server is. The similarity score and report can then be made available to the student, who can then review their performance but clicking on the relevant Similarity link.

Teachers can access the Turnitin originality report by clicking on the 'Similiarity' link, as illustrated above. The student view is similar.

One of the real advantage of this integration type was that it existing within a Moodle activity that academics at the University of Bath  are already very familiar with. Deployment would not require a massive support overhead, with a few FAQs and possibly a How To Guide being written to guide colleagues through the process of creation of a Turnitin enabled assignment activity. (Of course, the wider issue about how to get staff and students to interpret similarity scores in an appropriate way needs to be addressed elsewhere.)

The other integration that we considered was the iParadigms / Moodle Direct Integration aka “the one by nLearning Ltd.” (official Turnitin integration). According to the Turnitin website, this integration “allows access to Turnitin OriginalityCheck and GradeMark (not PeerMark) without having to leave the Moodle environment or log into Turnitin directly”. Further information can be found at: http://drgn.in/k63qKR.

The main difference between this integration, and the one discussed above, is that this is a new and distinct Moodle Assignment type with a different submission handling process to the usual Moodle Assignment activity one.

It is clear that the workflows employed by the iParadigms integration is markedly different from other Moodle activities – one of the hallmarks of some third party integrations, unfortunately. It was clear that this approach would require far more support than the Catalyst integration discussed above.

Given these two options, it was important that we conducted a side-by-side comparison of the two integration – available on request. The key emergent themes were as follows:

• The Catalyst integration was considered to be more usable and ‘Moodle like’ in this embryonic stage of Turnitin uptake. It would provide a low level entry point and would in turn encourage uptake.
• As such, the inability to integrate with GradeMark at this stage would not be a “deal breaker” as internal assessment processes would need to be amended to reflect this alternative method of marking.
• It was felt that use of the iParadigms integration type and its associated new/complicated workflow processes, might in fact inhibit uptake of Moodle to support online submission of work.

(Reference: Moodle/Turnitin Integration report by Lisa McIver, Moodle Operations Manager)

Whilst the Catalyst integration fast became the preferred option of the e-Learning team, we were keen to get some feedback from our academic colleagues in departments. Whilst some new items came to light during this meeting, their thoughts broadly supported our own internal evaluation.

So, that just about tells the story of where we are now! Should you have any thoughts or questions, do get in touch through the contact details provided elsewhere. Onward with testing…