Tuesday, September 27, 2011

Join the Open Badges Team!

The Mozilla Open Badges Team is expanding! 

As you might have guessed, there is a lot going on in the Open Badges world right now. We recently launched beta1 of the Open Badge Infrastructure (OBI) and are hard at work on beta2 and 1.0 development and preparations. We are developing documentation and materials to onramp folks as seamlessly as possible to the OBI, but also want to provide channels for direct assistance to those partners that need it - whether that be through advising on badge system components, developing interfacing widget technology to assist with connections to the OBI or custom building technological components. We are working with the MacArthur Foundation and HASTAC on their DML Competition to facilitate a set of high-quality badge systems and badges that will all be plugged into the OBI and thus, the wider badge ecosystem. We are also working on badges within various Mozilla programs, such as School of Webcraft and Hackasaurus, and are starting conversations about an even bigger Mozilla badge system that would extend across various projects and programs and create a consistent experience and pathway for Mozillians to participate and grow with us and through us. And more. As I said, TONS a’happening in Open Badges land. 

But all of this will not be possible without some really good people to help get us there. So we are currently hiring for 4 positions, with another one soon to follow. Please share these with your networks and if you fit the bill for one and are interested, please let us know! From my own experience, its a fun, chaotic, innovative and inspiring project to work on, so join us!

Open Badges Developer

Open Badges Partner Manager: Business and Design

Open Badges Partner Engineer: Tech and Support

Mozilla Badge and Assessment System Desginer/Specialist

  • Design and build a badge system for Mozilla that motivates and rewards participation, provides learning pathways through various programs and experiences and fosters the next millions of Mozillians to be involved in the open Web.
  • http://hire.jobvite.com/j/?cj=oz5XVfwg&s=MoFoPost

We are a distributed team - all positions are remote and flexible. All are one year positions with potential for extending based on our success together. So come on board!

-E

Friday, September 23, 2011

Badges for Lifelong Learning: Join the Conversation

As I (and numerous others) have already mentioned, last week in addition to our announcement of the Open Badge Infrastructure beta1 release, the MacArthur Foundation and HASTAC announced the 4th annual Digital Media & Learning Competition, which is focused around badges. These two efforts work together well in that we at Mozilla are building the infrastructure to support an ecosystem of badges-as-credentials for learners, and MacArthur is bootstrapping that ecosystem with high-quality, high-value, learning-focused badge systems through the competition. Together with MacArthur and HASTAC, as well as all of the people that join the competition (and conversation), I think we can take this experiment and exploration pretty far, pretty quickly, and learn a lot.

The announcement was made in DC at the Hirshhorn (which somehow was my first time there despite living in DC for 7 years - cool museum). It was a jam-packed few hours that went from the conceptual introduction of badges, through goals and aspirations for this work, to very real examples of badge systems that are already out there now. It took an initiative that was certainly publicly talked about (we are Mozilla, afterall), but within a limited range, to a much bigger stage with much wider reach. Needless to say, there has been a lot of chatter about it since then - this post from my colleague, Matt Thompson, highlights some of that. While much of the feedback was positive, there were definitely some concerns and issues raised among the voices, some of which I want to address here.

But first let me just say that for me, it was an incredibly surreal day, given that I could remember back when some of these initial conversations were happening in a not-so-well-lit corner in Barcelona at the Mozilla Drumbeat Festival. And fast forward a relatively short amount of time (and a TON of work) later and I was sitting in front of Secretary Duncan from the Department of Ed and Administrator Bolden from NASA, among others, saying some pretty inspiring and generally awesome things about these efforts. 

Now. I realize that I am coming from a different vantage point in this than most. I have been thinking about badges, talking about badges, designing badges, critiquing badge systems, building the badge infrastructure, etc. So I’m a little close to all of this. Some may argue that makes me blind to some of the concerns raised in the blogosphere and twit-o-sphere (?) after the event, but I would actually say it makes me more tuned into them. And appreciate them even more.

