Let’s Make More Backpacks

School is starting, which makes me think about school supplies. We use some school supplies as metaphors in the Open Badges world, the Mozilla Backpack is the place you can store your Open Badges. The current backpack stores open badges, organizes them and displays them. It’s really more of a portfolio than a backpack, a collection of achievements instead of something you need while you’re learning day-to-day.

The core functionality of what makes an open badges backpack valid supports the broken metaphor. A backpack (in the open badges sense) is a place to store badges. It validates the badges. It displays them. Maybe it organizes them, but that’s not a requirement. It’s just a filesystem with stuff in it.

So, should we change the name? Should we ditch the backpack metaphor and start calling it a ‘badge storage system’ (gag) or something? No, we shouldn’t, we should let the metaphor guide the development of what an open badges backpack is.

Backpack as Personal Expression

Ask my six year old about his school backpack. He’ll tell you all about it. It’s big, but not too big. It has Marvel super heroes on it. It has a special flap that let’s you choose between two different sets of super heroes, so he can change it up day-to-day. It has a single pocket, nothing fancy to get in the way of the essential nature of what a six year old needs, a place to put his lunch and a small amount of homework.

Ask me about my backpack, it’s biggish, but has these straps that make it small. It’s full of pockets that are easy to get to, some of which have a soft lining for electronic devices. It has a stiff back so that protects my laptop. It’s flat black and emphasizes utility and comfort. My last bag was a courier style bag with snazzy materials. It had a big single pocket that was easy to get to, and the design would impress people who were impressed by that sort of thing. I like both of these bags, but they’re very different and I use them for different reasons.

See what I’m getting at here? Real backpacks serve different purposes. They’re indicative of who we are and express ourselves in different ways. My bag won’t work for my son, his bag won’t work for me. Sometimes I use my utilitarian bag, sometimes I use my fancy bag.

Real backpacks as open badges backpacks lesson one – one size doesn’t fit all, open badges backpacks should be as various as real backpacks. Sometimes you need more than one backpack for different situations.

Backpacks with Constraints

Some schools have requirements about what their kids can use as a backpack. The most common is that they are clear, so teachers and staff can see inside them at any time. It’s not the greatest thing for student privacy or personalization, but as a constraint – it exists.

Lesson 2 – institutions will put constraints on the open badges backpack that won’t apply to all users. We need to accommodate them.

You’re lost without your backpack

Did you ever forget your backpack at home? Or your laptop bag? Your stomach  flip-flops, it’s borderline terrifying. In a learning situation, you’re lost without your backpack.

That isn’t the case with the current Mozilla Open Badges Backpack. The backpack is an after thought in a learning experience. It’s the place you push the results of your learning, not the place you’re actively planning your learning. It’s the equivalent of forgetting your report card at home. Who cares?

Which leads to lesson 3 – let’s make our open badges backpacks more useful, part of your day, essential to the way you learn. The badge backpack isn’t a trophy case, it shouldn’t just be a portfolio, it absolutely isn’t a report card. The backpack is where you go to track your progress, reflect on what you’ve learned, discover new paths you can take to get where you want to go. It’s your learning GPS, something essential to your learning.

What’s Mozilla Doing About It?

Yeah, so – backpacks can be cooler. What’s Mozilla doing about it? Three things:

Many Backpacks

There’s only one real open badges backpack today. If you press the button “push this badge to your open badges backpack” on any issuer’s site, it really means “push this to your Mozilla Open Badges Backpack located at http://backpack.openbadges.org” That’s what the world of badging needed to get started. It needed a single backpack, to prove the concept and bootstrap issuing.

Now that we have a healthy issuer ecosystem, it’s time to bootstrap a healthy backpack ecosystem. We’re working on extensions to the Open Badges Infrastructure that will allow a user to choose their backpack and push their badges there. There isn’t any burden on the issuer, they’ll still integrate a single button served by Mozilla, but the button will be 17% more magical. Once a user can push their badges wherever they want, they’ll want choices.

This feature has been on our roadmap for a while under the unintentionally obfuscated title “Federation.” It makes sense to us, but it’s hard to explain to the community. We’re working on better language (and could use your opinion, get involved in the mailing list) regardless of the name, the result of the feature is clear, learners get to choose their backpacks.

Mozilla Backpack 2.0

After a fair amount of soul-searching, we’ve decided to refactor the existing Mozilla Open Badges Backpack. We’ll do the work alongside support of the current 1.0 backpack. We’re not planning any significant features in the 2.0 backpack, it’s mostly a feature for feature replacement of the existing backpack. We’ll rework the UX, make branding changes to get the backpack in line with the current branding of Open Badges, but will mostly mirror the existing 1.0 backpack.

Why do it? There’s a significant amount of boiler plate functionality that makes up an open badges compliant backpack (which in itself is a moving target, we haven’t actually declared the requirements of a backpack yet, we will, so keep your ears peeled). If we want to encourage a diversity of backpacks, we’d like to offer a solid starting point. A collection of code that allows for easy extension of the backpack concept. If you have an itch to scratch backpack-wise, you can do it in a few days, or hours, you won’t have to recreate yet another storage system for assertions, or validation against the spec. Fork our code and focus on what you should, providing an awesome experience for your users.


Finally, Jess, Andrew and Emily are leading the charge towards a new vision of an open badges backpack. They’re working on backpack 3.0, or backpack 3000, or Badgeopolis. A backpack prototype that’s as important to you as that backpack with the flippy cover so you can show whatever super hero you want to. It will be a concept car like experience that will help guide future backpack crafters and seed the world of post it-just-stores-badges backpack thinking.

Exciting, yeah?

We hope so. Open Badges is taking off. We’ve proven to issuers that they can use open badges to guide their learning communities. Let’s get the same level of innovation applied to tools for the learners. Let’s make open badges backpacks as diverse and personalized as real world backpacks. Why settle for badge storage? You’re way cooler than that.

