Category Archives: OpenBadges

A Webmaker User Story in the Wild

Posted on by
Reply

As Mark explains, it’s Webmaker Planning Season, which includes writing user stories for where we want to take Thimble, Popcorn Maker and what we build to tie it all together. A really fantastic real world user story appeared over the weekend, courtesy of Notch and his army of followers.

It started with Notch tweeting about something he was experimenting with,

Then he finds a similar experiment from Mr.doob,

If you liked that, @ made a Minecraft type renderer using WebGL: http://t.co/GUjpiyC9
December 2, 2012 2:21 pm via webReplyRetweetFavorite
@notch
Markus Persson

And a conversation starts around the code, licensing and aesthetics.

Soon, a fan posted a Youtube video that explores Notch’s original code in detail. Notch moves his example to another community site similar to JSFiddle, but with social bits baked in.

Spent most of today learning new stuff. Ported Minecraft4k. Code is awful due to the nature of the project, but here: http://t.co/ZQQ8lsRj
December 2, 2012 2:05 pm via webReplyRetweetFavorite
@notch
Markus Persson

Why’s this like Webmaker?

Notch posts something he’s proud of, gets feedback from his peers (ignoring the fact that Notch is without peer for the purposes of this example), the community dives into his code and explains it to each other (the Youtube video), others remix or build off the original code (Mr.doob, I’m altering history here and pretending that the doob code came after Notch’s original post, artistic historical license).

The whole goal of Webmaker is to bring people together, show off what they’ve learned, help each other learn and get excited about making the web.

That’s cool, so how does Webmaker improve on it?

Right, that’s the big question. Everything you saw above happened today without the involvement of Webmaker, so what are we bringing that will improve it? A few things – in convenient bullet form,

  • Make it explicit – Notch learned something, he shared the learning and others built on top of it. Notch’s experiment, regardless of whether it’s on Thimble or JSFiddle, belongs in a gallery where it’s easy for others to find, share and remix.
  • Make it live beyond today – Twitter tied it all together. Twitter emphasizes real-time, it would be difficult to recreate this chain of events a year from now. It would be even more difficult to recreate the chain if a personality as large as Notch hadn’t initiated it. We need to see this chain of events as a unit without detective work.
  • Build and acknowledge reputation – the video commentator is a bit anonymous in the chain. He did significant work, and will help scores of learners make sense of Notch’s code. He deserves recognition for that work in a way that pushes his career, or gets him reputation in a community. (In short, give that guy a badge)

What should we build?

In this context, what is Webmaker.

  • A series of tools, Thimble and Popcorn Maker lead the way.
  • A gallery, currently in the planning stages, but we’re looking to build much more than a listing of projects. The gallery needs to fit a variety of roles, it should show what you made, what your friends made, and what everyone aspires to make.
  • Social‘y stuff. Take the conversation around a made item to the social network you choose, find better ways to let the work flow back and forth between tools and networks.

Mozilla?

How are the Firefox people going to tie all this together? I love Firefox, it’s my browser, but Mozilla isn’t just Firefox. Mozilla has a manifesto. We, Mozilla, are more than the sum of the people who get a Mozilla paycheck. We’re a world spanning community of contributors and zealots that believe working in the open has meaning beyond the products we produce. Mark Surman and Mitchell Baker say that very product has a semi-secret payload – Firefox’s payload was belief in the open web and open source and open standards.

The payload for Webmaker is still being worked out, but my take on it is that we build  together. We learn from each other, we make each other better than what we could be alone. Given that, everything on the web deserves a button that let’s someone else remix and comment on it in whatever way they see fit. The act of creation should encourage more creation, not just consumption and +1′ing.

It’s entirely possible to take all of this and make a product that fulfills basic requirements, and doesn’t worry so much about secret payloads and manifestos – but that would be boring, and unsuccessful. Mozilla doesn’t work in boring, we work on big stuff. The success of Webmaker is a world where the internet is writable, everywhere – and by extension, the world is writable, everywhere.