I still very much see this as a conversation, or as I said before, an experiment or exploration. Not so much in a starting-from-scratch or winging-it way, since again, there has been A LOT of work and thought put into this, but instead in a we-don’t-have-blinders-on, let’s-tackle-these-issues-together way. I think as many perspectives as possible are important for this conversation and I would be a little nervous if there wasn’t any push back from anyone. We don’t have everything figured out yet, and its only through this conversation and these explorations that we will make progress. (Note: I do not, however believe that not having all the answers means we shouldn’t try)

Again, most of the feedback was overwhelmingly positive and Matt captures some of that, but there were a few common themes in some of the more concerned feedback that I wanted to address here. This is a conversation after all, and so as conversations go, let’s talk it out. 

A few themes emerged in some of the feedback:

Theme #1: DANGER! This is being done by technologists, not education people

There seems to be some confusion about Mozilla’s role and the role of the technologists in all of this. Mozilla is building the technical infrastructure - the plumbing, or the part that makes sense to have techies involved in - but the key goal of that infrastructure is to support (and not constrain) innovation at the fringes. This means that the education folk have complete control over their badge systems - they can decide what the badges are, what the assessments look like, how the learning experience plays out, etc. So the educators are VERY much involved and in fact are driving the early badges, criteria behind those badges and ultimately the value of the badges.

Theme #2: This is going to be a top-down system forced on everyone that will ruin our motivations for the things we love to do just because we love to do them

Exactly the opposite, actually. This is at heart, a bottom-up, grass roots, OPEN ecosystem that is working to provide recognition where there currently isn’t any option. Issuers can issue badges for any number of skills, qualities, achievements, interests, affiliations, etc. Each issuer can decide what badges to issue and what things to recognize, just as each learner/user can decide what badges they care about. Learners/users control their collection of badges and can decide what to accept, what to reject, what to share, etc. For some, tinkering with robots may just be something they love to do in their free time (doesn’t everyone?) and that’s enough…for them, great. But for some, all of that experience and skill development could lead to job or further education opportunities and right now, there is no real way to get recognition for it. So that’s the gap badges are trying to fill. 

On the intrinsic/extrinsic motivation issue - I think this is definitely something that we want to track very closely. I agree with some of the more current thinking that this delineation is not as binary as we used to talk about it and that there are different motivations mixed into everything we do so I don’t think that the introduction of badges to interest-driven learning experiences is necessarily going to immediately bring us to the classic kid-getting-good-grades-because-they-want-to versus kid-getting-good-grades-because-they-get-paid situation. But again, this is definitely an area to research more and discuss further as we proceed. I am clearly not an expert on this and another great aspect of the competition is that is it supporting the people that are to do solid research on open questions, effectiveness, etc.

Theme #3: Oh great, more gamification, this time attacking education and learning.

Badges are linked in many people’s minds with gamification and so a natural reaction to these efforts is that this is another example of layering gaming on top of yet another space or discipline. These assumptions are not totally off-base, I think some of the concepts of game design and motivation will come into play in some badge systems, but this is definitely about more than that. Certainly, many of the badges developed through the competition will be backed by rigorous assessments and evidence. And we will see a lot of innovation that I think will move the learning/education space forward. This is not about just slapping some badges onto existing frameworks and calling it a day. This is about turning assumptions on their heads and taking a fresh, hard look at learning and how to support it. One of my Open Badges teammates, Carla Casilli, wrote a great post about this as well.

Theme #4: What happens when this gets out of hand and there are badges for everything?

