Advertisement
Advertisement
ATD Blog

Roll With It

Wednesday, September 26, 2012
Advertisement

A few weeks ago, the team that’s been working on the Experience API (“Tin Can”) wrapped up version 0.95 of the spec. Some people on the team are new since the public effort started up in April 2012, but the vibe is still very much the same: fast, open, collaborative, and well, fun. Here’s an inside glimpse for the many of you who don’t (and really wouldn’t want to) participate on our phone calls.

Making Milestones

In the beginning of July, the group set a milestone date of August 31 to stop adding items and finish up the spec for a 0.95 release. This timeline would put a hard stop in place for our gaggle of nerds who could conceivably go down every little rabbit hole when it comes to specifying a new technology because that’s the sort of nerd (like myself) who is attracted to working on specifications. You just have to accept us—if not whole-hug love us.

At any rate, August 31 seems a long way off when it’s the beginning of July and you are coming off a huge display of accomplishment at mLearnCon. When it’s the second week of August, however, people start getting tense.

By that point, the group has had a lot of conversation (phone and email), but not really any concrete outputs. It became clear that we were going to have to get into the weeds, make some extra-strong coffee, and start exploring the finer points of our ideas to form real solutions that we not only would have to make explicit, but also on which we would have to collaborate.

Getting Started

When we started the public leg of this effort in April, we inherited an impressive body of work from Rustici Software through the BAA they answered while working with ADL. To get started “doing stuff,” we universally agreed to begin our efforts with that work as a version 0.90. It was good enough to build with...and we’d see what we’d have to tweak.

However, as different vendors, technologists, and designers used “Tin Can” for mLearnCon, we determined that there were actions we wanted to do differently. For starters, we all wanted more choice in how we describe the activities we would track with the technology. We also wanted to “dumb down” learning record stores (LRS) so other services that perform analytics on the data collected by “Tin Can” could do so more effectively, while making sure that LRSs had a better chance of working the same way—no matter how they were developed. Interoperability is a huge goal for any specification, and for those of us involved with learning technologies (over the past decade), it’s become critical.

Advertisement

Making Progress

Unlike working on a project with people in the same organization, open source efforts are as much an opportunity (in terms of economic or personal development) as they are a labor of love. Tensions run high on an open source project in the same places as any project, but when organizations are basically paying their people to contribute to work that they don’t actually own, disagreements can kill forward progress. We had a few of those tense moments in August.

On any project, some questions require putting rubber to the road. This usually invites differences:

  • Who is making changes to the wiki?
  • How exactly should we extend and define verbs?
  • What balance do we strike between building for today and building for things yet to come?
Looking back, pretty much every point of tension came down to communication issues. But isn’t that so with any project? A real credit to the community, though, is how we transcended our communication challenges.
On the first test of how well we could survive actually taking communal reins on an open source project, I give the entire team an A. I give myself a B; there are a couple of things I could do better, such as being more decisive earlier—when it’s obvious to everyone that as a “benevolent dictator” a decision must be made.

Advertisement
I hedge, usually to try and spare feelings or find opportunities for everyone to win. Sometimes as a leader, you do this and you’re not leading anything. Instead, you’re pushing off honesty and candor under the canopy of transparency and openness. (I know that’s a weird sentence to read. It’s a weird sentence to write. Still, I stand by it.)

Overall, though, we came through those tense moments successfully. Sure, at some moments, people got snarky—but mostly just at me. And to be honest with you, that’s one of the things I really love about working on the Experience API. We make hard decisions, and we make the right calls. And we do that by being forward with and respectful of each other. We don’t take weeks to make decisions that should take hours (or minutes), and when we do take too long—or when I take too long—I get called on it. Example: when faced with the decision to start calling it the “Experience API” in our documentation, one key contributor to the effort made the crack to me, “Aaron do we need to have a meeting about that?” Point well taken. ;)

I think that’s what makes this effort so different from my experience working on SCORM. At every edge of this complex technological undertaking, we’re principally talking about connecting people—what we each do with a given technology and how such activity helps us accomplish our goals. This is holistic and hard to do. And I think being hard is also what makes it a bonding experience for everyone involved with the creation and evolution of Experience API. It’s bigger and more audacious than any of us can do individually. And sometimes, that little bit of snark is so essential for progress to be made. It reminds us all that not only are we all human, we shouldn’t take ourselves so damn seriously.

Up Next?

I’m looking forward to the snark of self-acknowledgement that comes with realizing what we’ve laid out in the spec for the first time. I am also looking forward to discovering the things we missed with this go-round.

Specification people are the rare breed of nerd that goes just a step beyond pure technogeek into meta-levels of “what-if” chains—and architecting solutions to those edge extremes. We “spec nerds” tend to have very wry in-jokes with the self-knowing wink of how ridiculous the amount of explanation is required for any of us to share what we’re doing with anyone outside of the effort.

We’re riding nerdy. We’re figuring out the plumbing that will be used for the next 30 years of learning technology. Frankly, that’s just how we roll.
About the Author

Aaron Silvers is an active leader in the evolution of online learning. He was the lead developer for Advanced Distributed Learning (ADL) responsible for determining how content could be built for SCORM system and over the last five years led the specification (and now standards) effort developing the Experience API. He chairs the IEEE xAPI Study Group.

Through his consultancy, MakingBetter. Aaron accelerates learning and builds capacity in organizations. He evaluates systems and tools, leverages LEAN methodology to innovate and continuously improve learning and development functions, designs learning experiences and develops learning analytics and reporting capabilities.

Aaron co-created the “Up to All of Us” community and annual gathering with partner Megan Bowe in 2011. Up to All of Us catalyzed a new community-of-practice that reconsidered design, workflow, tools and practice. He continues to encourage the development of more effective design practices and better tools through partnership for the Experience API community with the forthcoming events, Connections: xAPI.

Be the first to comment
Sign In to Post a Comment
Sorry! Something went wrong on our end. Please try again later.