Protyping Peer Assessment for Webmaker

For quite some time now we have been talking about the idea of integrating some form of peer assessment and feedback into Webmaker, as a way to level up an individual user's craft and community.  Today I want to share some ideas that Chloe Varelidi and I have been tinkering with and starting to actually prototype with Atul Varma.  I am going to do a little walkthrough of a potential user experience. Keep in mind that some of this is probably wrong, but I want to put it out there so that we can work on polishing those bits.

Imagine that you came to Webmaker and you were looking for a way to learn or gain specific skills. You click on the "Skills" tab (I'm sure there are tons of other names that could be more appropriate for this navigation item). On the skills page you see all of the possible badges that you can apply for - and these badges in the future will not just be individual small badges, but represent larger learning pathways. 

If a user clicks on a badge - they will learn about the badge through a playful interactive displayer and have the ability to immediately apply to earn that badge. 

When the user clicks "Apply" they are given the apply interface. This reminds the user what the criteria is for the badge, gives them the ability to upload evidence and write reflective thoughts on their process.  There are several things that we could do here, one idea was to have the user create a "how to" showing how they made their project, which eventually could be integrated into some kind of maker gallery.  What's great about this approach to "badge pledge" is that it is a useful  interaction in its own regard, and not existing solely for assessment/recognition purposes - that way there's both extrinsic and intrinsic incentives involved.

The user then submits their badge application. There are several directions that we could go from here. One option is to have all of the entries go into a queue that is accessible for mentor reviews from a secure interface that they will be able to access by logging into the queue through a mentor username and password to the site.

Another option might be to completely make this public and leverage a service like twitter. I imagine that the interaction here (after a user signs in and then clicks submit) could be similar the Army of Awesome (see below) where a the applications compile in a tweet queue and then peers pick up the individual applications to review. If we went in this direction, some more sophisticated flow will need to be developed so that there is a way to in essence vet the quality of peer review.

 

The actual application review for a mentor might be something like this:

Here, the reviewer can see the badge applicant's evidence and reflection and then provide feedback as well as recommend the user for a badge. One of the ideas that we had for this particular touchpoint is to create a feedback widget that encouraged constructive feedback. Taking a cue from the Lifelong Kindergarten Lab Chloe actually helped us to work on our internal tools for feedback at Mozilla meetings. Since we are often typing on etherpads during calls, we organize our feedback into categories. We added the blue one to the model to encourage collaborative making.

• Green (what's awesome)

• Yellow (what I am unsure about)

• Red (what's not working)

• Blue (an idea that I have)

Here is a screenshot of one that we recently did:

Since this has been a successful prototype for us internally, we thought that we could take this concept to a feedback widget. We were thinking of something like disqus that could be modified by different users to suit their own needs and own kinds of evaluations (imagine evaluating using just emoji's ?!!!)  The idea is that a mentor is able to click on the different colors and then is given prompts to help them to construct their feedback. In this moment they are able to recommend the badge as well. There are individual rubrics that we could create for the individual assessments as well, which is not shown.  Here is the sketch for this general idea: 

 

After this, let's imagine that the user was recommended for a badge. They are then sent a link (via twitter, via their Webmaker account -- depending on what direction we take above) that would look something like this:

What is worth noting here is that we include options for the user to send thanks or to rebound the feedback. This sets us up for beginning a dialog as well as using this touchpoint to evaluate the evaluator. This is a crucial step to the user flow, since it helps mentors improve their feedback, which is a skill in and of itself. There is some work that still needs to be figured out here in terms of what the interaction is if a user is not given the badge. We want that to be a positive experience. 

Chloe made this great stop motion video to quickly go over the overall interaction that I described:

Wondering what the next steps are here? Well, I am happy to tell you:

1. Prototype: We are going to use the Chicago Summer of Learning work to prototype a version of some of this interaction and then iterate on that to develop some of this flow out for Webmaker.

2. Identify mentors: we need to identify how mentors are going to play into this work flow for the Summer campaign. I know that we are going to have an active, dedicated community, however the decisions that we make around their involvement will impact some of the choices that we make moving forward with the assessment interaction design.

3. Work with the Webmaker, Mentor and Badges teams to make sure that we are all collaborating on this work.

Design Feedback for Badge Systems

Last week I participated in a workshop for Digital Media and Learning grantees. Everyone at the workshop presented their progress on creating open badge systems for their organization. It was my role during the workshop to act as a design expert, to give feedback on the projects and help facilitate a conversation about the design elements of their work.  Over the course of 2 days, I listened to detailed presentations about badge system design, learning theory and communication plans and realized that some themes were emerging. For today's post, I thought that I would share my 5 most common bits of feedback that I gave out to the grantees.

 

1.    Get to know your end-user

Take the time to think through your user persona and user flows. Remember that you have a specific human using your product and they are receiving the badges that you create. Get really specific here and come up with a user story and test that against your designs. 

For example: My user's name is Adrian, he is 18 years old and enjoys reading Science Fiction books, riding his bike and exploring New York City. He is participating in this after school program because he has a passion for math and has felt relatively uninspired by his in-school options. He does this program on Wednesdays after school and has already earned badges for peer mentoring, leadership and problem solving. These are particularly meaningful for him because he wants his peers to know that he is not only a smart guy, but really has street cred in the math community. He posts his badges both in his school LMS and on his personal Facebook page.

From my example, we can already learn a few things that will help inform some design decisions. We know he is doing this work as an extracurricular activity, so we want to frame the work as informal and we know that he is more interested in the social capital that he gains from this experience outside of the classroom and school community, so he is invested in the badges being flexible and shareable. 

You probably will have 3 or 4 types of users for any given product. Embrace that and come up with unique user stories that are based on real life use cases.

2.    Badges and identity

Think about how your badges communicate or enhance an end-users identity. This might seem like an obvious one, but it's crucial to think about how the end-user relates to the badge on a personal level and how that might inform their identity, both within the context of your tool or badge system design and outside of that framework in the real world. On a simple level, think about how might be naming the badges and ask yourself - does this have resonance with the badge recipient? What is more appealing "CSS 101 badge" or "CSS Super Styler"? Think about how this relates to the visual design as well, are you offering something that would have more significance to your organizational brand than to your users brand or identity? If so, then I would recommend reviewing the design and iterating.

3.    Badge design 

It's important to remember that 90% of the badge system design is not visual. Take the time to go and think through all of the touchpoints for badges and ask yourself "are they meaningful experiences?" and if they are meaningful - who are they meaningful for? Once you past that test, then you can move on to visual design. I gave a webinar on this about a month ago and put the slides up on a Google Doc here. 

The top level things to consider are legibility, scale and typography. Open badges are relatively small graphics, so think about that when you are designing them. Reduce the amount of graphic complexity as much as humanly possible. Ask yourself if you even need to incorporate text into the badge - because this adds an additional layer of content that a user needs to digest. I pull this point out separately because I don't think that text is needed because the backpack and/or system distribution could include that information alongside the badge, giving you the opportunity to free up your design. Badges are like icons, you need to attempt to communicate as much as possible with the fewest elements as possible.

4.    User Testing 

How can you engage your community in user testing and analysis? Can you think of ways to work in a more agile way- incorporating feedback and testing so that you are putting out releases that build on your learning and findings from fieldwork and testing?  All of the questions that you have about your design will be acknowledged the second that you have someone who is unfamiliar with your project review your work.

And, as part of the DML/ MacArthur/ HASTAC / Mozilla community- you can ask us for help. Yeah you have a grant deliverable, but you have a community right here who are asking themselves the same design questions and are a perfect user tester. That said, I would take the time to mix up your user tests - have friends and family, but also include complete strangers. 

Remember, user testing can be as informal as throwing two badge designs in front of a user and asking them which one they prefer and why. Don't be intimidated by the term user testing - in reality, what is more intimidating is putting out a product that will be used by hundreds of people that has not been tested.

5.    Metrics and dashboard Data

My final bit of feedback has to do with how you are valuing success but more importantly about how your end user values success, learning and skill acquisition. Many of the dashboard type tools that I saw were actually speaking to how an institution or organization values success within a Learning Management System (or badge system, or tool etc.) but not how the end - user values success. So for example, the tool was designed for the high school teacher instead of the high school student. Remember that success and metrics is something that can be shared and communicated to users as part of their experience within the product offering and it is an opportunity to help a user challenge themselves to level up or exceed both your and their expectations. In terms of design, this might mean that you should consider surfacing some of this data. 

Design needs to constantly be iterated upon, however, if done correctly it will be a huge contributor to the success of your badge system design. So go forth, and design with courage. Use this top 5 list as tools in your arsenal to help you craft a meaningful user experience.

Make - First Interaction Design

 On the Webmaker community call and on his blog this week, Brett Gaylor presented that we are currently aiming to solve several key design questions for Webmaker. You can read about the challenges and solutions here.

In an effort to move Webmaker into a space where from the moment you come to the site - you are encouraged to make something (what Brett is calling "make - first" interaction design) , I am going to show some prototypes that I have been working on. 

You can see all of them here in larger, more legible form.

Even though the fidelity of my prototypes might seem more polished then usual, as always please note that these are mockups and prototypes designed for the purpose of iteration, so please give me feedback and ideas for things that I should consider when moving forward with the design. 

First, lets take a look at the Landing page. The idea here is that from the moment that you land on Webmaker.org you are given the call to action to tinker and interact with content in a very real way. What you are looking at is actually a meta "Animated webpage" project that is comprised of several types of projects - so in essence the content type becomes a gallery. The page is instantly hackable and as the user, starts tinkering with an x-ray goggle like interaction- they can choose to deep dive and reveal the more advanced editing tools. While this is a mockup for the landing page - you could imagine that it is also a prototype for how a user might be able to pull and view content from the gallery - so the user gets the opportunity to digest a project first as consumable content and then engage with it as a hackable medium. This kind of interaction was deeply inspired by my reading of the work of Mimi Ito - particularly in her book Hanging Out, Messing Around and Geeking Out. Here is what it might look like with some timely content.

The next mockup is a first iteration of what a gallery could look like for us. A user does not have to be logged in to view the gallery, but if they are they will have a more personalized lens as well as the chance to engage with the content creators. 

In this mockup (which admittedly is the most nascent) you see a view of what a user might see if they are clicking on a particular users name - it's a filter of the content that the user made public. This could include their projects, badges or assets. Ideally this page will have some level of hackability - a la MySpace - so maybe the CSS of the page could eventually be modified by the individual users - since in essence this becomes a bit of a portfolio page. To be clear, I'm not saying it should look or feel like MySpace - but there was a certain level or ownership and creativity around that kind of personalization.

Finally, I'd like to share with you the prototype that I hacked up with Atul yesterday. It's a prototype, so you know don't tweet far and wide - but you can check it out to start to see what it would be like to have hackable content on a landing page and remember to click "D" for deep dive to bring that content directly into Thimble. 

Evolving Webmaker in 2013

"Allow events to change you. You have to be willing to grow. Growth is different from something that happens to you. You produce it. You live it. The prerequisites for growth: the openness to experience events and the willingness to be changed by them." - Bruce Mau from Incomplete Manifesto for Growth

2012 was a full year for us at the Mozilla Foundation - we released Thimble, a universal navigation MVP, soft launched badges, refined and launched Popcorn 1.0 and became an active voice for Web Literacy values in the community. So where does that leave us for 2013? As Bruce Mau's beautiful sentiment here reflects, now is the time for us to live in the moment and to be strong enough to allow ourselves to be changed or affected - by users, by people who do unexpectedly amazing things with our tools, and by people who are standing next to us in the crowd and trying to get their own voice heard.

2013 is full of a lot of opportunity.  For Webmaker that means evolving our design to be a real - world learning experience. By that, I mean that we need to focus on collaborative webmaking.  At our hack jams, community calls and festivals we have seen the value and success of peer to peer learning and we need to leverage the experiences of those events and have them inform our design.

We have laid the ground work for this in 2012 by introducing badges into our ecosystem. Badges are naturally equated with skills, however they need to have a level of social value in an ecosystem to have any meaning.  That's the problem- badges for the sake of badges leave you feeling pretty flat, so you need the entire ecosystem to live and breathe as a social, collaborative environment where you have supportive peers who are invested in the skills, but also - importantly - what it takes to earn those skills. That's our mission: create an environment where making = learning. Concretely that means that our website is going to shift from a site to a platform and our suite of tools are going to evolve into a more unified experience.

Over the past few weeks, a bunch of us on the Webmaker team took some time to do the blue sky thinking that needs to happen to take a design concept to the next level. We came up with some ideas and prototypes and I am going to share a few here.  Each prototype represents a concept that we want to explore in the New Year.

1. Your Creative Cloud - We want to make it easy to collect, share and remix content from your world - and this means everywhere that you are going- whether that be collecting content from your mobile device or browser and adding that directly to a project to remix on Webmaker . Maybe in the future that means remixing Webmaker content that you have clipped or saved from your cloud on to some sort of media clipping gallery -- remixing that on the web in a more distributed manner.  Click here to see the enlarged mockup. 
 

We feel that this is one area that Mozilla can lead as we are uniquely suited to be effective here because of the precedent of bookmarking in browser in Firefox as well as with our work directly around identity in conjunction with Persona. To be clear, we don't need or want to lock you in to a uniquely browser based experience - but the opportunities for this association and leveraging of the Mozilla brand and design values are quite large. We know this is a win for us, because our colleagues over at Firefox are in- line with our thinking and we are starting discuss opportunities for us to collaborate on this piece of the puzzle.

2. Collaboration as learning is a big theme for us, not just in the mockup I am showing but it is going to be a consistent and fluid theme within our tools and platform.  In the mockup above you are looking at system for using to revision history as a way to document process. Here, just like in etherpad, you are able to record your Webmaking sessions and replay them at different points in your timeline. You can see the work that you have done and how you constructed a project,  as well as how a peer who is helping to hack your project made the changes that she did. This allows for asymmetrical as well as symetrical collaboration experiences.

3. Making our tools speak the same language. We are trying to make the experience for an average user easier- this means putting some controls in place so that the user starts to recognize conventions and see how the Webmaker properties relate to eachother.  As you can see in this mockup, I am starting to experiment with building a more unified experience- which includes: having a unified (and single) login for Webmaker, building out common terminology, controls and User Interface - and incorporating the tools into the same experience. To be clear- this does not mean that Thimble goes away, it just means that we figure out a way for our tools to speak more clearly to the end user.

 

4.  Creating opportunitites for Community of Craft - working with peers and mentors to build the web in a social, real way. I demo-ed this prototype at the Webmaker community call and Bobby Richter helped me present it:

Imagine that you logged into webmaker.org and landed on the above gallery page.The view that you are looking at- is as if you have followed several other Webmaker users who have posted projects that they made as well as "themes" that you might have followed- for example- video projects or projects about activism. Any of these projects are remixable. You also are seeing badge graphics which, when you click on them, open up to a sub-gallery of sets of projects connected to various skills. For the moment, imagine that you are Secretrobotron going on to this page, you see a cool project by your friend and you click the green remix button which opens it directly in the editor. 

These are examples of some of the things that we have been thinking about. And this is exactly how we want to be working--- putting out crazy ideas, testing them out, seeing what sticks and iterating. Shout outs to Chris, Kate, Bobby, Atul , Brett, Chris, Erin and everyone who has been on Webmaker community calls in 2013. As I said earlier, this is an evolution of our thinking so all these ideas came out of lots of ground work, user testing , hive pop ups and festivals.

That last prototype was built in a period of 48 hours by Bobby, myself and Chris Appleton- so if all it takes is 48 hours to get some collaborative Webmaking action - imagine what we can make happen in 2013!

Reference: Check out this great post by Bobby on the prototype implementation.

Rethinking the Architecture of Webmaker

A few weeks back a bunch of us at Mozilla  had a design sprint to begin thinking through what it would mean for someone to come to Webmaker.org and experience it as user-not a visitor. We started to come up with a few ideas that push forward our thinking on Webmaker as a product. Some of this thinking is building off our work on Designing the Platform to teach the next generation of webmakers. Here are some takeaways from our latest conversations:

In order for us to convert visitors to users, a few things need to happen:

1. The information architecture of the overall site needs to be revisited
We can't think of webmaker.org as a regular website: we need to develop a strategy for people to immediately engage with making something on the web. This will require us to significantly rethink how we are framing our tools and content. The broad strokes view of this here is that overall, there needs to be less of a focus on tools and more movement towards the opportunity to make something.

The current architecture:

The drafty future sitemap:

click for a legible view!

So the key takeaways here are 1) we are moving away from challenging the user to choose between tool and project- they are at webmaker to make cool stuff- and learn while they are doing that- so let's make it easy for them and 2) overall this is a more personalized experience- there are user profiles, dashboards, content that is unique to the user based on their webmaking history, etc.  You can check out the etherpad where we are working through the details here.


2. Single sign on needs to be implemented 
In order to implement a lot of our vision for Webmaker, we need a single sign on- and a built in value for that sign on. Right now the singular value proposition for signing in to Thimble is badges. Yeah, it's more than just a gaming point, it's embedded assessment- but we could be doing so much more - users could get analytics on their webmaking-what are their trends? The kinds of things that they make on a regular basis-only Popcorn projects?, what kind of code do they prefer? JS, pure HTML? How many remixes have they made? The sign on can happen at several different touchpoints- the landing page- or via a button in the universal navigation.

So the landing page might end up looking more like this:

 or this:

 

This will affect users in several ways, the least of which---they can actually be "users" of webmaker.org- save and share their work, but it also takes me directly to #3:

3. The universal navigation needs to be implemented across all properties

We currently have a version of what could become the universal navigation implemented in Thimble:

 

Eventually, this is going to live across all webmaker properties and  transform into a more dynamic navigation/dashboard/ toolbar. So for example, instead of just linking to "Projects" it can link to "My Projects"

 
4. More user- centric content needs to be prioritized 

User centric content will live across Webmaker, so that it becomes a more social platform- and importantly, taps into the social platforms and places that people are already inhabiting on the web outside of webmaker.

One thought is to make a dashboard- that offers users a conceirge to help them figure out what they want to do, but also provides them data about their work, suggestions of things to make based on their usage habits.

 

Another thought it to build out the gallery to be more social and user friendly- so that might mean that a user can follow other users, or recommend peers for badges, create working groups or collaborative hacking sessions. But for starters---we need a gallery, one that integrates user generated content and mozilla starter projects. It will need to be curated but this can also be done dynamically based on user preferences and interactive filters.

There will also be places for people to store their work, collect assets from across the web and initiate collaborative webmaking.

5. Identify touchpoints for "teaching" or peer mentoring.

This one is a little bit less defined than the others, mainly because we need to work with the Learning/ Hacktivators/Hive/ Community teams to identify the need and opportunity here. In general since we see webmaker as a self directed, online experience similar to physical events like the Mozilla Festival-we want people to be able to share lessons learned easily with their peers.  This probably won't mean one section roped off for educators, but an embedded experience, perhaps when a user makes something-they can share a video documenting their process with a friend--- maybe on publish you are giving a hacktivity kit - there is a lot of interest here, and a chance to be innovative.

So that's the general direction of our thoughts over from the UX camp. It's a lot and it's messy but it's all good. Would love feedback. This week I will be working on building out the Webmaker Product vision. Much of this might morph into something else- but I want to document it so we can trace our thinking. I will post on the vision next week.

Lot's of good thinking is happening all around, however, I recommend reading these posts by Chris Appleton that focus on how we might approach Projects, and User Accounts:

Project Discovery

Workshops - a Space to Create

Redesigning Webmaker

The Value of Showcasing Craft

Lately I've thinking been about how we can value the craft of webmaking within the context of Webmaker.org. The topic is fresh on my mind because we are starting to seriously think about how to develop out a gallery presence for the platform that is true to the spirit of our community. This got me to researching a bit about how other web properties highlight this stage in the design process.

Threadless does a nice job of surfacing the process of individual t-shirt designers on their site. Very simply, they have a curated section of blogposts featuring designers going into detail about how they made the product.

First they profile the user, and then they show great process shots like this one below by Joshua Kemble:

Additionally, they have a critique section of their site, where users can rate in-progress shirts and provide feedback via commenting. Again, super simple and effective. There are so many reasons to do this kind of highlighting of process, but for Threadless, it serves three functions well: 1) as an educational resource that isn't in your face "here is how it is made," but in fact offers many ways to make similar things and 2) as a way to elevate their product- they highlight masters who have done cool work, and show you how to do that too and 3) as a way to build community.

Sketchpad.cc highlights process but in a very different way. In their gallery, instead of just showing the end product, they include the code which can be seen as a video replay. I find it compelling because it allows you to see the different decisions that the creator made when designing the animation. In turn the entire process is treated as a journey. I've seen other sites do similar things, and in a less organic way, a lot of cooking websites do this with their video documentation of their step-by-step tutorials, but I like that it's not really a tutorial- that the verb - or the action is actually an appreciated part of the design- possibly even elevated higher than the end product.

So we have two forms of process documentation so far, and my last site that I am going to talk about is so documentation heavy- that it might blow your mind: Github. Like other version or bug trackers, here you find a community of people who are collaboratively crafting documentation for their project. I like this as an example because you can see the history and different phases of the project.  So on an incremental level you can see how the project was built up, who forked what code, who hacked what - and from time to time, particularly with their "Issues" section of the app- you can see conversations about how decisions were made.

It seems like there is some awesome formula for success here- like 1 part documentation plus 2 parts social plus 1/8 part inspiration, 2 tsps of process and 4 cups design thinking = craft. 
Right now we are still in the research phase of the gallery for Webmaker- but what's clear to me is that it needs to accomplish a few things: it needs to be social, inspiring, educational, live across the web, and very importantly - have some level of showcasing the craft of making things on the web.

Building and Protecting My Community

During my day job, I am a designer at Mozilla and I advocate for learning how to understand, contribute and code the web so that you can protect it. I often talk about how the web is a hand crafted community that can only represent the world that we live in when individuals build webpages, so that they can make their mark and be part of the conversation. Two weeks ago, when Hurricane Sandy hit New York, it devastated- and in many ways destroyed the community that I grew up in- Rockaway Beach, New York. I went to my neighborhood and saw that people could not communicate with eachother or the world outside Rockaway- no cell phones, no internet, no power. When I returned home I built a small website- rockawayhelp.com just to give people the information they needed and to provide a way for families of locals to feel more connected. It was this act of webmaking that launched my participation in protecting and rebuilding my physical community.

I feel that the work that I do in the open source community and the open educational resource community prepared me to take on this small bit of leadership. Rockawayhelp.com to date has a minimum of 6,000 hits a day. Our facebook account has 8,873 users and our twitter account has 450 users- not ground breaking, but it's something. We put up a small volunteer form and in the first day got 600 volunteers. We put up a help request form and got 150 requests. We have active conversations on our social media channels and have a real active presence on the physical streets of our community- going into houses, cleaning out basements, connecting people who don't know where their family members are and working with the vets at Team Rubicon and the software developers at Palantir.  Here are 5 lessons that I learned as a designer- that helped translate into community engagement and activism:

Lesson 1: Working in the Open- Creates Community
When I was sitting at home worrying if my parents survived the hurricane- I went online and connected with friends and other Rockaway residents who were watching the local news and having panic attacks about their homes and families. We shared information, brainstormed ideas and gave each other the confidence to venture back into our community when the storm ended. I was scared, but knew that I had an online community. This is something that I learned while working at Mozilla- if you work in the open, you can share information and connect to a like- minded community. We do this daily with our Webmaker activities, starting with Hackasaurus two years ago- at first it was just some geeky librarians, Atul and myself- but then it expanded into this massive OER that people immediately responded to because we blogged, shared free resources and created content as a group- failing publicly and then iterating and improving publicly.

Lesson 2:  Leverage the Expertise of Others
So this one was a no- brainer, but in a disaster like this a lot of things needed to be done- and quickly I saw that I was not good at everything. Just for the website effort- we leveraged Blue State Digital who kindly volunteered with us and helped us to set up a database- an effort lead by Matt Kelley. Additionally, we had some who were good at blogging and others who were on the ground and could give us up to the minute info to communicate out. And when we got those volunteers--- and saw we couldn't figure out how to efficiently organize 1000 + people in one day- we partnered with Team Rubicon who had systems in place and a plan. This is commonplace in tech, you can start a project on git, and then get a collaborator to take on parts and be your wing-man.

Lesson 3: Put out Rough Prototypes- and Iterate
Doing software design- I usually throw out an idea that is crap,  then user test it- figure out what part of it works, and then build on that idea to make a new prototype. It's messy- but it works because you get your concept out there in the hands of real users. We are constantly doing this at Rockawayhelp. We really have never dealt with any of this before- so we have to be alright with trying things out, failing a little, and building a more efficient way of doing things. A simple example of this was that we first were standing in front of the local church and collecting addresses for people who needed help and then assigned them to crews of volunteers. We quickly learned that this wasn't the best way to go about things because we were too few people to get everything done- so we streamlined the system by creating forms.

Lesson 4: Peer Mentoring =  Best way to Learn a new skill
For the past few days I have been working with Palantir on mapping needs and getting help out to the community. I learned their system pretty fast by getting mentoring from Alec and Dave, who are experts in the software. There are also a ton of things that I had no clue how to do- like how to break up concrete or the best way to lift heavy furniture- that we have to do over and over and over- so I ask people who look like they know what they are doing to teach me and then I try it out myself. It's just like a hackjam- where I am learning how to code something by sitting near a code ninja.


Lesson 5: Show Up, Be Present- Get Social Karma
Every good hacker knows that they need street cred- whether that is just being at conferences or making yourself known through some form of social currency (like badges) and that holds true for community activism. You need to walk the walk- pick up a shovel, be authentic and ultimately make an effort to proactively rebuild and empower your community.

Just like the web and open source world, your community and neighborhood is hand crafted and it can only be protected if you learn the inner-workings of it and geek out a little by making it all that it could be.