Badges – another take

Badges can be seen as recognisable tokens of status or achievement. But tokens don’t work in a vacuum, they depend on other things to make them work. Perhaps looking at these may help us understand how they might be used, both for portfolios and elsewhere.

Rowin wrote a useful post a few weeks ago, and the topic has retained a buzz. Taking this forward, I’d like to discuss specifically the aspects of badges — and indeed any other certificate — relevant both to portfolio tools and to competence definitions. Because the focus here is on badges, I’ll use the term “badge” occasionally to include what is normally thought of as a certificate.

A badge, by being worn, expresses a claim to something. Some real badges may express the proposition that the wearer is a member of some organisation or club. Anyone can wear an “old school tie”, but how does one judge the truth of the claim to belong to a particular alumni group? Much upset can be caused by the misleading wearing of medals, in the same way as badges.

Badges could often do with a clarification of what is being claimed. (That would be a “better than reality” feature.) Is my wearing a medal a statement that I have been awarded it, or it is just in honour of the dead relative that earned it? Did I earn this badge on my own, was I helped towards it, or am I just wearing it because it looks “cool”? An electronic badge, e.g. on a profile or e-portfolio, can easily link to an explicit claim page including a statement of who was awarded this badge, and when, beyond information about what the badge is awarded for. These days, a physical badge could have a QR code so that people can scan it and be taken to the same claim page.

If the claim is, for example, simply to “be” a particular way, or to adhere to some opinion, or perhaps to support some team (in each case where the natural evidence is just what the wearer says), then probably no more is needed. But most badges, at least those worn with pride, represent something more than that the wearer self-certifies something. Usually, they represent something like a status awarded by some other authority than the wearer, and to be worth wearing, they show something that the wearer has, but might not have had, which is of some significance to the intended observers.

If a badge represents a valued status, then clearly badges may be worn misleadingly. To counter that, there will need to be some system of verification, through which an observer can check on the validity of the implied claim to that status. Fortunately, this is much easier to arrange with an electronic badge than a physical one. Physical badges really need some kind of regulatory social system around them, often largely informal, that deters people from wearing misleading badges. If there is no such social system, we are less in the territory of badges, and more of certificates, where the issues are relatively well known.

When do you wear physical badges? When I do it is usually a conference, visitor or staff badge. Smart badges can be “swiped” in some way, and that could, for instance, lead to a web page on the authority’s web site with a photo of the person. That would be a pretty good quick check that would be difficult to fake effectively. “Swiping” can these days be magnetic, RFID, or QR code.

My suggestion for electronic badges is that the token badge links directly to a claim page. The claim page ideally holds the relevant information in a form that is both machine processable and human readable. But, as a portfolio is typically under the control of the individual, more portfolio pages cannot easily provide any official confirmation. The way to do this within a user-controlled portfolio would be with some kind of electronic signature. But probably much more effective in the long term is for the portfolio claim page to refer to other information held by the awarding authority. This page can either be public or restricted, and could hold varying amounts of information about the person as well as the badge claim.

Here are some first ideas of information that could relate to a badge (or indeed any certificate):

  • what is claimed (competence, membership, permission, values, etc.);
  • identity of the person claiming;
  • what authority is responsible for validating the claim and awarding;
  • when and on what grounds the award was made;
  • how and when any assessment process was done;
  • assurance that the qualifying performance was not by someone else.

But that’s only a quick attempt. A much slower attempt would be helpful.

It’s important to be able to separate out these components. The “what is claimed” part is very closely related to learning outcome and competence definitions, the subject of the InLOC work. All the assessment and validation information is separable, and the information models (along with any interoperability specifications) should be created separately.

Competence and values can be defined independently of any organisation — they attach just to an individual. This is different from membership, permission, and the like, that are essentially tied to systems and organisations, and not as such transferable.

The future of Leap2A?

We’ve done a great job with Leap2A in terms of providing a workable starting point for interoperability of e-portfolio systems and portability of learner-ownable information, but what are the next steps we (and JISC) should be taking? That’s what we need to think about.

The role of CETIS was only to co-ordinate this work. The ones to take the real credit are the vendors and developers of e-portfolio and related systems, who worked well together to make the decisions on how Leap2A should be, representing all the information that is seen as sharable between actual e-portfolio tools, allowing it to be communicated between different systems.

The current limitations come from the lack of coherent practice in personal and professional development, indeed in all the areas that e-portfolio and related tools are used for. Where some institutions support activities that are simply different from those supported by a different institution, there is no magic wand that can be waved over the information related to one activity that can turn it into a form that supports a fundamentally different one. We need coherent practice. Not identical practice, by any means, but practice where it is as clear as possible what the building blocks of stored lifelong learning information are.

What we really need is for real users — learners — to be taking information between systems that they use or have used. We need to have motivating stories of how this opens up new possibilities; how it enables lifelong personal and professional development in ways that haven’t been open before. When learners start needing the interoperability, it will naturally be time to start looking again, and developing Leap2A to respond to the actual needs. We’ve broken the deadlock by providing a good initial basis, but now the baton passes to real practice, to take advantage of what we have created.

What will help this? Does it need convergence, not on individual development practice necessarily, but on the concepts behind it? Does it need tools to be better – and if so, what tools? Does it need changes in the ways institutions support PDP? In November, we held a meeting co-located with the annual residential seminar of the CRA, as a body that has a long history of collaboration with CETIS in this area.

And how do we provide for the future of Leap2A more generally? Is it time to form a governing group of software developers who have implemented Leap2A? Is there any funding, or are there any initiatives, that can keep Leap2A fresh and increasingly relevant?

Please consider sharing your views, and contributing to the future of Leap2A.