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
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.
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.
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.
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!
What this means for you:
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.
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:
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;
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:
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.
On the Open Badges front, we have 2 themed sessions planned;
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:
Tech Capability (related to resource availability)
It’s been a useful practice during conversations to do some color coding to these key barriers:
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.
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:
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.
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 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/
There were several themes that came up over and over again during the course the outreach conversations. Most common ones were as follows:
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.