EYE Witness News: Promotional Content on Webmaker

On January 28th Mozilla will be celebrating Data Privacy Day. This is an international effort centered on "Respecting Privacy, Safeguarding Data and Enabling Trust." There will be content on Mozilla, Webmaker and Mozilla Advocacy. The Webmaker team had previously developed privacy content with the Private Eye activity (featuring the Lightbeam add-on), so the primary challenge here was how to promote that content via the Webmaker splash page. This is actually a two - fold design opportunity:

1. micro: how might we promote the unique Privacy Day content on the splash page for the 28th?

2. macro: how might we incorporate promotional interest-based content into the real estate on the Webmaker splash page on an ongoing basis?

Constraints: needs to be conceived, designed and implemented within 2 weeks.

Start from the beginning 

I took a look at the current splash page. The content that we are promoting is directly connected to the Mozilla mission, so I identified a sliver of space directly above the section where we state the project's values. My thinking here is that we are creating a three tier hierarchy of values on the page: 1) we are webmaker - we are all about making - and this is what you can do right this second to get started, 2) we are deeply concerned about [privacy] - and this what you can do right now to dive into that topic and 3)we are more than just making + [privacy] - here are all the things that we value.

I SEE what you did there

That sliver was great, but it was below the non-existent but deeply considered fold of the page. If this was a painting I would create a repoussoir element to bring the users attention to the core content  by framing the edge. In the painting below you can see that tree branch that directs your attention directly into the heart of the composition.

Jacob Isaaksz. van Ruisdael, The Jewish Cemetery (1655-60)

Building off of my thinking from designing the Mozilla snippet and the onboarding ux,  I wanted to make this repoussoir element something that a user might find quirky, whimsical or relateable. All of the other elements on the page were expected and kind of standard elements for a webpage. I needed to create something that would be subtle yet attention grabbing.  Looking at subject of privacy, I immediately had associations with corporations and individuals big- brothering me as I visited web pages. I realized that the activity we were directing users to was called private eye - and this led me to create a small asset that features an eyeball that follows your cursor around as you explore the splash page. On hover it will flip and direct you to the activity.This worked for desktop, but for mobile we would have to simulate the action by having a simple CSS eyeball animation center aligned on the sliver. Major props here go out to Aki who had to invoke the pythagorean theorem to get the eye to follow the cursor without leaving the sclera.

  I did a study of eyeballs on redpen and immediately got a ton of community and staff feedback - which told me two things: 1. it was a conversation topic and 2. people liked the very first eyeball that I drew. 

My javascript now has a variable called ‘pythagoras’. HAHAHA TAKE THAT, MATH.
— Social Justice Mage (@gesa) January 14, 2015

Let me give you a walk through

From Mozilla's perspective, we are testing:

• whimsy vs. traditional promotional placement 

• mission driven content 

• how many people are we getting to engage with Webmaker and sign up for new accounts

What's Next Up:

• This will be deployed on staging on Monday and then our goal is to go live on January 28th, which is Privacy Day!

• Now that we have a promotional framework, figuring out how to incorporate a richer learning experience around mission - based content.

• Users can opt into enrolling in a sustained challenge - based Webmaker activity. Almost as if it's a virtual Webmaker club.
  
  
  Shout outs to the team that made this possible: Aki, Andrew, Erika, Paul, Dave

Shall we dance? On-boarding Webmakers

The first time that someone comes to your website is like a high school dance at the gym. You want that hottie who you have been thinking about all year to be attracted to you and join you on the dance floor . You want to show them what you are all about: how you aren't just about the MC Hammer pants and bikini top you are wearing (dating myself much?) - and you have the moves to prove it. This dance is just the beginning - you really want to go steady, but you have to start somewhere, right?

About 40-60% of users who sign up for a free trial of your software will use it once and then never come back.

When designing the on-boarding experience, we have a few goals: 

• We should make a positive user experience where the visitor learns something within minutes of interacting
• We should have the user take some action which results in signing up for a Webmaker account
• We should give the user a clear and compelling reason to return.

