← blogs.sussex.ac.uk

7.3.2011

Making Moodle a scaleable enterprise solution

An early task after installing Moodle is to integrate as much existing data held within an institution that would be helpful in the virtual learning environment (VLE) context.  Even though Sussex has had an institutional Moodle installation since 2006 there are still many possibilities for further integration.

Pre-existing Sussex systems

Sussex has a history of ORACLE development and the majority of business systems use a central ORACLE database.  In 2003 Sussex engaged in a major project exposing Sussex data through a password protected portal, or managed learning environment (MLE),  called Sussex Direct.  This included personal staff data, programme and course data and student data, including assessments and grades.  This system had been extremely popular with Sussex staff and students.

Nightly sync/enrolment process

In 2005 it was decided to move from a small-scale WebCT installation to an enterprise-wide Moodle installation for the 06/07 academic year.  This is called Study Direct. In 2005 we were awarded a JISC-funded grant to integrate our central administration database (DB) with Moodle.

One of the conditions of the funding was that we followed a standards-based approach to integration, hence we used the IMS Enterprise specification. An enrolment plugin-based on IMS Enterprise had recently been contributed to Moodle by a developer at UCL. It works by passing the data out of the central DB into an XML document of IMS Enterprise specification and reading this file into Moodle. It is a robust process and problems are easily traceable, and we are relatively happy with this solution.

Unfortunately since its introduction into Moodle core it has only been partially maintained and as a result at Sussex we configure and improve it for every Moodle upgrade we do.

All Sussex course modules have a Moodle site

Sussex course data is passed to Moodle and a site is automatically created for that site.  Before 2008 this was at the request of the tutor, however since 2008 a policy decision was made and all courses now have a Moodle site.

The data we pass includes course name, study level, academic year, department, learning objectives and the start date. These become non-editable fields in the Moodle site settings.  We decided early on to that a Moodle site should exist for the duration of a student’s study. For more information about this decision see blogs post on “maintaining sites for the students programme duration”. As a result the identifier passed to Moodle was the course code appended with the term and academic year.

Before 2008 Moodle sites were made available to the students through an interface in the MLE (Sussex Direct). This was so the central DB was updated with the Moodle course site state and links were established from other systems. Now this process is reversed and we make Moodle sites available to students in Moodle and concurrently update the central DB.

We currently do not pass the timetable or assessment data although we may do in future projects.

All Sussex users have a Moodle account

Sussex staff, students and associates who have a computer service account can log in to our Moodle installation through the LDAP authentication service, however this service passes limited user data to Moodle.  We therefore decided to pass all user data through our nightly sync. Data such as their name, username, person code, and email updates the user table.  Within the edit profile screen these fields become non-editable.  However, we have also created a local Sussex roles table into which we pass a person roles and the departments and schools for which they serve this role. For the student role we pass study levels, programmes, programme years and candidate number. The user searches have been customized to use the local Sussex roles table. It is also very useful when extracting data for Moodle use analysis.

A development for the Spring term will be to pass card photos to Moodle.  We will still allow staff and students to add a Moodle picture, but where one does not exist and they have allowed use of their card photo we will pass it. We will run a script every month to look for new Sussex account card photos. For more information see blog post on importing user profiles into Moodle.

We currently do not pass user assessment data back to the central server, but we may do in the future. Furthermore we would like to link closer with user assessment records held on the central server.

Course roles are synced with Moodle course site roles

The nightly sync manages course site roles and enrolments.  We decided not to use IMS-Enrolment standards to manage unenrolment, which specified that an unenrolled user would be of a specified status. It was easier to use a “snapshot unenrol” method which looked at all current members of site and compare that with the incoming membership.

Within the membership possibilities we have added a Colleague role to Moodle. This role permits read only access to a user.  Some departments have selected to give all faculty members a Colleague role on each others’ Moodle sites.

A development for the Spring term is to make it possible to sync a course’s teaching groups with a Moodle site. This will be a manual process.  For more information, see the Teaching groups imported into Moodle blog post.

Data in to Moodle

Comment Leave a comment Posted by Paolo Oprandi Posted in data integration, e-learning, enterprise integration, moodle development
Tagged , , ,


2.3.2011

Moodle Developments – Giving Moodle courses visual identities

Good web experiences usually implies one which is intuitive and visually appealing. This implies using visual identifiers in conjunction with texts, reducing the need to read in order to make meaning and navigate the site.

