BadgeKit Now!

This is the first in a two part series on Badgekit, the new badge issuing platform from the Mozilla Open Badges team. This post talks about the current suite of issuing tools we’ve built, the next post will talk about where we’re headed.

Badgekit is in active development. We’ve written about it a bunch, Erin, Sunny and Jess have all written introductions to it from different angles. There is a release in the future called Badgekit, that will do all the things that the Badgekite site talks about, but there’s also Badgekit-right-now, a collection of tools that the Open Badges team has used to launch the Chicago Summer of Learning, Connected Educators Month Badges, Open Badges Badges, Mozilla Summit Badges and MozFest 2013 Badges.

This post will explain how you can cobble together your own version of what will become Badgekit now. A follow-up post will explain the improvements we have planned, which will make Badgekit different from the collection of tools we have today.

Conventions

There’s a few things in common in the apps that I’m going to write about here, in no particular order -

  • Node.js – everything we build is in Javascript with Node.js on the server.
  • 12 factor – We’re bought into Heroku’s 12 factor application architecture. We follow it pretty closely. That means that most of these apps use environment variables for configuration and don’t write to the filesystem for anything.
  • Heroku – for most of our production applications, we run in custom AWS EC2 instances, but given the above 12 factor point, it’s entirely possible to run a complete Badgekit-now system in Heroku.
  • Datastores – there isn’t much consistency in datastores, we use MySQL in some places, MongoDB in others, Memecache here and there, Redis. There’s very little consistency (which will change as we move towards real-Badgekit).
  • Lot’s of API’s and Webhooks – the apps all have big healthy API’s and do lot’s of inter-app communication by Webhook callback.
  • One instance per ‘client’ – every client of Badgekit runs their own instance of all the tools. That made it easy for us to punt on serious user authorization. If you can log in, chances are you can do just about everything.
  • Design – we have awesome designed front ends (thanks Jess & co.!) but slightly clunky developer designed admin panels.

Open Badger

Open Badger is the biggest application in the current Badgekit implementation. It handles the core functionality of a badging system, defining badges, issuing them, tracking whether someone has accepted an issued badge, creating claim codes for in-real-life badging, it’s a big collection of tools that accumulated over time. Almost everything is available via the API. A single instance of Open Badger will manage a full badge system with multiple issuers. The model fit the Chicago Summer of Learning, which had issuers, who had programs, which had badges.

You can build a badge inside of Open Badger, define criteria to earn the badge using a bulleted list of yes / no questions the assessment tool uses to evaluate the application, and upload a badge image. You can’t design the visual image for the badge, which we realized was a limitation on CSOL. So we built Badge-Studio (try it out here) to visually design the badge. (Badge Studio is another tool that will be greatly improved for the release of Badgekit).

The best thing to come out of Open Badger is the API. It’s full featured, makes it easy to list badges, easy to issue, and served us well in several installations. It proved to us that a solid API is worth the effort (I mean, we were already pretty bought in, but it reinforced the idea). You can see an example API call here – a list of badges available for MozFest 2013.

Aestimia

First of all – it’s Latin for “assessment.” I named it, for better or for worse, in a fit of Latin nostalgia (does that exist?). Aestimia is the thinnest possible assessment platform. When a user applies for a badge, the client site sends a package to Aestimia that includes the learners submitted evidence and a criteria listing it grabs from Open Badger. Aestimia returns an application id, then calls a webhook url the client site defines with any updates to the application. When an evaluator evaluates the application, Aestimia tells the client site about the changed state. The client site then chooses what to do with that information, either issuing a badge and emailing the learner about their new badge, or emailing the learner that the badge wasn’t awarded.

Because Aestimia only cares about criteria and evidence, it doesn’t necessarily need to end in the awarding of a badge, it could be used for assessment for any sort of situation. It’s entirely possible to build a system on top of Aestimia and Open Badger where a user does several assessed activities before a badge is awarded. Open Badger doesn’t understand an activity outside of a badge, so you’d have to hack it a bit to store criteria, and you’d need to build in some logic (maybe with tags?) to define a ‘path’ but – you could do it. Hacking aside, all those things will be key features of Badgekit, we have lots of plans!

Backpack

One interesting sidenote from CSOL – because the Open Badges infrastructure doesn’t yet support federated backpacks, and because the current Mozilla Backpack can’t host badges for under 13 year olds, we ‘faked’ backpack functionality by creating an Open Badger API authenticated endpoint that provided a list of badges issued to a particular email id. In installations where users under 13 aren’t an audience, we push the badges to the Mozilla Backpack as a way of ‘accepting’ the badge.

All badge issuers need a place to store badges, I’ll write more about our plans here in the next Badgekit post, but for now – federation will fundamentally change how we think about backpacks.

Client sites

The CSOL client site was heavy compared to Connected Educators Month and Open Badges Badges. Largely because it had to handle user accounts and parent / guardian approval workflow for learners under 13. Subsequent sites were stateless with limited server code, feeding off the Open Badger and Aestimia API’s. That architecture works well for us, we expect continuing with it as much as possible as Badgekit develops.

How it all flows together

Phew, that was a lot of words. Let’s make some (low tech ASCII) pictures explain how all these pieces fit together.

