Bananigans!

The Open Badges team is in the midst of sprinting towards our v1.0 deliverables as part of our Q1 roadmap so we’ve all been up to our eyeballs focused on that. You can read about the specific features scoped for v1.0 here: http://bananigans.tumblr.com/post/37714817884/openbadges-product-sprint-winter2012

But I thought it might be worthwhile to take a moment to see the work we’re doing in context. In this blogpost, we’ll review Q4 2012 and the things that we’ve done last quarter that have brought us to this point.

On the Q4, 2012 roadmap we had planned to deliver on the following:

HOW DID WE DO?

A. Open Badge Infrastructure (OBI)

Following the beta launch of the OBI in early Q2 of 2012, we’ve been diligently gathering community feedback on existing features as well as feature requests in order to define the scope of v1.0 fully productized OBI. Based on feedback received, and our commitment to the Digital Media Learning competition, we came up with the following issues list to be addressed as part of v1.0 and started development accordingly. (Again, more detailed explanation can be found here: http://bananigans.tumblr.com/post/37714817884/openbadges-product-sprint-winter2012)

• COPPA stance

• Extending spec - a. standards alignment

• Extending spec - b. tags

• 508 compliance

• Signed badges

• Backpack Connect - Autopush

• Revocation of badges

• Badge expiration

B. Adoption

1. Tools:

OpenBadger development and beta release: Open Badger is a badge authoring and issuing tool that makes it possible for badge issuers to quickly and easily create and define a badge and then issue that badge to a badge recipient. Because Open Badger is already integrated with the OBI, the badge is defined such that it aligns with the Open Badge metadata specification and allows earners to push their badges into their Backpack. 

We released the beta version of Open Badger in November 2012 with Webmaker badges as its first client. The Mozilla Webmaker badges were launched in time for the Mozilla Festival and were created and issued utilizing the Open Badger badge authoring and issuing tool.  

Displayer widgets (Facebook, Wordpress)

It’s vital to the success of Open Badges that earners be able to showcase their badges to the world by being able to display them across the Web. Currently we have a displayer API that display sites such as social networking sites, content publishing sites, and various community sites can utilize in order to integrate services. However, we have decided to directly target major display sites Facebook and Wordpress and move forward with doing the integration work ourselves to help promote our displayer API and push forward with ecosystem development. 

• Wordpress display: We’ve released a beta version of Wordpress display that enables easy display of badges earned on personal Wordpress sites.

• Facebook display: We’ve released an alpha version of the Facebook display widget and continue to work on building an elegant user experience around this. 

2. Recruitment:

Identify key partners to onboard and develop strategy map for recruitment

Securing strategic partnerships with high-profile organizations that fill key gaps in the existing badge ecosystem is an important objective for 2013. Our goal is that by identifying and advising these organizations, we are able to influence strong proofs-of-concept that lend weight and legitmacy to the concept and implementation of badges. As such, a particular emphasis has been to think about employability through badges when reaching out to strategic partners. We’ve done active outreach with MOOCs, large corporate partners, key cities in the US and display sites. 

3. Support:

Scope and model a distributed support system

We know we need to extend our capacity to deliver direct, customized, project-specific technical and design support to partner organizations engaged in launching badge systems. This includes design and implementation of a distributed support system and ongoing development and iteration of support materials. 

The model of the distributed support system has been piloted through the support provisioned to the winners of the DML competition as well as the wider Open Badges community. 

C. Community

Hire community manager

We’ve hired a Community Manager who has ramped up our social media presence, increased attendance to the community calls, extended existing community calls to include special interest calls promoting community members to network and collaborate with one another, created a new badges blog, and started a repository of badge knowledge in just 3 months. 

D. Foundational Frameworks and Practices

Draft of the validation paper

As more badge systems are built and put into use, increasingly reviewers of badges are keen to determine value assignments for each badge. This process of validation will be central to the adoption of badges by high profile organizations and employers. While neither Mozilla nor the OBI will be the arbiter of badge value, it will be important for organizations to be able to identify which badges are trustworthy without prejudicing the emergence of new badges or new partners in the ecosystem. 

As such, we’ve produced an early draft of a white paper on badge validation that explores this topic in depth and proposes a framework for building a distributed validation system for badges. You can read more about this paper on the blogpost written by our Sr. Director of Learning, Erin Knight: http://erinknight.com/post/42841860849/an-open-distributed-system-for-badge-validation

Initial meetings with policy reps

Engaging with policy makers is key to having Open Badges recognized as valid and legitimate by formal learning institutions and other relying parties. It will also significantly boost the rate of badge adoption. The idea is to work with MacArthur and interested parties to establish any required legal precedents around issuing, display and the use/consumption of badges. With that in mind, we’ve done initial outreach to policy representatives to kick off the conversation. 

E. Mozilla Badge System

Mozilla has designed, built and deployed an end-to-end badge system across Mozilla’s Webmaker program which was released with much fanfare in November 2012, in time for the Mozilla Festival in London. 

WHAT DOES THIS MEAN???

We delivered on all that we set out to last quarter! That is a BIG DEAL. It’s easy to forget about past accomplishments when new deadlines and new milestones loom ahead but I think it’s important to take a moment to appreciate the hard work that was put into past goals and achieving them. 

Looking ahead, we’re excited for all the development work happening around v1.0 and will have more to share soon. 

On the weekend of January 18, Open Badges team members, Brian Brennan, Emily Goligoski and I participated in a Hackathon event for an Open Source project-based, collaborative university curriculum program hosted by Stanford Computer Science Professor, Jay Borenstein and Facebook. 

The hackathon was a kickoff event for a semester long mentorship program between shepherds of various open source projects like Open Badges, ReviewBoard, Freeseer, MongoDB, CouchDB etc and Computer Science college students across the world. This Stanford and industry sponsored, cross-university program is intending to give students in computing exposure to real projects and allowing them to apply their classroom learnings to live products with actual users. 

Open Badges was selected by 9 university students from Tampere University of Technology in Finland (2), Imperial College London (2), National University of Singapore (2) and Cornell (3). 7 students wanted to focus on code contributing and 2, the ones from Tampere University wanted to focus on UX. Throughout the weekend, Brian worked with the 7 while Emily and I worked with the UX students. 

The weekend provided a great opportunity to gauge the students interests, backgrounds, level of experience to figure out a plan forward for the semester. It’s important to us in the Open Badges team as mentors that we ensure the students feel like they are a part of the team and that they are making contributions to our product that they can point to and be proud of. 

Updates on the team’s work will be documented on the program’s Fb page which you can follow along here: http://www.facebook.com/groups/245840398877320/

We’re excited to work with these talented students in the months to come and will make sure to share along the way. 

n.b. Another long overdue blog post but better late than never!

The Open Badges team got together last week in beautiful Portland, ME to discuss what’s next for development. 

For the past couple of months we’ve been actively reaching out to the community and gathering feedback on a variety of issues from those related to COPPA to authentication with Persona to revocation of badges to pie badges etc. 

[You can find critical feedback gathered on these etherpads: https://openbadges.etherpad.mozilla.org/openbadges-community-feedback and https://openbadges.etherpad.mozilla.org/dml-workshop-features]

After gathering all the notes on feature requests and issues raised, we took a look at the list and started to prioritize. An important deliverable deadline for us is the ongoing DML4 competition and the upcoming DML conference scheduled for mid March 2013. Since March of this year, 2012, we’ve been working closely with all of the 30 DML funded grantee teams to ensure they understand the Open Badge Infrastructure and have what they need to integrate their badges with our open standard and API. At the upcoming 2013 DML conference they will have the opportunity to show their work and progress and we want to ensure their badges integrate well with our technical infrastructure and that our system can accommodate for the varying needs of the 30 grantee teams. 

Working with the 30 DML grantee teams has been a great testing ground of issuer use cases. So far, almost all issues raised by the larger community has most often been raised by the pool of DML grantee teams as well. 

We took both the feedback of the larger community as well as that of the DML grantee teams and have come up with the following issues list for release in Q1 2013:

I. COPPA

COPPA, as many of you well know, has been very front of mind for us. We’ve talked to many of you who work with children under 13 to gather information, we’ve spent countless billable hours of our legal counsels’ time diving into this into greater detail and studied many existing COPPA compliant technical implementations. 

Questions around children’s online identities are complicated ones that have yet to be resolved. At this moment in time, no children online identity providers handle identity and data protection while allowing sharing capability in an open Internet environment. 

Not to mention, COPPA is a moving target. As we dove deeper into understanding the complexities around youth and online identities, we realized that this is something we cannot undertake alone. We need to work with the broader community of stakeholders, educators, identity providers and policymakers towards a collective solution. 

As such we will be developing a cohesive stance towards COPPA which we will share out with the community soon. More to come here. 

II. Extending spec - a. standards alignment

Many members of the community requested an additional optional metadata field that would indicate standards alignment of that badge. For instance if the learning content behind a Buzzmath badge that was earned reflected how the earner learned how to “Rewrite expressions involving radicals and rational exponents using the properties of exponents”, that directly aligns with Common Core Standard, CCSS.Math.Content.HSN-RN.A.2. 

So Buzzmath, would likely link to the Common Core Standard url [n.b. specifics tbd] in this new standards alignment metadata field. 

We think there are opportunities for this field beyond formal standards alignment. Our Sr. Director of Learning, Erin Knight will be writing more about how this field can be relevant to you so again, more to come here as well. 

III. Extending spec - b. tags

As we think about badge organization and badge retrieval/discovery, we start to think about the different pieces of relevant information, i.e. data, that would help enhance this experience. Many of you have brought up the utility of creating a badge categorization or taxonomy of badges. We may choose the option to create a controlled vocabulary or take a folksonomic approach. We will be going with the latter and iterating based on how the community starts to utilize this field. 

IV. 508 Compliance

We take accessibility considerations seriously and will comply with 508. 

V. Fb Display integration

We will have Facebook display integration by spring 2013. In actuality, a big part of this is wrapping a great user experience around how a badge earner pushes their badges out to Facebook and how that can be distinguishable from a simple status update. 

We’ll share out interim releases with the community for feedback. 

VI. Signed badges

Signed badges will be a part of the Q1 2013 release schedule. As Brian mentions in the github issue, technical implementation is actually not the most challenging part. We really need to ensure issuers who are interested in signing their badges know where to start and how to go about making badges with signed assertions. The related documentation and tools development is key. We’d love for those especially keen on signed badges to provide feedback and support for this development. 

VII. Backpack Connect - Autopush (badges by approved issuers automatically pushed)

Currently a badge earner must deliberately push every badge earned into their backpack (batch approval does exist today, however) which could be a clunky user experience. With auto-push, earner-approved issuers will be able to automatically push earned badges into the earner’s backpack.

VIII. Revocation of badges

When an issuer mistakenly issues the wrong badge to an earner, the method of revocation is that they go ahead and delete the assertion file. From the earner’s standpoint, that badge still exists in the backpack but if they want to display it out, the assertion file will not exist and it will be evident that the badge is not valid if anyone bothers to check. However problematic to all of this is that, a revoked badge is not obvious. There’s needs to be a better user experience around badge revocation. We will be including this in our next release. 

IX. Badge expiration

Similar to badge revocation, the treatment and user experience around badge expiration is not clearly defined yet. We will be building out the new UX around badge expiration as well. 

All these issues are trackable on our github issue tracker which you can find here. 

We’ll keep you all in the loop with updates as many of these items require followup conversations and separate blogposts so stay tuned for more!

This blog post is a couple months overdue but I had some time on the plane en route to Mozfest (a month ago!) so I figured, better late than never. :)

On Thursday, September 27, 2012, the Gates Foundation hosted a hackathon at the Facebook campus promoting college readiness called HackEd. The idea was to gather like-minded folks passionate about improving education, put them in a room and make them build apps to help students be better prepared for college and life.

*** photo courtesy of Dave Lester

In addition to the hackathon, the event was intended to kick off the College Knowledge Challenge, a college readiness app development challenge in which folks interested in changing the landscape of education can compete for funds totaling $2.5M. 

One day is an awfully short period of time to put a functioning app together but we did our best with the team we formed. 

Our team was comprised of Charles Wright, Portfolio Manger for College Ready, from Gates, Lia who worked at a startup and was an alum of the Stanford dschool, Dave Lester, a developer, who we’ve actually worked with at Open Badges, Catalina Ruiz-Healy who had a startup called GradGuru, designed to help community college students navigate campus life, and me. 

Our team member, Catalina Ruiz-Healy had a ton of domain knowledge in the area of community colleges; who tends to attend community colleges, what’s the demographic breakdown, what they tend to major, how many are able to transfer to a four year college, etc, so our group came together around the idea of helping community college students succeed. 

We sketched out some ideas and decided to create a mobile app based on Catalina’s GradGuru model and add a badging component and social interaction. 

*** photo courtesy of Dave Lester

Key to the success of many community college students is as much about knowing deadlines for class enrollment, scholarship opportunities, govt grant and financial aid applications etc as it is about excelling in classes. 

*** photo courtesy of Dave Lester

Mindful of the time constraint, we decided to build a very simplistic and narrow proof of concept model that followed this workflow; 

• When Stacy fills out her FAFSA application, she is granted a badge;
• This badge shows up on her profile within this community college network so that her friends can see;
• When her friends see that she has been granted a badge for filling out her FAFSA application, this triggers reactions from her friends who may realize that they should start filing out their applications as well. 

The badge becomes a way of sharing information around key deadlines and important deliverables. FAFSA was just one example that we used to delineate this point. 

After several hours of hairied freneticism, we were able to put a small interactive prototype together to showcase during the pitchfest. 

The pitchfest was rapid-fire and impressive. I was delighted to see badges being part of several different projects. <Yay!> I’m eager to followup with some of these folks in case they might be interested to develop the idea out further. 

The hackathon event was truly exciting and a great opportunity to connect with many folks who are passionate about improving chances of success among students from underserved or disadvantaged backgrounds and enhancing education access. 

I look forward to hearing some of these projects fleshing out and to see the outcomes of the College Knowledge Challenge. 

I have survived my first Mozfest.

It was exciting, energizing and exhausting. Having hosted 3 sessions throughout the 2 days; Designing Open Badges in the Wild with colleagues Doug Belshaw and Emily Goligoski, and 2 different office hours/sessions called, Make Open Badges Better with Emily, and played wingwoman for the Hackable Games floor one afternoon, I want to jot down some reflections:

• Be well prepared: For all the sessions I took part in, my teammates and I erred on the side of over-preparing. For Designing Open Badges in the Wild, we contacted nearly a dozen participants ahead of time to first ensure their attendance, but also to make sure we understood what they wanted to learn and discuss in greater detail. 
• This helped us in the following areas: 
• We had a base level idea of who and how many participants to expect,
• We had an idea of the major themes they wanted to discuss,
• We had an idea of the range in the level of experience and familiarity with Open Badges,
• We had an idea of who should connect with whom to continue the discussion beyond the session prepared.

• Empower the participants, share real examples: Prior to the session, we reached out to several UK-based badge issuers that were ahead of their peers in the sense that they had gone through the process of designing a badge system and associated assessment thinking, and asked if they’d be willing to share their process with their peers. Many folks are already quite familiar with Open or digital Badges and its intended purpose. In fact, there are many issuers already integrated with the Open Badges standard and infrastructure who have learned lessons along the way and are eager to share. By empowering members of the community, we give a voice and face to those that are doing the actual work i.e. the practitioners, enabling opportunities for peer connection and collaboration. During our session, Cliff Manning and Lucy Neale of MakeWaves shared their work with S2R badges as well as Zoe Ross who has empowered her students to design badges of their own. The differing approach to badge system design provided quite a nice contrast and a bit of food for thought. 

• Break out into smaller groups: While we had a decent idea of who and how many to expect at the session, the reality is, you never really know how it’s going to turn out. Honestly, we thought we’d have about 20 people and were delighted with the dozens more that showed up. Limited space was a bit of an issue but we made it work. With a large number of people, it’s easy to stop paying attention, not even deliberately, but more likely due to logistical matters like difficulty hearing, etc. After the initial icebreaker and introductions, we quickly broke the session out into smaller teams so that participants got to know one another better, be more actively engaged, and have a voice among a smaller pool of people. 

• Icebreakers; have a couple in your back pocket: Speaking of icebreakers, we had several different ones lined up. While they can be predictable and hackneyed, they can also be a lot of fun. The couple icebreakers we did were as follows:
• Draw each other’s portrait: We broke the participants off into pairs, had them introduce each other and answer 4 basic questions; 1) name, 2) affiliation 3) what do they want to learn more about wrt badges and 4) favorite dessert. After that, we had them draw each other on a post-it note to the best of their artistic capability and stick it up on a communal wall. This provided a nice recess wall that participants could go to casually and actually get a few chuckles guessing who the portrait was intending to depict. 

