Open Education Conference 2012

Part of my learning journey in developing Agile Learner Design (ALD) is to engage others in my personal learning network. What a better way than to present at the Open Education Conference. I'd be flattered if I ended up being selected... but the attempt will only deepen my understanding and development of this much needed pedagogical approach.

Here are the details of my call for papers application:

Session Title:
Agile Learner Design

Short Abstract:
A pedagogical approach for the self-directed life-long learner to envision, plan, build and deploy their own curriculum.

Medium Length Description:
The people who build Open Educational Resources are also the people who create, and further develop, an expertise in the OERs subject domain. Agile Learner Design (ALD) leverages the idea that the instructional designers are often the ones who learn most from developing curriculum, not the students who consume it. At a time when self-directed life-long learning is becoming a recognized approach to personal learning and growth we require pedagogical approaches that develop the learners meta-cognitive abilities and provide a roadmap for these self-directed learners to develop and execute upon their own curriculum. ALD provides the pedagogical approaches to support self-directed life-long learners achieve their personal learning goals outside of (and within) the traditional institutions. This presentation will explore the breadth and depth of ALD as it has developed over the last seven years.

Conference Theme:
Open Educational Resources

Session Type: 
45 minute presentation

Martial Arts Badge Systems Design

Jiu Jitsu Belt Ranking System

I'm still enamored by the martial arts belt coloring as a reference for badge colors. It already comes with a defacto global understanding of different colors for different levels. And this understanding is close to shared across all the different martial art forms.

I also like how the colors can be expanded by adding attributes to the belt (like dark lines or white cuffs). This allows for a level of understanding, denoted by a single color, to be expanded to contain additional levels within the same color. This could allow for badges to be offered at different levels of granularity depending on the group, the learning goals, the duration, the context, etc. In some of the martial arts practices they have many top levels (or degrees), creating a flexibility for life-long learning.

From a technical perspective the colors found in the martial arts belts are all web safe colors. So when creating and displaying badges the challenges in rendering will be reduced by the smaller and known color palette. I am also a strong believer in having iconic or color themes throughout course materials that provide a visual prompt of where the learner is within their learning journey. Having this prompt aligning the learning resources with the awarded badge can assist in organizing learning modules throughout a program or learning journey. And again by using web safe colors across all modules, and out to the mobile devices they will be utilized, can assist in keeping the learner organized and knowing the materials they are focused upon are at the correct level for their abilities and knowledge.

cccccc	white	None
ffff66	yellow	Introduction
ff6633	orange	Beginner
339966	green	Intermediate
0066ff	blue	Advanced
ff00ff	purple	Expert
990000	brown
000000	black	Master
ff0000	red

Described here are my musings about badge color schemes. They may not work for your learning context or how many levels or goals your learning system has. There are many things to consider when designing badge systems. And having a varied color system that provides many levels that can be easily added too many not be the best. For further perspectives on badge systems design I strongly recommend reading Erin Knight's (Senior Director of Learning with Mozilla Foundation) excellent post discussing the three T's of badge systems design.

Making a badge

With my next step of implementing the OBI I needed to create my own badge. I wanted it to be original (make it myself), follow my badge coloring system, use open resources, and be associated with the wikiversity course I am building. All of this is possible by using GIMP, learning about gimp on youtube, and finding some open resources.One nice item I stumbled across is the NounProject which started back in December of 2010 as a kickstarter project. This project provides an opensource collection of symbols. All good for badges. I found myself a couple of symbols I could use across my badge taxonomy. I also found a couple of good youtube tutorials on how the use gimp to create badges. I watched a few and the ones I felt were the best I have embedded here. One for creating a badge and the other for creating text around a circle. Combined they provide a good couple lessons on how to create a badge. And adding the nounproject symbol is a simple drag and drop. All good, and oh so much fun...

Create a badge with Gimp


Semi-circular text with Gimp


Even though it is fairly easy to create your own badges, it is a really good idea to engage a proven designer. With the emerging badge economy and the benefits to promote your brand (institutional or otherwise) that will be available through badges, the designer could be of great benefit.

Carla Casilli's excellent troika of posts

This troika of posts from Carla Casilli is a must read for everyone wrapping the heads around designing open badge systems. I know these three posts have given me more license to dive more deeply into approaches for digital badges. particularly how they apply to the self-directed life-long learner. Thank-you Carla!!!

