OpenHatch: the startup

OpenHatch started out as a web startup founded in May 2009 by three alumni of the free culture and free software movements as part of startup incubator Shotput Ventures' inaugural class. OpenHatch built online tools to demonstrate and broaden open source developers’ experience and expertise in order to make the open source community better connected, more productive, and ultimately better rewarded.

I joined OpenHatch in late June 2009, about a month and a half after the company was founded. My initial duties were mainly research and writing related: learning about our target audience, researching competitors, preparing for meetings with industry leaders, and writing OpenHatch’s business plan. Over time, I became responsible for the site's graphics, design, and user experience as well.

I designed a ‘mascot’ of sorts for OpenHatch: Sufjan the baby penguin. Among other places, Sufjan appears as the default profile photo for new OpenHatch members.

All of the header cartoons and illustrations on OpenHatch's website are my work. They have become the face of OpenHatch and remain the most uniformly-liked, remarked-on part of OpenHatch’s user experience.

I developed personas, mocked up UI elements for user feedback, and worked on the site's design. Through many iterations, we tried to make the various tools on the OpenHatch website clear, responsive, and fun to use.

Given OpenHatch’s target audience, we needed to create a design that would appeal to open source software developers. Since most open source software project websites are designed by the coders who contribute to the project, not designers, they tend to be highly utilitarian (or, less charitably, ugly). I and the other designer on the team, Raffi Krut-Landau, worried whether this was just because many software developers didn’t have the skills, time, or inclination to do better, or if they were actually attracted to logos and websites that were spartan or garish.

Our design breakthrough came after I talked to my father, a software engineer and contributor to the Linux kernel. The initial site design was inspired by his and other engineers’ typical work wardrobe: minimalist; white, beige, and pale blue stripes; and cartoony site graphics—reminiscent of Dilbert—for a little color. It was a thrill when one of our users described the design to us as “clean, simple, friendly, and joyful”—a synthesis of my and Raffi’s personalities.

One early feature whose design we iterated on extensively was the automatic experience importer, which took the usernames a user regularly used in their open source software work and collected all the FOSS contributions associated with those usernames. We needed to develop an interface which would make it easy to quickly approve or unapprove the contributions the importer found (since most would not need any editing) while still allowing users to make edits if necessary. We also needed to make it clear what parts of an older contribution had been updated if new material was found and also offer an interface through which users could add contributions by hand if the importer failed to find them automatically. And, ideally, we had to do all this in a way that would not consume an excessive amount of vertical space. Through many enthusiastic debates, scribbles on whiteboards and scratch paper, Photoshop mockups, and user feedback, we eventually developed an interface that would accomplish our goals.

I also was key in creating and prioritizing the team's Agile-style user stories and arranging them into achievable, coherent sprints as we raced to get enough features done by Demo Day.

At the end of the summer, I outlined, prepared the slide deck for, and delivered part of OpenHatch's pitch at Shotput Ventures' Demo Day event for over 200 investors, entrepreneurs, and journalists.

Though we decided not to implement them in OpenHatch, I wrote a white paper and series of blog posts on applied game mechanics in web applications.

OpenHatch: the non-profit

After I left OpenHatch towards the end of 2009, the startup morphed into a more traditional open source software project. I continued to contribute by volunteering with UI and graphic design and release planning and began making code contributions in Python and Django as well, such as OpenHatch's data dump sanitizing scripts and the "buildhelper" feature for project pages.

Now that OpenHatch has made the transition to being a non-profit organization, I serve on OpenHatch's board of directors. I help apply for grants, represent OpenHatch at conferences, write blog posts, volunteer for OpenHatch-affiliated outreach events, connect with potential collaborators, and define the strategic trajectory for the organization.

I still contribute code, art, patch review, and release planning work; I was central to the site re-design and coordinating OpenHatch's expo hall booth and marketing presence at PyCon in 2012 and 2013. I designed two OpenHatch t-shirts--one in 2012, one in 2013--as thank-you gifts for contributors and donors. I also designed OpenHatch laptop stickers in 2013, which went into the swag bags for all 2500 PyCon attendees.

canitakemybikeonbart.com

My first Flask app, deployed on Heroku.

Mystery Hunt 2013

I served as the volunteer art director for the 2013 MIT Mystery Hunt. This year's Hunt was heist-themed.

In my role as leader of the writing team's art team, over several months I managed a group of volunteers in completing art-related tasks for the MIT Mystery Hunt. I also completed a number of crucial art tasks myself, including:

The Hunt invitation.

The opening ceremony slides..

Logos and brand identities for various fictional corporations within the Hunt.

