Thursday, March 6, 2014

Designing BadgeKit

After several months of hard work by the Open Badges team, we are announcing that BadgeKit is  available for access to Private Beta. This means that BadgeKit is now available in two forms:  a hosted version of Mozilla BadgeKit available in private beta for select partner organizations that meet specific technical requirements, and anyone can download the code from GitHub and implement it on their own servers. 

BadgeKit is a set of open, foundational tools to make the badging process easy. It includes tools to support the entire process, including badge design, creation, assessment and issuing, remixable badge templates, milestone badges to support leveling up, and much more. The tools are open source and have common interfaces to make  it easy to build additional tools or customizations on top of the  standard core, or to plug in other tools or systems.

From a design perspective, this milestone represents refinements in user research and testing, user experience, user interface and branding. 

We did user testing with members of the Hive in Brooklyn.
In preparation for this release, we conducted extensive user research to define the needs and goals for badge issuers. This work, led by Emily Goligoski, helped to define requirements for the BadgeKit offering as well as inform the user experience. The research was done using a variety of methodologies, however, it is worth noting that all of this work was done in the open. Emily organized distributed user testing in key markets such as New York, Chicago and Toronto to do everything from needs analysis to accessibility and functionality testing. The Open Badges weekly community calls were leveraged to pull in input from the highly motivated research and practitioner cohorts. Much of the work is documented both on her blog and in github. We paired every implementation milestone with some form of user testing and iteration. While this may sound obvious, it was a new way of working for our team, and I can unequivocally say that the product is better because of this practice. User research and testing did not happen in a bubble, but rather it became completed integrated with our design and implementation cycle. As a result, developers and designers became comfortable making informed iterations on the offering, as developers, designers and team researchers all participated in some form of user testing over the past three months. 

As a direct result of the extensive research and testing, the user experience for the entire BadgeKit offering was deeply refined. This work, led by Matthew Willse introduced some new features, such as badge “templates” which give the ability for any badge issuer to clone a badge template and remix it. This gives us the unique ability to offer template packages based on common badge requests from the community, as well as eventually to empower the large Open Badges ecosystem to develop badge templates of their own (and perhaps explicitly state how they are comfortable with their content being shared and remixed). One component of this work that evolved as a direct result of testing, was the increased attention to copy. Sue Smith led this work, which entailed everything from tool tip development and a glossary to API documentation. Considering that BadgeKit takes an issuer from badge definition



and  visual design



 to assessment and issuing,

designing the user experience was no small effort and the attention to detail combined with designing in the open - proved to be a solid approach for the team. 

Perhaps the most obvious design component of this release is the user interface design and brand definition. Adil Kim kicked off this work with an exploration of the brand identity. BadgeKit is under the parent brand of OpenBadges, which sits under the even larger parent brand of Mozilla - which gave us the constraints of designing within the brand guidelines. After exploring options to represent the visual metaphor for this modular system, here is the new logo:



The logo is meant to evoke the imagery of both a badge as well as a tool in one glance. For the untrained craftsperson (ahem) - while gazing into the mark - you will see a bolt . This connotes that BadgeKit is a tool, something that allows you to dive into the details and construct a badge, and a system for your community. The logo incorporates the palette from Mozilla Open Badges, in a playful mobius - at once implying that while this is a handcrafted experience, it is also a seamless one. This logo nicely fits into the larger brand family while reading on it’s own, as if to say, “hey, BadgeKit is the offering for badge MAKERS, dive in and get your hands dirty!” 

The brand is in turn extended to user interface design. The overall art direction here was that this needs to be clean, yet approachable. We know that many organizations will not be using all of the components in the interface directly on badgekit.org, however, the design needs to take into account that everything needs to be accessible and read as remixable. Some details to note here are the simplified navigation, the palette and subtle details like the ability to zoom on hover over thumbnails. 

It’s worth noting that while Emily, Matthew, Sue and Adil , as well as Carla, Meg, Erin, Jade, Sabrina Ng, Chloe and Sunny were invested in much of this design work, there was an intentional yet organic partnership with the developers (Zahra, Erik, Andrew, Chris, Mavis Ou, Mike and Brian + many, many community contributors) who were doing the implementation. We had weekly critiques of the work and often engaged in conversation about design as well as implementation on github. 