• Hack the robot dance: After the conclusion of the first hour, we wanted to provide session participants an opportunity to stretch, stand up and perhaps do something physical. We had participants break out into groups of 5 - 7. From their, we taught them how to hack the robot dance; first person to start does a robot dance move, the next person does that exact move and adds his own move to it, until you go around the full circle. 

• Connect People, get out of the way: Each time I’ve done sessions of these nature, I come away with my mind blown with all the knowledge and experience already embedded within the session participants. I think the best thing we can do as session moderators/facilitators, is ignite the conversation and get out of the way such that participants can connect and share their expertise amongst one another. 

• Meet people: Doing our job, that is making sure our sessions run smoothly, facilitating, going to sessions, helping colleagues, all of this is important. However, it is crucial at events like these to meet those that we don’t get the chance to meet in person on a regular basis. Meeting, talking, networking, connecting with people are essential at such events. Being able to put a face, voice, and character behind a name and email and personalizing one another, is what these events are all about. 

• Be flexible: No matter how much planning and preparation you do, something will go wrong. Expected printouts will not be printed, material will be missing, schedules will change last minute. But! some flexibility, thinking on your toes, and ingenuity will go a long way. 

• Be a team player: We are a team, all of Mozilla and all of the participants at the event. If someone needs a helping hand, we should provide it. I had a wonderful time helping out where I could in small ways, at the Hackable Games floor, run by Chloe Varelidi and I know I’m indebted to those that helped me and our Open Badges program throughout the festival as well. 

