It seems every couple semesters, the Office of Distance Education and eLearning, AKA the folks who run Carmen, get a visit from someone who has a great idea for an add-on product. Carmen is technically called a LMS, or Learning Management System. I had such a meeting this week with my wonderful colleague, Valerie Rake, and afterward I thought it might be wise to capture the suggestions we made to this up and coming developer for future generations of software developers and/or business people who might want to save time, money, and headaches on their LMS software development project. If this applies to you, a few notes might be in order.
By way of background, I work in Distance Ed and eLearning at Ohio State University, and I spend a good chunk of my time in pilot projects determining how outside vendor products might be coaxed into connecting with our LMS (think Carmen), along with any number of other issues. Valerie manages the support team for Carmen, Top Hat, Mediasite, Turnitin, and a slew of other ODEE services that students and faculty use on campus every day, and has worked with enough bad LMS add-ins to make one’s head spin like a scene from a horror film. Here are a few of our thoughts from our meeting this week.
1) If you’re developing, learn about LTI standards that will basically work with all LMS platforms. If you decide an API will work better, you’re going to be dependent on the client’s team of developers to care enough about your particular product to make it work with their systems. If what you’re working on is the best thing since sliced bread, that developer team may spring into action. If it’s one of fifteen similar products that do similar things, they probably won’t. Using LTI standards makes integration with the LMS a matter of a quick security review and a few settings changes within the LMS, not months of troubleshooting.
2) Security reviews and local accounts are another great reason to use LTI standards. If you start setting up a product where users create an account on your system, you’re opening a can of worms that may prevent your product from passing a university security review. We have no way of knowing whether ‘BuckeyeFan2015@roadrunner’ is actually a student in your class. Even if we know that hooker.24@osu is somehow connected to The Ohio State University, we still don’t know whether he is currently in the class using your app, or whether he dropped your class for advanced basket weaving on day one. And, in case this argument isn’t strong enough, how do you feel about 500 password resets a day for the first week of every semester? Every semester! Forever! Grab account information of the people who are enrolled in your class through LTI and you won’t have to worry about any of these issues. And you’ll never have to reset a password.
3) While we’re thinking about security, consider your data. Are you moving student information securely? Is it secure as it rests on your server? Is enrollment data and scoring data moving directly from your server to our LMS (in an encrypted form), or are you asking faculty to download a copy of the student data to their desktop computer before uploading it to the LMS? If your solution is the latter, the hair on the back of our security team members necks will stand on end. This is the point where many companies say ‘Hey, I can just use an API to move that stuff back and forth.’ Remember that will only work for one specific LMS. Use LTI standards and it should work for any LMS, not just one.
4) Business tends to see participants in a class as either one faculty member or a set of students; if you or your developers see education this way you’re going to have trouble. Faculty co-teach classes. Staff members assist faculty with course set up. Grad students may teach one class while being a student in another. Fixing and modifying roles and permissions issues will give you grief later, so be flexible early in the process. Grab their role in the specific class via LTI, but also design your software with provisions for two or more instructors, 5 TA’s grading assignments, etc. You get bonus points if your software can combine class sections into a coherent list of people at one time and break those sections back apart when different TA’s need to grade only students within their section. If you think about this sort of challenge early in your design process, the headache you save later will be your own. (Or your development team’s.)
5) Collaboration is the way things move forward in a university setting. Time and time again we encounter software with oddities like only allowing one admin account access at a time, including solutions from huge software companies. Is it a hassle for me to find my boss to ask if they remembered to log out after getting usage statistics from some admin site the day before? You bet it is. That same huge company I alluded to also rolled out a media authoring tool that initially didn’t allow faculty to invite their peers to collaborate on a project. Working alone is the exception in Higher Education, rather than the rule. Develop with collaboration in mind. On the other hand, don’t assume faculty want to share everything with everyone.
6) Support is on the minds of most of the vendors who come calling at OSU, however the old 9-5 Eastern support days are coming to an end. Today’s students are studying across the state, and across time zones. Consider what calls can be handled by the in-house support offered by university as the first level of defense and build up your support for second, third, and fourth level.
7) Consider what happens to this student data when the semester ends and grades are filed. Have you built an easy way for faculty to archive what they want, and securely remove what they don’t want to keep? Think about data storage policies, and how long you want to guarantee faculty can get back to that data. Unless you have unlimited funding you don’t want to store it forever. Our security team probably doesn’t want you to have that exposure either.
This is just a quick list and there are undoubtedly many other things to consider, but if you begin thinking about these sorts of issues when you begin designing your amazing new LMS tool, I’m sure you’ll be ahead of most of your competitors.