Another component of this work is looking ahead towards future features. Chloe Varelidi lead work here thinking through the potential for badge and skill discovery. Under a grant from The Bill & Melinda Gates Foundation, Chloe and her team are thinking through ways to represent earner pathways. This eventually will be leveled up into the core BadgeKit offering, but you can start to dip your toes into those features by checking out the work here.

And the good news is that design never ends! Design isn’t just a destination, it’s an invitation to a conversation. Check it out, let us know what’s working and importantly, what’s not.

Thursday, January 9, 2014

The Participatory Design Culture and Terms of Badges

As we all know, the Badges project seeks to provide users with a mechanism to shape their online identities: showcasing the skills that they have earned over time or in the case of an issuer, the skills that they might have to offer. 

So let's take a second to talk about collaboration -- or as I like to think of it: the conversation:

By nature, badges are a participatory design project. From its very conception, the project was designed by and for the learning,  design and tech communities to help ensure that the product that was ultimately designed met their needs and was in fact usable. 

However, Participatory design also requires user - generated content for culmination. Every badge is, in essence, an invitation to a conversation. For example:  I make a badge with some basic criteria (this is in essence a "call to action")  , and then a maker responds to the call with evidence (like a   photograph), and then I react to the response with a conversation about  that data.  
 
Badges say: "User generated content : you complete me. "
This call and response culminates in co-authorship of a badge that then has the ability to be viewed by any viewer in a way  that  allows them to be kind of like an eavesdropper on the  conversation.
This leaves us with questions about "ownership."  This question is more than just legal.  It's the foundation of the entire project.  

The notions of Participatory design + ownership require developing a community of practice around: (1) establishing authenticity (2) engaging in collaboration/remix culture and (3) attributing content ethically.   

I believe that Open Badges needs a method to instill the practices of remix and participatory culture that are at this project's core.  This project seeks fundamentally -- to show what you can do!  If I can put up a badge that says I can do X but I can't do X,  (or says that I am an expert judge of this skill) then the badge is meaningless.  This comes down to ethics for badgemakers 101 :) 

Henry Jenkins said that "Everyone sees the future will be more  participatory, but we are fighting over the terms of participation."  I don't know what the best terms of co-creation and remixing are, however I am interested in considering the opportunity that we are providing to badge makers, who are engaging in conversation via the vehicle of the medium. 

Through the exploration of co-authorship and remixing practices that are already happening or are desired, I suspect that we can start to propose some options for flexible options of copyright or licensing.

Before  I get too far along in the solution, let me guide you through some  potential use cases for participatory design within the badge making experience.

  • As a badge issuer I might want people to:
    • be able to use my badge 'as is' and re-issue it as their own.
      • They can re-use the art
      • They can re-use the metadata
      • They can re-use the badge name 
      • They can re-use the badge criteria
    • be able to 'fork' and modify my badge and re-issue it as their own.
    • be able to tweak my badge's metadata
    • be able to publicly issue my badge
    • be able to only issue the badge privately 
    • use the badge artwork that I designed
    • be able to issue this badge to <13 span="" users="">
    • be able to issue this badge with age restrictions
    • be able to issue this badge only to >13 users (etc)
    • be able to localize the badge

These are all interactions that could impact a license. What is implicit here  is the desire to freely circulate and allow for tinkering of content.  Without the free circulation content, participatory culture cannot  exist. After  Connected Educators Month, Chicago Summer of Learning and general badge issuing in the Hive we know that there is a  desire to  "fork", "clone" or "copy" badges or parts of a badge. We have already  started to deal with licensing issues with regard to badge  imagery -  utilizing icons from the Noun Project and Subtle Patterns, however we  know that there is a large scope for metadata that could in fact be  cloned or forked.  

Let's  take a look at the badge studio wireframes to see where there are  licensing touchpoints in the badge making process. These wireframes were  designed by Matthew Willse and will be incorporated into the upcoming  release for BadgeKit. Some of the ideas represented in these mockups  will be implemented in a future iteration of BadgeKit. 





   
As a badge maker is using this part of the BadgeKit site, they can define  many parts of the badge - from visual design to badge description.  Additionally, as you can see in the wireframe, in the optional  information we could enable users to add licensing and set parameters  for the project. This is really not an answer to the intellectual  property question, but just some context.