This has come up since day 1 which is kind of funny given that we’ve all jumped from just talking about the potential for using badges to some future world where this has taken off so much, that there are a ton of badges in the ecosystem. I think that that future day is a real possibility, and in some ways would validate some of our thinking about the potential for badges. But while I understand the concern, I myself am not that concerned about this. One, we aren’t there yet. Two, we are building things into the Open Badge Infrastructure that can help with some of this. And three, if badges do become as big of a ‘thing’, then there will be markets and tools that emerge around them. Look at the Web in the early days - thanks to the simplicity of HTML among other things, there was an explosion of websites. It could have been complete chaos but then third party tools (and arguably quite lucrative markets) emerged to help us filter, rank and make sense of this world. I think the same thing will happen for badges. There will be tools that emerge to filter and visualize badges. Endorsements and other information built into the technical infrastructure (and the badge itself) will help people make sense of badges. And again, users will have complete control over their badge collections so can decide which badges to let in, how to value those badges, who to share them with, etc.

Anyway, I am super excited about these efforts and really looking forward to continuing the conversation. I encourage all of you to get involved in that conversation - in a constructive way of course (nothing is more frustrating than a negative (or positive!) remark without anything context or thoughts that we can all react to or build from so let’s just avoid that if possible). So join the conversation, join the competition. Explore this with us. 

-E

Tuesday, September 20, 2011

OBI beta1

Hey all - 

As many of you probably heard, we formally launched the Mozilla Open Badge Infrastructure (OBI) last week in conjunction with the MacArthur/HASTAC Digital Media for Learning Competition focused on badges (more on my thoughts/reflections about this in the next post).

The OBI is an open infrastructure to support an alternative credentialing (badging) ecosystem where there can be lots of different badge issuers and any given learner/user can collect badges across those issuers, pull them into one collection that they control and manage, and then share them out as needed with various audiences, websites, etc. We are building the specifications/standards and core reference repository software to sit in the middle and make this ecosystem a reality. More on the OBI here and here and here

As of the middle of last week, we released the beta1 version of the OBI which is very exciting progress and means that there is now a there there. 

beta1 includes:

  • Reference Badge Backpack technology
    • Repository of all badges for a particular user
    • Unpacks the badges to provide user with a view into the metadata behind the badge
    • UI for management and privacy control
    • Grouping - ability to create groups of badges (and then share them out)
    • Coming soon - access to display sites that have registered with the OBI, so can share out groups of badges directly from the Backpack

  • Specifications/Standards
    • Metadata spec for badges - Badges pushed into the OBI from the issuer are simply JSON blobs, in other words, simply a set of metadata that defines the badge. This means a badge at any given time, carries with it all the information needed to understand the badge. Includes badge title, badge description, issuer, issue date, criteria to earn the badge (URL), badge image (URL) and optionally unique URL back to user work or evidence.
  • Communication channels/API
    • Issuer API (to push badges in)
    • Coming soon: Displayer API (to pull badges out)
  • Mozilla Baking Service
    • Service to embed JSON into PNG files*
  • Line-up of Initial Issuers
    • We are working with a number of initial issuers (around 10 so far), including Remix Learning, Open Michigan, P2PU and Parsons New School, to push their badges into the OBI. They will be rolling out badges systems starting next week, through the next month or so. beta1 is a ‘private’ beta meaning that we are working closely with the initial partners versus releasing it widely for public use. However, we are definitely still open to working with more beta partners so if you have a badge system and are ready to plug in, just let us know!

*More on PNG files

We have taken a somewhat unique approach to the badges themselves, based on some awesome ideas from the ever-impressive Dan Mills at Mozilla. Instead of badges existing as the raw data - JSON blobs - throughout the system, we are ‘baking’ (embedding) them into PNG files so that each badge becomes a portable, ‘tangible’ thing that can be exchanged more easily. This means that issuers could email them directly to users, and users could email/send them directly to consumers, etc. This approach gives users more control over their badges and creates a more decentralized system. Users can decide to forward badges onto the OBI, or they could store them in their own Backpack that they host or even store them locally. The one caveat is that the embedded PNG is fairly unreadable without some unpacking software - this means that the badge is a viewable/exchangeable image but the metadata behind it is fully embedded into the PNG and unreadable unless unpacked. There are several ways to access the metadata: the OBI Badge Backpack will unpack badges for users (so if they are stored there, users can see the data), some technically-able users may write their own tool or third party tools may emerge within the community. But the idea that the badge can be easily exchanged/stored and all the information needed to understand that badge lives with in means that ultimately, the PNG approach gives users and the ecosystem, more flexibility and control.

