What's in my toolshed: the prototyping edition

Lately I have been thinking a lot about how I go about prototyping. That's a huge topic, because really prototyping is a step along a long, loooong and windy path that begins with an idea. I often analyze in painful detail how I get the idea or what I do with that idea once I have it, but today I want to think through my process in terms of what's in my bag, or what's my setup. 

I think it goes something like this:

I have an idea.
Tools: shower, running shoes, a friend and/or hot chocolate

I sketch out the idea.
Tools: pencil, notebook, ipad, paper53, cosmonaut

I share that idea with a small group of people
Tools: more hot chocolate

This cup is from the  folks at One Girl Cookies in Dumbo

I share that idea with a larger group of people
Tools:  a blog, camera (usually just use my phone)

    

Then, I share the idea with people in my making environments
Tools: github, flickr

I read and write - A lot. I tend to research everywhere from blogs to books, to print articles. I ask experts and novices a like to talk to me.
Tools: New York Public Library, DML, goodreads, the interwebs

What I am reading now: Creative Confidence by the Kelley Brothers. Check it out!

Then I am like omgossssh  I have so many things I need to get organized, so I put all of my tools into some sort of list, or spark file.
Tools: Evernote, etherpad , Google Docs

By this time I realize that I want to make something so that people can have a proof of concept to play around with, so I start to make something interactive.
Tools: POP, Coda2, Cyberduck, Webmaker, Appmaker, Adobe Illustrator, etc.

Then I go into a rapid cycle of user testing -> iterating -> usertesting
Tools: redpen for mockups, user testing websites, Hive meetups, minigroups, groupme, Webmaker demos,  more hot chocolate and chocolate chip cookies.

At this point I kind of move into a decision making phase. This is a whole other set of operations, however I now have a lot of tools at my disposal to make that decision. By now, I have now developed a cohort of people who I am working with to develop the prototype - whether that be user testers, feedbackers or active co-developers.

I should note here that a) this whole process relies heavily on hot chocolate - my current favorite can be found by visiting the Little Sweet Cafe just off of Atlantic Avenue in Brooklyn and b) my process is all about prototyping in the open. I find that prototyping by, for and with people makes my ideas stronger and helps me to fail faster so that I can pick myself up and iterate with more knowledge, more often. I'd love to hear what ways YOU prototype.

Portfolio Design Workshop

Yesterday I went to a portfolio workshop for Hive NYC members at the Brooklyn Public Library. The workshop was run by Julia Vallera and the goal was to help people think through the process of developing content to showcase projects created within the Hive, however, the it ended up being so much more. By the end of the day, participants were helping members of the Hive HQ iterate on their portfolio application form, and started to articulate the need for tools that support an innovation framework.

Lifecycle of a Project 
Workshop participants reviewed the timeline of a project from exploration to the phase where you might be sharing out learnings (the portfolio touchpoint). Julia used this chart which compares the creation cycle to the lifecycle of water (how amazing is that?!). Particpants articulated that while there are lots of touchpoints and feeback loops after something has been created, there is a real desire for in-progress community support and reflection.

Portfolio template:
Participants used this template to start developing out their project portfolio piece.  Some feedback that Hive members gave is that it would be awesome if they could be developing the content throughout their making process. Additionally, they explained that it was really important to be able to identify who the author of the content was and in turn, who that author was "speaking to" via the medium of the portfolio.

Opportunity!
After listening to Hive members talk for a few hours and taking notes (below), I realized that there's a real opportunity to support what Brian from Beam Center referred to as a "framework for innovation" and what Leah from the Hive called a "living archive of process." 

I am going to tinker with Atul, Kat, Chris and the rest of the Hive community to think through what this could be, but overall I found this workshop inspiring and am eager to start noodling in this opportunity space. Some initial thoughts is that we should think through what a process dashboard and process project profile could look like. Here's what I sketched while at the workshop, but am going to dive deeper this week. 

Dear Massimo

Dear Massimo,

I met you when I was 23 and working as a Curatorial Assistant at the Museum of Arts & Design. You and Lella came to work on the exhibition design for a show on the jewelry of Seaman Schepps. At the time, I had never worked with a real designer and I was in complete awe of your process. You were a great listener, and methodically took notes and drew sketches while we described to you our dreams for the exhibition. You had a mechanical pencil. You drew thick and distinctive lines, unquestionably bold.