For more on the make the world writable idea, watch the Mozfest 2012 keynotes.

Badger Glue

Posted on by
8

A few days ago, Mark Surman wrote a blog post, Making tools for webmakers. I love the opening line, “We want everyone to tap into the full creative power of the web.” That’s a great mission. The rest of the post is a review of what we’ve done towards that mission so far, and some direction for the next few months. We’ve been talking about the ideas in the post inside of MoFo for some time now, trying to figure out what’s missing from the tools, what it means to learn on the web, and how to support the teaching goals of the Foundation with the software the Foundation is producing.

I’ve been focused on the idea that we need a central framework to hang all the learning pieces MoFo is producing off of, so that there remains a large amount of flexibility in the ways someone can interact with our tools, but without having to recreate a significant amount of architecture with each new tool feature.

Some constraints (fun-ppurtunities!) I had in mind,

  1. We want lots of data around the effectiveness of the learning.
  2. We want to give people a learning path, but also let them mess around on their own.
  3. Features should speed time to release, not throw up more roadblocks or add to the workload.

A Webmaker Project

The Summer Code Party is using Popcorn Maker and Thimble for most of the online webmaker activities. Both tools have a similar project pattern,

Pick a Project

Both Thimble and Popcorn start picking a project.

Pick a Thimble Project

Pick a Popcorn Maker Project

The metadata carried with the project is different, the assets are different, but the essential thing you’re doing is the same – picking something from a list of options, with information about what you’ll be doing in the project.

Work on the Project

The learner works on the projects inside of the tools.

Inside Thimble

Inside Popcorn Maker

Publish the Results

After the learner finishes the work, they publish. The publish step is similar in both tools, with Popcorn requiring a user account, but no user account for Thimble. The Popcorn team has had a gallery in the works for a while, which will change the way we publish projects, creating a gallery of published projects. Thimble has similar gallery in mind, but only publishes the finished project.

Thimble Publish Dialog

Popcorn Publish Dialog

Modularize all the things!

Given the similarity between the two tools, it makes sense to break out the common parts into modular tools you can mix and match to build future webmaking tools. The two obvious pieces are the project builder, and the gallery tool. In both cases, they’re responsible for either creating or displaying blobs of html & static assets. Both contain tool specific metadata, but they’re not so wildly different that we couldn’t make a base tool to create as much as possible, then extend it to include the tool specific bits. The gallery is the essentially the same thing – display a bunch of output html, plus some static assets.

All that said, it’s not a slam dunk, the details are…the details. There’s a fair amount of work contained in these humble paragraphs, so buyer beware. Let’s focus on the positives – if we’re working off a common codebase, we save time and energy. If we deploy these things as services, then we only need to work through security audit once. The bulk of our time should be focused on making the learning tools awesome, not recreating a gallery or a login system or a whatever. We’ll have all the lego pieces, if we build the sockets right, every day will be an exciting lego land adventure, rather than constant weeding and tending and digging.

OpenBadger, gluing it all together

So – lots of moving parts, everyone wants modular pieces, how do we glue it all together?

Badger Glue Fixes It All

The three parts to any webmaker project – pick, make, publish, match the three pieces of a badge pretty closely – criteria, evidence, assertion. The criteria are the list of things someone needs to do to earn the badge, the evidence is the result of them doing what the criteria asks, and the assertion ties it all together in badge form. The intent of the three pieces is to create a badge, but it’s not strictly necessary. We could use the three pieces as the scratchpads that each stage in the webmaker process looks to understand the context around the step it’s being asked to complete. Each of the three major pieces could be built on top of OpenBadger, like this convenient ASCII drawing illustrates,

   ASSESSMENT BUILDER /
   WEBMAKER.ORG             THIMBLE / POPCORN MAKER      GALLERY
 +-------------------+    +--------------------------+ +-------------+
 |                   |    |                          | |             |
 |Create a Project +-|----|-> Do the Project +------>| |Publish      |+--------------->  MASTERY!
 |/ Pick Project     |  + |                      +   | |             |        +
 |                   |  | |                      |   | |             |        |
 +-------------------+  | +--------------------------+ +-------------+        |
                        |                        |                            |
              +-----------------------------------------------------------------------+
              |         |                        |                            |       |      
              |         v                        v                            v       |
              |                                                                       |
              | Create Criteria URL           Ping Complete              Confirm      |
              |                               Evidence URL Created       Issue Badge  |
              |                                                                       |
              |                                                                       |
              +-----------------------------------------------------------------------+
                                                                                OPENBADGER

