Overview

As my specialist option I will focus on the way I have designed resources and, in particular, used JavaScript to customize the behaviour of QMplus to present generic programme information to students and staff in as accessible a form as possible. I initially transferred this information from other web sites with different facilities and constraints, so my problem was to work out how best to map this information onto QMplus.

In order to customize QMplus, I need to know exactly what code is being used. I do this in two ways: sometimes I look at the source code for a whole page and sometimes I look at the details of a particular element that is of interest. I currently use Firefox as my preferred web browser and right-clicking on a web page pops up a menu, the bottom element of which is labelled "Inspect Element". This opens the developer console focussed on where I clicked and is a very quick and easy way to look at the code in the neighbourhood of a particular element. I often use it just to check how a particular heading is marked up so that I can make my own heading markup compatible. For example, if the main heading on a page is marked up as <h2> then I would probably use <h3> for my own top-level headings.

Looking at the source code for a QMplus page shows just how much JavaScript is being run. There is far more JavaScript than content on most pages, and there are usually references to many external JavaScript files as well! Therefore, any JavaScript that I might add is unlikely to impinge on performance. When I use JavaScript to modify the DOM (Document Object Model) of a web page I prefer to use the jQuery library rather than raw JavaScript. Fortunately, QMplus already loads jQuery so I don't need to do that. In principle, I need to pay attention to which version of jQuery is being loaded, but in practice I have not found this to be an issue.

Before I moved it into QMplus, I maintained the detailed study programmes for our degree courses as a single Microsoft Word document, which began with a few pages of general guidance and was then followed by the details for each degree programme, with the main content in the form of a table with two columns, one for each semester, and the years of the degree organised as rows. To support this, I also maintained at the end of the document a table of modules that appeared in more than one programme. Each entry had a bookmark, labelled by the module code, and each appearance of the module in the main document was generated from the bookmark by an appropriate field code. I also handled several sections of boilerplate text that appeared in many degree programmes in the same way. I published this document by printing it to PDF without the final table of bookmarked text, and I also extracted the page(s) for each degree programme into separate files. I provided all these PDF documents separately on our web site.

I decided that inserting module details from a table was unnecessarily complicated so I dropped it when I moved this information to QMplus. I don't think it would have been difficult to implement using JavaScript, but it was too obscure and not sufficiently useful to justify the complexity. I used a Moodle book to implement our study programme guide in QMplus, with each degree programme as a separate chapter, which automatically provides much of the structure that I implemented by hand before. I describe my customized Moodle book in more detail in the first section on the right.

Previously, I used a single XML data file as the basis for our module details. From this, I generated an HTML overview list and an HTML detail page for each module, linked to the overview list. This structure maps naturally to a Moodle database, with the list view providing the overview list and the single view providing the detail page for each module. The information in the database can be maintained in a fairly straightforward way using a graphical editor and (in most cases) does not require any knowledge of HTML. However, previously I also generated an HTML page that summarized the restrictions on taking each module, which is similar to another list view. A Moodle database provides only one list view by default, so I had to find a way to provide a second list view. There is a lot of data to display. How can it be displayed intelligibly, especially on a small screen? I solved this problem by extending techniques I used on the previous XML-based system. I display abbreviated information that is expanded in pop-up displays.

The module details database uses by far the largest chunk of inter-related CSS and JavaScript that I have written to customize QMplus, which is difficult to maintain within QMplus. When I was doing the main development, I copied the code into an offline editor, developed it there and then copied segments of code back into the right places. It appears that a Moodle database is not really intended to be customized substantially, even though it is the only Moodle resource I am aware of that explicitly supports the use of CSS and JavaScript. It is also a moot point whether a Moodle database qualifies as a database at all, since it can only have one table. This seems slightly strange and disappointing given that Moodle is implemented using a relational database. If one could create relational databases within Moodle and have better facilities for editing the code then it would be possible to be a lot more creative! I describe my customized Moodle database in more detail in the second section on the right.

A couple of years ago, it was decided (I think at faculty level) that past exam papers should be provided by Schools in QMplus instead of by the library on their web site. This raised the question of how best to do it. We have around 60 undergraduate modules and if we provide past papers for 3 years than we need to provide access to around 180 files. Doing this naively using the Moodle file resource would produce a very long and awkward display. A folder resource would be more compact and one might consider one folder or sub-folder per module. An HTML table containing links would be an elegant solution but then the files have to be stored elsewhere, making this arrangement awkward to maintain. I decided that another Moodle database would provide the best solution and I think it does, with one caveat. I describe this customized Moodle database in more detail in the final section on the right.

Francis Wright's CMALT ePortfolio

Francis Wright's CMALT ePortfolio

CMALT 5

Confirm copying

Restore backup