Badgecamp ’13!

The Open Badges team is going to spend a few days in retreat mode, stepping away from day-to-day work to think through what we’ve been up to for the past year, where we want to go and the best way to get there. It’s a welcome change, we’ve run full speed since January. First to the 1.0 launch of the OBi, and then to release Chicago Summer of Learning. We need a chance to slow down, raise the periscope and figure out where we’re at.

Back in early June, Erin presented a vision of where Open Badges could go to the Mozilla Foundation board (slides). The work that the team agreed they wanted to explore pre-badgecamp all fits in with the concepts outlined in the board slides. We split the (growing) Open Badges team into smaller focused groups, and divided up the work. The goal is to have something to demo or present at badgecamp. By the end of camp, we’ll have a solid roadmap for the next couple of months. The rest of this post is me explaining my thinking on the pre-badgecamp projects, as preparation for the big get together.

Chicago Summer of Learning Learnings

From the launch of OpenBadges 1.0 in March until June, the badges team worked with the City of Chicago (and others) to launch the Chicago Summer of Learning. The largest citywide open badge system ever. The project and outcomes are worth a post of their own, so for now I’ll say that it was a difficult project. Tremendously rewarding, super important for the city and for the open badges ecosystem, but taxing for sure. There are lots of details to discuss coming out of the project, and we’re planning on spending at least the first day of camp talking them through.

We learned a few important things. First, what it means to build a product for a community that doesn’t know you and hasn’t already bought into the concept of open badges. We’re fortunate to have worked with a very supportive open-minded community up until this point. Our backpack has UX issues, the community accepts it and works with us to fix it, someone finds a bug, same thing. With CSOL, we put our work out in front of a large group of people who weren’t interested in us, they support the product. It’s an obvious lesson, one that we’ve all experienced individually, but as a team – it was a first. A very valuable lesson.

Second, design driven development is what we’re best at, and it’s not worth trying to deny or reinvent the system. I tried to shorten the development time by running broad design in parallel with the site development. It was a worthwhile experiment, but ultimately proved that we should take time up front to make fundamental design decisions. It doesn’t mean we’re running a waterfall project, but it does mean we need to have a solid handle on what we want to build before we just start building stuff. Think of it as agile with a slightly more cautious first week or two of up front work. At camp, >Jess will get to say, “I told you so” for no more than 3 minutes.

Like I said, there’s lots of learning from the project, I don’t want to spend this entire post figuring it out, so I’ll leave it for now with a third (and final) CSOL takeaway – building a team that invents things is different from building a team that executes based on a pre-existing template. The fact is, the badges team is a team of deep thinkers who are amazing at proving or disproving the validity of an abstract idea. CSOL was a problem solved largely by elbow grease, phone conferences and grinding out code. I’m excited that the core open badges team is moving back towards designing the future of badges. We’ll find more sustainable ways to execute the next CSOL level project that don’t cut into the kind of work we’re good at.

The Backpack

The Mozilla Open Badges Backpack has been online for a year and a half now. It’s allowed users to collect over 100,000 badges so far. It’s an important piece of software, what’s next for it? It’s a big topic, so we divided into two teams – a “what do we do with the backpack now?” team, and a “what will the backpack be in the future?” team. It’s possible, actually pretty likely, that those two teams are actually working on two separate products, that the second team will conceptualize something that’s way different from the current backpack. I hope they do. Innovation in the open education world is starting to level off. Everyone is developing things that are versions of something that already existed. I want to see this team propose something wholly different and wonderful, Willy Wonka level innovation. Wallpaper that tastes like fruit. That sort of thing.

On the other hand, the current backpack has 100,000 badges! That’s a pretty big responsibility. Here’s the thing though – if you’ve been on a community call in the past year or so, you’ve probably heard us refer to the backpack as “a reference implementation.” The implication is that the Mozilla backpack is just something to prove a concept. That’s not the case anymore. People are using it, they’re collecting important information about themselves there, we have to treat that with respect and make sure they have the best possible experience. The first step is to clean up the implementation. Fix long-standing bugs, monitor production in a way that makes it easier for us to find bugs before our users. A lot of the thinking around the operationalization of the backpack comes from the launch of CSOL. We learned a lot about quick launches and monitoring in the run up to CSOL, we’re applying that thinking to the backpack now. There’s plenty more in the works as well, including another pass at UX / UI enhancements. We saw a huge improvement with the 1.0 launch, we’re due for another overhaul, both to streamline badge earners workflow and to match the branding we established back in March. We want our backpack to be a place that encourages users, not challenges them.

Open Badges Infrastructure

For 1.0, Brian nailed signed assertions, a revised assertion spec that allowed alignment to standards and a slew of other extensibility features and opened the door to alternative authentication systems. Atul prototyped Backpack Connect, a backpack specification that gives users the ability to directly connect trusted issuers to their backpack, allowing the trusted issuer to put badges directly in the users backpack.

Next on the list is Federation, best described as “the user has a backpack someplace, their badges should go there.” Federation implies two things (maybe more), 1) a backpack has a standard interface that it implements at a minimum. Things like “accepts badges”, “authenticates a user”, “authenticates a badge” are all things that a backpack should do. Without a common standard of backpack behavior, we can’t treat any backpack like any other. 2) If there’s a bunch of backpacks out there and a bunch of issuers, and a user earns a badge on some issuer, how does the issuer know where to send the badge? At its simplest, the user would tell the issuer where their backpack is. We’re discussing (animatedly – it’s kind of a hot topic now, which means its fun to talk about) some sort of magical directory service, that’s both distributed and centralized enough that it’s easily discoverable but not a dumb fat server sitting out there in the world. When you combine the two pieces, you get an infrastructure that supports the holy grail of badge issuing, “I have earned a badge from issuer x, it goes into my backpack (that I host on my desktop) magically, but safely and verifiably.” That’s the story I’m interested in building. When it’s done, and you peek behind the curtain, it’s probably going to be strange and unmagical, but on the surface, I want the user to know as little about their backpack as possible, as little about the issuer as possible and everything just comes together. We’ve been compiling research here, and plan on presenting a version of what we want to build to the openbadges-dev list soon.

