Bananigans!

I’m excited to share with you all the work we’ve been devoting ourselves to in the Badge Alliance Standard Working Group over the past several months. We are releasing the latest Open Badges v1.1 specification today. Yay!!!!

Details here: https://openbadgespec.org

This work has been done in collaboration with the W3C Credential Community Group under the leadership of Nate Otto from Concentric Sky with the support and stewardship of Kerri Lemoie, Chris McAvoy, John Knight, myself, and the larger standards working group and open badges community - so truly a community driven effort with no shortage of contributors and folks who have guided and helped us along the way!

A couple things to note about this release:

This specification is fully backwards compatible with v1.0.

We have adapted the specification to use Linked Data/JSON-LD technology which is increasingly being adopted by the big players such as Google, Yahoo, Yandex and Microsoft. You can read more about that here. This only requires adding three new JSON-LD properties to new badges to make them fully understandable Linked Data: @context, id and type. 

What are the benefits of JSON-LD?

This will enable all 1.1 Open Badges to be indexed and understood better by search engines and directories.

Key stakeholders in the ecosystem such as issuers, earners and badge consumers will benefit from well-understood, well-defined and context-driven metadata.

The biggest feature introduction is the extension specification. As many of you know, open badges metadata fields are clearly defined, and there has long been the ability to add additional data to badges but nothing was ever done with this additional data. Increasingly members in the community have been requesting the ability to add additional fields to satisfy the particular needs of their communities in a way that can be understood across different issuers. The extension specification enables just that. We think this has a couple advantages:

We can keep the open badges foundational metadata itself lean.

We can experiment with additional fields through the extension field first. If we see increasing use of a particular extension, say geolocation extension, we can start a discussion around the utility of bringing it into the foundational specification.

As many of you already know, Open Badges are comprised of 3 objects: Assertion, Badge Class and Issuer. Any of these 3 badge objects may be extended.

We think this is an exciting development for the Open Badges community.

We will be making sure to dedicate some time to this release during our next open badges community call on May 13! Come with your questions!

In the mean time, Nate Otto and Tim Cook have been putting together this FAQ. 

2014 has seen a lot of development in the open badges world. You can see all the cool things we did and worked on here. 

    Reflecting back on the past year allows us an opportunity to take pause and inventory the tremendous amount of work and activity around open badges that occurred and the advances we made to further our goal of reimagining credentialing for the 21st century so that it is interoperable, democratic, open and designed with the learner in mind. 

But it also gets me excited about 2015 and thinking about what I want to work on in the next year; i.e. what’s personally interesting to me, what I get most energized about and where I think we’ll get the most “bang for our buck” in terms of broader adoption. 

  Here’s my list:

  * Adoption and ongoing experimentation of the open badges standard extension

The standard the standard the STANDARD! Are you sick of hearing about the standard yet? I know I know but that’s how important it is! It’s the underpinning of all our work enabling credentials to be all the things we want it to be; interoperable, stackable, portable and easily shareable. We’ve made a lot of advances on the foundational standards framework during Cycle 1 of the Badge Alliance Standard Working Group adapting JSON-LD technology to enable extending open badge metadata such that it is machine readable and indexable. We have shared the 1.1 proposal of the extension framework with the broader community and have put it through the feedback and iteration cycle. Having done that, in 2015 I’m eager for the community to start plugging in. The extension specification is super exciting because it allows badge issuing organizations to append additional metadata fields to any of the badge objects (i.e. badge assertion, badge class, issuer). 

  * Image courtesy of Nate Otto

  Oft-talked about extension field possibilities include location data, endorsement, additional identities, etc. 

What’s really neat about the extension field is that we can experiment in a coordinated way. Say, my organization thinks location data is really important within my community so I decide to define a location extension context and add it to the Badge Class object. After introducing the field, I notice that other organizations are starting to use the context file in which I define my location field with increasing frequency. As more and more organizations start utilizing the location field, I can potentially bring this up with the Standards community and build a case to add the location field to the standard proper. 

  * Making endorsement a reality by using the open badges standard extension field