As much work as Mozfest was, I can’t wait to do it all over again next year. :)

The Open Badges team, with the rest our colleagues at Mozilla Foundation, are headed to London this week for our annual Mozilla Festival. Some of you may recall that it was at this very annual festival, 2 years ago in 2010 under the banner, “Learning, Freedom and the Web” that Open Badges was born.

The theme for this year’s event is “Making, Freedom and the Web” and Michelle Thorne, our Global Event Strategist, with the help of many, many people, has put together an action-packed weekend all to underline our overarching ethos of “less yack, more hack”; Let’s make, remix, hack and tweak and see what we learn in the process. Let’s earn badges to represent the learning we’ve done and the skills we’ve accomplished. 

We’ll be getting our hands dirty this weekend, introducing all the latest from webmaker (more on that from Erin) and all its tools and projects and a slew of others. 

On the Open Badges front, we have 2 themed sessions planned; 

• Designing Open Badges in the Wild: A fireside chat moderated by our team members Doug Belshaw, Emily Goligoski and me
• Make Open Badges Better I and II at the Webmaker Bar: Playtest sessions on both Saturday and Sunday led by our team members Emily Goligoski, Mike Larsson and me

Designing Open Badges in the Wild

We’ve been talking about Open Badges at a higher introductory level for quite some time now and we felt it was time to take the conversation further during this year’s event. There is tremendous work around Badges happening in the UK and Europe, with Doug Belshaw, our Skills and Badges lead, guiding and advancing the conversation. 

