OU blog

Personal Blogs

Christopher Douce

MOOCs - What the research says

Visible to anyone in the world
Edited by Christopher Douce, Friday, 3 Jan 2014, 10:23

On 29 November 2013 I bailed out of the office and went to an event a place called  the London Knowledge Lab to attend a dissemination event about MOOCs.  Just in case you’re not familiar with the term, a MOOC (Wikipedia) is an abbreviation for Massively Open On-line Courses. The London Knowledge Lab was a place that I had visited a few years ago to attend an event about e-assessment (blog post).

This post is a quick, overdue, summary of the event.  For those who are interested, the London Knowledge Lab has provided a link to a number of pages (Institute of Education) that summarises some of the presentations in a lot more detail.  

Introductions

The event started with a brief presentation by Diana Laurillard, entitled The future potential of the MOOC.  During Diana’s presentation, I noted down a number of points that jumped out at me.

An important question to ask is what problems is a MOOC going to solve?  Diana mentioned a UNESCO goal (UNESCO website) that states that every child should have access to compulsory education by 2015.  It’s also important to note that there is an increasing demand for higher education but in the sector, the current model is that there is 1 member of staff for every 25 students.  If the objective is to reach as many people as possible, we’re immediately faced with some fundamental challenges. One thought is that perhaps MOOCs might be able to help with the demand for education.

But why should an institution create a MOOC in the first place?  There are a number of reasons.  Firstly, a MOOC offers a taster of what you might expect as a particular course of study, it has the potential to enhance or sustain the reputation of an institution that provides (or supports) a MOOC, offers an opportunity to carry out research and development within the intersection between information technology and education.  One of the fundamental challenges include how to best create a sustainable business model.

A point to bear in mind is that there hasn’t (yet) been a lot of research about MOOCs.   Some MOOCs clearly attract a certain demographic, i.e. professionals who already have degrees; this was a point that was echoed a number of times throughout the day.

Presentations

The first presentation of the day was by Martin Hawksey who talked about a MOOC ran by the Association of Learning Technology (ALT website).  I made a note that it adopting a ‘connectivist’ model (but I’m not quite sure I know what this means), but it was clear that different types of technology were used within this MOOC, such as something called FeedWordPress (which appears to be a content aggregator).

Yishay Mor, from the Open University Institute of Educational Technology spoke about a MOOC that was all about learning design.  I’ve made a note that his MOOC adopted a constructionist (Wikipedia) approach.  This MOOC used a Google site as a spine for the course, and also use an OU developed tool called CloudWorks (OU website) to facilitate discussions.

Yishay’s tips about what not to do include: don’t use homebrew technology (since scaling is iimportant), don’t assume that classroom experiences work on a MOOC, from the facilitators perspective the amount of interactions can be overwhelming.  An important note is that scaling might mean (in some instances), moving from a mechanical system to a dynamic system.

The third presentation of the day was by Mike Sharples who was also from the Open University.   Mike also works as an academic lead for FutureLearn, a UK based MOOC that was set up as a partnership between the Open University and other institutions.  At the time of his presentation, FutureLearn had approximately 50 courses (or MOOCs?) running.

I’ve noted that the pedagogy is described as ‘a social approach to online learning’ and Mike mentioned the term social constructivism.  I’ve also made a note that Laurillard’s conversational framework was mentioned, and ‘tight cycles’ of feedback are offered.  Other phrases used to describe the FutureLearn approach include vicarious learning, conversational learning and orchestrated collaboration. 

In terms of technology, Moodle was not used due to the sheer number of potential users.  The architecture of Moodle, it was argued, just wouldn’t be able to cope or scale.  Another interesting point was that the software platform was developed using an agile process and has been designed for desktop computers, tablets and smartphones. 

Barney Graner, from the University of London, described a MOOC that was delivered within Coursera (Coursera website).  I have to confess to taking two different Coursera courses, so this presentation was of immediate interest (although I found that the content was very good, I didn’t manage to complete either of them due to time pressures).  The course that Barney spoke of was 6 weeks long, and required between 5 and 10 hours of study per week.  All in all, there were 212 thousand students registered and 9% of those completed.  Interestingly, 70% were said to hold a higher degree and the majority were employed.  Another interesting point was that if the students paid a small fee to permit them to take something called a ‘signature track’, this apparently had a significant impact on retention statistics.

Matthew Yee-King from Goldsmiths gave a presentation entitled ‘metrics and systems for peer learning’.  In essence, Matthew spoke about how metrics can be used on different systems.  An important question that I’ve noted is, ‘how do we measure difference between systems?’ and ‘how do we measure if peer learning is working?’

The final presentation of the day, entitled ‘exploring and interacting with history on-line’ was by Andrew Payne, who was from the National Archive (National Archive education).  Andrew described a MOOC that focused on the use of archive materials in the classroom.  A tool called Blackboard Collaborate (Blackboard website) was used for on-line voice sessions, the same tool used by the Open University for many of their modules.

Towards the end of the day, during the start of a discussion period, I noted of a number of key issues for further investigation.  These included: pedagogy, strategy and technology.

Reflections

In some respects, this day was less about sharing hard research findings (since the MOOC is such a new phenomenon) but more about the sharing of practice and ‘war stories’.

Some messages were simple, such as, ‘it’s important to engineer for scale’.  Other points certainly require further investigation, such as, how best MOOCs might potentially help to reach those groups of people who could potentially benefit most from participating in study.  It’s interesting that such a large number of participants already have degree level qualifications.  You might argue that these participants are already experienced learners.

It was really interesting to hear that different MOOCs made use of different tools.  Although I’m more of an expert in technology than pedagogy, I feel that there is continuum between MOOCs (or on-line courses, in general) that offer an instructivist (or didactic) approach on one hand, and those that offer a constructivist approach on the other. Different software tools, of course, permit different pedagogies.   

Another (related) thought is that learners not only have to learn the subject that is the focus of a MOOC, but also learn the tool (or tools) through which the learning can be acquired.  When it comes to software (and those MOOCs that offer learners a range of different tools) my own view is that people use tools if they are sure that there is something in it for them, or the benefit of use outweighs the amount of investment that is extended in learning something.

In some respects, the evolution of a MOOC is an exercise in engineering as much as it is an exercise in mass education.  What I mean is that we’re creating tools that tell us about what is possible in terms of large scale on-line education.  Some tools and approaches will work, whereas other tools and approaches will not.  By collecting war stories and case studies (and speaking with the learners) we can begin to understand how to best create systems that work for the widest number of people, and how MOOCs can be used to augment and add to more ‘traditional’ forms of education.

One aspect that developers and designers of MOOCs need to be mindful of is the need for accessibility.  Designers of MOOCs need to consider this issue from the outset.  It’s important to provide media in different formats and create simple interfaces that enable all users to participate in on-line courses.  None of the presenters, as far as I recall, spoke about the importance of accessibility.  A high level of accessibility is connected to high levels of usability.

Just as I was finishing writing up this quick summary, I received an email, which was my daily ‘geek news’ summary.  I noticed an article which had an accompanying discussion.  It was entitled: Are High MOOC Failure Rates a Bug Or a Feature? (Slashdot).  For those who are interested in MOOCs, it’s worth a quick look.

Permalink Add your comment
Share post
Christopher Douce

Understanding Moodle Themes

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 21 Jul 2010, 18:27

A section of a Moodle screen showing three icons: forums, lessons and resources

This post is about the journey that I followed trying to understand Moodle Themes.  Moodle Themes are pieces of programming magic that change the visual appearance of your Moodle installation.

If you download Moodle and play around with it, you might eventually arrive at a decision that it might be useful within your institution.  You might hold a meeting with senior management where you may say, 'I think it's a good idea if we try to use this thing call Moodle to host some of our courses'.  After answering some difficult questions about maintenance and development costs, your managers might say, 'okay, you've convinced us... let's give it a go, I'll give you a budget'

Other than figuring out which operating system and database to use and where (and how) your instance of Moodle is to be hosted, one of the first development activities you will have to do is make sure that your Moodle system is 'on brand', i.e. it's visual appearance should reflect the institution that you work for.

This is pretty much what I have to do.  I have to try and make my 'vanilla' (unmodified) version of Moodle blend in with a set of existing web pages that have been built as a part of a research project I'm working on.  Other development teams within my university have already done something similar with their production version of Moodle, but I need to tackle this problem myself.

I start with a couple of questions: what makes up a theme and how might you go about changing one or maybe even making a new one?

Resources galore

Before I can answer these questions I needed to find something to read, and it didn't take a lot of browsing to find a number of potentially useful resources.

The first page that I discovered was a link to over one hundred different themes thanks to the Database of Moodle Themes.  Perhaps I shouldn't be so surprised given the number of Moodle installations that are out there in the world.

I soon discovered the Themes documentation pages and a number of other related links, including a set of themes related FAQs and dedicated discussion forum.

The Themes documentation link (for a Themes novice) seems to be the most useful.  One of the sections says that themes can be delivered in zip files.  You download them, unzip them and place the contents in the /moodle/theme directory, and then click on some admin tools to activate it.  This sounds almost too easy!

Towards Code

Being someone who likes to view code I thought it might be useful to look at some of the magic that makes Moodle themes work.  To do this, I chose a random theme from the themes database and unzipped a folder to my desktop.  To begin to make sense of it properly, I felt that it might be a good idea to compare this random theme against one that already existed.  This made me answer, 'which theme is used by default?'

