Badge Design

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

  • Integrate with Open Badges via BadgeOS and the Award Badges API
  • 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

badges-and-accounts.png

Topics

  • 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.

Implementation Details

  • Rolled-up Badges
  • Badges that a user would be interested in displaying or carrying around can be presented separately from the constituent steps. For example, for the Seeker badge, the user would need to install the app along with page visits and other tasks. We don't want a "badge" for installing the app. We want a badge for all the pieces added up into an accomplishment. The constituent steps can be achievements with colorless icons that are hidden from the user.
  • There is the ability to award badges by making a GET call from the game application. The GET is made with the following query fields:
    • URL: wp-admin/user-edit.php
    • Data
      • user_id
      • action=award
      • achievement_id
    • Housekeeping
      • wp_http_referrer
      • _wpnonce
  • The ability to flag visits to specific pages is limited. The LearnDash may be appropriate for most complicated visits, but it should be possible to trigger a server-side call to the Award Badges API from any page that I want. Perhaps a widget that links to the achievement being given.
  • For posts to social media, I'd like to automate the sharing from the app so the app is able to trigger the call to the Award Badges API.
  • Points are accumulated across the entire constellation rather than totalled according to some categorization or classification. There are no separate buckets for points. This means we'll want to decide on a specific meaning for the points and only award points in that category. There may not be badges associated with reaching a certain level of points, although it sure seems like this would be a useful thing.

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.
  • AOP Modules committed as part of CA-335 (PR on GitHub)
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License