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

Trying http://t.co/BR0KhDqd: http://t.co/IMoz4b9K

December 2, 2012 2:12 pm via webReplyRetweetFavorite

@notch

Markus Persson

Then he finds a similar experiment from Mr.doob,

If you liked that, @mrdoob made a Minecraft type renderer using WebGL: http://t.co/GUjpiyC9

December 2, 2012 2:21 pm via webReplyRetweetFavorite

@notch

Markus Persson

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.

Spent most of today learning new stuff. Ported Minecraft4k. Code is awful due to the nature of the project, but here: http://t.co/ZQQ8lsRj

December 2, 2012 2:05 pm via webReplyRetweetFavorite

@notch

Markus Persson

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.

Mozilla?

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.

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.

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

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.

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.

Accessibility

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:

• May 19th @ Chicago Code Camp
• Edited to add: July 20th @ OSCON
• August 15th @ That Conference in the Wisconsin Dells

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.

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!

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.

Furthermore

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.

@lmorchard @plural @chmcavoy so how do we get @adafruit and @OpenBadges connected?

March 21, 2012 8:41 pm via webReplyRetweetFavorite

@raster

Pete Prodoehl

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.

The memorial also had a more detailed record of Isham’s railroad career, which I’ll add to the Wikipedia entry soon.  It also gave the names of his three sons (I only knew one) and his wife.  I found the name of his wife in census records, but not his son’s beyond Col. Randolph (who the memorial says was a Major?)  It also says that Isham helped to organize a regiment of engineers during World War One, and quotes the conclusion of a speech he gave them before their departure for Europe.  Though not poetry, it speaks to the poetic character of the man,

One last quote from the piece, not from Isham, but from the memorial writer, suggesting that a volume of Randolph’s writing, including his poetry, should be published.

I haven’t collected enough of his writing to “gather and edit a volume,” but I have pulled a bit together over the course of the last year, so – I guess I’m the guy that’s doing what this author asked for, just a hundred years later than he expected.

@chmcavoy what @OpenBadges would Isham have collected?

March 6, 2012 5:16 pm via Twitter for AndroidReplyRetweetFavorite

@plural

jason gessner

My pal @plural (Jason Gessner)’s funny tweet inspired a second (shorter) post explaining badges in terms of Isham Randolph.  (for those just joining, Isham Randolph was the chief engineer of the Chicago Sanitary and Ship Canal, the canal that reversed the flow of the Chicago River, I’m sort of obsessed with him.)

So, Jason, in response to your tweet – Isham Randolph is an excellent example of an entrepreneurial learner who would have benefited a great deal from OpenBadges.  Here, in convenient bullet format, I present my argument:

• Isham began his career by learning carpentry from a man (whom he owned, sadly, he was a slave owner) on his plantation, he was not formally apprenticed or trained. citations
• Isham worked his way up from axeman to chief engineer of the Chicago and Western Indiana Railroad, leveraging his on the job learning to advance his career. citations
• Isham became chief engineer of the Chicago Sanitary district, dug the CS&S canal, then used his achievement to gain an appointment to the Panama Canal Committee. citations

So, in short, he would have had at least three badges, all of which were important to his career, none of which would was considered formal learning at the time: carpentry, surveying (probably engineering management), and canal building.