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.
Study programme guide as a Moodle book
Description and Reflection
Having decided to implement our study programme guide as a Moodle book, it was not too difficult to copy and paste content from my Word document into chapters and sub-chapters and then tidy up the HTML. As I recall, the part that needed the most work by far was the tables. The core of each degree programme consists of a table specifying the modules to be taken in each semester of each year. HTML generated by Word tends to contain a lot of extraneous markup, even after all the styling code has been removed. I wanted clean, maintainable HTML, so I removed any inessential markup. In my Word version I had taken a lot of care with where I placed rules between cells and what weight the rules were. Word makes it easy to do this. If I recall correctly, this information did not transfer to the Moodle table and I could not find any easy way to set it up other than by very tediously adding a lot of inline styling, which would be very hard to maintain, so I decided not to do this. I don't know how much it affects the intelligibility of the tables.
Initially, I used a separate table for each year, as I had in the Word version, but I found that it was difficult to make the tables line up consistently. (I think at that stage I did not intend to make the tables full width, as they are now.) So I combined the tables for each year into one large table. But I still wanted to make it look like one table per year by removing the rules at the sides of each of the rows containing the year headings. It would have been feasible to use inline styling for each year heading row, but each year heading already had a class carried over from the style I defined for these headings in Word. This class would have made it easy and elegant to specify the style in a <style> element, but I couldn't do that straightforwardly because Moodle does not provide access to the HTML <head> element and the editor does not allow <style> elements within the body. I therefore used some JavaScript to work around this. I could have used JavaScript to modify or add a <style> element within the head but instead I modified the style of the relevant table cells directly.
Initially, I added a <script> element to the bottom of each chapter, which worked, but when I started modifying the JavaScript I learnt from experience that I needed a way to refer to one copy of the JavaScript to be run on every chapter, so I moved the JavaScript into a file that I loaded with a <script> element at the bottom of each chapter. I put the file in an orphaned section of the course area containing the book. This works well and should be easy for anyone to maintain. The JavaScript file currently does the following three things in addition to modifying the table styling.
- I no longer use anywhere near as much boilerplate text as I did in my Word version, but there is one complicated text segment that appears towards the top of all our BSc programmes. I maintain this in a separate chapter within a <div> element at the fragment URL http://qmplus.qmul.ac.uk/mod/book/view.php?id=489759&chapterid=43339#BSc and use AJAX code in the JavaScript file to load the boilerplate text into the chapter for each BSc degree. (A slight flicker is sometimes noticeable as this text is inserted after the page has loaded, but I think that's a price worth paying for the enhanced maintainability.)
- I have made the module code for each Maths module in a study programme into a link to the detailed description of that module. It would be very tedious and error prone to add and maintain all these links by hand, but fortunately that's not necessary. It is possible to find the single-page description of a module in our module database (described below) by searching for its module code, which allows me to use JavaScript to construct appropriate links automatically. My code searches for a "regular expression" that identifies a Maths module code and replaces it with a hyperlink that incorporates the module code as a search string. I have not found any way to do this for non-Maths modules because I can't find suitable module descriptions. In principle, I should be able to link to the Queen Mary Directory of Modules, but that page is unbelievably slow to load. Also, it is on a different server and if I tried to script it, which I think would be the only way to input a module code, it would require cross-origin resource sharing (CORS), which would almost certainly not be allowed (either technically or politically). So currently I only hyperlink Maths modules.
- Finally, I indicate important changes to study programmes from one year to the next. The natural way to mark up such changes is to use <del> for deletions and <ins> for insertions, but by default this markup is not very obvious, so I use some JavaScript to make deletions red and insertions green.
The sub-chapter of our study programme guide entitled "General guidance for students in the second and later years" is fairly long and consists of 15 subsections, each in the form of an answer to a question. This raised the question of how to ensure that readers can find the information they are looking for. One solution that I sometimes use is to provide a jump list at the top of a document consisting of the section headings linked to the sections below. But that solution just makes a long document even longer and is awkward to maintain by hand. So instead I decided to make the main content into a collapsible list. I implemented this as a accordion widget using jQueryUI by including a few lines of JavaScript at the bottom of the main content. One advantage of this approach is that if JavaScript is disabled the web page is still perfectly readable but no content is collapsed.
My JavaScript consists entirely of calls of jQuery functions and methods. I could have uploaded a copy of jQueryUI as a file, as I did with my own JavaScript file, but it seemed preferable to load it from a content delivery network (CDN) and I currently use CloudFlare (which seems to work very well and I recommend it). jQueryUI requires a style file, so the first line of my JavaScript adds this into the <head> element of the page. The jQueryUI accordion widget requires that each section of the accordion is contained in a <div> element, so the second line of my JavaScript wraps each section in a <div>, and the third line turns on the accordion widget with my chosen settings. I found that the default QMplus styling conflicts with the heading styling required for the accordion widget, so the second line of my JavaScript also moves each heading to the right to accommodate the triangle icon that indicates whether an accordion section is collapsed or expanded.
When I first added the collapsible sections I did not include any graphics to indicate that the structure was an accordion. But I became concerned that readers would overlook the instruction at the top of the page and not realise that they needed to click on a question in order to see its answer, so I added some additional JavaScript (from the jQueryUI site) to make the accordion respond to hovers as well as clicks. I left it like this for some time, but it began to annoy me (and so probably other users as well). It was just too dynamic and unpredictable when a section would expand or collapse. Therefore, I removed the hover code, and at the same time I updated the code to use the latest release of jQueryUI. This forced me to use different CDN links and hence to review the JavaScript and CSS files available. I decided to load the whole jQueryUI package, which provides several graphical cues that indicate that the structure is an accordion and whether sections are collapsed or expanded. I think this version is the most accessible I have produced so far, except that the styling was completely hiding hyperlinks, so very recently I added a line of JavaScript to underline them. (This is not shown in my evidence below.) I am happy with this version for now, although in principle I should load only the support I need for the accordion widget and not the whole jQueryUI package!
Evidence
- Study programme guide 2016–17 is the latest version (at the time of writing) of this Moodle book and the Archive of study programmes from previous years provides access to earlier versions, of which the hyperlinked PDF document Study programmes 2013–14 is the last version that I generated using Microsoft Word. (The final year of the 2013–14 study programme for GG31 BSc in Mathematics and Statistics illustrates the way I used rules between table cells in the Word version to try to elucidate the programme structure, which I no longer do in the Moodle book version.)
- My JavaScript file, which I load into each study programme chapter, is publicly accessible and should open readably in a web browser. (Beware that at the time of writing it includes an old version of the linking code that I have commented out.)
- This screen shot of the first three years of the four-year programme GN1H MSci in Financial Mathematics shows how I indicate deletions and insertions, which are marked up using <del> and <ins>. (Note that the module codes are blue because they are hyperlinks.)
- This is my JavaScript to implement an accordion widget using jQueryUI.
Module details as a Moodle database
Description and Reflection
Having decided to use a Moodle database for our module details, my first task was to choose appropriate field names and types in a sensible order. It is very important to get this right because, as I learnt the hard way, it can't be changed retrospectively! I set up a few trial versions that were successively closer to the final version and put some test data in to make sure it worked. I used the HTML that I generated from my XML master file as a guide rather than the XML file itself because I wanted to produce a new system that would be easier for somebody else to maintain. Once I had a field structure that looked like it would work, I transferred the information from my XML-based system. I did this by writing an XSLT file that generated a CSV file, which I could then import into the Moodle database. This was not quite as straightforward as it should have been and required some shoe-horning by hand, but it was a one-off process. The problem with CSV is that it is not a well-defined format and was probably never intended for large records containing very heterogeneous data. An example of the kind of problem I ran into is this: If double quotes delimit fields, will an end-of-line character within a double-quoted field be treated as a record separator? If so, one needs to encode "internal" line endings and then decode them once they are in the database. (XML, by contrast, is a well-defined format!)
A difficult design decision that I had to make fairly early was how to handle prerequisites and overlaps, which can have a complicated logical structure. I wanted this structure to be clear when displayed as one page per module with plenty of space and also when summarized in a single table row. I chose to use list-based HTML markup augmented with classes to indicate the logic. The essential prerequisites for MTH6132 Relativity illustrate how this works and are about as complicated as the logic gets in practice. They are "MTH4101 Calculus II, and (MTH4102 Differential Equations, or MTH5123 Differential Equations), and MTH5112 Linear Algebra I", which I summarize as "MTH4101, MTH4102/MTH5123, MTH5112" and mark up as
<ul class="prereqs-and">
<li><span class="mod-code">MTH4101</span><span class="mod-name">Calculus II</span></li>
<li>
<ul class="prereqs-or">
<li><span class="mod-code">MTH4102</span><span class="mod-name">Differential Equations</span></li>
<li><span class="mod-code">MTH5123</span><span class="mod-name">Differential Equations</span></li>
</ul>
</li>
<li><span class="mod-code">MTH5112</span><span class="mod-name">Linear Algebra I</span></li>
</ul>
The classes I use in the <span> elements primarily allow me to control whether I display the module names and the classes I use in the <ul> elements allow me to generate words or symbols that indicate how the modules combine to form acceptable prerequisites. The absence of any space between the module code and name in the underlying data is important (and in retrospect possibly a bad design decision because it is counter-intuitive). I think that following this markup protocol will be the most difficult aspect of this database for somebody else to maintain. I generate both the list view and single-page view of this markup purely by using CSS, which adds the required words, symbols and spacing. I use JavaScript to construct the full linear version as a title attribute on the table cell in list view so that it pops up on hover.
The HTML generated from my XML file originally linked to learning outcomes as fragments within a separate page on our web server, so one of the next things I did was to copy the learning outcomes for each module into the appropriate database field, thereby making the Moodle database more self-contained. (I would probably have made the same change to my XML system if I had not decided to replace it.) Unlike most of Moodle, databases provide specific support for CSS and JavaScript, although whilst I use the CSS facility I currently put my JavaScript at the bottom of the HTML template sections and not in the JavaScript template. Doing it this way means that I can allow the JavaScript to run as soon as it has been read, since the DOM elements that it will modify will have already been created by then. The next step was to start adding some CSS. The default templates provided by Moodle assign alternating classes to alternating table rows and use these to stripe the rows. But this is horribly inflexible. If you decide to move any rows around you have to reassign the row classes. So I abandoned this in favour of CSS3 selectors that count elements.
I found that the Moodle database list view (of the module summary table) displayed more slowly than I would have liked and I thought the problem might be that the browser was taking time to auto-format the fairly large table, with around 60 rows and 6 columns. I therefore spent some time experimenting with fixed column widths, which I still use, but this didn't help. I have concluded that the problem lies with Moodle and not the browser, so I can't do anything about it. The download delay is just about acceptable.
In order to provide a summary of module restrictions, I added more columns to the list view to show the restrictions. This makes the table too wide to view, so I used JavaScript to provide two versions of the list view. I defined classes for the columns that I want to be able to hide or show and I added a pair of radio buttons that control which columns are visible. The column switching is very fast and could be generalized to provide an arbitrary number of different list views.
By default, a Moodle database displays 10 rows and provides controls to show more rows. This doesn't really make sense for our module details – you really need to see all of them together – and naive users may not spot the row controls at the bottom of the page. I learnt this from my colleagues when they began to complain. My solution was to add some JavaScript that sets the number of rows to 100, which is large enough to display all our modules, and to hide the row controls. Unfortunately, this causes the page to reload, although only for guest users or the first time a logged-in user accesses the page because Moodle remembers the setting after that. I also added some local memory so that page refreshes do not change the current view.
Moodle allows the user to change the list view sort order, but not very flexibly or conveniently, and it forces a page reload, which is slow. I therefore added support for the jQuery tablesorter package, which allows very fast and sophisticated sorting on multiple columns. To allow useful sorting on the module organiser field I wrote a custom sort function for that column, which guess the relevant part of the field. Sorting the table using JavaScript only makes sense if the whole table is displayed, so this customization is intimately tied in with the previous customization that forces all records to be displayed.
My most complicated customization is the JavaScript I use to construct HTML title attributes, as described above, and to abbreviate some of the less structured information displayed in list view by copying the full information into the title attribute and truncating the information displayed as content. It took some trial and error to decide how long to make the truncated displays.
The main displays are straightforward transcriptions of information from the database but I use JavaScript to customize one or two aspects. For example, if I have not created a QMplus course area for a module (either because it is in some way special or simply because it is new and I will create the course area later), I do not want to create a broken hyperlink to the non-existent course area, so I generate link text using the JavaScript "document.write()" method within conditional code and if the QMplus page id field is empty I output unlinked text.
After I had designed the database field structure, we decided to introduce level-6 versions of some of our level-7 modules. It makes sense to keep almost all the information for the level-6 and level-7 versions the same, but I wanted to indicate clearly that these are split-level modules by displaying the level as 6/7. Unfortunately, I had set up the field type to be numeric, so it would not accept 6/7 as input and I could not find any way to change the field type retrospectively. Moodle databases are not very flexible! Instead, I entered the level as 6.7, which is numeric, and then used JavaScript to change the display to 6/7. This has the unintended advantage that level 6/7 sorts automatically between 6 and 7!
I would prefer a more elegant solution but I can't think of one that is practicable. The only way I can think of to change the field type would be to export the content and import it into a new database with the right field types. But my experiments suggest that this would not be straightforward because the exported CSV cannot be re-imported without reprocessing it. I think this is because of line breaks in the larger HTML fields, which get misinterpreted as record terminators, to which I alluded above. So I feel that a few hacks are justified until it becomes really imperative to restructure the database!
My most recent update was to add a subject area field and provide a jump list in list view that selects only modules in a specified subject area. I did this in response to a request from our students that came to me as a member of our student experience working group, but in fact it had been suggested a while ago by members of our professional services staff who need this information to allocate teaching assistants to modules. The jump lists were very easy to implement and just use the standard Moodle search facility, although not the standard Moodle interface to it. I used some trial and error to work out the required search URL and just wrote that into the links in the jump list. This facility doesn't currently use any JavaScript!
At present, most of the information in our module details database is copied into various places in the separate module course areas, but some information is only in the module course areas. One of the next things I want to do is to rationalize this situation by copying all the information into the database and then either linking to it or using AJAX to load it into individual module course areas – I haven't decided yet how best to handle this. I have experimented with using AJAX and I think it will work but I don't want to use so much JavaScript that the database becomes unmaintainable!
Evidence
Our latest module details database is publicly accessible as Module details 2016–17 and previous versions are publicly accessible in the Archive of module details from previous years, which shows the changes of format. The older versions up to academic year 2010–11 were generated using a system initially developed long ago by a colleague that used a master file with a non-standard format based on LaTeX. The versions from 2011–12 to 2013–14 use my XML-based system and the versions from 2014–15 onwards are Moodle databases.
The Moodle database template includes a CSS section, which generates this separate file containing the CSS I wrote to customize our module details database. It should open readably in a web browser. The first few lines currently style tables embedded within the main single-view table, which I am in the process of adding from individual module pages because it is information that should be held centrally. The next section sets up the classes to hide specified columns and sets the fixed column widths in list view. The following section handles the display of prerequisites and overlaps. The final section supports list-view table sorting and I think I just copied this code from the tablesorter style file.
The following snippets of JavaScript show how I use jQuery to implement the radio buttons that select which version of the list view is displayed. This code is visible within the source code for the list-view HTML page and should be accessible using any web browser but may be tricky to find. The first snippet initialises the variable "show" from the web browser's session storage if possible:
// Support page reloads and updates
// Note that sessionStorage is only defined in IE via http, not via file!
try {
var show = sessionStorage.getItem('showWhat') || 'show-organisers';
}
catch (e) {
var show = 'show-organisers';
}
The next snippet sets the appropriate radio button to be selected initially and the corresponding table columns to be displayed:
$('input:radio[name=showWhat]').val([show]); // REQUIRES array - not clear from docs!
$('div#list-view').attr('class', show);
The last snippet makes the radio buttons active by attaching a function that is called when the radio button state changes. It gets the current state and updates the table columns to be displayed. It also saves the radio button state if possible.
$('input:radio[name=showWhat]').change(function () {
var show = $('input:radio[name=showWhat]:checked').val();
$('div#list-view').attr('class', show);
try {
sessionStorage.setItem('showWhat', show);
}
catch (e) { /* Ignore any exceptions */ }
});
Past exam paper repository as a Moodle database
Description and Reflection
Based in part on my experience of using a Moodle database for our module details, I decided that a Moodle database would provide a good repository for our past exam papers. Setting it up was much more straightforward than was setting up our module details database. I use seven fields of which only six are explicitly visible: three for module level, code and name, and three for exam papers from each of the past three years. The fourth field in the underlying database is the id number component of the URL of the QMplus course area for the module, which I use to link the module code and title to the course area. The single-view template is fairly similar to the default provided by Moodle and does not use any JavaScript, so it is not very interesting and I will not discuss it further.
I use three lines of CSS in the CSS template section, which I include in my evidence below. My CSS left-aligns column headings and automates table row striping for both views, and it sets the table cell padding in list view to give compact row spacing but enough spacing between columns to make them readable.
The list-view template is more interesting and I include the full code in my evidence below. I include a few lines of JavaScript at the bottom of the list-view template, which has the advantage that it will only run in list view, whereas if I put it in the JavaScript template it would run in both views. For this particular database it would not do anything in single view except waste resources, but more generally it might be necessary to include conditional code so that the appropriate JavaScript runs in a particular view. Generally, I think it only makes sense to use the JavaScript template for code that should run in both list and single view.
The list-view "Header" code generates the opening <table> tag and <thead> element and any content required before the table, although for this database I don't currently include any content before or after the main table. The list-view "Repeated entry" code is applied automatically by Moodle to each record in the database and outputs one table row per record. I use the template code to construct the hyperlinks. The list-view "Footer" code generates the closing </table> tag and then runs my JavaScript, which consists almost entirely of jQuery. Most of this code requires the whole page to be loaded, not just the preceding table, so I use the elegant jQuery idiom of passing a function as the argument of the $ function, i.e. $(function() {…}), to run my JavaScript after the page has loaded. The code ensures that all records are displayed automatically, using the same technique that I described above for the module details database. It then shortens the file names and removes the ".pdf" extension by editing the file names in order to make the table more compact without losing any useful information. I don't feel that this is necessary in single view, for which the information displayed and hence the table is much smaller.
It occurs to me that for next academic year I will need to revise this database in the same way that I revised the module details database to accommodate our split-level modules, which were new this year and so will have past exam papers from next year. Or I might just remove the level column instead! It is not strictly necessary since the level is indicated by the first digit of all our module codes.
Using a Moodle database as a file repository works well from the user's perspective but there is one snag from the maintainer's perspective. I designed the database to make it easy to roll forwards each year by deleting the oldest year field and adding a new one at the bottom of the field list. However, I find that as soon as I have uploaded a file to one database record, this file appears automatically as if it has already been uploaded to every other record, but only when editing. I hoped this was a transient glitch that would go away, but it hasn't. I also thought it might be a quirk of the platform I use or that I might have done some damage to the database when I was developing it. (I attempted to re-order the fields in the underlying database, which caused havoc, so I had to back out of this change as best I could.) It's something that I should try to resolve and report as a bug if appropriate.
Evidence
I expect our Past exam papers database to remain publicly accessible for the foreseeable future, and the source code for it as output by Moodle can be viewed in any web browser. However, this is not in all cases exactly the same as the source code input to Moodle, so I provide a snapshot of the current source code for list view.
Further reflection
I decided that it would be a good idea to gather the views of Maths staff and students on our main sources of generic undergraduate information in QMplus, namely our landing page, study programme guide and module details database, all of which I created and/or maintain. I therefore created a very short, simple and anonymous Maths Information Questionnaire, which uses the Moodle questionnaire plug-in. Since only logged-in users can access questionnaires, I include a PDF printout of the final version of my Maths Information Questionnaire as evidence.
Just before I ran my questionnaire, fairly wide-ranging surveys of the views of all Queen Mary staff and students on e-learning provision had been run centrally, so I decided to focus on just three very specific aspects. These include the facilities I described in the first two above, but not the past exam paper database, which is very straightforward and so has little scope for improvement.
I created an initial draft of the questionnaire, which essentially consisted of the bottom two questions on each page of the final version but all on one page, and then invited comments from our Teaching and Learning Committee. I immediately discovered that staff could not access the questionnaire because they access the QMplus course area I used as viewers rather than as students, so I changed the permissions on the questionnaire to allow the viewer role to access it. I then received the suggestion explicitly to include two different aspects of the provision of information: firstly, how easy the information is to find and, secondly, how useful it is once you have found it. This led me to add the questions about access that are at the top of each of the three pages. Further suggestions from my wife (as a disinterested commentator) led me to split the questionnaire into three pages with the details of the resource considered on each page moved into the page heading, clarify the wording and make the hyperlinks more obvious. (The current default QMplus styling makes hyperlinks very hard to see.)
Once I was happy with the questionnaire, I invited all permanent academic and professional services staff in the School of Mathematical Sciences who have any involvement with undergraduate students to complete the questionnaire within about three weeks. My hope was that this would demonstrate that the questionnaire made sense and allow me to check that I could analyse the results, both of which turned out to be the case. I then invited all Mathematical Sciences undergraduate students to complete the questionnaire during May. This timescale prevents me from considering the results of the student survey here, but I include a PDF printout of the full staff response as evidence. After I had sent a reminder, 22 out of a possible maximum of 69 members of staff completed the questionnaire, which I think is a good response rate, especially since this was during a vacation and not all 69 staff are involved with undergraduates.
The response statistics suggest that the accessibility and quality of the information I asked about is adequate, but as always could be better, and I received some helpful suggestions about how to improve it, which I will pursue. There are a few minor issues that I should be able to fix quickly, some that will require more consideration and some that are out of my control. Apart from genuine inadequacies in the provision of the information, the survey also picked up a number of issues that I think are misunderstandings about how to use either facilities I have developed, QMplus itself or web browsers in general. I provided feedback to staff via a broadcast email, in which I also tried to clarify some of these misunderstandings and I include a PDF printout of this email as evidence. Generally, I was pleased with the responses, which could have been far more critical than they were! Interim results of the student survey look encouraging, with 27 responses by late May and statistics that are broadly positive but fewer comments than from staff.
These very specific questionnaire results, together with the more general results from the central Queen Mary surveys, will feed into our School e-learning strategy, which we will be working on over the summer.
One gratifying consequence of the module details database that I developed has been that one of my academic colleagues, who this year has taken over as Director of our MSc in Mathematics, decided that a Moodle database would be a better way to present the MSc projects that we offer, many of which are also available in restricted forms to our MSci and BSc finalists. She successfully bid for support for an "e-learning assistant" to transfer the content from a Moodle book (that I created a few years ago) to a new Moodle database. I have acted as an informal consultant on this project and I have been able to share some of what I have learnt about Moodle databases with the colleagues who have been involved in creating this new project database. It was decided to keep this new database simple and not use any JavaScript, but this decision shows up some of the limitations of Moodle databases, in particular, that the standard server-based sort facility has limited capabilities and is slow!