Leaning on the partner relations cultivated through Doug and fellow colleague of ours, John Bevan, we thought we should take advantage of the locality of the event in London and really highlight the work taking place in and around the UK. We invited several of these partners to join us in the conversation, showcase their work around badges and share lessons learned. But we wanted to stay true to the Mozilla maker motto by allowing a forum for active making. 

Thus we’ve created a 2 hr session broken into 2 halves in which participants can go in and out. 

The first hour will allow for session participants to get introduced and talk about their various badging interests and efforts. From there we intend to capture key areas of interest and allow those conversations to really flourish and build, much in an unconference-y fashion. 

The second hour, we will regroup from our discussion from the earlier hour. If participants would like to continue with their breakout conversations, we will encourage it. If folks would like to switch gears, we’ve prepared a mini badge design activity that will encourage participants to think through the various components of designing a badge within a larger badge system and how it would play within the Open Badge ecosystem. 

We are excited about the session and look forward to connections being made among the participants, lessons being shared, conversations being advanced and ideas being generated all to advance our work in Open Badges. 

Make Open Badges Better I and II at the Webmaker Bar

With Mike Larsson at the helm, our development team has been working hard at introducing a slew of user experience enhancements in the Backpack. The list of updates that we’ve been working towards with Mozfest in mind can be found in our github. 

