Edited by Christopher Douce, Wednesday, 21 Jul 2010, 12:58
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?
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.
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:
Where did this feature come from?
How is the data represented in the db? (looking at things from a developers eyes again!)
What part of the code should I modify so I can connect the Moodle user interface to some kind of magic 'preferences server'?
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!
Discovering Moodle profile fields
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.
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:
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!