• Addressing questions of validity and introducing reliability + credibility into the equation
  https://carlacasilli.wordpress.com/2012/05/21/badge-system-design-what-we-talk-about-when-we-talk-about-validity/
  
  I completely resonate with this post and how it challenges the status-quo regarding validity of credentials and how validity is built through time. Most things that have credibility, built their credibility through time.
  
  
• Different perspectives on ways to approach badge system design
  https://carlacasilli.wordpress.com/2012/05/20/badge-system-design-seven-ways-of-looking-at-a-badge-system/
  
  Looking at badge systems from many views is key to understanding badges systems. Badges are a paradigm shift, a disrupter, an opportunity for every self-directed life-long learner.
  
  
• Why open badges matter in a binary world https://carlacasilli.wordpress.com/2012/05/18/badge-system-design-beyond-a-binary-approval-system/
  
  This post does a great job of getting you thinking about traditional accreditation systems. Learning is a life-long journey and doesn't have an end point. Even upon mastery of a subject domain, you realize there is still so much to learn. Badge systems can do a great job is supporting the endless journey of learning.

A badge taxonomy

I'm now to the point where I need to create sample code for the badges step-by-step. For my testing and sample code there is a minimum of items I need to begin, these are;

1. some graphics files for each of the badges I'd like to issue
2. a web location describing the criteria
3. a web location providing evidence of completion

Items 2. and 3. are fairly straight forward I just need to point at any stable URL. For the sake of building something close to real I will use some URL's that point to some real criteria and its related evidence. I will use different base URL's to add authenticity.

How do I decide on the badge taxonomy?
The new challenge is in creating a badge taxonomy that will work for my learning context and how the learning progress will advance. It does seem like I'm making the creation of some sample code way to complicated, but I want the sample to provide enough complexity to make it real.

Now I have started thinking about it, it becomes complicated, the devil really is in the details. I want a taxonomy that provides enough levels so I can differentiate between the different levels of competency, I also want to show beginning and completion. I want things to be visually appealing and easily understood. When I step outside of scout / merit badges, I begin to think more about the different levels of competency or mastery. The two that jump to mind are what is available with the martial arts with belts and those available with bronze, silver and gold awards.

The martial arts taxonomy
What I really like about the martial arts taxonomy is the range of colors, the differentiation between child and adult, the shared starting point of white, and the flexibility to the number of levels. What concerns me most in using the martial arts levels is there are too many levels. and trying to spread a curriculum across so many levels would create an unnecessary complexity in getting to completion.

Gold, Silver and Bronze taxonomy
What I like about the Olympic style awards is its simplicity. And how it has been well applied to many award systems. I remember growing up in Canada we had a gold, silver and bronze fitness badges. The amount of excitement around these badges was outstanding. And having only three levels made things simple and provided for three different levels of achievement. What concerns me most about these three awards is their relationship with competitive activities and having a 1st, 2nd and 3rd place finish. In my mind, learning isn't about competition, it's about achievement and depth of knowing. I also don't believe the gold, silver and bronze provide enough variety of colors to make the badges distinguishable.

My badge taxonomy
I often find the simple solution is often the best solution. I like the use of colors as found in the martial arts approach, I believe a good use of colors will also work best on the web. I also like starting with white as the introductory level. I like having only a few levels of achievement (three or four)  for this fits well within; beginner, intermediate, advanced and master.

The taxonomy I have developed here only serves as an example of the things I have thought about and what I believe is important. I would think that their already exists many attributes within your institution, organization and approaches that should be considered when developing a badge system taxonomy. I hope this post has got you thinking about how you would create your badge system.

Open Badges: Step-by-Step

Over the last few weeks I have had the pleasure and opportunity to speak to a number of people regarding how best to onboard people to implementing the Open Badges Infrastructure (OBI). The participants of these conversations have been both Mozillians deeply involved in the project and potential partners who want to implement the OBI as a part of their project. I believe the most significant understanding from all these conversations, combined with my reading and research, is that a gap exists between wanting to implement and being able to implement. The Mozilla team in and around open badges has done a good job of putting together resources that cover the subject of how to implement. These resources can be found in four primary places;

• the open badges website
• the Mozilla wiki
• the github wiki
• and the open badges google group

