Feedback for Faculty

[SethBattis]

Canvas analytics rock for developing feedback and learning strategies for students, but faculty need support and feedback too. We'll share our current "grading analytics" system that combines quantitative feedback with qualitative guidance for our faculty in their use of Canvas as a teaching tool, helping everyone hit the high notes.

Presenter: Seth Battis​ - St. Mark's School

  Location Map & Room: BISON 3-5

  Login to "Add a comment" below!

               

[SethBattis]

I'm still working on putting together exactly what I'm going to say next week, but I know that it's going to be chapter 2 of last year's presentation: I'll talk a bit it about why and how we've developed our faculty feedback system, how we use it, and look a bit more deeply at where we've gone with it this past year at school.

Last year's presentation is online, if you want to see chapter 1 (which I will recap at the outset, to be sure).

Slides, links, etc. coming soon to an event near you!

[SethBattis]

For reference, here are the resources that I am/will/did mention(ing) in this session:

1. Our Grading Analytics package. This runs on a LAMP stack and uses the Canvas API to harvest data nightly. We use the Global Javascript to add links to the analytics views into the Canvas interface where they make sense (rather than where LTIs are allowed to add links), and then present the views on our own LAMP server. In our case, we're using an AWS EC2 t2.micro Ubuntu instance as our server, which resides in the same cluster as our Canvas instance (which makes API calls 4-5 times faster than making them from our campus).
   • Stable release versions are posted to Github.
   • As are known issues. (Some of which are embarrassing.)
2. Our whole Global Javascript package, which combines a number of other modules like the Grading Analytics package and merges them into a single Global Javascript file. At the moment, we do this by using Git submodules, to pull in updates from the various packages at our discretion. I'm looking at shifting to more of a PHP Composer workflow for this, to simplify the Git overhead. Included in this package are:
   • Faculty Journal, a tweak to make the Faculty Journal browse-able by course, rather than student, accessible from the People page of courses.
   • Navigation Menu, a tweak to add additional menus to the top navigation bar of Canvas (you'll see them in my screenshots), including click-tracking data.
   • Templates, a tweak for course-level templating of Assignments, Wiki Pages and Discussions. (Only basic assignments are currently enabled, because I slapped it together right before our end-of-year faculty meetings, and I didn't want to enable features that were still… idiosyncratic.) A quick walk-through video is online.
3. SMCanvasLib, our current library for… well, for hacking Canvas. I slapped it together to generate webpages dynamically, connect to the Canvas API more seamlessly, manage MySQL queries, and generally "do all the stuff" that all of my various hacks had in common. Almost all of our other packages rely on SMCanvasLib as a submodule to get things done. This too is probably going to shift towards a Composer workflow over the summer (gradually), to reduce some of the Git overhead and to pull apart some redundancy and over-complication verging on obfuscation.
4. CanvasPest, a PHP object for interacting with the Canvas API. This is the first step that I've made towards pulling our SMCanvasLib back into more manageable chunks. It is a Canvas-specific extension of the excellent Pest, "a proper REST client for PHP". It's sort of mid-development right now -- the basic functionality is in place, essentially replacing the CanvasApiProcess object used in SMCanvasLib, and I'm working on generating responses from the API that are seamlessly iteratable (iterable?) across Canvas response page-breaks.
5. Coming soonish, I think, I will also have a CanvasHack LTI, which will allow me (and you!) to more seamlessly develop hacks that follow my design pattern (Javascript tweaks to the Canvas UI / LAMP-based processing/presentation / Canvas API data collection/modification). The model is that the CanvasHack would integrate via an LTI to get authenticated user/course information, which would be fed back to the LAMP server to do… whatever with. It's still in the design stages, but it feels like it will be useful enough to me to be worth building… for me.

[SethBattis]

…and here are the slides for this talk. (Not, I think, particularly penetrable without my lucid narration, but good as a reminder.)

[SethBattis]

It has been suggested that an overview of moving something from Github to production might useful. This is a one-take version, that ends with a touch of (unintentional, authentic, realistic) troubleshooting.

[CommunityTeam]

The session video is now available at: