Learning in hallways (with APIs)

November 18, 2012 | 4 comments

I can’t let Clay Shirky’s piece, Napster, Udacity and the Academy, go un-commented-on:

Open systems are open. For people used to dealing with institutions that go out of their way to hide their flaws, this makes these systems look terrible at first. But anyone who has watched a piece of open source software improve, or remembers the Britannica people throwing tantrums about Wikipedia, has seen how blistering public criticism makes open systems better. And once you imagine educating a thousand people in a single class, it becomes clear that open courses, even in their nascent state, will be able to raise quality and improve certification faster than traditional institutions can lower cost or increase enrollment.

You can – and should – read the whole piece here.

I completely agree with it, and I think that startups like Udacity will broadly be a good thing for the world. (Of course, it’s worth mentioning that this is a movement that OpenCourseWare started a long time ago.) Having said this, there are a few important tenets about learning that I think aren’t necessarily captured by the Udacity model.

  • There are different kinds of learners.
  • Learning with your peers is important to some people – and learning alone is important to others.
  • A one-size-fits-all approach doesn’t work when it comes to education.

I went to public (state-funded) schools, and a public university. I can’t claim to have experienced the one-on-one education that you might receive at Harvard, for example. But it’s nonetheless true that education has traditionally been, at least a little bit, tailored; you could always go to your Director of Studies if you had a problem, or talk to your professor about substituting work or taking a different focus.

In the modern web age, by which I mean from about the iPhone onwards, we’re used to cookie-cuttering users. Everyone gets the same interface, in the same design, with the same content types, because that design is good, it’s efficient, and don’t you love good design anyway? We’re all supposed to write a certain way, consume a certain way, look a certain way.

Applying this principle to education will be disastrous.

There’s a lot wrong with education right now, particularly in countries like the United States and Britain, where class systems are enforced through high fees and barriers to entry. But in a knowledge economy, we should be emphasizing creativity and individual strengths, rather than attempting to make learners fit an ever more rigid, dehumanizing template. (We should be doing that with users of our applications too, of course.)

But as I said at the beginning, I don’t think this is a bad trend. It’s also an inevitable one. Educational content will be open, it will be delivered en masse, and you will be able to access it from anywhere in the world. It will be a great thing.

The trick is how you consume it.

You can use Udacity’s interface, if you like. But just as I have the freedom to take three classmates to the pub (I went to university in Britain, remember?) and talk over our notes there, I should have the freedom to take some of my classmates and discuss on Facebook, or a collaborative Google Drive space, or on some other custom platform.

And that’s where the technology focus becomes really interesting. Web applications have APIs: Application Programming Interfaces that let other applications talk to them programmatically. The same API approaches that allow people to build third-party Twitter apps or to sync Instagram with Facebook could allow people to take streams of learning from the learning service – let’s say Udacity – and pull them into the platforms of their choice. Other commercial applications, or freely-available open source projects, could take that learning and allow you to interact with it individually or in a group. And then you can use the app or method of your choice to submit your work back to be evaluated. And if everyone’s using the same APIs, then everyone benefits: learners get to pick and choose their courses, and the educational providers get to participate in an open marketplace that’s as big as the web.

In this model, the raw course is always the same. But suddenly there are a hundred thousand lenses that you can apply to it, so if you’re a visual learner, or a group learner, or a solitary text-based scholar, you can find the interaction method that appeals to you, pull in relevant third-party information and conversation to augment your learning, perhaps even talk to third-party tutors in other countries (or next door), and have a much deeper, richer, more personalized experience than you could ever have had before.

My worry with the new educational startups is that they’ll try and lock themselves down, in the way that Twitter and Facebook have locked themselves down. If, on the other hand, they can open up and embrace what the web really is, there’s the potential for a real revolution.

The Edinburgh Festivals API: a case study in innovation

May 14, 2012 | Leave a comment

I was the inaugural Geek in Residence at the Edinburgh Festivals Innovation Lab, working with Rohan Gunatillake and the Edinburgh Festivals on open data and digital accessibility.

Here’s a video from Rudman Consulting for AmbiTIon Scotland about the Festivals API portion of the project:

The Open Stack and truly open APIs

May 28, 2009 | Leave a comment

The following is an expanded version of the short talk I gave in Oxford yesterday. My original slides follow the transcript.

