I have been thinking about how best a project or organization can integrate with open badges. This isn't the bits and bytes type of thinking, but the technical project management thinking required for the near-term (6 -12 months) success of the OBI and all projects that integrate with the OBI. Keep in mind this is a list of what I would focus upon as you work toward success. It is my approach as a technical architect and senior project manager and not Mozilla's or the OBI teams. I see these tasks as a benefit to the Open Badges project, as they will bring further insight into the design of the project, provide further requirements, and put the OBI through is paces before it is considered a production release.
1. Figure out the data model of your badge system design
This may require some technical skills and knowledge (and I suggest you find them at this time) to understand the data requirements of your badge system design. Do this without making reference to the existing OBI metadata specification, for that may compromise the vision of your badge system design. And you should stay true to your badge system design without restraining it by the existing Mozilla OBI specification. Keep in mind the OBI is in pre-release and really needs rubber-hits-the-road insights into how people want to implement badges. Once you have this data model try and map it to the OBI metadata specification for issuing a badge. If it doesn't fit, let the OBI team know via the
google group, this could kick off an interesting discussion.
2. Start loading (and deleting) data
I see two kinds of badging systems. Those that already exist; like girl guide badges, khan academy badges, stackexchange badges or military badges. And the badges systems that don't yet exist. These existing badge systems have a huge number of badges already stored within them. If these badges are to make it into Mozilla Open Badges, we need to start loading them into the OBI now. This attempt to mass load badges into the OBI should come as a gift to the OBI team. Better they start dealing with the issue of thousands of badges showing up while still in pre-release than having them show up once Open Badges is officially released and bringing the whole OBI to a halt. If you are going to load data, you should also be able to delete the same data. The ability to load data should be a feature available within the OBI. A test environment should also be available, so partners can test their data loads, and delete the data that was loaded. The testing of data loading is a blog post in itself and beyond the scope of this particular tome.
Keep in mind that manually entering badges (one by one) is also a good idea as it will utilize the same process as the earners will use for adding badges to their backpack.
3. Build an automated testing approach
If you have already started working with the Mozilla Open Badges Infrastructure (OBI), or are considering it in the next short while, you should consider yourself an early adopter. And given this type of role expect things to change within the OBI, as it is currently a pre-release version. Given this early release things can change that
may break the code at your end of the integration. Building an automated testing approach will
yield great benefits as it will reduce the downtime of your system, increase the quality of your code, and provide early warning if the system elements beyond your control have changed. These automated tests could be built for both your internal system and the API calls you make to the OBI. Once these automated tests are built, it would also be beneficial to run them against the OBI at scheduled times to ensure the programatic assumptions made by your system are still valid against the OBI.
4. Determine where and how you want to encourage the display of your badges
Once you have badges "loaded" into the OBI and have viewed these badges in the earners backpack it becomes important to display the badges in a variety of locations. There is
a growing number of widgets built for badge display and with the variety of methods for display you never know where your badges will show up. It is important to test these different display approaches and as a part of your issuing site encourage people to use specific displayers. You may also want to build or integrate your own displayer. What is important here is that you have displayed your badges in a number of different locations for testing purposes.
5. Advocate for other attributes to be added to the OBI metadata specification
Learning rarely occurs in isolation and learning is always related to other or previous learning in some way. The current metadata specification has a badge standing on its own. There is currently no attribute within the badges metadata that allow for it to link-to, be the detail of, or cluster-within another badge or set of badges. The OBIs' criteria attribute is being extended to allow
blobs of data, so you could store this badge inter-relationship and linkage data in this criteria attribute. I believe this approach will store this information in the wrong place, for issuing systems would then have to store and maintain the data about these relationships of interest. A badge should know for itself if it exists in relationship to other badges.Erin Knight has created a great blog post describing the
webmaker badge system design.
 |
| WebMaker Badges show a system design where badges are linked, clustered and the detail of a cumulative badge. |
6. Encourage the completion of badge validation
Over the last year there has been much discussion regarding badge assertion or validation. The idea being that it can be determined if a badge is still valid through time. A number of approaches have been tabled, and agreement to the value and approach to implementation of this feature has yet to be agreed upon. I believe it is an important feature, for it would be nice to click on a badge from within the backpack or a displayer site and be notified if the badge is still valid.
If you have further questions or require assistance please do not hesitate to contact me. I will be very happy to assist.