Off-the-shelf Moodle has no way of giving course sites a visual identity.  This means that list of sites such as a user would come to when they first login are text-based names.

At Sussex we felt it was important that editors had their ability to give their sites a visual identity, which would be displayed at the top of the page, in all course site lists and in search results. Visual identifiers can help a lot if your trying to scan through a long list of text. It can be quicker for users to instantly spot a familiar image, than a word.

Using the current functionality for adding images to user profiles and course groups we added the functionality for editors to upload images from either the settings page of a site, or the custom built quick editor toolbar (See the Quick editor tool bar post).

Since we put this live in January 2011 62 of the Spring term course sites (approximately 10% of Spring courses with a Moodle site) and a further 29 other sites have added a site image, and we are seeing bold and imaginative choices shown by editors in site images.

We think course images look quite nice, and adds character to sites. Sometimes, even in a VLE, a little bit eye-candy can be a good thing.

Comment Leave a comment Posted by Paolo Oprandi Posted in interface design, moodle development
Tagged ,


1.3.2011

Moodle history/extended memory issue – cache with $USER->display & course_display

The problem :

When a user in moodle chooses to view a single section of a site, they are shown the section as expected.

Moodle stores which section you are viewing, so that when you go to a resource or activity and then return to the site, you are still viewing the section you last looked at.

This can be useful for users within the context of a single session. However, we found that even if a user logs out, changes computer, or returns to a site after several days they are still shown the section they last looked at.

Imagine if once you loged in sites like amazon, ebay, facebook or youtube and went into a view, it showed you the content you last looked at. This never happens. So the fact that it happens in moodle is perhaps understandably confusing for our users.

Some of our students report they are unable to see resources tutors inform them have been added, beacause moodle is only showing them a single section of a site when they login in. Other report no longer being able to see resources they have previously accessed, simply because moodle is showing them only one section – the section in the course moodle remembers in the db from when they last visited the course.

Our solution :

The behaviour users expect is when they visit a site, to be shown the landing page of a course/site. We need to clear moodle’s ‘extended memory’ to achieve this.

Clearing this memory when a user logs out would seem to be the natural approach. Realistically most users do not press the logout button, but simply shut down or close the browser. Triggering events on browser close isn’t an easy task.

So we approached it by clearing this data on login, which achieves the same effect.

There are two separate places where moodle looks to see which section the user was previously viewing in a site.

  • In the database – table called prefix_course_display
  • In the $user->display cookie array, keyed by course id

Both of these needed to be cleared to give moodle a more standard web pattern of behaviour.

Our code :

In login/index.php

Moodle1.9

// clear data on users last section visited in sites / courses
if (record_exists('course_display', 'userid', $user->id) ) {
delete_records('course_display', 'userid', $user->id);
foreach($user->display as $key => $value) {
$user->display[$key] = '';
}
}

Moodle2

if ($DB->record_exists('course_display', array('userid'=> $user->id) ) ) {
$DB->delete_records('course_display', array('userid' => $user->id) );
foreach($user->display as $key => $value) {
$user->display[$key] = '';
}
}

This might not be the best or only solution, so we would be grateful to hear from others who found the same problem, and how they dealt with it.

Again – the very helpful DB layer 2.0 pages in moodle helped us upgrade our 1.9 code to moodle2.

We implemented this fix in Jan 2010, and so far have seen a complete drop in the number of users contacting support about not being able to see a resource or section.

Comment Leave a comment Posted by Posted in moodle development, moodle2, navigation
Tagged , , , ,


22.2.2011

Moodle Developments – Quick editor toolbar

In Moodle some of the things users need to quickly do can be buried in the middle of a form, without an obvious label.

In order to help out our staff and tutors we added a quick editor toobar which has the common settings that Moodle editors often need to change in their sites.  The toolbar is displayed to editors at the top of the page when editing is on.

The bar allows editors to quickly :

  • Make site available to students / make site unavailable to students
  • Increase the number of course sections
  • Add a course site image (local customisation)

Anecdotal evidence suggests the editor bar has been warmly welcomed by academics.

Comment Leave a comment (1) Posted by Paolo Oprandi Posted in interface design, moodle development
Tagged ,


10.2.2011

Looking for patterns in students’ use of Echo360 screencasts

As part of the Me2U project we are evaluating student use of the short screencasts that have been created by lecturers. Some of this information will come from student questionnaires and focus groups, but we can also look at the reports that Moodle creates when students view pages where the screencasts are held.