Arrows pointing to OpenBadger are either webhook API calls, or posting next-step metadata.

By splitting the direct connections between the pieces, and passing them off to OpenBadger, we can leverage OpenBadger for all sorts of clever analytics – regardless of whether we’re offering a badge for a particular project. That’s an important note – OpenBadger doesn’t need to limit itself to issuing badges, it’s a platform for any sort of learning activity, if we use it in a way that makes sense. OpenBadger isn’t about issuing the sticker at the end of a process, it’s about keeping track of the steps involved with an online learning project.

The most Meta of Metadata

We’re not the only people in wide world web looking to make exchanging education data easy, LRMI is a Creative Commons project to bring common metadata to learning resources. If we use LRMI as a basis for our criteria url’s, and then extend it with tool & display specific information, we’ll be able to take advantage of other LRMI parsing infrastructure (like the Learning Registry).

Next Steps

Over the next week or two, we’ll be discussing the plans for Webmaker tools, and start working on making everything fit together in early August, with a launch of all kinds of new stuff for Mozfest London in November. Between the Thimble, Badges, and Popcorn teams, we have some super smart developers. I’m hoping they tear this blog post apart, rebuild it in a way that makes sense to them, so we can start pounding keyboards in dramatic software development montage sequences that end in high fives, hugs, and exploding fireworks over Big Ben (because we’ll be in London…get it?)

First Round of Planned Backpack UX Improvements

Posted on by
3

The Mozilla Summer Code Party kicks off at the end of June, most of the work on Thimble (the tool the Open Badges developers were working on during our hiatus from Badge development) is done, so we’re getting ready to get back to Badge development. We’re planning a 2 week sprint around UX improvements in the backpack, this post is a brief explanation of what we’re thinking, along with some wireframes our trusty UX squad ginned up.

The bulk of what we’ll work on this round is improving the badge acceptance workflow.

Your first badge

An area that we’ve had a lot of concern about is the first badge experience, accepting a badge on a site, then pushing it to your backpack, creating the backpack, creating a Persona account, accepting the badge…it’s a lot of steps, plus most of it happens in a lightboxed iFrame modal, which seemed like a good idea, but actually confuses people.

The first big change is to move the dialogue out of a modal, and into its own page. When you choose to push a badge you’ve earned on an issuer site to your backpack, the first dialog is still a lightboxed modal,

Once the user chooses to create a backpack (remember this is their first badge), the next dialog happens in a new window on the backpack site,

There’s some variations to work out, we’ve talked about pushing the first badge to a generic backpack without a user account associated with it, then letting the user know it’s temporary until they create a Persona account, but there’s potential issues there we’re not sure about. Erik, the designer of the above workflow, is going to join the team in a more direct way for this sprint, helping smooth over any design issues that come up as we start implementing.

Next Steps

Two big events are happening in the badging world this weekend, The Ann Arbor Mini Maker Faire and the MOUSE Emoti-con festival. Badges are going to be issued at both events, and we’re going to get a bunch of first hand reports on the Backpack from the events. Anya, the second member of the crack UX squad, is planning on compiling learning from both events into more UX tasks we can tackle in a future sprint.

I’ll be distributing this post to the Open Badges mailing list for comment.

