CC BY – we propose that Badge Wiki use a Creative Commons Attribution 4.0 International license instead of the CC BY-SA license used on other wikis, including Wikipedia. Although we would encourage them to do so, we recognise that some people may not be in a position to share material they reuse and remix from Badge Wiki under an open license.
Register to edit – we propose that, in order to edit Badge Wiki, you must have a registered user account, approved by an administrator. This is to prevent valuable contribution time being taken up by wiki vandalism, trolling, and other anti-social behaviours caused by anonymous editing.
Real name policy – we propose that members of Badge Wiki use their real names on their profile pages, as well as provide a short bio. This is to prevent accusations of sabotage, given that the Open Badges ecosystem includes commercial interests.
Today it’s been announced that Mozilla will transition development of Open Badges to the IMS Global Learning Consortium, a non-profit that maintains and develops technology standards in education. Alongside this announcement comes the long-awaited refresh of openbadges.org, the dissolution of the Badge Alliance, and the continued harmonisation with the work of the W3C Open Credentials work.
Having had this news previewed to me a couple of weeks ago, I can’t say it’s a huge surprise. Mozilla, with financial backing from the MacArthur Foundation incubated Open Badges and ensured that it was kept going. However, it’s been the enthusiasm and dedication of the community that has ensured its success.
Although I couldn’t make it to Bologna for the ePIC conference this week, I am at the Mozilla Festival this weekend. Both there, and over the next few months, I’m looking forward to working with the community to ensure that there’s a ‘human’ side to badges, to complement Open Badges as a technological standard.
This is a new dawn for Open Badges, a new chapter in its successful, history. There’s so many people who have been, and continue to be, part of the story — certainly far too many to list here. But you know who you are, and today, as we celebrate the continued viability of a movement built upon a technical standard, I’m raising a glass to you all.
Back in January of this year, Mozilla announced a ‘continued commitment’ to, but smaller role in, the Open Badges ecosystem. That was as expected: a couple of years ago Mozilla and the MacArthur Foundation had already spun out a non-profit in the form of the Badge Alliance.
That Mozilla post included this paragraph:
We will also reconsider the role of the Badge Backpack. Mozilla will continue to host user data in the Backpack, and ensure that data is appropriately protected. But the Backpack was never intended to be the central hub for Open Badges — it was a prototype, and the hope has forever been a more federated and user-controlled model. Getting there will take time: the Backpack houses user data, and privacy and security are paramount to Mozilla. We need to get the next iteration of Backpack just right. We are seeking a capable person to help facilitate this effort and participate in the badges technical community. Of course, we welcome code contributions to the Backpack; a great example is the work done by DigitalMe.
Last month, digitalme subsequently announced they have a contract with Mozilla to work on both the Open Badges backpack and wider technical infrastructure. As Kerri Lemoie pointed out late last year, there’s no-one at Mozilla working on Open Badges right now. However, that’s a feature rather than a bug; the ecosystem in the hands of the community, where it belongs.
Tim Riches, CEO of digitalme, states that their first priority will be to jettison the no-longer-supported Mozilla Persona authentication system used for the Open Badges backpack:To improve user experience across web and mobile devices our first action will be to replace Persona with Passport.js. This will also provide us with the flexibility to enable user to login with other identity providers in the future such as Twitter, Linkedin and Facebook. We will also be improving stability and updating the code base.
In addition, digitalme are looking at how the backpack can be improved from a user point of view:
“We will be reviewing additional requirements for the backpack and technical infrastructure gathered from user research at MozFest supported by The Nominet Trust in the UK, to create a roadmap for further development, working closely with colleagues from Badge Alliance.
Some of the technical work was outlined at the beginning of the year by Nate Otto, Director of the Badge Alliance. On that roadmap is “Federated Backpack Protocol: Near and Long-term Solutions”. As the paragraph from the Mozilla post notes, federation is something that’s been promised for so long — at least the last four years.
Federation is technically complex. In fact, even explaining it is difficult. The example I usually give is around the way email works. When you send an email, you don’t have to think about which provider the recipient uses (e.g. Outlook365, GMail, Fastmail, etc.) as it all just works. Data is moved around the internet leading to the intended person receiving a message from you.
The email analogy breaks down a bit if you push it too hard, but in the Open Badges landscape, the notion of federation is crucial. It allows badge recipients to store their badges wherever they choose. At the moment, we’ve effectively got interoperable silos; there’s no easy way for users to move their badges between platforms elsewhere.
As Nate mentions in another post, building a distributed system is hard not just because of technical considerations, but because it involves co-ordinating multiple people and organisations.
It is much harder to build a distributed ecosystem than a centralized one, but it is in this distributed ecosystem, with foundational players like Mozilla playing a part, that we will build a sustainable and powerful ecosystem of learning recognition that reflects the values of the Web.
I’m delighted that there’s some very smart and committed people working on the technical side of the Open Badges ecosystem. For example, yesterday’s community call (which unfortunately I couldn’t make) resurrected the ‘tech panel’. One thing that’s really important is to ensure that the *user experience* across the Open Badges ecosystem is unambiguous; people who have earned badges need to know where they’re putting them and why. At the moment, we’ve got three services wrapped up together in badge issuing platforms such as Open Badge Academy:
One step towards federation would be to unpick these three aspects on the ecosystem level. For example, providing an ‘evidence store‘ could be something that all badge platforms buy into. This would help avoid problems around evidence disappearing if a badge provider goes out of business (as Achievery did last year).
A second step towards federation would be for the default (Mozilla/Badge Alliance) badge backpack to act as a conduit to move badges between systems. Every badge issuing platform could/should have a ‘store in backpack’ feature. If we re-interpret the ‘badge backpack’ metaphor as being a place where you securely store (but don’t necessarily display) your badges this would encourage providers to compete on badge display.
The third step towards federation is badge discoverability. Numbers are hard to come by within the Open Badges ecosystem as the specification was explicitly developed to put learners in control. Coupled with Mozilla’s (valid) concerns around security and privacy, it’s difficult both to get statistics around Open Badges and discover relevant badges. Although Credmos is having a go at the latter, more could be done on the ecosystem level. Hopefully this should be solved with the move to Linked Data in version 2.0 of the specification.
While I’m limited on the technical contributions I can make to the Badge Alliance, something I’m committed to is helping the community move forward in new and interesting ways. Although Nate wrote a community plan back in March, I still think we can do better in helping those new to the ecosystem. Funnelling people into a Slack channel leads to tumbleweeds, by and large. As I mentioned on a recent community call, I’d like to see an instance of Discourse which would build knowledge base and place for the community to interact in more more targeted ways that the blunt instrument that is the Open Badges Google Group.
Something which is, to my mind, greatly missed in the Open Badges ecosystem, is the role that Jade Forester played in curating links and updates for the community via the (now defunct) Open Badges blog. Since she moved on from Mozilla and the Badge Alliance, that weekly pulse has been sorely lacking. I’d like to see some of the advice in the Community Building Guide being followed. In fact, Telescope (the free and Open Source tool it’s written about) might be a good crowdsourced solution.
Finally, I’d like to see a return of working groups. While I know that technically anyone can set one up any time and receive the blessing of the Badge Alliance, we should find ways to either resurrect or create new ones. Open Badges is a little bit too biased towards (U.S.) formal education at the moment.
The Badge Alliance community needs to be more strategic and mindful about how we interact going forwards. The ways that we’ve done things up until now have worked to get us here, but they’re not necessarily what we need to ‘cross the chasm’ and take Open Badges (even more) mainstream.
I’m pleased that Tim Cook is now providing some strategic direction for the Badge Alliance beyond the technical side of things. I’m confident that we can continue to keep up the momentum we’ve generated over the last few years, as well as continue to evolve to meet the needs of users at every point of the technology adoption curve.
Note that the text of this version continues to be released under a CC0 license – meaning you can do whatever you like with it. Bryan’s drawings are released under a CC BY-ND license. This means that, while you can use them for whatever you like, you must attribute them (and you mustn’t change them).
Please, please give us feedback! You can do this via Twitter, in the comments section of this blog post, or by email. This can only get better when lots of people are looking at it and attempting to apply it to their context!
TL;DR: I’m working on creating a Community Alignment model (name TBC) that sets out some of the ways I’ve had success working with diverse stakeholders to ship meaningful things. I’ve started work on this on my wiki here.
Just as my continuum of ambiguity is a fundamental part of how I approach life, so I’ve got a default way of working with communities. I’m working with City & Guilds at the moment and realised that it’s actually quite difficult to articulate something I take for granted.
As a result, I’ve started working on a guide to an approach that I’ve found useful for some kinds of initiative. It’s particularly useful if the end product isn’t nailed-down, and if the community is fairly diverse.
I’ve taken a couple of hours today to write the initial text and draft some diagrams for what I’m initially calling a Community Alignment model. Your feedback would be so valuable around this – particularly if you’ve been part of any projects with me recently, or have expertise in the area.
“If you want to go fast, go alone. If you want to go far, go together.” (African proverb)
Jamie Allen reminded me that February 7th marked the two year anniversary of the Web Literacy community at Mozilla. We’ve achieved a fair bit in that time. Here’s a visual history of how we’ve got (nearly) to version 1.5 — inspired, in part by contributor Greg McVerry. There’s a list of all of the contributors so far at the end of this post and here.
Mozilla’s web literacy work was actually kicked off by Michelle Levesque before I joined Mozilla. I helped with some suggestions and iterations — as you can see from her blog. To begin with, it was just a list of skills that I suggested she might want to put into graphical form. So she did: There was a few months of overlap between me joining Mozilla as ‘Badges & Skills Lead’ and Michelle leaving. I took over development of the web literacy work and wrote a whitepaper.
Erin Knight, Director of Learning at Mozilla at the time, suggested we might work towards a ‘Web Literacy Standard’. We hosted a kick-off call in February 2013 which was well-attended. This is when the community work started, iterating towards a v1.0. The first draft (April 2013) looked like this: The ‘release candidate’ in July actually had some design love (from Chris Appleton) rather than me messing about in Keynote. This was the ‘Request For Comments’ version from July 2013: We’d decided to lock things down for September so that we could launch a version 1.0 at the Mozilla Festival the following month. We were still hoping for it to be a formal ‘standard’ so we called it a specification: As you can see, it’s very similar to v1.1 and the upcoming v1.5 – as you’d expect.
I’d moved teams in late 2013 to become ‘Web Literacy Lead’ at Mozilla. This meant that the Web Literacy Map was one of my main responsibilities. As a community we decided to transition away from ‘Standard’ as the term carries so much negative baggage in North America. After some discussion and debate, we settled on ‘Map’ — and took the opportunity to update it to v1.1. Cassie McDaniel provided the visual refresh: In April 2014 this was then used to underpin the Webmaker Resources section: Clicking on one of the competencies takes you to a page listing the skills underpinning that particular competency. It was contains resources for teaching that particular area of the Web Literacy Map. This was curated by Kat Braybrooke. In addition, nine of the ten points of the Mozilla manifesto link through to appropriate parts of the Web Literacy Map when you click on them for more information. For example under the ‘learn more’ section of Principle 2 it says Explore how to help keep the Web open. This links through to the Open Practices section of Webmaker resources.
Towards the end of 2014 we began work as a community on scoping out what we originally called ‘version 2.0‘. There was a series of interviews, a community survey, and a small number of community calls in the run-up to Christmas deciding on what we should focus on in 2015. Ultimately, we decided to re-scope to version 1.5 with the potential to go for a v2.0 later in the year. In the community calls we’ve held this year, we’ve already decided to combine ‘Web Mechanics’ and ‘Infrastructure’ to create a new, re-scoped Web Mechanics competency. At the same time, we’re separating out the two parts of ‘Design & Accessibility’ to create Designing for the Web and Accessibility. We should have v1.5 ready by the end of March 2015. 🙂
This is a visual history, but behind the simplicity we’ve aimed for is so much debate, discussion and complexity. I’ve been in awe at times at the nuanced thinking of contributors to this project. Some have showed up since the beginning of the project, others have given their precious time for just a couple of sessions. But either way, we couldn’t have come this far without them. If you want to get involved in this work, you’re very welcome! Here’s where to point your attention:
Here’s the community, in alphabetical order by first name. They’re all rockstars:
Elizabeth E Charles
Janet Laane Effron
Majda Nafissa Rahal
Have I missed your name? Apologies! Let me know. Finally, there’s a few people I want to single out for their extraordinary help. I can’t overstate how important Carla Casilli was as a thought leader to the community from 2012 to 2014. Ian O’Byrne has stepped up time and time again and has led when I’ve been away. Greg McVerry has been a tireless champion of the Web Literacy Map. Laura Hilliger has been inspirational, knowledgeable and enthusiastic. Marc Lesser has been the voice of reason and wisdom. Gus Andrews has been thoughtful and questioning. Alvar Maciel has opened our eyes beyond the English-speaking world and been a indefatigable translator. It’s been such an enjoyable couple of years. I can’t wait to get v1.5 ready and then move on to version 2.0!
TL;DR version: Mozilla is working on a new, open learning standard for Web Literacy. We’ve got weekly community calls and a blog to help us come to a consensus on what we need and what such a standard will look like. Our first target is the Mozilla Festival in October where we hope to have organisations that have aligned with the standard, as well as some Mozilla-devised learning activities, assessments, widgets, pathways and badges available.
Working in a distributed way at Mozilla is an interesting experience. We, of course, have strategies and roadmaps and an element of top down decision-making, but by and large there’s a great deal of consensus-making that goes on. Over the next few months we’re going to be learning on that experience to engage the community in coming up with a new, open learning standard for Web Literacy. If you’re unsure why we need such a standard, you might like to check out some of my previous posts on the topic.
If you’re at all familiar with how formal, technical standards are constructed then you’ll be aware that it’s often a multi-year process with much to-ing and fro-ing. While that’s absolutely necessary for a technical of standard, we’re hoping to foreshorten the process significantly in our attempt to define a learning standard for Web Literacy. Essentially, what we need is something that works well enough for those who would like to align with it. We can (and indeed, should) iterate as the Web evolves.
While I’m unwilling to put hard and fast dates on the following, these are the four steps we believe the community needs to work through in the medium-term to get to an alpha version of the standard:
Outcomes: What are our desired outcomes (and audiences)?
Assessing & Sharing: How do we scale this standard?
Building: Here’s the framework—what should we add or remove?
What I can say is that to have time for testing, for organisations to have time to think about how they will align, and for Mozilla to build the learning activities, assessments, widgets, pathways and badges we’re planning to build, then we need to get a consensus around this pretty quickly. Happily, the work that we’ve done previously seems to be a good base for this discussion. And so it should be – that framework was itself created after interviewing with a number of smart people and some research into the literature.
I’m very much looking forward to what Mozilla can create with the community over the next few months. If you’re interested in this work, may I suggest that you follow the new Web Literacy standard blog and, if possible, join our weekly calls? You’d be very welcome and you need no qualifications (other than an interest in the area) to get involved!
When I was a classroom teacher, peer assessment was something I loved to do. Once you’ve shown learners the basics it’s as easy as asking them to swap books with the person next to them. Not only do they get to focus in on writing for a particular purpose, but it’s a decentralised system meaning there’s no single point of failure (or authority).
Online, however, things are a little more problematic. When we go web scale, issues (e.g. around identity, privacy and trust) become foregrounded in ways that they often aren’t in offline settings. This is something I need to think carefully about in terms of the Web Literacies framework I’m working on, as I’m envisaging the following structure:
Skills level – granular badges awarded for completing various tasks (most badges will be awarded automatically – as is currently the case with Mozilla Thimble)
Competencies level – peer assessment based on a portfolio comprising of the work completed towards the skills badges
Literacies level – self- and peer-assessment based on work completed at the competencies level
I’ll figure out (hopefully with the help of many others) what the self-assessment looks like once we’ve sorted out the peer-assessment. The reason we need both is explained in this post.
Some of the xMOOCs such as Coursera have ‘peer-grading’ but I don’t particularly like what they’ve done for the reasons pointed out by Audrey Watters. I do, however, very much like the model that P2PU have been iterating (see this article, co-written by one of the founders of P2PU for example). The (very back-of-an-envelope) way that I see this working for the Web Literacies framework is something like:
A learner complete various activities and earns ‘skills’ badges.
These skills badges are represented on some kind of matrix.
Once the learner has enough badges to ‘level-up’ to a competencies-level badge they are required to complete a public portfolio featuring their skills badges along with some context.
This portfolio is submitted to a number (3? 5? 7? more?) of people who already have the competencies-level badge.
If a certain percentage (75%? 90%?) agree that the portfolio fulfils the criteria for the badge, the learner successfully levels-up.
There’s a lot of work to be done thinking through potential extra mechanisms such as rating-the-raters as well as making the whole UX piece seamless, but I think that could be a fairly solid way to get started.
This is a scheduled post whilst I’m on holiday in the UAE – my apologies if I don’t respond to comments straight away!
In my last post I highlighted Hugh McLeod’s work on Social Objects, pointing out just how useful an idea and way of conceptualising the world it is. Hugh does, however, go one step further in the form of ‘Social Markers’. He gives many examples in this post but Example F stood out for me:
“After a year of personal trauma, you decide that yes, indeed, Jesus Christ is your Personal Saviour. You’ve already joined a Bible reading class and started attending church every Sunday. Next thing you know, you’ve made a lot of new friends in your new congregation. Suddenly you are are awash with a whole new pile of Social Objects. Jesus, Church, The Bible, the Church Picnics, the choir rehearsals, the Christmas fund drive, the cookies and coffee after the 11 o’clock service, yes, all of them are Social Objects for your new friends to share.”
The implication is that Social Objects work within your particular circle as anchors around which to have discussions. Outside that circle and when dealing with strangers, Social Objects serve as Social Markers as a kind of shorthand. “I’m a Christian” serves as three-word way of expressing a whole worldview, expected way of acting, and (perhaps) engenders a level of trust.
That certainly seems a persuasive argument from a secular point of view as to the utility of churches in the 21st century. But I’m not really interested in whether or not the sacred can be classified with the profane in the realm of Social Markers; what I’m interested in is the concept of Social Markers and to what extent they can be explicitly agreed upon in advance. In his post, Hugh uses the example of well-known tech blogger Robert Scoble who, he believes, acts as a Social Marker:
“When I visit San Francisco I am always surprised how often the name of my friend, Robert Scoble comes up in random conversation, unprompted by myself. Why is that? Why is he so well known? Is his blog REALLY that good? Is he REALLY that smart and interesting?
Well, I could give a whole stack of reasons to explain why I think Robert’s success is well-deserved. But one major reason that his blog’s traffic is so high, and his name so well-known, is that his personal brand has somehow managed to become a Social Marker inside the Silicon Valley ecosystem. The same could also be said for Mike Arrington, Paul Graham or Mark Zuckerberg. Dropping their names into random conversations allows people to quickly and efficiently contextualize themselves.”
And, of course, as soon as someone become a Social Marker, they’ve got it made. People position and, to some extent, define themselves in relation to the Social Marker. They have an opinion on them/it, they have a relationship with the Social Marker – as does the person they’ve just met. These relationships with the Social Marker are then bridged forming a new connection based upon common ground.
Social Markers are nothing new and people have attempted to find some form of commonality, presumably, since the dawn of (human) time. Where it was probably more useful in the way of life preservation, it’s now a handy way to establish yourself as a node on a network and gain instant social cachet. In both examples the use of Social Markers is method of positioning.
So, you want to be a Social Marker? Easy. Do this:
Decide on something you’re interested in. Find out what it’s called. If it hasn’t got a name, make one up. If it’s new, take every opportunity to explain to others what it is.
Become known for that thing. This can be as easy as expressing an interest in something, asking people to share examples with you, and re-sharing them back (in a curated form) with the wider community.
Tell people what to do with your stuff.Share this, amplify that.Seth Godin is awesome at, essentially, instructing people how to share his ideas and brand.
Big up other people.When people use your ideas, express something you find useful, or share what you’ve created, collated or curated, thank them. Celebrate the formation of a community around an idea.
Don’t charge fans Social Markers are, naturally, usually paid for their opinions and work in their area of expertise. Don’t charge the fans to make money, charge the people who want bespoke work or publishers. Don’t milk the community dry.