Badge Design

At this point, a grab-bag of ideas (that would be good to mind-map together):

  • Integrate with Open Badges
  • Integrate with Badge issuance/display via Buddy Press
  • Involves sharing of user profile / user identity and a single identity that holds the badges.
  • Some thoughts toward a Badge DB Design

Overall Picture



  • Member — Someone who has identified themselves as the collector of the badges. Badge Owner might be a better term.
  • Principal — the unique identifier under which badges are earned.
  • Register Device — associates the apps with the principal (representing a user) who accumulates badges.
  • Badge Display
    • In-Game Badge Display - At least an Icon for the badge with links to the details.
    • WordPress Badge Display - Full details for the Badge; this is the reference page for a badge.
  • Publishing Badges — happens independently of the awarding of the badge, and allows badge owners to "carry" their badges around and if they want, present them via Credly or Linked-In.
  • Authorization(multiple levels)
    • Once registered, the device becomes the credentials for logging in. It would be possible for someone to take your device and collect badges for you, but it is your device that performs the work of earning the badges.
    • Ownership of a badge can authorize access to portions of the application.
  • Badge Details per Principal — along with Evaluation Criteria, this may be worth its own diagram:
    • Expect that most of the association between the WordPress part and the Game part will take place via an API.
    • Synchronizing the two will be interesting. Need to lay out what data is recorded on each side.
  • There are two Databases: One we control and one that BadgeOS controls. This is a fundamental design decision that allows us to upgrade BadgeOS with minimal impact to the Game database.
    • WordPress BadgeOS Events are part of the BadgeOS plugin. The plugin has workflow built-in.
    • Game Badge Events database holds what we generate per principal playing the game or maintaining courses.
  • Evaluation Criteria determine which Game Events are turned into BadgeOS Events
  • Badge Maintenance and Badge Issuance are defined by the BadgeOS functionality.

Risk Assessment

Map out the data required

  • Picture of where the records are stored.
  • Evaluation Criteria may be maintained to some extent within BadgeOS. How much can be leveraged?

Prototype this with some candidate badges

  • Learning how to organize these will be a big help.
  • Learning where time is consumed will be a big help.

What are the pinch points that are unproven

  • What will the API look like?
  • What implementations look shaky?
  • Security implications

Badge capture

  • Annotation of classes so events are generated automatically when someone commits updates, visits pages, or whatever within the API against a session which is tied to an account.
  • Whiteboard image
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License