Why ‘beta1’?

What’s this ‘beta1' thing all about, why not just call it 'beta’? Basically because ‘beta' has come to mean something different than originally intended. Today we see a beta stamped on just about everything, sometimes for long periods of time. It seems to have come to mean, this is almost 100% but there may be a little flakiness or we may change a few things around from time to time. Our beta is much more in line with the traditional beta which means, its the step up from alpha that is critical feature complete, but there’s still a lot of tweaking, updating and building out to be done. Hence ‘beta1’.

What’s Next?

beta2: We are working to release the beta2 version later in October that will include the displayer side API and communication channels, enhanced Backpack UI, scalability considerations, etc. More issuers and the initial displayers will start to plug in at this point. We are also building a Facebook widget as the first displayer widget example.

Public 1.0 release: We will be releasing the fully functioning OBI as GA/1.0 in January of 2012. This will include documentation and materials to support issuers, users and displayers who want to use the system. At this point, the OBI is fully public and anyone can plug in on either end.

Where Can I Learn More About the OBI/beta1:

Kudos:

Many thanks and praise go first and foremost to our rockin’ technical lead, Brian Brennan, who architected and built the current version in record time. Additionally, again, thanks to Dan Mills and the Mozilla Labs folks who assisted and guided the work. And finally, we are incredibly fortunate to have a totally awesome advisory group made up of folks spanning academia, development, federal agencies, industry and the open source world. They have been with us every step of the way, helping us vet ideas (and many times kill ideas), think through assumptions, etc. Thanks everyone!

-E

Monday, August 8, 2011

OBI alpha

Last week, we released the alpha version of the Mozilla Open Badge Infrastructure (OBI) with the first issuer, Peer 2 Peer University. 

What is the Open Badge Infrastructure? (earlier post and background here)

The Mozilla OBI is a technology solution to support the creation of a badge ecosystem. The OBI allows there to be many independent badge issuers and for a single individual to earn badges across issuers, collect them to a single collection that s/he has complete control over, and then decide how to share out various subcollections with display sites including social networks, career sites, personal sites and digital resumes/portfolios. The OBI is that central piece that includes a reference badge repository, management interface (the ‘Badge Backpack’) for each user and the necessary communication channels to support pushing badges in (issuers) and pulling badges out (displayers), as well as authenticating and verifying badges.

OBI tech diagram

What is the alpha version? What does it include?

The alpha version is the first major release of the OBI. It includes:

There are still a few things that need to happen on the P2PU side for the P2PU community to push their badges to the OBI, but all the groundwork is there. Here is a post on the latest updates on the P2PU side.

What’s next?

1) Beta - September 2011

The alpha version is the first step in many good things to come. Next up is the beta version which will be a a core feature-complete, fully functioning OBI that is launched with a small number of partners as issuers. Beta will also include the Badge Backpack for badge management and the first display widget for users to display badges outside of the OBI. We are aiming to launch beta in early September. That’s right folks, only a month away!

2) Public 1.0 Release - January 2012

After beta, next up is a public release of the spec/API and all documentation. In addition to feature additions and bug fixes/updates, this public 1.0 release will allow anyone to become a badge issuer or badge displayer with the OBI. The Public 1.0 release is scheduled for early January 2012.

So, needless to say, much more to come soon!

-E

Friday, April 15, 2011

The Badge as a Story-teller

As we push forward with our badge pilot and other explorations of badges for learning, we are now facing the inevitable question of what is the badge itself? In some ways, its a much easier question than others we have been working through like how does one earn a badge, how does one use a badge, how much are badges valued, etc. But in other ways, its the toughest question to answer because the badge itself is the gateway, the alert, the attention-grabber, the story-teller. How does one little badge carry all that information?