Once we get organizations playing with the extension field for endorsement, I think things will get interesting. There are still a lot of things around endorsement that needs discussion and unpacking such as the following:

What’s the user experience around an issuer organization endorsing another organization’s badge class?

What’s the user experience around an issuer organization endorsing an earner’s badge instance?

What’s the user experience of a badge consumer who wants to review the endorsements a badge class has received?

What’s the user experience of a badge earner who wants to review the endorsements her particular badge instance has received?

What’s the user experience around an issuer organization or badge earner rejecting an unwanted endorsement?

How are the various endorsements a badge class or badge instance has received displayed so that it is both human and machine readable?

As folks start to pick up and run with the extension field, we can start to pin point with more accuracy the pain points people are experiencing in utilizing the endorsement field for their needs. We can use that data to triage and prioritize how to make the experience smoother for all participating parties to help support endorsement adoption. 

  * Continuing progress on the Directory

Under the leadership of Kerri Lemoie from Achievery, the Directory Working Group has accomplished a lot during Cycle 1. But there’s so much more we can do to. 

I concluded my last blog with some next step suggestions such as listing badge instances in addition to badge classes, additional API end points and exploring ways in which we can lower the barrier of entry for badge issuers and being more articulate about the value proposition of the directory offering. 

Pending usage and uptick of the extension field in 2015, we could also list badges according to location data, or endorsement information, standards alignment, and more. 

In 2015 I want the directory to be at a place where twitter was circa 2008; minimal UI with production ready back end and APIs developers could easily plug into. With badge instance, badge class, endorsement data and the like available with easy access points, I can see an employer-facing application develop on top of the directory that enables hiring managers to extract badge earner listings based on certain badges, endorsements, tags and location, deriving practical value for organizational needs. This paves the way for employer tool development making it easier for employers to plug in and start accepting badges, completing the badge narrative from issuance to consumption for hiring. 

  * Making a kick ass open badges display tool

It’s hard to “get” or wrap your head around what you don’t see and I think herein lies the problem with bridging the gap between early to mainstream adoption of open badges. The pitch is there and more and more people are coming on board, acknowledging the value proposition of an interoperable digital credential but we still don’t have a simple example of a visualized open badge that we can point to that has been verified, earned and displayed with all the meaningful data easily extractable on somewhere as simple as a Facebook timeline or blog. We need a simple display tool that helps folks easily share and display their open badges wherever they want. I think this tool should satisfy several needs currently not met with satisfaction in the ecosystem:

Earner can easily share earned badge on various websites, via email or attachment

Badge reviewer can easily extract and view the badge metadata

Metadata is both human and machine readable

Badge reviewer can verify whether badge earner matches the person claiming the badge

Current display capabilities do exist but they don’t do a good job at fully telling the potential and value of an open badge. A display tool that makes it simplistic and easy to share and review an open badge will go a long way in helping guide a broader audience to adoption. 

==================================================

As open badges continues to gain a foothold in the world of digital credentialing and skills recognition, more and more folks have expressed interest in accessing a list of all the earnable open badges out in the wild. Earners, issuers and employers alike want to see the various badges available to earn based on certain search parameters, find out how to earn them and be directed to the appropriate places to dive deeper and start learning and earning.

One thing that the ecosystem was clearly in need of was a directory service that catalogued and listed all the open badges in the ecosystem with APIs that would enable other organizations to build cool applications on top, such as a badge-based pathway generator, an employer tool that facilitates connections with earners of certain badges, a badge or pathway discovery engine, etc.

In response, the Open Badges Directory Working Group was formed to precisely dedicate itself to prototyping this much-needed directory offering.

*** n.b. The documentation for the Open Badges directory can be found here: http://directory.openbadges.org and examples of it in use can be seen here: http://directory.openbadges.org/examples/browser/#/recent and here: http://achievery.com/discover.