In one particular conversation with Sunny (Product/Partner Manager, Open Badges) we talked about how best to close the gap for those who want to implement, yet are struggling to get over the first few steps of how to implement the OBI. There has already been a few people or groups who, with relative ease, have successfully navigated the documentation and source code to implemented both an issuer and displayer for badges. My investigations into why some people people have implemented with ease and others struggle is due to having specific technical understandings. The skills and knowledge required are an intermediate understanding of JavaScript, JSON and web development combined with a conceptual understanding of the roles (earner, issuer and displayer) within the OBI.

Steps to Wat San Goo, Mae Rim, Thailand.

What I really like about all this recent activity is it fits very well with where I am at in designing the OER for the OBI. I've finished the envisioning step and have moved into the planning step. And having had these conversations with a few partners and some Mozillians I have had a good amount of user and stakeholder engagement to focus my planning and design for the OER. This planning and design will focus on building educational modules to close this identified gap and engage others to support the building and testing of these modules. And to me (and I think others) the place to deploy these learning modules will be p2pu.

The proposed first steps will be (comments and feedback would be most appreciated);

• Step 1: Claiming a badge
  Create a hands-on familiarity with badges by earning a badge.
• Step 2: Technical Prerequisites
  Build a basic understanding of the technology behind open badges
• Step 3: Creating your site
  Fulfill the minimum requirements of the technology needed to host the ability to issue a badge
• Step 4: Issuing a badge
  Implement the technologies in your hosting environment to issue a badge
• Step 5: Earning a badge
  encourage learners to claim their issued badge and store it in the backpack
• Step 6: Managing your badges
  how to manage the badges in the backpack and make them available for display
• Step 7: Displaying your badges
  Put together the code to display your badges

For more detail to how this step-by-step guide is progressing follow along and contribute to the wiki page; https://wiki.mozilla.org/User:Prawsthorne/StepxStep Feel free to contact me if you would like to join-in, help out or test what will be created...

Open Badges: What I've learned so far

Over the last couple of weeks I've begun to immerse myself in the Open Badges Infrastructure (OBI) with two main goals;

1. Have the technical understanding to support the developer community who want to implement the OBI from the issuer, displayer and earner perspectives.
2. To develop a complete curriculum [as an Open Educational Resources (OER)] around how to implement the OBI.

My immersion has created a number of enjoyable explorations and I believe it is this broadness to my learning that has given me the most value. I have explored every path that I have discovered, and collectively they have allowed me to understand both the technical implementation and the rationale behind the OBI. The paths and lessons are as follows;

• open badges site - the openbadges.org site provides a great introduction to all the main concepts of open badges. It also serves as a launching pad, via the assorted embedded links, to deeper learnings across all subjects.
• open badges wiki - the open badges wiki provides all the information the site has with much more detail and additional links and documents. Particularly important with the open badges wiki is the get involved section that provides all the references someone would need to engage with the community. Also, it is a wiki so feel free to contribute or start building pages under your profile.
• community calls - if you can find an hour starting at 9 am PST on Wednesday, it is well worth your time to engage in a open badges community call. Also, a really good example of how distributed teams can work well together.
• open badges google group - when the time comes venture into the google group, you will be glad you did, there is great depth to the discussion threads. The discussions vary from the technical details of how to implement the OBI, through the importance of evidence, the idea of a federated backpack, to how to design the assessment. all good!
• github wiki - the github wiki gets into describing the syntax and technical details of the OBI. Venturing into this wiki requires an intermediate level understanding of web development and JavaScript. Even if you don't have an intermediate understanding of things diving in can add to the learning and bring insight to how things work.
• github widgets source code - so far my focus is on how to use the OBI (not how to contribute to the OBI). As my focus remains on the implementation side having the opportunity to review other peoples code serves learning about the OBI very well.
• github source - so far I haven't had the need to dive into the OBI source code. To me this shows the maturity of what is available as a code base and in documentation. To develop an understanding of things I don't need to look at the source code. This may come later when I start to push the OBI capabilities, but for just wanting to earn, issue and display badges the OBI can be learned without diving into the source.
• taking apart and editing JSON files - taking apart and playing with the issuer JSON can go a long way to building understanding. Create a .json file on disk and push it into the validator. Look at each attribute and think about how it can be used.
  

  {
    "recipient": "sha256$2ad891a61112bb953171416acc9cfe2484d59a45a3ed574a1ca93b47d07629fe",
    "salt": "hashbrowns",
    "evidence": "/badges/html5-basic/bimmy",
    "expires": "2013-06-01",
    "issued_on": "2011-06-01",
    "badge": {
      "version": "0.5.0",
      "name": "HTML5 Fundamental",
      "image": "/img/html5-basic.png",
      "description": "Knows the difference between a <section> and an <article>",
      "criteria": "/badges/html5-basic",
      "issuer": {
        "origin": "http://p2pu.org",
        "name": "P2PU",
        "org": "School of Webcraft",
        "contact": "admin@p2pu.org"
     }
    }
  }
  