The flipside of the Federation coin is Discoverability. What interfaces can an issuer give that makes their badge offerings discoverable by indexing systems? A tangent, but related idea – what opened standards are already out there in the world that we should use in the OBi? I started a small list here but am sure it’s only a start. I’d like us make sure we understand the geography of the various groups out there pursuing similar goals. My guess is, things like discoverability will be easier to execute if we borrow from other similar standards, which will also make the OBi more interoperable with existing products and services.

There’s More

We’re getting serious about product marketing, communications, partnerships – all the things that can make or break a large project. We’re going to start issuing our own badges (I know, right? We sort of missed that one. Heh.). We’re going to figure out who we can play with and how. There’s a lot of things we’re going to talk about at camp, I focused mostly on the tech things here. It will be an epic week, we’re all very excited to come back to the real world and share what we figured out together.

A Webmaker User Story in the Wild

As Mark explains, it’s Webmaker Planning Season, which includes writing user stories for where we want to take Thimble, Popcorn Maker and what we build to tie it all together. A really fantastic real world user story appeared over the weekend, courtesy of Notch and his army of followers.

It started with Notch tweeting about something he was experimenting with,

[blackbirdpie url=”https://twitter.com/notch/status/275331530040160256″]

Then he finds a similar experiment from Mr.doob,

[blackbirdpie url=”https://twitter.com/notch/status/275333948412944385″]

And a conversation starts around the code, licensing and aesthetics.

Soon, a fan posted a Youtube video that explores Notch’s original code in detail. Notch moves his example to another community site similar to JSFiddle, but with social bits baked in.

[blackbirdpie url=”https://twitter.com/notch/status/275329867984302081″]

Why’s this like Webmaker?

Notch posts something he’s proud of, gets feedback from his peers (ignoring the fact that Notch is without peer for the purposes of this example), the community dives into his code and explains it to each other (the Youtube video), others remix or build off the original code (Mr.doob, I’m altering history here and pretending that the doob code came after Notch’s original post, artistic historical license).

The whole goal of Webmaker is to bring people together, show off what they’ve learned, help each other learn and get excited about making the web.

That’s cool, so how does Webmaker improve on it?

Right, that’s the big question. Everything you saw above happened today without the involvement of Webmaker, so what are we bringing that will improve it? A few things – in convenient bullet form,

  • Make it explicit – Notch learned something, he shared the learning and others built on top of it. Notch’s experiment, regardless of whether it’s on Thimble or JSFiddle, belongs in a gallery where it’s easy for others to find, share and remix.
  • Make it live beyond today – Twitter tied it all together. Twitter emphasizes real-time, it would be difficult to recreate this chain of events a year from now. It would be even more difficult to recreate the chain if a personality as large as Notch hadn’t initiated it. We need to see this chain of events as a unit without detective work.
  • Build and acknowledge reputation – the video commentator is a bit anonymous in the chain. He did significant work, and will help scores of learners make sense of Notch’s code. He deserves recognition for that work in a way that pushes his career, or gets him reputation in a community. (In short, give that guy a badge)

What should we build?

In this context, what is Webmaker.

  • A series of tools, Thimble and Popcorn Maker lead the way.
  • A gallery, currently in the planning stages, but we’re looking to build much more than a listing of projects. The gallery needs to fit a variety of roles, it should show what you made, what your friends made, and what everyone aspires to make.
  • Social‘y stuff. Take the conversation around a made item to the social network you choose, find better ways to let the work flow back and forth between tools and networks.


How are the Firefox people going to tie all this together? I love Firefox, it’s my browser, but Mozilla isn’t just Firefox. Mozilla has a manifesto. We, Mozilla, are more than the sum of the people who get a Mozilla paycheck. We’re a world spanning community of contributors and zealots that believe working in the open has meaning beyond the products we produce. Mark Surman and Mitchell Baker say that very product has a semi-secret payload – Firefox’s payload was belief in the open web and open source and open standards.

The payload for Webmaker is still being worked out, but my take on it is that we build  together. We learn from each other, we make each other better than what we could be alone. Given that, everything on the web deserves a button that let’s someone else remix and comment on it in whatever way they see fit. The act of creation should encourage more creation, not just consumption and +1’ing.

It’s entirely possible to take all of this and make a product that fulfills basic requirements, and doesn’t worry so much about secret payloads and manifestos – but that would be boring, and unsuccessful. Mozilla doesn’t work in boring, we work on big stuff. The success of Webmaker is a world where the internet is writable, everywhere – and by extension, the world is writable, everywhere.

For more on the make the world writable idea, watch the Mozfest 2012 keynotes.

Building the Platform to Teach the Next Generation of Webmakers

New software products start with a vision, solidify as a product plan, and are fully realized through design and engineering. A few days ago, Mark wrote about the clarified vision of Webmaker, then Erin followed up with what that meant to Webmaker as a product. This post is about that third corner of the triangle, the implementation. I’ll mostly focus on how Webmaker has affected the architecture of Mozilla Foundation projects, which means Jess is on the hook for a post about Webmaker design Jess writes about the design over on her blog.

The rest of this post steps through the key changes we’ve made in how we work, what we work on, and how it all fits together. If you’re interested in contributing to Webmaker as a developer, this is a good overview, you’ll need to jump into the mailing list if you want to start contributing code right way.

I didn’t read any of the prerequisites

If you didn’t read the links above, here’s the story so far — The Mozilla Foundation wants to teach people how to make the web. Mozilla Webmaker: a quick way to make, remix or tweak a webpage or 
video while learning how the web works.. This means that the bulk of projects the Foundation has been working on now fall under the Webmaker mission, Thimble, Popcorn Maker, Webmaker.org are all Webmaker tools. As someone progresses in their mastery of the tools and concepts, they earn Badges which they push to their Backpack, which will one day help them figure out the next thing they should learn. There’s really more to it than that explanation, you should read Erin’s post.

Team Quilting

If you looked at MoFo projects in the beginning of the summer, you’d see teams dedicated to a single project, each with their own platforms, project management tools, testing practices…islands of development that all got along, but mostly worked independent of each other. The teams got a little closer in the June / July push to Thimble, but we had to really squish the islands together to start working on Webmaker.

Lots of organizations would just give up and die at this point. Not MoFo, the developers here are the most easy going, open minded people I’ve ever worked with. This wasn’t an exercise in protecting turf, from the beginning it was about figuring out how to make the large vision that pulled all our products together work. There was negotiation, but every negotiation ended with compromises that each team was happy with. It was way smoother than anyone could have anticipated. These are some great people.

Scary MoFo’s

The biggest decisions we had to make,

  • Server side platforms aren’t uniform, should we push towards a common platform?
  • We track bug’s and features all over the place, do we unify the bug trackers?
  • We manage the projects in the individual bug trackers, how do we express cross team dependencies?

The answers to the above are kind of obvious, not super complicated, but still took a couple of weeks to work out. Picture a montage of lot’s of discussions about tools, failed attempts to organize with the wrong tools, wrong approaches to the right tools, all ending in a giant group high five freeze frame.

Here’s where we ended up,

  • Asana tracks the projects, specifically new features and daily tasks. Asana is where the engineers go to figure out what to work on next, and where the product teams go to figure out what should be built after that. It’s a great tool, really well thought out, and easy to use. We still need to work out the details of what it means to work in the open, and build a community around the development of the products with Asana, but we’re confident we’ll figure it out.
  • The whole development team meets with the whole product team once a week. By the end of the meeting, engineers know what they’re working on until next week’s meeting. Sounds ideal, right? It’s a total lie. It’s not this easy. It’s a bunch of work. Every completed task is a victory worthy of a million high fives.
  • Server side decisions are still up to the individual product teams, but a series of services will decouple the architectures enough that there’s no advantage to unifying the platforms. Which means we’re still proudly a Djangoplaydohpythonnodejsexpressmysqlmongodb shop.

The Webmaker Roadmap in Asana

Services We Need to Build

Once we had the logistics of how we were going to work as a team worked out, we started talking about what exactly we were going to build. This is going to be an on-going conversation over the next couple of months, but we made a few decisions immediately that we’re moving on now.

Single Sign On – If you sign into your account on http://thimble.webmaker.org, you should be signed into http://popcorn.webmaker.org automatically, and you should be able to manage your profile (including seeing what badges you’ve earned) on webmaker.org. Persona manages authentication, but we need a service that authorizes an authenticated user to an application, and keeps the user logged in across apps.

Open Badger – I’ve written about it before, but to issue badges across the applications, we don’t want to duplicate the work of creating and maintaining badge systems.

Unified Publishing – All of our projects publish something, each of them use different storage systems and different security models. If we offer publishing as a service to our tools, we can consolidate backups, consolidate security and make developers feel are warm and special.

Project Database – Before you start working with a tool, you pick a learning project. The projects are described in a couple of different ways. If you want to make a list of available projects across tools, it’s not easy. It should be easy. The same goes for making a list of everything everyone has ever published with the tools, or anything a single user has published with the tools. We need services that make these queries simple.

Make it all look good – Not really a service, but everything needs to look like it’s all one. Jess, Chris and Kate are way on that. They already have a three stage information architecture in mind, and the start of a style guide. We’re still developing new stuff as they figure out the design, so engineering is working really closely with these folks to keep things fast and loose.

Make it work for everyone – Webmakers cross languages, cultures and devices. We need a common way of internationalizing, localizing and making the apps and sites accessible to a variety of devices.

Build it Right

We’re going to bring a lot of new work to Mozfest, some will be in production, some will be there purely to get feedback. It’s going to be an amazing couple of days. MoFo engineers are going to spend the time working with people working with their tools, figuring out how to make them better. MozFest is our next big milestone, it’s also our next big proving ground. We refuse to release bad products, so all of our timelines are based around the question, “how much time is it going to take to put something out that we can all be proud of?” The best way to figure that out is to start working and see how things shape up, if you want to be part of the discussion, join the Webmaker mailing list, or join our weekly community call.

Badger Glue

A few days ago, Mark Surman wrote a blog post, Making tools for webmakers. I love the opening line, “We want everyone to tap into the full creative power of the web.” That’s a great mission. The rest of the post is a review of what we’ve done towards that mission so far, and some direction for the next few months. We’ve been talking about the ideas in the post inside of MoFo for some time now, trying to figure out what’s missing from the tools, what it means to learn on the web, and how to support the teaching goals of the Foundation with the software the Foundation is producing.

I’ve been focused on the idea that we need a central framework to hang all the learning pieces MoFo is producing off of, so that there remains a large amount of flexibility in the ways someone can interact with our tools, but without having to recreate a significant amount of architecture with each new tool feature.

Some constraints (fun-ppurtunities!) I had in mind,

  1. We want lots of data around the effectiveness of the learning.
  2. We want to give people a learning path, but also let them mess around on their own.
  3. Features should speed time to release, not throw up more roadblocks or add to the workload.

A Webmaker Project

The Summer Code Party is using Popcorn Maker and Thimble for most of the online webmaker activities. Both tools have a similar project pattern,

Pick a Project

Both Thimble and Popcorn start picking a project.

Pick a Thimble Project

Pick a Popcorn Maker Project

The metadata carried with the project is different, the assets are different, but the essential thing you’re doing is the same – picking something from a list of options, with information about what you’ll be doing in the project.

Work on the Project

The learner works on the projects inside of the tools.

Inside Thimble

Inside Popcorn Maker

Publish the Results

After the learner finishes the work, they publish. The publish step is similar in both tools, with Popcorn requiring a user account, but no user account for Thimble. The Popcorn team has had a gallery in the works for a while, which will change the way we publish projects, creating a gallery of published projects. Thimble has similar gallery in mind, but only publishes the finished project.

Thimble Publish Dialog

Popcorn Publish Dialog

Modularize all the things!

Given the similarity between the two tools, it makes sense to break out the common parts into modular tools you can mix and match to build future webmaking tools. The two obvious pieces are the project builder, and the gallery tool. In both cases, they’re responsible for either creating or displaying blobs of html & static assets. Both contain tool specific metadata, but they’re not so wildly different that we couldn’t make a base tool to create as much as possible, then extend it to include the tool specific bits. The gallery is the essentially the same thing – display a bunch of output html, plus some static assets.

All that said, it’s not a slam dunk, the details are…the details. There’s a fair amount of work contained in these humble paragraphs, so buyer beware. Let’s focus on the positives – if we’re working off a common codebase, we save time and energy. If we deploy these things as services, then we only need to work through security audit once. The bulk of our time should be focused on making the learning tools awesome, not recreating a gallery or a login system or a whatever. We’ll have all the lego pieces, if we build the sockets right, every day will be an exciting lego land adventure, rather than constant weeding and tending and digging.

OpenBadger, gluing it all together

So – lots of moving parts, everyone wants modular pieces, how do we glue it all together?

Badger Glue Fixes It All

The three parts to any webmaker project – pick, make, publish, match the three pieces of a badge pretty closely – criteria, evidence, assertion. The criteria are the list of things someone needs to do to earn the badge, the evidence is the result of them doing what the criteria asks, and the assertion ties it all together in badge form. The intent of the three pieces is to create a badge, but it’s not strictly necessary. We could use the three pieces as the scratchpads that each stage in the webmaker process looks to understand the context around the step it’s being asked to complete. Each of the three major pieces could be built on top of OpenBadger, like this convenient ASCII drawing illustrates,

 +-------------------+    +--------------------------+ +-------------+
 |                   |    |                          | |             |
 |Create a Project +-|----|-> Do the Project +------>| |Publish      |+--------------->  MASTERY!
 |/ Pick Project     |  + |                      +   | |             |        +
 |                   |  | |                      |   | |             |        |
 +-------------------+  | +--------------------------+ +-------------+        |
                        |                        |                            |
              |         |                        |                            |       |      
              |         v                        v                            v       |
              |                                                                       |
              | Create Criteria URL           Ping Complete              Confirm      |
              |                               Evidence URL Created       Issue Badge  |
              |                                                                       |
              |                                                                       |

Arrows pointing to OpenBadger are either webhook API calls, or posting next-step metadata.

By splitting the direct connections between the pieces, and passing them off to OpenBadger, we can leverage OpenBadger for all sorts of clever analytics – regardless of whether we’re offering a badge for a particular project. That’s an important note – OpenBadger doesn’t need to limit itself to issuing badges, it’s a platform for any sort of learning activity, if we use it in a way that makes sense. OpenBadger isn’t about issuing the sticker at the end of a process, it’s about keeping track of the steps involved with an online learning project.

The most Meta of Metadata

We’re not the only people in wide world web looking to make exchanging education data easy, LRMI is a Creative Commons project to bring common metadata to learning resources. If we use LRMI as a basis for our criteria url’s, and then extend it with tool & display specific information, we’ll be able to take advantage of other LRMI parsing infrastructure (like the Learning Registry).

Next Steps

Over the next week or two, we’ll be discussing the plans for Webmaker tools, and start working on making everything fit together in early August, with a launch of all kinds of new stuff for Mozfest London in November. Between the Thimble, Badges, and Popcorn teams, we have some super smart developers. I’m hoping they tear this blog post apart, rebuild it in a way that makes sense to them, so we can start pounding keyboards in dramatic software development montage sequences that end in high fives, hugs, and exploding fireworks over Big Ben (because we’ll be in London…get it?)

First Round of Planned Backpack UX Improvements

The Mozilla Summer Code Party kicks off at the end of June, most of the work on Thimble (the tool the Open Badges developers were working on during our hiatus from Badge development) is done, so we’re getting ready to get back to Badge development. We’re planning a 2 week sprint around UX improvements in the backpack, this post is a brief explanation of what we’re thinking, along with some wireframes our trusty UX squad ginned up.

The bulk of what we’ll work on this round is improving the badge acceptance workflow.

Your first badge

An area that we’ve had a lot of concern about is the first badge experience, accepting a badge on a site, then pushing it to your backpack, creating the backpack, creating a Persona account, accepting the badge…it’s a lot of steps, plus most of it happens in a lightboxed iFrame modal, which seemed like a good idea, but actually confuses people.

The first big change is to move the dialogue out of a modal, and into its own page. When you choose to push a badge you’ve earned on an issuer site to your backpack, the first dialog is still a lightboxed modal,

Once the user chooses to create a backpack (remember this is their first badge), the next dialog happens in a new window on the backpack site,

There’s some variations to work out, we’ve talked about pushing the first badge to a generic backpack without a user account associated with it, then letting the user know it’s temporary until they create a Persona account, but there’s potential issues there we’re not sure about. Erik, the designer of the above workflow, is going to join the team in a more direct way for this sprint, helping smooth over any design issues that come up as we start implementing.

Next Steps

Two big events are happening in the badging world this weekend, The Ann Arbor Mini Maker Faire and the MOUSE Emoti-con festival. Badges are going to be issued at both events, and we’re going to get a bunch of first hand reports on the Backpack from the events. Anya, the second member of the crack UX squad, is planning on compiling learning from both events into more UX tasks we can tackle in a future sprint.

I’ll be distributing this post to the Open Badges mailing list for comment.

Super Awesome Badge Summer

We’re a third of the way into second quarter, so I wanted to check in with the roadmap and see how we’re performing against the plan. The structure of the development team has changed a bit. Our full time developers Brian and Mike are helping out with Webpagemaker through the end of May, to get it ready for the upcoming Mozilla Foundation Summer Campaign. The move changes the timeline of OpenBadger a bit, but most of that timeline was dictated by OpenBadger’s inclusion in the Summer Campaign. We’ve decided to hold off on badging the first round of the campaign, so that frees the Open Badges development team to help out with Webpagemaker.

That doesn’t mean there won’t be progress on the larger Open Badges Infrastructure this quarter. We’ve brought a few contractors on board to help us with some of our second quarter goals. We also found a great Google Summer of Code student in Matt Ramir. Matt starts working for us this week, he’ll be getting up to speed for a bit, then he’ll be helping us with a bunch of stuff.

What’s the point of the backpack?

That question came up a few times in a few different forms recently. It took me by surprise, probably because I’m so close to the work. My response was something like, “the backpack let’s the badge earner collect badges from multiple sites, and show them in different places.” “Sure, ” they’d respond, “but that’s not obvious when you earn your first badge. Plus, there’s really no place to display badges now. Oh, and login is a mess. If the pop up looks like it’s part of the site you earned the badge on, why do I have to log in a second time to get the badge in my backpack?” I’d stare blankly for a bit, and wish I had a ninja smoke-bomb I could toss to make an escape.

It’s a totally valid list of concerns, all of which we’re taking action on. Here’s the breakdown, in convenient list format,

  1. No place to display badges – For the beta release, we added the ability to create group portfolio pages, but only included a simple tweet button. We released the displayer api, hoping to see some pick up by potential displayers, but we’re caught in a catch-22. Lots of issuers want display options before they push a bunch of people into the backpack, and displayers want issuers before they invest in building their own display widgets. To break us out of that cycle, we’re bringing some folks from the community in to help us build out a series of display tools. We expanded the share widget on the portfolio page to include Facebook, Google Plus, and Twitter. A community member is going to build a nice WordPress plugin, and help us with a Facebook app that will aggregate earned badges on your timeline. We expect to have a lot more display options by the end of May / early June.
  2. Login is a mess – Similar to the displayer issue, login is another catch-22. It’s actually super simple, if you’re already set up with Persona / BrowserID, but as that’s a new project, there isn’t a significant existing userbase. Rather than just give up and offer a huge number of login options, we’re working on streamlining the process. We contracted with two UX people, one, Anya from our community, and a second, Erik Kraft, with an extensive portfolio of education sites. Anya has experienced the login issues first hand while building two badge systems, one at the University of Michigan, and another for the Michigan Maker Faire. Both Anya and Erik have ideas about fixing the issues, and we should be able to free up enough time to make a change there by mid-June.
  3. Backpack value story – When you earn that first badge, we need  to explain to the earner what the backpack is, and what it’s going to do for them. In addition to the UX issues and display issues above, we need to tell a story inside the backpack workflow, a screencast explaining what’s going on, what the backpack is, and how it will help the earner learn more, and gain more from the learning. We’re going to start small here, I’m going to make a few screencasts, and we’re going to figure out a reasonable way to work them into the workflow. I’ll be done with the videos in the next few weeks, and have them in the first-badge workflow by the end of the month.


A big goal of the Open Badges project is to create a platform that anyone can use, regardless of device or language. We’re going to make some progress on that goal this quarter, with Matt (the GSoC student) helping us make the backpack and openbadges.org site Section 508 compliant. We’re also going to work on incorporating Mozilla’s localization standards into the backpack and site. Both projects will go beyond the second quarter, but this is when we’ll start making some progress.

We also want badge earners to be able to use their badges on whatever device they want to use, so we’re going to work with some reactive design experts to figure out easy ways to support multiple devices without having to support a ton of individual code forks. The discussions are strategic at this point, so it’s not clear yet what we’ll be offering, or the timelines we’ll be offering them in. I’ll update the roadmap when we know more.

Endorsement, public key infrastructure, federated backpacks

It’s not really fair to smoosh three big topics into a single heading. Beyond the words though, we don’t have a solid plan for any of the three features above. By the end of the second quarter, we want to have paper versions of all the above. They’re topics we’ve thrown around for a while now, if they’re not obvious, some definitions,

  1. Endorsement is the ability for one badge issuing organization to endorse another organization’s badges. Endorsement is a significant step towards a badge ‘economy’, where badges have objective worth relative to one another. A badge with multiple endorsements will probably be ‘worth’ more than a badge without the endorsements.
  2. Public key infrastructure will allow issuers to sign a badge cryptographically. Badge signing will allow the issuers an extra level of security, but will also give the earners truly portable badges, even if the issuer goes away, or stops hosting the badge’s assertion file.
  3. Federated backpacks are the holy grail of the open badges infrastructure. Mozilla’s hosted backpack can’t be the only backpack out there, we want everyone to create and host backpacks. We want them discoverable though, which complicates things. We need a system for making all the backpacks in the world act like one giant backpack for the purposes of aggregation and discovery. This is a tricky one, but it will be super awesome when we’re done with it. Super awesome.

Super Awesome Summer

Given all the above, this summer is shaping up to be…super…awesome. I’ll write about projects as they complete, and will be speaking at a few conferences this summer:

Post Flourish Badge Talk Thinking

Flourish 2012 Talk photo by @pdp7

The Flourish talk went well, at least that’s the what the feedback was.  It felt rambly to me, probably because I was having a hard time pinning down what I wanted to talk about.  Badges is a big topic, it’s a not-trivial technical implementation, and it’s a big fat topic in education circles.  I tried smooshing the two things together, a bit about badges role in education (which I’m totally unqualified to do, but I’ve never let that stop me in the past), a bit about where I thought people could fit badges into their own projects, and finally an overview of how to actually issue and earn an OBI compliant badge.

This was the first time I’d talked publicly about OpenBadges, and one of the first times anyone from the OpenBadges team has presented to a technical audience and not an education audience.  It was a good trial of the material.  Luckily, despite my jumbled thoughts, the core of the OpenBadges resonated with people, so that’s positive.  I’m going to have a second chance to present to a technical audience this Tuesday (4/10/12) at Groupon for GeekFest.  Be sure to RSVP if you’re interested in the talk.  I’m going to edit my talk based on stuff I learned at Flourish, a rough idea of the changes are here in convenient bullet form

  • The technical material should go up front, I’m going to drop the speculative section to the tail of the talk, if not drop it entirely.  It didn’t work the way I thought it would.
  • Define “digital” badges right away, they’re not as obvious as I thought they were.
  • The crowd anticipated the roadmap, including cryptographically signed badges, issuer endorsement of other issuer badges (creating a web of trust), lots of stuff. Which means we’re on the right track.  I should put in a slide of the total planned functionality relatively early in the talk, and then check things off that are complete.
  • Not be surprised by education questions, I think I mentally prepared for lots of implementation questions, but it turns out that a technical crowd still has opinions on badges as learning motivator.
  • Stop trying to be funny – I violated an old improv rule, I tried to be funny in a talk.  It totally failed.  I’m funny when I try not to be funny…when I try to be funny…it fails.  It’s a paradox.

If you were at the talk, and have any other feedback, I’d love to hear it.  Also, if you’re interested in diving deeper into the theory of badges, Erin Knight, the director of learning at the Mozilla Foundation, wrote a great blog post that acts as a reasonable primer on the space.  She answers a lot of the questions that came up on Saturday, without hearing any of them, she’s clearly psychic.

Badges – Less Yack, More Hack

This post is the basis for a talk I’ll be giving at the 2012 Flourish conference on March 31st

I’ve covered a bit of what a OBI compliant badge is, technically, but wanted to speculate a bit on where badges could start appearing. There’s a lot of theorization on badges in higher education, and badges for learning, but I want to propose something else entirely, something more geek-centric.

The Problem

I’ve spent a significant amount of my life in user group meetings, open source conferences, and more recently – playing Pathfinder (an OGL D&D 3.5 edition variant). In each of those three places, you spend some percentage of your interaction time explaining who you are, and trying to figure out where you fit in with the overall ecosystem, or team dynamic.

We do it for a few reasons, the above board – store this information away so I know who to talk to in the future when I have a particular problem, or do I want to be pals with this person, and the less-above-board – is this other person more awesome than me? It’s not all warm and fuzzy either, in a hack-sprint situation at a conference, you have to figure out who’s going to work on what, and at what level. In a dungeon raid, you need to know who can pick pockets, and who can heal you when you get a sword boo boo.

Yack Yack Yack

All this takes time, it’s a lot of yacking, not a lot of hacking. Pathfinder speeds it up a bit. At table games, each player brings a table “tent” (a placard?) that gives their character name, level and class. So, at a glance, you know the player is a Dwarf fighter, and is good to get behind in a fight. The tents aren’t the end of the discussion by any means, they’re just short hand so we can quickly get to the meat of the team. There’s usually some tongue in cheek RPG backstory stuff, maybe some general strategizing, whatever – the point is, we didn’t have to waste 10 minutes going in a circle explaining the basics, it’s right there in front of everyone. Now we can get to the (sword) hacking faster.

The Open Badges spec provides a few things,

1) Criteria – what the badge means
2) Attribution – who earned the badge, who awarded the badge
3) Verifiability – is all this for real?