Post Flourish Badge Talk Thinking

Posted on by
1

Flourish 2012 Talk photo by @pdp7

The Flourish talk went well, at least that’s the what the feedback was.  It felt rambly to me, probably because I was having a hard time pinning down what I wanted to talk about.  Badges is a big topic, it’s a not-trivial technical implementation, and it’s a big fat topic in education circles.  I tried smooshing the two things together, a bit about badges role in education (which I’m totally unqualified to do, but I’ve never let that stop me in the past), a bit about where I thought people could fit badges into their own projects, and finally an overview of how to actually issue and earn an OBI compliant badge.

This was the first time I’d talked publicly about OpenBadges, and one of the first times anyone from the OpenBadges team has presented to a technical audience and not an education audience.  It was a good trial of the material.  Luckily, despite my jumbled thoughts, the core of the OpenBadges resonated with people, so that’s positive.  I’m going to have a second chance to present to a technical audience this Tuesday (4/10/12) at Groupon for GeekFest.  Be sure to RSVP if you’re interested in the talk.  I’m going to edit my talk based on stuff I learned at Flourish, a rough idea of the changes are here in convenient bullet form

  • The technical material should go up front, I’m going to drop the speculative section to the tail of the talk, if not drop it entirely.  It didn’t work the way I thought it would.
  • Define “digital” badges right away, they’re not as obvious as I thought they were.
  • The crowd anticipated the roadmap, including cryptographically signed badges, issuer endorsement of other issuer badges (creating a web of trust), lots of stuff. Which means we’re on the right track.  I should put in a slide of the total planned functionality relatively early in the talk, and then check things off that are complete.
  • Not be surprised by education questions, I think I mentally prepared for lots of implementation questions, but it turns out that a technical crowd still has opinions on badges as learning motivator.
  • Stop trying to be funny – I violated an old improv rule, I tried to be funny in a talk.  It totally failed.  I’m funny when I try not to be funny…when I try to be funny…it fails.  It’s a paradox.

If you were at the talk, and have any other feedback, I’d love to hear it.  Also, if you’re interested in diving deeper into the theory of badges, Erin Knight, the director of learning at the Mozilla Foundation, wrote a great blog post that acts as a reasonable primer on the space.  She answers a lot of the questions that came up on Saturday, without hearing any of them, she’s clearly psychic.

Badges – Less Yack, More Hack

Posted on by
2

This post is the basis for a talk I’ll be giving at the 2012 Flourish conference on March 31st

I’ve covered a bit of what a OBI compliant badge is, technically, but wanted to speculate a bit on where badges could start appearing. There’s a lot of theorization on badges in higher education, and badges for learning, but I want to propose something else entirely, something more geek-centric.

The Problem

I’ve spent a significant amount of my life in user group meetings, open source conferences, and more recently – playing Pathfinder (an OGL D&D 3.5 edition variant). In each of those three places, you spend some percentage of your interaction time explaining who you are, and trying to figure out where you fit in with the overall ecosystem, or team dynamic.

We do it for a few reasons, the above board – store this information away so I know who to talk to in the future when I have a particular problem, or do I want to be pals with this person, and the less-above-board – is this other person more awesome than me? It’s not all warm and fuzzy either, in a hack-sprint situation at a conference, you have to figure out who’s going to work on what, and at what level. In a dungeon raid, you need to know who can pick pockets, and who can heal you when you get a sword boo boo.

Yack Yack Yack

All this takes time, it’s a lot of yacking, not a lot of hacking. Pathfinder speeds it up a bit. At table games, each player brings a table “tent” (a placard?) that gives their character name, level and class. So, at a glance, you know the player is a Dwarf fighter, and is good to get behind in a fight. The tents aren’t the end of the discussion by any means, they’re just short hand so we can quickly get to the meat of the team. There’s usually some tongue in cheek RPG backstory stuff, maybe some general strategizing, whatever – the point is, we didn’t have to waste 10 minutes going in a circle explaining the basics, it’s right there in front of everyone. Now we can get to the (sword) hacking faster.