• blog posts by mozilla team members - when you come across mozillians online or through a retweet or rss feed follow through and follow them or subscribe to their feed. Often answers to you questions may come from a current or past post. Be thorough...
• blog posts by badge followers (both critical and supportive views) - its a really good idea to seek out other views of things. And there is another side to badges, read posts that are both critical and supportive of badges. Deepening your understanding in this way helps to broaden your learning about badges.

What I've learned so far:

1. all aspects of the open badges and Mozilla learning groups members are outstanding. They are incredibly helpful!
2. you need to iterate around all the sites, groups, resources and references you can find. And loop around for second and third readings.
3. you need to be an intermediate level developer with confidence around JavaScript
4. you need to know a web programming language (Ruby, PhP, Python, Etc...).
5. Deep diving into the json files forces a deeper understanding of the OBI.
6. you need to be able to create a nice looking badge and save it as a png file.
7. you need to understand assessment approaches.

Open Badges: Issuer vs. Displayer

Discussions, readings, review and reflection continues to deepen my understanding of the Open Badges Infrastructure (OBI). One item that is important, and has been given considerable thought by the Open Badges team, is the difference between an Issuer and a Displayer. As you start diving into open badges it could make sense that the issuer and displayer could be the same entity. It kind of makes sense; if Girl Scouts Canada issued a whole lot of badges to someone, why wouldn't they also provide the feature to display the badges that had been awarded to this person (the earner)?

http://www.flickr.com/photos/eezpictures/3299183408/

The scout badge analogy continues to work well here. Once a badge has been issued to someone, where they display them and what they do with them through time is really up to the person who earned the badge. Upon reflecting on this I believe it would NOT make sense to leave the badge sash at the scout office because every time the badges were to be displayed the viewer would have to go to the scout office to see them. The better solution is to decouple the issuing of badges from the display of badges. This way the earner can choose how to display the badges for themselves;

• Determine where to display their badges (personal blog, facebook, other...)
• Grouping the badges (volunteer activities, webmaking activities, professional development, community involvement, learning milestones, coursework, etc...)
• Organize badges from different issuers to create a greater meaning (or meta-credential)

Even though having the issuer and displayer be the same entity is technically possible, it is a better solution to keep these two separate. This will allow the earner greater control over their badges and how and where they display them. 

Open Badges Interdisciplinary Opportunities

I'm still deeply entrenched in planning my Open Badges curriculum. And all this writing and reflecting has deepened my understanding of the OBI. The other day I took it upon myself to add to the Mozilla wiki page that describes getting started with open badges. This was a lot of fun and shows that my understanding of open badges has come a long way in a short time. That really is the spirit of Agile Instructional Design. Your personal learning begins the moment you commit to learning a subject and can very quickly develop into a deepening understanding.One of the tasks within the planning step of Agile Instructional Design requires some time looking for interdisciplinary opportunities.

To increase and broaden your learning it is also a good idea to bundle your personal learning across subjects you have already personally committed.The idea being that if your learning crosses subject areas it will deepen for the skills and knowledge are being used more broadly and within different contexts. Currently, my ongoing learning covers two main subject domains; folk music and dance, and mobile first web development. In each of these two areas I am currently focused on the following;

1. Folk Music and Dance
• I'll go enlist for the sailor - beautiful tune with a nice dance jig
• Folk style percussion instruments - well almost anything folk that can add rhythm
• Pipe and Tabor - if I had the time, I'd spend two hours a day blowing this whistle
2. Mobile First and related Web Development
• HTML5 - the latest (and most mobile friendly) version of HTML
• CSS - the always improving cascading style sheets
• Advanced PhP - mostly focused on building RESTful API's
• node.js - currently deepening my understanding of this JavaScript framework
• popcorn maker - hacking rich media into stories and music videos