Pathfinder does all this too, including verifiability. All players are given a character id, so that anyone can look up a given character and verify they’ve earned their rank, including a papertrail. It’s pretty neat, here’s one of mine. Because my character’s background is verifiable, the folks at my table don’t need to spend a bunch of thought cycles trying to figure out if I know what I’m doing. They can see it right there, I’ve been in the shit man! I’m a Dwarf that knows what’s what!

Pathfinder Table Tents

Table Tents, anonymity provided by the pink unicorn.

Towards Hack

There are companies forming around something I think of as resumes+. LinkedIn is an obvious first example, their additions of skills to online resumes makes sense. The reverse search ability of them is cool too, so if you’re looking to fill a job, it makes it pretty easy to find someone who knows “Python”.

What about levels into Python though, what about fine-grained stuff like, “knows the guts of the Django ORM?” That’s a real skill, but not what LinkedIn wants to know. There’s also the continuing problem of verifiability. There’s some alternatives, like CoderWall that pull directly from your Github account to decide the kinds of stuff you’ve done. It leans towards the show-off side of things, but could easily remove friction to putting together a team.

If you extend the CoderWall example to physical hardware hacking, you could build a site that certifies competency on a bunch of different tools. That way, if you’re certified on a laser cutter in Chicago, you can use the same machine in Milwaukee and San Francisco. At some high level of achievement with the cutter, you could certify other folks. Reverse lookup of the certification could make it easy to figure out who could help set up a newly purchased cutter. All of this can be done with emails and phone calls and tweets, but it takes time. Time that could be spent using the cutter, not verifying your ability to use the cutter.

