Academic Computing

the other end of the Personal API

A lot has gone on lately about the “Personal API.” Getting information on it gets to be a bit meta, with one link leading to another article to a blog post then all the way back around to the first reference but start off with a great post from Jim Groom that in turn links to an article by Tim Klapdor that really captures the key ideas, then check out some talk on the Indie Ed Tech discussion from 

A massive oversimplification of an idea as expansive as a personal API is that it’s a way for the user to control how his or her own data is being used and accessed. An API in the software world is a defined interface for accessing data from a system like Twitter or Facebook. A personal API, therefore, is about controlling how personal data is accessed. It puts the power back into the hands of the individual, rather than the system. This discussion is taking place in higher ed, so the practical example would be a student deciding when personal data such as a phone number is available, rather than the institution controlling that information through access into, say, the Student Information System (this is the example Kelly Flanagan, the CIO at BYU, provides).

This is an amazing idea, and one worth pursuing regardless of your type of institution. It’s worth rethinking how you approach everything from digital learning in general to the LMS specifically. But it also has a flip-side challenge that is non-trivial.

Earlier this week, I was in a demo from an SIS vendor where we talked about ways to access data in the system. Not surprisingly, they discourage direct SQL database access, so the options were to either use reports (e.g. – giant Excel file, which requires more work to use) or build hooks into their APIs. The latter is preferred since it would inherently include getting the data into the right format for whatever the intended use, plus it would be more secure. The vendor was touting how they have well-documented and extensive APIs so that we can do what we wish in terms of software development.

APIs – whether for a Student Information System or a person – are great and indeed quite powerful. It’s like an extended hand in a way, but one that carries with it all the information about how high up the hand is from the floor, how far away it is from the body, whether it’s the right or left hand, etc. Taking this metaphor a bit further, the key is that the person extending the hand – the student in the personal API example – gets to decide all of those variables. The angle of the hand, the distance extended, etc. What data is included or excluded, and exactly how a secure exchange should take place.

However, having an API isn’t a complete solution. The problem with an API is that it’s only half of a two-part process. The hand is extended, but someone does indeed have to walk up, take hold, and offer that firm handshake. It’s great to offer access to data, and it’s even better to give control over that process to the individual, but it still takes two to tango.

Now, BYU and some schools involved in projects related to digital identity (see Domain of One’s Own – another Jim Groom brainchild – for a good starting point on this topic) are already or will soon be investing time and resources into the other half of this relationship. And this is undeniably something that every institution should explore as we find ways to empower students and create the Next Generation Digital Learning Environment, but there is part of me – the cynical half? – that keeps wondering about the resources needed. Looking with blinders on only at our department at Muhlenberg, I don’t see us being able to engage in a meaningful way for some time. We’ll take advantage of tools that others build, sure (and of course there is nothing wrong with that IMO). But as far as us being the other end of the handshake, building our own tools? I don’t know. Can we disaggregate the LMS on our own? Not likely in the near future.

Absolutely worth it, without a doubt, to work to find a way to get involved. But it will take work to get to a meaningful outcome with the personal API.

hillbilly MOOCs

Note – I realize that using the term “hillbilly” might strike some as insensitive and some as rude. I apologize for that. The fact is that it has a strong relationship to the notion of “rural” and “backwards” and, in comparison with the other MOOC programs I want to discuss, it is appropriate. So yes, I am taking some editorial/artistic license in the name of a better “hook” of a title. I’ll change it if anyone speaks up.

Massive Online Open Courses – or MOOCs – have been basically THE topic of the past couple of years. Whether it’s a company – Khan Academy – or part of a university – HarvardX – the creation and delivery of these courses has taken on a decidedly formal manner. There are offices devoted to helping design and deliver these programs, with dedicated staff. They have reached a level of maturity that, for instance, faculty whose curriculum have become part of the HarvardX program have written a formal letter asking for more oversight on the program itself. Faculty are injecting themselves into the program. Which means they are taking the impact of MOOCs on the larger issue of education and Harvard’s educational “brand” quite seriously. Which is a big deal.

For small institutions, though, delivering content online can be quite challenging. At Menlo College, for example, which is a very small college – 700 students – the first question is about getting something online. Not an entire courses. A MOOC is so far down the line that while it might be on the horizon, we’re still far enough away that we’re not sure if the world is flat or not. Perhaps we’ll fall off the edge of the world before we get to the MOOC implementation.

Lately, I’ve been contemplating how we might build a program overtime that would lead to an effective implementation of online course materials in a hybrid and/or “flipped” (rather broad description from Wikipedia) environment that could, in theory, eventually lead to acceptance and creation of effective MOOC-style curriculum. Since we don’t have an academic computing/educational technology program right now, this is an important issue for me and for Menlo. Is this a topic we wish to address as we build a program from scratch? If I had to pick, say, 5 low-cost, low-overhead, high-impact solutions, would any of them be the building blocks of online content delivery? Or should any of them be, with an eye towards that horizon?  One always wants to make tactical moves that align with strategic goals but is there enough clarity?

One thing we know is that the MOOC model is not going away.  From a purely business perspective, it is just too compelling to ignore. Right now the “open” part of the MOOC acronym suggests that profit should not be a factor at all. But at some point people will want to make money on any venture, and the notion of being able to deliver one set of content to 100, 200, 300 or any number of students in a ridiculously scalable model (single delivery system, single assessment model, etc – all scalable) is just too compelling and enticing. So MOOCs are here to stay. If you reel in the “ideal” that underlays MOOCs just a bit, courses delivered entirely online are equally obvious. They might not be massive and not as scalable (depending on implementation), but they are still very compelling. So, from a strategic planning perspective, I guess we do need to build up to a significant online presence for our curriculum.

For us, where we are starting from the ground up and with no staff dedicated to this purpose, we have to take this one step at a time. (more…)