The above list really are the things I spend my free time learning about. Of these I could include the following interdisciplinary opportunities to deepen my learning within open badges;

1. HTML5 and CSS3 to render the User Interface for my badge displayer
2. node.js to build my server side code for the issuer and host the backpack
3. popcorn maker to create some rich media learning resources describing the OBI

Agile Instructional Design: PLAN

A while back I wrote a post that elaborated on the flowchart I had embedded in a paper on how I envisioned Agile Instructional Design (AID). As I wrote the post I realized there was to much information for a single post. I provided a high level description of the AID flow within the first post with the promise to provide detailed descriptions of each step in later posts. This post describes in detail the activities performed and outcomes desired from the PLAN step of Agile Instructional Design.

PLAN - this is the process of taking the learning vision from the previous step of the AID methodology (ENVISION) and planning the learning journey. As was previously discussed the methodology is an iterative process that can begin as soon as the first words of the knowledge domain have been identified. As planning begins it is a good idea to review the learning themes and the learner roles. It is the time while capturing and documenting the vision that planning would begin. Often within these design processes (whether individual or group) that the main planning items are easily identified early in the process. Often these are not immediately articulated; yet, this is where peoples intuition becomes apparent. As you work through the planning step items that seem most appropriate from the envisioning step bubble up and become the items of focus. These items should be recorded for the next iteration of envisioning. The steps of planning are as follows, and some of these items may change from iteration to iteration.

1. Identify anchor subject - the anchor subject grounds the learning into a theme meaningful to the learner. A well chosen anchor will bring authenticity to learning and more deeply engage the learner through "role play" and bringing "fun" into learning. Finding an anchor that can span different course subjects (ie. science, language, history, maths, etc.) also allows the learner to explore the anchor from different perspectives which can deepen learning.
   
   Outcomes: a written description, rich-media artifact or some other method of capturing a description of the anchor subject. The anchor subject should provide a collection of user stories to help clarify and increase understand-ability.





Caribbean Pirate Map

2. Identify interdisciplinary opportunities and requirements - how can the anchor subject and knowledge domain as a whole span more than a single discipline? Can the learning methods, approaches and lessons be utilized so learning can occur in many different areas? If the anchor subject was "pirates" it could be discussed in all courses. Economics would talk about the financial realities of being a pirate and the greater economics of the time. Language Arts could speak to the languages of the Caribbean or the South Asian Sea. Geography could explore the different regions of the world who have struggled with piracy. History could look at piracy through time. Technology classes could look at piracy as it applies to the modern age. With a well chosen anchor subject the interdisciplinary opportunities are numerous and will deepen learning.
   
   Outcomes: a written list, concept map or other approach to identifying the interdisciplinary opportunities with descriptions of how they would be tied to a lesson or module.


3. Examine timeline, instructional strategies and research - There are many attributes toward determining the instructional strategies for any module, course or curriculum being built. The following are some of the attributes to be considered;
• Timeline and Schedule - how long is the course? the time of day? number of hours available?
• Geography - where are learners located? is this a classroom course, exclusively online, or blended? What resources are available given the geography?
• Access - what bandwidth is available? what technology resources are available given geographical restraints?
• Cohort - Who is the cohort of learners? how tech savvy are they? is discussion more appropriate?
• Pedagogical approaches - given the above restraints what will be the most effective learning environments. Should the approach be inquiry based, a MOOC, use constructivist theories or connectivist practices?
• Previous experience - Determine if there is research available for similar learning situations. What worked? How could things be improved? 
• Research Opportunities - Are you capturing information from this learning development project to add to the research? Are you contributing back? Are you being transparent?

Outcomes: a table, mind-map, story or other approach that answers all the above questions formatted in a way to deepen understand-ability.


4. Identify learning objectives and modules - once items 1 through 3 above are completed it comes time to review all the artifacts created and gathered from this step and the previous ENVISION step to identify learning objectives and learning modules. Keep in mind being agile, so the task of identifying objectives and modules can start at any time. Having stickies or a way of recording these for later review is a part of agility. Identifying objectives and modules should be fairly straight forward if the previous tasks and steps had depth. Surprisingly, the objectives and modules fall out of the information created and gathered.
   
   Outcomes: a written list of learning objectives and identified learning modules. This should be published and made available for feedback and collaborative efforts.

