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,

   ASSESSMENT BUILDER /
   WEBMAKER.ORG             THIMBLE / POPCORN MAKER      GALLERY
 +-------------------+    +--------------------------+ +-------------+
 |                   |    |                          | |             |
 |Create a Project +-|----|-> Do the Project +------>| |Publish      |+--------------->  MASTERY!
 |/ Pick Project     |  + |                      +   | |             |        +
 |                   |  | |                      |   | |             |        |
 +-------------------+  | +--------------------------+ +-------------+        |
                        |                        |                            |
              +-----------------------------------------------------------------------+
              |         |                        |                            |       |      
              |         v                        v                            v       |
              |                                                                       |
              | Create Criteria URL           Ping Complete              Confirm      |
              |                               Evidence URL Created       Issue Badge  |
              |                                                                       |
              |                                                                       |
              +-----------------------------------------------------------------------+
                                                                                OPENBADGER

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?)


  • brettgaylor

    Great post, Chris  – excited that this conversation has started.

    For the badge n00bs like myself, I’m curious about a few things:
    1) can you say more about how “pick a project” is similar to the “criteria” requirement for badges? 
    1a) this is what I think you mean from a popcorn context- we have a project that asks someone to make a newscast using a few plugins, and provides some starter content to do so  – is what you saying that the criteria is “webmaker must combine plugins x and y”?
    2) In lay terms, what does “create criteria URL” mean?  Its a static page that defines a set of hoops (in machine readable language) that a webmaker must jump through before we can issue a badge?

  • http://www.lonelylion.com Chris McAvoy

    Yeah, it’s less about picking and more about displaying a project that could be picked. In both Popcorn and Thimble, we’re using a handful of metadata items that describe the project. Title, what to work on…basic stuff. I’m suggesting we normalize the fields we use to describe the project generally, and supplement them with the tool specific data where necessary. That data can be used as a criteria url for a badge. If we normalize based on the OBI spec & LRMI, we get a few things 1) everyone is using the same standard, 2) We might be able to share things outside of Mozilla 3) we can build generic webmaker project picking across tools (so a popcorn maker project can sit next to a thimble project if we want) and 4) we can issue a badge at the end of the process (again, if we want – not a requirement).

    tl;dr – we need a standard way to describe webmaker projects that’s tool-agnostic, the OBI just happened to have a nice place to put that.

  • OpenMatt

    I love the thinking here, Chris. I’d be curious to know a little more about the time horizon we’re thinking about. In particular: when do we want to award the *first* badge to someone for making a Webmaker project? (Thimble, Popcorn, etc.) September? MozFest?

    For me, the biggest obstacles for our OpenBadges work in general is: *real world implementations.* The “take the badges quiz and earn your first badge” was an interesting reference implementation, that helped you see how the backpack works. But the first time someone uses our software to display *real* skills — which it sounds like you’re describing — will be a major milestone.

    It’s not totally clear to me whether a) that’s happened already (and I just don’t know about it), or b) if it hasn’t happened yet, when are we thinking it will happen?

    Contemplating “theoretical badges” for our work is still hard for me. Especially at the level of: “this is the glue that will bring everything together!” Before I can understand the full implications of meta awesome Badger Glue, I kinda need to see *one* real person with *one* real badge.

    I’m also asking about timelines in part so I can think about communications for September, and beyond that MozFest. I know there’s probably interest in tying our badges work into “back to school” type stories in September, plus the big SCP wrap-up Sep 23. And of course beyond that: the hurricane of awesomeness that is MozFest! :) Want to make sure press and the wider world know what’s cookin’.

  • http://www.lonelylion.com Chris McAvoy

    Hey Matt,

    For Mozilla – badges are still theoretical, but for a handful of other organizations (mostly DML winners) they’re in full swing. We waiting on a production change to get actual data around the current state of badge issuing in the OBI, I’ll blog about it when we have the data.

    Timeline wise, we’re going to try and issue badges at the end of the summer campaign, but we’re _absolutely_ going to issue badges around Mozfest.
    What I wrote here is sort of large systems thinking, I doubt we’ll have a perfect system by Mozfest, but what I’m hoping is that we’ll use this post (and the resulting discussion) as a large framework to start fitting tools into. So that we avoid a bunch of effort that doesn’t fit into a larger planned architecture.

    Once we get through all this theory discussion, we’ll be able to attach some hard deadlines.

    Thanks for at least acknowledging the awesomeness of badger glue.

  • epilepticrabbit

    Ditto on loving the thinking. There are several things here that I too have been thinking about (though from the content angle rather than the tool angle). Modularity, customizable, variable…I don’t feel the need to be long winded about it, in both contexts I wholeheartedly agree (Hive Five!)

    I’m really interested in your idea to use the LRMI – Am I understanding this correctly? With a competency object we can use metadata to mark the location of the longer description/full website that describes the learning objective and pedagogy behind the webmaker project? In your ASCII the “Create Criteria URL” is where the learner chooses a project, right? I’m not sure that our project pages hold enough information to make proving the “real world” implications possible. Can the criteria and the user entry point be different? And if so, how would the criteria URL be created? Manually each time a new project is created?

    Explaining WTF I’m talking about with a use case:

    A learner earns an Intro to Web Native Film badge. The learner displays that badge on her portfolio website. The learner applies for an internship and sends her website with badges as a part of her application/resume. The employer sees the badges and clicks to see what the this badge actually means (ie view the criteria).

    Does the employer get taken to or shown the Storycamp Intro to Web Native Film URL (where the learner began her learning, ie user facing), or a specifically created page that contains information on the pedagogy, learning objectives, etc?

    For the record, I’m also a n00b on the technology behind badges. Totally understand the concept and awesomeness of badges, but don’t know anything about the metadata piece and how that is written to adhere to the sorts of expectations one might find in the “real world”. Also, in terms of wide spread adoption, I wonder how much metadata connected to our badges is enough.

    Despite my murky understanding on the criteria piece of the puzzle, I think beginning this particular conversation is a huge step in the right direction. Kudos!

  • Erin

    Good stuff Chris. I love the project builder tool – this is exactly the kind of thing that could help lower the barrier to entry for community contribution to the content (and we should keep that in mind when designing to make sure its a simple and straightforward as possible).

    I still think there are quite a lot of details to work out – building a Thimble project, for example, is WAY different than building a DIY project, etc. But would be awesome to figure out how to make that work. As you and I talked about, I don’t think we can get there in time to have initial badges for MozFest, but its good to be thinking about this upfront.

    Also, huge +1 to a shared gallery. Mark said the other day that the product from the external point of view, is the projects. So someone should be able to come to webmaker.org, pick a project regardless of the tool, then be directed to the tool required to support that project, and then publish to a common space. One MoFo! Unite!

    (Love the pick/make/publish == criteria/evidence/assertion analogy…food for thought)

  • http://www.lonelylion.com Chris McAvoy

     Lot’s to respond to here…I’m going to give it my best shot,

    “I’m really interested in your idea to use the LRMI – Am I understanding
    this correctly? With a competency object we can use metadata to mark the
    location of the longer description/full website that describes the
    learning objective and pedagogy behind the webmaker project? In your
    ASCII the “Create Criteria URL” is where the learner chooses a project,
    right? I’m not sure that our project pages hold enough information to
    make proving the “real world” implications possible. Can the criteria
    and the user entry point be different? And if so, how would the criteria
    URL be created? Manually each time a new project is created?”

    I need to write a follow-up, because this has come up a few times. The criteria page is free-form, but should have some sort of machine readability baked in. LRMI is a good choice, because then non-Moz things can read it. In my diagram, the Criteria URL is what’s created when the project designer creates a possible project. The Criteria URL would be hosted on OpenBadger, and contain LRMI data, additional copy describing the project, project assets (images, etc), tool specific meta-data, and the core project file (in Thimble’s case the actual html you’re going to edit). Because the criteria pages will span tools, we can build project choosing galleries that read from OpenBadger, and let learners choose the project they want to do. Think of it as a big repository of possible projects, then we choose how to display the choices on a per-site basis.

    “A learner earns an Intro to Web Native Film badge. The learner
    displays that badge on her portfolio website. The learner applies for an
    internship and sends her website with badges as a part of her
    application/resume. The employer sees the badges and clicks to see what
    the this badge actually means (ie view the criteria).

    Does the employer get taken to or shown the Storycamp Intro to Web
    Native Film URL (where the learner began her learning, ie user facing),
    or a specifically created page that contains information on the
    pedagogy, learning objectives, etc?”

    The employer is taken to a portfolio page for that badge – which includes links to the criteria page (a description of the work that needs to be done to earn the badge), an evidence page (the results of the learner’s work), and an assertion that proves the learner did the work they said they did. It’s sort of a one-stop shop for displaying the work, and also verifying it. There’s a lot of possible variation in how the information is displayed.

    “Despite my murky understanding on the criteria piece of the puzzle, I
    think beginning this particular conversation is a huge step in the right
    direction. Kudos!”

    HIGH FIVES ALL AROUND!

  • http://www.lonelylion.com Chris McAvoy

     “I still think there are quite a lot of details to work out” – yeah, totally agreed. I’d really like to see us get a reasonable shared idea of the ULTIMATE LEARNING TOOL then figure out which pieces we can build now, and which are built later, rather than pre-scope-narrowing without at least considering the potential collective awesomeness of our skillz.