The last day of Hack/Doc, as usual, was a bit shorter due to attendee travel plans. We wrapped up around lunchtime after some discussions about Moodle 3.8 and accessibility.
Forum grading accessibility
We logged a third and final issue with the new forum grading tool and accessibility: MDL-67663. Again, some of these issues are specific to the tool, which some are broader problems with Moodle itself. We’ll continue to monitor the situation. A major related issue is MDL-64494, where Moodle core is tracking project-wide color contrast issues.
We discussed the future of Swarthmore’s “filescan block“, which evaluates the accessibility of PDFs uploaded to Moodle. Several schools, including Hampshire and Lafayette, have been using the block on their Moodle instances. CLAMP is going to organize a workshop this winter for interested schools to come together to develop a roadmap and implement changes, which an eye toward publishing the plugin on the Moodle plugins repository and incorporating it into the Liberal Arts Edition.
We have released a new version of the Roster report; you may now configure which fields are displayed for each student, including custom profile fields. This release is available on the Moodle plugins repository and will be incorporated into the next release of the LAE.
And that’s a wrap for this winter’s Hack/Doc at Swarthmore College. Warm thanks to Andrew Reuther and Swarthmore for their outstanding hospitality this week. If your institution is interested in hosting a future CLAMP event, please consider filling out our host interest form.
Hack/Doc Fest Winter 2020 at Swarthmore College: Event page | Day 1 | Day 2 | Day 3
As the final day of Hack/Doc Fest at Butler wrapped up the team continued its accessibility work, reviewed the course overview plugin, and discussed our upcoming Moodle 3.1 recommendation.
On Day 2 we created a long “scroll of death” course with numerous accessibility issues baked in. On Day 3 we began building out the improved versions of this course using stock Moodle, the grid course format, and the collapsed topics course format.
Work on the courses will continue beyond Hack/Doc. Next steps include:
Evaluating the updated courses with various accessibility tools to verify that we truly fixed all the problems.
Writing a blog post describing the various issues with the badly-designed version and how they were addressed in the fixed ones.
Publishing the courses to a “Moodle Museum” category in the CLAMP Moodle Exchange.
In addition we discussed having a having a “Moodle Accessibility” online hangout in July and contributing the example courses to Moodle core for use in their demo site.
Related to these efforts we looked at how to create an “accessibility” toggle for the Grid Course Format that lets users switch between the grid-style course and the default topics course. Issue #23 in the Grid format project discussed ways of doing this but it took some experimentation to make it a reality.
Matt Wright from Butler University demonstrated their use of the Course Overview on Campus plugin. The plugin replaces the default “my courses” page with a dropdown that lets the user browse through all the course categories on the system. How the courses are listed (e.g. title, short code, teacher) is configurable. The list still includes course-specific action items (e.g. a course assignment needs review) but it is concealed in a collapsed content area by default.
The category selected is preserved between sessions, so if user choses the “Fall 2016” category it will be there waiting for them the next time they log in.
Working on a Moodle 3.1 Recommendation
We will be working on our recommendation for Moodle 3.1 over the next week and hope to have it published on June 29. At this point we don’t see any major blockers, but there are a few things (like annotation in the assignment submission view, whether to turn on the Competencies feature, and improvements to cron) that colleges should consider before upgrading.
During Day 2 of Hack/Doc Fest at Butler the team tackled a review of third-party plugin compatibility with Moodle 3.0 and 3.1, continued our accessibility work by testing new tools and documenting best practices, reacquainted ourselves with the Workshop plugin, and delved deeply into Moodle 3.1’s new Competencies feature.
We compiled a list of popular 3rd party plugins for Moodle and then determined if they are compatible with 3.0 and 3.1. Of particular note were the following plugins, which list compatibility with 3.0 but not 3.1:
Course Overview was tested under 3.1 and seemed to work just fine. That said, the way it is configured changed in 3.1; it is now difficult to get to all of the settings on one unified page.
Continuing our work from Monday, we created a “scroll of death course” — aka an exceedingly long course — with a variety of accessibility issues. The course was created using the TinyMCE WYSIWYG editor, but edited using Atto.
As expected, Atto couldn’t fix much of what had been done incorrectly using TinyMCE, if for no other reason than it didn’t have the same editing options. Many of the problems in the course had to be fixed by going into the source HTML and editing it there.
Once the new course is completed, we’re going to create the following example courses that address the “scroll of death” issue while improving accessibility and usability:
an accessible course using stock Moodle
an accessible course with Collapsed Topics course format
an accessible course with the Grid course format
We also intend to look at an option that allows students to switch switch course formats (e.g. grid to topic) to help with accessibility. This requires the user to set a custom profile field called “accessibility” which — when toggled — lets them switch to a designated “accessible” course format.
We spent some time experimenting with screen readers on Moodle and other websites. We started with ChromeVox, a plugin for Chrome that allows you to tab through a page and reads the elements to you. The lack of mouse support made it more difficult to use and there isn’t an obvious way to toggle the plugin on and off.
We experimented with TalkBack on Android. It works great, but it radically transforms the way you use your phone and introduces a number of double and triple click command for common tasks. It requires you to re-learn how to how to navigate your phone.
We also researched optical character recognition techniques and found ConvenientOCR is a plugin for JAWS. This plugin lets you mouse or tab over an image and then OCR it. We did not get to try this plugin, but it sounds promising. JAWS itself is an expensive piece of software that only runs on Windows, but there is a free trial version for those who want to check it out.
A number of schools are planning on turning off the PDF annotation component of Moodle until the issues with it are resolved. However, before turning off the feature we wanted to know how many people were using that particular feature at our institutions. We created an ad hoc query that looks for the use the annotation feature in Moodle assignments by identifying occurrences of “comments” and “annotations” in the database.
We fixed two issues with the CLAMP website. We’ve resolved the SSL cert error that occurred when you tried to browse www.clamp-it.org under https. We also fixed a bug that would redirect you to an account sign-up page when accessing http://clamp-it.org.
Printing Quizzes in Moodle
We continued looking at ways to print quizzes and documented a technique involving embedding a quiz within a “book” within Moodle. View the documentation.
We revisited Moodle’s Workshop module and found it to be a good peer assessment tool and fairly easy to set up. The tool has different student grading options including
comments, no grades
comments and grades
rubrics (which are different than assignment rubrics)
We spent considerable time at Hack/Doc reviewing Competencies and have come to the conclusion that it’s a complicated new system with an inherent workflow that isn’t well documented.
Here’s how the documentation describes Competencies:
“Competencies describe the level of understanding or proficiency of a learner in certain subject-related skills:”
In brainstorming use cases for competencies at our colleges the scenarios that stood out the most were those where some sort of interdisciplinary or cross-institutional outcomes needed to be tracked. For example, a writing program that establishes a set of skills that students should develop during their time at the college. Evidence of acquiring competency in those skills could be provided in a variety of ways:
Evidence submitted by students
Evidence submitted as part of a course activity
Evidence submitted by faculty for students.
Moodle Competencies handle this through three tools:
Competencies: The building blocks of the system, competencies establish a specific goal, and provide a mechanism for giving evidence that the goal has been met.
Competency Frameworks: A collection of competencies.
Learning Plans: A method for pushing out a particular set of competencies (possibly taken from multiple frameworks) to students.
The single biggest challenge with Competencies is that it assumes you have an existing offline workflow and framework and want to implement it in Moodle. If you have those things, we expect that the tool makes a lot more sense. If you don’t, then the published documentation isn’t going to help understand the usefulness of the tool or how to implement it at your college.
In addition, Competencies itself has an implied workflow that isn’t obvious to laypeople. For example, there is a process for students or faculty to request review of competency evidence. The per-student requests for such review appear on the “My Moodle” page, but it’s not clear if there is a place where faculty or learning plan managers could go to see the progress of an entire student cohort (e.g. not just an individual student’s progress toward meeting competency goals, but the entire cohort’s progress).
The development documentation does a much better job of explaining the purpose of Competencies and does a better job of explaining how the various pieces fit together.
CLAMP kicked off Moodle Hack/Doc Fest on Monday, June 21 with our traditional sprint day. The sprint day exists for everyone to get a jump on the week’s work — a few people (in this case, most of those attending Hack/Doc) arrive early, resolve any logistical challenges (getting to campus, connecting to the local network, making sure sources of caffeine are available throughout the day), and start organizing the week’s worth.
During this sprint we came up with our usual tasks list in Google Drive and people signed up for the things they were interested. Then, in a fit of spontaneous documentation, everyone started using that tasks list to provide updates on their progress. It’s not a thing we’ve done before, but it’s working out very well — it provides a running log of what we were working on, and it’s more efficient because we don’t need to spend as much time reporting out each day.
Topics identified include:
Accessibility – Making Accommodations for Users with Disabilities
Managing the “scroll of death” on course pages within Moodle
The practical implementations of layering quizzes over video
Evaluate the Moodle Mobile app
Printing from Moodle
The Recycle Bin plugin in Moodle (new feature in Moodle 3.1)
Evaluate the Mass Action block (3rd party plugin)
Evaluate Competencies (new feature in Moodle 3.1)
Test out the Global Search
Document, test, and name the new umbrella course plugin (3rd party plugin)
Look at other major changes in Moodle 3.1
Review anonymous forums in Moodle 3.1 (Moodle Liberal Arts Edition)
Review Ad-hoc database queries (customsql) (Moodle Liberal Arts Edition)
Best practices for using Moodle with other schools
In the course of our work we came across a gnarly problem involving the new assignment review interface. This interface allows the user to see a student’s submitted assignment alongside all the relevant grading fields (e.g. add a grade, comments, etc.). The student’s work is rendered as a PDF and the teacher can use Moodle’s annotation capabilities to mark up the paper with their responses. The end result is saved as a PDF and sent to the student as feedback.
The problem is with the PDF. If students submitted a PDF, then the process works reasonably well. If they submitted a Word or Open Office document instead, Moodle converts it to PDF for display … or tries to. If you do not have a specific helper application known as unoconv installed on the server (and in our experience, it’s unlikely you will have it), then the PDF conversion fails. Instead you get a blank page. That blank page can then be edited with the annotation tools and submitted as feedback, but that’s not particularly helpful since the student’s original assignment isn’t included.