Advertisement
Advertisement
ATD Blog

We're All New at This

Wednesday, October 3, 2012
Advertisement

It was February 2005. I was sequestered in a conference room during Plugfest 9 with Philip Dodds, chief architect of the Sharable Content Object Reference Model (SCORM™) and a few people on the ADL technical team. With us was Tom King, who helped create Authorware. At the time, King was one of the leading people at Macromedia (soon to be Adobe) working on making integration with SCORM happen in products like Flash and Captivate.

This was not going to be a pleasant meeting—because I had made a very public faux pas. I had called out a body of work being done that was really, really hard to figure out.

It is now 2012. It is given that tools like Captivate, Articulate, and Lectora will simply work with learning management systems. What and how technology drive interoperability is not something that anyone thinks much about anymore. This was a very different story in 2005, however. Flash didn't just naturally work with JavaScript across different browsers, which meant working with SCORM™ was definitely a challenge. A much younger, not-so-bearded self scoffed the work that Macromedia had done, completely ignorant of the important role it played in SCORM™.

Basically, I was wrong, arrogant, and ignorant. I didn't know Tom, and walking into the meeting I wasn't quite sure if I'd have a job at the end of it. So as I started into what was sure to be a half-hour apology, Tom simply said, "We're all new at this." To this day, his words stick with me.

Tom went on to talk about how we're in an industry called “e-learning” that didn't even exist a few years before. We were all figuring out how what we made with the advent of SCORM™ would even work. It was ALL new, and we were bound to make missteps.

For years, I’d reflect on what Tom said. Sure, he was talking about me being green to how the world of emerging technologies worked. But I've come to realize that what he said at that meeting was even more profound. It's a principle—that can apply in many ways, on many levels.

"We're all new at this."

Fiona Leteney ( @fionaleteney) recently asked a question on Twitter that belies a common and completely valid skepticism about the Experience API ("Tin Can"). She asks, "But why would we want to record this level of detail? Help me understand context for corporate/education."

The ability to track so much information about one's learning activities with the Experience API is, admittedly, fodder for a complex debate. There's a double bind, and quite simply it looks like this:

I need my privacy respected. =><= I need to share details.

Advertisement
These are two sentences that many people today, especially those of us who are living distributed lives, find equally true—even when they seem in opposition with each other.

For instance, I work remotely from my team, which is distributed in Pennsylvania, Virginia, Wisconsin, and Florida. I organize and participate on a number of big projects with people in New York, Texas, and California. I have family and friends local to me in Chicago. In my own daily life, I have a need to share explicit details via digital means because that's the main way I communicate with so many people who aren't sitting next to me. And I wear lots of hats (some metaphorical, some not), so the context of the conversations I have tend to overlap from time to time.

Transparency, openness, and active sharing are what build and maintain trust when we work and build relationships through the Internet. In this case, sharing on the verge of over-sharing is a virtue.

On the other side of this double bind, quite simply is the notion that I don't want everybody knowing everything I'm doing. It's not that I have anything I need to hide, so much as it's no one's damn business what I do, with whom I talk, or on what projects I choose to collaborate when it's not explicitly in service to someone or something else. "We're all new at this."                                         

I think this is what Fiona is speaking to in her comment. And, I think this echoes the sentiment of prominent voices in our community. More important, transcending this double bind is going to be hard.

For one, we're talking a whole lot lately about "learning analytics." That's because imagining what a report looks like is easier than thinking about how a report gets made. The report-out that comes from performing analytics is made possible because it is assumed that there is indeed a large set of data from which to extract information.

Advertisement
The real question is from where does that data derive? The answer: data will come from things that generate a lot of data. In my mind, the Experience API has a role to play in this. The thing many of us, as designers, are going to need to accept is that we don’t quite know what to do with the ability to track so much data. We’re so used to describing learning with data in short, stunted sentences:
  • Sally completed Business Conduct Guidelines.
  • Sally scored 90% on Assessment 105a in Business Conduct Guidelines.

Working with the Experience API, one could conceivably tell an actual story.
Sally received an email from a [email protected]. Sally searched the Customer Service Dashboard for response procedures. Sally clicked on “Email Response Policies.” Sally clicked on “What to do about competitors?” Sally clicked on “Do you suspect corporate espionage?” Sally entered a chat window with Dave and Juan. Sally IM’d “Have you guys dealt with [email protected] before?” Juan IM’d “Here’s a link.” Sally clicked the link. Sally launched Business Conduct Guidelines. Sally scored 90% on Assessment 105a in Business Conduct Guidelines. Sally responded to [email protected].

The above isn’t just some pre-defined learning experience; it could be a report on a series of interactions that are free-formed and largely self-directed. What is told in this little story would have to be designed. This is what I mean when I write: “ we need to accept that we don’t quite know what to do with the ability to track so much data.”

Largely, what it comes down to is what kind of mad-lib stories we may want to tell—only the mad-libs might be created in-the-moment. This is a completely new way of thinking about design for our profession. Maybe not new for all of us...but new for most of us? In the beginning we’re going to tell stories with the data that isn’t very good. We’re going to keep track of things that don’t always have value. And we’re likely to have privacy and security scares. This is going to happen. This is all really hard stuff.

And. We. Will. Get. Better.

The thing is that because we’re all new at this, we have to accept that we’re going to fall short. When we realize that, it’s the opportunity we give ourselves to figure stuff out. The future is not some downloadable app—defined for us and packaged tightly. The future is what we make, as we make it.

This is how self-directed learning works. It doesn’t just work for whom we serve. It works for us, too. We’re going to make mistakes as we figure out how to design with and for data. But the opportunities for learning abound.

So while we see a chance, we have to take it. And remember it is okay to make a few missteps along the way, because as Tom reminded a few years ago…

"We're all new at this."

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.