Two ways. The up front story + the behind/underneath story.

1) What’s Up Front: DESIGN

The look and feel of the badge will tell some of the story at first glance (to humans…and maybe smart dogs like mine). And in fact, the more it can tell, the better, although that said, I much prefer something visual and simple than text-heavy

We are working with an awesome designer to design the badges for the pilot(s) and these are the most current iteration of the first subset:

A few things to note about the thought behind the designs:

Iconography: In our book, iconography can go a long way. We actually prefer icon treatment over text - when it works - but for the skill badges, we felt the text treatment was necessary because without it, we were getting too cute. And at the end of the day, we don’t want to make people guess what these badges are about. If I am putting my badges on a job application, I don’t want to confuse people or make them work hard to figure out what they represent.

 Shape: Shape can also add to the story and for the skill badges, we went with a gear shape to convey something along the lines of harder skills. May or may not be working - interested in feedback*.

Color: Some of this is design 101, but color can tell a story too. Red obviously pops and some felt was more aligned with skills than with community types of badges. (We were also driven by the colors that were automatically assigned to the different types of badges within the badge environment) I think at the very least, having some consistency in color treatments can help color add to the story.

Branding: This was a tricky one for us, and still is being worked out actually. Real estate is obviously an issue here - and while size is not prescribed (you can actually see two we were playing with), its doubtful anyone would display a badge that is 800 pixels wide. Most likely, they would resize it down so that they could display it alongside other badges and thus we would be back to square one. In addition to real estate, branding is tricky for us because we have so much of it :). These badges are being issued from the School of Webcraft, which are a set of P2PU courses that are backed by Mozilla. 

The current thinking is that carrying the Mozilla brand, especially on the skill badges, would have the most value in the marketplace, so that’s what we have now. But interested in feedback - is there more value in having SoW or P2PU? Having branding across all badges? What else?

That is actually a nice segue into the second aspect of badge’s story-telling power:

2) What’s Behind it: METADATA

What’s behind a badge can tell just as much of a story as what’s up front. In fact, it can tell more. Metadata gives us ways to extend the front end design and jam pack the badge with additional story-tellin’ information. For example, with simple html metadata, you may mouseover the badge to see more information like the title, description and branding. But beyond just that, we feel a badge itself should carry with it all of the information needed to understand the badge, value it, validate it (has it expired?), authenticate it (ensure it was issued to this person), etc. A badge is really (on the backend) just a blob of metadata that tells a story. This means that a learner can put that badge anywhere and it will still be able to tell the same, consistent story. 

Oh yeah, and computers don’t speak purty images, its the goods behind/underneath - the metadata - that they care about. And these badges are digital…aka, live, breath and thrive on and between computers…So obviously metadata is extremely important. 

As part of the open badge infrastructure project, we are working to define a metadata spec that each badge could adhere to and thus badges could be exchanged easily across sites. That spec is still in development* but here are some things we know it has to include:

CORE:

  • Title
  • Description (what does the badge represent, what did someone need to do to get it)
  • Image file
  • Issue Date
  • Issuer
  • Callback authentication link (link back to issuer to confirm that this badge was in fact issued on this date to this user)
  • Expiration date (issuer can set a certain timeframe for the badge to be valid and require an update or new badge after a certain period)
  • URL to evidence (learner work, endorsements, etc backing the badge)

OTHER:

  • Group ID - to be able to say that x badge is from a certain group of issuers, this might be b/c you have a certain set of trusted issuers, etc.
  • What else?

*How you can help:

  • Help us help humans understand badges: Provide feedback and suggestions on the badge designs
  • Help us help machines understand badges: Provide input and ideas around the metadata spec. What else will people/computers want to do with badges that should be captured in the metadata?

I *finally* got comments set up on this blog so the good news is that you can provide your feedback right here in line with the post! Brilliant! So, have at it!

-E