World of E's

The Three T’s of Badge System Design

We’ve been working on the Mozilla Webmaker badge system, or at least initial alpha badges for the Summer Campaign and it’s tough! We knew that going in - if it were too easy, then we probably wouldn’t end up with very valuable or robust badges - but that didn’t make it easier. There are many things to consider and it’s very easy to get caught up and stuck in the core question of what badges?  That’s a really loaded question because its not just about what to call the badges - which is a rabbit hole of itself altogether - but its also considerations around specific skills, levels and granularity (which is a huge/tough one), assessment, experience, etc. We spent days trying to answer the what badges question - should we have an HTML Level 1 and Level 2 badge, or just an HTML badge (and what do those mean?)?; should we call them Ninjas or Samurais (note: we decided on neither)?, is there a Webmaker badge that everything aggregates up to and if so what are the badges that make that up?; are all badges the same granularity?, etc. The decisions at this level are also things that more people care about and have to sign off on so that also slows down the process.

I’ve since stepped back and looked at the process and realized that there were a few considerations that actually helped us move forward - and that those considerations were one or more steps removed from the badges themselves. I’m now calling this my 3 T’s of badge system design, and so far its proving to be a helpful place to start or at least move back to when you feel you getting buried in badge level decisions. 

3 T’s of Badge System Design:

(1) Types - general categories of badges. Do you have skill badges or participation badges? Progress badges or achievement badges? To do this, you need a general understanding of the learning experiences, the community and most importantly, the goals of the badge system, but you don’t have to go super deep. You don’t, for example, need to know the exact set of skills that you want to badge. And you definitely don’t need to finalize the badge names ;). You just need to decide if you are badging skills or actions or achievements or progress, etc. Finalizing and putting some lightweight descriptions around your types of badges can really help you scope the system before diving into the questions around the specific badges that fall into each.   

Our alpha badge TYPES*:

Skill badges - I developed this skill

Participation badges - I attended or hosted this event

Achievement badges - I made this

(2) Touchpoints - next you do Touchpoints or general description of how someone will earn the TYPE of badge. This starts to pull in assessment and criteria but again, you don’t have to go super deep at first. 

Our alpha badge TOUCHPOINTS*:

Skill badges will be based on work that the learner submits, assessed by peers against a rubric. (note: this is probably even more specific than you need to go at first)

Participation badges will be based on registration for an event and proof of attendance.

Achievement badges will be based on work that the learner shares with the community.

It’s a good practice to think through if there are several possible touchpoints for each badge type (and the pros/cons of each approach). Thinking through this at the outset gives you more flexibility going into the technology considerations and helps you better work with any technology constraints you might have. For example, back up touchpoints for our badges might be:

Skill badges will be issued when the learner completes a learning challenge that cover the skills.

Participation badges will be issued by the host of an event directly to attendees.

Achievement badges will be based on completion of making exercises/projects.

(3) Technology - finally, you translate the touchpoints into high level technology requirements. 

For the first set of touchpoints, our TECHNOLOGY requirements might look something like the following:

Badges integrated into the learning tool environment and the events site

A Gallery component that learners can submit work to with a voting or rating capability for skill/achievement badges

These can be more granular but don’t have to be at this point. Just think through the basic requirements and see where you net out. It may immediately become clear that something won’t fly and you can start to work around it right away instead of way later in the process. Going back to our example, maybe we would find out that we weren’t able to have a gallery component and if this is the case, we could go back to our touchpoints and decide to use another option for those types of badges and tie those badges to the learning exercises, and thus the learning tool, instead. That decision would most likely change elements about the assessments and the specific badges we ended up defining as well, so the information flow works both ways.

What you end up with is a general map of your badge system and a basic roadmap for what needs to be built to support the badge issuing. It could also help you evaluate existing badge issuing platforms to see if they have the features that meet your needs. 

Next steps are to start to dive into each piece a bit more. Define a few of your skill badges and work through the work flow again - what is the specific touchpoint (rubric, rating required, etc.) and what are the specific features needed to support that. Press repeat, press repeat. 

Again, this is the model that we’ve accidentally started to use with our badge system design. It’s not rigorously tested by any means, just seemed to work well for our first few iterations. Would love to hear back from folks on if this is helpful, where it breaks down, etc.

-E

*Note: our alpha badges are still in alpha so are subject to change

Where’s the Web?

I’ve been re-immersed in the digital literacy world lately and have seen lots of different ideas and projects that get kids interacting with technology. I also recently subscribed to the Daily Papert and have been enjoying my daily dose of constructionist genius*.

But it has gotten me thinking about something missing from the conversation: The Web. The messaging is often SO similar to ours - interest-based learning, teaching kids to make, authentic assessment, customized pathways/experiences, programming to help make abstract concepts concrete, etc. - we are all telling similar stories and are after similar goals, which is awesome - but most of the practice and implementations we see are using closed technologies and systems. We see this all the time in the digital literacy and teach-people-to-code space. Learning providers use heavy programming and engineering technologies - or fake, sandboxed learning languages - and spend tons of money and resources to create (often impressive) tools and environments to scaffold the learning, but without broadly applicable understanding at the end. Where is the Web? Where are the open technologies and standards that learners can go on to use across the Web today? Not there. There are entrenched policies and proclivities, and probably a lot of unawareness, that guide people down these closed/sandboxed paths. But the Web is definitely missing and I think that limits the power of a lot of the innovation. 

