Badges and more!
Recent Tweets @soletelee
Posts I Like
Who I Follow

We’ve talked a ton about BadgeKit over the past few months from its initial announcement back in October at Mozfest to BadgeKit MVP defining, tech defining, user experience design, to more recently BadgeKit for Cities

Many of these posts pointed to BadgeKit being made available at the Digital Media & Learning conference, this year taking place in Boston from March 6 through 8. 

And we’re finally here! We will be making BadgeKit available to organizations interested in issuing open badges. As previously mentioned, this initial release of BadgeKit targets organizations, like cities, who want to stand up larger-scale badge systems. This was a natural evolution of the work we did for Chicago Summer of Learning last year and the tools we developed to support that initiative such as Badge Studio (badge design tool), Open Badger (badge defining and issuing tool) and Aestimia (badge application and assessment tool). 

So what will this initial release of BadgeKit entail for issuing organizations?

* Enable access control

The issuing organization can create an uber admin login and from there grant some level of access control like who gets to issue a badge and who gets to assess/review a badge. We are thinking about adding more granularity down the road with ongoing user feedback and issuer requests. 

* Design a badge

The issuing organization can get started on designing and defining their badges. BadgeKit will support the full badge life cycle states from draft form, published to archived. The badge design and defining experience will be scaffolded through the introduction of templates. An example of templatizing badges can be found in the badges designed and issued as part of Chicago Summer of Learning. These badges all shared a hexagonal shape and a Chicago city banner that hung across it. 

This is an example of templates used to create consistent badge design but they can also be used for content creation. Some badges that are part of the same program may share similar information, like issuing organization name, program name, including elements of criteria. Rather than the issuing organization having to rewrite this information with each new badge, templates can help build on templatized content. We think templates can greatly help streamline the badge creation process for organizations. 

* Create badges that level up

Not only that, issuing organizations can build in leveling up features into their badge system. We are calling these milestone badges. An issuer can define the set of badges that together unlock a larger badge, which we are calling a milestone badge. 

* Issue a badge via email

The issuing organization will be able to issue a badge using the earner’s email. However, as perviously mentioned, BadgeKit is intended to be a backend admin support for issuing orgs who have existing sites where their communities reside. When a badge is issued to an earner via email on BadgeKit, this information is relayed to the issuing org’s application for the issuing org to determine how the badge will actually be delivered, whether via email, SMS or message in a bottle. Badge issuing via email is supported through the BadgeKit API with the issuer, customizing specific experiences according to their community needs and desires. 

* Display a badge on Issuer site via BadgeKit API

The issuing organization will be able to pull all the badges they have designed and created on BadgeKit onto their own website through an API and customize the badge interaction experience for their community of badge earners. 

* Support earners to apply for a badge on issuer site via BadgeKit API

When an earner is on the issuer site and comes across a badge that she would like to earn and can apply for online, she can do so. The earner, or prospective earner in this case, can click through and see the badge criteria and apply for the badge by submitting relevant information and evidence. This experience is supported by the BadgeKit API. 

* Assess a badge 

Once the prospective earner has submitted all relevant information on the issuer site, that badge application becomes accessible on the site to badge assessors/reviewers who have been granted the appropriate access controls from the issuing organization. Assessors/reviewers can then see the queue of badge applications and start evaluating them based on pre-defined criteria and/or rubrics. They can provide feedback and determine whether to issue or deny the earner of the badge. As mentioned in bullet 4, the earner experience of the actual delivery of the badge is defined by the issuer. 

* Support earners to send their earned badges to federated backpacks

n.b. Federated backpack feature will come later this month

Because BadgeKit is integrated with the open badges standard and APIs, the earner has the opportunity to send their earned badges to federated backpacks where they can decide how they want to further share it out to various social media channels. 


In addition to all this, it’s worth noting the brand definition work that our designers took on. We have a nice streamlined BadgeKit logo that is cohesive with the parent brand of Open Badges as well as Mozilla. This work was led by our designer Adil Kim with the guidance of our Creative Lead, Jess Klein who has written about this in greater detail in her blogpost:

We’ve made a lot of progress in the past few months but we still have a lot of work to do. As you can see, this initial release is focused on issuing organizations who have some level of technical resources and have an existing community-facing site into which they can integrate their badge system. Thereby it seemed appropriate to call this release private beta.

However, the goal is to make this more widely accessible in subsequent releases. As you well know, we develop and design in the open so all our code, sketches, wireframes and staging information are in fact out there for anyone to keep an eye on and poke holes at.

We’re excited to have reached this major milestone and look forward to feedback from issuing organizations who start to plug in!

n.b. We realize there may be a bunch of questions so we’ve put together some FAQs so take a look! Thanks to you all and as per yooszh, more to come!

This has been a crazy week for the open badges team. 

Amongst our team members, we are covering 3 conferences: ATP Innovations in Testing, SXSWEdu and the Digital Media and Learning conference

This includes 3 panel discussions, 1 interactive talk and presentation, 1 ignite talk, 2 Science Fair booths preparation, not to mention 1 BadgeKit private beta release and 1 Discovery prototype showcase. 


I wrote this while I was on a plane with colleagues Meg from the Badges team, Matt Williams from SF Hive and Dustin from Sprout Fund. We had departed an unseasonably frigid Austin, having survived SXSWEdu, and were headed to an even more frigid Boston for DML. 

So where are we at this midway-ish point in the week?

  • I think we’re pretty good to go with BadgeKit Private Beta release. More to come on that through several of our channels. 
  • We’re excited to showcase the Discovery prototype at DML and to get feedback from conference attendees. 
  • We have 1 panel at ATP, 2 panels at SXSWEdu under our belt now and have 1 more SXSWEdu panel, 1 ignite talk at DML and 2 Science Fair booths to go. 

Reflections on the panels and sessions so far:

I couldn’t help but notice that the badges and digital credentialing conversation has come a long way. The ATP Innovations in Testing has not been a conference we had participated in the past. It is attended by the well-known guardians of high stakes testing, assessment and accreditation like Pearson, ACT, ETS etc. I popped into a couple sessions and was surprised to see the level of interest around digital credentialing and also its increasing relevance. On the actual panel that I had the honor of being a part of, it was clear that the badges conversation had expanded beyond the esoteric and was reaching a broader audience.

*** A session at ATP Innovations in Testing about the Changing Landscape of Recruiting in Industries, mentioned Digital Credentialing and Mozilla Open Badges. 

I would say the questions fielded and the level of interest and enthusiasm shown at our SXSWEdu sessions would corroborate that. 

A lot of work remains, both in the near term (this week) and longer term (getting wider adoption of open badges as complementary digital credentialing). While extremely tired right this moment, I’m also still pretty excited and looking forward to all the adventures ahead. 


As you all know, I can’t stop talking about BadgeKit, the product we’re working on for a beta release in early March. As it turns out, folks are starting to line up to get in on the BadgeKit action and many of them are cities who would like to bring the Summer of Learning experience, like the one Mozilla collaborated on with the city of Chicago in 2013, to their respective neighborhoods. 

So with several different cities expressing interest for a summer 2014 rollout, we started to think, what would Cities of Learning 2014 look like built on top of BadgeKit?

Chicago was definitely unique as they were the guinea pig for the tools we’re now evolving and refactoring to form the base of BadgeKit. But as more and more cities line up, we think there’s an opportunity for a shared model among cities in which cities leverage one another’s content through a common technical infrastructure powered by BadgeKit. 

Rather than Milwaukee, Chicago, Los Angeles, Dallas and Portland, having their own Summer of Learning sites that are silo-ed and independent, what if we provided cities with the option to leverage one another’s learning content and badging experiences? That would essentially multiply the learning pathways and engagement opportunities for their community of learners. How exciting would that be; for a learner in Milwaukee to check out all the cool things going on in the city of Portland, or LA or Chicago?

Not only that, the shared technical infrastructure could provide multiple benefits for cities such as the following:

  • Through sharing a common framework, cities can reduce complexity and create turnkey badging solutions
  • Cities are provided with an opportunity to connect with multiple organizations and networks, not to mention other cities
  • A shared framework can reduce costs
  • Cities can share resources, diversify content and create more badging experiences for their learners
  • Cities can play a pivotal role in investing in building the foundation for a badging system that can be expanded to more cities and organizations

But Mozilla cannot do this on our own. We must enlist partners within our network that can help coordinate the complex web of working with city governments and the unique needs of each city locality. In addition to providing a sound software infrastructure to support multiple city needs, we need to provide adequate training and support for cities to implement and execute. 

As such we are working closely with the MacArthur foundation and our Chicago Summer of Learning partner in crime, Digital Youth Network, to plan out the details of the BadgeKit for Cities shared infrastructure. Our first BadgeKit for cities guinea pig will be the city of Chicago yet again, this time under the name, Chicago City of Learning (CCOL)

CCOL will be testing out their next evolution of CSOL in April to coincide with Chicago Public School’s spring break. At this point BadgeKit will be plugging in and integrating with the CCOL site and powering its badging experiences.

From there we hope to continue to add additional cities and expand on the shared infrastructure to include several different cities across the US and North America, multiplying the learning and engagement opportunities for learners at a greater scale. 

Details around Cities of Learning are starting to crystalize and we’ll continue to provide updates as we go along. We’re excited for all that’s ahead in 2014 and thrilled to grow and scale our Chicago Summer of Learning 2013 experience. 

This past week, we marked the completion of Milestone 2, affectionately coined, “Preparing for Flight” on our BadgeKit product development roadmap. The milestone preceding “Preparing for Flight” was, “Ducks in a row”