In Cycle 1 of the Working Group, we had to figure out the scope of the project we wanted to tackle. The following were some of the questions we needed to answer to determine the MVP (Minimum Viable Product) feature set.

What are we listing?

What is the barrier to entry for badge issuers?

Where does the directory end and other potential 3rd party services begin?

I’ll share the line of reasoning we went through and where we netted out with each of these questions below.

What are we listing?

This seems like a simple question but actually is a bit more layered. This has to do with the way in which Open Badges technology is set up. The fundamental building block in the badging ecosystem is the assertion. The assertion describes 3 things;

who a badge was awarded to

what that badge represents —>  Badge Class

who issued the badge —> Issuer Organization

The assertion essentially ties all these 3 different pieces together in a unique badge instance that is tied to a specific badge earner.

*** n.b. More information can be found in this wiki guide written by Sue Smith: https://github.com/mozilla/openbadges/wiki/Assertion-Information-for-the-Uninitiated

In that case, what do we list?

Badge Instances that tie a badge class to an earner?

A general Badge Class that explains the badge?

Or do we also include issuer information in the directory too?

While there’s a case to be made for all three options, we decided that the MVP of the badge directory will simply list the Badge Class to start, with Badge Instance and potentially Issuer Organization as subsequent additions. This was because, while listing Badge Classes, depending on method of implementation, has a dependency on the Issuing organization, listing Badge Instances has a dependency on the Earner to make the badges they earn, public. We thought the latter was a bigger initial barrier that the directory would have to overcome as opposed to working with the issuers.

What is the barrier to entry for badge issuers? What does the badge issuing organization need to do in order to be a part of the directory?

This question presented us with a few options as well:

Crawl the open web and look for the open badges assertion file type, automating the listing process for the issuer: While this option eliminates the barrier to entry for issuers, it is a resource intensive and expensive undertaking as the crawler would have to scour millions of IP addresses looking for certain file types. This didn’t seem like the right approach for the initial MVP.

Issuers register their badge classes with the directory and provide the paths to where their badges are stored: This is the least developmentally intensive process but at the same time we are dependent on issuers to come to us and register their badges. The barrier to entry for issuers is put in place and we must provide them with a value proposition to register themselves and their badges.

Issuers only register themselves and a simple crawler would know what domains and IPs to crawl: This is a bit of a hybrid solution of the above 2, utilizing crawling with minimal issuer cooperation. Even so, without a robust value proposition presented to issuers, we still have to reckon with the initial barrier of registration that they must overcome.

We opted for Option 2 in this initial iteration because it provided us with an opportunity to work collaboratively with the issuers in the ecosystem to highlight their badges and proof of concept the directory to a broader audience. Not only that, it saved us from overexpending our technical and development resources which would have been the case if we opted for Option 1.

However, we have seen rather slow responses from issuing organizations who want to register. We are in the process of evaluating the barrier(s) to entry, as well as the value proposition for issuers, in order to figure out next steps.

Where does the directory end and other potential third party services begin?

It’s easy to get excited about a directory offering because of its potential. Say I’m a learner and I want to find out what badges are out there that I can earn that will make me more competitive in the job market. I hear user experience design is a growing field, so I go to the directory, input a few keywords like ‘UX’, ‘user experience’, and ‘UI’ to see the list of badges in the ecosystem related to my search. What next? Does the directory offer me a cool UI with a list of various badge pathways around user experience design I can tackle? Can I save or favorite the badges presented so I can come back to them later?

What level of end-user experience will the directory enable? Are the cool, personalized experiences mentioned above, something an application on top of the directory creates while the directory is simply providing the service of listing open badges with some search and filtering?

Is there an end-user interfacing component to the directory at all or should it simply be a list of APIs for developers?

We all agree the API component of the directory will be critical for encouraging application development, but at the same time, we felt we needed some level of a UI to help folks understand and grasp the fundamental concept behind the directory. As such, what we ended up creating is a simple user interface that lists all badges with basic search and filter capability but nothing beyond that for now.

*** n.b. The API Explorer illustrates how the API works.