The Open Badges spec provides a few things,

1) Criteria – what the badge means
2) Attribution – who earned the badge, who awarded the badge
3) Verifiability – is all this for real?

Pathfinder does all this too, including verifiability. All players are given a character id, so that anyone can look up a given character and verify they’ve earned their rank, including a papertrail. It’s pretty neat, here’s one of mine. Because my character’s background is verifiable, the folks at my table don’t need to spend a bunch of thought cycles trying to figure out if I know what I’m doing. They can see it right there, I’ve been in the shit man! I’m a Dwarf that knows what’s what!

Pathfinder Table Tents

Table Tents, anonymity provided by the pink unicorn.

Towards Hack

There are companies forming around something I think of as resumes+. LinkedIn is an obvious first example, their additions of skills to online resumes makes sense. The reverse search ability of them is cool too, so if you’re looking to fill a job, it makes it pretty easy to find someone who knows “Python”.

What about levels into Python though, what about fine-grained stuff like, “knows the guts of the Django ORM?” That’s a real skill, but not what LinkedIn wants to know. There’s also the continuing problem of verifiability. There’s some alternatives, like CoderWall that pull directly from your Github account to decide the kinds of stuff you’ve done. It leans towards the show-off side of things, but could easily remove friction to putting together a team.

If you extend the CoderWall example to physical hardware hacking, you could build a site that certifies competency on a bunch of different tools. That way, if you’re certified on a laser cutter in Chicago, you can use the same machine in Milwaukee and San Francisco. At some high level of achievement with the cutter, you could certify other folks. Reverse lookup of the certification could make it easy to figure out who could help set up a newly purchased cutter. All of this can be done with emails and phone calls and tweets, but it takes time. Time that could be spent using the cutter, not verifying your ability to use the cutter.

Why OBI?

Like I’ve said before, figuring out what to badge is the hard part. Determining if someone is actually able to use a laser cutter is serious. All of that sort of stuff is best left to those that know, and best initiated by trusted organizations. The Open Badge Infrastructure doesn’t solve the problem of creating badges, it solves the problems of multiple badges living together.

Let’s say you’re a certified laser cutter user, but you’re also a Django ORM expert, and maybe even a 5th level dwarf. Three separate silos are badging you, Pumping Station One, CoderWall, and Paizo (objection – speculation, these badges don’t exist, don’t get sad, give it time…they’ll come around). Each badge lives in its respective silo, and you’ll need to direct someone to all three places to land that amazing laser cutting / orm hacking / dwarf fighter gig you’ve dreamed of.

That’s the guts of the OBI, make each badge portable, and push them all into a backpack that you have complete control of. You’re also able to set the privacy settings, so if you’re not comfortable letting your boss know what a kick-ass axe wielding dwarf you are, you don’t need to. That’s your business.

Furthermore

The unofficial tagline for Open Badges is, “enabling lifelong learning.” I love that mission, but think it itself sounds too formal. The unofficial mission statement of the Mozilla Foundation (undocumented) is “less yack, more hack.” If you see badges as a way to promote hacking, rather than constantly having to prove and reprove yourself with the repetitive yackery, then that’s right too.

Further Furthermore

There’s two counter arguments here, things that people say, that I agree with, and am actively trying to work around.

1) People are unique snowflakes, badges pigeon hole them – yeah, totally, people are unique snowflakes, and you should take the time necessary to explore a person’s unique crystalline structure. In the meantime, there’s a castle to storm, and we need a good necromancer…let’s save the getting to know you for later.

2) Certifications suck – yeah, totally. There’s a whole market of semi-fraudulent certifications out there. As a person-who-hires-people, I’ve never used professional certifications as a significant hiring factor. However, I’ve definitely used Github, code samples, and general internet-profile-google-stalking of someone as a hiring factor. Badges codify some of what we’re already doing. And since anyone can make them, it seems like there’s less incentive to build bullshit ones, or at least, bullshit badges will be quickly supplanted by not-bullshit badges. Time will tell.