Why OBI?

Like I’ve said before, figuring out what to badge is the hard part. Determining if someone is actually able to use a laser cutter is serious. All of that sort of stuff is best left to those that know, and best initiated by trusted organizations. The Open Badge Infrastructure doesn’t solve the problem of creating badges, it solves the problems of multiple badges living together.

Let’s say you’re a certified laser cutter user, but you’re also a Django ORM expert, and maybe even a 5th level dwarf. Three separate silos are badging you, Pumping Station One, CoderWall, and Paizo (objection – speculation, these badges don’t exist, don’t get sad, give it time…they’ll come around). Each badge lives in its respective silo, and you’ll need to direct someone to all three places to land that amazing laser cutting / orm hacking / dwarf fighter gig you’ve dreamed of.

That’s the guts of the OBI, make each badge portable, and push them all into a backpack that you have complete control of. You’re also able to set the privacy settings, so if you’re not comfortable letting your boss know what a kick-ass axe wielding dwarf you are, you don’t need to. That’s your business.


The unofficial tagline for Open Badges is, “enabling lifelong learning.” I love that mission, but think it itself sounds too formal. The unofficial mission statement of the Mozilla Foundation (undocumented) is “less yack, more hack.” If you see badges as a way to promote hacking, rather than constantly having to prove and reprove yourself with the repetitive yackery, then that’s right too.