One of the great things about Moodle (and other virtual learning environments) is that they record which pages on a site students have visited and when they visited them. In the context of the Me2U project, this means we can get some idea of how students on the course are accessing the materials.

We have started looking at the usage statistics for some of the screencasts and thinking about the meaningful data we can extract (given the plethora of data that VLE reports produce, it’s tempting to analyse everything).

So far, we have looked at:

  • the proportion of students on the course who have viewed each screencast;
  • how these figures compare to other resources available on the course site (for example, PowerPoint slides, lecture notes);
  • the degree of overlap between those who have viewed screencasts and a similar resource that is available in another format (e.g. preparation material for practical ) – this could give us an insight into whether there are some students who prefer a more visual format;
  • the kinds of screencasts appear to be most popular with students.

We’ve only just started looking at these data on a small number of courses, so drawing any firm conclusions at this stage is tricky. However, usage stats show that students are looking at the screencasts, even when they are available in alternative formats. Also – and perhaps no great surprise – the screencasts that get the most views tend to be those that offer guidance and support on the assessment, e.g. advice on essays writing, pointers for mock tests.

So – we know students are looking at these resources – now we need to ascertain how useful they feel they are. I think screencasting offers real potential in terms of helping students’ understanding of assessment expectations and we’ll hopefully be able look at this in more detail through our other forms of data collection.

Comment Leave a comment (2) Posted by Posted in audio and video, e-learning, podcasts
Tagged , , ,


9.2.2011

Maintaining sites for the students’ programme duration

At Sussex we made a decision that Moodle sites which related to a Sussex course should be maintained for the duration of the students’ degree programme. This means for any particular course we have sites for every year it is run.

For example Sussex 3rd year students have Moodle sites for all the course modules they have taken, through the academic years 10/11, 09/10 and 08/09. They can return to their first year, and indeed any sites they have been enrolled on during their time at Sussex.

This has implications pedagogically, socially and technically.

Pedagogical implications

There are advantages for the students because they can access their previous year’s sites so for example they can return to their original lecture notes, the discussions they had and the feedback they got from formative online assessments such as quizzes.

Social implications

Often student contributions to Moodle activities are chatty and temporal in nature and it is not always useful or desirable to have them inscribed permanently in the online learning space. Keeping sites for the entire length of a student’s degree ingrains the idea of permanency of student contributions and might deter students from contributing.

Technical implications

Whist we have tentatively explored hosting different Moodle installations for different years we currently keep all sites on one Moodle installation, having decided it is better to have one code source and database to maintain. This effects the method by which we roll sites forward to new academic years, navigate Moodle sites and server disc space.

Rolling sites forward

At the start of each academic year courses have new empty Moodle sites created for them.  Often the tutors want to import the data from the previous year’s site. There are two Moodle features which help tutors do this: “import” and “backup and restore”.  Because import is simpler we encourage tutors to use this method. To support this we added a plugin which meant the “import” process brought across the site section summaries if one didn’t exist.

Navigating Moodle sites

Because we keep Moodle sites for three years or longer we have many sites available to our users. If sites are sorted alphabetically users have to sift through many old sites which they no longer regularly access. In order to combat this we have added an academic year field to the database that allows us to sort sites chronologically.

Server disc space

In general sites within a 1.9 Moodle installation have separate file stores. This means that files used in more than one site are stored separately. Often tutors might use the same files from year to year. This means that we have different files containing the same data for each instance of a site (08/09, 09/10, 10/11).  As a result we currently have in excess of 400GB of data. This is an issue for our infrastructure team and it also means that there is too much data for us to have an exact development replica of the live system.

Comment Leave a comment (5) Posted by Paolo Oprandi Posted in e-learning, enterprise integration, moodle development, navigation
Tagged , ,


8.2.2011

Importing user profile photos into Moodle

At Sussex we encourage the use of user profile images (avatars) in our Moodle installation because it provides a more personal learning experience, encourages interaction and improves usability of the system by having more graphic representations of data.

However many students and staff haven’t uploaded an avatar in Moodle. We have therefore initiated a Spring term project to import staff or student card photos from users web profiles, where they have permitted its use.

Current use of card photos