==========================

Having released this initial MVP that provides the broader ecosystem with a production beta version, we’re eager to continue development of the directory. Focus areas include the listing of badge instances in addition to badge classes, additional API endpoints, and exploring ways in which we can lower the barrier of entry while clearly articulating the value proposition for badge issuers.

There is still a lot more work left to do to have a full functioning directory product. But the prototype is a strong proof of concept and has taught us a ton. Needless to say, none of this could've been possible without the leadership, dedication and hard work of Kerri Lemoie from Achievery.

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 badgekit.org 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: http://jessicaklein.blogspot.com/2014/03/on-designing-badgekit.html

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.  WE CAN DO THIS!

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. 

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

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. :)

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 badgekit.org in which the issuer should be able to do the following:

Start visually designing a badge. Think any of the following badge design tools: openbadges.me , 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 badgekit.org 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 badgekit.org 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 badgekit.org 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 badgekit.org 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 badgekit.org, 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 badgekit.org, 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 badgekit.org 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 badgekit.org 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 badgekit.org 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. 

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, openbadges.me, 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. 

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:

BUILD:

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)

ASSESS:

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.)

ISSUE:

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

COLLECT:

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?

SHARE:

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

DISCOVER:

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

USE:

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

VALIDATE (ENDORSE):

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 

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:

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.  source: http://connectededucators.org/about-connected-educator-month-2013/

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. 

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 mozillians.org. Many mentioned that they'd like to see open badges integrated into mozillians.org 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. 

Before heading out to badge camp, many of our team members put together reflections on the past months leading up to badge camp and our hopes and dreams moving forward. 

Doug’s: http://dougbelshaw.com/blog/2013/07/21/badge-camp-2013/

Carla’s: https://carlacasilli.wordpress.com/2013/07/20/badge-camp-open-badges-badges/

Chloe’s: http://chloeatplay.tumblr.com/post/55901798994/a-flaneurs-thoughts-on-openbadges-pathways

Emily’s: http://emilygoligoski.com/2013/07/18/how-does-your-garden-grow-considering-open-badges-discovery/ 

Chris’: http://weblog.lonelylion.com/2013/07/16/badgecamp-13/ 

Mine: http://bananigans.tumblr.com/post/56134788716/badge-camp-here-we-come

Badge camp came and went and it was all I expected and much more. The team got the chance to unwind, debrief, reflect, brainstorm, get our hands dirty with making badges(!) no less, and get inspired and excited again about why we do what we do. 

As well as we work together in a distributed way, it's definitely a treat to be able to sit across with teammates in real time, face to face and discuss matters, react to and riff off one another. 

Such was the case as we broke off into smaller groups to discuss what we wanted to accomplish by Mozfest which will take place October 25 - 27 in London this year. 

The priorities and component pieces of the things we'll be working on from now till end of October is well outlined by Erin Knight, our team leader, here: http://worldofe.tumblr.com/post/56788139095/badge-camp

As part of the production backpack team, I thought I'd elaborate a bit further on our goals and what we intend to accomplish. 

What do we mean by production backpack? I mean this http://backpack.openbadges.org/backpack/login. I mean the backpack that is currently being utilized by the tens of thousands of badge earners who have pushed more than 100,000 badges into the open badges ecosystem so far. 

We made a lot of progress from beta to 1.0 release back in March at the DML conference but in the last minute push, we cut some corners and a few features fell by the wayside. In the next couple months we plan to make up for that by tackling the following:

(1) Clean up the codebase

We want to take this time to go back and clean up the code and lay down a more robust foundational framework. This will make it easier to layer on new features in an elegant way, while incurring less technical debt in the process. 

(2) Acceptance tests built into development process

We also want to build in acceptance tests into the development process. Acceptance tests are written in a human readable way that help developers and stakeholders like product managers align expectations of how the product should behave. 

You can read more about acceptance tests here and here.

With so many moving pieces in developing a product, documentation of agreed upon features and behaviors seems like an obvious thing to do. We intend to be more rigorous about capturing these in the form of acceptance tests moving forward. 