To answer this question, I logged onto my local instance of Moodle (which was running on my local machine, localhost) as an administrator.  After struggling to remember my username and password, I clicked on the Administration link, followed Appearance, Themes and then on the Theme Selector link (because I couldn't really make sense of the Theme Settings options).

I quite like the Theme Selector page.  It presents all the different themes that have been installed.  The current theme that is selected is highlighted by a black square.  The one that was selected by default (in the case of my installation - I cannot remember whether I changed it) was named standardwhite.

I delve into the Moodle code area, take a copy of standardwhite and placed it alongside the one I have randomly downloaded and started poking around.

Looking at code

I noticed similarities and differences.  The similarities are that some of the filenames are the same.  I see two PHP files, styles and config, followed by two html files, header and footer.  There seems to be a CSS file (Wikipedia) in both themes (but the downloaded theme contains a few more than the default theme).  I also notice a graphics file called gradient in the default theme (which is a jpg), and a png graphics file in the other one.  A big difference lies was that the theme I have downloaded contains a directory which seems to contain a bunch of graphic files.

Before deciding I'm terribly confused, I decide to do one more thing: open up both of the PHP files to see what they contain.

In a config script, I see assignments to a variable called $THEME.  Different attributes appear to do different kinds of magic.  Looking in the styles script, a comment tells me that 'there should be no need to modify this file'.  It seems to do something that relates to the presentation of a CSS file.  That is good enough for me!

I have a quick peek into the header and the footer html files.  It looks like these are templates (of some kind) that are filled out using the contents of some PHP variables.  Obviously the pages that the Moodle code creates have a pretty well defined structure, and presumably this structure is documented somewhere.  This is perhaps something I might need to remember later.

Return to the documentation

At this point, I roughly (think) I know what a Theme comprises: some magic scripts which define some variables (and some other stuff), some header and footer scripts which look at bit like templates, a CSS file of some kind, perhaps a graphic (which could be used by the CSS file?) and maybe a bunch of graphics that replace those that are used in Moodle by default.

If this is my current understanding, can I now find the documentation easier to understand?

I soon uncover two further pages: Make your own Theme and Creating a Custom Theme (the first link seems to be easier to understand).  A couple of clicks takes me to a documentation page called Theme config file which goes some way to explaining the variables that I have touched upon above.

The final comment in the Creating a Custom Theme page was instructive.  Other than saying that you can't change everything, if you want to make your site look like an existing site, it might be a good idea to make use of a tool called Firebug which is a plug in for your Firefox browser.

With Firebug, you can browse to a web page of your choice and uncover what CSS definitions have been used to build its visual appearance.  I've used Firebug before, and mentioning that it is a good tool is certainly a good piece of advice.  The Moodle developers have also been kind enough to prepare a CSS FAQ which is certainly worth a look.

Although I could have tried to create a new theme from scratch, I'm in a lucky position since one of my colleagues has already created a customised theme for a custom instance of Moodle.

Towards testing things out

To test things out, I copy of my customised theme into my local 'themes' directory and hit refresh on my browser.  I then select my newly installed theme and everything starts to go wrong.  The action of selecting a theme seemed to have rendered my local copy of Moodle useless since only a tiny fraction of a HTML page is created (which I see by viewing the code the browser receives).

A problem seems to have been created since the version of Moodle that I am using and the structure of the theme that I have transferred are not completely compatible with each other.  I need to go back to my default theme! But how do I do this? Where are the theme settings held?

My first guess is in the database.  I open up a front end to the MySQL database that is running on my PC, using a tool called SqlYog.  I eyeball the contents of the database to see if there's anything I can use.  I discover a 'config' table, but this doesn't tell me much.  I did, however, discover that there is a theme setting within individual courses as well as individual users.

I turn my attention towards the code by first looking at the code within the themes directory and I soon find myself fruitlessly searching through different libraries.  Finding a simple answer may necessitate spending quite a bit of time.

To get things working again, you sometimes have to cheat.  I renamed my theme to something totally different and refreshed my Moodle page.  Moodle then had no choice but to return to its default setting (which was, again, 'standardwhite').

Incrementally merging

I have two themes: one theme that I want to use but doesn't work (because it has been modified for a customised version of Moodle), and another theme that does work which I don't want to use.  When I'm faced with this situation, I try to get 'code to speak to me' by incrementally taking the one that works and making it look like the one that doesn't work.  I find I can really understand stuff when things stop working!

I begin by looking at the files and then the contents of the files.  The first thing that strikes me is that the header and footer files are quite different.  There seems to be quite a bit more happening in the customised theme when compared to the standard theme.  A step at a time I move files across and test, beginning with the favicon, then the config file, and finally the pix's.  I discover that both themes require the use of a CSS file that is contained within the standard theme directory.

The effect of moving files around seems to produce, more or less, what I was after.  The interactive 'side blocks' (particularly the show/hide buttons) are not presented as they should, but further searching reveals a magic variable, allowuserblockhiding that can be used to control this functionality.

Moodle version 2

A question to complete this post is: what is the situation regarding Moodle version 2.0?  This is a development that I have heard about for some time, but I have not heard recent any announcements regaring its expected release.  After a quick search, I reacquaint myself with something called the Moodle Roadmap.

This appears to state that there will be a beta release of V2 by the end of 2009, followed by some months of testing before a final release.  Judging by the planning document, there appears to be quite a lot more coding to do (nearly four hundred days of development time to go, so we should expect some delays).

I appreciate that giving opinion is certainly a lot easier than giving code, so I hope that Moodlers who read this section will forgive me.  I personally hope that the code for the next version is a lot cleaner.  Since the developers are forced to move to PHP version 5, I hope they will choose to adopt its object-oriented features which can help developers to form clearer (less leaky) abstractions.

In a perfect world, developers should be able to look at a screenful of code and be able to describe, more or less, what that section of code does without having to look at other code (providing, of course, they more or less have an understanding of what the product does).  From what I have seen so far in version 1.9, there is a long way to go to, but I'm certainly looking forward to learning how things have moved on in version 2.0.

Wrap-up

It's great that the developers of Moodle have designed it in such a way that it is 'themeable' (if there is such a word).  In some respects, I was surprised to discover things were not as difficult as I had expected.  Whilst, in some ways, going directly to the code and looking what is there may be a daunting challenge, it is one that I certainly recommend doing.

There's a whole lot more to the issue of Moodle themes.  I haven't touched upon the structure of Moodle pages and how they relate to elements in stylesheets, for example.  I'll leave this challenge for another day!

Permalink
Share post
Christopher Douce

Exploring Moodle forums

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 21 Jul 2010, 18:08

A set of spanners loosely referring to moodle tools and debugging utilities

Following on from the previous post, this post describes my adventures into the Moodle forums source code.

Forums, I understand, can be activities (a Moodle term) that can be presented within individual weeks or topics. I also know that forums can be presented through blocks (which can be presented on the left or right hand side of course areas).

To begin, and remembering the success that I had when trying to understand how blocks work, I start by looking at what the database can tell me and quickly discover quite a substantial number of tables.  These are named: forum (obviously), forum_discussions, forum_posts, forum_queue, forum_ratings (ratings is not something that I have used within the version of Moodle that I am familiar with), forum_read, forum_descriptions, forum_subscriptions and forum_track_prefs.

First steps

Knowing that some of the data tables are called, I put aside my desire to excitedly eyeball source code and sensibly try to find some documentation.

I begin by having a look at the database schema introduction page (Moodledocs), but find nothing that immediately helps.  I then discover an end user doc page that describes the forum module (and the different types of forum that are on offer in Moodle).  I then uncover a whole forum documentation category (Moodledocs) and I'm immediately assaulted by my own lack of understanding of the capabilities system (which I'll hopefully blog about at some point in the future – one page that I'll take note of here is the forum permissions page).

From the forums category page I click on the various 'forum view pages', which hints that there are some strong connections with user settings.

Up to this point, what have I learnt?

I have learnt that Moodle permits only certain users to carry out certain actions to Moodle forums.  I have also learnt that Moodle forums have different types.  These, I am lead to believe (according to this documentation page) are: standard, single discussion, each person posts one discussion, and question and answer.  I'm impressed:  I wasn't expecting so much functionality!

So, can we discover any parallels with the database structures?

The forum table contains fields which are named: course, type, name, description followed by a whole other bunch of fields I don't really understand.  The course field associates a forum with a course (I'm assuming that somewhere in the database there will be some data that connects the forum to a particular part or section of a course) and the type (which is interestingly, an enumerated type) which can hold data values that roughly represents the forum types that were mentioned earlier.

A brief look at the code

I remember that the documentation that I uncovered told me that the 'forums' was a module. In the 'mod' directory I see notice a file called view.php.  Other interesting files are named: post.php, lib.php, search.php and discuss.php.  View.php seems to be one big script which contains a big case statement in the middle.  Post.php looks similar, but has a beguiling sister called post_form which happens to be a class.  Lib, I discover, is a file of mystery that contains functions and fragments of SQL and HTML.  Half of the search file seems to retrieve input parameters, and discuss is commented as, 'displays a post, and all the posts below it'.

Creating test data

To learn more about the data structures I decide to create some test data by creating a forum and making a couple of posts.  I open up an imaginatively titled course called 'test' and add an equally imaginatively titled forum called 'test forum'.  When creating the forum I'm asked to specify a forum type (the options are: single simple discussion, Q and A forum, standard forum for general use).  I choose the standard forum and choose the default values for aggregate type and time period for blocking.  The aggregate type appears to be related to functionality that allows students to grade or rate posts.

When the forum is live, I then make a forum post to my test forum that has the title 'test post'.

Reviewing the database

The action of creating a new forum appears to have created a record in the forum table which is associated to a particular course, using the course id.  The act of adding a post to the test forum has added data to forum_discussions, where the name field corresponds to the title of my thread: 'test post'.  A link is made with the forum table through a foreign key, and a primary key keeps track of all the discussions held by Moodle.

The forum_posts table also contains data.  This table stores the text that is associated with a particular post.  There is a link to the discussion table through a discussion id number.  Other tables that I looked at included forum_queue (not quite sure what this is all about yet), forum_ratings (which probably stores stuff depending on your forum settings), and forum read, which simply stores an association between user id, forum id, discussion id and post id.

One interesting thing about forums is that they can have a recursive structure (you can send a reply to a reply to a reply and so on).  To gain more insight into how this works, I send a reply to myself which has the imaginative content, 'this is a test post 2'.

Unexpectedly, no changes are made to the forum_discussions table, but a new entry is added to the forum_posts table.  To indicate hierarchy a 'parent' field is populated (where the parent relates to an earlier entry within the forum_posts table).  I'm assuming that the sequence of posts is represented by the 'created' field which stores a numerical representation of the time.

Tracing the execution flow

These experiments have given me with three questions to explore:

  1. What happens within the world of Moodle code the user creates a new forum?
  2. What happens when a user adds a new discussion to a forum?
  3. What happens when a user posts a reply?

Creating a new forum

Creating a new forum means adding an activity.  To learn about what code is called when a forum is added, I click on 'add forum' and capture the URL.  I then give my debugger the same parameters that are called (id, section, sesskey and add) and then begin to step through the course/mod.php script.  The id number seems to relate to the id of the course, and the add parameter seems to specify the type of the activity or resource that is to be added.

I quickly discover a redirect to a script called modedit.php, where the parameters add=forum, type= (empty), course=4, section=1, return=0.  To further understand what is going on, I stop my debugger and start modedit.php with these parameters.

There is a call to the database to check the validity of the course parameter, fetching of a course instance, something about the capability, fetching of an object that corresponds to a course section (call to get_course_section in course/lib code).   Data items are added to a $form variable (which my debugger tells me is a global).  There is then the instantiation of a class called mod_forum_mod_form (which is defined within mod/forum/mod_form.php).  The definition class within mod_forum_mod_form defines how the forum add or modification form will be set out.  There is then a connection between the data held within $form and the form class that stores information about what information will be presented to the user.

After the forum editing interface is displayed, the action of clicking the 'save and return to course' (for example) there is a postback to the same script, modedit.php.  Further probing around reveals a call to forum_add_instance within forum/lib.php (different activities will have different versions of this function) and forum_update_instance.  At the end of the button clicking operation there is then a redirect to a script that shows any changes that have been made.

The code to add a forum to course will be similar (in operation) to the code used to add other activities.  What is interesting is that I have uncovered the classes and script files that relate to the user interface forms that are presented to the user.

Adding a new discussion

A new discussion can be added by clicking on the 'Add a new discussion topic' button once you are within a forum.  The action of clicking on this button is connected to the forum/post.php script.  The most parameter associated to this action is the forum number (forum=7, for example).

It's important to note the use of the class mod_frum_post_form contained within post_form.php which represents the structure of the form that the user enters discussion information to.

The code checks the forum id and then finds out which course it relates to.  It then creates the form class (followed by some further magic code that I quickly stepped through).

The action of clicking on the 'post to forum' button appears to send a post back (along with all of the contents of the form) to post.php (the same script used to create the form).  When this occurs, a message is displayed and then a redirect occurs to the forum view summary.  But where in the code is the database updated?  One way to do this is to begin with a search to the redirect.  Whilst browsing through the code I stumble across a comment that says 'adding a new discussion'.  The database appears to be updated through a call to forum_add_discussion.

Posting a reply to a discussion

The post.php script is also used to save replies to discussions (as well as adding new discussions) to the database.  When a user clicks on a discussion (from a list of discussions created by discuss.php), the link to send replies are represented by calls to post.php with a reply parameter (along with a post number, i.e. post.php?reply=4).  The action of clicking on this link presents the previous message, along with the form where the user can enter a response.

Screen grab of user sending a reply to a forum discussion

To learn more about how this code works, I browse through the forums lib file and uncover a function called forum_add_new_post.  I then search for this in post.php and discover a portion of code that handles the postback from the HTML form.  I don't explore any further having learnt (quite roughly) where various pieces of code magic seems to lie.

Summary

The post.php script does loads of stuff.  It weighs in at around seven hundred lines in length and contains some huge conditional statements.

Not only does post appear to manage the adding of new discussions to a forum but it also appears to manage the adding, editing and deletion of forum messages.  To learn about how this script is structured I haven't been able to look at function definitions (because it doesn't contain any) but instead I have had to read comments.  Comments, it has been said, can lie, whereas code always tells the truth.  More functions would have helped me to more quickly learn the structure of the post.php script.

The creation of the user interfaces is partially delegated to the mod and post form classes.  Database updates are performed through the forum/lib.php file.  I like some of the function abstractions that are beginning to emerge but any programming file that contains both HTML and SQL indicates there is more work to be done.  The reason for this aesthetic (and person) opinion is simple: keeping these two types of code separate has the potential to help developers to become quickly familiar where certain types of software actions are performed.  This, in turn, has the potential to save developer time.

One of the central areas of functionality that forum developers need to understand is how Moodle works and uses forms.  This remains an area of mystery to me, and one that I hope to continue to learn about.  Another area that I might explore is how PHP has been used to implement different forum systems so I can begin to get a sense of how PHP is written by different groups of developers.

Acknowledgements: Photograph licenced under creative commons by ciaron, liberated from Flickr.

Permalink
Share post
Christopher Douce

How Moodle block editing works: database (part 2)

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 21 Jul 2010, 18:05

Pattern of old computer tapes intended to represent databases

This is a second blog entry about how Moodle manages its blocks (which can be found either at a site level or at a course level).  In my previous post I wrote about the path of execution I discovered within the main Moodle index.php file.  I discovered that the version of Moodle that I was using presented blocks using tables, and that blocks made use of some interesting object-oriented features of PHP to create the HTML code that is eventually presented to the end user.

This post has two objectives.  The first is to present something about the database structures that are used to store information about which blocks are stored where, and secondly to explore what happens when an administrator clicks on the various block editing functions.  The intention behind this post is to understand Moodle in greater detail to uncover a little more of how it has been designed.

Blocks revisited

Screen grab of the latest news block with moving and deletion editing icons

Blocks, as mentioned earlier, are pieces of functionality that can sit on the left hand or right hand borders of courses (or the main Moodle site page).  Blocks can present a whole range of functions ranging from news items through to RSS feeds.

Blocks can be moved around within a course page with relative ease by using the Moodle edit button.  Once you click on ‘edit’ (providing it is there and you have the appropriate level of permissions), you can begin to add, remove and move blocks around using a couple of icons that are presented.  Clicking on the left icon moves the block to the left hand margin, clicking the down arrow icon changes its vertical position and so on.

One of my objectives with this post is to understand what happens when these various buttons are clicked on.  What I am hoping to see are clearly defined functions which will be called something like moveBlockUp, moveBlockDown or deleteBlock.

Perhaps with future versions it might be possible to have a direct manipulation interface (wikipedia) where rather than having buttons to press, users will be able to drag blocks around to rapidly customise course displays.  Proposing ideas and problems to be solved is a whole lot more easier than going ahead and solving them.  Also, to happily prove there’s no such thing as an original thought, I have recently uncovered a Moodle documentation page.  It seems that this idea has been floating around since 2006.