Currently there is no way to credit someone in any form in components/ or a whole badge through using the tools that we have developed. So, without clearly attributing ownership, the wrong person could be credited as the maker, etc

I believe that a creative commons license is the direction that we should head with this project, however, there are many existing forms of licenses that support creative digital content and I want to go over how I came to this decision. *You can scan my overview in the etherpad.

  • Pros: automatic,  the default, commonly understood 
  • Cons: Doesn't encourage this type of creating

2. OPEN SOURCE  + Copy Left  (SOME RIGHTS RESERVED)
  • Pros:
    • More closely matches this project's underlying purpose--cooperation, collaboration...
    • This sharing model allows people to quickly use, change, and share badges
  • Cons:
    • Seems to apply more acutely to the core software (vs. the bi-product) 

3. Badge Common License (BCL) *something i totally just made up 
  • PRO: A unique license structure could allow users to badge component parts or whole badges.
  • CON: This  seems a bit over the top, considering how many great  licensing frameworks are already in existence. This would be another thing that  badge issuers would need to conform to, and really, who is going to police it ? 
    The response from my colleague Michelle Thorne was so strong, I have to add it here:  " Please, please, please don't make a new license! It will cause confusion and lack of interoperability. This is more restrictive than all rights reserved. Instead, consider a "badge licensing policy" which suggests how to license and attribute based on existing licensing standards, like Creative Commons."

This leaves me to my choice, the: 

4. CREATIVE COMMONS LICENSE -which is actually not a single license, but many licenses. Lawrence Lessig founded the free culture movement  to promote greater legal freedom in the reuse of published content, which later lead to the Creative Common flexible"licenses" that offer a range of legal protections..

  • Pros: 
    • Alligns w/ this project's purpose 
    • Flexible, so that it offers a media maker the ability to state what level of remixability she is comfortable with
    • Allows someone to fulfill ambition of encouraging dialogue, collaboration, etc., w/o sacrificing control, etc.  
  • Cons:
    • New, not universally recognized or understood --> I'd argue these are some of the best known copyright licenses with lots of adoption. Education space already using widely.
    • Not made for source code. So, worth considering how to use CC for creative work (like badge design and descriptions) and source code (but not metadata) like the OBI. 

As I mentioned earlier, my goal is to get a sense of the options available to us so that I can incorporate it into the software. This will allow us to start to develop a community of practice around attribution.  At the moment, I feel that we should go with creative commons licenses. 
That said, I still have a lot of questions in terms of application. For example, should the software allow for different operations to have different licenses? or What about when a badge earner submits their content for review, does this part of the conversation have a separate license? 

I would be interested in hearing about additional use cases for badges remixing, co-authorship and cloning and hearing more thoughts on licensing and copyright. 


FURTHER READING:

  • Elkin-Koren,  Niva. "Intellectual Property and Public Values: What Contracts Cannot  Do: The Limits of Private Ordering in Facilitating a Creative Commons." Fordham Law Review. (2005): 375.
---------------
Please note: I am not a lawyer, nor do I pretend to be. I am merely researching the subject.

----------------

Monday, December 2, 2013

Brainstorming on Dashboards

During the summer, I spent some time thinking about badge directories and dashboards. The general idea was to prototype a tool for badge earners to make sense of the larger badge ecosystem and in turn to create an integrated dashboard that would help them to collect, maintain and analyze their personal data on their learning, goals and skill acquisition.

Initially I had come up with a few ideas for this dashboard:

a. focusing and personalizing skill search. Here, the user might type in skills that are of interest to them and then popular badges would appear. I like exploring the interaction of incorporating some narrative elements into this framework. Here, instead of just a search box - you have a statement of intent. 

-1 


b. pathways focused -  This mock up lays out skills you already have and then upon click/hover you can see where your skills could lead you. This is personalized approach, so once you log in, it will display a visualization of skills that relate to your data. However, if you are not logged in, it could display popular or trending skills or even .. geolocate badges based on your location.


-2 

c. Toggle vision - this gives you the chance to explore what is available in the ecosystem as well as in your personal badge library - as a list, as a visual display, and on a map.