Why you should consider the Web.

• The Web is THE platform for learning right now. In fact, it can be THE platform for almost everything these days. There is SO much opportunity for learning across the Web and we have an obligation to teach people things that will matter for them beyond individual projects or learning experiences. Web literacy is a top level literacy at this point for the general public. 
• The Web is THE model for the types of learning that we all clearly believe is the future of learning. Transparent, open, accessible, multi-pathway, participatory, etc. these are all principles behind the Web, and behind the learning innovation that we all care so much about and are investing so much time and effort into making happen.
• The Web is THE THING that we can make on, learn from, etc. We can build stuff on the Web, as part of the Web. Learners can view source and hack on web pages or videos, etc. There is so much content that is part of the Web that we can leverage, or contribute to, that can support learning and making of all kinds. 

How to build the Web into these conversations / learning experiences.

This requires a bigger conversation and some deeper thinking but I think there are a few easy wins:

• Start (even end) with the Web stack (HTML, CSS, JS). These are much more powerful than you may think. These are the core technologies on the Web and someone with a little bit of understanding can do a lot on the Web, and someone well versed can make some pretty powerful stuff. Getting kids making things on the Web gets them one step closer to web literacy which is becoming more and more important and necessary in today’s world. The Web is where it’s at people and we have the opportunity to not only move folks from simple consumers to producers and active participants, but prepare them for success in a wide (HUGE!) range of jobs, not JUST engineering or programming. 
• Use Web technologies to build the scaffolded environments. You can do almost anything these days with open Web technologies. Then your work becomes more accessible to folks, and possibly more interchangeable or plug-and-play with other tools, works better or more aligned with and across the Web and possibly advances the technologies and standards. We all benefit if we are leveraging the same underlying components.
• Consider opening up the back door.  Open up the code! Now, this isn’t always possible for folks but when it is, its a really powerful thing. Suddenly your tool or content can take on a life of its own through community remixes, forks, etc. The learners themselves can hack the tools to make it do something better or more advanced. That’s the ultimate pinnacle for learning, afterall, to have someone not only understand and use the stuff you’ve created, but actually take it the next step further. 
• Bake in sharing at the core. Help learners share their work and encourage remixing and repurposing of that work. The Web makes this possible and pretty darn easy. We all know transparency in learning is valuable, and we even spent some time talking at a recent conference about the rash of research lately (which I still need to look up) on the benefits of letting learners see the work of others for their own learning (ahem, view source, ahem). Lots and lots of options for and opportunity through openness and transparency. 

I am sure there are more ways, and I would love to hear about them! Let’s do this together!

-E

* To cut Dr. Papert a bit of slack, he was writing about this stuff before personal computers, let alone the Web. I’d love to have a conversation with him today about how he would leverage the Web for his work. 

JISC webinar on Web Literacy

MichelleL and I gave a presentation on our webmaker / web literacy work through JISC last Friday. 

On webmaking and the Web:

• We want to help people understand that the Web is like Legos - you can build original things, take things apart or remix them, create and weave stories and narratives around your creations, etc.
• Part of this is about making learning fun and relevant again, but its more than that. Webmaking skills are important life skills.
• Why is the Web such an important part of this:
• The Web is a platform for learning
• The Web is a model for learning  - transparency, openness, access, collaboration, participation
• The Web is the thing we can build and learn with
• Why is webmaking important? I’ve written about this before so check that out for more (also, the Web is about interconnectedness of information and pathways…win!)

Favorite slides (adapted from a Mark Surman presentation):

       

Doesn’t all content eventually become something owned by Google, Facebook or YouTube at this point?

How do you plan to recognize these skills?

There are no mention of Web 2.0 tools in your skills. How do you see this fitting in with Web 2.0 tools?

How does this map to computer science requirements / pathways?

Hacker Literacies

The ignite talks from this year’s DML Conference are posted. I wasn’t able to get to the Ignite talks at the conference due to the inevitable impromptu side meetings that always pop-up (which is kind of the beauty of conferences like these). 

But in perusing them this morning, one that caught my eye was Rafi Santo from Indiana University talking about Hacker Literacies. There is a lot here that aligns with our thinking and goals around webmaking and web literacy, so I wanted to dig in a little further.

Highlights (transcribed from the video so with some paraphrasing): 

We are not talking about hacking like “breaking into banks and stealing credit card numbers”, but “what I am talking about is a certain kind of technological industriousness - a maker disposition that’s tied to innovation and creativity.