Unfortunately, we’ve encountered some snags along the way and the release of the neatly packaged Backpack UX improvements looks like it’ll be delayed. Not to be discouraged, we are moving forward with the playtest session. Rather than testing out specific new UX releases, we’ will be utilizing paper prototypes of the original designs to frame the conversation and get participant feedback on various aspects of the backpack from groups, share, tagging, and privacy settings etc. 

We intend for these 2 playtest sessions to be casual but are aiming to engage as many users as possible throughout the festival; meaning, while we have 2 formally scheduled playtest sessions, we’ll be doing a lot of informal playtesting in the form of conversational information gathering about the backpack and the various features we’ve developed or intend to develop. The last count I heard was that we were anticipating over 1000 attendees at the festival. We’d love to reach as many of these folks as possible to share what we’re building, gather feedback and improve the overall experience user’s have when interacting with Open Badges. 

If you’re headed to Mozilla Festival, we hope you get the chance to come join us during one of our sessions. If you’re unable to, we’ll make sure to report back during our weekly community call!

The Mozilla Open Badge Infrastructure (OBI) is a relatively new product. At the Mozfest in Barcelona back in November of 2010, Open Badges was merely in its napkin sketch stages. Since then we created the conceptual framework (Q1 2011), defined requirements around what we needed to build (Q2 2011), released alpha of the Mozilla Open Badge Infrastructure with a set of early partners (Q3 2011) and earlier this year the beta version (Q2 2012).