-3 

d. Whimsical Exploration - still playing with the theme of exploration, discovery and happenstance - this is kind of like a wheel of fortune. Each node coming out of the circle lists skills and then if you are logged in and in fact have the skill, it will be notated. There is a natural progression from this view to a more sophisticated learning pathways exploration. 

-4 


e. Your (data) garden - This one is a little crazy - but imagine that all of the trees below represent your skills at different stages of growth. You can have "community" gardens as well as "secret gardens" - giving you the ability to curate what data you are in fact sharing. Here you can also set goals, be informed about your "garden health" - which might just equate to giving feedback on various goals that you have set up for yourself - and tool tips - which could be mentorship or coaching based on your goals. There's a lot of metaphor going on here and it probably would be a brain game to figure out how to design it .... but this is just a sketch, so wha ha ha haaaa.


-5 


So - the Summer came and went and I thought about these prototypets a little bit more. More specifically, I started to consider what a dashboard and a discovery feature would mean in the context of something like BadgeKit. The goals of the dashboard, by nature would change to accommodate an issuer (as opposed to an earner). I think that these explorations are still totally valid and even hackable to modify for this new lens. Some of the goals for the user might include:
  • keeping track of the badges that they are offering
  • getting notifications regarding badge assessment needs
  • analyzing trends for badge earners. 
  • sharing rights for admin functionality. 

While I push forward on the thinking some more - I was reminded of the video, the Powers of Ten, when thinking about the display of badge data and badge ecosystem information. Upon first glance, a user might want a 1000 ft view of their world, but perhaps they want the ability to easily navigate back and forth through the level of detail that their data could be providing. Maybe an issuer only wants to view their goals, or their assessments - but perhaps they want to see trends, data about individual badges, and individual users. Maybe an issuer wants to connect their data to algorithms... the possibilities are endless!   Will update as we start to think about this more.


Thursday, November 21, 2013

Rethinking the Annual Review Self Evaluation

Every year I have to do an annual review - where I meet with my manager and discuss my performance over the course of the past year. Usually these reviews require me to respond to some sort of questionnaire about my work - with questions kinda like these:

List the projects that you worked on?
Which project are you the most proud of?
How can you improve?
  
For my last review, I felt inspired to switch up my submission to my manager and handed her this instead of the traditional q and a response form:
jessklein-birthday
My manager, Erin Knight, responded to it well and was able to ask me relevant questions based on the things that I chose to highlight. This year I was going to take it up a notch and make this an interactive experience. As I started to think about how to go about this work.

The first thing that I did was create a list in Evernote of all of my work:


Then I started to think about if this was going to be interactive - where would I link out to my work. This helped me to realize that I have my work documented in several places online, including: this blog, flickr and github. This lead me to an a-ha moment. I had skills that I wanted to show off, evidence to back up that I did in fact earn or enhance those skills and... I had a peer reviewer to potentially endorse me. Are you following me here? BADGES!

What I imagining here is a re-envisioning of the self evaluation. Instead of thinking about this as an evaluation - you can imagine this being a tool to help to uncover what you have learned over the course of the year and how you could potentially further your learning moving forwards. I am proposing a tool where I can self issue badges, with evidence and have those badges endorsed by my peer. A more complex version of this would integrate career pathways and mentorship opportunities - as well as a recommendation system.

Here is my first sketch on this idea:


Thinking to be continued.....

Saturday, November 16, 2013

MentorN00b : matchmaker matchmaker make me a match!

I have been doing a lot of little projects for one off events lately.  Like this badge claim page I made for the recent Mozilla Summit:

summitsuite 

Or the one that I made for Mozilla Festival:
draft 
Usually we try to make one - offs more meaningful by actually doing some iteration on them or using them as a use case to inform the core product that we are actually working on.  So for example, I will probably work with our development and design team to figure out how to incorporate these kinds of claim pages into BadgeKit and will use the feedback that we got by standing and watching hundreds of people "test" out the sites as a usertesting and research exercise.

For these two events we also made something that I would put in the category of "schwag". Which, yeah - can totally be fun to make, but kind of usually feels a little meaningless. Here are the buttons that my teammates Chloe and Emily and I made for the events to help people to get interested in Open Badges:


