Badges

2 Comments

At 4pm today (16th July, 2014) I’ll be giving a talk to the Institutional Web Managers Workshop (IWMW14) in Newcastle. The sessions aren’t being streamed but I’ll see if I can stream to my YouTube channel. The main idea I want to convey is that in a world which is benefiting from being digitally distributed, networked and increasing crowd driven the IWMW audience is in the prime position to support their institutions creating opportunities for learning aligned to this.  In particular, I want to highlight the work George Siemens is proposing around the Personal Knowledge Graph (PKG):

The big shift that needs to be made in education is to shift from knowing content to knowing learners.

What is needed in education is something like a Personal Learner Knowledge Graph (PLKG): a clear profile of what a learner knows – Siemens, G (2104)

There are a number of challenges with this idea including technical and ethical, but having played with ideas that could potentially highlight aspects of a persons latent knowledge capacity the concept excites me. As part of my presentation I’ll be highlighting the ways the latest iteration of ALT’s Open Course in Technology Enhanced Learning (ocTEL) align to a Personal Knowledge Graph. One of the strongest features of ocTEL, which we completely fluked, was how Open Badges can be used to support the construction of part of a Person Knowledge Graph.

Open Badges in ocTEL

As part of ocTEL the course was broken into weekly topics. Each week there were five types of badges available for that topic (this was based on the BlendKit Course).

  • Check-in: awarded for reading the week’s course material
  • Webinar: awarded for attending or watching the webinar
  • TEL One: awarded for completing each week’s ‘If you only do one thing’ activity
  • TEL Explorer: awarded for completing each week’s ‘TEL Explorer’ activities (there could be more than one)
  • Topic Badge: awarded for completing at least 3 of the above

All the badges with the exception of TEL One and TEL Explorer were automatically awarded by a click of a button, entering an activity code or the system detecting a configured set of requirements. TEL One and Explorer were awarded by the participant providing a url evidencing their activity which was manually reviewed. Other badges were available outside the weekly set for community related activity. These included badges automatically awarded for adding details to a profile, making posts on other sites recorded in ocTEL as part of our data aggregation using FeedWordPress. There were also other badges tutors could individually award people to recognise contributions to the course.

Open Badges = new nodes and edges

Besides badging appearing to be a positive influence in course engagement the badging system used in ocTEL, the BadgeOS Plugin for WordPress, there are several features of our setup you could argue supported the construction and use of Personal Knowledge Graphs:

Situational awareness

As part of the badging system there was an option to display who else had earned the badge. With this there is an opportunity to be aware of who else is active (an example badge page). Given this was available on all badges activity become categorised by level (basic check-in to advanced activity) and topic. In the current configuration we have no made connections between these but would prove an interesting area for further research. Another area for improvement is the profile pictures link you only to the persons general profile page. Whilst this has uses, outlined below, in the case of badges with evidence attached to them this link isn’t exposed.

Who's been awarded

A profile of what knowledge has been gained by an individual is arguably a key aspect of a Personal Knowledge Graph. The badging plugin used combined with the BuddyPress social network plugin integrates achievements into a person’s profile (an example profile here). This provides another entry point for people to make connections. Whilst BuddyPress has the facility for friend/follower relationships we were keen for participants to identify the personal 3rd party spaces they  exist in.

Another aspect of BuddyPress/BadgeOS we only briefly experimented with was the inclusion of badge award in the person’s activity stream. The main mechanism this could have supported is with a friending tie this activity could have been pushed to followers via email.

ocTEL achievment profile

Self-declared activity

One challenge of open or distributed activity is collecting that activity. ocTEL uses the FeedWordPress model to aggregate activity from participant blogs and other networks. Whilst the hashtag provides some means of collecting information from self-organising spaces there will always be issues with data collection. With the TEL One and TEL Explore badges requiring the person to submit a url as evidence that they have completed the activity this issue is partially overcome, the individual becoming the curator of information in their knowledge graph.

Interoperability

The final aspect of badging in ocTEL worth noting is our efforts to move from the ‘digital badging’ natively used in the BadgeOS plugin to instead directly issue Open Badges. This small difference potentially has a big impact. Most notably this means the ocTEL site exposes information about achievements in the interoperable Open Badges specification. The benefit for the user is they can display badges in other systems, on a personal knowledge graph level it means these achievements are machine readable.

Summary

This hastily written post hopefully gives you a flavour of how the use of Open Badges, or digital badging in general, could support the construction of part of a Personal Knowledge Graph. There are still a number of questions to be answered like how might Open Badges, a skills and competency definition using something like InLOC, and a Personal Knowledge Graph fit together. My slides for my IWMW14 talk, for what  they are worth, are embedded below and I look forward to hearing your thoughts on this area.

3 Comments

Update 18/06/2014: The Open Badges Issuer Add-on is now also available in the WordPress Plugin Directory. Get the Open Badges Issuer Add-on

OpenBadges_Insignia_WeIssue_BannerALT’s Open Course in Technology Enhanced Learning (ocTEL) is entering it’s final week. ocTEL has been and continues to be an excellent opportunity to explore ways in which we support ALT’s community of members. Last year the work we did in setting up a blog and community aggregations site directly feeding into the development of the ALT conference platform. This year one of the areas we were keen to explore was the digital badging of community contributions. The use of community badging is well-founded and predates the web itself. This area has however gained extra interest by educators in part due to Mozilla Open Badges. Mozilla Open Badges specify a framework for the description and award of badges using a common specification. The main benefit or this approach is interoperability. Recipients of Open Badges can collect badges in one place, manage them into collection and control how they are shared across sites, social networks and personal portfolios. One such place is in a Mozilla Backpack.

In the case of ocTEL the creation and award of digital badges, particularly within a community context, has been made very easy thanks to the BadgeOS™ plugin for WordPress. BadgeOS has a number of methods which trigger the awarding or badges including reviewed submissions as well as the completion of a defined set of steps.

One issue for us has been that to issue Open Badges with BadgeOS requires integration with the badge awarding and display site Credly. Sites like Credly are very useful parts of the badge ecosystem but the feeling we had was that if we were going to issue Open Badges we would take on the commitment of hosting the badge data ourselves rather than relying on a 3rd party. BadgeOS, regardless of whether you turn on Credly integration, still provides an excellent framework for creating and awarding digital badges. Even better is BadgeOS is open source and is actively encouraging developers to extend and enhance the plugins core functionality. If you look at the BadgeOS Developer Resources there is a number of ways this can be achieved.

With this in mind, with the support of ALT, I has decided to make my own contribution to BadgeOS  with the development of the Open Badges Issuer Add-on. This add-on achieves two things:

  • Badges designed and awarded using BadgeOS are now exposed as Open Badges compliant Assertion - Assertions are the DNA of Open Badges. They are data files which describe the badge and identify who it has been awarded to. Behind the scene the add-on is using the BadgeOS created data turning it into the required object recognised as an Open Badge. Critically this data existing in the host site. For example, one of my ocTEL badges exists here and is shown below in a formatted view.

Open Badges Assertion

  • The creation of an interface for the user to add badges awarded using BadgeOS to the Mozilla Backpack - this is technically made a lot easier as the add-on uses the existing Issuer API which provides most of the code to get the job done.

The rollout of this plugin in ocTEL is complete as detailed in ‘ocTEL digital badges are now Open Badges: How to add them to your Mozilla Backpack’. I’ve also submitted the plugin as a recognised BadgeOS add-on. The add-on will also shortly be appearing in the official WordPress Plugin Directory. Hopefully this add-on will make it easier for others to issue Open Badges through their WordPress powered site.

Like all projects this development greatly benefits for your feedback, which may include coding suggestions or improved functionality, so we appreciate your feedback.

Download the Open Badges Issuer Add-on for BadgeOS

A repost from the ocTEL course blog outlining the way we setup the BadgeOS plugin for WordPress to issue badges as part of the course. This post follows on from an earlier post, 'ocTEL and the Open Badges Assertion', which highlights some progress towards directly issuing Open Badges using BadgeOS ... more to follow on this development.

Moira Maley recently wrote to us asking for some details on how the ocTEL course is configured to issue badges. As others might benefit from this and with Moira's permission here are her questions and my responses. ...continue reading

9 Comments

Update 16/06/2014: This idea has been revisited by the Elevate team at University Campus Suffolk. You can read more about and get a copy of the code here

 Open Badges Issuer Gadget for Google SitesWant to issue badges in Google Sites? That was the challenge I set myself. My solution is the Open Badges Issuer Gadget for Google Sites. This gadget wraps the Mozilla Issuer API to allow you to issue badges from a Google Site. To use the gadget is insert into a Google Site and prefix (base url) is set for your Assertion JSON. To allow users to collect their badges direct them to the web address of your Site page containing the gadget adding ?claim_code={assertion url post fix}.

For example, if my Site page with the Issuer Gadget is found at https://sites.google.com/a/hawksey.info/openbadges and by Assertion files are all found in the directory http://mysite.ac.uk/badges/ this would be my base url. If one of my Assertion files in this directory was v1mhaws.json, to claim the badge for that person I’d send them a link to https://sites.google.com/a/hawksey.info/openbadges?claim_code=v1mhaws.json

Get the Open Badges Issuer Gadget for Google Sites

The Open Badges Issuer Gadget for Google Sites is located here:

http://hosting.gmodules.com/ig/gadgets/file/108150762089462716664/openbadges.xml

To add to your own site

  1. Open/create a page on your Google Site
  2. Selecting Insert > More gadgets,
  3. Add gadget by URL inserting the address http://hosting.gmodules.com/ig/gadgets/file/108150762089462716664/openbadges.xml
  4. Insert a prefix (base url) for your Assertion JSON files (you can leave this blank if the host site varies) and click ‘Ok’
  5. For each or collections of Assertions direct users to visit the page your gadget is hosted on adding ?claim_code= followed by a comma separated list of the remainder of you Assertion file locations

Try it

If you’d like to try the gadget complete this form and you’ll be issued with a Gadget Issuer User Badge. Get the question right and you’ll also get the Gadget Issuer Gold Badge.

How the gadget works

For those of you unfamiliar with gadgets/widgets they are an easy way to embed content in other gadget/widget compatible sites. The majority of gadgets are simply XML wrappers for HTML content. The great thing is that gadgets can include JavaScript that doesn’t get sanitized/stripped out. If you want more information about making gadgets see My First Google Gadget. The source code for the is linked to above but can also be viewed on GitHub. Essentially it’s a wrapper for Mozilla’s Issuer API

The Issuer API is a [java]script that can be dropped-in to any badge issuer's website to provide a way for users to add an issuer's badges to their backpack.

Feel free to modify the gadget code to handle the success and error callbacks.

Yep I’m issuing badges from a Google Form/Spreadsheet, here’s how

If you tried the demo you might be wondering how I went from a Google Form to issuing some badges. Here’s how. Google Spreadsheets includes Google Apps Script, a cloud scripting language with uses the JavaScript Syntax to automate processes across Google products and third party services and deploy/publish custom applications and data. Apps Script includes a Content Service, which amongst other things lets you publish JSON data. As the metadata blobs behind open badges are JSON based we can use Apps Script to process the form responses, email the recipient and create the JSON … well almost.

An issue with JSON files generated by App Script  is security measures put in place by Google prevent the cross-domain use when called by AJAX as used by the Issuer API. So currently I have to proxy the JSON via my webhost (Mozilla could fix this by also permitting JSONP, which can also be produced by Apps Script. I imagine this is however low priority. If you have any thoughts on other ways leave a comment).

Here’s a copy of the code running behind my Google Form (you’ll also need to include a rollup of the CryptoJS sha256 library to hash and salt the recipient’s email address).

[A pointer if you want to extend this work is you might want to use the native NoSQL style ScriptDb Service part of Google Apps Script to prepare and serve assertions. Also I found the Open Badges Validator is very useful for testing your Assertions.]

Related work

Some recent posts/upcoming events that have influenced this post are:

So what do you think? Inspired to issue badges from Google Apps? Have I missed anything? What isn’t clear? I look forward to your thoughts ;)