Deeply inspired by the theory of Hanging Out, Messing Around and Geeking Out: Kids Living and Learning with New Media, I started to think about what a low bar way might be to get people to dance with me.  The idea is that there is a progression and/or just different ways that a site visitor might interact with the site. I wanted to create an experience for the user, that will allow them to walk away having seen a little bit of code, had the a ha! moment, the realization that there is so much to learn about the way that the web is crafted - and most importantly: that remixing the web is an approachable challenge.  According to this chart below, we could argue that most of our site visitors are at the beginning of the customer awareness journey.

Start from the beginning --- err where is that exactly?

I started by doing an exploratory sketch - asking where might users first see/ interact with the Goggles on Webmaker? I see 5 main areas of contact:

1. Webmaker Landing Page with a very specific call to action
2. Via the not-yet-existing "Join Webmaker" button user flow
3. On the Tools page within Webmaker
4. On the Goggles page within Webmaker
5. Within the Goggles interface upon activating the bookmarklet

For this heartbeat (and the build sprint after) we decided to focus on number 1 via 2 (Join Webmaker user flow via the landing page) as the goal for the first quarter is to improve our conversion of visitors to Webmaker.org into makers.

Think through the user flow

With a clear scope, I took a stab at thinking through potential user flows (ahem,dance moves). What interactions might I be able to design that could help the user gain an understanding of the awesome potential of Webmaker and come away with learning a little bit about making things on the web within the first few minutes of their site visit? On a traditional site, this is where I would do a product tour - to tell the visitor about all the bells and whistles. But, let's remember, we are at a high school dance. We don't want to just tell that hottie about how great we are, we want them to hold our hand and dance with us. So what exactly is our dance? It's an introduction to the site through an interactive tinkering activity.

I had some experience tackling this user experience challenge a few months back when I designed the Maker Party snippet for the Firefox about page. Here, we were trying to coax visitors to the About Page to sign up for Webmaker AND ... (the cooler part) expose them to a little bit of code through modeling a playful interaction that they in turn would emulate. We found this approach to be successful. I personally user tested the page with a variety of site visitors in the Hive Learning Network and found that the animated modeling of the CSS value being typed acted as I would as a teacher in a classroom, or a friend showing someone how to approach the problem, asking the friend to try it out themselves. This approach could easily translate to an activity on the landing page where we show a visitor how to edit some playfully placed text using the X-Ray Goggles.

Approach 1: Modeling

Modeling tries to emulate the way you might teach this in a classroom environment - you show the actions that you want the learner to emulate.  See complete mockup here.

I also tackled this challenge of getting a user to dabble with new information and content in the weather activity experiment for the Hour of Code. Here, I thought about how I like to follow recipes and get feedback as I do each each step in a staged progression. (This would be like... someone teaching you how to do the macarena step by step at the dance)

Approach 2: Stage Progression

The staged progression allows the user to read, and then asks them to try it out, providing little tips along the way. See complete mockup here.

After getting some feedback from my colleagues and a few user testers I am leaning towards a hybrid approach - where you might model for them at each "step."

Next up: enticing your friend to get on the dance floor

All of the user flows and interaction designs are a good exercise, but if the icebreaker prompt isn't enticing, then it's no good.  So - I did a few iterations:

Name tag fill in the blank --- this could somehow tie in to the sign up flow.

Venn Diagrams - probably too designerdy but I couldn't help myself.

Fill in the blank - I <3 webmaking.="">

Fill in the blank - attempt 2. I like this one the most at the moment because it has a focal point, and it feels a bit disruptive, like Webmaker itself.

Next up: Finding those dancing shoes.

To get to an interactive prototype, we need to:

• Design the hybrid interaction design (modeling + staged progression)
• Choose a direction and then work on the UI elements
• Wordsmith the copy.
• User test with real humans!

Designing an on-boarding is like asking someone to the dance floor ----testing if your pits stink and all, so I would love to hear any thoughts if I've got any moves. 

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. 

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.

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.