We’ve talked a ton about BadgeKit over the past few months from its initial announcement back in October at Mozfest to BadgeKit MVP defining, tech defining, user experience design, to more recently BadgeKit for Cities.
Many of these posts pointed to BadgeKit being made available at the Digital Media & Learning conference, this year taking place in Boston from March 6 through 8.
And we’re finally here! We will be making BadgeKit available to organizations interested in issuing open badges. As previously mentioned, this initial release of BadgeKit targets organizations, like cities, who want to stand up larger-scale badge systems. This was a natural evolution of the work we did for Chicago Summer of Learning last year and the tools we developed to support that initiative such as Badge Studio (badge design tool), Open Badger (badge defining and issuing tool) and Aestimia (badge application and assessment tool).
So what will this initial release of BadgeKit entail for issuing organizations?
* Enable access control
The issuing organization can create an uber admin login and from there grant some level of access control like who gets to issue a badge and who gets to assess/review a badge. We are thinking about adding more granularity down the road with ongoing user feedback and issuer requests.
* Design a badge
The issuing organization can get started on designing and defining their badges. BadgeKit will support the full badge life cycle states from draft form, published to archived. The badge design and defining experience will be scaffolded through the introduction of templates. An example of templatizing badges can be found in the badges designed and issued as part of Chicago Summer of Learning. These badges all shared a hexagonal shape and a Chicago city banner that hung across it.
This is an example of templates used to create consistent badge design but they can also be used for content creation. Some badges that are part of the same program may share similar information, like issuing organization name, program name, including elements of criteria. Rather than the issuing organization having to rewrite this information with each new badge, templates can help build on templatized content. We think templates can greatly help streamline the badge creation process for organizations.
* Create badges that level up
Not only that, issuing organizations can build in leveling up features into their badge system. We are calling these milestone badges. An issuer can define the set of badges that together unlock a larger badge, which we are calling a milestone badge.
* Issue a badge via email
The issuing organization will be able to issue a badge using the earner’s email. However, as perviously mentioned, BadgeKit is intended to be a backend admin support for issuing orgs who have existing sites where their communities reside. When a badge is issued to an earner via email on BadgeKit, this information is relayed to the issuing org’s application for the issuing org to determine how the badge will actually be delivered, whether via email, SMS or message in a bottle. Badge issuing via email is supported through the BadgeKit API with the issuer, customizing specific experiences according to their community needs and desires.
* Display a badge on Issuer site via BadgeKit API
The issuing organization will be able to pull all the badges they have designed and created on BadgeKit onto their own website through an API and customize the badge interaction experience for their community of badge earners.
* Support earners to apply for a badge on issuer site via BadgeKit API
When an earner is on the issuer site and comes across a badge that she would like to earn and can apply for online, she can do so. The earner, or prospective earner in this case, can click through and see the badge criteria and apply for the badge by submitting relevant information and evidence. This experience is supported by the BadgeKit API.
* Assess a badge
Once the prospective earner has submitted all relevant information on the issuer site, that badge application becomes accessible on the badgekit.org site to badge assessors/reviewers who have been granted the appropriate access controls from the issuing organization. Assessors/reviewers can then see the queue of badge applications and start evaluating them based on pre-defined criteria and/or rubrics. They can provide feedback and determine whether to issue or deny the earner of the badge. As mentioned in bullet 4, the earner experience of the actual delivery of the badge is defined by the issuer.
* Support earners to send their earned badges to federated backpacks
n.b. Federated backpack feature will come later this month
Because BadgeKit is integrated with the open badges standard and APIs, the earner has the opportunity to send their earned badges to federated backpacks where they can decide how they want to further share it out to various social media channels.
In addition to all this, it’s worth noting the brand definition work that our designers took on. We have a nice streamlined BadgeKit logo that is cohesive with the parent brand of Open Badges as well as Mozilla. This work was led by our designer Adil Kim with the guidance of our Creative Lead, Jess Klein who has written about this in greater detail in her blogpost: http://jessicaklein.blogspot.com/2014/03/on-designing-badgekit.html
We’ve made a lot of progress in the past few months but we still have a lot of work to do. As you can see, this initial release is focused on issuing organizations who have some level of technical resources and have an existing community-facing site into which they can integrate their badge system. Thereby it seemed appropriate to call this release private beta.
However, the goal is to make this more widely accessible in subsequent releases. As you well know, we develop and design in the open so all our code, sketches, wireframes and staging information are in fact out there for anyone to keep an eye on and poke holes at.
We’re excited to have reached this major milestone and look forward to feedback from issuing organizations who start to plug in!
n.b. We realize there may be a bunch of questions so we’ve put together some FAQs so take a look! http://badgekit.org/help Thanks to you all and as per yooszh, more to come!
This has been a crazy week for the open badges team.
Amongst our team members, we are covering 3 conferences: ATP Innovations in Testing, SXSWEdu and the Digital Media and Learning conference.
This includes 3 panel discussions, 1 interactive talk and presentation, 1 ignite talk, 2 Science Fair booths preparation, not to mention 1 BadgeKit private beta release and 1 Discovery prototype showcase.
WE CAN DO THIS!
I wrote this while I was on a plane with colleagues Meg from the Badges team, Matt Williams from SF Hive and Dustin from Sprout Fund. We had departed an unseasonably frigid Austin, having survived SXSWEdu, and were headed to an even more frigid Boston for DML.
So where are we at this midway-ish point in the week?
Reflections on the panels and sessions so far:
I couldn’t help but notice that the badges and digital credentialing conversation has come a long way. The ATP Innovations in Testing has not been a conference we had participated in the past. It is attended by the well-known guardians of high stakes testing, assessment and accreditation like Pearson, ACT, ETS etc. I popped into a couple sessions and was surprised to see the level of interest around digital credentialing and also its increasing relevance. On the actual panel that I had the honor of being a part of, it was clear that the badges conversation had expanded beyond the esoteric and was reaching a broader audience.
*** A session at ATP Innovations in Testing about the Changing Landscape of Recruiting in Industries, mentioned Digital Credentialing and Mozilla Open Badges.
I would say the questions fielded and the level of interest and enthusiasm shown at our SXSWEdu sessions would corroborate that.
A lot of work remains, both in the near term (this week) and longer term (getting wider adoption of open badges as complementary digital credentialing). While extremely tired right this moment, I’m also still pretty excited and looking forward to all the adventures ahead.
As you all know, I can’t stop talking about BadgeKit, the product we’re working on for a beta release in early March. As it turns out, folks are starting to line up to get in on the BadgeKit action and many of them are cities who would like to bring the Summer of Learning experience, like the one Mozilla collaborated on with the city of Chicago in 2013, to their respective neighborhoods.
So with several different cities expressing interest for a summer 2014 rollout, we started to think, what would Cities of Learning 2014 look like built on top of BadgeKit?
Chicago was definitely unique as they were the guinea pig for the tools we’re now evolving and refactoring to form the base of BadgeKit. But as more and more cities line up, we think there’s an opportunity for a shared model among cities in which cities leverage one another’s content through a common technical infrastructure powered by BadgeKit.
Rather than Milwaukee, Chicago, Los Angeles, Dallas and Portland, having their own Summer of Learning sites that are silo-ed and independent, what if we provided cities with the option to leverage one another’s learning content and badging experiences? That would essentially multiply the learning pathways and engagement opportunities for their community of learners. How exciting would that be; for a learner in Milwaukee to check out all the cool things going on in the city of Portland, or LA or Chicago?
Not only that, the shared technical infrastructure could provide multiple benefits for cities such as the following:
But Mozilla cannot do this on our own. We must enlist partners within our network that can help coordinate the complex web of working with city governments and the unique needs of each city locality. In addition to providing a sound software infrastructure to support multiple city needs, we need to provide adequate training and support for cities to implement and execute.
As such we are working closely with the MacArthur foundation and our Chicago Summer of Learning partner in crime, Digital Youth Network, to plan out the details of the BadgeKit for Cities shared infrastructure. Our first BadgeKit for cities guinea pig will be the city of Chicago yet again, this time under the name, Chicago City of Learning (CCOL).
CCOL will be testing out their next evolution of CSOL in April to coincide with Chicago Public School’s spring break. At this point BadgeKit will be plugging in and integrating with the CCOL site and powering its badging experiences.
From there we hope to continue to add additional cities and expand on the shared infrastructure to include several different cities across the US and North America, multiplying the learning and engagement opportunities for learners at a greater scale.
Details around Cities of Learning are starting to crystalize and we’ll continue to provide updates as we go along. We’re excited for all that’s ahead in 2014 and thrilled to grow and scale our Chicago Summer of Learning 2013 experience.
This past week, we marked the completion of Milestone 2, affectionately coined, “Preparing for Flight” on our BadgeKit product development roadmap. The milestone preceding “Preparing for Flight” was, “Ducks in a row”.
The goals we wanted to reach in Ducks in a Row are very much deducible by its name. We wanted to ensure we had everything teed up for us to move efficiently and effectively throughout the development of BadgeKit. We essentially wanted to get all our ducks in a row prior to the holidays so we could hit the ground running once we came back in the new year and pick up where we left off. As a refresher, our goals for Ducks in a Row included the following:
** check out the amazing badges Jess designed for the team, each time we reach a milestone. This one is for Ducks in a Row.
Our work was happening in parallel between the design team, led by Jess Klein and our development team, lead by Chris McAvoy, of course with a lot of cross pollination. While the design team sketched out the user experience, the development team deep-dived into the software backbone originating from the Chicago Summer of Learning experience, namely Open Badger, Aestemia, BadgeStudio and the CSOL site.
Coming back from break, we found ourselves refreshed, recharged and ready to go. And we dived into what we set out to accomplish in the next milestone, “Preparing for Flight”, for which a big driver was user testing.
In previous product development roadmaps, we’ve meant to incorporate user testing early and frequently but a lot of times when corners needed to be cut and project timelines re-negotiated, user testing would often be the first thing to get compromised. But with a dedicated user researcher on the team, shout out to Emily Goligoski, we have a strong, prevailing voice, advocating for the need to layer in user testing early on in the product development cycle, not to mention, our Creative Lead, Jess Klein, strongly supporting this vision.
As such, right out of the gate, the goal of milestone 2 was to get to a prototype that was testable. The following comprised the overarching goals of the Preparing for Flight milestone:
We reached this milestone this week as initially planned. What that means is that today, we have something that looks a lot like the UX sketches designed by Matthew Willse, our lead UX designer, on a staging site that provides a solid, albeit work in progress, BadgeKit experience. There are of course a lot of things missing here. There is essentially no UI direction or touch, many pages are “stubbed out” meaning there may be links to pages but those pages are not fully functioning yet and the front end is not entirely wired up with the backend powering many of the intended experiences. But there is still enough there to get out to users who can weigh in on the initial proof of concept and provide us with a gut check on our direction.
We also got a badge for completing this milestone, courtesy of Jess Klein. :)
Emily has drafted the script for user testing and circulated it amongst our team members and the inner circle within the concentric circle of networked partners. The idea is, we want to test it, but we don’t want to freak people out who are not familiar with testing a product at a very elementary stage and are distracted by the lack of polish or UI.
So we’re super stoked to have reached milestone 2, with user testing meeting us at the check point. Of course, we’re already fully in tackle mode for Milestone 3, which we’re calling Take Off. We welcome you to keep track of its progress here: https://github.com/mozilla/openbadges-badgekit/issues?milestone=6&state=open
We’ll keep chugging along in the mean time!
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!