This exercise, (I have to admit - quite surprisingly) turned out to be a meaningful design exploration that keeps on giving to us things to think about on the badges project. As Emily explains in her blogpost, the badges took on another life in practice. People hacked them and used them to give peers a glimpse of their identity - but not just identity with a capital I - really a deeper, more nuanced thing - how people self identify.

One day, I was in a coffee shop with Atul and Mike - thinking about the badges schwag and we were kind of doing our usual brainstorm of - wouldn't it be cool if ..... - and we came up with an idea for a prototype that could have pretty tight parameters. I would categorize this as a prototype that's not designed to scale. 

What we realized was - that at these events we would be seeing people with different kinds of expertise and desires and how in a perfect world we would match-make button wearer's so they could help each other out to learn skills. So for example, my button said that I was a javascript n00b and if Mike's button said that he was a javascript nin.ja we could be paired together.






What the three of us started to hack on was an app - where people could sign in, state their interests and then get paired with a like-minded friend to help mentorship. I could imagine this being something that could be taken further - so after a match is made, a mentor could help a n00b to develop a learning map/goal or trajectory and suggest or create badges for the n00b to work towards. Using the tools offered in BadgeKit, the mentors could then provide peer assessment for the n00bs. Additionally, the feedback loop could be closed by the n00b then giving the mentor through various kinds of mentor badges. This would in essence develop a mentor - n00b community and give participants the ability to always identify as somewhere on the spectrum for different skills or activities as mentors and/or n00bs. I particularly like this idea - that someone could be a mentor and a n00b at the exact same time. 

Here is a mockup that I worked on to start to express the idea:


We haven't gotten super far with the prototype, but I could see this as something that might be interesting to test out with the Hive or the mentor community activities at Mozilla.

Friday, November 15, 2013

On bathrooms, hurricanes and my new approach to design

On a recent flight I was reading some blogposts that were sitting in my Pocket for quite a while and I came across an article talking about the famed architect Michael Graves that originally appeared in Metropolis Mag in 2006. After a long career as an established, yet accepted quirky architect, Graves became paralyzed and wheel-chair bound due to a nerve condition. The way that he approached his work ever since that day has been altered. He did not stop dead in his tracks, but as a designer, he started to see the world around him with a new lens. Now he was seeing how inaccessible the world was how this was an opportunity for design thinking, problem solving and perhaps a  bit of innovation.

I finished reading the article, heard the pilot announce the infamous "10 minutes to landing" - bathroom call to action, and I got up to go to the restroom. Only this time, when using the restroom, I wasn't just using it - I was noticing it. I was thinking to myself "how on earth does anyone in a wheelchair use a toilet on a plane?" and wondering how they can even fit into this itsy bitsy space! Because Graves shared his personal struggle, he made me think about design solutions.

I guess I am writing about this because it helps me to understand why I feel compelled to share the story of how my life changed and how the way that I approach design has changed. One year ago, hurricane Sandy hit my hometown of Rockaway Beach, NY - and in many ways devastated the geography and the lives of the locals. At the time, I reacted by doing emergency webmaking - creating places for people to connect to volunteers, acting as a technology translator and inadvertently I became a resource for hyper local open news. Weeks went by and we found my displaced friends and family and started to repair their houses. Months went by and we dealt with long term repairs. A year went by and we moved from response to rebuilding.

During this time a tornado hit Oklahoma, and a flood hit Colorado - horrible natural disasters where people reached out to me for help - due to my so called expertise. I told them what I did and they iterated on it in their own communities. But like Graves, I had identified a problem - and an opportunity. The problem is the way that we are handling large scale emergency response and our opportunity is to use our webcraftsmenship and various kinds of innate skills to address the challenge.

If we are living in this blended environment of the web and the real world - how can these environments help eachother out when one of the environments is in trouble? My hope is that because I spoke out about things (even though I am no Michael Graves), you will see the world through this lens and approach your design problems by thinking about this story. This event changed my world and I can't help wonder if perhaps it could positively change many others as a result.

Right now I am sitting here feeling a bit pissed and angry - as I watch yet another natural disaster on the television - in the Philippines. Often people think that all they can do is give money for someone else to do something amazing and helpful, but really, we are a community of designers and developers and THINKERS. Lets use our anger and new lens to make something innovative so that when emergencies strike - people can feel empowered to help each other and help themselves.