Further Furthermore

There’s two counter arguments here, things that people say, that I agree with, and am actively trying to work around.

1) People are unique snowflakes, badges pigeon hole them – yeah, totally, people are unique snowflakes, and you should take the time necessary to explore a person’s unique crystalline structure. In the meantime, there’s a castle to storm, and we need a good necromancer…let’s save the getting to know you for later.

2) Certifications suck – yeah, totally. There’s a whole market of semi-fraudulent certifications out there. As a person-who-hires-people, I’ve never used professional certifications as a significant hiring factor. However, I’ve definitely used Github, code samples, and general internet-profile-google-stalking of someone as a hiring factor. Badges codify some of what we’re already doing. And since anyone can make them, it seems like there’s less incentive to build bullshit ones, or at least, bullshit badges will be quickly supplanted by not-bullshit badges. Time will tell.

Earn a badge, issue a badge

[blackbirdpie url=”https://twitter.com/#!/raster/status/182658137621405699″]

Good question.  The hardest part is deciding what kind of badges you want to issue, the rest is straightforward.  I’ll explain.

Earn a badge!

Let’s start by earning a badge on openbadges.org. Click on the big blue “Get Started” button on the front page and you’re given an easy quiz, testing your Badges 101 level knowledge,

The Start of the Badges 101 Quiz

After you finish the quiz, you get a fancy badge, which you have the option of sending to your backpack,

You earned the Badges 101 Badge

When you send it to your backpack, you’re asked to sign in. The sign in is through Mozilla Persona (aka BrowserId), so this is also a great opportunity to set up a Persona account if you haven’t already.

Logging into your Open Badges Backpack

After you’re done adding the badge to your Backpack you can share your badge out through a share page like mine.

What’s that badge, really?

Badges can represent all kinds of things, completing trivial quizzes, or months of study, regardless of what you had to do to earn them, the actual guts of a OBI compliant badge (a badge that you can push into your Backpack) is three things,

  1. A badge graphic
  2. A badge criteria url
  3. and a badge assertion url

A badge graphic

The badge graphic is a square PNG. That’s it. Here’s the badge graphic for the Badges 101 badge,

The graphic isn’t specific to the person (though it could be) and it doesn’t have any information in it that describes the badge (though it could, via Badge Baking, a service that embeds the assertion information in the badge to make it truly portable).

A criteria url

The content of this url describes what I had to do to earn the badge. For the Badges 101 badge, we cheated a bit and just said that the criteria was the Open Badges homepage. For now, the criteria url is any valid url, in the near future we’re going to release a spec for machine readable criteria url’s. The issuer hosts the document, which proves that the badge came from the issuer.

An assertion url

The assertion is the specific document that ties a badge to a Persona id. Just like the criteria, the issuer hosts this document. When I earned the Badges 101 badge, Open Badges (the issuer) created an assertion url, which you can see here.


The above example is using a slightly older version of assertions which include the Persona ID in plain text, we just rolled out the salted hashes as identifiers (salty hashes! delicious!). When we update the Badges 101 badge to assert a hashed ID, I’ll update this post to show the new method.

The assertion ties all the pieces together, it’s hosted on the issuers site – so you know they know about it, it has an ID associated with a Persona account – so you know it belongs to the person that earned it, and it links to the criteria – so you know what they had to do to get it. Oh, and it has a picture, so it looks cool too.

Push the badge to the backpack

Once you, the issuer, have created the two generic requirements (a picture and a criteria url), and the learner has shown they’ve earned the badge (up to the issuer how this accomplished), the issuer creates the assertion url, and then passes this whole mess of stuff to the Backpack via the Issuer API.

The Issuer API is a Javascript API, which pulls a dialogue from the Backpack. The Open Badges Infrastructure is for the learner, we don’t want any badges pushed into their backpack without explicit approval, we want the learner to see which badge is going in, why, and approve it.

Including the API on your site is a JS include, which then gives you access to the all important OpenBadges module.


What the OBI isn’t

From all the above, you might have picked up on something about the Mozilla Open Badges Infrastructure isn’t, which sometimes confuses people. The OBI isn’t a badge issuing platform. Issuers need a system that assesses learning and awards badges within their own site. What the  OBI is, is a lightweight specification that allows for learners to collect badges from multiple issuers.

However, if you look at the way Open Badges.org is issuing badges, you’ll see – it’s not that complicated. Atul built a nice JS assertion creator which hosts the assertion on Amazon S3, so nothing about the Badges 101 badge is server side, it’s entirely on the client.

Oh, and…

Several heavyweight platforms for badge issuing are in development, some of which will be open sourced. There’s room for a light issuer, similar to Atul’s assertion creator, but with a bit more refinement. If you’re looking for a way to contribute to the project, that would be a great start. Otherwise, if you’re interested in the OBI bits, and want to lend a hand, we’re really interested in finding collaborators.

If you’re looking to create OBI compliant badges, now’s a great time to get started. Beta is launching at the end of this month, so things will be pretty stable by then. Jump into the Open Badges Google Group for discussion, or come talk to us on IRC at irc.mozilla.org #badges.