(3) Improving Backpack User Experience

We've made some user experience enhancements during the 1.0 release but admittedly in the last minute dash towards release, many of the design sketches created by our Creative Lead, Jess Klein were left on the editing floor. We want to pick those pieces back up, do some user testing on high fidelity wireframes with our community and make the experience more intuitive. 

From now until Mozfest, we'll be focusing on the login / sign up workflow, the issuer API modal badge push workflow as well as the existing backpack collections experience. 

We'll be reaching out to the community soliciting feedback and input. 

The Open Badges team is headed to the beautiful state of Maine for a team gathering we're calling badge camp. We've been keeping extremely busy since the beginning of the year, first with Open Badges v1.0 launch at the DML competition in March and then with the Chicago Summer of Learning release in June. We've been sprinting a marathon for 7 months and it's time to pause, recharge our batteries, reflect on our journey and start to get excited about what lies ahead. 

I'm excited to start working on a couple things. 

1. Empowering the Learner; the learner as the true driver of their lifelong learning

While the intention of the Open Badges Infrastructure was built with the learner at the center, many of the existing interactions are issuer dependent. A learner must be issued a badge by an issuer in order to capture their learning. But how would a learner who would like to capture prior learning in a badge do so? They'd have to find issuers that provide assessments on prior learning or go through the process of learning through an issuer all over again. 

How can we truly empower the learner to drive their prior, ongoing and future learning without such a heavy dependency on issuers to put a stamp of approval on it? Is there a way for the learner to be empowered to drive this experience and for us to put verification mechanisms in place such that those reviewing those learner-driven badges feel confident about the skills claimed in them? Keeping in mind, the predominant job application mechanism to date is a self-reported resume, I think we can do better such that learners can capture and signal their skills more effectively and employers can better comprehend and connect those very skills to their workforce needs. 

2. Making display AWESOME; really living up to the information-rich possibility of open badges

Badge display is something that I've been really eager to focus some energy on. Open badges are exciting because they are information rich by carrying the pieces of metadata defined in our specification. However, displaying that information in a way that is contextual, easy and intuitive for those that need to review that very information is still very much a work in progress. 

We need to define badge display best practices such that one can start to expect consistently informative information no matter where open badges are displayed. At this moment in time, badge display experiences in the wild are pretty inconsistent. We need to provide guidance on what an open badge display would look like. A good first step in this direction is by fulfilling our promise to have an open badges Facebook integration in place soon. 

Many of our team members have started putting together blog posts looking ahead to what's next as well. 

Here's some of them:

Doug's: http://dougbelshaw.com/blog/2013/07/21/badge-camp-2013/

Carla's: https://carlacasilli.wordpress.com/2013/07/20/badge-camp-open-badges-badges/

Chloe's: http://chloeatplay.tumblr.com/post/55901798994/a-flaneurs-thoughts-on-openbadges-pathways

Emily's: http://emilygoligoski.com/2013/07/18/how-does-your-garden-grow-considering-open-badges-discovery/ 

Chris': http://weblog.lonelylion.com/2013/07/16/badgecamp-13/ 

Following the launch of Open Badges v1.0 back in March 14 at the Digital Media and Learning conference, the Open Badges team has been heads down working with the city of Chicago, the MacArthur Foundation, Hive Chicago, Digital Youth Network among others on the Chicago Summer of Learning initiative. 

The Chicago Summer of Learning brings together youth-serving organizations, museums, cultural institutions, philanthropists within Chicago to support young people in exploring the themes of Science, Technology, Engineering, Art and Mathematics (STEAM). All the learning that is undertaken by youth is captured and recognized in the form of badges that are used to communicate back to schools and employers in the fall. 

This city-wide initiative has provided an opportunity for the Open Badges team to test new features and functionalities that we hope to loop into the core product in coming months. The following is a list and explanation of these new features and functionalities that we are excited to build out further and bring to the wider Open Badges community. 

