The Open Badges Directory → Laying the foundation for cool open badges applications
As open badges continues to gain a foothold in the world of digital credentialing and skills recognition, more and more folks have expressed interest in accessing a list of all the earnable open badges out in the wild. Earners, issuers and employers alike want to see the various badges available to earn based on certain search parameters, find out how to earn them and be directed to the appropriate places to dive deeper and start learning and earning.
One thing that the ecosystem was clearly in need of was a directory service that catalogued and listed all the open badges in the ecosystem with APIs that would enable other organizations to build cool applications on top, such as a badge-based pathway generator, an employer tool that facilitates connections with earners of certain badges, a badge or pathway discovery engine, etc.
In response, the Open Badges Directory Working Group was formed to precisely dedicate itself to prototyping this much-needed directory offering.
*** n.b. The documentation for the Open Badges directory can be found here: http://directory.openbadges.org and examples of it in use can be seen here: http://directory.openbadges.org/examples/browser/#/recent and here: http://achievery.com/discover.
In Cycle 1 of the Working Group, we had to figure out the scope of the project we wanted to tackle. The following were some of the questions we needed to answer to determine the MVP (Minimum Viable Product) feature set.
What are we listing?
What is the barrier to entry for badge issuers?
Where does the directory end and other potential 3rd party services begin?
I’ll share the line of reasoning we went through and where we netted out with each of these questions below.
What are we listing?
This seems like a simple question but actually is a bit more layered. This has to do with the way in which Open Badges technology is set up. The fundamental building block in the badging ecosystem is the assertion. The assertion describes 3 things;
who a badge was awarded to
what that badge represents —> Badge Class
who issued the badge —> Issuer Organization
The assertion essentially ties all these 3 different pieces together in a unique badge instance that is tied to a specific badge earner.
*** n.b. More information can be found in this wiki guide written by Sue Smith: https://github.com/mozilla/openbadges/wiki/Assertion-Information-for-the-Uninitiated
In that case, what do we list?
Badge Instances that tie a badge class to an earner?
A general Badge Class that explains the badge?
Or do we also include issuer information in the directory too?
While there’s a case to be made for all three options, we decided that the MVP of the badge directory will simply list the Badge Class to start, with Badge Instance and potentially Issuer Organization as subsequent additions. This was because, while listing Badge Classes, depending on method of implementation, has a dependency on the Issuing organization, listing Badge Instances has a dependency on the Earner to make the badges they earn, public. We thought the latter was a bigger initial barrier that the directory would have to overcome as opposed to working with the issuers.
What is the barrier to entry for badge issuers? What does the badge issuing organization need to do in order to be a part of the directory?
This question presented us with a few options as well:
Crawl the open web and look for the open badges assertion file type, automating the listing process for the issuer: While this option eliminates the barrier to entry for issuers, it is a resource intensive and expensive undertaking as the crawler would have to scour millions of IP addresses looking for certain file types. This didn’t seem like the right approach for the initial MVP.
Issuers register their badge classes with the directory and provide the paths to where their badges are stored: This is the least developmentally intensive process but at the same time we are dependent on issuers to come to us and register their badges. The barrier to entry for issuers is put in place and we must provide them with a value proposition to register themselves and their badges.
Issuers only register themselves and a simple crawler would know what domains and IPs to crawl: This is a bit of a hybrid solution of the above 2, utilizing crawling with minimal issuer cooperation. Even so, without a robust value proposition presented to issuers, we still have to reckon with the initial barrier of registration that they must overcome.
We opted for Option 2 in this initial iteration because it provided us with an opportunity to work collaboratively with the issuers in the ecosystem to highlight their badges and proof of concept the directory to a broader audience. Not only that, it saved us from overexpending our technical and development resources which would have been the case if we opted for Option 1.
However, we have seen rather slow responses from issuing organizations who want to register. We are in the process of evaluating the barrier(s) to entry, as well as the value proposition for issuers, in order to figure out next steps.
Where does the directory end and other potential third party services begin?
It’s easy to get excited about a directory offering because of its potential. Say I’m a learner and I want to find out what badges are out there that I can earn that will make me more competitive in the job market. I hear user experience design is a growing field, so I go to the directory, input a few keywords like ‘UX’, ‘user experience’, and ‘UI’ to see the list of badges in the ecosystem related to my search. What next? Does the directory offer me a cool UI with a list of various badge pathways around user experience design I can tackle? Can I save or favorite the badges presented so I can come back to them later?
What level of end-user experience will the directory enable? Are the cool, personalized experiences mentioned above, something an application on top of the directory creates while the directory is simply providing the service of listing open badges with some search and filtering?
Is there an end-user interfacing component to the directory at all or should it simply be a list of APIs for developers?
We all agree the API component of the directory will be critical for encouraging application development, but at the same time, we felt we needed some level of a UI to help folks understand and grasp the fundamental concept behind the directory. As such, what we ended up creating is a simple user interface that lists all badges with basic search and filter capability but nothing beyond that for now.
*** n.b. The API Explorer illustrates how the API works.
==========================
Having released this initial MVP that provides the broader ecosystem with a production beta version, we’re eager to continue development of the directory. Focus areas include the listing of badge instances in addition to badge classes, additional API endpoints, and exploring ways in which we can lower the barrier of entry while clearly articulating the value proposition for badge issuers.
There is still a lot more work left to do to have a full functioning directory product. But the prototype is a strong proof of concept and has taught us a ton. Needless to say, none of this could've been possible without the leadership, dedication and hard work of Kerri Lemoie from Achievery.
While Cycle 1 has ended, we still have an active mailing list, so please join the conversation!