Your notes were written in capitals, like an architect. You were stubborn and your stubbornness pushed all of us around you out of our comfort zones. I remember sitting with you and Lella, in the back of a yellow cab when we discussed the materials that we would be using to create the pedestals to display jewelry. You said "lead".  Lella said "MAAAAASSSSIMO, don't be ridiculous." You then described to us your vision of having the intricate jewelry stand out against the simplicity of the raw material. Your vision, was measured, austere and had perfect symmetry. As someone who had to work with the contractors to acquire the lead and to actually handle the lead to build the cases, I was of course completely terrified. Isn't lead toxic? Like, could this perfect design decision of Massimo's actually kill me in the long run?  We worked together and learned that wax detoxifies lead. We went to your studio (the first real designer's studio I had ever seen) and tested it out.  You had an I told you so look on your face like a devilish child. And so, we made the cases:

You loved a good fight. One of my favorite things was listening to you, Lella, Yoshi Waterhouse and Beatriz Cifuentes completely disagree about design direction. Lella was your partner and you had a beautiful banter that inspired me to be adventurous, and own my questioning nature. 

At the time I wasn't sure what I wanted to do with my life. I was working in museums but found myself sketching in the galleries and taking side jobs just to draw. You saw me at lunch one day and asked me why I was wasting my talent and then you didn't stay around to hear an answer. Lella, of course, followed up with me and told me to try things out, to take in as much art and design as I could and that things will figure themselves out. You very much had the ask for forgiveness, not permission attitude, which I still to this day, admire.

I ended up working at the Rubin Museum of Art after that museum, and found myself constantly questioning and designing and thinking about my conversations with you. Eventually I built up enough courage to quit and went to design school. I learned about why I should admire you even more and read your writing on design, watched you speak in Helvetica and looked at your wealth of work over time. But really, that's just the evidence. You showed me how to be a designer because you embodied it. You had a viewpoint, and a goal of helping people to better understand the world they inhabit, through design. I am a stylistically a different kind of designer, but you taught me to own my stubbornness and to have an opinion. 

I will always admire you. We are lucky enough to see all the design interventions that you have left the world on a daily basis.  Thank you for being bold and stubborn. 

I already miss you.

Jess

Note: I learned that Massimo Vignelli passed away today. His son, Luca asked for all those for whom Vignelli was either an influence or an inspiration to write him a letter. This is mine.

Making History in Appmaker

In my previous post, I wrote about my user interface explorations in Appmaker. As I mentioned, those explorations lead me to start thinking a bit about potential features for the tool. One feature that I took a bit of a deep dive on is the concept of a recording your history while you are in the process of designing the app. The big problem/opportunity here is that a lot of time when you have tools like the goggles, thimble, appmaker or popcorn that are designed to encourage learning engagement, you have people create these one off pages, videos or apps in such a way that they have a kind of rough product, and little - to - nothing to help showcase the process. That's what I am noodling on. 

My thesis: 

Appmaker history will enable users to raise the value of their (collaborative) making process and learn from their design choices by integrating annotation into a users “save” workflow.

Here's the userflow:

1. A maker does something in appmaker, like add a button.

2. The maker saves their work

 3. A timestamped modal appears, and that allows the user to Name the milestone moment and annotate it with comments.

 4. The maker is then given the option to watch a screencast of the moment, share it or take a look at their history tab.

5. If they choose screencast, they can watch a video replay of all of their actions contained in their history.

6. At any time in the maker's design process, they can now go to their history tab and see all of their saved version with annotations. They can also revert to this period in their making.

This is exciting to me because it rethinks the hierarchy of the end product. After designing, a user now has two bi-products: the app and the process by which the app was made. This is particularly useful for collaborative making and if you wanted to share or learn from others who shared.

Appmaker User Interface - Mockups

This week I've been spending a bunch of time with the Appmaker team at the Mozilla all hands work week.  One thing, that 's really hard for me to do - is to work on products that don't seem to make visual sense to me - and that's kind of what was happening when I looked at the design canvas of Appmaker. Here is what the user interface currently looks like: 

 

What's working?

- The building components are super easy to identify and manipulate. 

- The searchability of components

- The ease with which you can sign in or add a new app

What could use some work? 

- The design canvas itself was bit confining. I felt like I was in a claustrophobic room when I designed

- It feels like theres a lot that I have to pay attention to in one glance and I can't figure out where I am supposed to be looking, clicking, thinking at any given moment. 

- It still feels like a lo-fi prototype - so users can't really see the friggin' awesome potential for this tool.

Mockup Attempt One: The Webmaker Appmaker

For the first iteration of mocking up the UI, I took cues from Webmaker. My thinking here is that we could be delivering a consistent, cohesive product family offering. 

Since designing the UI mockup sometimes inspires me to rethink the tool, I added a few notable features here: 

1. Media Library - the ability to use the mobile devices affordances to pull in assets to integrate into the app design 

2. History - the ability to save your process, and revert to any moment in your designing 

Mockup Attempt Two:

I took a bit of a different approach here. I thought through how I actually organize my space as a designer, and how that approach could be reflected in the design. When I design, I like to organize my space and shift things around the canvas as I am working on different components. Some fun things to note here: 

- the phone itself is clickable so that you can change the model (the firefox phone is seen here).

- the toggle on the top of the canvas allows you to switch back and forth from different design modes: editor or preview

- the floating editor changes depending on what component you are working on. 

- undo, redo.

That's all for now. Just taking the time to think through the designs and will probably user test with the Appmaker team to really figure out what's a good direction. 

Prototype: Evaluating Prototypes that we make at Mozilla

I am at the Mozilla annual All-Hands meetup in San Francisco this week. I made this quick animated gif to explain this idea that I have had in my head for a while. One problem I have for evaluating the prototypes that I make at Mozilla is really figuring out if the prototype matches the design values of Mozilla. I quickly drafted this idea for a widget that can be dropped on to any web-based prototype for contributors to help me to see how aligned with the values the concept is (or isn't).

Just in case the gif was a bit too fast for you to see the interaction, here are some stills of the process:

Step one: a prototype - maker (whether that's a Mozilla employee or a Mozillian) puts the e-VALUE-ator * widget on to their prototoype.  * = working title, probably won't stick :)

Step 2: a prototype user will hover over the widget, it spins to get their attention and then turns into a clickable button:

Step 3: after click the button, this screen will appear - asking the user to choose which Mozilla design values this prototype embodies.

Step 4: After a user submits the values, a confirmation screen will appear, showing the user a graph-i-fied version of the widget, reflected their feedback. Additionally a user can then look at the birds eye view feedback on the prototype from many contributors etc. or, if they are motivated, give long form feedback in a comment field.

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.

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.

1. ALL RIGHTS RESERVED COPYRIGHT 

• 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:

• Adrienne K. , Goss. "Student Note: Codifying a Commons: Copyright, Copyleft, and the Creative Commons Project." Chicago-Kent Law Review. (2007): 963. http://scholarship.kentlaw.iit.edu/cgi/viewcontent.cgi?article=3609&context=cklawreview.

• Montagnani,  Maria Lilla. "A New Interface Between Copyright Law and Technology: How  User-Generated Content Will Shape the Future of Online Distribution." Cardozo Arts & Entertainment Law Journal. (2009): 719. http://www.cardozoaelj.com/wp-content/uploads/2013/04/Montagnani.pdf.

• 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.

• Loren,  Lydia Pallas. "Building a Reliable Semicommons of Creative Works:  Enforcement of Creative Commons Licenses and Limited Abandonment of  Copyright." George Mason Law Review. (2007): 271. http://www.georgemasonlawreview.org/doc/14-2_Loren.pdf.

• West,  Ashley. "Little Victories: Promoting Artistic Progress through the  Enforcement of Creative Commons Attribution and Share-Alike Licenses."Florida State University Law Review. (2009): 903. http://www.law.fsu.edu/journals/lawreview/downloads/364/west.pdf.

• Participate: Designing with User Generated Content : http://nypl.bibliocommons.com/item/show/19472503052907_participate

---------------
Please note: I am not a lawyer, nor do I pretend to be. I am merely researching the subject.

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

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. 

 

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.

 

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.

 

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. 

 

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.

 

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.

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:

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.....

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:

 

Or the one that I made for Mozilla Festival:
 
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.