Here’s all the players,

                                                   +--------------+
                                                   |              |
                                                   |              |
                                                   |  E-mail      |
                                                   |  Service     |
                                                   |              |
         +--------------------------------------+  +--------------+
         |   A badging site                     |
         |                                      |
         +--------------------------------------+  +--------------+
                                                   |              |
                                                   |              |
                                                   | Backpack     |
         +---------------+      +---------------+  |              |
         |               |      |               |  |              |
         |               |      |               |  +--------------+
         |  Open Badger  |      | Aestimia      |
         |               |      |               |
         |               |      |               |
         +---------------+      +---------------+

Everyone’s there, the overarching site, Open Badger, Aestimia, the Backpack and a e-mail service of your choice.

First of all, a learner visits a badge listing site, the badging site requests a list from Open Badger and shows them to the user,

                                                   +--------------+
                                                   |              |
                                                   |              |
                                                   |  E-mail      |
                                                   |  Service     |
                                                   |              |
         +--------------------------------------+  +--------------+
         |   A badging site                     |
         |                                      |
         +--------------------------------------+  +--------------+
                 ^                                 |              |
                 |                                 |              |
                 +                                 | Backpack     |
         +---------------+      +---------------+  |              |
         |               |      |               |  |              |
         |               |      |               |  +--------------+
         |  Open Badger  |      | Aestimia      |
         |               |      |               |
         |               |      |               |
         +---------------+      +---------------+

The user picks a badge, and submits evidence that they’ve completed the badge. The evidence, plus the evaluation criteria for the badge (from Open Badger) are sent to Aestimia. After the evaluator evaluates the evidence, Aestimia calls back to the badging site to let them know they finished the evaluation. (see all the new arrows?)

                                                   +--------------+
                                                   |              |
                                                   |              |
                                                   |  E-mail      |
                                                   |  Service     |
                                                   |              |
         +--------------------------------------+  +--------------+
         |   A badging site                     |
         |                                      |
         +--------------------------------------+  +--------------+
                 ^                     +  ^        |              |
                 |                     |  |        |              |
                 +                     v  +        | Backpack     |
         +---------------+      +---------------+  |              |
         |               |      |               |  |              |
         |               |      |               |  +--------------+
         |  Open Badger  |      | Aestimia      |
         |               |      |               |
         |               |      |               |
         +---------------+      +---------------+

Let’s say the learner got the badge! Hurray for learning! The client site then calls to Open Badger to issue the badge, most likely by asking Open Badger for a claim code embedded url that the site can email to the user. Once the site has that link, it sends it to the user via the email service.

                                                   +--------------+
                                                   |              |
                                                   |              |
                                            +----> |  E-mail      |
                                            |      |  Service     |
                                            +      |              |
         +--------------------------------------+  +--------------+
         |   A badging site                     |
         |                                      |
         +--------------------------------------+  +--------------+
              +  ^                                 |              |
              |  |                                 |              |
              v  +                                 | Backpack     |
         +---------------+      +---------------+  |              |
         |               |      |               |  |              |
         |               |      |               |  +--------------+
         |  Open Badger  |      | Aestimia      |
         |               |      |               |
         |               |      |               |
         +---------------+      +---------------+

The learner gets the email, clicks on the link, which takes them back to the site to accept the badge and push it to their backpack.

                  +-----------------+
                  |                 |              +--------------+
                  | An email        |              |              |
                  |                 |              |              |
                  +-----------------+              |  E-mail      |
                          +                        |  Service     |
                          v                        |              |
         +--------------------------------------+  +--------------+
         |   A badging site                     |
         |                                      |
         +--------------------------------------+  +--------------+
                                +                  |              |
                                +----------------->|              |
                                                   | Backpack     |
         +---------------+      +---------------+  |              |
         |               |      |               |  |              |
         |               |      |               |  +--------------+
         |  Open Badger  |      | Aestimia      |
         |               |      |               |
         |               |      |               |
         +---------------+      +---------------+

And that’s it! Easy, right? Not really. It’s actually pretty complicated. There are multiple variations to the above flow, and it’s not even clear that we want to make the learner jump through the claim code acceptance flow – most learners just want their badge! Plus, each of those boxes is a separate piece of hosted software. This isn’t a setup for the feint of heart.

Which is really the point of Badgekit – all those services make sense. They’re the right thing, so what can we do to make it easy to use them? Plus – we’re not the only tool provider, maybe there’s a better assessment tool out there, maybe an issuer uses another issuing platform, but wants to use Aestimia. Badgekit will make hosting all these things seamless, without having to know the difference between Open Badger, Aestimia and whatever else, and give an issuer choice in how the pieces of their program work together. To paraphrase some advertising campaign somewhere – issuers should worry about teaching and making cool badges, not about how their badge system moves bits of data around.

[editing help from Sunny and Brian, thanks!]

  • mrboll

    Thank you so much for moving this forward. This will really help us out at my school!

  • DPrice

    It’s great to see the progress here McAvoy! Awesome! As an educator, I cannot tell you how exciting this project is. Badges….I LOVE STINKING BADGES!

  • Pingback: BadgeKit Future! | Lonely Lion