While we continue to build out the OBI, ensuring its stability and ability to scale, in parallel we are working hard to get more badge issuers to integrate with the OBI, more displayers to start pulling public badges out of backpacks onto their display site, and more employers and colleges to start thinking about accepting badges as part of applicant evaluation. We are working hard to start thinking through how we can achieve wider badges adoption and the development and growth of a larger badges ecosystem. 

Critical to that thinking is understanding the perspectives of the partners we are trying to onboard. What are their respective barriers, external and internal, to entry? What keeps them from integrating with the OBI and is there anything we can do on our side to help lower those barriers?

From various conversations, I found that barriers frequently distill down to 4 key elements:

Organizational buy-in: 

• Does the organization buy in to what we are trying to do? 
• Does the organization feel comfortable that the Open Badge Infrastructure was built in an open source way? 
• Is the organization being cautious and simply waiting for Open Badges to hit critical mass before getting onboard?
• Does integration with the OBI help/hinder organizations from meeting their bottom line?

Resource availability

• Does the organization have resources to be able to build out a badge system if they don’t have one already?
• Does the organization have resources to be able to conform their badges to the metadata specification we defined?
• Does the organization have resources available to parse through our API to integrate their system?

Tech Capability (related to resource availability)

• Does the organization have the technical chops to architect their badge system and integrate with the OBI?
• Does the organization operate under an entrenched legacy system that requires technical heavy lifting in order to integrate with the OBI?

Organizational pace

• Is the organization highly bureaucratic requiring multiple layers of approval for decisions to be made?
• Is the organization nimble and lean in which decisions are made deliberately but quickly?

It’s been a useful practice during conversations to do some color coding to these key barriers:

• GREEN  : low tension
• YELLOW  : medium tension
• RED  : high tension

We have talked to organizations that are completely on-board with the mission and goals of Open Badges and the OBI (Organizational Buy-in ) with few resources to start architecting a badge system that is OBI compliant (Resource availability and Tech capability ) that work in a large organization with high level of bureaucracy (Organizational pace ). 

We have also talked to organizations that are still waiting on other well-known organizations to come on board before committing (Organizational Buy-in ) with flexible ability to ramp up resources if needed (Resource availability ), strong technical resources on staff that can easily parse through our APIs (Tech Capability ), operating under a small and lean management with little bureaucracy (Organizational pace ). 

The intent of Open Badger, to be released later this year, is to help lower the barrier for those that lack resources and technical chops by abstracting the technical requirements of integration such as setting up a server, conforming to the metadata specification and parsing through the API. We continue to work towards getting organizational buy-in through education and advocacy, improving our tools, and getting more and more folks on board (in an attempt to get to the tipping point of the domino effect). But there is really little we can do with regards to the pace at which an organization operates. 

That taken into account, we will continue to think through the existing tensions organizations encounter in order to come on board and do what we can to minimize those. We are a work in progress and open to feedback. Please let us know what you feel might be missing from the above mentioned barriers to entry and how we can be more empathetic to the needs of those organizations we want to bring on board. 

The DML competition and conference came and went earlier this year at the end of February/early March in San Francisco, CA.