I know I am feeling a bit cranky because I also know I have this prototype that I am itching to work on and just haven't had the time to work on it. I feel committed now more than ever and am going to push it forward. I don't just design for solutions or for work, I design to help people - and I feel that planet earth is giving us a kick in the ass and saying, come on - create, work together.


Tuesday, November 12, 2013

Badge Directory: A Yelp for Badges


Over the Summer, I started working (although I haven't gotten super far) on an idea for a Badge Directory - that was kind of like a Yelp for Badges. I have previously talked about this here . This is definitely in the realm of prototyping for a future addition to the Open Badges world, but the general idea is that it's a directory that leverages community input to categorize, group and rate the fidelity of the badges. This could be combined at some point with the idea of a Badge dashboard for users, but independently I see this as having some value as a service or a tool on to itself.

When I initially mocked up the concept for a badge directory, I was smack in the middle of thinking about how cities (like the City of Chicago) might benefit from a directory. At the time I made this sketch:

A mobile - first design made sense as the geographic location was deeply tied to badge or content discovery for participants in the Chicago Summer of Learning. So I could literally imagine a game - like alert notification if a user had geolocation services on their mobile devices. 

 

At some point, I sat down and tried to make this a real thing - which forced me to think about it in terms of a tool or a service that might be more broadly used. When I considered all of the things that I was imagining the tool doing (recommendations based on interest, location, skill, peer group etc) I realized that I needed some sort of way to collect the data. This began my investigation into creating a community crafted directory - aka a "Yelp for Badges." 
  Initially I started by thinking about the structure of the service as a searchable - interactive filter layer for public badges. 



 

Here is what a badge detail might look like (below):






Some features that I added here that don't currently exist are:
  Goal Group - this allows a potential badge earner to build a collection of badges that they intend to pursue and to declare a goal for that collection. This could take the form of badge pathways where someone says - my goal is to become an expert at woodworking and then all of the badges that they add to that group represent the learning map for how they are going to achieve that goal. These groups could be made public and could potentially be forkable.

 Badge Rank - the idea is that an algorithm will be generated that helps to contextualize badges in relationship to one another. The algorithm( in theory) will take into account crowdsourced feedback and evaluate the metadata contained in each badge as well as other factors that I am sure I have not thought about at this point.

  License - think of this as a creative commons license for badges. I am actually really excited about this - but the general idea is that is that like a work of art or a concept, people have different ways that they intend the badge to be used or reused - and this will give the author control over their intent.

  Reviews - users of the directory will have the ability to read and write reviews for individual or groups of badges. This helps us with the possible problem of the badge ecosystem being flooded with meaningless badges - the reviews (hopefully) will force content providers to put out high quality work (and if anything could just keep badgemakers on their toes). As I worked a little more on the UX wireframes, and got some initial feedback. I realized that I needed to  raise the hierarchy for search and make it easy to access, consistently placed and focused on specific forms of output: goals, reviews, badges. Here, I also explored visualizing badges as pure text.
 




Finally, I started to incorporate the idea of a user dashboard and backpack into the directory. If you are making goal groups, and badges and are able to get recommendations - then really, what if the interactions were combined to give a user control over their learning data - before, during and after the act of doing whatever it is that they are doing to learn a skill or concept. 




So, let me take a second to talk about the Backpack sync that I incorporated into the mockup above. Imagine you are logged into the directory - as a user - via twitter (for this example) . As a user, you want to get recommendations on your interactions on the site as well as the knowledge of badges that you have already earned. Here, you sync to your backpack (s) - have your services talk to eachother and eventually earn recommendations for goal groups, learning maps, badges and peers based on this newly expanded perspective of what is in essence, your profile.
 

I still have a lot more to think about, and am frankly writing this post so that I can keep track of my thinking and get some feedback. Some things that need to be thought about here are : how are badges added to the directory? Is there something in the badge specification that would need to be altered to accommodate this? Is there a different view for badgemakers? Can I make a badge directly from the directory? How does this work relate to BadgeKit? How is this moderated? …. and I'm sure much much more.  I look forward to hearing feedback and talking more about this.