The goals we wanted to reach in Ducks in a Row are very much deducible by its name. We wanted to ensure we had everything teed up for us to move efficiently and effectively throughout the development of BadgeKit. We essentially wanted to get all our ducks in a row prior to the holidays so we could hit the ground running once we came back in the new year and pick up where we left off. As a refresher, our goals for Ducks in a Row included the following:

  • Product definition finalized
  • Software architecture conceptualized and defined
  • Wireframes for MVP designed
  • Plan for implementation drafted

** check out the amazing badges Jess designed for the team, each time we reach a milestone. This one is for Ducks in a Row. 


Our work was happening in parallel between the design team, led by Jess Klein and our development team, lead by Chris McAvoy, of course with a lot of cross pollination. While the design team sketched out the user experience, the development team deep-dived into the software backbone originating from the Chicago Summer of Learning experience, namely Open Badger, Aestemia, BadgeStudio and the CSOL site

Coming back from break, we found ourselves refreshed, recharged and ready to go. And we dived into what we set out to accomplish in the next milestone, “Preparing for Flight”, for which a big driver was user testing. 

In previous product development roadmaps, we’ve meant to incorporate user testing early and frequently but a lot of times when corners needed to be cut and project timelines re-negotiated, user testing would often be the first thing to get compromised. But with a dedicated user researcher on the team, shout out to Emily Goligoski, we have a strong, prevailing voice, advocating for the need to layer in user testing early on in the product development cycle, not to mention, our Creative Lead, Jess Klein, strongly supporting this vision. 

As such, right out of the gate, the goal of milestone 2 was to get to a prototype that was testable. The following comprised the overarching goals of the Preparing for Flight milestone:

  • Working app: mockups / stubbed functionality for anything that isn’t ready
  • User testing sessions identified
  • User tests planned
  • Milestone badges, aka meta badges, aka level-up badges, experience within BadgeKit designed
  • Visual language study initiated
  • Federated city backpack requirements explored
  • Branding work initiated

We reached this milestone this week as initially planned. What that means is that today, we have something that looks a lot like the UX sketches designed by Matthew Willse, our lead UX designer, on a staging site that provides a solid, albeit work in progress, BadgeKit experience. There are of course a lot of things missing here. There is essentially no UI direction or touch, many pages are “stubbed out” meaning there may be links to pages but those pages are not fully functioning yet and the front end is not entirely wired up with the backend powering many of the intended experiences. But there is still enough there to get out to users who can weigh in on the initial proof of concept and provide us with a gut check on our direction. 

We also got a badge for completing this milestone, courtesy of Jess Klein. :)


Emily has drafted the script for user testing and circulated it amongst our team members and the inner circle within the concentric circle of networked partners. The idea is, we want to test it, but we don’t want to freak people out who are not familiar with testing a product at a very elementary stage and are distracted by the lack of polish or UI. 

So we’re super stoked to have reached milestone 2, with user testing meeting us at the check point. Of course, we’re already fully in tackle mode for Milestone 3, which we’re calling Take Off. We welcome you to keep track of its progress here:

We’ll keep chugging along in the mean time!

In an earlier blogpost, I shared our thinking behind our BadgeKit MVP
Having gone through the exercise of defining the basic user interactions that we wanted to support in our March 2014 release, we started to think through the site architecture that would house the said user interactions and the supporting APIs that would help power the experiences. 
To sort through this I took each MVP user interaction from my earlier blogpost and mapped it against site and API requirements as follows: 


1. We want an issuer to visually design the badges and define the criteria for earning them. 


At the very basic level, there should be a page within in which the issuer should be able to do the following:
  • Start visually designing a badge. Think any of the following badge design tools: , MakeBadges , Achievery , CSOL Badge Studio
  • Define the metadata that will be embedded within the badge aligned with the open badges standard. 
What if the issuer wants to save badges mid-design? Then the issuer should be able to log in with some identifier and save the badges that have been created whether they’re simply in draft form or complete. As such, issuer should additionally be able to do the following:
  • Log in
  • Save created badges in various stages of design
  • Access, open and edit previously saved badges
This badge design and defining experience should be supported within a page. 


2. Learners can then apply for the badge by submitting evidence and their e-mail address
To support this earner interaction, we thought through what the issuer would need from BadgeKit.  


Following user interaction 1 outlined above on the site, there should be a page in which the issuer can see see a listing of all the badges they’ve created. 


On the issuer site (not the site), there would need to be some ability for the issuer to pull in this listing of badges created (with some level of filtering) through an API that the potential badge earner can see, learn more about and apply for, again on the issuer site. 


So how would BadgeKit provide support for this? 
  • There should be an API that enables the issuer to pull in all the badges they have created from user interaction 1, onto their site.  
From there, the API would support the following user interactions:
  • Potential badge earner could apply for badges that are apply-able. 
  • Potential badge earner could submit all required evidence in order to apply for the badge. n.b. The evidence won’t be going into the API, simply links to the evidence from the backpacks hosted by the cities. 
  • Potential badge earner could save their badge application. 
  • Potential badge earner could submit their badge application. 


