BadgeKit basic components of the Information Architecture and supporting APIs
In an earlier blogpost, I shared our thinking behind our BadgeKit MVP.
Having gone through the exercise of defining the basic user interactions that we wanted to support in our March 2014 release, we started to think through the site architecture that would house the said user interactions and the supporting APIs that would help power the experiences.
To sort through this I took each MVP user interaction from my earlier blogpost and mapped it against site and API requirements as follows:
1. We want an issuer to visually design the badges and define the criteria for earning them.
At the very basic level, there should be a page within badgekit.org in which the issuer should be able to do the following:
Start visually designing a badge. Think any of the following badge design tools: openbadges.me , MakeBadges , Achievery , CSOL Badge Studio
Define the metadata that will be embedded within the badge aligned with the open badges standard.
What if the issuer wants to save badges mid-design? Then the issuer should be able to log in with some identifier and save the badges that have been created whether they're simply in draft form or complete. As such, issuer should additionally be able to do the following:
Save created badges in various stages of design
Access, open and edit previously saved badges
This badge design and defining experience should be supported within a badgekit.org page.
2. Learners can then apply for the badge by submitting evidence and their e-mail address
To support this earner interaction, we thought through what the issuer would need from BadgeKit.
Following user interaction 1 outlined above on the badgekit.org site, there should be a page in which the issuer can see see a listing of all the badges they've created.
On the issuer site (not the badgekit.org site), there would need to be some ability for the issuer to pull in this listing of badges created (with some level of filtering) through an API that the potential badge earner can see, learn more about and apply for, again on the issuer site.
So how would BadgeKit provide support for this?
There should be an API that enables the issuer to pull in all the badges they have created from user interaction 1, onto their site.
From there, the API would support the following user interactions:
Potential badge earner could apply for badges that are apply-able.
Potential badge earner could submit all required evidence in order to apply for the badge. n.b. The evidence won't be going into the API, simply links to the evidence from the backpacks hosted by the cities.
Potential badge earner could save their badge application.
Potential badge earner could submit their badge application.
The submitted badge application would then go into a queue in a page within the badgekit.org site that mentors/assessors can access which leads to the next user interaction.
3. Mentors or peers can review the badge applications against the criteria. Once criteria is met, the badge will be issued to them (email being one method).
Within badgekit.org, there should be a page that mentors/assessors with the appropriate permissions can log into and access the queue of earner submitted badge applications.
Within badgekit.org, there should be a page in which the issuer should be able to do the following:
Grant appropriate access to designated badge application mentors/assessors.
Define rubrics for mentors/assessors to assess badge applications.
Define threshold for badge awarding and rejection.
Define pre-canned feedback for badge applications by under 13 earners.
Having done that, mentors/assessors with the appropriate permissions should be able to do the following:
Review badge applications against a rubric.
Provide feedback to the badge applicant.
Award or reject badges based on assessment rubric.
Once badges are assessed, the badge earner should get a notification informing them of the badge acceptance or rejection along with appropriate feedback depending on whether the earner is under 13 or not.
4. Recipient accepts the badge and sends it to their backpack - badge acceptance flow from email
On the issuer site, there should be a badge detail page (pulled from the API mentioned in user interaction 2, that is linked from the notification email sent from user interaction 3, that should enable the following:
Earner clicks on link included in badge award notification email.
Earner lands on issuer site with badge image and detail information that prompts earner to send earned badge to backpack.
Earner clicks prompt which triggers badge acceptance flow into the Mozilla Backpack or city backpack.
To support this experience, the issuer would need to integrate with our Issuer API which enables this badge acceptance flow. The details of badge acceptance into city backpacks is still being ironed out as we sort out the details of federation so more to come there.
5. They share their badge on their [Facebook or even LinkedIn hey!] profile.
To support this experience, we’re thinking about this in a couple of ways.
The issuer could integrate with our Issuer API which currently enables a version of this flow triggered within the Mozilla Badge Backpack site. Either that or the federated backpack they're hosting has sharing api's enabled.
But we’re thinking about ways in which a badge can be shared out to various web properties without reliance on the share functionalities of the Backpack, whether it's the Mozilla one or the city one. We could enable embed and baked badge download and upload features through our APIs. The details of share and the site properties in which they should occur are still in the process of being sorted out.
=================================================
Having gone through the user interaction steps originally mentioned in the BadgeKit MVP flow, what I’ve found to be missing is the experience of the issuer generating claim codes and issuing badges based on an earner identifier like email. So let’s add those.
6. Issuer should be able to generate claim codes for badges created in user interaction 1, outlined above.
To support this, within a page on the badgekit.org site, the issuer should be able to do the following:
View all badges created from user interaction 1.
Generate claim codes for each badge.
Generate claim codes manually or automatically.
7. Issuer should be able to issue badges based on email for badges created in user interaction 1, outlined above.
To support this, within a page on the badgekit.org site, the issuer should be able to do the following:
View all badges created from user interaction 1.
Issue badge created with earner email.
=========================================================
The above was an attempt at a basic understanding of the required components of the badgekit.org site architecture and supporting APIs. From it, we've come up with the following Information Architecture framework sketched out by our Creative Lead, Jess Klein.
Each week we get a little bit more detailed with the product definition and going through this is all part of the process. We welcome your feedback, comments, questions and concerns!