-
Notifications
You must be signed in to change notification settings - Fork 263
v1.0 Features List
We have taken both the feedback of the larger open badges community as well as that of the DML grantee teams and have come up with the following issues list for release in Q1 2013 as part of OBI v1.0:
COPPA, as many of you well know, has been very front of mind for us. We’ve talked to many of you who work with children under 13 to gather information, we’ve spent countless billable hours of our legal counsels’ time diving into this into greater detail and studied many existing COPPA compliant technical implementations.
Questions around children’s online identities are complicated ones that have yet to be resolved. At this moment in time, no children online identity providers handle identity and data protection while allowing sharing capability in an open Internet environment.
Not to mention, COPPA is a moving target. As we dove deeper into understanding the complexities around youth and online identities, we realized that this is something we cannot undertake alone. We need to work with the broader community of stakeholders, educators, identity providers and policymakers towards a collective solution.
As such we will be developing a cohesive stance towards COPPA which we will share out with the community soon. More to come here.
Many members of the community requested an additional optional metadata field that would indicate standards alignment of that badge. For instance if the learning content behind a Buzzmath badge that was earned reflected how the earner learned how to “Rewrite expressions involving radicals and rational exponents using the properties of exponents”, that directly aligns with Common Core Standard, CCSS.Math.Content.HSN-RN.A.2.
So Buzzmath, would likely link to the Common Core Standard url [n.b. specifics tbd] in this new standards alignment metadata field.
We think there are opportunities for this field beyond formal standards alignment. Our Sr. Director of Learning, Erin Knight will be writing more about how this field can be relevant to you so again, more to come here as well.
As we think about badge organization and badge retrieval/discovery, we start to think about the different pieces of relevant information, i.e. data, that would help enhance this experience. Many of you have brought up the utility of creating a badge categorization or taxonomy of badges. We may choose the option to create a controlled vocabulary or take a folksonomic approach. We will be going with the latter and iterating based on how the community starts to utilize this field.
We take accessibility considerations seriously and will comply with 508.
We will have Facebook display integration by spring 2013. In actuality, a big part of this is wrapping a great user experience around how a badge earner pushes their badges out to Facebook and how that can be distinguishable from a simple status update.
We’ll share out interim releases with the community for feedback.
Signed badges will be a part of the Q1 2013 release schedule. As Brian mentions in the github issue, technical implementation is actually not the most challenging part. We really need to ensure issuers who are interested in signing their badges know where to start and how to go about making badges with signed assertions. The related documentation and tools development is key. We’d love for those especially keen on signed badges to provide feedback and support for this development.
Currently a badge earner must deliberately push every badge earned into their backpack (batch approval does exist today, however) which could be a clunky user experience. With auto-push, earner-approved issuers will be able to automatically push earned badges into the earner’s backpack.
VIII. Revocation of badges -- Pushing post v1.0 for now. Complications discovered and need to punt for now.
When an issuer mistakenly issues the wrong badge to an earner, the method of revocation is that they go ahead and delete the assertion file. From the earner’s standpoint, that badge still exists in the backpack but if they want to display it out, the assertion file will not exist and it will be evident that the badge is not valid if anyone bothers to check. However problematic to all of this is that, a revoked badge is not obvious. There’s needs to be a better user experience around badge revocation. We will be including this in our next release.
Similar to badge revocation, the treatment and user experience around badge expiration is not clearly defined yet. We will be building out the new UX around badge expiration as well.
All these issues are trackable on our github issue tracker which you can find here.
We’ll keep you all in the loop with updates as many of these items require followup conversations and separate blogposts so stay tuned for more!