In Sussex’s Managed Learning Environment (MLE), Sussex Direct, you can select to show your staff or student card photo to everyone on the web. Staff can also upload an alternative photo. These options are respected within the MLE, the staff profile pages visible on the Sussex web pages, but they are not currently respected in our Moodle installation.

Development plan

In Moodle, Sussex’s Virtual Learning Environment (VLE), users can put up avatars of themselves. These avatars can be more casual than a card photo. We like this because it reflects the informal learning environment that the VLE can represent. However, where a staff or student hasn’t selected to put up an avatar we would like to use the card  photo where they have permitted everyone to see it.

A new picture_sussex database table

We created a new table in the Moodle database so

  • We have a record of all photos copied
  • If a copied photo is deleted in Moodle we don’t copy it again

The logic will work as follows:

For each current Moodle user without an avatar already and who has allowed use of their Sussex card photo we will:

  • Copy card photos from their unrestricted web address
  • Store them in a temporary directory
  • Process them for Moodle
  • Move them into the Moodle user directory
  • Update the “picture” field in their Moodle user record
  • Store a record that photo has been passed in a new table called “picture_sussex”

To prevent photos being copied again if a user deletes their copied card photo from Moodle, we record this within the new “picture_sussex” table.

If a user updates their Moodle picture and a record exists of the picture in the “picture_sussex” table the record will be deleted unless the “deleted time” field is set.

Exclusions

Because of the informal nature of Study Direct, we don’t want users avatars from Moodle passed back to the more official MLE.

There will be no facility for keeping availability flag in sync if permission settings are updated on Study Direct or Sussex Direct. The user can however delete the picture from Study Direct manually.

Comment Leave a comment (3) Posted by Paolo Oprandi Posted in e-learning, enterprise integration, moodle development
Tagged , , ,


4.2.2011

Moodle guest access

If you login as a guest on the Sussex Moodle, Study Direct,  you’ll see something very different from a standard Moodle install.

Guest users are presented with sites – by academic year – to which the creators have allowed guest access.

When Moodle became our institutional VLE a minority of staff had issues with users having to sign in to access their learning materials, in particular those member of staff with web pages who were used to distributing their course material through their web pages. These staff did not like the fact that their materials would now be behind a central password protected portal, even if they had the option to provide “guest access”.

The problem with standard guest access

In a default Moodle installation you need to find the links to the course site categories, then look for a small non-standard icon by the course which indicates it allows guest to enter. It can be a lot of clicks, and very difficult to explain to users.

In a Moodle install with as many sites as Sussex, it becomes a thankless endeavour.

Our solution

We made all sites which allow guest access visible from the first page a guest comes to, so they don’t have to root around the site categories pages looking for sites which might be available to them!

The code :

$courses = get_records_select("course","guest=1 && visible=1" , $courses_sort_query);

Our $courses variable is loaded with all the visible courses, with guest access set, then sorted in the same $courses_sort_query order as our logged in users see.

By doing this, we try and give guest users the same experience as our authenticated users.

You can login as a guest to Study Direct here.

Comment Leave a comment Posted by Paolo Oprandi Posted in interface design, moodle development
Tagged , , ,


2.2.2011

Teaching groups imported into Moodle

At Sussex our course modules may have a number of teaching activities, including :

  • seminars
  • tutorials
  • workshops
  • laboratory classes

Each of these might split a module cohort into groups. We call these teaching groups.

Like our course modules at Sussex, Moodle has a notion of groups and teaching groups which they call ‘groupings’.

Using these groupings in a VLE can help tutors target resources and activities at the relevant groups of students and our tutors have sometimes requested to use these real world groupings in their online sites.

A Spring term development at Sussex will be to implement a method to import these teaching groups from our courses into our Moodle sites. Because of its overheads, rather than automatically running it for every site, we leave it as a manual process which the tutor can perform on demand.

Whilst developing the teaching group import we also looked at and made some refinements to the Moodle group interface to help make it easier for our staff to use, and the language of groups and groupings clearer.

Simplified groups & supergroups interface

There are three use cases for a tutor using groups & supergroups.

1. No groups or supergroups exist

If no groups are set up tutor is taken to page which says so, clearly explaining how groups can be used and benefit the site, and tells user what to do next if they want to use groups.

2. Import/Create groups and supergroups

A Tutor has the ability to import teaching groups if they exist, create groups, auto-create groups and create groupings which we have called “supergroups”. The interface is improved and options are accompanied with a brief none-technical description.

3. Managing groups and supergroups