Earn a badge, issue a badge

Posted on by
8
@ @ @ so how do we get @ and @ connected?
March 21, 2012 8:41 pm via webReplyRetweetFavorite
@raster
Pete Prodoehl

Good question.  The hardest part is deciding what kind of badges you want to issue, the rest is straightforward.  I’ll explain.

Earn a badge!

Let’s start by earning a badge on openbadges.org. Click on the big blue “Get Started” button on the front page and you’re given an easy quiz, testing your Badges 101 level knowledge,

The Start of the Badges 101 Quiz

After you finish the quiz, you get a fancy badge, which you have the option of sending to your backpack,

You earned the Badges 101 Badge

When you send it to your backpack, you’re asked to sign in. The sign in is through Mozilla Persona (aka BrowserId), so this is also a great opportunity to set up a Persona account if you haven’t already.

Logging into your Open Badges Backpack

After you’re done adding the badge to your Backpack you can share your badge out through a share page like mine.

What’s that badge, really?

Badges can represent all kinds of things, completing trivial quizzes, or months of study, regardless of what you had to do to earn them, the actual guts of a OBI compliant badge (a badge that you can push into your Backpack) is three things,

  1. A badge graphic
  2. A badge criteria url
  3. and a badge assertion url

A badge graphic

The badge graphic is a square PNG. That’s it. Here’s the badge graphic for the Badges 101 badge,

The graphic isn’t specific to the person (though it could be) and it doesn’t have any information in it that describes the badge (though it could, via Badge Baking, a service that embeds the assertion information in the badge to make it truly portable).

A criteria url

The content of this url describes what I had to do to earn the badge. For the Badges 101 badge, we cheated a bit and just said that the criteria was the Open Badges homepage. For now, the criteria url is any valid url, in the near future we’re going to release a spec for machine readable criteria url’s. The issuer hosts the document, which proves that the badge came from the issuer.

An assertion url

The assertion is the specific document that ties a badge to a Persona id. Just like the criteria, the issuer hosts this document. When I earned the Badges 101 badge, Open Badges (the issuer) created an assertion url, which you can see here.

 

The above example is using a slightly older version of assertions which include the Persona ID in plain text, we just rolled out the salted hashes as identifiers (salty hashes! delicious!). When we update the Badges 101 badge to assert a hashed ID, I’ll update this post to show the new method.

The assertion ties all the pieces together, it’s hosted on the issuers site – so you know they know about it, it has an ID associated with a Persona account – so you know it belongs to the person that earned it, and it links to the criteria – so you know what they had to do to get it. Oh, and it has a picture, so it looks cool too.

Push the badge to the backpack

Once you, the issuer, have created the two generic requirements (a picture and a criteria url), and the learner has shown they’ve earned the badge (up to the issuer how this accomplished), the issuer creates the assertion url, and then passes this whole mess of stuff to the Backpack via the Issuer API.

The Issuer API is a Javascript API, which pulls a dialogue from the Backpack. The Open Badges Infrastructure is for the learner, we don’t want any badges pushed into their backpack without explicit approval, we want the learner to see which badge is going in, why, and approve it.

Including the API on your site is a JS include, which then gives you access to the all important OpenBadges module.

 

What the OBI isn’t

From all the above, you might have picked up on something about the Mozilla Open Badges Infrastructure isn’t, which sometimes confuses people. The OBI isn’t a badge issuing platform. Issuers need a system that assesses learning and awards badges within their own site. What the  OBI is, is a lightweight specification that allows for learners to collect badges from multiple issuers.

However, if you look at the way Open Badges.org is issuing badges, you’ll see – it’s not that complicated. Atul built a nice JS assertion creator which hosts the assertion on Amazon S3, so nothing about the Badges 101 badge is server side, it’s entirely on the client.

