D2L Fusion 2017 Recap

Every year it’s a bit different; some new faces appear, some old ones disappear. Jobs and roles change, focus changes. Las Vegas is a place that exemplifies an absurd demonstration of capitalism at its most consumer-driven absurdity. With the event happening in Las Vegas, I thought that D2L might be subtly telling us that they were taking a gamble. Turns out, that the gamble is not a big, all-in shove to take the pot, but perhaps a less-sexy gamble of shying away from glitzy announcements, to a more mature, iterative approach.

People talk about Las Vegas light shows being spectacular, but the one over Oklahoma City was pretty dang cool.

Flying Near Lightning from Jon Kruithof on Vimeo.

Usually in my recaps I’ll talk about the sessions I attended and what I learned. This year, was like every other, the sessions were well done, interesting, and useful (although maybe not immediately useful in my case). I won’t break down each thing learned, or really talk about what the learning was, instead I’ll reflect on the conference as a whole and maybe some of the underlying things that were interesting.

My focus this year was to really better understand two things, API extensibility and the data hub (Brightspace Data Platform, or BDP, which is awful close to ODB). I think I did that. I attended one session that described how they use the API to scrape everyone’s course outline, which was cool because that’s something that has come up periodically at McMaster, and I’ll have to get in touch with them to see how they handled ownership and other matters. It’s that fine line that admins run up against, where they can do things, but should they? We often fall on the no, we shouldn’t side.

I didn’t really pay attention to the keynotes – John Baker’s become quite a good speaker – but I’ve heard it before. I’ve been working at D2L clients now for almost a decade. I’m probably as intimately familiar with the product as many of the people working at D2L. Ray Kurzweil is interesting as a person, and I appreciate some of his theories, I don’t think the singularity will happen (we may approach it, but never achieve it) and I don’t really dig his speaking style. The talk (for me) really circled around the changing nature of work and that is a reality of my everyday.

I did a session about the work we’re doing badging faculty for skill in LMS use, more in another post about that.

I saw echoes of what I’ve done around faculty training in other presentations (which I stole from others whom I’ve worked with and talked to). More importantly, I walked around chatting with folks I know, wondering if this was still right for me? Is EdTech still the thing that I want to be working in? I’ve been in this field since 2001 (or 2003, or 2005, depending on when you want to mark my start – whether as a computer programming co-op student looking after a language lab, or when I graduated or when I first started working in higher education relatively uninterrupted). That’s a long time. I’m still energized by seeing the exciting things that other people are doing. And almost to a person, whenever I say to those people, “hey that’s awesome” or express my interest, there’s the same, humble responses of surprise that anyone would want to talk to them about what they’re doing. I don’t know if that’s a Fusion specific thing, or an EdTech person thing, or just my humble radar forcing me to talk to those people.

It also reminded me that any interesting work was extending the LMS –  using Node.js to create an Awards Leaderboard, doing data analysis for LMS wide analytics using the Brightspace Application API. Hell, even understanding what the Discrimination Index means in the Quiz tool.

My personal underlying theme was that there’s more that can be done with the LMS if you extend it’s capabilities. I think we’re on the cusp of doing just that. 

Once again, it was a fun after the conference experience. Hanging out with some of my favourite people (and recognizing the posse from just a few short years ago is just about gone!).

 

D2L Badging

So, I’ve been poking around with D2L’s badging/certificate since it was unveiled in September (and actually writing this blog post since then!) on our test instance and it’s been a fun thing actually thinking about and configuring a new tool. It’s been so long since I’ve actually spun something new up – that I had to really work the part of my brain that frankly hasn’t been worked in a long time – the “what if?” part. What really stinks is that with badging we actually don’t want to have every instructor available to create badges. That simply means controlling access to the tool via Navigation Bars (which we don’t allow our instructors to change) or creating a new role. Either way is a bunch of manual work for me.

The one big problem, and this isn’t by any means a knock against us, is that I haven’t had time to properly configure this on test in a way that makes testing easy – I’ve just been too busy working with ePortfolios and PebblePad to take the time. Thankfully there’s documents like the Assessments Administrator Guide on the Brightspace Community that help a lot when working through the user permissions (which frankly are poorly documented) and what used to be called DOME variables (now Config Variable Browser). So we’ve slowly got the technical side working and we’ve run into a huge issue that could conceivably cripple the whole damn thing. Issuing a certificate or award (or digital badge) means that we’re giving power to instructors that Registrar’s previously held very closely to themselves. So, we’ve devised a way to do this without ruffling institutional feathers – and with a way to control how the badges are used.

We really want to avoid badging as another way to give grades or learning outcomes. There is already a wealth of tools in the LMS that do this (uhhh, Grades and Competencies/Outcomes) so do not recreate what you already do and add a pretty picture to it. That is useless, and students will inevitably find badges useless in that context. More importantly, external parties will find badges useless, which if you really want badges to hold some value, then you will need external people to value them. Giving a badge that says you got an A in a course, is frankly useless (as useless as the A is in determining what a person is capable of or knows).

So as an institution we are looking at ways that we can ensure that people using badges are using them in ways that actually contribute to the student experience, by either awarding badges that have no representation elsewhere (like experiences that could make up a part of a co-curricular record) or awarding badges for skills that are not explicitly found within the core curriculum. Students already have a transcript that uses grades as a way of communication ideas about broad topics. Students should have learning outcomes that syllabi tell them are the important aspects of those courses. Don’t bother recreating the wheel – higher education already has a few that work well enough. Focus on what doesn’t get communicated already.

Our initial plan was to have training help people through this process and when they complete the training, they can then issue badges within their courses context. We’re still doing that – but with an added wrinkle. By the end of the workshop, instructors have designed at least one badge, thinking through the visual design (and sketching it out), the implications of what a digital badge means, how this badge might connect to external groups, what criteria or release condition will issue the badge and finally, how they might value badges coming into the course from other sources.

All of this on paper. Then people can have a serious thought about how it’s technically going to happen. Essentially it’s a two hour enforced planning session.

What will inevitably come up is that some forward thinking instructor will ask “what if we want to have students give each other badges?” and the answer will be “they can’t (providing that the student role is configured in a typical way that controls access to courses)”. It’s a huge gap that’s not a problem with the tool, but with the design of the LMS.