If groups are already set up user is taken to overview page where management of groups is possible.  The management options are dependent on whether the grouping (supergroup) has been imported from a teaching group or created manually.

Reduced complexity

By knowing the current site groups ‘state’ (e.g. groups exists, groups don’t exist) we are able to show the user the appropriate information without them having to search the different tabs/options. Almost all tasks can be carried out in one place without having to switch between different tabs.

Clarity

After interviews with staff, re-labelling groupings as supergroup was suggested as a way of re-enforcing the hierarchy which exists between groups and groupings. The notion of groups and supergoups is not a simple one for most users to understand. By clearly showing the structure/hierarchy (Supergroup > groups > user) on one main landing page we hope to make this more obvious to our tutors.

Integration into Moodle 2

This development has been developed and tested in Moodle 1.9, but our evaluation of Moodle 2 show that the interface pattern could equally benefit tutors using groups in Moodle 2.

Comment Leave a comment (2) Posted by Paolo Oprandi Posted in data integration, interface design, moodle development, moodle2, moodle2 evaluation & integration
Tagged , , , ,


1.2.2011

Things we love about moodle2 pt3 – section name

Edit the summary of any section in moodle2 and you’ll see a new field – Section name.

This is another step in bringing moodle into line with other content management systems, and we like it.

The section name text box isn’t WYSIWYG – so it’s less confusing and will inherit any stylesheet – also its just the right size to encourage users to enter a short, descriptive and meaningful name as a navigation element.

So, why is this important?

At Sussex we encourage our content creators to build a rich user experience for their students. We encourage teachers to add contextual information (using labels) videos and images to each section. Each section,week or topic in moodle becomes more than just a list of links.

Interviews with students and statistical data on site use, seems to support the theory that students find this enjoyable and engaging, and our tutors often take a pride in the experience they can create online for students.

With tutors spending time creating supportive text, images and contextualising the resources/activities in a section it’s important students see this, and don’t just go straight to a resource/activity without seeing the context.

For our VLE in Sussex enabling navigation to resources/activities without any contextual information the tutor intended when designing the course could be considered detrimental to the learning environment. Tutors and users rely on navigating to sections, rather than a list of uncontextualised links.

For our VLE it’s really important for us to create navigation which allows a user to visit site sections, as the course designer intended. By default moodle (1.9 or 2) does not support this kind of navigation with links to sections (moodle2), or meaningful section titles for users (moodle 1.9 section links block).

The new field – section name – could easily enable tutors to create meaningful navigation to sections in their site.

Mock section names for a site/course – moodle1.9

Within our current install (moodle1.9) users are able to navigate to any section in a site (in Sussex each moodle course is called a site).We use the the YUI menu block to generate a site menu. This is generally displayed in every site, as the first block on the left hand side.

The block itself grabs the first 19 characters from the section summary, and uses that text (stripping any HTML) as the section names. Users can configure the amount of characters to use from the summary for longer titles, but unfortunately that is a complex idea for a user to understand, and can lead to section names not being as useful as they might be.

When used well – it’s a powerful and essential usability navigation element, but (due to its complexity for the user) in the majority of cases its not deployed in an optimal way.

Getting the section names for a site/course in moodle2

Moodle2’s addition of a Section name gets rid of the need for the complexity to the user of the YUI menu block. Instead users have a very clear, simple field which will be their section name, and we like this.

We plunged straight into writing our first block in moodle2.0 by trying to create a site navigation menu – using the section names.


$course_sections = $DB->get_records("course_sections", array('course' => $COURSE->id));
foreach ($course_sections as $section) {
$section_name = $section->name;
$visible = $section->visible;
if(!$section_name) {
$section_name = "section ".$section->section;
}
$section_link = $CFG->wwwroot/course/view.php?id=$COURSE->id&$course_format=$section->section;

You’ll notice the new $DB layer format for get_record, and the new array key => value query, but apart from that the code should be pretty familiar to most moodle developers, and if you need a hand the DB layer 2.0 docs are a good starting point.

Here as a screenshot of our UX Nav block in action on a moodle2 site – with some Section names added, and others using the default name.

There are currently no plans to release this as a moodle2 block, but hopefully the code above can help you make your own quite quickly if its something you think user experience on  your moodle2 install will be improved by.

Comment Leave a comment Posted by Posted in moodle2, moodle2 evaluation & integration, navigation
Tagged , , , ,