Oh, and…

Several heavyweight platforms for badge issuing are in development, some of which will be open sourced. There’s room for a light issuer, similar to Atul’s assertion creator, but with a bit more refinement. If you’re looking for a way to contribute to the project, that would be a great start. Otherwise, if you’re interested in the OBI bits, and want to lend a hand, we’re really interested in finding collaborators.

If you’re looking to create OBI compliant badges, now’s a great time to get started. Beta is launching at the end of this month, so things will be pretty stable by then. Jump into the Open Badges Google Group for discussion, or come talk to us on IRC at irc.mozilla.org #badges.

What Badges Would Isham Have Collected?

Posted on by
Reply

My pal @plural (Jason Gessner)’s funny tweet inspired a second (shorter) post explaining badges in terms of Isham Randolph.  (for those just joining, Isham Randolph was the chief engineer of the Chicago Sanitary and Ship Canal, the canal that reversed the flow of the Chicago River, I’m sort of obsessed with him.)

So, Jason, in response to your tweet – Isham Randolph is an excellent example of an entrepreneurial learner who would have benefited a great deal from OpenBadges.  Here, in convenient bullet format, I present my argument:

  • Isham began his career by learning carpentry from a man (whom he owned, sadly, he was a slave owner) on his plantation, he was not formally apprenticed or trained. citations
  • Isham worked his way up from axeman to chief engineer of the Chicago and Western Indiana Railroad, leveraging his on the job learning to advance his career. citations
  • Isham became chief engineer of the Chicago Sanitary district, dug the CS&S canal, then used his achievement to gain an appointment to the Panama Canal Committee. citations

So, in short, he would have had at least three badges, all of which were important to his career, none of which would was considered formal learning at the time: carpentry, surveying (probably engineering management), and canal building.

Joining Mozilla Open Badges Team

Posted on by
3
I joined the Mozilla Foundation this week, putting consulting on hold for the time being. Proud to be a part of the @ team.
March 6, 2012 4:54 pm via TweetDeckReplyRetweetFavorite
@chmcavoy
Chris McAvoy

I’m now a Mozillian, or more specifically a Mozilla Foundationian. I joined the Open Badges team this month. I haven’t given up on the idea of starting a consulting business, but I like the project, the team, and the organization enough to want to work with them in a more full way than what consulting offered. As part of the commitment to work in the open, I’ll be using my blog to talk more about the project, and my involvement with it. I’ll still write about the other stuff I love, but this will be the first time in recent memory that I include a significant amount of work stuff here. The fact that I want to do that is part of the appeal of the move for me.

Explain Badges

Badges, along with other loaded phrases like crowd-sourcing and gamification, doesn’t have a single easy to explain meaning, unless you take the absolute bare minimum explanation that a badge signifies something for someone. Lots of sites have badges, Khan Academy is a pretty easy way to demonstrate the idea, so are Steam achievements and Wikipedia barn stars. MIT is getting into the badging game (though they prefer to call them certificates) through their MITx initiative, and last week the MacArthur Foundation (with the support of Mozilla, HASTAC, the Gates Foundation, and others) announced the winners of the DML Badges for Lifelong Learning competition.

A sample of the winners of the DML competition show the breadth of ideas around the relatively simple of idea of digital badges:

  • NASA will use badges, and their enormous online assets, to encourage robotics and space education programs.
  • Young Adult Library Services Association will use badges to help librarians develop new skills to improve their work with teens.
  • Smithsonian Institution is building a museum education program to link visits to the museum with online learning to encourage lifelong learning.
  • The Department of Veterans Affairs is will use certified digital badges to represent work skills that soldiers develop while in-service, making it easier for them to find solid jobs in the private sector.