Before I delve into trying to uncover how each of the Moodle block editing buttons work, it is worthwhile spending some time to look at how Moodle remembers what block is placed where.  This requires looking at the database.

Remembering block location

I open up my database manipulation tool (SqlYog) and begin to browse through the database tables that are used with Moodle.  I quickly spot a bunch of tables that contain the name block.  One that seems to be particularly relevant is a table called block_instance.

The action of creating a course (and adding blocks to it) seems to create a whole bunch of records in the block_instance.  Block_instance appears to be the table that Moodle uses to remember what block should be displayed and when.

The below graphic is an excerpt from the block_instance data table:

Fragment of the block_instance datatable showing a number of different fields

The field weight seems to relate to the vertical order of blocks on the screen (I initially wondered whether it related to, in some way, some kind of graphical shading, thinking of the way that HTML uses the term weight).  Removing a block from a course seems to change the data within this table.

The blockid seems to link each entry within block_instance to data items held within the  Block table:

Fragment of the blocks table, showing the field headings and the data items

The names held within the name field (such as course_summary) are connected to the programming code that relates to a particular block.  The cron (and the lastcron) relate to regular processes that Moodle must execute.  With the default installation of Moodle everything is visible, and at the time of writing I have no idea what multiple means.

Returning to block_instance, does the pageid field relate to the id used in the course?  Looking at the course table seems to add weight to his hypothesis.

I continue my search for truth by rummaging around in the Moodle documentation, discovering a link to the database schema and uncover some Block documentation that I haven’t seen before (familiarity with material is a function of time!)  This provides a description of the block development system as described by the original developer.

Knowing that these two tables are now used to store block location my question from this point onwards is: how does this table get updated?

Database updates

To answer this question I applied something that I have called ‘the law of random code searching’: if you don’t know what to look for and you don’t know how things work, carry out a random code search to see what the codebase tells you.  Using my development environment I search to find out where the block_instance datatable is updated.

Calls to the database to be spread out over a number of files: blocks, lib, accesslib, blocklib, moodlelib, and chat/lib (amongst others).  This seems to indicate that there is quite a lot of coupling between the different sections of code (which is probably a bad thing when it comes to understanding the code and carrying out maintenance).

Software comprehension is sometimes an inductive process.  Occasionally you just need to read through a code file to see if it can yield any clues about its design, its structure and what it does.  I decided to try this approach for each of the files my search results window pointed to:

Accesslib
Appears to access control (or permission management) to parts of Moodle.  The comments at the top of the file mention the notion of a ‘context’ (which is a badly overloaded word).  The comments provide me no clue as to the context in which context is used.  The only real definition that I can uncover is the database description documentation which states, ‘a context is a scope in Moodle, for example the whole system, a course, a particular activity’.  In AccessLib, there are some hardcoded definitions for different contexts, i.e. CONTEXT_SYSTEM, CONTEXT_USER, CONTEXT_COURSECAT and so on.

The link to the blocks_instance database lies within a huge function called create_context which updates a database table of the same name.  I’ve uncovered a forum explanation that sheds a little more light onto the matter, but to be honest, the purpose of these functions is going to take some time to uncover.  There is a clue that the records held within the context table might be cached for performance reasons.  Moving on…

Moodlelib

Block_instance is mentioned in a function named remove_course_contents which apparently ‘clears out a course completely, deleting all content but don’t delete the course itself’.  When this function is called, modules and blocks are removed from the course.  Moodlelib is described as ‘main library file of miscellaneous general-purpose Moodle functions’ (??), but there is a reference towards another library called weblib which is described as ‘functions that provide web output’.

Blocks
A comment at the top of the blocks.php file states that it ‘allows the admin to configure blocks (hide/show, delete and configure)’.  There is some code that retrieves instances of a block and then deletes the whole block (but in what ‘context’ this is done, at the moment it’s not clear).

Blocklib
The file contains the lion’s share of references to the block_instance database.  It is said to include ‘all the necessary stuff to use blocks in course pages’ (whatever that means!)  At the top there are some constants for actions corresponding to moving a block around a course page.  Database calls can be found within blocks_delete_instance, blocks_have_content, blocks_print_group and so on.  The blocks_move_block seems to adjust the contents of the database to take account of moment.  There also appears to be some OO type magic going on that I’m not quite sure about.  Perhaps the term ‘instance’ is being used in too many different ways.  I would agree with the coder: blocklib does all kinds of ‘stuff’.

Lib files
Reference to block_instance can be found in lib files for three different blocks: chat, lesson and quiz.  The functions that contain the call to the database relate to the removing of an ‘instance’ of these blocks.  As a result, records from the block_instance table are removed when the functions are called.

So, what have I learnt by reading all this stuff?  I’ve seen how the database stores stuff, that there is a slippery notion of a course context (and mysterious paths), and know the names of some files that do the block editing work, but I’m not quite sure how.  There is quite a lot of complexity that has not yet been uncovered and understood.

Digressions

I have a cursory glance through the lib folder to see what else I can discover and find an interestingly named script file entitled womenslib.php.  Curious, I open it and see a redirect to a wikipedia page.  The Moodle developers obviously have a sense of humour but unfortunately mine had failed!  This minor diversion was unwelcome (humour failure exception), costing me both time and ‘head’ space!

Bizarrely I also uncover seemingly random list of words (wordlist.txt) that begins: ‘ape, baby, camel, car, cat, class, dog, eat …’ etc.  Wondering whether one of the developers had attended the famous Dali school of software engineering, I searched for a file reference to this mysterious ‘wordlist’.

It appeared that our mysterious list of words was referenced in the lib\setup.php file, where a path to our  worldlist was stored in what I assumed to be a Moodle configuration variable.  How might this file be used?  It appears it is used within a function called generate_password.

Thankfully the developers have been kind enough to say where they derived some of their inspiration from.   The presence of the wordlist is explained by the need to construct a function to create pronounceable automatically generated passwords (but perhaps only in English?)

This was all one huge digression.  I pulled myself together just enough to begin to uncover what happens when a user clicks on either the block move up, down, or delete buttons when a course is running in edit mode.

Button click action

Returning to the task in hand, I add two blocks (both in the right hand column, and one situated on top of the other) to my local Moodle site with a view to understanding that function code that contributes to the moveBlockUp and deleteBlock functionality.

4815869094_9c27f1aaf4.jpg

I take a look at the links that correspond to the move up and the delete icons.  I notice that the action of clicking sends a bunch of parameters to the main Moodle index.php.  The parameters are sent via get (which means they are sent as a part of the hypertext link).  They are: instanceid (which comes straight out of the block_instance table), sesskey (which reminds me, I really must try to understand how Moodle handles sessions (wikipedia) at some point), and a blockaction parameter (which is either moveup or delete in the case of this scenario).

The question here is: what happens within index.php?  Luckily, I have a debugger that will be able to tell me (or, at least, help me!)

I log in as an administrator through my debugger.  When I have established a session, I then add some breakpoints on my index.php code and launch the index.php code using the parameters for ‘move activity upwards’.

Index.php begins to execute, and a call to page_create_object is made. It looks like a new object is created.  An initialisation function within the page_base class is called (contained within pagelib).  A blocks_setup function is called and block positions from the block_instance database is retrieved.  After some further tracking I end up at a function called blocks_execute_url_action.  The instanceid is retrieved and a call is made to blocks_execute_action where the block action (moveup or delete) is passed in as a parameter with the block instance record that has just been retrieved from the database.

In blocks_execute_action a 'mother of all switch statements' makes a decision about what should be done next.  After some checks, two update commands to the database are issued through the update_record function updated weight values (to change the order of the respective blocks).  With all the database changes complete, a page redirect occurs to index.php.  Now that the database has the correct representation of where each block should be situated index.php can now go ahead and display them.

Is the same mechanism used for course pages?

A very cursory understanding tells me that the course/view.php script has quite a lot to do with the presentation of courses, and at this point gathering an understanding of it is proving to be elusive.  Let’s see what I can find.

4815245535_c6182b86b1.jpg

Initially it does seem that the index.php script controls the display of a Moodle site and course/view.php script does control the course display.  Moving the mouse over the ‘move block up’ icons reveals a hyperlink to the view.php script with get parameters of: id (which corresponds to the course number held within the course data table), instance id (which corresponds to a record within the block_instance table) and sesskey and blockaction parameters (as with index.php).

To get a rough understanding of how things work, I do something similar as before: open up a session through my debugger and launch the view.php with this bunch parameters.  The view.php course is striking.  It doesn’t seem to be very long and nor does it produce any HTML so it looks like there’s something subtle going on.

In view.php, there are some parameter safety checks, followed by some context_instance magic, checking of the session key followed by calls to the familiar page_create_object (mentioned in the earlier section).  Blocks_setup is then called, followed by blocks_get_by_page_pinned and blocks_get_by_page which asks the database which blocks are associated to this particular page (which is a course page).

Like earlier, there is a call to blocks_execute_url_action when updates the database to carry out the action that the administrator clicked on.  At the end of the database update there is a redirect.  Instead of going to index, the redirect is to view.php along with a single parameter which corresponds to the course id.

This raises the question: what happens after the view.php redirect?

Redirect to view.php

When view.php makes a call to the database to get the data that corresponds to the course id number it has been given.  There is then a check to make sure that the user who is requesting the page is logged into Moodle and eventually our old friends page_create_object and blocks_setup are called, but this time since no buttons have been clicked on, we don’t redirect to another page after we have updated the database.

Towards the end of view.php we can begin to see some magic that begins to produce the HTML that will be presented to the user.  There is a call to print_header.  There is then a script include (using the PHP keyword ‘required’) which then creates the bulk of the page that is presented to the user, building the HTML to present the individual blocks.  When running within my debugger, the script course/format/weeks/format.php was included.  The script that is chosen depends on the format of the course that has been chosen.  When complete, view.php adds the footer and the script ends.

Summary

So, what have I learnt from all this messing about?

It seems that (broadly speaking) the code used to move blocks around on the main Moodle site is also used to move blocks around on a course page, but perhaps this isn’t too surprising (but it is reassuring).  I still have no idea what ‘pinned blocks’ means or what the corresponding data table is for but I’m sure I’ll figure it out in time!

Another thing that I have learnt is that the view course and the main index.php pages are built in different ways.  As a result, if I ever need to change the underlying design or format of a course, I now know where to look (not that I ever think this is something that I’ll need to do!)

I have seen a couple of references to AJAX (MoodleDocs) but I have to confess that I am not much wiser about what AJAX style functionality is currently implemented within the version of Moodle I have been playing with.  Perhaps this is one of those other issues that will become clearer with time (and experience).

One thing, however, does strike me: the database and the user interface components are very closely tied together (or closely coupled) which may make, in some cases, change difficult.  One of the things that I have on my perpetual ‘todo’ list is to have a long hard look at the Fluid Project, but other activities must currently take precedence.

This pretty much concludes my adventure into the world of Moodle blocks. There’s a whole load of Moodle related stuff that I hope to look at (and hopefully describe) at some point in the future: groups, roles, contexts, and forums.  Wish me luck!

Acknowlegements: Image from lifeontheedge, licenced under Creative Commons.

Permalink
Share post
Christopher Douce

How Moodle block editing works : displaying a block (part 1)

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 21 Jul 2010, 17:58

A photograph of a car engine

One of the great things about Moodle (other than the number of databases it can use!) is the way that courses can be easily created and edited.  One of its best features is the edit button that can be found at the top of many pages.  Administrators and course managers can push this button and quickly add and remove functionality to redesign a course or a site within seconds.

This blog post is the first in a series of two (but might even extend to three) that aims to answer the question of: how does the Moodle block editing magic work?  To answer this question I found that it was useful to split this big question into a number of smaller questions.  These are: how are blocks presented to the user?, how are block layouts stored in the Moodle database?, and what happens when the user clicks on the edit button and makes changes to the layout of a site or a course?

There are two reasons for wanting to answer to these questions.  The first is that knowing something about this key part of Moodle might help me to understand more about its architecture which might help me in the future if I have to make any changes as a part of the EU4ALL project.  The second is pure curiosity, particularly regarding the database tables and structures - I would like to know how they work.

There are two broad approaches that I could take to answer these questions: look at things from the top down, or from the bottom up.  I could either look at how the user interfaces are created, or I could have a look at the database to see if I can find data tables that might be used to store data that is used when the Moodle user interface is created.  In the end I used a combination of top down and bottom up approaches to understand a bit of what is going on.

This post will present what I have learnt about how Moodle presents blocks.  The second post will be about what I have found out about the database and how it works (in relation to Moodle blocks) and what happens when you click on the various block editing icons.

There will be load of detail which will remain unsaid and I’ll be skipping over loads of code subtleties that I haven’t yet fully understood!  I’ll also be opinionated, so advance apologies to and Moodle developers who I might inadvertently offend.  I hope my opinions are received with positive spirit, which is the way that they are intended.

Introducing blocks

Blocks are bits of functionality which sit on either side of a Moodle site or course.  They can do loads of stuff: provide information to students about their assignment dates, and provide access to discussion forums.  When first looking at Moodleworld, I had to pause a moment to distinguish between blocks, resources and activities.  Blocks, it might be argued, are pieces of functionality that can support your learning, whilst activities and resources may be a central part of your learning (but don’t quote me on that!)