For those unfamiliar with the DML competition, here’s a brief recap: Having built out the Open Badge Infrastructure (OBI), the plumbing to support a larger open badges ecosystem, we at Mozilla along with the MacArthur foundation and HASTAC felt it would be important to seed the ecosystem with high quality badges to kickstart the badges movement. Thereby, we made an open call for badge system submissions about a year ago where we had over 600 entries which got whittled down to 90 finalists who came to San Francisco earlier this year to pitch their badge systems to a panel of judges. Of those 90, 30 were selected as funded winners who now have a year to build out their badge systems that will integrate with the OBI.

More information on the DML competition can be found here. 

For reflections after the DML competition, definitely check out the blog post written by our Sr. Director of Learning, Erin Knight which can be found here.

5 months later, it’s worth taking a gut check on where we are and what lies ahead.

Now that the emotional highs and lows of the competition and conference are behind us and the dust has settled, the winning grantee teams are getting to work on building out their badge systems or badge platforms and we at Mozilla in conjunction with HASTAC and MacArthur are ensuring that the teams have the support and guidance they need to successfully do so.

As part of this effort, Sheryl Grant from HASTAC and I conducted a round of outreach conversations with each of the winning grantee teams. Coordination with 30 winning grantee teams, frequently comprised of multiple team members, traversing different timezones was no trivial task, but it was well worth our time and energy.

Similar to how I put together a partner breakdown report a few weeks back, I thought it’d be a worth while exercise to examine our own grantee projects in a similar manner but within the context of the DML competition.

Here are some of our findings from this first wave of outreach conversations:

OBI Familiarity

11 out of the 30 teams have had some contact with the Mozilla Open Badges team and/or have had checked out the available resources out there and thus were somewhat familiar with the integration process. During the course of outreach, Sheryl and I made sure all the grantees knew who to contact (me!) when they were ready to start issuing badges that integrate with the OBI as well as the pointers to the resources readily available for them.

Tech Platforms

The breakdown of the tech platforms utilized by each grantee team is as follows:

With 6 grantee teams, .net is the most used tech platform among the grantee teams, closely followed by drupal. There are still 5 teams that are weighing the different tech platform options and 5 teams that are building their badge system on top of existing badge issuing platforms.

COPPA Compliance

COPPA stands for Children’s Online Privacy Protection Act, in which a “child” is defined as an individual under the age of 13. The details get much trickier but the general idea is that a website operator who collects personal information from children under 13 must seek verifiable consent from a parent or legal guardian. We wanted to know for whom among the grantee teams, COPPA was a concern.

The breakdown falls smack down the middle; 15 teams are concerned about COPPA compliance and 15 teams are not.

The current public beta release of the Mozilla reference implementation of the backpack does not support children under 13. This was a deliberate choice as accommodating for COPPA would have delayed our release rather significantly. We will be creating a parallel backpack with limited sharing capabilities that will be COPPA compliant for the 15 DML grantee teams and their community of under 13 badge earners by early next year.

More information on COPPA can be found here: http://www.coppa.org/

Reoccurring themes

There were several themes that came up over and over again during the course the outreach conversations. Most common ones were as follows:

• Common Core alignment: How to ensure the alignment of badges and its associated content with common core standards. 
• COPPA compliance: How to develop a badge system mindful of protecting children’s online privacy and complying with the law. 
• Wider badges adoption: After these badge systems are developed, how to ensure these badges scale and reach a wider audience? 
• Assessment thinking: How to ensure badges have well designed assessment rubrics behind them. 
• Employer consumption of badges: Related to wider badges adoption, how to ensure badges are consumed by important stakeholders like employers and college admissions offices to assess potential candidates? 
• Working within existing entrenched systems: While badge systems are emerging, they are operating within existing, established models of pedagogy and assessment. How to make badge systems work with the system rather than against it? 
• Badge validation: How to ensure the badge system is valuable and represents real learning in the eyes of those who will likely consume the badges such as employers.
• Designing a badge system: How to design a meaningful badge system that captures the right granularity of badges, that encompasses an assessment model that resonates with the community of learners, that will generate currency in the larger badges ecosystem. 

All of these are HUGE themes in and of themselves that deserve a lot of attention and careful thinking around them. And none of them are discreet or isolated but relate to, depend on or validate one another.

Following up on these outreach conversations, in September we are holding a face-to-face workshop for the grantees to take place at Duke University in Durham, North Carolina. We hope to learn more on the progress made by the grantees and how we can collectively work through and tackle these higher level themes. I’ll have more to share after the workshops.