The list of ideas is enormous, and the companies and organizations participating in the space is amazing – Pixar, Disney, Microsoft, Intel, Design for America, Carnegie Mellon, PBS / Storycorps, 4-H, plus a bunch of organizations that are on the cutting edge of new models of technology fused education, like Mouse and Hive Network. Of the ~90 finalists in the contest, ~25 were funded. Having sat in on some of the judging sessions, I can say that the finalists were all good ideas and could be executed, and probably will be executed, regardless of whether or not they received funding from the contest. The space is tremendously busy, with lots of thinking about how to make a simple badge meaningful to a learner, and the people that can provide that learner with new opportunities.

But you’re not a teacher

Yeah, totally – I’m not a teacher, I’m a technologist with a love of learning and long history of supporting open source communities. All three of those things, technology, lifelong learning, and open are fulfilled with this project.

Technology

This was our booth at the DML Mozilla Science Fair, where we explained OpenBadges dozens of times.

Badges aren’t just simple pictures, the idea is to build a system that builds badges with meaning. Meaning in this case is a set of metadata that can be verified and attributed, both to a particular recipient (the learner) as well as the institution (the issuer). Both sides of that transaction should have control of their choices, a learner should be able to take their badges wherever they go, and the issuer should be able to issue whatever badges they see fit.

If a learner chooses to display their badges, on their blog, their Twitter stream, their Facebook, their online resume, they should be able to, regardless of the silo in which the badge was earned. If the badge is public, or shared with a specific party, the person viewing it should have the ability to verify that it was actually earned, that the issuer is who they say they are, and that they did give the learner this badge.

Over the course of the project, I’ll dive deeper into the bits and pieces that make all this possible, in the meantime – we’re building the majority of the infrastructure in Node.js with the Express framework, and developing it in the clear on Github, and planning the project in an open Pivotal Tracker.

Lifelong Learner

It’s a phrase that keeps coming up, it was the subheading of the DML competition, it’s in lots and lots of explanatory copy around badges. It’s a simple enough idea, which I thought didn’t need much explanation (because, really, it doesn’t). That said, this John Seely Brown keynote from the DML conference last week really blew me away. I’ve always thought of myself as a lifelong learner, but now I’m convinced I’m an entrepreneurial learner (his phrase). It’s a really great speech, and worth the hour and a half investment to watch it.

As it relates to badges, formal degrees and certifications only explain half of who a lifelong learner is, lighter-weight systems need to be acknowledged as valid learning experiences. Verifiable digital badges bridge that gap between informal and formal learning experiences, and make it easier for a non-formally educated person to prove their worth at a glance.

Open

The (open, heh) view from the SF Mozilla Office, with Brian the OBI tech lead / super architect in the foreground.

It goes without saying that Mozilla is an open organization, they promote the openweb, promote open source software, and advocate for open learning, open journalism, and even have a pretty badass manifesto. Given the enormous number of companies involved in the badging ecosphere, (see above) who do you want to develop the plumbing that keeps all this together? A company that sees every eyeball as a dollar sign? Or a foundation built on the principals of open source? Badges won’t survive without the support of lots and lots of organizations, and there isn’t anything wrong with using them as a profitable pursuit. As a learner though, I want to ensure that I control my badges, any of which could represent hundreds of hours of effort.

I don’t want a single company to decide how I can represent myself, not even Mozilla, which is why every piece of the code that represents an OpenBadge is open source, the same goes for the backpack you store the badge in, the ways in which you can display them, and (eventually) where the backpacks are hosted. In the next few months, you’ll be able to self host every piece of the OpenBadges infrastructure, without ever talking to Mozilla.

In Conclusion

This badge thing is happening, it has enough momentum that it’s highly likely that your children will include a significant number of fancy online badges in their first job interview, that you might include some in your next job interview, or that you yourself might issue a badge for teaching your neighbor how to hand code an html page. Badges aren’t magic, and yes – they’re just like Boy Scout merit badges, except in the case of OpenBadges, we all have access to that fancy sewing machine that makes the pretty pictures for your sash.