Open Badges Values
We’ve been doing some strategy and planning work for Open Badges and the general badging work, and one thing that became clear was that we have some implicit values and principles that we have carried and/or want to carry with us into the future work.
We decided to write them down and turns out, that process alone was valuable for our strategy work. They have already been useful as a guide on our strategy and a litmus test for possible directions or opportunities. And that’s after just throwing them up on the fly. We want feedback and thoughts so that we can refine and agree on these, and in the process, set a direction that we can all work towards together.
Open Badges Values / Principles:
- Empower the learner. The end game is about helping learners improve their lives, get credit for what they do, and give them the data/ammunition necessary to do the things that they want to do. There are other ways we’ve talked about this - redefining learning, rethinking accreditation, but ultimately its about putting the learner in the driver’s seat.
- Agency. This is similar to the above and is specifically about control. The learner should control their data. They should control the interactions around that data. They should be able to collect and share any badges they want, even “smaller” or social ones that might mean something to them. They should decide who sees badges or what stories they want to tell about themselves (through the badges).
- Open. This is a loaded word, but its important in every meaning of the word. Badges should remain open in that anyone should be able to issue them. Many ask to restrict what can be badged so that its easier to establish equivalencies but that means we are restricting the possibilities for learners. The onus is on us to figure out how to make sense of that data. There should also be tools to support badging that are free and open source. As mentioned before, no proprietary or closed system should control the badges, the learner should. Open, open, open.
- Interoperable. A single badge might carry some value in some contexts, but a group of badges that tell a more complete story about a learner is so much more powerful. Especially when those badges are earned across experiences. This requires that badges be interoperable. This requires that badges align with the open standard. If we can have consensus at that lower level, then anyone can build tools on top of badges to make them more useable, more shareable, more valuable, etc.
- Distributed. We are working towards a more distributed ecosystem of recognition. That means each touchpoint in the ecosystem should be distributed - issuing, validating/endorsing, sharing, using badges, etc. Badges should be and go where the user is, and the badge information and value should follow.
- Credible. We think badges can be the real deal - can lead to real results like jobs and credit and advancement. We need to continually think about what gets badges to these standards without squelching the other features of badges. I have some thoughts on that here.
- Flexible/Innovative. (or “Weird.”) At the same time, we need to “keep digital badges weird”. We shouldn’t force all badges to be a one level or for one particular goal, we should build tools and frameworks to allow for innovative uses for badges.
- Community-driven. The community is gold. We can’t do this alone, you can’t do this alone. We are stronger together and a community that shares resources and findings, vets ideas and builds this stuff together is the community that wins. Our community is the lifeblood of the badges work and we need to codesign our future together. (*hugs!*)
- Something we are proud of. We are those feel-goody people that want to be proud of what we do. This means both not being evil, and also producing high quality stuff. On the former, I think we’re doing pretty well already but there is real risk of closed solutions segmenting or threatening the ecosystem and we should fight against this. On the latter, from the conceptual framework and the whitepapers, to the software and technical framework, to the toolkits and implementations, we want to walk away proud. There is a lot that we are proud of but turns out that this is pretty challenging to do all the time when there are so many moving pieces. But its a standard that we should all hold ourselves to and find ways to get there together.
What are we actively working against?
This list looks like the opposites of all of the above, but a few highlights:
- Data about the learner not for the learner. In our recent offsite, @iamjessklein had a revelation that most, if not all, of the data about learning out there is not for the learner. That’s really broken.
- Spy-ware. There’s a surge of attention around scouring the web to determine things about individuals or ‘score’ them, and then selling that information to employers. The individuals probably have no idea that this is happening. There is certainly some value in some cases, like the one in this recent NYT article, where some unsuspecting individual is rewarded for previous work or interaction with a job offer. But in most cases, its just spying and making decisions about people without giving them a chance to have their say. Badges should be all about giving people their say - letting them tell the story that they want to tell, but in an evidence-based, verified way.
- Replicating accreditation. A centralized system or body for judging or OKing badges would be bad for badges. If we are embracing open and distributed, as I hope we are, we need to find and open and distributed way to build trust and assurance into badges. I’ve written more about this here [referenced above].
- Closed and siloed. If badges do not meet the open standard or are stored in a system that is closed, we lose the real power of the ecosystem. To empower the learners, we need to let them have access to the broader ecosystem, craft their own pathways and write their own stories without predetermining the set they can work from or the constraints they are under.
We have a real opportunity for change and impact with the badges work, but we feel that the values/principles are important pieces for realizing that opportunity. As you can see from the list above, these principles do not define the solutions - there are still a lot of things to answer or figure out, but knowing the guiding principles can in some cases make those answers easy or keep us on course as we start to tackle them.
I’m sure the list is too long - maybe 3-5 is the magic number. Let us know what you think. Comment below or join us on the community call tomorrow to dig in.
The Evolution of Badges, DML-by-DML
The DML conference over the past few years has been a key milestone in the badge work. This year we formally launched the production version of Open Badges and it was awesome. As I was standing on stage announcing the badge work, I looked around the crowd and saw many many familiar faces. It made me reflective (and maybe even a little nostalgic) about the DML experiences over the years and the progress we’ve made together in that timeframe. In fact, if we use the DML Conference as a marker, its easy to see how the badges work has evolved and how far we’ve come:
(I threw in that last one because my team jokes that we can trace the lifetime of badges along with my son’s since they map quite nicely. I don’t know that that means but it makes it easy for me to remember how long I’ve been working on this stuff :)).
Looking through this list, you can see that the conversation around badges has certainly progressed in many ways - we’ve moved from solely badges 101 conversations into meatier topics like badge validation, and we’re now talking to policy folks, school boards, mayor’s, etc. about big implications and potentials of badges. The Open Badges technical work has advanced in that it didn’t exist (or was just in prototype form on Brian’s laptop) in 2011 and now its in 1.0, includes the open standard for badges and already has a significant level of initial adopters (over 700 issuers!). The DML Competition around Badges for Lifelong learning wasn’t conceived of yet in 2011 and now we have 33 grantees all demoing high quality badge systems and tools that will push additional job relevant and credit-worthy badges into the ecosystem. The team has also grown with the increasing momentum and resulting workload. We’ve come a long way.
There are places where we’re still spinning a bit. Mitch’s concerns echoed many of this thoughts last year, although I have to say that this year wasn’t anti-badge, but was more cautionary around ensuring that the badges represent learning and are thoughtfully designed. I’d have to agree with that wholeheartedly and in fact, have lots of ideas that I am going to pull into a separate follow-up blog post later this week. But it’s apparent that we’ve moved past the ‘what if’ on badges and now really need to dig into the ‘now what’. There is a great need for some knowledge sharing, research and toolkits around what ‘good’ badge system design looks like. A lot of this is already in the works, but we’ve got to make sure its accessible and actionable for folks. This has to be a community effort and the most valuable work will come from the people that are closest to the learning and assessment. Carla Casilli has stepped in on our side to help collect and curate this work, as well as put it into practice through our proof of concept badge systems like the City of Chicago and Webmaker.
I’m proud and excited about the progress we’ve made and also fully aware that there is much more work to do. My favorite part of it all goes back to the beginning of this blog post - all those familiar faces in the crowd - we’ve really built/accumulated a tight community - a family, really - of early adopters, advisors, skeptics and thinkers that have helped us get here and will need to help us get even further by next year (wherever that may be, hopefully somewhere warm!)
Open Badges 1.0 Launch
You may have heard but we launched Open Badges 1.0 on Thursday at the DML Conference. Here are some places to read more:
Here’s what 1.0 means to me, pulled from the talk I gave at the announcement on Thursday:
A digital badge is an online representation of a skill you’ve earned.
Open Badges takes that concept further, and allows you to verify your skills, interests and achievements through a credible organization.
And because the system is based on an open standard, you can combine multiple badges from different issuers to tell the complete story of your achievements — both online and off.
Badge earners can display their badges wherever they want them on the web, and share them for employment, education or lifelong learning.
So what does Open Badges 1.0 mean?
Mozilla Open Badges is made up of two things: a technical standard that anyone can follow to make their own Open Badges and free, open source software for issuers and users.
How does it work?
Right now, Open Badges gives enables issuers to issue verified, open badges and connect their users into this broader learning ecosystem.
It also gives users a way to collect, combine, and share their badges.
Finally, every badge is full of information: employers and others can dig into the rich data behind each badge and see who issued it, how it was earned, and even review the projects the user completed to earn the badge.
Let me walk you through the process of issuing, earning, and sharing a badge.
This is the badge backpack, where you collect and manage your badges.
So to begin, users can create a backpack with just an e-mail
Here’s an image of an empty backpack - eventually we will have links out to possible badges to earn or things to learn here. For now, let’s show you how we earn and collect a badge. We’ll use a Mozilla Webmaker badge as an example.
Here our user is making a web page with Webmaker. On the upper right you see that they’ve been awarded a badge for the skills they’ve applied while making the project. This is a good place to remind ourselves that badges are just recognizers on top of the learning and assessment - that is the meat behind the badge. In this example, a learner is learning HTML and CSS Basics while they are building a webpage and earning badges in the process.
The user then sees detail of the badge, and can accept it and add it to their backpack.
Now the badge has been added to the backpack.
Earners will be able to organize their badges into different collections
They can then create a public-facing portfolio page with their badges, and add notes about what they’ve earned
You can also share your badges on social media. Clicking the Twitter link brings up a box to write and send your tweet.
And there it is in our user’s twitter timeline.
A plug-in for Wordpress built by a community member also allows you to display your badges right on your blog. There is much more to come here as well in the next few months.
All of this is powered by free and open source software that anyone can use. And Open Badges sets a technical standard that any issuer can follow, which means their badges can connect to and add up to more substantial recognition and opportunity.
Why does this matter?
We think Open Badges will change how people think about recognition and achievement — from traditional institutions to leading organizations — and connect lifelong learning to real results like jobs and additional opportunities.
On the jobs front, we’ve talked to many employers, and they all say the same thing: undergraduate degrees are a check box, but they tell you very little about the skills that the particular person possesses; resumes are difficult to verify; and it is almost impossible to get an understanding of a candidate’s social or ‘softer’ skills.
Open Badges changes that, and gives us a way to tell a more complete story about who a candidate is, and what they bring to the table.
We are formally launching 1.0 but there are already hundreds of organizations working with Open Badges today - there are 600 orgs issuing badges and even more moving in that direction. Potential badge earners can now look for this symbol, which they’ll begin to display on their sites in the coming weeks.
And there’s lots more to come with new features, more social integration (Fb), more tools for issuing, new partners, and new ways to earn badges. We’re here to continue the conversation and collaboration, and build the ecosystem around Open Badges.
I want to give a HUGE shout out to the Open Badges team, which is still a pretty small, scrappy team. These folks get up everyday believing in this stuff and trying to change the world and I am so lucky to work with them. This was a herculean effort, and I can’t thank them enough.
I also want to thank our communications team which pulled out all of the stops to add the polish to our work and get the word out broadly.
Thanks as well go to MacArthur for the funding which is obviously important, but for also being an inspired thought partner on all of this work.
And last but certainly not least, we have to whole heartedly thank our community who works with us side by side to build and iterate on Open Badges. Through community calls, the mailing list and other channels, our community vets everything that we do and contributes to the broader conversation on a daily basis. They are also the ones developing high quality badges - we couldn’t do this or be to this point without them.
I look forward to your questions and feedback. I hope you’re as excited as we are to challenge our outdated ideas about what should “count” toward education, and empower people to create their own paths to success.
A couple quotes to leave you with
With Open Badges, you don’t have to just tell the world about how awesome you are—-you can prove it. (me :))
The more incidences of an “unaffiliated” (term used loosely) third-party creating web standards for credential sharing…the better off education will be. No two ways about it. (Techcrunch)
Webmaker Badges Roadmap
It’s roadmappin’ time again, folks. I’ve shifted my focus a bit to zero in on making badges a success and that has two pieces:
- Web literacy badges
- The Open Badge Infrastructure and wider badge ecosystem
This roadmap covers the web literacy badges plan for the rest of the year. Look for the OBI roadmap to follow shortly.
WEB LITERACY BADGES
Objective #1: Build the web literacy standard.
I’ve written about this before and done a bunch of thinking about it sense. This is a different spin on the work we’ve done so far to define the skills that we think are the core pieces of being web literate, or having those literacies. The goal is to co-create and maintain a learning standard with a bunch of partners - and then for us all to align to that standard and work together toward this common goal of creating a web literate planet.
We don’t yet know what the ‘product’ for the standard looks like, but we’ll be digging into that more deeply over the next few weeks. If you are interested in learning more, we’re hosting a virtual meeting next Thursday, Feb 7th. Join us!
Objective #2: Build more web literacy badges.
We rolled out the first set of web literacy badges last November through Webmaker, that covered some basic web competencies like HTML and CSS. Obviously, that is a small slice of our vision of web literacy and we want to expand the badge offering to cover more skills - ultimately to provide learning pathways and badges for all of them.
Objective #3: Build assessment pathways.
This is the fuzziest of our objectives because we could do it in lots of different ways. Ultimately, we want to give people a way to demonstrate the web skills they have, regardless of where or how they learned them, and get assessed and earn recognition (badges) for those skills. This could manifest as a mechanism for submitting a link to something you built to the Mozilla community to assess and then earning one of our badges. Or it could involve building mini assessments aligned with each competency/skill that you can come back to us to demonstrate your skills, or you could take those assessments and build them into your own curriculum, etc. Lots of things to decide on but lots of exciting potential directions.
Objective #4: Launch the New Backpack.
This is where the two roadmaps intersect a bit. The Backpack in the Open Badge Infrastructure is a repository and management interface for each badge earner. Right now, they can use their Backpack to collect badges across issuers, create groups and publish them and share out badges. It’s the, as we like to say at Mozilla, minimal viable product of what people could do with their Backpacks. We have lots of ideas of expanding on that to include dashboards, goal setting, discovery of other learning opportunities and finding mentors. We will most likely build this for Webmaker first and then role it into the broader ecosystem solution.
What Success Looks Like:
These are sort of cheating as far as success metrics go, but its still early and just want to give an idea of what we’d feeling like celebrating:
- Launch the learning standard for web literacy
- Have lots of other orgs and people aligning with it
- Offer learning pathways and badges for all of the competencies/skills
- See lots and lots of people earning and sharing these badges
How We Will Get There:
Tons of work to do and here’s how it will roll out over the year:
- Web Literacy Standard kick off and launch
- Early prep / prototypes for more badges
- Launch second wave of web lit badges
- Launch peer assessment
- Continued standard iteration and partner recruitment
- Launch larger Mozilla-wide badge system
- First prototypes of assessment pathways
- Additional integration in Webmaker
- Launch full set of web literacy badges
- Launch assessment pathways
- Launch Dashboard / New Backpack
Let me know what you think!
Open Standard for Web Literacy: A Vision for Webmaker
We’ve been doing a lot of planning and brainstorming and chatting about what Webmaker will look like in 2013. There are lots of good ideas floating around that you can see from a bunch of my colleagues here, here, here and here.
One thing I want to add into the mix is the vision for Webmaker as an open standard for web literacy.
That’s a mouthful so let’s work backwards and break that down a bit:
The Web Literacy part…
(Or as Doug reminds me, web literacies)
We’ve been talking for a long time about the skills that we think people need to be a webmaker. To be more producer-minded. To understand and love the Web. To express themselves in a way they can be proud of. To compete in today’s economy. To be an active citizen.
In addition to all of the flashy tools, content and branding we’ve been launching over the last year, we’ve also been doing some considerable ‘underbelly’ work to define the thing we are ultimately after: a generation of web literate people. Doug has been leading a lot of our initial work in this area, which looks something like this in its current iteration:
You can see that there is a mix of ‘hard’ skills like HTML and CSS - very specific skills that people need to know to make things on the web without wysiwygs or forms. But then there are also a lot of the more social or 21st century skills like sharing, collaboration and remixing.
The Standard part…
I think this is important work for more reasons than just enumerating the things that Mozilla cares about or may provide learning pathways and badges for, but as a definition that we, as in the royal we of the web world, can all get behind and all teach to. One of the issues with the digital literacy work that’s been around for some time, is that there isn’t a commonly agreed upon description of what it actually means from a skill perspective, or when we can draw a line and say, congrats, you are digitally literate! Some of that is beautiful - we want flexibility and room for innovation - but I think there needs to be a core definition that people can build from. I think that’s one thing that Webmaker can offer. You can use our tools if you want, but you can also use your own tools or other options out there - but if we all agree on the basic thing that we’re working towards, we’ve created a web-wide choose your own adventure for learners, with a success story that benefits them and helps us all reach our goals.
The Open part…
This is a loaded word and that’s intentional here. I think in order to be successful, this standard needs to be open in several ways, some of which I’ve already alluded to:
1) Open as in open source:
Mozilla cannot build and maintain this standard alone. In fact, we haven’t been - Michelle and now Doug, have been traveling the world, talking to experts and n00bs and everything in between to get a sense of what skills are important. Lots of people have contributed and we are going to be ensuring that this is even more of a community effort moving forward.
Additionally, this standard needs to be extensible. We should see this as the core and leave room for people to easily hang things off of it (i.e. design skills, game theory, etc.).
2) Open as in open ecosystem:
Mozilla can’t be the only place you come to learn this stuff. Lots of other people are already teaching people many of these skills and so let’s leverage each other to teach web literacy at web scale. In fact, as you look at that grid above, it’s highly unlikely that any one organization will teach all of those things, so again, it’s together that things become more comprehensive and more powerful.
We also aren’t saying that there are particular ways that people should teach this stuff. We are building some of our own learning pathways which will be very making-forward, but to appeal to everyone, there are a lot of other approaches that should be in the mix (for example, folks like Codecademy, Coder Dojo and Khan Academy), but also including approaches that aren’t even intended to be learning experiences. There is a lot going on through Twitter or Instagram that help people develop web skills like sharing or curating. Again, it will be important to leverage a lot of the work and options that are already out there and find ways to build the learning/recognition layer on top of things people already love to do.
3) Open as in Open Badges:
We are developing a set of badges that are aligned with this definition of web literacy, but again, if Mozilla sites are the only places that you can earn those badges, we’re limiting ourselves, and constraining learners. Recognizing the learning and skill development, and fostering reputation and identity development around web literacy is as huge part of all of this and that necessarily means that we need a solution for a more distributed set of badges. Good news is that our other day job is building and promoting Open Badges, so we have the infrastructure in place, but no one else in that ecosystem is sharing badges across organizations so solving for that will be an important challenge.
What we end up with is a co-designed, shared purpose with a much wider network with much wider reach…and a much higher likelihood of ‘winning’ together.
Lots of work to do on this moving forward - excited to work with all of you on it.
Webmaker Badges Are Here: Get Recognized!
I wrote awhile back about our thinking around the Webmaker Badges. Well that thinking is now a reality, we launched the first set of Webmaker badges at MozFest.
There was a big Mozilla post and fanfare around the launch, so I’ll just let you read that for the high level details, but I wanted to go a level deeper and also highlight some key next steps.
Skills + Participation.
As I detailed in my previous post, and as you can sort of see above, the initial badges cover a range of ‘hard’ skills like HTML and CSS, but also a range of participation and contribution activities. We think web literacy is more than just learning how to code or specific technical things, but also about being good active members of communities, etc. The first Webmaker badges are a taste of this.
The badges above represent the first of a much larger set of badges that we plan to release over the next year. We knew we needed to start somewhere and zeroed in on the core skills that we were already covering in Thimble, as well as participation badges aligned with MozFest, but plan to release badges that span more skills, levels and events.
Repeat after me: Badges are not assessment. Badges are the thing you get after you’ve learned something and successfully demonstrated that learning through an assessment. The assessments are incredibly important because they are the ‘evidence’ or meat behind the badges. For the initial Webmaker skill badges, we are using embedded assessment, meaning that we’ve built rules into Thimble that automatically assess as the making is occurring and issue badges accordingly. We love this type of assessment because its built into the making, or the stuff that the learner wanted to do anyway, versus making the learner do some artificial separate assessment like a multiple choice quiz. It works pretty well for things like HTML and CSS.
Smart issuing technology.
We’ve built a pretty awesome tool, currently called Open Badger, that supports badge creation and issuing. It allows someone to define a badge, including assigning a name, image, and all of the metadata behind the badge, generates criteria pages, gives you an API to award badges based on learner behavior on your site and posts/hosts the badge assertion for you. And I’m sure I’m missing a few things. It’s pretty awesome and of course, its open source. We’ll be releasing it early next year for folks to run on their own servers. For now, we are beta testing it as the engine behind the Webmaker Badges.
User experience tweaks.
We watched a bunch of people earning badges at MozFest and while people love the badges, we’ve got some work to do on the UX to make sure that people not only understand the badges, but make the connection back to the learning that occurred. This launch was the MVP so we knew we made some sacrifices on the UX front and the good news is that we learned a lot at the festival and have the right people in place to take the experience to the next level.
As I mentioned before, this was just the initial set of badges. Next up, we are working to launch badges in Popcorn Maker, as well as add more badges across the web literacy skills to our arsenal.
More assessment innovation.
We did some pretty cool stuff with the embedded assessment for this launch and we want to do more of that, as well as explore peer and self assessment approaches to provide additional flexibility and robustness to the badges.
One of the main goals for 2013 is figuring out how to meet our goal of building a generation of webmakers without getting in the way. There are a lot of other people already doing awesome stuff that teaches various webmaking skills or web literacies and we want to include them or recognize their learning, etc. We don’t know exactly what that means yet but we want to find a way to open up the Webmaker Badges to a much broader set of organizations and learning pathways.
I’ve been lucky enough to be the one introducing the world to the Webmaker Badges, but the credit really goes to the awesome team, including:
- Carla Casilli - Chief Brains and Systems Designer of the Webmaker Badges and learning pathways behind them. She’s the big kahuna of Webmaker Badges and she pulls together all the pieces to make it a badge SYSTEM.
- Chloe Varelidi - Assessment Guru and Badge Mentor (while also driving all of the hackable games work!). She helped define all the initial badges and assessment approaches.
- Doug Belshaw - His Majesty of Web Literacies and Skills. He owns the definition of the web literacies and skills.
- Chris McAvoy - Chief Techie Wrangler. He wrangles all of the brilliant geeks (and is in fact a brilliant geek himself) to deliver production grade stuff on schedule.
- Jess Klein - Aesthetic Sorceress. She wields her magic to make things beautiful, usable and effective for all of Webmaker.
- Atul Varma - The Innovation Developer, or the Guy-Who-Makes-All-The-Crazy-Ideas-Real-Things, responsible for making the embedded assessment in Thimble a reality, among other things, like, um, Thimble.
- Brian Brennan - Badges Overlord. But not the evil kind. He is the technical brains behind the Open Badge Infrastructure and built the issuing technology for the Webmaker Badges.
- Mike Larsson - Finesse Doctor and our go to Fire Fighter. He not only builds mission critical stuff and fixes problems, but adds the finesse on top of everything.
- Chris Appleton - Badge Designer Extraordinaire. He not only designed the first School of Webcraft badges way back when, but designed our pretty honeycomb badges for Webmaker.
- Sunny Lee - Big Picture Advisor. She represents the Open Badges work and helps keep the Webmaker badges work firmly grounded in the wider ecosystem efforts.
Thanks all! You should all get badges for the awesome work! And thanks to the extended team that gave feedback, fixed bugs, promoted the work, etc.
We’re gonna launch some Webmaker badges at MozFest and some more next year. They will include a variety of badge types and some awesome assessment. Get ready world.
====LRIYW; (Longer, read if you want version)====
We’re building a Mozilla Webmaker badge system - eventually feeding into a larger Mozilla badge system. As I mentioned in my last roadmappin’ post, this is our number one priority from now through MozFest. And it’s WAY more than designing some pretty images, its the skills, assessments, technology, metadata and learning content as well. It’s all underway and here are some of the details, pulled from a presentation I gave on the Webmaker call last Tuesday**.
I think it’s important to explicitly talk about the why or the goals behind the badges. Not only is that important for justifying and explaining why badges are a huge priority for us, but it can also help inform some of our decisions about the types of badges to include, what’s in scope/out of scope, etc.
- Badges = disrupting a monopoly and putting the control back into the individuals’ hands…it’s what Mozilla does.
- Defining / driving a Webmaker experience.
- tying together tools and experiences
- defining potential learning webmaking pathways
- defining an architecture of participation and contribution
- Building fun into the Webmaker experience.
- Recognizing and tracking learning.
- Building and formalizing community.
- Scaling our stuff beyond ourselves.
With those goals in mind, the following is the current set of badges, assessments and tools (types, touchpoints and technology) planned for the first iteration of our badge system.
- Skill (I can ____, I know ____)
- mini (I can hyperlink)
- cumulative (I know HTML Basics)
- Achievement (I made a _____)
- mini (I made a webpage)
- cumulative (I am a webmaker)
- Participation (I attended an event)
- Contribution (I hosted an event, I created a project, I added code)
*NOTE: because we are starting with a very small set of explicit ‘hard’ skills, we are awarding the cumulative based on accumulation of the mini badges. Moving forward, we want to expand to a much broader set of skills, including softer skills. We know that moving to a peer assessment model will be very important for adding more review, evidence and mentorship behind the badges. Look for peer review to come early next year. We’ll be asking for your help on designing an effective peer assessment system.
PULLING IT ALL TOGETHER
the badges constellations available by the end of this year below.
NOTE: we are still working through the possibilities with Popcorn so there may be another set of skill badges: mini and cumulative reflecting those skills and that learning either in the first iteration or shortly thereafter.
So how are we going to make all of this happen? (answer: very quickly, but more specifically:)
We are building OpenBadger (OBr), a lightweight badge issuing tool that, despite being lightweight, will do most of the heavy lifting. Specifically, OBr will handle:
- Badge creation and metadata definition
- Badge issuing
- Connection to the OBI
In addition, we will be doing some tool and site integration:
- Building embedded assessments into Thimble and Popcorn
- Building calls out to OBr within Thimble and Popcorn. For example, when someone clicks publish, issue this badge, etc.
As I mentioned above, we are pushing towards MozFest for an initial release, but we are already thinking about the follow-up releases and where we ultimately want to get to. So the roll out looks something like this (although everything is subject to change and wide open for comments/suggestions). More detail on the follow up releases to come in separate posts.
- November 9-12 in London - don’t miss it!)
- All of the above, first iteration of the badge system
- More badges and skills covered
- Peer assessment
- Pathways (including non-Mozilla options)
- Dashboard, goal-setting, portfolios
So that’s the current plan. We would love feedback and suggestions on how to improve the first iteration of the badge system, as well as ideas for the follow-up releases. Let us know!
The Three T’s of Badge System Design
We’ve been working on the Mozilla Webmaker badge system, or at least initial alpha badges for the Summer Campaign and it’s tough! We knew that going in - if it were too easy, then we probably wouldn’t end up with very valuable or robust badges - but that didn’t make it easier. There are many things to consider and it’s very easy to get caught up and stuck in the core question of what badges? That’s a really loaded question because its not just about what to call the badges - which is a rabbit hole of itself altogether - but its also considerations around specific skills, levels and granularity (which is a huge/tough one), assessment, experience, etc. We spent days trying to answer the what badges question - should we have an HTML Level 1 and Level 2 badge, or just an HTML badge (and what do those mean?)?; should we call them Ninjas or Samurais (note: we decided on neither)?, is there a Webmaker badge that everything aggregates up to and if so what are the badges that make that up?; are all badges the same granularity?, etc. The decisions at this level are also things that more people care about and have to sign off on so that also slows down the process.
I’ve since stepped back and looked at the process and realized that there were a few considerations that actually helped us move forward - and that those considerations were one or more steps removed from the badges themselves. I’m now calling this my 3 T’s of badge system design, and so far its proving to be a helpful place to start or at least move back to when you feel you getting buried in badge level decisions.
3 T’s of Badge System Design:
(1) Types - general categories of badges. Do you have skill badges or participation badges? Progress badges or achievement badges? To do this, you need a general understanding of the learning experiences, the community and most importantly, the goals of the badge system, but you don’t have to go super deep. You don’t, for example, need to know the exact set of skills that you want to badge. And you definitely don’t need to finalize the badge names ;). You just need to decide if you are badging skills or actions or achievements or progress, etc. Finalizing and putting some lightweight descriptions around your types of badges can really help you scope the system before diving into the questions around the specific badges that fall into each.
Our alpha badge TYPES*:
Skill badges - I developed this skill
Participation badges - I attended or hosted this event
Achievement badges - I made this
(2) Touchpoints - next you do Touchpoints or general description of how someone will earn the TYPE of badge. This starts to pull in assessment and criteria but again, you don’t have to go super deep at first.
Our alpha badge TOUCHPOINTS*:
Skill badges will be based on work that the learner submits, assessed by peers against a rubric. (note: this is probably even more specific than you need to go at first)
Participation badges will be based on registration for an event and proof of attendance.
Achievement badges will be based on work that the learner shares with the community.
It’s a good practice to think through if there are several possible touchpoints for each badge type (and the pros/cons of each approach). Thinking through this at the outset gives you more flexibility going into the technology considerations and helps you better work with any technology constraints you might have. For example, back up touchpoints for our badges might be:
Skill badges will be issued when the learner completes a learning challenge that cover the skills.
Participation badges will be issued by the host of an event directly to attendees.
Achievement badges will be based on completion of making exercises/projects.
(3) Technology - finally, you translate the touchpoints into high level technology requirements.
For the first set of touchpoints, our TECHNOLOGY requirements might look something like the following:
Badges integrated into the learning tool environment and the events site
A Gallery component that learners can submit work to with a voting or rating capability for skill/achievement badges
These can be more granular but don’t have to be at this point. Just think through the basic requirements and see where you net out. It may immediately become clear that something won’t fly and you can start to work around it right away instead of way later in the process. Going back to our example, maybe we would find out that we weren’t able to have a gallery component and if this is the case, we could go back to our touchpoints and decide to use another option for those types of badges and tie those badges to the learning exercises, and thus the learning tool, instead. That decision would most likely change elements about the assessments and the specific badges we ended up defining as well, so the information flow works both ways.
What you end up with is a general map of your badge system and a basic roadmap for what needs to be built to support the badge issuing. It could also help you evaluate existing badge issuing platforms to see if they have the features that meet your needs.
Next steps are to start to dive into each piece a bit more. Define a few of your skill badges and work through the work flow again - what is the specific touchpoint (rubric, rating required, etc.) and what are the specific features needed to support that. Press repeat, press repeat.
Again, this is the model that we’ve accidentally started to use with our badge system design. It’s not rigorously tested by any means, just seemed to work well for our first few iterations. Would love to hear back from folks on if this is helpful, where it breaks down, etc.
*Note: our alpha badges are still in alpha so are subject to change