Why Are Systems Administrators for the LMS Such Dicks?

Full disclosure. I’m an LMS administrator, and I’m probably a dick. I will say, in my defense, that I’ve never set up a system from scratch, but have contributed to configuration discussions, so I’ve been close to the decisions that get made in configuring a system, I’ve never had to do it.  I have, however, had the opportunity to change the system and still have not, for many legitimate reasons. However, the controls that we could configure to be adjusted by the end user, in all practicality cannot be configured in that way due to the constraints of the software. The only platform that could be configured in such a way was First Class, which wasn’t an LMS, but a communication platform for collaboration (think SharePoint, but functional).

What if faculty could choose the tools they wanted, and essentially plug them into a system that housed their content and managed the enrollments? I don’t see this as any different than a faculty member choosing a textbook – however, the education system and people like me, LMS administrators and educational technology advocates everywhere, have made choices like this all but impossible because of the infantilism of faculty. We often treat faculty like they couldn’t, or shouldn’t make these choices. As educational technology professionals, we often just espouse what we think in much the same way a parent lectures their children. We talk about ways that technology should be used, instead of fostering a culture of creativity, we actually work against it in the interests of managing technology.

And there’s the ugly word: management. Systems administrator aren’t just administering systems, but really they’re administering people, and administering access to information. Some parties (students) shouldn’t have access to each other’s courses, so that’s a constraint on what we can do – especially if a system wasn’t (gasp) designed for it. Some parties (faculty) shouldn’t have access to each other’s courses to preserve intellectual property – the only capital they have under neoliberalism.

While we may be justified in many cases in saying that faculty don’t always look out for the finer details of educational technology (like privacy, or data collection, or accessibility) – it’s not because they couldn’t. I often wonder if we stopped running workshops on how to use the tools we support in place of teaching what the considerations are for using tools if faculty could be encouraged to take responsibility for their own teaching spaces?

Could institutions feasibly support hundreds of tools? Of course not, but instead of training people how to use tools, we should be training people how to select tools that respect user’s privacy, meet their needs and most of all, help students learn. Really it’s that simple.

i>Clicker Integration with D2L/Brightspace

I’m sure i>Clicker won’t be particularly happy with this post, that’s ok, because I’m not happy with them. The one thing as an LMS administrator that you should feel very, very sanctimonious about is sharing data. We have an internal policy that we’ll never share student numbers. I also think that we shouldn’t share usernames, however some folks feel that’s ok. I guess it depends on your username convention. First dot last as a convention is great, except in these cases when you’re trying to maintain privacy. Now, if you’re making a single sign on connection through LTI, you can have the originating LMS username obfuscated, which essentially boils down to a paired database table that has two usernames in it – the one handed off to the third party via LTI, and the one in the LMS. Typically, I’m a little bristly about this as well, because you become reliant on the system not changing how this is handled, and if there’s an HTTP call mixed in there, it still could be sniffed out while in transit… but that’s not what this post is about.

Since last year, I’ve been bugged by i>Clicker to do an integration to make sign-up with their service seamless for students. There has been some requests for integration between i>Clicker and the gradebook in D2L from some of the more heavy users. The first request, I’ve always put off because, frankly, I don’t do anything a private enterprise wants me to do, they aren’t my boss, nor are they a member of my community. They serve one purpose, and that’s collecting money. The second, however, does benefit a select user group on campus. We were thinking about this since last year’s summer of integration, and April had a couple minutes free (more on that in forthcoming blog posts), so we scheduled some time to finally make it happen.

We schedule a call, to walk us through the integration and see if there’s anything that we have questions about. I don’t need anyone to walk me through an integration, but I often like to raise privacy, data collection policies, and other awkward questions to the poor sucker who’s on the end of the other line. Typically they are ill informed. I didn’t even get to the awkward stage, as a request was made that was frankly shocking. I was asked to turn on passing the Org Defined ID – or our student number – to facilitate the connection. Not just at the tool level, but at the configuration for the Tool Information. See below:

config_tool_consumer (1) Now if I understand this panel correctly, it not only changes the configuration settings for the tool in question, but for all the tools. ALL the tools. So not only i>Clicker, but anything else you have connected through using the External Learning Tools administration panel. I asked our technical account manager about changing it, and he basically said, “yeah, that’s not good.”

So in the middle of this exchange where I explain how we don’t pass the student number under any circumstances, the i>Clicker representative seemed to be a little miffed about my protests. He wasn’t particularly nasty about it, but certainly didn’t seem to understand why this was an issue at all. Looking at i>Clicker’s website, students are asked for their ID. It’s different asking a student to give them their ID (consent) and setting up access to everyone’s ID (no consent).

What makes me wonder is, how many other institutions even give this a thought? Surely we can’t be the first person to balk at the idea of handing over student data like this? Or maybe we are being too paranoid? I mean, I guess there’s people who have faith in the third-party vendors, but I’d prefer having a license, stating exactly what they are doing with data, how they’re using it, how long it’s retained and an agreement signed between the two parties. That way if the external party violates the agreement, the institution can hold them liable for the data breech – something a little stiffer than “oops”.