1. A backpack that supports children under 13

The reference implementation of an Open Badges backpack that we have built, i.e. the Mozilla Backpack, currently does not support youth under 13 in order to meet the requirements of the Children's Online Privacy and Protection Act. 

We have been fully aware that a Backpack that is unable to support under 13 youth is limiting. We knew there was no question about us having to support youth under 13 as part of the Chicago Summer of Learning initiative. 

This meant we would need to track user birth dates and provide 2 different experiences accordingly. 

The over 13 youth backpack would act just like the Mozilla Backpack, enabling share capability and user volition without parental oversight. 

Meanwhile the under 13 youth backpack would have no integration with existing social media thereby lacking share functionality. However it would have a robust parental notification system to ensure parents and guardians are able to maintain clear oversight over their children's activities. 

We have created the date of birth gate check which takes the learner down 2 different paths within the Chicago Summer of Learning experience, depending on whether they are under 13 or not, which is something we hope to loop back into the core Open Badges product offering. 

2. Open Badger https://badge.chicagosummeroflearning.org/ 

Open Badger is an open source badge issuing tool we created last year to help Mozilla webmaker create and issue badges. Chicago has since become the 2nd client to use this badge issuing software. 

This provided an opportunity for us to scale up the features of Open Badger as Chicago badges needed to be created and issued at an entirely different scale. For instance, webmaker was simply one "organization" client, meanwhile we had nearly 100 unique Chicago organizations providing a variety of programs that each issued badges. While there were a total of 12 webmaker badges, there were a total of 442 unique Chicago Summer of Learning badges. 

While creating and issuing 12 webmaker badges may have been feasible manually, that was an untenable solution for CSOL badge creation and issuance. 

We developed a data entry admin panel to input organization detail, program detail and badge detail and created the necessary among these 3 pieces of information. 

We developed a badge issuing admin panel that allows instructors of organizations to

* access and issue the appropriate badge to a deserving learner via email

* generate simple claim codes

* create claim code badges that are printable that can be easily distributed at live, in-person events

We created badge recommendation logic such that when a learner earned a particular badge, the external Chicago Summer of Learning site could call that API end point to generate learner tailored recommendations on site. 

These are just several of the core pieces that were developed as part of Open Badger for CSOL. We're excited to see how these pieces can be of used to benefit the larger open badges community. 

3. Aestimia https://assess.chicagosummeroflearning.org/ 

Aestimia is a badge assessment tool. In Chicago Summer of Learning, it was important to ensure there were plenty of online, self-paced learning activities for youth. In order for the learner to earn any of these online, self-paced badges, they would have to go through the activity and apply for the badge by submitting evidence and reflections. 

Once a badge was submitted, it would go into a badge application queue that is accessible by selected mentors. The badge application review process is enabled through Aestimia. 

Mentors log on to the assessment tool and see a list of badge applications that are in need of review. Mentors open up each badge application one by one, review the evidence and reflections submitted by the learner against a pre-determined rubric and provide feedback. Depending on whether the earner who submitted the application is < 13 or not, mentor's feedback is a pre-canned message selected from a drop down menu or free form text. 

Additional capabilities are being built out to help mentors understand how many badge applications are in need of review and to set goals. 

4. Badge studio http://badgestudio.chicagosummeroflearning.org/ 

Badge studio is a web-based tool that helps anyone to easily create a badge design. This is something that's been in high demand in the community as many organizations don't have a visual designer on staff. For CSOL, streamlining badge design was critical due to the high volume of badges that needed to be designed with minimal resources. 

It was agreed that badges that were part of the Chicago Summer of Learning would have a cohesive look and feel. As such, the badge design tool is intended to be templatized. 

However we can easily genericize any Chicago branding and extend the services to be more inclusive beyond the Chicago initiative. 

===========================================================

I'm omitting a lot of details up top including all the backend work that went into developing these additional tools and services. There was a lot of heavy lifting that went into building these out that do not end up presenting themselves visually to the end user.