The 2013 Hunt coin design. (Each year's coin design is unique. Finding the coin is the objective of the Hunt. Each member of the winning team received a solid metal copy of the coin.)

The Hunt t-shirt design.

I also designed and coded a majority of the front end for the Python/Flask-based Hunt website, working closely with the tech team.

On the hunt homepage, as each round unlocked, a silhouette of the heist team member would appear; when the round was solved, the silhouette would fill in with the full-color character. The obstacles would similarly appear in silhouette and then fully as they were solved by teams.

Each round sub-site had its own theme.

The MIT Mystery Hunt is one of the oldest, most complex, and highest production value puzzle hunts in the world.

Pulse

Pulse, a classroom feedback mobile application, was my group final project for my UI Design and Development class in spring 2011.

Pulse was a simple mobile-based application for large lecture courses that allowed students to submit their current emotion and monitor the sentiments of other students around them during class in real time. Pulse was meant to help solve chronic problems in large lecture courses, including lecture formats not designed to be interrupted with questions, students feeling afraid to ask questions in front of a large group when they're confused, students not knowing how their classmates around them are feeling, and the typical lack of quantitative course evaluations that allow for mid-course corrections.

To develop this application, over the course of the semester, my four-person group followed a formal user experience design process from stakeholder analysis to initial experimental tests of a working prototype.

We performed contextual inquiry on users and stakeholders with interviews of students and professors and participant observation of classes.

From that data, we created various culture, sequence, and flow model diagrams of classroom processes and power dynamics.

Finally, we created five personas--three students (Tessa Schmitt, Justin Brough, and Hye-Seong Park) and two professors (Dr. Erik Olufsen and Dr. Alvin Crumplebottom, Sr.).

In the beginning, we saw our app as creating a forum for dialogue between students and professors and thought it would be useful to both groups. However, based on our interviews and other responses, we found that many professors didn't think they wanted or needed such feedback, and even those who did noted that there were no institutional incentives for them to use our system. Thus, we pivoted to focus on the needs of students, without any assumptions of professorial engagement.

We then iterated on paper and digital (Balsamiq) prototypes, performing both in-person user "think-alouds" and heuristic-based evaluations to find UX bugs and make improvements.

These tests prompted us to switch from a complicated series of line graphs to a simpler bar chart for tracking emotion, offer only a pre-set selection of emotions instead of allowing user-submitted ones, and to simplify further by removing the distinction between questions and comments.

At this point, I also created our set of custom emotion icons for use in our later prototypes.

My teammate Alex Chung was then able to create a working Android-based prototype.

Finally, we tested the prototype qualitatively and quantitatively with students. We presented our experimental results and final report to our class and showed our application poster at the UC Berkeley computer science department's May 2011 UI Design Tradeshow.

"Suck It Up, Princess": Diversity and Outreach in FOSS Communities

For my Social and Organizational Issues of Information class in spring 2011, I wrote a research paper called "'Suck It Up, Princess': Diversity and Outreach in FOSS Communities" (html)(pdf). The paper examined current processes of how new contributors get involved in free software, how subtle biases in those "recruitment" mechanisms might account for the gender gap in free software contribution, and possible ways that free software projects could address those issues in becoming friendlier to newcomers.

The paper made the rounds through various free software and free culture circles. In August 2011, I published a condensed version as an article for Ubuntu Women's column in Full Circle Magazine.

Community Management as a User Experience Problem

In November 2011, after sending my paper around Wikimedia's listserv, Wikimedia Foundation's executive director Sue Gardner invited me to give a tech talk. The talk, "Community Management as a User Experience Problem", covered similar themes as the paper using the lens of user experience design to uncover problems and roadblocks that new contributors typically face.

Improving Documentation With "Beginner's Mind"

In March 2012, I gave another related talk at PyCon about getting into the mindset of newcomers when writing documentation, playtesting your open source software project's docs, and generally the importance of good installation and tutorial docs in growing your project's community.

Code for America Brigade

Summer 2011: Geek Corps

During my Google Summer of Code-sponsored internship at Code for America in the summer of 2011, I designed and helped build a prototype Ruby on Rails application then called "Geek Corps".

The application was a documentation repository and collaboration platform to help volunteers hack on and redeploy Code for America's civic apps in non-CfA client cities.

Geek Corps was the initial attempt to solve the problem of how Code for America could expand the number of people involved in modernizing civic technology without making their fellowship program unmanageably large. Before this application, when interested potential volunteers contacted Code for America and asked how they could help, Code for America did not have a place to point them to--there were no resources for wrangling volunteers. With only thirty fellowship slots for over five hundred applicants for the 2012 fellowship class, there was far more interest in improving city technology and civic hacking than Code for America's tiny staff could handle. By creating a clear entry point and resources for new volunteers, Geek Corps was meant to be a whole new channel for Code for America to pursue its mission of making local governments more accountable, transparent, efficient, and agile.

Fall 2011: CfA Everywhere

After the summer ended, I continued work on the project in my fall 2011 Information Systems and Service Design (ISSD) class. There, instead of focusing on technical development of the application, the rest of my five-person group and I stepped back and analyzed the application's stakeholders, requirements, and use cases for the Geek Corps application.

Through stakeholder and user interviews, analysis of Code for America artifacts including Twitter follower data, and research into related technologies and services, we discovered several key findings that had not been present in the Geek Corps iteration of the project.

First, our research suggested that the focus of the application ought to be on all sorts of volunteers, not just (or even especially) volunteer coders. Second, rather than being a sterile coordinating tool for volunteer labor, the application needed to nurture the development of local civic technology communities by enabling not just the deployment of existing apps but events, brainstorms, and hackathons for creating apps for local needs. Finally, we found that the main assets Code for America could provide were not task-focused project management resources but rather a brand name with momentum and credibility and experience and advice in collaborating meaningfully with government for local groups that ask for it.

Based on these findings, we developed a list of requirements and a static prototype for the service, now called "Code for America Everywhere."

As part of this, I designed a custom set of icons for the five roles or tasks associated with getting an app up and running: data, research, design, code, and deployment.

At the end of the semester, we compiled our research into a final presentation and report for classmates, friends of the I School, and Code for America staff members.

2012: CfA Brigade

A week after my group's final ISSD presentation, Code for America received a $1.5 million Google grant for continued work on CfA Everywhere, renamed "Code for America Brigade" for the final time.

Based on my group's recommendations and designs, group member Kari McGlynn and Code for America staff members built a new volunteer-coordinating application over a few short months. CfA Brigade was launched at Code for America founder and CEO Jennifer Pahlka's keynote address at SXSW in March.

IOLab: learning

In fall 2010, I took Information Organization Lab (IOLab), a web programming class where students build five simple web applications to illustrate themes in 202: Information Organization and Retrieval (one of the ISchool core courses).

craigslist++

Craigslist++ was a basic JavaScript/JQuery web application that attempted to ameliorate the vocabulary problem when searching for furniture on Craigslist (e.g. so when you search for "sofa", you would also get results that only include the word "couch"). It used JavaScript/JQuery, Big Huge Thesaurus (along with a custom dictionary), and Google’s Feed Control.

GenreRoyale

Genre Royale mashed up tag data from last.fm's API (since broken) to determine the top artists for a given genre and visualize data about them (e.g. where the artist is touring next). It also took advantage of visualizations from Raphaël and Google Maps.

Djikstronomy

An exercise in implementing tf-idf search, Dijkstronomy was also an experiment in going beyond the traditional "bag of words" document model to a "string of beads" model that natively understood term distance and multi-word searches using Python and Google App Engine.

The Dijkstronomy distance scorer code (nearly entirely my work) lives here. This code would represent each document as a string of "beads", giving each "bead" a distance score (stopwords and hyphenated phrases have a shorter distance, terms separated by punctuation have a longer distance). A Term class would keep track of the addresses where that (stemmed) term appeared in each of the documents in the corpus. Given a two-term search, then, the code would search forward and backward in the document up to seven steps to determine what the average distance between the terms was for each document, then calculate the raw distance into an adjusted distance score. This score would then be integrated into the traditional tf-idf formula.

IOLab: teaching

A year later, when IOLab was offered again, I served as the class's teaching assistant. I led lab sessions every week, answered students' questions, wrote an HTML/CSS/JS cheat sheet, helped debug problems, and graded their homework.

I also gave a few lectures and tutorials with live code demos: one on beginning JavaScript and JQuery, one on CSS3 and basic design, and a self-written two-part Django tutorial open to the whole ISchool.

All IOLab projects are group projects, with groups of 2-4 students. Our rule was that students should avoid working with anyone that they worked with for a previous assignment. The students were able to keep to this principle for the first three projects by their own devices, but by project 4 it was getting difficult for students to group up uniquely. Thus, just for fun I wrote a grouping script in Python and used it to assign groups for project 4. (By the project 5 it was hopeless, so students could work with whomever they wanted.)

Getting Sh*t Done

In January 2012, Google Tasks randomly lost all of my todo items with assigned due-dates. (Which, practically speaking, was nearly all of them.) In a fit of pique, I responded by designing, building, and deploying my own hand-rolled todos application, lovingly named Getting Sh*t Done after the book/cult of (almost) the same name, in about two weeks using JQuery UI, Python, and Django.

GSD is extremely simple, too simple at this point to be anything more than a dirty hack or demoware, but it works. It was the first time I built a Django app entirely soup-to-nuts, including deployment.