Again, this is very much aligned with our concept of webmakers and web literacy. These skills are more about building a webpage or knowing how to code but about an approach to learning and to exploring the world. Rafi called this “technological industriousness”. John Seely Brown coined the phrase “entrepreneurial learner” - its all about a sense of ownership, control and empowerment…over technology and the Web, over learning and the pathways we take (and choose!), and over our lives in general. I know, its mind blowing stuff. 

All technology is political. All technology is made by people and people are political and those politics get baked right into the technologies when they design it whether they like it or not….What a hacker understands is that technology is malleable and if it doesn’t line up with our values, we can change them.

Again, it comes back to this idea that we are talking about something bigger here. The individual skills add up to way more than just the sum, but an approach to everything in life. It’s about moving people from consumption to production, not just so that they can make things (although that’s cool too), but so that they don’t take things for granted, or accept things as they are. So that they don’t just remain oppressed, but understand that they have a voice, they have a channel for that voice and they can change things. 

The Internet [read: Web] was not an accident. All the things that we like about it - the openness, transparency, participatory culture - these things were by design. 

YES. The Web is awesome for so many reasons and we should use it - both as a medium for connecting people, empowering people, helping them build things…but also as a model for what we are trying to do here. Open up education/learning, allow for the emergence of many pathways and connections, make learning and assessment a transparent experience and exploration and connect learners together at web scale.

Digital literacy is about empowerment through technology. Hacker literacy is about empowerment in relation to technology. 

This is pretty deep. I had to stop and think about this for awhile. But it’s really powerful. I think it’s both a leveling up thing, and a literacy thing. Leveling up: I think we probably need to start with some of the technology as the medium, but we shouldn’t just stop there, at the what-I-can-do-with-them-stage, but use that as lessons about a broader sense of what’s possible across technology and in our lives in general. Literacy: he talks about these as hacker literacies, we talk about web literacies - the word literacy is in there intentionally. Again, its not about just a few hard skills, but a broader set of competencies that stitch together for possibility and opportunity. And many argue that these literacies should first order literacies like reading and writing…I definitely think we are moving in that direction. 

Finally, Rafi’s marching orders are below, with my commentary:

1. position kids as designers and makers of technology (= webmaking. check.)
2. talk with kids about relationship between tech and values (help them understand intentions, biases, etc. - this comes back to the idea of moving us out of ‘elegant consumption and acceptance, and approaching the world with a sense of “I can change this if I want/need to” which is part of this newer literacy)
3. integrate hacker literacies into digital literacies (see above)
4. embrace hacking everywhere - everything should be hackable (yes! hack the planet!)

-E

OBI Public Beta

We are announcing today that we launched the Public Beta of the Open Badge Infrastructure. Huge milestone and huge kudos to the team for making it happen. 

What’s the OBI?

The OBI is the ‘plumbing’ of the badge ecosystem. It is a specification for badges, set of repositories (“Backpacks”) for storing badges and APIs for pushing badges in and pulling badges out. It’s an important piece of this badge experiment because it moves us beyond more silo’d systems, allows the learner to collect badges from lots of different learning experiences and provides the structural components to enable badges to be transferred and leveraged across the ecosystem for real results like jobs or credits.

What’s Public Beta?

With this Public Beta launch, the OBI is now publicly available for use. Badges can be pushed in and pulled out and earners can store badges in the middle in their Backpacks. And more! Specifically, Public Beta includes:

• New and improved issuer API
• Backpack feature upgrades:
• Store badges
• Manage badges
• Import badges
• Group badges
• Publish groups to a unique URL and add narrations/notes around each badge to share
• New displayer API
• New documentation
• Legal docs! Privacy policy, terms of use and FAQs specifically for the Backpacks.

Wait, weren’t you already in beta?

Yes and no. We were calling it ‘beta1’ which was a made up word to mean that it was a step up from alpha but not quite all the way to beta. It was essentially the initial issuer API and Backpacks, but was available basically by invite only. We should have called it a ‘developer preview’ but hindsight, something something. This Public Beta (capital B!) is a proper Mozilla beta (security review, user data committee review, on Mozilla servers, etc.) and its publicly available! Woo!

What does it look like?

Technically like this…

But really like this…

(Sample Badge Backpack)

And this….

(Published group of badges)

How can I get involved?

• Be a badge issuer or a badge displayer
• Earn badges and push to your Backpack - in fact, you can earn your first badges at openbadges.org
• Check out the code. Fork it. Get Technical Documentation. https://github.com/mozilla/openbadges
• Join our community calls: https://openbadges.etherpad.mozilla.org/openbadges-community

What’s Next?

We are moving to a much shorter release cycle - releasing things at least every two weeks, but possibly more quickly as we go. But we are aiming to move from Beta to 1.0 by the end of the year. In addition that work, plus bug fixes along the way, we are also working on some lightweight tools that make creating and issuing badges easier, and eventually will most likely do the same for displaying badges. 

Who should we congratulate?

The team for being some of the smartest, hardest working game changers I’ve known, as well as our community who have been advising us every step of the way. Thanks to you all - congratulations!

-E