First Round of Planned Backpack UX Improvements

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.

Super Awesome Badge Summer

We’re a third of the way into second quarter, so I wanted to check in with the roadmap and see how we’re performing against the plan. The structure of the development team has changed a bit. Our full time developers Brian and Mike are helping out with Webpagemaker through the end of May, to get it ready for the upcoming Mozilla Foundation Summer Campaign. The move changes the timeline of OpenBadger a bit, but most of that timeline was dictated by OpenBadger’s inclusion in the Summer Campaign. We’ve decided to hold off on badging the first round of the campaign, so that frees the Open Badges development team to help out with Webpagemaker.

That doesn’t mean there won’t be progress on the larger Open Badges Infrastructure this quarter. We’ve brought a few contractors on board to help us with some of our second quarter goals. We also found a great Google Summer of Code student in Matt Ramir. Matt starts working for us this week, he’ll be getting up to speed for a bit, then he’ll be helping us with a bunch of stuff.

What’s the point of the backpack?

That question came up a few times in a few different forms recently. It took me by surprise, probably because I’m so close to the work. My response was something like, “the backpack let’s the badge earner collect badges from multiple sites, and show them in different places.” “Sure, ” they’d respond, “but that’s not obvious when you earn your first badge. Plus, there’s really no place to display badges now. Oh, and login is a mess. If the pop up looks like it’s part of the site you earned the badge on, why do I have to log in a second time to get the badge in my backpack?” I’d stare blankly for a bit, and wish I had a ninja smoke-bomb I could toss to make an escape.

It’s a totally valid list of concerns, all of which we’re taking action on. Here’s the breakdown, in convenient list format,

  1. No place to display badges – For the beta release, we added the ability to create group portfolio pages, but only included a simple tweet button. We released the displayer api, hoping to see some pick up by potential displayers, but we’re caught in a catch-22. Lots of issuers want display options before they push a bunch of people into the backpack, and displayers want issuers before they invest in building their own display widgets. To break us out of that cycle, we’re bringing some folks from the community in to help us build out a series of display tools. We expanded the share widget on the portfolio page to include Facebook, Google Plus, and Twitter. A community member is going to build a nice WordPress plugin, and help us with a Facebook app that will aggregate earned badges on your timeline. We expect to have a lot more display options by the end of May / early June.
  2. Login is a mess – Similar to the displayer issue, login is another catch-22. It’s actually super simple, if you’re already set up with Persona / BrowserID, but as that’s a new project, there isn’t a significant existing userbase. Rather than just give up and offer a huge number of login options, we’re working on streamlining the process. We contracted with two UX people, one, Anya from our community, and a second, Erik Kraft, with an extensive portfolio of education sites. Anya has experienced the login issues first hand while building two badge systems, one at the University of Michigan, and another for the Michigan Maker Faire. Both Anya and Erik have ideas about fixing the issues, and we should be able to free up enough time to make a change there by mid-June.
  3. Backpack value story – When you earn that first badge, we need  to explain to the earner what the backpack is, and what it’s going to do for them. In addition to the UX issues and display issues above, we need to tell a story inside the backpack workflow, a screencast explaining what’s going on, what the backpack is, and how it will help the earner learn more, and gain more from the learning. We’re going to start small here, I’m going to make a few screencasts, and we’re going to figure out a reasonable way to work them into the workflow. I’ll be done with the videos in the next few weeks, and have them in the first-badge workflow by the end of the month.


A big goal of the Open Badges project is to create a platform that anyone can use, regardless of device or language. We’re going to make some progress on that goal this quarter, with Matt (the GSoC student) helping us make the backpack and site Section 508 compliant. We’re also going to work on incorporating Mozilla’s localization standards into the backpack and site. Both projects will go beyond the second quarter, but this is when we’ll start making some progress.

We also want badge earners to be able to use their badges on whatever device they want to use, so we’re going to work with some reactive design experts to figure out easy ways to support multiple devices without having to support a ton of individual code forks. The discussions are strategic at this point, so it’s not clear yet what we’ll be offering, or the timelines we’ll be offering them in. I’ll update the roadmap when we know more.

Endorsement, public key infrastructure, federated backpacks