Screen grab of an administrator editing a Moodle course

Not long after starting looking at the blocks code, I discovered a developer page on the subject.  This was useful.  I soon found out that apparently there are plans to improve the block system for the next version of Moodle.  The developers have created an interestingly phrased bug to help guide the development of the next release.  This said, all the investigations reported here relate to version 1.9+, so things may very well have moved on.

Looking at Index

Blocks can be used in at least two different ways: on the main Moodle site area (which is seen when you enter a URL which corresponds to a Moodle installation) and within individual courses.  I immediately suspect that there is some code that is common between both of them.  To make things easy for myself, I’ve decided (after a number of experiments) to look at how blocks are created for a Moodle site.

To start to figure out how things work the first place that I look at is the index.php file.  (I must confess that I actually started to try to figure out what happened when you click on the editing button, but this proved to be too tough, so I backtracked…)

So, what does the index.php file do?  I soon discover a variable called $PAGE and asked the innocuous question of ‘why are some Moodle variables in UPPERCASE and others in lowercase?’ I discover an answer in the Moodle coding guidelines.  Anything that is in uppercase appears to be global variables.  I try to find a page that describes the purpose of the different global variables, but I fail, instead uncovering a reference to session variables, leaving me wondering what the $PAGE class is all about.

Pressing on I see that there are some functions that seem to calculate the width of the left and the right hand areas where the blocks are displayed.  There is also some code that seems to generate some standard HTML for a header (showing the Moodle instance title and login info).

The index page then changes from PHP to HTML and I’m presented with a table.  This surprises me a little.  Tables shouldn’t really be used for formatting and instead should only be used to present data.  It seems that the table is used to format the different portions of the screen, dividing it unto the left hand bunch of columns, a centre part where stuff is displayed, and a right hand column. 

It appears that the code that co-ordinates the printing of the left and right blocks is very similar, with the only difference being different parameters to indicate whether things appear on the left, and things appear on the right.

The index file itself doesn’t seem to display very much, so obviously the code that creates the HTML for the different blocks is to be found in other parts of the Moodle programming.

Seeding program behaviour

To begin to explore how different blocks are created I decide to create some test data.  I add a single block to the front page of Moodle and position it at the top on the right hand side:

Screen shot showing empty news block

Knowing that I have one block that will be displayed, I can the trace through the code when the ‘create right hand side’ code is executed using my NuSphere debugger to see what is called and when.

One thing that I’m rather surprised about is how much I use the different views that my debugger offers.  It really helps me to begin learn about the structure of the codebase and the interdependencies between the different files and functions.

Trying to understand the classes