The submitted badge application would then go into a queue in a page within the site that mentors/assessors can access which leads to the next user interaction. 


3. Mentors or peers can review the badge applications against the criteria.  Once criteria is met, the badge will be issued to them (email being one method).


Within, there should be a page that mentors/assessors with the appropriate permissions can log into and access the queue of earner submitted badge applications. 
Within, there should be a page in which the issuer should be able to do the following: 
  • Grant appropriate access to designated badge application mentors/assessors
  • Define rubrics for mentors/assessors to assess badge applications. 
  • Define threshold for badge awarding and rejection. 
  • Define pre-canned feedback for badge applications by under 13 earners. 
Having done that, mentors/assessors with the appropriate permissions should be able to do the following:
  • Open badge applications. 
  • Review badge applications against a rubric. 
  • Provide feedback to the badge applicant. 
  • Award or reject badges based on assessment rubric. 
Once badges are assessed, the badge earner should get a notification informing them of the badge acceptance or rejection along with appropriate feedback depending on whether the earner is under 13 or not. 


4. Recipient accepts the badge and sends it to their backpack - badge acceptance flow from email


On the issuer site, there should be a badge detail page (pulled from the API mentioned in user interaction 2, that is linked from the notification email sent from user interaction 3, that should enable the following:
  • Earner clicks on link included in badge award notification email. 
  • Earner lands on issuer site with badge image and detail information that prompts earner to send earned badge to backpack. 
  • Earner clicks prompt which triggers badge acceptance flow into the Mozilla Backpack or city backpack. 
To support this experience, the issuer would need to integrate with our Issuer API which enables this badge acceptance flow. The details of badge acceptance into city backpacks is still being ironed out as we sort out the details of federation so more to come there. 


5. They share their badge on their [Facebook or even LinkedIn hey!] profile.


To support this experience, we’re thinking about this in a couple of ways. 
  • The issuer could integrate with our Issuer API which currently enables a version of this flow triggered within the Mozilla Badge Backpack site. Either that or the federated backpack they’re hosting has sharing api’s enabled.
But we’re thinking about ways in which a badge can be shared out to various web properties without reliance on the share functionalities of the Backpack, whether it’s the Mozilla one or the city one. We could enable embed and baked badge download and upload features through our APIs. The details of share and the site properties in which they should occur are still in the process of being sorted out. 


Having gone through the user interaction steps originally mentioned in the BadgeKit MVP flow, what I’ve found to be missing is the experience of the issuer generating claim codes and issuing badges based on an earner identifier like email. So let’s add those. 


6. Issuer should be able to generate claim codes for badges created in user interaction 1, outlined above. 


To support this, within a page on the site, the issuer should be able to do the following:
  • View all badges created from user interaction 1. 
  • Generate claim codes for each badge. 
  • Generate claim codes manually or automatically. 


7. Issuer should be able to issue badges based on email for badges created in user interaction 1, outlined above. 


To support this, within a page on the site, the issuer should be able to do the following:
  • View all badges created from user interaction 1. 
  • Issue badge created with earner email. 


The above was an attempt at a basic understanding of the required components of the site architecture and supporting APIs. From it, we’ve come up with the following Information Architecture framework sketched out by our Creative Lead, Jess Klein




Each week we get a little bit more detailed with the product definition and going through this is all part of the process. We welcome your feedback, comments, questions and concerns!

We’ve gone ahead and announced BadgeKit, we’ve shared the common verbs that drove our brainstorm around its definition and we’ve kicked off conversations with many folks in the community for feedback on our thinking. 

Having done this sort of wide and open brainstorm around BadgeKit, we’re now trying to reign things in a bit and get clear and concrete around a definition of the beta version of the product, i.e. the MVP, the minimum viable product, that we’d like to get to by March 2014. 


The verbs that drove us to the initial thinking of BadgeKit served us well but we needed to brings things down a level closer to the reality of the user experience.

So an exercise we did was to think through a complete end to end user experience we wanted to enable. That user experience is captured in the following steps. [This is also documented in our BadgeKit github repo wiki.] 

1. We want an issuer to visually design the badges and define the criteria for earning them. 

  • The issuer should be able to visually design badges. 
  • The issuer should be able to define the metadata aligned with the open badges standard. 
  • This includes the criteria page outlining the requirements for earning the badge. 
  • This includes defining evidence required for earning the badge. 

n.b. Keep in mind that badge designing can be done on a number of existing platforms including Makebadges, Achievery,, and many more.  

2. Learners can then apply for the badge by submitting evidence and their e-mail address  - on a splash site for DML

  • After the badge has been designed and defined and made available to earn, learners should be able to apply for that badge. 
  • Badges built on other badge design platforms should be easily importable and made available to earn. 
  • The learner should be able to go to some site, say the Digital Media & Learning conference site, and see all earnable badges created by various issuers from step 1. 
  • The learner should be able to see all the information behind the badge including criteria information. 
  • The learner should be able to apply for that badge by submitting appropriate evidence and email address. 
  • The learner should receive a notification confirming they have applied for that badge. 
  • The badge application should go to an assessor review queue awaiting assessor review. 

3. Mentors or peers can review the badge applications against the criteria. 
Once criteria is met, the badge will be issued to them via email.

  • Submitted badge applications need to be reviewed and assessed based on defined criteria. 
  • Designated mentors with permissions or peers, aka assessors, should be able to go to some site, and see all the badge applications that they are allowed to assess. 
  • Assessor should be able to click on a badge application and review it against the provided rubric. 
  • Assessor should be able to provide feedback to the badge applicant. 
  • Assessor should be able to grant or deny a badge. 
  • Badge applicant should be notified that they have earned a badge or not earned a badge. 

4. Recipient accepts the badge and sends it to their backpack - badge acceptance flow from email

  • Badge applicant, when provided with notification about the badge status, should be able to act on the information provided in that email. 
  • Badge applicant, when notified, should have access to the feedback provided by the assessor. 
  • Badge applicant, when awarded a badge, should be able to send the badge to their backpack. 
  • Badge applicant, when denied a badge, should be able to reapply for the badge.  

5. They share their badge on their [Facebook or even LinkedIn hey!] profile.

  • Badge earner should be able to easily share out their badge to their Facebook profile page from their backpack. 
  • Viewers of the badge on the Facebook profile should be able to see all metadata embedded within the badge. 


Sound simple enough? The good news is we have a lot of the pieces in place already to drive this experience. But there’s plenty of room for improvement. We’ve built many of these component pieces while building CSOL, but we want to make the experience better, smoother, faster, and more seamless. 

In our initial brainstorm, we had a laundry list of things we wanted to include as part of BadgeKit. But thinking through what we wanted to deliver for beta, we felt like rather than introducing dozens of new half-baked features, we wanted to build something, while seemingly narrow in scope, really really well. So our MVP delivery will be gut checked by the above steps. We’ll make sure we do a kick ass job with enabling a fluid user experience outlined above and keep you all in the community apprised of each step. 

The Open Badges team has returned from Mozfest in London and is now going through the process of taking in and digesting all the amazing conversations, brainstorms, hacks that transpired during the festival to extend our work. 

One of those insightful conversations took place during the BadgeKit session that Jess Klein and I facilitated with the support of Erin Knight and Chris McAvoy.

[You can read more background information about BadgeKit from the following blog posts written by Jess Klein, Erin Knight and myself.] 

We are still at the inception stages of BadgeKit, defining and honing its features, utility and priorities. Things are still in motion at the moment. As we do in typical Mozilla fashion, we wanted to get our thinking out to the community as soon as we could in order to make sure it resonated with key stakeholders and to have a gut check on our assumptions. 

The session was designed such that Jess and I, as facilitators, did exactly that; facilitate rather than present or dictate the conversation. Truth be told, the intention was to get as much information from the session participants as possible so that we could incorporate that feedback into the evolving BadgeKit design thinking. We wanted answers to some of the following questions;  

  • Did the verbs around which we started designing BadgeKit resonate with you?
  • Were there verbs that we missed that also need scaffolding and support?
  • Which verbs were most important to you and your organization and why?
  • Were our verb definitions aligned? i.e. Does “assess” or “design” or “apply” mean the same thing to everyone?
  • Does the idea behind BadgeKit excite, confuse, or scare you? 
  • Does the idea behind BadgeKit seem aligned with your expectations as the open badges ecosystem grows and evolves?

We didn’t get to the bottom of all these questions during the session but we were able to get broad first impressions. 

After introducing the key verbs to the audience, we had everyone do a post it exercise, jotting down thoughts related to each. The results are as follows, transcribed the best I could:


  • No need for design / Coding skills <— +1
  • WYSIWYG editor for visual design
  • Criteria page builder
  • metadata definition
  • Creating pool of reusable badges or designs
  • Tools in multiple languages (open for contributions)


  • Grades?
  • Access to work
  • Peer or tutor assessment <— both should be supported
  • Notes / feedback to learner <— Yay!
  • Feedback if they have not met criteria
  • Academically / professionally recognized by relevant bodies
  • Github issues, online bug tracker style management backed interface for tracking, assessment of learners’ “applications”
  • interconnection with HW {hardware} (location tracker, GPS, fitness, access cards, cars…)
  • Helps visually track the learning process <— like duolingo? <— open for educator / dashboards
  • Teachers can make badges for students and see their progress
  • Criteria and evidence
  • Different states of same badge (citizenship badge in charity works)
  • Reporting on who has done it / progress
  • Submit application with evidence (links to bugs, docs, etc.)


  • Validate
  • Informal online recognized qualification
  • Access -> beyond email
  • A really, really, really, really, really, really, really, really, really, really, really well documented & simple API <— Like copy paste youtube embeds?
  • Security? badge contains hash / secret? vis bitcoin?
  • certification
  • issuing authority should be able to communicate standards for the badge. tl;dr certification
  • Existing issuer pushed to support open badges (e.g. foursquare)
  • Work with different bodies - cooperation
  • Single click <— +1, time limited, revokable 
  • Value rank, relative { }
  • Visually cool looking tools to create / describe / issue / open for involvement of learners
  • Support for gaining a badge


  • Effortless
  • Employment
  • Online CV!
  • LinkedIn
  • Final in! to something
  • Can’t be isolated
  • 'Open CV'
  • 'Gradular' display
  • Connect badges with same area
  • Some possibilities to move metadata if some server goes down?


  • Is metadata of badges easily searchable by third parties
  • Social network integration, twitter, Facebook, linkedin
  • Open backpack
  • Carry badges into every profile you have across the web
  • Address < 13
  • Portfolio integration (on backpack also as an ePortfolio)
  • issues regarding info about minors
  • Resume / CV


  • Visual easy ways to show systems of badges for learners
  • Wikipedia style taxonomy for breakdown of areas of human knowledge + interest
  • Backwards badging known people - model pathways
  • Ongoing personal + professional development
  • How do I find badges that are relevant to me?
  • Different pathways to same goal
  • Search by topic of interest
  • Highlight common paths “next badge” based on those completed/earned
  • Search
  • Other doing badge
  • Search engine for discovering available badges
  • Share
  • Cumulative badges. Earn a badge for earning X badges in a subset. 
  • Pathways - yes, Need to follow complete route from start to finish - maybe
  • Clear progression between badges in a pathway
  • 3D journey visualization


  • To easily make badges and descriptions and have them easily be distributed
  • Mobile app / display case for tablets
  • Connect badges to social media
  • Keep all your badges in one place
  • "Badges are successful when…" user guide
  • Displaying integration for variety of platforms (open for customization)
  • Single click resume creator converting badges to professional doc <— +1
  • Platform agnostic
  • Framework of badges tool
  • Gamified learning experiences
  • Curriculum template - what components make ‘good’ learning badges


  • Tools to group badges in backpack according to ‘tag’ or ‘standard’
  • Backing from universities and coursera <— +1
  • Backing from Linux user groups / hackerspaces
  • Verifiable as from particular organization
  • Evidence about others who received badge already (= value, uniqueness)
  • Tools to validate and display if badge is validated
  • Recognition 

A lot of the features we have been aggregating ourselves and have been thinking through were reflected in the post-it notes added by the session participants in this group exercise. 

You can see how it compares to our own list here:

One verb that was added by participants was “VALIDATE (ENDORSE)”. Some of the thinking reflected on the Validate board bleed into others. A reasoning behind omitting endorse was that we felt it was a level above the foundational pieces of BadgeKit. BadgeKit is intended to be the absolute basic tools required for badge system design and development. While one can argue “Use” to be a level above as well, we included that because there needs to be an audience of badge reviewers and users, i.e. consumption to meet the demand in order for a basic badge market structure to take hold. 

We’re cognizant that this is simply a small sample size of open badges ecosystem stakeholders but it was great to have this validation of our initial thinking come from the community. 

Having compared the post-it notes with our own list, next step for us is figuring out what features to implement first. We’ll be reaching out to the community for further feedback in helping us think through the priority of features for implementation. 

The BadgeKit session at Mozfest was a great opportunity for us to kickoff the BadgeKit conversation and we’re thrilled to keep that conversation going as we make progress towards development and implementation. 

This past summer, the Open Badges team had the great opportunity of introducing digital badges at a citywide scale through the Chicago Summer of Learning (CSOL). We worked in collaboration with the city and on the ground organizations like Hive Chicago and Digital Youth Network with the support of the MacArthur foundation to reach out to more than 100 Chicago-based organizations to create an end-to-end badging system.

As mentioned in my previous blogpost, to support this initiative, we created a set of tools and services to help the 100+ Chicago based organizations to design, define, assess, and issue badges and for participating learners to collect, manage, share and discover badges

Following a successful summer of learning, we’ve been getting increased interest from other cities and organizations who would like to replicate the badging model initiated in Chicago. We’re thrilled about this interest and would like to facilitate the adoption of other CSOL like initiatives in a scalable way. This would entail us going back to the tools and services we built for CSOL and for the ecosystem, modularizing them, and making them readily implementable for organizations in a light-weight, open-source way. 

The idea is to make it as simple as possible for organizations to pick up the specific tool they need for their badge system development and implement it into their environments. Time and time again, we’ve heard that the barrier to entry is still too high. We want to lower that barrier. With that in mind, we started writing down the requirements and goals for what this collection of tools might be. 

The key verbs that we kept using over and over again when trying to get crisp about this tool collection were as follows:

  • Design badges: Enable organizations (or individuals) to visually design their badges
  • Define badges: Enable organizations (or individuals) to define the information behind the badge according to the open badges standard, i.e. metadata specification
  • Assess badges: Enable organizations to define rubrics for assessment and assess the badges accordingly
  • Issue badges: Enable organizations (or individuals) to issue their badges once the criteria is met
  • Collect and manage badges: Enable learners to see all the badges they have earned in one place, organize and manage them
  • Share badges: Enable learners to share their earned badges easily across the web
  • Discover badges: Enable learners, issuers (and down the road employers) to discover new badges and badge owners

We took those verbs and matched them with the tools we had built either for CSOL or as part of building out our ecosystem and they aligned as follows:

  • Design - Badge Studio
  • Define - Open Badger
  • Assess - Aestimia
  • Issue - Open Badger
  • Collect & manage - Backpack
  • Share - Backpack
  • Discover - CSOL Backpack

So we already have a lot of the components of what would comprise this stack of tools, which we’ve started calling BadgeKit. But we have work to do in order to clean these component pieces up and modularize them into light-weight, open-source tools that would work like Lego pieces that an organization or individual can build and stack according to their tailored needs. 

At this moment, we’re finalizing and cleaning up the requirements for each verb. And we want you to weigh in. We’ll be holding a BadgeKit session at the upcoming Mozfest during which we’ll explore with the community, questions on how this toolstack could benefit them. 

We want to tackle questions like the following:

  • What are the challenges you foresee and or have endured in developing a badge system?
  • What focus would you like to see developed to satisfy your badge system development needs?
  • What are the use cases for BadgeKit that we should explore further?

We’ll be talking a lot more about the BadgeKit moving forward at Mozfest, during our community calls and on our mailing lists. The community is a critical part of the development of BadgeKit since it is being built precisely to service our community interested in being a part of the open badges ecosystem. We are looking forward to hearing your thoughts on BadgeKit and incorporating your feedback. 

In the mean time, here’s  a teaser BadgeKit postcard created by our own Jess Klein:



n.b. the url will go live at Mozfest. 

About a month ago, the open badges team was approached by the folks at American Institutes for Research (AIR) who in collaboration with the Department of Education had kicked off the Connected Educator initiative in 2012. Last year, they launched their inaugural Connected Educator Month with the goal of 

  • Getting more educators “connected” (to each other)
  • Deepening and sustaining learning of those already connected
  • Stimulating and supporting collaboration and innovation in professional development

The initiative was a big success with over 170 education organizations, companies and communities involved and over 4 million followers of the #ce12 hashtag by the end of the month. 


For their second year, they wanted to include badges as a way to capture the learning and professional development connected educators were undergoing throughout the month and we had the wonderful opportunity to work with the folks at AIR and the Dept of Ed to make badges on CEM a reality. 

We had 2 weeks to make this happen and we were able to do so by largely repurposing the tools we built for the Chicago Summer of Learning (CSOL), namely Open Badger, the badge issuing tool, and Aestimia, the badge assessment tool. 

CEM’s badge system was smaller in scale but the audience reach was larger, national and distributed. 

We first distilled what we need to build in order to make badge issuing and earning possible on the site. 

CEM staff would first design and define their badges which landed in 4 different categories, Peer to Peer, Starter Kit, Connected Educator and Participation:

  • Peer to Peer badges were badges that would be issued from a peer to another peer. A connected educator would submit their email as the nominator and the email of a fellow peer they wanted to nominate for the badge and include information on why they believed that peer deserved to earn that particular badge. This information would then go to an assessor who evaluated the reason provided by the nominator and approve the badge to be awarded to the nominee. 
  • Starter Kit and Connected Educator badges on a functional level were very similar in that the connected educator would apply for either one of those badges, submit evidence, which was sent to an assessor who evaluated the evidence against criteria and was either awarded (or rejected) with a badge. 
  • Event badges were to account for participation in the hundreds of events that get added to the CEM calendar that include webinars, conversations, discussions etc. When events were added, CEM staff would generate a unique multi-use claim code for the event and give that to the event organizer to disseminate at their event. Event participants could then go to the CEM site and input the claim code, and get recognized for participation in the event. 

All these experiences were supported through the repurposing of Open Badger and Aestimia. 

In Open Badger, we tailored the badge parameters to fit the needs of CEM. We then input all the badges that were defined by the CEM staff. We trained the CEM staff so that they could continue to add participation badges for the events as they came through. We also taught them how to generate claim codes to disseminate to the event organizers once the event was created. 

We tailored Aestimia as well. For instance, as CEM does not deal with an under 13 audience, all the notification triggers and details related to dealing with under 13 youth were stripped. CEM simply needed a facile interface for the staff to see the badge applications and nominations and provide approval or not. 

We were able to ramp up, gather and define all the requirements for CEM, repurpose the CSOL tool suite to meet those needs, build a microsite that enabled connected educators to view, apply, nominate or claim badges, train CEM staff, do a brief round of QA and get everything out the door within 2 short weeks. 

This was an incredibly rewarding and heartening experience. It was great to see the CSOL tools we built be extended to service other organizational needs and it was exciting to know that we were able to do so rapidly. A lot of work remains to get the tools fully modularized to make extensibility more facile but undergoing this project with AIR and the Dept of Ed in a very short period of time was an indicator that we are not too far off. We’re excited to make these tools readily available for those interested in developing a badge issuing and assessing component to their site and we’re hard at work to make this happen. More to come on what’s next on this toolstack. Stay tuned!

Mozilla summit is an opportunity for Mozillians from all across the globe to come together and celebrate the work we do, the contributions we make, the conversations we have and the products we build, to promote the Mozilla manifesto and ethos. This year, summit took place in 3 different cities, Brussels, Toronto and Santa Clara at the same time attracting nearly 700 people in each location. 

The Open Badges team was distributed across these 3 different cities, allowing us the opportunity to bring in our own global contributor community to these locations to partake in the big picture discussion of being a Mozillian as well as being an integral part of the growing open badges community. 

My colleague Carla Casilli and I were joined by community members Nate Otto working with Dan Hickey at Indiana University on the DML badge system documentation project, Lisa Dawley of Planet Stewards, a DML grantee and Joanna Normoyle of UC Davis, another DML grantee, in the Santa Clara location. 

Our goals going into Summit were as follows:

* Educate Mozillians who are not familiar with open badges about our work and its potential
* Get Mozillians excited about how open badges can impact their work and communities
* Get folks activated to create open badges for their own communities for the purpose of engagement, skills recognition or any other purpose

Our plan of attack was to keep ourselves _very_ busy throughout the summit by participating in the world fair, the innovation fair, hosting a couple badges related sessions each day. It was quite the whirlwind!

I feel as though we have certainly accomplished our goals. In addition, the following are some of my observations and thoughts distilled from numerous conversations that I had at Summit. 

  • Mozillians generally get open badges and many we’ve talked to are really excited about their potential. These folks have been contributing to Mozilla whether it is through checking in code, evangelizing, creating documentation, working on localization, etc because they believe in the Mozilla mission. While these contributions are not necessarily made with the intended goal of getting recognized, they understand the value of having this work captured in a way that is easily communicated to those that might be interested to know. Many mozillians are contributing to the Mozilla mission in their spare time outside of their separate jobs and careers. In addition to material swag like sweatshirts and bags, providing ways for these contributions to be recognized and documented can help them with new opportunities. 
  • People loved the summiteer badges During the week leading up to Summit, the open badges team rapidly put together a microsite that enabled summit-goers to claim event participation badges. We wanted to take advantage of the captive audience at the summit and encourage folks to try out open badges and create a backpack. Three beautiful badges were designed by our creative lead, Jess Klein, for each summit location. These participation badges turned out to be a big hit at all of our summit locations. During the innovation fair, Carla and I were clamored by folks coming to our station to claim the Santa Clara summit participation badge and reports back from our colleagues at the other two locations mentioned the same. While these were super-lite editions of open badges, definitely not reflective of any skill attainment, they helped folks grok the idea, create their backpack and get engaged.

  • Mozillians want to be able to better articulate their skills and strengths on Many mentioned that they’d like to see open badges integrated into and have their earned badges displayed on their profiles. Currently, there is a capability to add tags of skills but these are self-proclaimed. There was mention that badges could be a complement to this feature by providing verified badges that can give more weight to the self-proclaimed tags. 
  • Badge where badging works and makes sense. The reality is, you can put a badge on just about everything. But truth be told, sometimes it just doesn’t fit and there’s no point in forcing it. We’ve talked to folks at SUMO, web dev, web QA, etc to understand how they’ve historically engaged and recognized their contributors and the methods vary a great deal. Sometimes contributors are sent a simple yet personal email expressing gratitude, sometimes they’re sent material swag in the form of tshirts, bags, plush toys etc, and sometimes they’re given the spotlight on a community call. Badges can capture the contributions made but a personal touch of an email or spotlight in a big gathering goes a long way too. Badges should be considered complimentary and not be seen as a way to replace existing practices that serve a purpose. 
  • dogfooding FTW. If Mozilla intends to make credentialing and recognition systems work more like the web through open badges to help with career and educational opportunities, we better be practicing what we preach. We’ve had conversations with the people team who are starting to express interest in exploring how badges can be a part of our own hiring practices and considerations. 

Summit was crazy busy, exciting, exhausting, rewarding and inspiring all at the same time. I left completely amped thinking about how open badges can cut across many Mozillians needs including contributor and staff recognition, engagement, hiring, recruitment, promoting lifelong learning etc. I’m excited to keep the conversations going and setting up the next steps. Good thing we have another big event, Mozfest!, right around the corner to take all the lessons learned and think about how we can make maximum impact. I’m excited!