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.
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
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.
4. Recipient accepts the badge and sends it to their backpack - badge acceptance flow from email
5. They share their badge on their [Facebook or even LinkedIn hey!] profile.
Sound simple enough? The good news is we have a lot of the pieces in place already to drive this experience. But there’s plenty of room for improvement. We’ve built many of these component pieces while building CSOL, but we want to make the experience better, smoother, faster, and more seamless.
In our initial brainstorm, we had a laundry list of things we wanted to include as part of BadgeKit. But thinking through what we wanted to deliver for beta, we felt like rather than introducing dozens of new half-baked features, we wanted to build something, while seemingly narrow in scope, really really well. So our MVP delivery will be gut checked by the above steps. We’ll make sure we do a kick ass job with enabling a fluid user experience outlined above and keep you all in the community apprised of each step.
The Open Badges team has returned from Mozfest in London and is now going through the process of taking in and digesting all the amazing conversations, brainstorms, hacks that transpired during the festival to extend our work.
One of those insightful conversations took place during the BadgeKit session that Jess Klein and I facilitated with the support of Erin Knight and Chris McAvoy.
[You can read more background information about BadgeKit from the following blog posts written by Jess Klein, Erin Knight and myself.]
We are still at the inception stages of BadgeKit, defining and honing its features, utility and priorities. Things are still in motion at the moment. As we do in typical Mozilla fashion, we wanted to get our thinking out to the community as soon as we could in order to make sure it resonated with key stakeholders and to have a gut check on our assumptions.
The session was designed such that Jess and I, as facilitators, did exactly that; facilitate rather than present or dictate the conversation. Truth be told, the intention was to get as much information from the session participants as possible so that we could incorporate that feedback into the evolving BadgeKit design thinking. We wanted answers to some of the following questions;
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:
A lot of the features we have been aggregating ourselves and have been thinking through were reflected in the post-it notes added by the session participants in this group exercise.
You can see how it compares to our own list here: https://openbadges.etherpad.mozilla.org/toolstack-reqs
One verb that was added by participants was “VALIDATE (ENDORSE)”. Some of the thinking reflected on the Validate board bleed into others. A reasoning behind omitting endorse was that we felt it was a level above the foundational pieces of BadgeKit. BadgeKit is intended to be the absolute basic tools required for badge system design and development. While one can argue “Use” to be a level above as well, we included that because there needs to be an audience of badge reviewers and users, i.e. consumption to meet the demand in order for a basic badge market structure to take hold.
We’re cognizant that this is simply a small sample size of open badges ecosystem stakeholders but it was great to have this validation of our initial thinking come from the community.
Having compared the post-it notes with our own list, next step for us is figuring out what features to implement first. We’ll be reaching out to the community for further feedback in helping us think through the priority of features for implementation.
The BadgeKit session at Mozfest was a great opportunity for us to kickoff the BadgeKit conversation and we’re thrilled to keep that conversation going as we make progress towards development and implementation.
This past summer, the Open Badges team had the great opportunity of introducing digital badges at a citywide scale through the Chicago Summer of Learning (CSOL). We worked in collaboration with the city and on the ground organizations like Hive Chicago and Digital Youth Network with the support of the MacArthur foundation to reach out to more than 100 Chicago-based organizations to create an end-to-end badging system.
As mentioned in my previous blogpost, to support this initiative, we created a set of tools and services to help the 100+ Chicago based organizations to design, define, assess, and issue badges and for participating learners to collect, manage, share and discover badges.
Following a successful summer of learning, we’ve been getting increased interest from other cities and organizations who would like to replicate the badging model initiated in Chicago. We’re thrilled about this interest and would like to facilitate the adoption of other CSOL like initiatives in a scalable way. This would entail us going back to the tools and services we built for CSOL and for the ecosystem, modularizing them, and making them readily implementable for organizations in a light-weight, open-source way.
The idea is to make it as simple as possible for organizations to pick up the specific tool they need for their badge system development and implement it into their environments. Time and time again, we’ve heard that the barrier to entry is still too high. We want to lower that barrier. With that in mind, we started writing down the requirements and goals for what this collection of tools might be.
The key verbs that we kept using over and over again when trying to get crisp about this tool collection were as follows:
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:
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:
We’ll be talking a lot more about the BadgeKit moving forward at Mozfest, during our community calls and on our mailing lists. The community is a critical part of the development of BadgeKit since it is being built precisely to service our community interested in being a part of the open badges ecosystem. We are looking forward to hearing your thoughts on BadgeKit and incorporating your feedback.
In the mean time, here’s a teaser BadgeKit postcard created by our own Jess Klein:
n.b. the url will go live at Mozfest.
About a month ago, the open badges team was approached by the folks at American Institutes for Research (AIR) who in collaboration with the Department of Education had kicked off the Connected Educator initiative in 2012. Last year, they launched their inaugural Connected Educator Month with the goal of
The initiative was a big success with over 170 education organizations, companies and communities involved and over 4 million followers of the #ce12 hashtag by the end of the month.
For their second year, they wanted to include badges as a way to capture the learning and professional development connected educators were undergoing throughout the month and we had the wonderful opportunity to work with the folks at AIR and the Dept of Ed to make badges on CEM a reality.
We had 2 weeks to make this happen and we were able to do so by largely repurposing the tools we built for the Chicago Summer of Learning (CSOL), namely Open Badger, the badge issuing tool, and Aestimia, the badge assessment tool.
CEM’s badge system was smaller in scale but the audience reach was larger, national and distributed.
We first distilled what we need to build in order to make badge issuing and earning possible on the site.
CEM staff would first design and define their badges which landed in 4 different categories, Peer to Peer, Starter Kit, Connected Educator and Participation:
All these experiences were supported through the repurposing of Open Badger and Aestimia.
In Open Badger, we tailored the badge parameters to fit the needs of CEM. We then input all the badges that were defined by the CEM staff. We trained the CEM staff so that they could continue to add participation badges for the events as they came through. We also taught them how to generate claim codes to disseminate to the event organizers once the event was created.
We tailored Aestimia as well. For instance, as CEM does not deal with an under 13 audience, all the notification triggers and details related to dealing with under 13 youth were stripped. CEM simply needed a facile interface for the staff to see the badge applications and nominations and provide approval or not.
We were able to ramp up, gather and define all the requirements for CEM, repurpose the CSOL tool suite to meet those needs, build a microsite that enabled connected educators to view, apply, nominate or claim badges, train CEM staff, do a brief round of QA and get everything out the door within 2 short weeks.
This was an incredibly rewarding and heartening experience. It was great to see the CSOL tools we built be extended to service other organizational needs and it was exciting to know that we were able to do so rapidly. A lot of work remains to get the tools fully modularized to make extensibility more facile but undergoing this project with AIR and the Dept of Ed in a very short period of time was an indicator that we are not too far off. We’re excited to make these tools readily available for those interested in developing a badge issuing and assessing component to their site and we’re hard at work to make this happen. More to come on what’s next on this toolstack. Stay tuned!
Mozilla summit is an opportunity for Mozillians from all across the globe to come together and celebrate the work we do, the contributions we make, the conversations we have and the products we build, to promote the Mozilla manifesto and ethos. This year, summit took place in 3 different cities, Brussels, Toronto and Santa Clara at the same time attracting nearly 700 people in each location.
The Open Badges team was distributed across these 3 different cities, allowing us the opportunity to bring in our own global contributor community to these locations to partake in the big picture discussion of being a Mozillian as well as being an integral part of the growing open badges community.
My colleague Carla Casilli and I were joined by community members Nate Otto working with Dan Hickey at Indiana University on the DML badge system documentation project, Lisa Dawley of Planet Stewards, a DML grantee and Joanna Normoyle of UC Davis, another DML grantee, in the Santa Clara location.
Our goals going into Summit were as follows:
* Educate Mozillians who are not familiar with open badges about our work and its potential
* Get Mozillians excited about how open badges can impact their work and communities
* Get folks activated to create open badges for their own communities for the purpose of engagement, skills recognition or any other purpose
Our plan of attack was to keep ourselves _very_ busy throughout the summit by participating in the world fair, the innovation fair, hosting a couple badges related sessions each day. It was quite the whirlwind!
I feel as though we have certainly accomplished our goals. In addition, the following are some of my observations and thoughts distilled from numerous conversations that I had at Summit.
Summit was crazy busy, exciting, exhausting, rewarding and inspiring all at the same time. I left completely amped thinking about how open badges can cut across many Mozillians needs including contributor and staff recognition, engagement, hiring, recruitment, promoting lifelong learning etc. I’m excited to keep the conversations going and setting up the next steps. Good thing we have another big event, Mozfest!, right around the corner to take all the lessons learned and think about how we can make maximum impact. I’m excited!
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.
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.
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.
I’m reinvigorated coming out of badge camp and look forward to sharing the progress we make on Backpack 1.1.
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:
I’m excited about badge camp and I’m excited about what lies ahead. I’ll be reporting back with more.
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.
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.
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.
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.
Next step for us is to modularize all the code we created for these tools so they can be repurposed to fulfill the needs of the community. Stay tuned for more.
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.