It soon becomes apparent that the developers are making use of some object-oriented programming features.  In my opinion I think this is exactly the right thing to do.  I hold the view that if you define the problem in the right way then its solution (in terms of writing the code that connects the different definitions together) can be easy, providing that you write things well (this said, I do come from a culture of Java and C# and brought up, initially, on a diet of Pascal).

After some probing around there seem to be two libraries that seem to be immediately important to know about: weblib and blocklib.  The comments at the top of weblib describes it as ‘library of all general-purpose Moodle PHP functions and constants that produce HTML output’.  Blocklib is described as, ‘all the necessary stuff to use blocks in course pages’.

In index, there is a call to a function called blocks_setup (blocks, I discover, can be pinned true, pinned both, or pinned false – block pinning is associated to lessons, something that I haven’t studied).  This function appears to call another function named   blocks_get_by_page (passing it the $PAGE global).  This function returns a data structure that contains two arrays.  One array is called l and the other is called r.  I’m assuming here that array data has been pulled from the database.

The next function that follows is called blocks_have_content. This function does quite a bit.  It takes the earlier data structure, and translates the block number (which corresponds to which block is to be displayed on the page) and converts it into a block name through a database call.  The code then uses this name to instantiate an object whose class is similar to the block name (it does this by prepending ‘block_’ to the start).

There is something to be cautious about here: there is a dependency between the contents of the database (which are added to when the Moodle database is installed) and the name of the class.  If either one of these were to change the blocks would not display properly.

The class that corresponds to the news block is named ‘block_news_items’.  This class is derived from (or inherits) another class called block_base that is defined within the file moodleblock.class.php.  A similar pattern is followed with other blocks.

Is_empty()

Following the program flow, there is a call to a function called is_empty() within blocklib.php.   This code strikes me as confusing since is_empty should only be doing one thing.  Is_empty appears to have a ‘side effect’ of storing the HTML for a block that comes from a call to get_content to a variable called ‘content’.  Functions should only do what they say they do.  Anything else risks increasing the burden of program comprehension and maintenance.

The Moodle codebase contains several versions of get_content, one for each of the different blocks that can be displayed.  The version that is called depends on which object Moodle is currently working through.  Since there is only one block, the get_content function within block_news_items is called.  It then returns some HTML that describes how the block will be presented. 

This HTML will be stored to the structure which originally described which block goes where.  If you look through the pageblocks variable, the HTML can be found by going to either the left or right array, looking in the ‘obj’ field, then going to ‘content’.  In ‘content’ you will find a further field called ‘text’ that contains the HTML that is to be displayed.

When all the HTML has been safely stored away in memory it is almost ready to be printed (or presented to a web client). 

Calls to print_container_start() and print_container_end() delineate a call to blocks_print_group.  In this function there will then be a database call to check to see if the block is visible and then a call to _print_block() is made.  This is a member function of a class, as indicated by the proceeding underscore.  The _print_block() can be found within the moodleblock.class file.  This function (if you are still following either me or the code!) makes a call to print_side_block function (which is one of those general purpose PHP functions) contained within weblib.php.

Summary and towards part 2

I guess my main summary is that to create something that is simple and easy to use can require quite a lot of complicated code.

My original objective was to try to understand the mechanisms underpinning the editing and customising of course (particularly blocks) but I have not really looked at the differences between how blocks presented within the course areas and how blocks are presented on the main site.  Learning about how things work has been an interesting exercise.  One point that I should add is that from an accessibility perspective, the use of tables for layout purposes should ideally be avoided.

What is great is that there is some object-oriented code beginning to appear within the Moodle codebase.  What is confusing (to me, at least) is the way that some data structures can be so readily changed (or added to) by PHP.  I hold the opinion that stronger data types can really help developers to understand the code that they are faced with since they constrain the actions that can be carried out to those types.  I also hold the view that data stronger typing can really help your development since you give your development tools more of an opportunity to help you (through presenting you with autocomplete or intellisense options), but these opinions probably reflect my earlier programming background and experience.

On the subject of data types, the next post in this series will be about how the Moodle database stores information about the blocks that are seen on the screen.  Hopefully this might fill the gaps of this post where the word ‘database’ is mentioned.

Acknowlegement
: Picture by zoologist, from Flickr.  Licenced under creative commons.

Permalink
Share post
Christopher Douce

Learning Technologies 2009

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 21 Jul 2010, 17:49

Conference logo

Yesterday I went to the Learning Technologies exhibition held at Kensington Olympia, London.  This is the third time I have been to this event.  The first time I went (back in 2004) was because I also attended a related exhibition called BETT which is hosted a couple of weeks earlier.

The two shows have different audiences: BETT is more focussed towards the schools and government funded education sector whereas the Learning Technologies exhibition focuses more on education (or training) software, services and systems for private sector companies (but there is much cross over, of course).  Every year there seems to be a conference that is linked to the exhibition but I have so far never been able to attend.

Last year

Last year I came away from the exhibition learning a few new things.  I learnt that there was a range of products called competency management systems which enables corporations to learn about what their employees know about (and how these map to individual training courses).  I also learnt about the release of new mobile learning systems.  The prevailing theme of last year’s exhibition seemed to be the concept of Rapid E-learning (more of this later).

My objective for this visit was to determine whether there were any new themes (or innovations) in learning technologies that are emerging from the commercial sectors.  I also had one eye on the subject of accessibility and the extent to which Moodle was beginning to feature in the commercial e-learning sphere.

Themes

Whilst walking around the exhibition I asked a number of exhibitors whether they thought there were any differences between this years exhibition and the previous years exhibition.  Two main seemed to dominate.  The first is the application of web 2.0 ideas into learning systems.  The second is the idea of informal learning.  Both of these themes were, perhaps unsurprisingly, reflected in articles that were provided in the free magazine that came with admission.  I also picked up on a number of other themes too.  These are listed below.

Web 2.0

The notion of web 2.0 (or the 'participatory web'), seemed to feature quite heavily.  Given the amount of discussion this label has generated this perhaps isn’t surprising.  It was interesting to see that an article written by the current Open University vice-chancellor was given a mention in the exhbition and conference magazine.

One comment that I heard from the exhibitors is that there is a more wider acceptance of the use of blogs and wikis.  One vendor who I spoke to was called Infinity Learning.  Infinity were presenting something called their 'learning portal' product which provided some functionality to allow learners to rate and review courses.  It was interesting since it featured a recommendation system akin to something that Amazon does when it offers you products that other people have bought.  I presume this will expose the learning pathways that other employees or learners have followed, allowing water cooler discussions about what learning activities were helpful to become more explicit.

Informal learning

I have to confess, I do struggle with understanding the concept of formal learning, but the exhibition magazine points me in the direction of a related blog post.  There are a couple of links within this link that might be useful.

One vendor connected e-learning and informal learning by describing an approach where large quantities of digital resources are placed on-line allowing employees to gain access to useful information as and when they are required, allowing gaps of knowledge about procedure or practice to be filled.

Informal learning, in this sense, can be connected to some of the other themes that could be found within the exhibition, specifically ‘bite sized’ or on-demand learning (which may or may not incorporate product simulations).

Gaming

There seemed to be a bit of a buzz about gaming, but I didn’t get a sense that this was one of the big topics of the show.  When speaking to one exhibitor, gaming was mentioned in the same sentence as virtual worlds.

Rapid e-learning

The idea of rapid e-learning initially puzzled me when I first came across it last year.  I soon realised that  rapid e-learning is facilitated by tools that allow e-learning designers to create their own in-house courses without having to go outside to professional e-learning content development companies (of which there are many).

Last year, the word at the exhibition was that rapid e-learning tools were causing the decline in the price of bespoke e-learning contracts.  Every exhibitor that had a rapid e-learning tool seemed to have their own learning management system of some kind.  When it comes to industry standards (in the e-learning world), the one that is most often mentioned is SCORM (wikipedia).

Bite sized e-learning

Bite sized e-learning seems to relate primarily to e-learning objects that are quite small.  You might use informal learning and bite sized learning in the same sentence.  These might be small 'mini courses' that give you instruction about how to carry out a particular task or operation within your institution.  This is also related to the next theme: simulations.  (As an aside, I'm assuming that a bite sized piece of e-learning doesn't last more than ten or twenty minutes, but this wasn't a question that I really asked).

Simulations

A number of vendors were selling tools that enable you to build simulations of any IT system that your organisation might have deployed.  Simulations can be used to either train up new employees, or to offer 'bite sized' reminder courses that can help to guide employees through the features of a large system that might not be used very often.

The presence of these products did make me wonder about how the provision of simulation recording (and development) systems might stack up against quick and easy to use open source tools such as Wink (but this exposes a dimension of simulation systems that has illustration at one end and involvement at the other).

Competency Management

I love this term!  It has such a positive feel to it!

Like last year there were some vendors who were selling systems that attempted to bridge the gap between human-resources systems and training delivery systems.  I know very little about human resource management systems but I can see that the link between LMS systems that deliver different kinds of learning might be useful.  When asking about the different personnel management systems that were on the market, Oracle seemed to be the one that was mentioned most frequently, having acquired Peoplesoft (wikipedia).

Content Development

I stumbled across the term 'workflow management' a couple of times.  I can see the purpose of using an e-learning material workflow management system: a company needs to draw upon the skills and abilities of different people within an organisation, some of whom might be external contractors.  I find the area of workflow management systems interesting since they can really take advantage of the fact that IT systems are exceptionally good at remembering stuff about who did what and when.

Moodle

Moodle cropped up a couple of times.  Kineo, a company based in Brighton in the UK was offering a cut-price hosted solution for a period of twelve months.  As a part of the package they appeared to be offering customising (or branding) of the Moodle instance to match the identity of your institution, and some training.  Sadly, all the guys at Kineo were way too busy to have a chat with me!

The second big Moodle related find was a product called Moomis marketed by Aardpress.  Moomis is apparently a Moodle 'plug-in'  that can add Continuing Professional Development (CPD) and competency management functionality (my favourite term) to make Moodle more flavoursome for the more commercially inclined.

Accessibility

Since e-learning materials appear to be often created using rapid e-learning tools, the accessibility of the resulting material is likely to partially dependent upon the structure of the digital resources that are generated.  I didn't have much of a chance to quiz vendors about this issue, but well known UK companies such as Epic and Brightwave are known to appreciate the importance of accessibility.

On another note, I was interested to discover the presence of Texthelp, a company who produce a tool called ReadWrite&Gold (they also produce the BrowseAloud system which can be used in conjunction with the main Open University website).  They kindly gave me quick demo and said that they had just release a new version which incorporates new synthetic voices and updated dictionaries.

I also discovered the presence of the UK Council for Access and Equality, a not for profit organisation.

The downturn

The Learning Technologies exhibition seemed to be as busy as it was last year – it was certainly buzzing with visitors.  I asked a couple of people about their opinions about the current concerns about 'the downturn' and received a mixed set of responses.  Some companies, it was reasoned, were choosing to bring their training spend 'in-house', choosing to use rapid e-learning tools (but this was in line with some of the trends I felt were at the exhibition last year).

Other companies seemed to state that they had been affected, whereas others had a deliberate strategy of going after public sector projects.  In one of the presentations that I briefly attended contained the argument that organisations should make use of learning technologies to ensure that employees are able to perform as efficiently as possible.  On-demand 'bite sized' e-learning will certainly help when it comes to carrying out complex infrequent tasks.

And finally

I also discovered the presence of a project called Next Generation Learning , a campaign sponsored by Becta.

As well as noticing the presence of organisations like the British Computer Society, I also noticed an organisation called the e-Learning Network (which appears to be a partner with the Association of Learning Technology), and was duly informed that associate membership was free.  Might be worth a look.

Summary

I quite like the Learning Technologies exhibition (I might even be able to attend the conference one day).  It's a good way to find out (very roughly and quickly) what's happening in the wider e-learning industry. 

Its interesting to see that vendors offer a portfolio of different services which often includes content creation, tool development, managed learning environment provision and system hosting.  The concept of 'web 2.0' (whatever that means) seems to be a salient theme this year.  It was interesting to see the substantial use of the term informal learning.  It'll be interesting to see how the exhibition looks next year.

Acknowlegements: thanks to all those exhibitors who I spoke to!

Permalink
Share post
Christopher Douce

Database abstraction layers and Moodle

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 21 Jul 2010, 17:47

4815223101_d522684c99.jpg

One of the great things about Moodle is that it can be used with a number of different database systems.  It can use popular open source databases such as MySQL or Postgres, or commercial offerings from Oracle or Microsoft. 

The great thing about offering this level of flexibility is that it can make the adoption of Moodle into an existing IT infrastructure a whole lot easier.  If you have an IT department which is Microsoft centric, then adopting Moodle or slotting it into an existing IT infrastructure might not cause too much upset.  Similarly, if your IT department uses Linux and has a dedicated database server that runs Postgres, offering choice of back end technologies can make things easier for system administrators.

This post is all about exploring how Moodle works with so many different database systems.  The keywords that I am starting with is database abstraction layer.  Wikipedia defines a database abstraction layer as ‘an application programming interface which unifies the communication between a computer application and databases’.  In some cases, a database abstraction layer can also help to maintain good application performance by caching important data, avoiding the need to repeatedly request data from a database engine.

Here are my questions: how does a Moodle developer save stuff to and get stuff from a database? Does Moodle have a database abstraction layer?  If it does, how might it work?  Finally, are there other database abstraction layers or mechanisms out there that could be used?  Let’s begin with the first question.

Getting stuff in and out

What instructions or mechanisms do developers used to get data into and out of Moodle, or a database that Moodle is using?  My first port of call is the Moodle documentation.  After a couple of clicks I find something called the Moodle Database Abstraction Layer.  This looks interesting but way too complicated (and initially confusing) for me to understand in one go.  What I’m interested in is an example.

I turn to the Moodle codebase and using my development environment I perform a text search (or grep) with  the word SELECT, which I know to be a frequently used part of the SQL database language which underpins most relational database systems, and browse through the results.  I quickly uncover a function called get_record_sql which seems to be the way to send SQL language commands to a database.

Another search reveals that the function is defined within a file called dmlib.php.  This library is said to contain all the Data Manipulation Language functions used to interact with the DB.  Comments within the file are reported to be ‘generic’ and work with a number of different databases.  A link to a documentation page is also provided, but seems to be describe functions that relate to the development version of Moodle, not the version that I am using (version 1.9).

It seems that functions named get_record_sql, get_record_select and update_record (amongst others) are all used to write to and read from a database that is used with Moodle.  To write new Moodle modules requires a developer to know a vocabulary of abstraction functions. 

The second question can be answered relatively easily: Moodle does seem to have a database abstraction layer.  Judging from the documentation it seems to have two different types of abstraction layers: one for the usage of a database, another for the creation of database structures.  I’ll try to write something about this second type in another post.

How does it work?

How does the Moodle abstraction layer work?  How does it act as an intermediary between the Moodle application and the chosen database engine? There seems to be a magic global variable called $db, and the abstraction layer code seems to be replete with comments about something called ADOdb.  Is ADOdb the magic that speaks to the different databases?

Another search for the phrase '$db =’ yields a set of interesting results, including files contained within a folder called adodb (lib/adodb).  This seems to be a database access library for PHP.  I uncover a link to the ADOdb sourceforge project from where the code originated and I’m rudely confronted with some sample code.

At this point, it seems that Moodle uses different two layers to 'get' and 'set' data.  It begins with the Moodle-world functions (the database manipulation language functions).  Calls are then passed to ADOdb, where they are magically ushered towards the database.

Other questions come to mind, such as: why did the Moodle developers choose ADOdb?  This question does not have an answer that can be easily uncovered.

Other abstraction layers

A quick glance at two of my PHP books point towards different database (or data) abstraction layers.  My copy of Programming PHP, for example, emphasises the use of a library called PEAR DB (named after the PHP Extension and Application Repository).  Clicking this previous link tells me that the PEAR DB library has since been replaced by something called MDB2.  My PHP Cookbook, on the other hand emphasises the use of PDO, which is a part of PHP 5 (a version of the PHP engine that the Moodle community has only relatively recently adopted).

So, why did the Moodle developers choose ADOdb when there are all these other mechanisms on offer?  I haven't managed to uncover forum discussion that explains the precise motivation for the choice.  Moodle release notes go back to May 2005, but the earliest forum discussion I can find that relates to ADOdb dates back to 2002.  Perhaps the choice could be put down as a happy accident of history and one that has facilitated amazing database interoperability.

One thing is clear: PDO is the (relatively) new kid on the 'database abstraction' block, and other software developers are asking the interesting (and difficult to answer) question of 'ADOdb or PDO: which is better?'  In trying to answer this question myself, I uncovered a slideshare presentation and a blog post that tries to compare the two technologies by using benchmarks to see which is faster.  PDO, it seems, is a central part of PHP 5 and has been written in 'native code' which might explain why is reported as being faster.

The debates about which database interface technology is better are interesting but don't directly arrive at a clear conclusion.  Different technologies may do similar things in slightly different ways, and sometimes a choice of one or the other may boil down to what the programmers have used in the past.  Unpicking the subtle advantages and disadvantages of each approach needs lots of time and determination.  And when you have an answer, affecting a change may be difficult.

Future developments?

I recently uncovered a really interesting Moodle forum discussion on the topic of database abstraction (amongst other things).  Subjects included differences between various database systems, the possibility of using stored procedures, the difficulty of mapping object-oriented data structures to relational database engines and so on.  All great fun for computer scientists and application developers!

One thing bugs me about the Moodle database abstraction layer is that it is very shallow.  It requires module developers to know a lot of stuff about things that ideally they shouldn't need to know about.  To add courses and modules, you have to know a little about the structure of the Moodle database and how to work with it.  There is very little code that separates the world of SQL statements (passed on to databases using DML and ADOdb) and the interfaces that are presented to users.

It could be argued adding additional layers of abstraction to more firmly manage data flow between Moodle application code and the database would place additional demands on the Moodle programmers.  In turn, it this could make it harder for occasional contributors, particularly those working within academic institutions to make contributions to the code base.  I strongly disagree with this argument.  Creating a more sophisticated (or layered) database abstraction approach may open up the possibility of making more effective use of functions of different database engines and make the Moodle code base easier to understand (if the abstractions are designed correctly).

One way to consider ways about how the abstraction layer might be improved is to look at how other open source projects solve the same problem.  I was recently told about the Drupal database abstraction layer.  One useful activity might be to investigate its design and learn about what decisions have helped to guide its development.

Summary

Databases can be a tough subject.  Creating an application that can work with different database engines effectively and efficiently is a big software engineering challenge.  This challenge, on the other hand, can make things a lot easier for those people who are responsible for the management and operation of IT services.  Providing application choice can increase the opportunities for an application to be used.

What is certain is that the database abstraction mechanisms that are currently used in Moodle will change as Moodle evolves and database engines are updated.  At the time of writing work is underway to further develop the Moodle database abstraction layer.  I look forward to seeing how it changes.

Image acknowledgement: pinksherbert, from Flickr.

Permalink
Share post
Christopher Douce

Using OpenLearn resources with Moodle

Visible to anyone in the world
Edited by Christopher Douce, Monday, 29 Apr 2019, 13:38

OpenLearn logo

One of the things that we need to do in the EU4ALL project is to create a prototype. To show the operation of a prototype, we need to show how content can be personalised. To show content personalisation happening we need some content. Luckily, the OpenLearn project is at hand to provide some Open Educational Resources (wikipedia) that we may be able to use.

The OpenLearn project provides learning materials in a number of formats. These formats range from native OU XML files, raw HTML files, IMS content packages through to RSS feeds and Moodle backup formats. This post is all about finding the most effective way to transfer OpenLearn to Moodle (and uncovering the best approach to use for on-going development work).

Using a Moodle Course Backup

The sample content that I'm going to use is a learning package about the Forth Road bridge (openlearn). This learning package (for want of a better term) is interesting since it contains a couple of different resources, including a video, a transcript in the form of a PDF file and some HTML pages.

In terms of loading the package to Moodle, I thought the easiest route would be to import the backup file type. The course backup facility allows Moodle users to make copies of entire courses (and their setup) for safe keeping. If inadvertent changes are made, a user then has the possibility of restoring (Moodle documentation) a course to your Moodle installation.

Others at the OU have blogged about similar issues, providing a more comprehensive description about how to setup an EEE netbook to allow users to view the OpenLearn material whilst on the move. This post takes (more or less) a similar approach, but focuses more on the different OpenLearn filetypes.

After downloading an OpenLearn Moodle backup course, I logged into Moodle as an administrator then clicked around on the 'course' menu options to see what I could find. It wasn't immediately clear what to do, so I went to the documentation for help. I found quite a few things.

I discovered that you needed to use the Course administration block. But this could be only accessed from within a course. It was apparent that to import a course, I needed to also create one.

After creating an empty course (using all the default settings), the course administration block duly appeared. From faint memories of this process, having played with this part of Moodle a couple of years ago I remember that restore was a two step process: first you had to upload the backup file, then you had to click on a restore link to start the backup process.

After trying to upload my backup package I was presented with a message that read 'a required parameter (id) was missing' ('what on earth does this mean?' I wondered). I then noticed that the size of my OpenLearn zip file was bigger (because it contained a video) than maximum supported upload file size in Moodle. Obviously I need to change a setting somewhere.

The first place that I looked was the Moodle system configuration file called config.php, but this didn't tell me much. I then delved into the area of my computer that contained the PHP installation and found a file called php.ini.

After a quick search, I discovered two places which might explain the maximum file size that Moodle has told me about. I subsequently make a change to the upload_max_filesize variable, setting it to 32MB, restarted my web server and then refreshed my browser. As if by magic, the maximum file size that Moodle allows has changed.

When trying the upload again, everything seemed to work okay (but I should say that the error message that I was presented with does need some attention).

When the upload from local file store to a Moodle folder was completed, I could see an adjacent 'Restore' button which I clicked. I was then presented with a question: 'Later in this process you will have a choice of adding this backup to an existing course or creating a completely new course – do you want to continue?' In my situation I initially want to do the latter operation, but I'm forced to do the former. I click yes to continue.

I was then presented with a list of actions that have been carried out: creating temporary structure, deleting old data etc, with no button or option to click on afterwards when it appears that everything has finished. Obviously things were not working as they should be. I carried out a further web search for answers.

I discovered the following from the Moodle backup and restore FAQ: 'Attempting to restore a course to an older version of Moodle than the one the course was backed up on can result in the restore process failing to complete'.

So, what versions am I using, and what version is the OpenLearn backup software provided in? To find the version of your Moodle installation, you have to go to the site administration menu (when logged in as an administrator), and click on Environment. I soon discover that I was using version 1.9+. I extract the contents of the OpenLearn Moodle Backup file and discover that it might be version 1.9, according to the first set of lines in an XML file that I discover. It seems I might be in a spot of trouble.

Getting Moodle Restore working

All was not lost, however. After some random searches I found a forum discussion. Fred has a suggestion: change a more recent programming file to an older version (which can be downloaded from the Moodle code repository). I changed the name of my 'restorelib.php' to 'backup restorelib.php' and download the version he suggests.

After replacing the file and restarting the restore process, magic begins to happen and messages are displayed on the screen. I'm then presented with a course restore screen, where a drop down box has the options: restore to new course (what I wanted to do initially), existing course deleting it first, existing course adding data to it. I chose 'existing course deleting it first', carelessly ignore everything else (which has been automatically ticked), and faithfully click on continue. I'm then presented with a list of courses to overwrite (I was surprised by this option since I thought I was automatically going to overwrite the course from where I clicked the 'restore' option through). Ignoring the warning, 'this process can take a long time', I clicked on 'restore this course now!'

4815233102_2dd79fab23.jpg

It didn't take a long time, and a minute or so later, I could happily browse through (and edit) my newly imported OpenLearn courses. Fred saved the day!

But what of the other OpenLearn file options? I'll steer clear of the 'Unit Content XML', the 'OU XML Package' and IMS Common Cartridge for now and instead focus on some of the others.

IMS Content Package

IMS publishes specifications that aim to make learning technology systems interoperate with each other. One of the specifications that they have publishes is the content package (CP). A CP is essentially a bunch of files which are contained with a zip file. In the zip file there is something called a manifest file. This manifest file is, more or less, like a table of contents, when is read by a VLE/LMS like Moodle.

In Moodle, a CP can be a resource (interactive components are called activities). I create a new course, set a course to have a topic format, and choose to upload my CP to the first topic. When this is done, I browse to the newly added resource and Moodle tells me that it is about to deploy the CP (meaning, uncompress its contents and read the table of contents file). When complete, I can now navigate through the different pages of my material.

4815233182_9a3fe65ec5.jpg

One of the differences between this format and the Moodle format is that the content is a lot more difficult to change. You have to use special tools, such as Reload to edit the manifest file, and HTML editors (and other similar tools) to change the contents of individual pages. Also, there is no direct way to include VLE supported interactive tools such as Wikis, blogs or on-line discussion forums in the middle of the material other than using the navigation mechanisms that the VLE provides (this will hopefully become a bit clearer later on).

SCORM

SCORM is an industry standard for the sharing of e-learning materials. SCORM makes use of IMS content packaging and defines an interface between the learning material and the VLE that is used to present the material.

This interface allows the VLE to record information such as whether the user has viewed all the pages of a SCORM resource, store interaction state to the VLE (such as answers for formative questions) and retrieve information from the VLE, such as the name of the current user (to allow partial customisation of a learning experience).

IMS content packages created by OpenLearn can also be viewed using the Moodle SCORM player (but I don't know if there are any problems doing this!).

4814610459_4a2ff30fd5.jpg

SCORM originated from a US government initiative called Advanced Distributed Learning (wikipedia). As a result, it reflects its training origins. Like IMS CP, it does not directly support the inclusion of interactive activities that are provided by a VLE (other than the activities that are contained within the boundaries of a content package).

In Moodle, there are two ways to present SCORM resources. The first, as presented above, is to add it as an 'activity'. The other way is to create a course that has a SCORM format. Rather than having individual weeks or topics, a single SCORM occupies centre stage. Surrounding the centre, it is possible to create Moodle supported activities, such as forums. Here I have create a Moodle wiki, allowing consumers of the OpenLearn course to share links about bridge engineering (!), for example.

4814610507_d113253322.jpg

The way that Moodle presents IMS packages and SCORM objects (or SCOs – sharable content objects) are similar, but subtly different, making me wonder about the underlying source code. When I have time I'll explore the code development history to see whether they are related in any way.

Plain Zip

One of the simplest formats that OpenLearn supports is called plain zip.

Unzipping a 'plain zip' file reveals all the resources for a course (images, video and transcripts), along with two types of HTML file: an index file (which is similar to the Moodle course summary screen that was presented earlier), and set of content pages. The content pages themselves have their own navigation links, i.e. page 1 is connected to page 2 and so on. SCORM, on the other hand, provides its own mechanism to navigate between resource pages, generated by the information contained within a manifest file.

Two other things are provided in the plan zip package: a creative commons deed (describing licencing terms), and a formatting stylesheet. If you want, you can change the font and the colours of the content pages by changing the stylesheet. The action of double-clicking on any of the HTML files within this package displays the material directly in a browser.

So, how can a plain zip OpenLearn package be used in Moodle? Is it possible?

The answer is that it is possible, and it's quite easy, but the end result is obviously not as 'integrated' as the other approaches. First of all, I create a new course. I give my course an obvious name and set it to use the 'topics' format. Then I transfer my OpenLearn zip package to Moodle. To do this, I click on the Files menu (from administration block whilst logged in as an administrator), and upload the zip file to the course (each course has its own file area). When the file has been uploaded, I unzip the zip file. After pressing the course edit button, I can now add a link.

From the resource menu I click on 'link to a file or website'. Here I select 4ROAD_1_section0.html. This is the first content file in a sequence of four. It is the file that presents the learning objectives to a learner.

4814610291_a5b503bbb1.jpg

I turn editing off to see the effect of what I have done. Clicking on the new link takes you to the first page in the OpenLearn content, providing further navigation links that allows you to access all the other resources.

One thing that should be noted is that you have not directly uploaded the resource into a directory on the web server that anyone can access to. Only people who have legitimate access rights can gain access to these files.

These approaches rely on content being downloaded from the OpenLearn site to Moodle. Are there any other ways to tell your students about the OpenLearn content through Moodle?

RSS

The final way that I will describe is through RSS (wikipedia). RSS is most commonly associated with blog syndication. RSS can be described as an XML data structure that contains links to interesting material. OpenLean also provide RSS Feeds to individual courses. If you take a copy of a RSS feed link, you can use it within other tools. One of those tools is Moodle.

Moodle can make use of activities, resources and blocks. Blocks are the pieces of functionality that can surround courses. Blocks can be added, deleted and moved around. One of the blocks that Moodle provides is an RSS block.

Using course I created earlier, I add a new block and paste in the RSS feed link that I gathered from the OpenLearn course, then ticked a tickbox and confirmed something. As if by magic, my new block was populated by the contents of the OpenLearn course I had just told it about.

4815233350_3665e64f54.jpg

Clicking on one of these links takes you directly to the OpenLearn site, where you can access the material directly. The advantages of this approach is that you don't have to do very much, plus the material is always up to date.

There is an outstanding question that this section of the blog raises: could it be possible to create a Moodle activity (or resource?) called an 'RSS feed' that could be placed within the main body of a course? This way, educators could be able to quickly and efficiently group together different OpenLearn (or other forms of OER) resources. Furthermore, this would make it possible to group different 'blog reading or reviewing' activities together which may culminate in a forum discussion or even an on-line audio conference at a pre-arranged time. But here, I'm starting to digress...

Further information

After having completed (more or less) the first section in this post, I discovered an OpenLearn course entitled Re-using, Remixing and Creating Content. This provides further information about the different file types and how they can be manipulated.

Conclusions

There are a number of different ways to use OpenLearn content in Moodle. Each of them differ in terms of how much you have to do and how the end result appears. Taking a personal perspective, which one might be the best approach to use within my project?

What I want is flexibility: the ability to change a course and add an additional category of resource to the middle of it, should this be required. Since I'm going to be using Moodle as my main research tool, it makes sense to make use of the Moodle course format. I can then make use of the Moodle tools (should this be necessary) and move resources and sections around with relative ease.

Permalink
Share post
Christopher Douce

Understanding Moodle localisation

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 21 Jul 2010, 13:19

moodle-logo-small.gif

Another Moodle activity that I've been tasked with is: 'ensure that different users are presented with user interfaces that match their language choices'.

I understand that software localisation (or internationalisation) is an industry in its own right, replete with its own tools and practices. When you scratch the surface of the subject you're immediately presented with different character sets, fonts and issues of text direction (whether text flows from left to right or visa versa).

My question is: how is Moodle localised into different languages, and does it use any approaches that could be considered to be common between other systems?

This post will only scratch the surface of what is an interesting (and often rather challenging) subject. For example, what is the Moodle approach to dealing with plurals, for example? There's also the issue of how internet browsers send their localised settings to web servers and application engines... Before I've even started with this post, I'm heading off topic!

Let's begin by considering three different perspectives: the students perspective, maintainers perspective and the developers perspective.

Students perspective

A student shouldn't really need to concern themselves with their locale settings, since the institution in which they are enrolled are likely use a sensible default setting. But if students wish to change the LMS interface language (and providing your particular Moodle installation permits the changing of user preferences), a student user could click on their name hyperlink that they see after logging on and click on an 'Edit Profile' tab and search for the 'preferred language' drop down box.

In my test installation, I initially had only one language installed: English (en). In essence, my students are not presented with a choice. I might, at some point during my project need to offer 'student users' a choice of four different languages: German, Italian, Greek and Spanish. Obviously something needs to be done, leading us swiftly to the next perspective.

Maintainers perspective

I log out from my test student account and log back in as an administrator and discover something called a 'Language' menu, under which I discover a veritable treasure trove of options.

The first is entitled 'Language Settings'. This allows an administrator to choose the default language for a whole installation and also to do other things such as limit the choice of languages that users can choose.

The second menu option is entitled 'Language Editing'. It appears that this option allows you to edit the words and phrases (or strings) that appear on the screen of your interface. The link between a 'bit on a screen' and a language specific description is achieved by an identifier, or a 'placeholder' that indicates that 'this piece of text should go here'.

What is interesting is that individual strings are held within Moodle programming files. This makes me wonder whether the action of editing the strings causes some internal programming code to change. This process is mysterious, but interesting.

As a useful aside (which relates to an earlier project related post), I click on 'resource.php' to see what identifiers (and text translations) I can find. I see loads of resource types, including names for resource types, which are numbered. Clearly, when adding new functionality, a developer needs to understand how software localisation occurs.

Continuing my user perspective exploration (after being a little confused as to what 'new file created' means after choosing to view the 'resource.php' translation page), I click on the 'Language Packs' option. Here I am presented with a screen that tells me about what language packs I have installed. By default, I only have a single language pack: English (EN). Underneath, I see a huge list of other language packs, along with a corresponding 'download' link. Apparently, because of a problem connecting to the main Moodle site (presumably because one of my development machines is kindly shielded from world from different nasties), things won't install automatically and have to save (unzipped) language packs to a directory called 'moodledata/lang'.

Let's see what happens by downloading and unzipping the language packs I need.

After unzipping the language packs, I hit my browser 'refresh' button. As if my magic, Moodle notices the presence of the new packs and presents you with a neat summary of you have installed.

Developers perspective

So, how does this magic work, and what does a developer have to know about localisation in Moodle?

One place to start is by exploring the anatomy of a downloaded language pack by asking the questions: 'what does it contain, and how is it structured?' Out of all the four packs that I have downloaded the German pack looks by far the most interesting in terms of its file size. So, what does it contain?

The immediate answer is simply: files and directories. In the German pack I see three folders: doc, help and fonts. The doc and fonts folder do not contain very much, mostly readme files, whereas the help folder in turn contains a whole load of subfolders. These subfolders contain what appears to be files containing fragments of HTML that are read using PHP code and presented to the user. At this point I can only assume that Moodle reads different help files (and presents different content to the user) depending upon the language that a user has selected.

At the root of a resource pack I see loads of PHP files. Some of these have similar file names, i.e. some begin with quiz, and presumably correspond to the quiz functionality, and others begin with repository, enrol and so on (my programmer sense is twitching, wondering whether this is the most efficient way to do things!)

A sample of a couple of these PHP files shows that they are simply definitions of localised strings which are stored in an associative array, which is indexed by a name. Translated into 'human speak', there's a fixed 'programming world' name which is linked to a 'language world' equivalent. You might ask the question of why do 'language localisation' this way? The answer is: to avoid having to make many different versions of the same Moodle programming code, which would be more than a nightmare to maintain and keep track of.

A number of questions crawl out of the woodwork. The main one being, 'how are the contents of these resource packs used when Moodle is running?', but there is the earlier question of 'what happens when you make a change to a translation?' that needs to be answered. Both are related.

Moodle has two areas where localisation records are stored. The first can be described as a 'master' area. This is held within the 'programming code' area of Moodle within a directory unsurprisingly named 'lang'. This contains files which contains identifiers and strings for the default language, which is English. The second area is a directory, also called 'lang', which can be found within the Moodledata directory area. Moodledata is a file area that can be modified by the PHP software engine (the software that Moodle itself is written in). Moodledata can store course materials and other data that is easier to store using 'file storage' area as opposed to using the main Moodle database.

As mentioned earlier, language packs are stored to the Moodledata area. If a user chooses to edit a set of localised strings, a new version of the edited 'string set' is written as a new file to a directory that ends with '_local'. In essence, three different language resources can exist: the 'master' language held within the programming area, the installed 'language pack', and any changes made to the edited language pack.

During earlier development work, I created a new resource category called an 'adaptable resource'. After installing the German resource pack, using the 'master language pack', Moodle can tell you whether there are some translations that are missing.

4814610613_9b910ff2c8.jpg

After making the changes, the newly translated words are written to a file. This file takes the form of a set of identifier definitions which are then read by the Moodle PHP engine. Effectively, Moodle writes its own programming script.

Using this framework, developers shouldn't have to worry too much about how to 'localise' parts of their systems, but before stating that I understand how 'localisation' works, there's one ore question to ask.

How does Moodle choose which string to use?

When viewing a course you might see a the 'topic outline' headline. How does Moodle make a choice about which language pack to use? I begin my search by looking through the code that appears to present the course page, 'course/view.php'. There isn't anything in there that can directly help me, so I look further, stumbling upon a file within a 'topics' sub-directory called 'format.php'.

In the format file I discover a function called get_string, which references an identifier called 'topicoutline'. This is consistent with the documentation that I uncovered earlier. The get_string function is the magic function that makes the choice about where your labels come from.

Get_string is contained within a file called 'moodlelib.php' which is, perhaps unsurprisingly, contained within a directory called 'lib'. Moodlelib is a huge file, weighing in at about eight thousand lines. It is described as (in the comments) as a file that contains ‘miscellaneous general-purpose Moodle functions’.

Get_string is a big function. One of the first things it does is figure out what language is currently set by looking at different variables. It then creates a list of places to look where localised strings can be found. The list begins with the location of where language packs are installed to, followed by areas within the Moodle codebase that are installed by default. It then checks to see if any ‘local’ (or edited) versions of the strings that have been created (as a result of user editing the language packs). When the function knows which file the strings are held in, Moodle reads (includes) the file and caches the contents of the 'string file' into a static variable (so Moodle doesn’t have to read the file every time it needs to fetch a string) and returns the matching localised string.

In the middle of this function there is extra magic to present sensible error messages if no strings are found, and other code to help with backwards compatibility with earlier versions of Moodle. It also seems to check for something called 'parent languages', but I've steer clear of this part of the code.

Testing language installation

Has all my messing around the languages worked? Can I now assign different users different languages? (Also, can users choose their own language preferences?) There is only one way to find out. Acting as an administrator I created a new user and set the users default language to Italian. I logged out and logged in using the new user account.

Moodle in Italian

It seems to work!

The one thing that I have not really explored is whether Moodle will automatically detect the language a user has configured on their internet browser. A little poking around, indicates that Moodle can indeed be clever and change its language dynamically by using the hidden 'language' information that is sent to a web server whenever a HTTP request is made.

The 'dynamic language adaptation' functionality is turned on by default, and a switch to turn it on and off can be found within the 'language settings' menu that the administrator can use.

The fact that Moodle can dynamically change in response to browser (and potentially operating system) settings is interesting. One of the things that the EU4ALL project is exploring is whether it might be possible to tell web-based systems whether certain categories of assistive technology are being used. This may open up the possibility of user interfaces that are more directly customised to users individual needs and preferences.

Other 'languages'

I've described (rather roughly) how Moodle takes care of software localisation, but how is it handled in other programming languages. I've used Java and the .NET framework in the past, and each system provides its own way to facilitate localisation.

Java makes use of something called a resource bundle (Sun Microsystems). dotNET, on the other hand, uses something called resource files (Code Project). One question remains: is there a generally recommended approach for PHP, the language on which PHP is based? Like with so many different things in software, there is more than one way to get the same result.

The author of the PHP Cookbook describes another way to think about localisation. This approach differs in the sense that it focuses more on demonstrating localisation by using object-orientation (an approach that Moodle has historically tried to steer away from, but this seems to be changing), and doesn't really address how a user might be able to edit or change their own strings should they not like what they see.

Conclusions

Software localisation, like accessibility, is a subject that software developers and web designers need to be aware of. This rather long post has outlined how software localisation is broadly achieved in Moodle. Much, however, remains unsaid. Issues such as how plurals, right to left scripts and multi-character fonts have been carefully side stepped.

What is clear is that Moodle appears to have a solid infrastructure for localisation which seems to work, and provides site maintainers the ability to add different languages without too many headaches. Also, whilst browsing the documentation site I stumbled across a documentation page that hints at potential future localisation developments.

Although I have mentioned one other way to approach localisation within PHP it might be useful at some point to explore how comparable learning management systems tackle the same problem, perhaps also looking at how localisation is handled in other large projects.

Localisation will always be something that developers will need to address. Whenever new functionality is introduced, developers will obviously make provision to ensure that whatever is developed is understandable to others.

Permalink
Share post
Christopher Douce

Exploring how to call SOAP webservices using PHP (and Moodle)

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 21 Jul 2010, 13:00

4815188662_bd8a3e24e0_m.jpg

This post describes my second bash at understanding PHP and SOAP webservices, work carried out off and on over the last couple of weeks. The first time I connected PHP to an externally hosted web-service was using a script that I wrote that was external to Moodle. Now my challenge is slightly different: to try to get Moodle calling external web services.

Just to make sure I understand everything, I'm going to present some background acronyms, try and remember what pages I looked at before, then step towards uncovering parts of Moodle that are in some way connected to the magic of web services.

Background information

I'm required to interface to web services that use the SOAP protocol (wikipedia). SOAP is, I am led to believe, an abbreviation for Simple Object Access Protocol. In a nutshell, SOAP allows you to send a message from one computer to another, telling it to do stuff, or asking it a question. In return, you're likely to get a response back that either tells you what you wanted or indicates why your request had failed. SOAP is one of many different techniques that you can use to pass messages to one computer to another over the internet.

Another technique, which is simpler (and faster) but has some limitations that SOAP gets round, is REST (wikipedia). More information on this 'architectural style' can be found quite easily by doing a quick internet search. My focus is, however, SOAP.

So, assuming that one computer exposes (or makes available) a web service to another computer, how do other computers know how to call a service? In other words, what parameters or data does a particular service expect? The answer is that the designers of SOAP service use a language that describes the format of the messages that the SOAP server (or service) will accept. This language is called WSDL, or Web Services Description Language (wikipedia).

Each SOAP server (or service) has a web address. If you need to find out what data a SOAP service requires, you can usually ask it by adding ?wsdl after the service name. This description, which is presented in a computer readable structure, can sometimes help you to build a SOAP call – a request from your computer to another.

Very often (in my limited experience of this area), the production and use of this intermediate language is carried out using layers of software tools and libraries. At one end, you will describe the parameters that you will process, and some magic programming will take your description (which you give in the language of your choice) and convert it into a difficult to read (for humans!) WSDL equivalent. But all this is a huge simplification, of course! And much can (and will) go wrong on the journey to get SOAP web services working.

A web service can be a building block of a Service Oriented Architecture (again, wikipedia), or SOA. In the middle, between different web services you can use the mysterious idea of middleware to connect different pieces of software together to manage the operation of a larger system, but this is a whole level of complexity which I'm very happy to avoid at this point!

Stuff I looked at earlier

The first place that I looked was in a book! Specifically, the PHP Cookbook.

Chapters 14, consuming web services, and 15, building web services looked to be of interest, specifically the sections entitled 'calling a SOAP method with/out WSDL'. Turning to this section I was presented immediately with a number of possibilities of how to make SOAP calls since there are a number of different implementations depending upon the version of PHP that you're using.

Moodle, as far as I understand, can work with version 4.3 of PHP, but moves are afoot to move entirely towards version 5. My reference suggested its perhaps best to use the bundled SOAP extension as opposed to the other (PEAR::SOAP or NuSoap) libraries since they are faster, more compatible with the standards, automatically bundled and exceptions (special case errors) that occur within SOAP are fed into corresponding PHP exception constructs to make programs (theoretically!) easier to read.

Consuming services

On my first attempt to call a web service, I ran into trouble straight after starting! All my code was failing for a mysterious reason and my debugger wasn't deciding to give me anything that was useful. After doing some searching and finding some on-line documentation I gave the PEAR library a try, but ended up just as confused. I ended up asking one of my illustrious colleagues for help who suggested that I should add an additional parameter to original attempts using the PHP extensions to take account of local network setup.

Calling seemed to be quite easy. I could create something called a SOAP client, tell it which address I want to call, give it some options and make a call my sending my client a message which has the same name of the web service which I want to call, optionally loaded up with all my parameters. To see more of what came back, I put some of the client variables in some temporary variables so I could more easily watch what was coming back in my debugger.

Producing services

Now that I (more or less) knew how to call web services using PHP, it struck me that it might be useful to see how it might be possible to present web services using PHP. This was found in the next chapter of the book.

To maintain consistency, I asked the question how might I create some WSDL that describes a service? Unfortunately, there is not an easy answer to this one. Although the integral SOAP libraries don't directly offer support to do this, there are some known techniques and utilities that can help.

One of the big differences between PHP and the WSDL language is that PHP is happy to just go ahead and do things with data without having to know exactly what form (or type) the data takes. You only get into trouble when you ask PHP to carry out operations on a data item that doesn't make sense.

WSDL, on the other hand, describes everything, giving both the name of a data item and its type. Because of this, you can't directly take a PHP data structure and use it to create WSDL. To get round this difference one approach is to provide this additional information in the form of a comment. Although comments are intended to help programmers, they can also be read by other computer programs. By presenting data type information in the form of a comment, an intermediate program can create WSDL structures without too much trouble, saving developer time and heartache. This approach is used by both the NuSoap library and code that works with PHP 5. But I digress...

Moodle web services code

There appear to be some plans to expose some of the Moodle functionality via a series of web services, enabling Moodle to be connected to and used with a range of external applications. There is also a history connecting Moodle with external assessment systems using web services.

A grep through the Moodle codebase (for 1.9) reveals a library called (perhaps unsurprisingly) soaplib. There appears to be some programming logic which makes a decision about which SOAP interface library to use, depending upon the version of PHP: use the native version if PHP 5 is used, otherwise NuSoap.

I'm guessing that the need to use the NuSoap library will gradually disappear at some point, but a guess is totally different from finding out whether this is really going to happen.

One way to find out what is going on and what lies in store for the future is to explore the on-line discussion forums and quickly find a forum that is dedicated to discussing Moodle web services. It appears there are two interesting developments, something called the Moodle NetWork (which allows you to share resources between different instances of Moodle, at a first glance), and non-core Moodle code contribution called the OKTech Web Services. After a little poking around it's possible to find some documentation that describes this development in a little more detail.

I also discovered a documentation page entitled Web services API , but is related to XML-RPC (wikipedia) rather than SOAP. My head is beginning to hurt!

Returning to the Moodle core SOAP library, I ask the question: what uses the soaplib? One way to do this is to search for calls to functions that are contained within this library. I have to confess, I didn't find anything. But, what I did find is a discussion.

It turns out it was added as a result of work carried out at the University of York in the UK for a project called Serving Maths that created something called the Remote Question Protocol (RQP). The initial post mentions concerns about not being able to make use of some of the additional parameters that the PHP 5 library provides. This is a concern that I share.

Next steps

I've more or less finished my whistlestop tour of Moodle components and code that relate to web services type stuff. I'm sure there is more lurking out there that I haven't discovered yet. But what of a conclusion?

Since I'm not planning on using Moodle to expose any web services I can thankfully sidestep some of the more difficult discussions I've uncovered.

Also, since there isn't much in the way of existing SOAP utility code that I can build upon and I roughly know more or less how to call web services using the magic functions that are provided in PHP 5, I'm going to try to more or less directly add some lines of code to Moodle. But before I do this, like every good developer, I'll test things out using a test harness to explore how my target services behave.

Image: modified from wikipedia

Permalink
Share post
Christopher Douce

Understanding Moodle accessibility

Visible to anyone in the world
Edited by Christopher Douce, Tuesday, 2 Dec 2008, 17:13

moodle-logo-small.gif

To really understand why things are the way they are today necessitates understanding what has happened in the past. This blog post is an attempt to build up an understanding of the current state of Moodle accessibility by looking into what has happened during parts of its development. My methodology is simple: begin with internet (and Moodle forum) searches, ask a few people to see what they know, and see where it takes me!

Initial results

A quick search using Cuil took me to some Moodle developer pages and the Moodle Accessibility Specification which has the headline, 'the document specifies improvements to the accessibility of the Moodle course management system for version 1.7’' This is useful. Both the page itself and the release number can point me towards some dates. Version 1.7 of Moodle dates from November 2006 onwards (until March 2007, when version 1.8 is released).

Digging a little further in the Moodle documentation, I discover the release notes for version 1.7. This provides a huge amount of information. Release notes are very often overwhealming for the casual reader. So, to help my search, I search this page for the term 'accessibility'.

Under Moodle 1.8 release notes, the words 'the Moodle interface is now compliant with XHTML Strict 1.0 and major accessibility standards' catch my eye. This is interesting, but what does this mean? Thankfully, there is a link. I’ll try to uncover what the significance of XHTML Strict later. Let's continue with the search for discussions relating to 'major accessibility standards'.

Moodle Accessibility Page

The link found on the 1.8 release notes takes me to the Moodle Accessibility page. The page provides several groups of other links: starting points, standards, legislation, tools and resources. A couple of things jump out at me: a link to the development tracker that relates to Accessibility Compliance in Moodle 1.8, a link to Italian Accessibility Legislation Compliance, and a link to an accessibility forum (guest login required).

It looks like I might be finding some very useful stuff! So much stuff, I need to focus down on what is often very important to me: source code. Code cannot lie, but on its own, it cannot always tell you its history... Thankfully, there are other ways to understand how (and why) things have changed.

Looking at the detail

To enhance the accessibility of Moodle, the developers have created tasks within a combined bug tracker and change management system. This is something that is common to loads of other software developments. Change management systems help developers to keep track of what has changed, when and by whom. If bugs are accidentally introduced as a result of changes, keeping records can help us to understand why. A side effect of a good tracker is that it can also tell you what changes are incorporated into individual releases.

Let’s have a look at a tracker entry to see what one of them says: Indicate type of resource in the name of the resource. This is an interesting one. For screen reader users, having advance warning about the file type is useful, particularly if a link is to a resource that is handled by an application outside of the browser, such as a PDF file, for example.

It’s also interesting to see that the tracker can also contain information about debates about the development of the software and, sometimes, its requirements. Clicking on the 'change history' may sometimes present you with a file that summarises the modifications that a Moodle developer has made to several files to make the accessibility enhancement.

Higher level advice

As well as the Accessibility Specification, one of the developers has created a useful page entitled Accessibility Notes (found within the developer area). This includes an executive summary of some of the guidelines, a roadmap for further accessibility developments, pointers towards future areas of development and a link to some accessibility 'patterns' which have been derived from the Web Content Accessibility Guidelines (WCAG).

Relationship to WCAG?

You often hear WCAG mentioned in relation to different levels of conformance, specifically A, AA and AAA. Whilst searching the terms Moodle and WCAG, I found myself back at the forum that I mentioned earlier which had the title, a forum to discuss 'planned conformance to standards/laws such as the Web Content Accessibility Guidelines (WCAG), Special Educational Needs and Disability Act (SENDA), Section 508 (USA)'

It should be said that there is no formal way to 'conform' to the WCAG guidelines. Whilst some of guidelines can be assessed by machine (by the use of a computer program), some sections of the guidelines require real people to determine whether or not a web page is accessible (according to the guidelines). It should be noted that even if something is accessible under one measurement, to some users, this might not be the case.

The issue of compliance is also complicated by the fact that Moodle (along with many other learning management systems) can make use of different blocks, modules or components in a range of different ways. The way that an application is use and configured can significantly influence its accessibility.

Although there is no definitive statement how Moodle adheres to the different WCAG 1.0 levels, but I have discovered a forum posting that relates to a question about the American Section 508 procurement legislation. But will there ever be a statement about WCAG? I decided to dig further by speaking to one of the contributors to the Moodle Accessibility Specification.

Whilst WCAG is great for content, it doesn’t work so well with interactive systems. The Moodle accessibility specification has been created by distilling accessibility principles and ideas from a number of different sources, WCAG as well as an organisation called IMS (see also the IMS Guidelines for Developing Accessible Learning Applications).

Future work?

It was recently announced that the latest version of the WCAG guidelines (version 2.0) will be soon released. One interesting piece of work would be to carry out an assessment of a 'vanilla' (or out of the virtual box) installation of Moodle against these new guidelines.

Strict!

Earlier on I mentioned that I might explore what is meant by the mysterious words XHTML Strict. Whilst browsing the Moodle accessibility pages, I discovered the Moodle tracker task that asked the developers to move to web pages that are 'marked up' in this way.

One part of this tracker jumps out at me, specifically: 'avoid using, within the markup language in which the page is coded, elements and attributes to define the page's presentation characteristics'. In essence, use semantic tagging on web pages as opposed to tagging that relates to the change of the visual characteristics of a display. Rather than using bold tags to indicate a heading, a developer should instead use heading tags. This way, the tags that 'add meaning' to a document can help users who have assistive technology navigate through a page more easily.

A further comment on the subject of semantic tagging is that if a developer needs to add visual formatting to a page, cascading style sheets should be used (CSS). CSS can be used to separate the structure of the content from how it appears on the users screen. A great illustration of what CSS is and what it is capable of can be found within the CSSZengarden.

There is another line within the tracker problem that was interesting: 'for all new sites, use at least version 4.01 of HTML, or preferably version 1.0 of XHTML'. What does this mean, and is there a difference between the two, and why is a difference preferred? Let’s have a look what they are in Wikipedia which contains a paragraph that explains how XHTML relates to HTML.

It seems there are little differences between the two, except that the HTML pages become well-formed XML documents. Not only can then the resulting pages be manipulated by programs that can manipulate XML (and more easily check for different types of conformance – page checking is mentioned in the tracker comments page), but by insisting that they are 'well formed' may prevent the possibility of 'ill-formed' pages confusing assistive technologies, such as screen readers.

The tracker provides more information about how XHTML relates to accessibility. WCAG states that content authors (and you could argue that a page generated by Moodle is content) should 'create documents that validate to published grammars' (checkpoint 3.2). Other useful WCAG checkpoints include guidance not to use deprecated (now obsolete or old) features, and select W3C technologies when they are available, and use the latest versions. In essence, take advantage of new technologies when they are available for use.

Summary

It seems that accessibility, as a subject, has been discussed on the Moodle forums since November 2005. Since this date, a lot of work has been carried out to improve the accessibility of Moodle, some by the Open University. Evidence of this work can be found documented within the Moodle project without too much difficulty. I hope this post has helped to show where (and how) to find information about Moodle accessibility.

Although it can be argued that no platform is totally accessible, strides have been made to make Moodle more suitable for users of assistive technology. Anyone who uses Moodle has to be aware that the accessibility of such a system does not only depend upon the programming code alone, but also how it is used, and what materials it presents to learners.

Acknowledgements are extended to those who I spoke to during preparation of this post. You know who you are!

Permalink
Share post
Christopher Douce

Discovering Moodle profile fields

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 21 Jul 2010, 12:58

EU4ALL logo

One way to improve e-learning user experience is to attempt to present material that match a learners precise needs and preferences. In terms of accessibility, it would be non-sensical to provide a screen reader user with a digital video resource, if that resource contained images or illustrations which did not have accompanying auditory explanations.

The previous post explored how it might be possible to add a new category of resource to Moodle, an 'adaptable resource'. This post will try to explore a related piece of the puzzle by examining how it might be possible to tell Moodle about your own e-learning content preferences.

Some background

A learner might use a range of different e-learning systems at different schools or universities during a learning career. One problem might be the need to continually tell different systems what your content preferences might be. Let's face it: this is trouble! Not only would this take time, but it would also no doubt introduce errors. One solution to this might be to allow a user to store their preferences on a server somewhere. This server could then share user preferences to different systems, subject to some form of magic authentication.

A learning management system could be used allow a learner (or someone acting on behalf of a learner) to edit and change their centrally managed preferences. The question is: how could we demonstrate this idea using Moodle?

Let's begin from where I left off in the previous post: user profile developer pages.

Returning to code

What this page says is that it's possible for a user of Moodle to store extra 'stuff' about a group of users to a database. This sounds great! But how does it work? In true developer fashion, ignoring all the user documentation, I delved into the source code and then browsed over the database structures. I found quite a few tables that relate to the user. There were tables relating to fields, data and categories, and a hint of previous accessibility development work as evidenced by the presence of a 'screenreader' field (but more of this later).

It soon became clear that there was quite a lot of existing functionality that might be able to be 'leveraged' (horrid word!) to facilitate (another one) the entering of user preferences. I liked what I saw: code where the functions were not too (not bigger than a screenful) and had the odd set of comments (you can read that in two different ways). Looking at the code, whilst useful, is never enough. It was time to have a look to see what the user sees.

Return to the user interface

Within a couple of minutes, I found it was possible to construct a way to enable both the user and the administrator to enter extra data against a particular user profile. Using the Moodle tools I created a really quick pull down menu to represent a learner specifying their preferences.

4815188614_d799dfb361.jpg

I should note, that a single menu represents a tip of the iceberg regarding the issue of entering user preferences! My titles are undoubtedly badly chosen. Also, there are existing metadata standards, such as AccMD (powerpoint), which can be used to describe user preferences, but I certainly won't go this thorny area here...

Along the way I stumbled across some documentation pages that describes the Moodle user profile.

Joining the dots (or nodes)

Okay, so this part of Moodle might be able to be used as a simple user interface to allow a user to specify their content preferences, but how (and where?) might I store other information like 'special-magic-numbers' or identifiers that can allow the VLE to understand that other systems are referring to the same user? (I hope this sentence makes sense!)

It seems that there are ways to store additional stuff in a Moodle profile too, fields that can be accessed and used by an administrator, but cannot be seen or edited by learners.

But... why?

As ever, one simple question has created a whole raft of others:

  1. Where did this feature come from?
  2. How is the data represented in the db? (looking at things from a developers eyes again!)
  3. What part of the code should I modify so I can connect the Moodle user interface to some kind of magic 'preferences server'?
  4. What does this mysterious 'screenreader' option do?

I'll leave some of them for another day, but I shall 'touch upon' answers to the first and the fourth.

Answers... of a sort

Apparently the capability to add profile fields (and categorize them) was added in version 1.8 of Moodle (which also incorporated a number of accessibility enhancements). I've tried to find the discussions on the forum that culminated in the addition of this feature, but I've had no joy - but what I have learnt is that there is talk about making an even more customisable version of the user interface, but I digress.

Wishing to know more, I turned my attention to the code to see what it could tell me. References to the screen reader profile tag is found scattered throughout the codebase. It appears to change how certain parts of the HTML is presented to browsers. It is found in the chat module, within the file type resource code, the question engine code (where additional feedback is presented to screen reader users), and in some of the currently mysterious theme code. I sense this question is a bit harder to answer than I had initially anticipated!

Onwards and upwards (or should it be downwards?)

Now that I know roughly how to make a custom user profile interface, my next task is to identify where in the code I should add some magic to make Moodle speak to different servers. Wish me luck!

Permalink
Share post
Christopher Douce

Working with new Moodle resource types

Visible to anyone in the world
Edited by Christopher Douce, Tuesday, 2 Dec 2008, 17:14

Moodle logo

As a part of the EU4ALL project, I have been trying to figure out how to add a new resource type. The idea is to add a resource known as an 'adaptable resource', whereby different media types are presented to the user depending on their accessibility preferences. The issue of how and where to assign or change these preferences is currently a question that has to be resolved. This post is intended as a bunch of 'notes to self' about what I have found during the last couple of days exploring and poking around the Moodle code base.

To explore the code, I've been using a couple of tools: SQLYog, which was recommended to me by an illustrious IET developer (to allow me to explore an instance of a Moodle MySQL database I have running on my home machine), and NuSphere, a PHP IDE. I did try the Zend IDE a year or so back, but abandoned it since I became rather confused!

So, how is it possible to add a new resource to Moodle? Initially, I decided to look at an existing resource, beginning with the simplest one that I could find: a simple text resource. By browsing the code base I seemed to find the rough area where the 'resource code' lives. I also browsed around the developer documentation page an unearthed a resource class template. Great!

In development, one question instantiates a tree of others. The most fundamental question is: how does this code work? I need to answer this big one to make a change. This is too big, so I split it into two other questions: (1) how can you modity a form that allows you to enter the parameters that describe an adaptable resource (currently it is to be a simple numerical value, from what I understand), and (2) how can I take the values held within a form and update them to the MySQL database? This requires an understanding of further magic code. As a note to myself, let's have a look at each of these in turn.

Entering stuff

Looking at the text resource code, there seemed to be a bit of object-oriented polymorphism going on. The name of the directory where the resource code is important too! There is a magic function called display which appears to make some further magic calls to create some data entry fields - but these calls are quite a long way away from the pure HTML that is presented in the browser window.

This is another question: how does the magic functions in display() get turned into HTML? The answer apparently lies with the application of a forms library called PERL. If I figure out how to add functions in a way that would work for this library, I can ask the user for whatever I want.

The form uses some object-oriented principles. Individual controls are added to 'the form', and then a function is executed that 'prints out' or renders each of the controls, without you having to go near to producing your own HTML.

Another interesting observation, is that the display function I have uncovered only relates to a small part of a bigger form. This is due to subclassing and polymorphism that is being used, but this is a distraction... now I have a little understanding of what is happening (thanks to the NuSphere debugger!), I'll park this question for the time being. There are other mysterious areas to explore!

Storing stuff

When a Moodle user edits a course resource, there are a couple of buttons that appear at the bottom of the screen. These are 'save and return', 'save and display' and 'cancel'. Looking at these buttons from a HCI perspective I think, 'buttons doing two different things?? surely this is a bad idea!'. But I digress.

My question is, 'what happens when the tutor (or administrator) clicks on either of the save buttons - where does the data go? Or more precisely, how does the data get saved?

Moodle seems to have a thin database layer: a set of functions that allows you to send SQL statements and receive data in response. Since the contents of the resource form is held in what can only be described as a 'big variable' (PHP has a funny approach to object-oriented programming if you've used other languages), the Moodle developers have figured out a way to transfer the contents of a form to the database, by matching on-screen fields to database fields.

This seems to work well: but on the downside is the database update code that Moodle code generates appear to be rather big, and an implicit dependency is created between the form and the database structure. Other systems that I've looked at make use of stored procedures, which has the potential to boost performance and security on one hand, but on the other restrict the database platforms that an application can be used with.

Moving forwards

Now I know (roughly) how to add extra bits to a new resource type, the next thing I have to do is figure out how to write the functions that I need. After I've done that I'll have to hook up my edits to the database, and figure out how to best display the data that I've produced. I already have some idea about how to do this since I have created a paper prototype.

But before going down that road, I think I'll continue my survey of the Moodle codebase by exploring what sections can potentially relate to adding and manipulation of user parameters and settings. I think I'll start by looking at the user profile developer pages.

Looking towards the longer term, I will also have to connect Moodle to a number of different web services. Wish me luck!

Permalink
Share post

This blog might contain posts that are only visible to logged-in users, or where only logged-in users can comment. If you have an account on the system, please log in for full access.

Total visits to this blog: 1977118