Remember, with Agile Instructional Design it is about the designers learning and being iterative. As soon as enough information is gathered to create and start building learning modules, these modules should be built. Agile Instructional Design is iterative and shipping learning modules often is a key measure of success.

Getting started with open badges

So I added a bunch of content to Mozillas wiki page describing open badges. This page had very little content other than an image and some links. I really felt it needed to have a non-tech-savvy upgrade. I did my best to put getting started with open badges into more lay terms. With a few additional edits, this is what I ended up with...

Getting Started
Being on the steep side of a learning curve can sometimes seem overwhelming. And jumping into learning about digital badges is no different. If you iterate around three main concepts, and with each iteration deepen your understanding all will be good. If you have landed here without first reading the badges about page, it is suggested you go back and read what badges are all about; About Badges.

The Three Main Roles 
There really is a whole bunch of technology that went into building open badges. Particularly, when you consider that all badges need to be confirmed as genuine and that loads of different organizations will be issuing badges. More on this as you deepen your understanding of badges. The first thing when developing an understanding of badges is to consider the three main roles of; earner, issuer and displayer. And how these three roles work together within the whole Open Badges Infrastructure (OBI).

The Earner
The earner is anyone who wants to earn a badge. And they are willing to focus their energy and make an effort to acquire the skills and knowledge that demonstrates their mastery represented by the badge. Badges are everywhere, and are particularly present in our youth. Girl Scouts can earn badges, Students in sailing school can earn badges, Swimmers can earn badges. It is these badge systems where people prove skills, knowledge and ability and from this they earn badges. If you want to jump deeper into understanding the technology behind the earner follow this link to the technical documentation of onboarding the earner.
and their Backpack
The earner will store their badges is a digital backpack. The backpack is the online digital place where the earner can store and manage their badges. By managing their badges they can be put into groups or be made private and not be available for display.

The Issuer

The issuer creates the badge, figures out what skills and knowledge are represented by the badge, and figures out how to assess (or prove) if a person has the skills and knowledge to earn the badge. The issuer has a lot of heavy lifting to do, this is because determining if someone has mastered the skills and knowledge and are deserving of a badge requires work and should be rigorous if the badge is going to hold value.

There are may ways to assess peoples abilities and knowledge. Figuring out effective ways to assess these is also the responsibility of the issuer. The assessment methods used for the badges available in our youth are proven and have considerable rigor. For example, the assessment of the skills and knowledge to get a scouting badge is done with well articulated criteria and assessment forms within a master - apprentice model. Once the badge earner has proven their skills and knowledge against the criteria as assessed by the master, they are issued a badge. It should be noted that there are many approaches to assessment and what is described here is only one approach. The important thing is that the issuer needs to figure out how to assess if the earner is deserving of the badge. If you want to jump deeper into understanding the technology behind the issuer follow this link to the technical documentation of onboarding the issuer.

The Displayer
The displayer provides the ability to display badges. This could be a social media site like facebook or it could be your own personal wordpress blog. The displayer will retrieve badges from an earners backpack and display them for all to see. The groupings and permissions around the display of badges will be determined by the settings in the backpack. If you want to jump deeper into understanding the technology behind the displayer follow this link to the technical documentation of onboarding the displayer.

The Technology

These three roles can be found in the diagram enclosed. The Issuers and Displayers are obvious as they each have their own box in the diagram. The Earner role isn't so obvious because, as a technology, the earner becomes the backpack. You could say the Earner is holding their backpack. From a technology perspective and an infrastructure view the Issuer is the provider of badges, the backpack stores the badges earned and the displayer shows them to the world. 

With a close inspection of the diagram above there are a number of boxes, lines, images, and text. All of these represent a piece of the technology that makes up the Open Badges Infrastructure. As you learn more about the badges technology you will become familiar with all the elements found in the diagram. Take the time to review the diagram, reflect upon the Earner, Issuer and Displayer roles and how they would interact to display a badge.

One question to really get you thinking is. "How do you determine if a badge is genuine?" Don't think about this from an open badges technology perspective, think about it from a real world girl scout badges or sailing school perspective. Think again, think further than if the badge looks official... "how would you really determine if a badge is genuine?"