It’s not really fair to smoosh three big topics into a single heading. Beyond the words though, we don’t have a solid plan for any of the three features above. By the end of the second quarter, we want to have paper versions of all the above. They’re topics we’ve thrown around for a while now, if they’re not obvious, some definitions,

  1. Endorsement is the ability for one badge issuing organization to endorse another organization’s badges. Endorsement is a significant step towards a badge ‘economy’, where badges have objective worth relative to one another. A badge with multiple endorsements will probably be ‘worth’ more than a badge without the endorsements.
  2. Public key infrastructure will allow issuers to sign a badge cryptographically. Badge signing will allow the issuers an extra level of security, but will also give the earners truly portable badges, even if the issuer goes away, or stops hosting the badge’s assertion file.
  3. Federated backpacks are the holy grail of the open badges infrastructure. Mozilla’s hosted backpack can’t be the only backpack out there, we want everyone to create and host backpacks. We want them discoverable though, which complicates things. We need a system for making all the backpacks in the world act like one giant backpack for the purposes of aggregation and discovery. This is a tricky one, but it will be super awesome when we’re done with it. Super awesome.

Super Awesome Summer

Given all the above, this summer is shaping up to be…super…awesome. I’ll write about projects as they complete, and will be speaking at a few conferences this summer:

Post Flourish Badge Talk Thinking

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

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.


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

@ @ @ so how do we get @ and @ connected?
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 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 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 #badges.

Isham Randolph, Poet

I’ve written in the past about Isham’s 26 stanza poem, written for Admiral Dewey on his visit to the Chicago Sanitary & Ship Canal.  You can see the entire poem on page three of this album.  I’ve found plenty of examples of Isham’s technical writing, but no other examples of his poetry, until this gem showed up in a memorial, quoted in the Society of Western Engineers, no date is given for its creation, but it is attributed to Isham,

The memorial also had a more detailed record of Isham’s railroad career, which I’ll add to the Wikipedia entry soon.  It also gave the names of his three sons (I only knew one) and his wife.  I found the name of his wife in census records, but not his son’s beyond Col. Randolph (who the memorial says was a Major?)  It also says that Isham helped to organize a regiment of engineers during World War One, and quotes the conclusion of a speech he gave them before their departure for Europe.  Though not poetry, it speaks to the poetic character of the man,

One last quote from the piece, not from Isham, but from the memorial writer, suggesting that a volume of Randolph’s writing, including his poetry, should be published.

I haven’t collected enough of his writing to “gather and edit a volume,” but I have pulled a bit together over the course of the last year, so – I guess I’m the guy that’s doing what this author asked for, just a hundred years later than he expected.

What Badges Would Isham Have Collected?

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

I joined the Mozilla Foundation this week, putting consulting on hold for the time being. Proud to be a part of the @ team.
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.


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.


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.

Ebin. J. Ward v. Isham Randolph

I’ve started to collect any historic records from the Sanitary District of Chicago during the Sanitary & Ship Canal dig on a Google bookshelf.  I’ve found 8 books, including several volumes of the official proceedings of the board of trustees.  All pretty dry stuff, but given enough time could paint a solid picture of the actual construction of the canal.  My guess is that not many of the volumes were printed, and really only for archival purposes.  Isham Randolph mentions them in his memoir, so I’m also guessing that they were mostly held by people involved with the department.

The first two volumes I found, 1891 and 1892 were from the collections of Michigan University and the University of California.  The 1892 edition has this signature on several of the front pages:

I googled “Ebin J. Ward” and found this record at the Chicago Public Library, “The Illinois water-power-water-way / an attack by Ebin J. Ward ; and defense by Robert Isham Randolph.”  Kind of cool, the Google books scanned copy is from the personal collection of one of Isham’s professional rivals.  One of these days I hope to come across a scan of something from Isham’s collection.

Some other clips -

Consulting, and the Open Badges Project

Some big changes for me this week, I started a consulting company, and kicked off my first client assignment – helping the Mozilla Foundation with the Open Badges Project.

Open Badges give credit for learning outside of a traditional institutional setting. The kind of learning that matters, but isn’t often officially credited. Anyone can issue a badge, sign it (through a nifty cryptographic scheme), and anyone can display their badges in their own ‘backpack’. That relatively simple explanation opens the door for lots of peer-to-peer style education opportunities. It’s a disruptive idea, as disruptive to the current education system as the Awesome Foundation is to philanthropy.

The big mind hack of the Awesome Foundation is to convince people that they can create change in their communities without the help of large charitable organizations. It doesn’t discount the work those organizations do, it enables people to have a meaningful impact without their approval or help. Open Badges has the same potential  – give the ability for people to acknowledge one another’s skills without the help of a large institution. The Open Badges Infrastructure (OBI) runs anywhere, and won’t need Mozilla to issue a badge, or even sign off on or host a badge.

Social change aside, it’s also a cool project from a technical perspective. Built on Node.js, developed in the clear on Github, with a team of super smart folks, it will certainly be a great learning experience, and a lot of fun to work on. I’m thrilled to be a part of it. I’m going to take any opportunity to speak about the project I can find, both from a technical and non-technical perspective. As talks emerge, I’ll update @chmcavoy. The project is also hiring full-time Node engineers, if you’re interested – drop me a line.