There’s a new kind of web development afoot, which marries old-school object-orientated programming techniques with the distributed power of the web.

Application Programming Interfaces (APIs) are published sets of instructions for programmatically querying or extending a service. For example, the Google Maps API allows anyone with some development skills to build applications based around Google Maps; the Twitter API allows anyone to build an application that lets you interact with Twitter (like Tweetie or Tweetdeck). The act of allowing anyone to do this is generally thought of as being “open” – as in, open to anybody. While that’s true, in another sense they’re very closed.

The trouble is, if you write a microblogging application using the Twitter API, you’re locked into Twitter. If you want to write an application for another microblogging service, you have to use their API and start from scratch again. The formats produced by each service’s API are proprietary, as are the methods to query them. They’re incompatible with each other by design, because those services don’t really want you moving users’ data around between them. They want users to sign up with them and then stay there – a great proposition for the service, but a lousy one for the users, who have no real way of importing or exporting the content they’ve created.

Furthermore, there are some situations where this one-API-per-service model breaks down completely. Let’s say you’ve joined a social network and you want to check to see which of your friends is already there. The service provider could use a Gmail API to check your address book, but some users will use Hotmail for their email, so they’ll need to use the Hotmail API as well. Repeat for Yahoo, and every single email provider under the sun – there’s no way anyone could possibly write this feature without a generic API that works across all services.

Enter the Open Stack, which is a set of generic APIs designed to provide common tasks:

  • eXtensible Resource Descriptor (XRD): allows an application to discover resources and APIs relating to a particular page (for example, an application could check a user’s profile page and discover that they have an OpenID). There’s no point in having open APIs if an application can’t find them, and XRD fills this gap.
  • OpenID: allows anyone to log into any service that supports it using the same digital identity (potentially linking that user’s accounts on those services together). A WordPress.com ID is an OpenID, for example; you can log into any OpenID-compatible site with it.
  • OAuth: a way to authenticate access to API-based services without forcing the user to present their username and password for that service. Previously usernames and passwords were passed in order to authenticate APIs, which led to serious security issues. Here a user can easily and securely grant or deny an application’s access to their data. OAuth can also be used to apply granular access controls to a piece of data.
  • Activity Streams: a way to broadcast your activity on each service (for example ‘Ben has published a blog post’, a la Facebook’s river) so that it can be aggregated at a central point.
  • Portable Contacts: a simple way to transmit collections of contacts, like email address books and lists of friends, between services.
  • OpenSocial: provides a framework for hosting remote application widgets on a service.

In programming jargon, a stack is a specific data or platform structure; actually, this is more of a pile of useful technologies that can (in part) be used together.

These generic APIs allow for a more distributed kind of web application. Suddenly, instead of writing support for a particular function from scratch, you can pick up an existing code library and slot it in. You can interact with any service that supports them without writing any further code.

However, there are some unresolved issues that need to be discussed. One major headache is the privacy implications. If I sign up to BensFabApp.com, I agree to the terms of service and privacy policy there. However, behind the scenes it might be accessing the APIs for AppOfEvil.com, which has a very different privacy policy and terms and conditions. How does that second set of terms and conditions apply, and what’s the legality of passing a user’s data across two services with two different sets of terms, when the user only knows about one of them?

A second issue is a user’s control over their data. When BensFabApp.com sends data to AppOfEvil.com, it may get cached and duplicated. What happens if I delete the original data on BensFabApp.com? So far in the open stack there is nothing to handle deletion of content. It’s a fair argument that when something is published publicly you lose control over its distribution; however, if access has been limited using OAuth or another method, there’s no way of reaching out an ensuring its removal from every system it’s been sent to. That would be fine if the data had been sent to another person or application with the user’s express permission, because they’ll be aware of the implications. However, if it’s been sent completely behind the scenes, they have no way of knowing that it was sent to begin with.

These are issues with any API-based service, but generalized APIs are likely to be used more frequently. Solutions to all of these problems will be found, but it’s important to note that they’re not there yet – which serves as a warning to applications developers and an opportunity for anyone who wants to step up and provide them. As this kind of open API becomes commonplace, new kinds of web applications will begin to emerge as developers spend less time reinventing the wheel and more time innovating. It’s just one of the things that makes the web as a platform so exciting to work with.