Open Badges are more than Pretty Pictures

One of the reasons why Open Badges are so popular is their ability to make visible what people have achieved. And the way to make the achievements visible is through the display of a picture. Several times in the past I have commented that Open Badges are more than pretty pictures and that there is a risk that the  pretty pictures might become to the Open Badge Infrastructure (OBI) what the proverbial tree is to the forest…

What gives value to the pretty picture is the metadata baked into it, i.e. the links to the issuer, the recipient, the awarding criteria and possibly the evidence informing the criteria. Without metadata (and the underpinning OBI trust architecture) a badge would be dumb. Conversely, a badge does not really need a picture to be made visible: from the point of view of accessibility, or simply good design, any picture should have an “alt” field properly informed, so a visually impaired reader could make sense of it. It should be the choice of the badge owner or reader to decide whether to see the picture or the textual version. This would be practical to compose a CV from a collection of badges without having to force a potential employer or client to figure out what those pretty pictures mean.

Why should the pretty pictures be dynamic?

There could be various reasons why the picture displayed by a badge should be dynamic, depending on the point of view:

  1. Issuer: an issuer can decide that a badge is valid for a certain period of time, after which the candidate needs to become re-accredited. Being able to provide a visual cue on the badge, such as changing from bright colours to grey, from sharp to fuzzy, or displaying a countdown to the expiration date, are some of the many options an issuer should be able to choose from.
  2. Recipient: a candidate could pledge for a badge and display a pie-chart indicating the % of progress towards achievement. This would be a means to show potential employers or clients ones current learning, not just past achievements.
  3. Reader: an employer reads a series of CV’s with 100+ badges, many of them totally new to her/him (except for those delivered by well known brands of education providers) and wants to use her/his CSS to create a display relevant to her/his own needs based on the baked metadata.

 Why Should the Design of Pretty Pictures be Consistent?

One problem with the pictures designed to represent Open Badges is that they are meaningless: two very similar badges can mean things as different as “has visited a page on the web” to “can manage a team of 20 people and a budget of 1 M€.” Is there a visual cue one could use to  make the difference?

OpenCredentialsIn Order to address this issue, I’ve suggested  defining something akin to a grammar of Open Badges, where the shape of the badge would make it obvious whether it is a badge related to a single event (like visiting a web page), a skill (or knowledge), a competency (a combination of skills, knowledge, attitudes and values) or a set of competencies leading to the mastery of an area of activity within a trade.

Of course, nothing can (and probably should) oblige a badge designer to conform to a rule but, as a community, we could decide to create an Open Badge registry, where the condition to register a badge would be that, among other things, the image of the badge is in line with the rules of the registry (the idea of a registry comes from Aaron Silver in the work related to brining together Open Badges and xAPI, link).

In the picture above, I have suggested how different shapes could represent different levels off aggregation or granularity: a fact or event is smaller than a skill, which is smaller than a competency, which is smaller that a mastery. Of course, good graphic designers should be able to suggest much better alternative — at one point I had the idea of a Pixel-Badge, i.e. the composition of a number of those Pixel-Badges would contribute to forming the picture of a whole badge.

Can we deliver an Open Badge for anything, like visiting a web page?

My very first response to this question was no, we shouldn’t! If we can deliver a badge for anything, then the ‘meaningful’ badges, those relative to a competency, will be lost in an ocean full of ‘meaningless’ badges. What was bothering me was the fact that a badge could be delivered after a single event, e.g. visiting a webpage, while a competency badge (my so-called ‘meaningful badge’) requires a whole range of evidence collected over a period of time within a number of contexts. I wanted badges delivered after a process, not just after a single event.

Yet, I was wrong: any attempt at differentiating between meaningful and meaningless badges is value-led  and not everybody will agree with this value judgement. The fact that a badge is delivered after a  whole process or a single event does say much about its intrinsic value. If one can bring souvenirs back from the places visited, or from a public demonstration, then why not collect souvenirs about the places visited on the Internet? One could say that there are bookmarks (and  ‘I Like’ buttons). In that context, a badge delivered after visiting a webpage could be seen as a kind of trustworthy souvenir/bookmark and the statement “I visited the website xyz” becomes verifiable.

We have to face a similar issue with the automatic delivery of Badges. With Moodle badges delivered after responding to multiple choice questions or quizzes. On-line communities, like Fedora, delivering badges automatically, based on the number of contributions to a wiki or the number of commits.

They are many badges aside from competency badges. But are all badges worth a pretty picture? Could not we have Open badges without them? Yes, and they are called xAPI (experience API) statements. You cannot yet store xAPI statements in a Backpack (they are stored in a LRS), but I hope that this will be possible very soon.

Open Badges + xAPI

When I need to explain xAPI to the people who know Open Badges, I describe them as Open Badges without a pretty picture. Although accurate, it is incomplete: I should add […] and without a native trust infrastructure!  xAPI (ex Tin Can) was initially designed to store outside the LMS, in Learning Record Store (LRS), a repository similar to the Open Badges Backpack, the data generated during the learning process.

In the following pictures, you can see the scenario (inspired by Aaron Silver) of a curriculum designer working in an environment where the LRS and Backpack  are joined into a Personal Locker. The Badge/Activity Registry hosts references to the structure of badges and activities, while the Competency Registry hosts competency definitions. Each registry is in reality a federation of registries. Everybody (and organisation) has a Personal Locker and a Badger: the function of the Badger is to issue xAPI statements (“Jim did that”) and badges that are stored in the Personal Locker. xAPI statements can be generated by anybody, institution or system equipped with a Badger.

usecase1.2 usecase1.3 usecase1.4 usecase1.5 usecase1.6 usecase1.7 usecase1.8 usecase1.9

 

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

%d bloggers like this: