Managed Endorsements

I'm approaching my 10th anniversary on LinkedIn and I have found it a magnificent record of my professional life. The fact that it is published to the web is a positive side benefit. Surprisingly (or maybe not), I use it as my system of record for my professional life. When I enter into situation that may require a resume, the first thing I do is I make sure my LinkedIn profile is up to date. And I make updates to my resume reconciled against my LinkedIn profile. It is the easiest and best organized place to keep my professional profile information.

So when a past associate from Mozilla pointed to the year old blog post about "empty endorsements" I started reflecting about how I disagree with this. Don't get me wrong, I have the utmost respect of the work done by Erin and Alex. And the world is a whole lot better place because they are in it. As we move further into our digital, connected, and social media lives... the idea of online or digital endorsement becomes increasingly important. And staying connected with people is our connected knowledge (*we store our knowledge in our friends*); and really over a life well lived we don't know when things will come full circle. So staying connected to people in multiple ways, and acknowledging (or endorsing) a persons skills or knowledge you are familiar is the right thing to do. I do know I recently endorsed Erin for her leadership skills. I didn't do this lightly, I was mindful when I did it. I spoke with Erin a number of times during my time with Mozilla and I observed how she led a group, she is a good leader. So when I was prompted by LinkedIn (an option she has chosen to use) on a skill she has included with her profile, I thought about it and made the endorsement. From my experience, I will always consider Erin a good leader. If Erin (or anyone) truly believes LinkedIn endorsements are empty, I will politely suggest they turn off the ability to be endorsed.

From my perspective my LinkedIn endorsements are not empty, either given or received. They could be if I wasn't mindful when I gave an endorsement, or didn't consider which endorsements I displayed. (I regularly prune / update my online profiles). I believe in social media and paying it forward. I believe our personal reputations are an accumulation of all our contributions, recommendations, endorsements, badges, interactions, etc... across all the locations we participate and contribute online (and more importantly, offline).

Quick issuing and organization of Badges

Working through some of the comments within the Quick Issuing course within the P2Pu School of Badges. One discussion item prompted me to answer a bunch of questions that I believe are really important. These are the questions and related answers;

Are all my badges tiered?
No not all my badges or tiered. I do believe some of my arrangements are a star or a network. I do think badge organization should follow the organization of the knowledge domain. I do think it would be more of a network of related subjects, skills, events... that as they are earned would form clusters or groupings. I organized as a tiered approach for I was wanting to relate the categorization like the color scheme of the martial arts belt system.

I do believe the work Mozilla has been doing around badge system design is excellent and I believe they are wanting to stay away from the tiered or hierarchical approach. But I do think many humans organize in hierarchies...

Mozilla Webmaker is also becoming the exemplary badge system design. Kudo's for creating a great example!

Do I create a table for all my badges, or just tiered badges?
No, I don't create a table for all my badge systems. I do believe it is important to provide some way to organize, display and describe the badge system. A table is one way... and due to my using wikiversity for the mobile app dev course, the table seemed like the best way to go.

Do I have a giant table for all badges in one course?
I don't see creating one giant table to describe all the badges. There does need to be some way of describing the badge system as a whole. I believe it would help people understand the learning pathways within the badge system if there was a "curriculum" or "learning journey" map. I do see that Mozilla Webmaker is doing great work here as an example. See Erin Knights post; http://erinknight.com/post/29830945702/webmaker-badges
I also see the badge system and approach created by the Khan academy is also an interesting example of displaying a whole badge system.

Mozilla, Agile Learning Design, and Everything else

It was an active year for my reading, research and writing (106 blog posts in 2012). I feel I learned a whole lot. I particularly like that I had an opportunity to deep dive into open and digital badges. I believe my year of learning can be broken into three main themes; First, my work with Mozilla Open Badges and Badge systems in general; Second, my further proving out an Agile Learner Design methodology; and Third, everything else I thought about.

Mozilla Foundation

Its difficult to express the gratitude I have for the time I spent on contract with the Mozilla Foundation. In the six months I spent with Mozilla I did a whole lot, and I learned a whole lot;

• Created a lot of learning resources for on-boarding the newbie open badges user / implementer
• Completely updated the Open Badges FAQs by reading through the related google group end-to-end
• Went deep into Webmaking with my kids and some of the youth on Bowen Island
• Engaged in a number of discussions on curriculum design and building communities of practice
• Dug into some emerging open technologies like WebGL, WebRTC... and how they fit within an virtually unlimited bandwidth network
• Played with popcorn.js and wrapped learning resources to highlight formative and summative learning events
• Deepened my understanding in using distributed technologies to facilitate meetings and collaborative efforts. With a good understanding of the nature of the engagement the appropriate technologies and approaches can facilitate a very collaborative effort and keep a comprehensive record of the event. These records can be indexed (and therefore searchable) and used for later reference or as resources for subsequent events. All done with open and free technologies and approaches. Mozilla is very good at all this!

Agile Learner Design

My focus on an Agile Learner Design methodology for creating and determining your own curriculum got a renewed focus this year. It all started with my last post of 2011 where I revisited and summarized Agile Instructional Design. I have come to the conclusion that what I am doing isn't focused on instruction, but upon the self-directed learner. Therefore, what I am doing is developing an Agile Learner Design methodology, not an Agile Instructional Design methodology. An important distinction in the fundamental focus of the methodology. To build upon my last post of 2011 I kicked off the year by looking at some of the existing research and approaches to self-directed learning. And looked at some of the approaches that I would consider similar to ALD. I also considered some of the people and approaches within my inspired learner series of posts, because it is these inspired learners that drive me to further develop ALD.

The Agile Learner Design (ALD) Methodology

• Envisioning your curriculum
• Planning the learning journey
• Apply the sprint approach

ALD Reference Materials

• New image for progressive inquiry
• Personal Curriculum Mapping
• Narcissism and Presentism
• Agile Instructional Design References

ALD Examples and Inspirations

• Mobile learning concept map
• Agile Instructional Design in Practice
• Social Artistry
• Learning in the Open
• Example implementations 
• Mitch Resnick and Progressive Inquiry
• Inspired Learners  

Everything else
Outside of these two main themes for last years postings came everything else. And if there were any themes they would have been either community building or mobile web development.So here is a list of the other learnings / explorations I had from last year.

Online learning communities

• Creating online learning communities
• Inquire, Paraphrase, Acknowledge, Advocate

School of Badges 

• School of Open Badges

Learning Approaches

• Emersive and transformative learning
• OER Assessment

Screencasting

• Lighting for video capture
• Screencasting Guildelines

Mobile Web Development

• Mobile First
• Mobile web pages in HTML5 part 1
• Mobile web pages in HTML5 part 2
• Explaining CSS as a skin
• Tighten up lists for the mobile web
• Book Review: HTML5, Mark Pilgrim

Polling for posts

• Half finished blog posts
• Let my readers decide
• My readers have chosen

So there you have it. My 2012 in review. What I'm looking forward too in 2013;

• Further developing learning materials for digital badges at the P2PU School of Badges
• Officially starting my OnPhD by achieving Wikiversity / P2Pu OnPhD candidacy
• Start coding the aggregation for disparate badge systems to create and display badge clusters

Linkages to other badges

Over the last few weeks I have been diving into other badge systems to figure out a way to consolidate badges from other existing (non-obi compliant) systems into the Mozilla Open Badges Backpack. This has really forced me to think about the metadata that makes up the Open Badge. Some of the other badge systems I have looked at include;

• khan academy - https://github.com/Khan/khan-api
• codeacademy - http://www.codecademy.com
• foursquare - https://developer.foursquare.com/
• stackoverflow - https://api.stackexchange.com/
• codewall - http://coderwall.com/api

What I find interesting is that it is not immediately clear how all these badge systems will map to the current OBI specification for a badge. And until we have a standard metadata specification for the badge, we don't really have an "open" badge. I have great faith that the open community, Mozilla and the open badges team will work toward an open metadata standard for all (or should that be ALL) badges. I also believe that their work at implementing webmaker badges will improve the current open badge metadata standard greatly.

WebMaker Badges show a system design where badges are linked, clustered and the detail of a cumulative badge.

IMHO, a number of attributes regarding a badge need to be added or brought into the discussion about badges. Fortunately, I am not the first to think about this. A page within the open badge github was put in place six months ago to foster such a discussion (it remains empty, but it is there). Three of the attributes I can see originating from the new webmaker "ecosystem" of badges are what I will name; linked, clustered and the detail of a cumulative badge. A little further below in this post is how I see these three, and a couple of my additions, need to be considered within the metadata of the badge. But first, I think it important to consider who is assigning this relationship.

Who creates a badges relationships?
I believe two different people (or groups) create the badge relationships; the issuer and the earner.

• The issuer creates a badge and its metadata detailing the badges criteria, origin, contact, etc. The issuer also knows how the badge exists in relationship to other badges. Does the badge stand alone as representing a skill or knowledge all on its own? or does the badge exist with other badges to be a part of a curriculum, learning objectives, a learning journey or a cluster of skills and knowledge?
• The earner, who has little control over a badges metadata, will also create relationships between badges. Is the earner creating their own learning journey or clustering badges to represent a unique set of skills and knowledge. I believe one of the strengths of badges is how the earner is given greater control of their learning by allowing them to create a personalized curriculum.The earner needs to be able to organize their own badges. Fortunately this can be done in the Mozilla badges backpack.

This distinction is important when considering the required additions to the badge metadata specification. Once a badge is issued its attributes cannot be altered for (given current thinking) this would invalidate the badge. I agree with this assertion. What this means is that if an earner wants to set relationships among their earned badges this needs to be done in the earners badge backpack and not alter the metadata of the badge itself. I believe the issuer has many reasons to set the relationships within the metadata of the badge, as the issuer understands how the badges fits within learning and related learning. Look to the above webmaker badges for an example of this.

Badge relationships:
Currently I see four different kinds of badge relationships. All of these apply to the issuer where only a subset apply to the earner. Please do not confuse a badge with curriculum or assessment, they represent mastery of a skill or knowledge.

Some possible additional json attributes

1. journey (or linked) - a set of badges that represent a learning journey. They are related through subject matter or knowledge domain. Badges are issued and some build upon each other, others are gates (you need this badge or set of badges to move on to earning other badges). They may be the previous or next badge in a learning journey.
2. clustered (or grouped) - badges can be clustered to represent a domain of knowledge or the complete mastery of a skill.
3. master-detail - a set of badges may be sub-badges to a master badge. The idea being someone needs to collect a set of badges to be awarded the overall competency badge. (the webmaker badges seem this way). This badge relationship differs from clustered in there is no higher level badge or overall competency badge with the clustered relationship.
4. dynamic - some badges change or are updated through time. This is very apparent with engagement type badges (see stackoverflow) where the more someone contributes the greater a badge is given value for the specific earner.

Next steps?
I believe the Mozilla badge needs to incorporate these (or similar) additional attributes into the badges metadata specification. Not all may be required as a part of the specification as having them baked into the badge may not be the best place for them. But I believe these relationships need to be considered in the design of the badge, its metadata, the role of the backpack and its features, and what features should be part of the displayer.

To assist with this endeavour I will continue in mapping existing non-OBI compliant badge systems to determine the gap between emerging badge systems and what the current Mozilla Open Badge can support. I will continue my journey toward building a badge consolidation system with an alpha release at some unannounced date in the future (I've got a family to support so paid work will be my priority, duhhh).

Integrating with Open Badges

I have been thinking about how best a project or organization can integrate with open badges. This isn't the bits and bytes type of thinking, but the technical project management thinking required for the near-term (6 -12 months) success of the OBI and all projects that integrate with the OBI. Keep in mind this is a list of what I would focus upon as you work toward success. It is my approach as a technical architect and senior project manager and not Mozilla's or the OBI teams. I see these tasks as a benefit to the Open Badges project, as they will bring further insight into the design of the project, provide further requirements, and put the OBI through is paces before it is considered a production release.

1. Figure out the data model of your badge system design
This may require some technical skills and knowledge (and I suggest you find them at this time) to understand the data requirements of your badge system design. Do this without making reference to the existing OBI metadata specification, for that may compromise the vision of your badge system design. And you should stay true to your badge system design without restraining it by the existing Mozilla OBI specification. Keep in mind the OBI is in pre-release and really needs rubber-hits-the-road insights into how people want to implement badges. Once you have this data model try and map it to the OBI metadata specification for issuing a badge. If it doesn't fit, let the OBI team know via the google group, this could kick off an interesting discussion.

2. Start loading (and deleting) data
I see two kinds of badging systems. Those that already exist; like girl guide badges, khan academy badges, stackexchange badges or military badges. And the badges systems that don't yet exist. These existing badge systems have a huge number of badges already stored within them. If these badges are to make it into Mozilla Open Badges, we need to start loading them into the OBI now. This attempt to mass load badges into the OBI should come as a gift to the OBI team. Better they start dealing with the issue of thousands of badges showing up while still in pre-release than having them show up once Open Badges is officially released and bringing the whole OBI to a halt. If you are going to load data, you should also be able to delete the same data. The ability to load data should be a feature available within the OBI. A test environment should also be available, so partners can test their data loads, and delete the data that was loaded. The testing of data loading is a blog post in itself and beyond the scope of this particular tome.

Keep in mind that manually entering badges (one by one) is also a good idea as it will utilize the same process as the earners will use for adding badges to their backpack.

3. Build an automated testing approach
If you have already started working with the Mozilla Open Badges Infrastructure (OBI), or are considering it in the next short while, you should consider yourself an early adopter. And given this type of role expect things to change within the OBI, as it is currently a pre-release version. Given this early release things can change that may break the code at your end of the integration. Building an automated testing approach will yield great benefits as it will reduce the downtime of your system, increase the quality of your code, and provide early warning if the system elements beyond your control have changed. These automated tests could be built for both your internal system and the API calls you make to the OBI. Once these automated tests are built, it would also be beneficial to run them against the OBI at scheduled times to ensure the programatic assumptions made by your system are still valid against the OBI.

4. Determine where and how you want to encourage the display of your badges
Once you have badges "loaded" into the OBI and have viewed these badges in the earners backpack it becomes important to display the badges in a variety of locations. There is a growing number of widgets built for badge display and with the variety of methods for display you never know where your badges will show up. It is important to test these different display approaches and as a part of your issuing site encourage people to use specific displayers. You may also want to build or integrate your own displayer. What is important here is that you have displayed your badges in a number of different locations for testing purposes.

5. Advocate for other attributes to be added to the OBI metadata specification
Learning rarely occurs in isolation and learning is always related to other or previous learning in some way. The current metadata specification has a badge standing on its own. There is currently no attribute within the badges metadata that allow for it to link-to, be the detail of, or cluster-within another badge or set of badges. The OBIs' criteria attribute is being extended to allow blobs of data, so you could store this badge inter-relationship and linkage data in this criteria attribute. I believe this approach will store this information in the wrong place, for issuing systems would then have to store and maintain the data about these relationships of interest. A badge should know for itself if it exists in relationship to other badges.Erin Knight has created a great blog post describing the webmaker badge system design.

WebMaker Badges show a system design where badges are linked, clustered and the detail of a cumulative badge.

6. Encourage the completion of badge validation
Over the last year there has been much discussion regarding badge assertion or validation. The idea being that it can be determined if a badge is still valid through time. A number of approaches have been tabled, and agreement to the value and approach to implementation of this feature has yet to be agreed upon. I believe it is an important feature, for it would be nice to click on a badge from within the backpack or a displayer site and be notified if the badge is still valid.

If you have further questions or require assistance please do not hesitate to contact me. I will be very happy to assist. 

Community Engagement

Tuesday September 4th at 10 am EST and again at 8 pm EST I will be hanging out in Google+ and discussing Community Engagement approaches of the Open Badges team. I am going to use the following slide deck to prompt discussion. If you are new to open badges or want to listen in on an introductory discussion on open badges, message me. This hangout will also be live broadcast on YouTube and can be viewed via my Google+ profile.

The open badges team uses a collection of online tools and approaches for community engagement. This collection of tools is used for a number of different contexts. They range from open community engagement with a large number of participants to small one-on-one engagements. The tools offer both synchronous and asynchronous approaches.

Open Badges Engagement from Peter Rawsthorne

Open Badges Case Study 1 - Wikiversity, part 3

This case study is the last in a series of case studies created to help people learn about open badges. This case study describes the manual issuing of Mozilla Open Badges from within a Wikiversity course. This screencast discusses the claiming of the badge, and how it is stored in the earners backpack.

Reflective Activity: What needs to be similar in both the open badges backpack login email address and the json file?

Open Badges Case Study 1 - Wikiversity, part 2

This case study is the second of a series of case studies created to help people learn about open badges. This case study describes the manual issuing of Mozilla Open Badges from within a Wikiversity course. This screencast discusses the technology required to implement the manual issue of the badge. It also describes how the criteria and evidence to manually issue badges can be stored and assessed.

Reflective Activity: Do you understand enough programming to hash the learners email address with the salt value? If not, where would you get access to this resource or skill?

Open Badges Case Study 1 - Wikiversity, part 1

This case study is the first of a series of case studies created to help people learn about open badges. This case study describes the manual issuing of Mozilla Open Badges from within a Wikiversity course. This screencast discusses the scenario for the case study and touches upon how to design a badging system. It also describes how the criteria and evidence to manually issue badges can be stored and assessed.

Reflective Activity: What would you consider the best way to issue badges? For milestones within a course or for the course as a whole? Or would you issue both? What are the strengths and weaknesses for each approach?

WebMaking on Bowen Island

Two main themes to my webmaking over the next six weeks. Citizen based journalism with youth involved with localized food production and the creation of a rock-umentary with my teen daughter and her friends.

Citizen based journalism
The localized food production webmaking event got some local publicity in the island newspaper, which was great to read and increased my excitement about this event. It is likely this event will span three workshops where the first two will take place in the island information centre (shown in photo) and the last one in the community school. The first two sessions are mostly about skills development for journalism. Interview skills, videography, photography, storyboarding, music selection... that kind of stuff. The last session is going to be building all this into a small documentary with the Mozilla Popcorn Maker.

Rock-umentary
My teen daughter and her friends are totally into music, photography, and video production. So I set a challenge for them to create a rock-umentary about Ana Rose's music career so far. And when we are done it will be fully enhanced using Mozilla popcorn maker or maybe just popcorn.js. Looks to be an exciting six weeks...

Open Badges 3.3 - Hashing the recipient attribute

The last of three screencasts on the basic requirements for setting-up a server to be a badge issuer. In this screencast I look at hashing the earners email address with the slat value. This hashed value is then used in the recipient attribute of the json file. This screencast is a part of a step-by-step guide built to support the onboarding of the non-technical OBI implementer.

Reflective Activity: Do you feel confident with a server side programming language like PhP or Python? If not, do you have access to programmer resources to assist?

Open Badges 3.2 - Configuring for the json content-type

The second of three screencasts on the basic requirements for setting-up a server to be a badge issuer. In this screencast I look at configuring the web server to support the json content-type. This screencast is a part of a step-by-step guide built to support the onboarding of the non-technical OBI implementer.

Reflective Activity: Do you feel confident with your basic server administration skills? If not, do you have access to server administration resources to assist?

Open Badges 3.1 - Importance of a stable URL

The first of three screencasts on the basic requirements for setting a server to be a badge issuer. In this screencast I provide an overview of the basic server and configuration needs to issue a badge manually, and discuss the importance of a stable URL for the origin, criteria and evidence json attributes. This screencast is a part of a step-by-step guide built to support the onboarding of the non-technical OBI implementer.

Reflective Activity: Manually issuing a badge is not the only approach to accomplish this task? Can you think of one (maybe two) other ways to issue a badge using the OBI?

Inquire, Paraphrase, Acknowledge, Advocate

So I was reading through the information streams created around this years OSCON. And it looks to be an outstanding event... focused on the impact the open movement has had at many levels and in many realms. All good! I am so happy to be a part of it and grateful to be a part of the Open Badges initiative with Mozilla Foundation. A lot of my current activity is with building community in and around the implementation of the Open Badges Infrastructure (OBI). So what really resonated with me are the four traits for a good community as lifted by Tim O'Reilly from David Eaves keynote. The four traits are; Inquire, Paraphrase, Acknowledge, Advocate. But what does all this mean to community building? So I looked up each and what could each community member do to assist in building a strong sustainable and healthy community.

http://www.flickr.com/photos/roland/7436172034/

• Inquire - To seek information by asking a question; curious; probing.
  Always be asking questions and seek information to understand each community member and their positions and context.
  
  
• Paraphrase - A restatement of a text or passage in another form or other words, often to clarify meaning; clearness; rewording.
  Confirm that you have understood, add strength to another community members words by showing your understanding as it related to a particular issue within the community. Even restate within a different context as it relates to the community.
  
  
• Acknowledge - to show or express appreciation or gratitude for. to acknowledge a favor. To express thanks or gratitude for. To admit the existence, reality, or truth of.
  Let people know they are welcome in the community by acknowledging their contribution, engagement and presence. Confirm their contributions by tying them back to current and emerging truths within the community and its shared knowledge.
  
  
• Advocate - to support or recommend publicly; plead for or speak in favour of. to speak or write in favor of; support or urge by argument; recommend publicly.
  Speak out for all the good work the community is doing. Choose the topics of interest to you, within the community, and speak passionately of them. Assist in keeping all things moving forward; network, engage, understand, promote, and share. Be positive... advocate.

References:
http://www.thefreedictionary.com/
http://dictionary.reference.com/
https://twitter.com/timoreilly/statuses/225622408231534592
http://www.oscon.com/oscon2012/public/schedule/detail/24859

Open Badges Step 2.3: Technical Prerequisites - Server Infrastructure

The last of three screencasts on the technical prerequisites for integrating with the Open Badges Infrastructure. In this screen cast I discuss the server infrastructure required for each of the three roles of; issuer, earner, and displayer. I mostly spend my time describing the server needs of the issuer, where the displayer is quite similar to the issuer, especially if it becomes a fat displayer. And by fat I mean it offers a lot of displayer services related to badges and their earners. Again, the earner requires the least infrastructure, but can require more if we begin down the road of federated backpacks. More on the federated backpack in a later screencast.This screencast is a part of a step-by-step guide built to support the onboarding of the non-technical OBI implementer.

Reflective Activity: If the server infrastructure for the issuer is mostly about storing and managing earner, evidence, criteria and badge information, what information needs to be stored and managed by the displayer? Compare and contrast the server infrastructure needs of the issuer and the displayer.

Open Badges Step 2.2: Technical Prerequisites - Technology Stack(s)

The second of three screencasts on the technical prerequisites for integrating with the Open Badges Infrastructure. In this screen cast I discuss the technology stack(s) required for each of the three roles of; issuer, earner, and displayer. This discussion is more of a logical view of the technologies you need. The idea being we are building on ideas from the non-technical perspective. Getting deeper into the technology will come in later screencasts.This screencast is a part of a step-by-step guide built to support the onboarding of the non-technical OBI implementer.

Reflective Activity: Why does the issuer require the most technology? Can the earner get away with having no technology beyond internet access and a facebook account? Can you think of a reason why a displayer would require more technology than the issuer?

Open Badges Step 2.1: Technical Prerequisites - JavaScript

The first of three screencasts on the technical prerequisites for integrating with the Open Badges Infrastructure. In this screen cast I discuss the basic javascript you need to know to manually issue badges. I also touch upon the prerequisites if you move beyond manually issuing badges and integrate with an LMS or other server application. This screencast is a part of a step-by-step guide built to support the onboarding of the non-technical OBI implementer.

Reflective Activity: If you are going to integrate badge issuing with your learning management system (LMS) or other server application, do you need more than just JavaScript?

WebGL Interview 2

My learning in the open journey in building learning resources for the Mozilla Ignite initiative continues. 8 days back I had the amazing opportunity to speak with Mozillians Benoit Jacob, Ben Moskowitz and Bobby Richter, the conversation created the following pocast. This podcast was a discussion about some of the ideas forming from the Ignite challenge and we discussed what would be required to implement these ideas using WebGL within the superfast-superwide GENI network. The purpose of this podcast was to further identifying technologies and approaches so we can create focused learning labs, and set up experiments that others can follow and use as learning resources.

WebGL Interview 1

My learning in the open journey in building learning resources for the Mozilla Ignite initiative continues. 10 days back I had the amazing opportunity to speak with Mozillians Ben Moskowitz and Bobby Richter, the conversation created the following pocast. This podcast was a blue-sky discussion about using WebGL within the superfast-superwide GENI network. The purpose of this podcast was to start identifying technologies and approaches so we can create focused learning labs, and set up experiments that others can follow and use as learning resources.

Open Badges Step 1: Claim your first badge

In this screencast I look at some of the technical resources available for introducing someone to the open badges infrastructure (OBI). The screencast is a part of the Introduction to Open Badges Step by Step guide. The main theme of this screencast is to claim a couple of badges and to look at a number of badge issuers.

Reflective Activity: Once you have earned, claimed and displayed a few badges take some time to reflect upon the three main roles of open badges; the issuer, the earner and the displayer.