Overview

GistBox is a web-based application built for developers to curate a library of code snippets. The app was written with Backbone.js on the frontend, Ruby on Rails on the backend and deployed on Heroku. It uses GitHub's API for authentication and for storing personal code snippets.

The Problem

Programming is, at its essence, an exercise in applying existing code patterns to new situations. Most of the time, this involves just thinking for a moment. But once in a while, we remember only a small part of the solution and need to do a bit of digging to retrieve the whole thing. All professional developers keep these patterns in the form of code snippets somewhere. They could be in text files, in Google Docs or on Evernote.

When I started GistBox, I was personally struggling to organize this library of code snippets. GitHub's Gist provided a decent mechanism for sharing snippets. However, it was not organized in a form that made the act of retrieving information fast and simple. I also needed something more personal, that was tailored to use by an individual or a small team.

Design

I looked at the systems out there which helped to organize large quantities of atomic information. Apps like Spotify, which featured playlists that could stretch into hundreds of tracks, was structured around discovery, but at the expense of curation. Evernote, which was (and still is) the most popular app for storing and retrieving personal notes, tried to be a single repository of everything worth capturing but didn't do much to accommodate the use case of storing code. My main form of inspiration came by way of one app which, while having nothing to do with software development, worked well for retrieving small "snippets" of information.

Gmail's Labels

The heart of Gmail's retrieval system is its labels. For every email which meant anything to me, I would label it. For instance, whenever I got a flight or car rental confirmation, I would label it with "Trips". Once I arrived at the destination, it was easy to just open up the "Trips" label and scan through the most recent emails to find the relevant information.

The ease of organizing and retrieving emails through Gmail's label system meant that it provided a convenient starting point for my own design. Just as with Gmail, GistBox's labels could be created, edited, deleted and rearranged. They were also color-coded, which provided convenient visual indicators for users as they scanned long lists of code snippets.

The Split-View

Beyond its labels, GistBox's design still needed an interface for the fast retrieval of code snippets. I wanted to accommodate two primary use cases: (1) browsing for content by some set of criteria and (2) searching for snippets by description or file content.

GistBox's split-view design allows for users to operate at the right level of detail for the task at hand. At the top level, there are filters and labels on the entire library. One level down is basic information and metadata about each gist. This gives users the ability to scan the list to browse for content. When a gist is selected, its full content, including all code, is shown in the largest panel.

This hierarchical layout sets up a familiar left-to-right, general-to-specific design pattern and allows a developer to drill down with increasing levels of specificity. This accommodates the case of a dev remembering only vague details about a pattern and using a combination of labels and search to whittle down the possibilities until he finds what he needs. The layout was designed to support a common pattern of mental information retrieval.

Team Gists

Once personal code snippets had been out in the wild for several months, I turned my attention to another important facet of professional coding: sharing code within an org. Unlike GitHub Gists, which were built to distribute snippets far and wide through embeddable widgets, GistBox needed a system that made it easy for any member to access the team library but still kept snippets private from the web.

I immediately faced the dilemma of whether to continue using GitHub's API for Team Gists. The trouble was that gists were specific to a single user in GitHub's world, which meant that a team's code could magically disappear if one of its members decided to disassociate from the team. GistBox needed gists to exist on the team level, which was not a capability that GitHub's API provided.

I ended up writing the data model for teams, gists and members from scratch. The design ensured that a team and its content existed separate from its members. This meant team membership/leadership could be changed without affecting gists.

Technology

GistBox's architecture was designed around low-latency user interaction. I wanted it feel like a desktop app, with the number of requests to the server kept to a minimum.

Backbone

User experience starts at the frontend. Thus it was important that I pick a Javascript framework which accommodated a minimally-chatty interface. I decided against a standard RESTful Backbone data interface because the app needed much of its content upfront. This was to ensure users wouldn't face spinners as they quickly browsed through snippets.

Backbone also allows for easily mixing in helpers. I wrote a bunch of these functions for many purposes, from rendering Date objects to piecing together Gravatar URLs. With such a large single-page app, it was also important that changes were uniformly applied to every corner. Helpers ensured that code was reduced and reused.

Ruby on Rails

I picked Rails for its awesome ecosystem. Coming with great support for writing APIs straight from the box, Rails is made even better with Ruby Gems, which are single-purpose packages of code for everything from request caching to generating cat memes.

For GistBox, I relied on a number of great gems:

• Unicorn - Allows for multiple server threads to be pooled into a single server process, making Heroku dynos 4x more efficient
• Pusher - Gives GistBox the ability to automatically refresh team members' local library if another member makes an edit to a team gist
• RABL - Makes writing JSON output much easier through the use of templates

For the full list, check out the GistBox About page.

Heroku

Deploying on Heroku was an easy choice to make. I wanted to write apps, not manage servers. As a platform, Heroku has nice support for load scaling (which I made full use of when Addy Osmani tweeted about GistBox) and for integrating with monitoring services like New Relic. While not the cheapest solution by any measure, Heroku's ease of deployment and flexibility was the right solution for an app of GistBox's size.

Adoption

To date, GistBox has over 35,000 registered users, with about 20% of them coming back each month. There have also been over 2,200 teams created along with 11,000+ team gists. The Chrome Web Store boasts over 22,000 users of the packaged app along with 6,000 installed users of the GistBox Clipper, a companion extension for creating gists from any content on the web.

Overview

I joined Yesware as the company's first full-time engineer in June of 2011. The founders, Matthew Bellows (CEO) and Cashman Andrus (CTO), brought me on to help design and build out Version 1 of Yesware for Gmail. Here was the problem we faced:

Salespeople spend a big part of their day performing data-entry and other largely automate-able tasks. What could Yesware do to help make their professional lives more meaningful? How could we help sales professionals focus on the one thing they do best: selling?

Three years, two rounds of VC financing, one acquisition and 500,000+ users later, Yesware is now the market leader in helping salespeople close more deals, faster.

Below are stories of two features I worked on which contributed to Yesware's success.

Templates

The very first feature I worked on was Yesware's templates interface for the Gmail composer. We started with email templates on the assumption that typing repetitive emails in response to similar customer inquiries was the number one time waster in a salesperson's day.

We were right. Templates quickly got our foot in the door at many small-to-medium-sized sales organizations. During the first year, I lead the design and frontend engineering effort to make using templates an even better experience. Early customer feedback and subsequent iterations led to features like subject lines and peer-sharing.

When Google introduced the new Composer design for Gmail, we knew it was a good opportunity to re-evaluate the templates experience. In Version 2 of Yesware Templates, I focused my attention on satisfying 2 primary use cases:

• The ability for a high-volume sales rep to quickly find and insert templates
• Allowing for sales team leaders to manage a library of commonly-used responses

For the first use case, we introduced a mini-dialog for the Gmail composer which allowed reps to drill down and search for templates quickly. For reps who used the same handful of templates over and over again, we also presented an option to curate a list of favorites.

In the second case, sales team leaders wanted a larger interface to edit, delete and move templates. We designed the management interface to be comprehensive without being overwhelming. The ample whitespace, strategically placed controls and logical information hierarchy gives users the feeling of control over chaos.

Events Feed

While high-volume outbound reps were interested in speeding up their outreach with templates, there was another group of sales representatives who wanted to gather more insight about their leads. These account executives, who were in charge of closing deals, needed help in prioritizing tasks and learning as much as possible about prospects.

The Yesware Events Feed was created to assist in these goals. The Events Feed displays opens, clicks and presentation views for every tracked email a rep sends out. The second feature I helped design and build for Yesware, Events became an important source of information for reps to gauge prospect interest.

Events were designed to be updated in near real-time. This was crucial for reps who had to react to interest at a moment's notice. The focus on fast data became even more important when we realized that calling a prospect when a deal was top of mind, significantly improved connect rates.

Where Yesware is Now

Half a million users later, Yesware is still focused on improving the lives of salespeople. The goals of saving reps time and providing actionable insights continues to drive much of the product. And with the move into Microsoft Outlook and Apple iOS, Yesware is setting up to tackle a large market by being everywhere salespeople work.

Overview

On most workdays, I take the MBTA Commuter Rail from Salem down to Boston. The conductors would often check fares right after passengers get on. Fortunately, the MBTA does provide passengers with an app to store and use virtual tickets. Unfortunately, the experience of using tickets leaves something to be desired. In order to activate a ticket, I have to:

1. Pick a route
2. Choose from one of many (identical) virtual tickets
3. Tap to activate the ticket
4. Tap to confirm activation

The whole process means I'm often holding up the conductor for 30 seconds while I scramble to activate a ticket. 30 seconds doesn't sound like much. But when there are dozens of passengers performing the same inefficient actions, the wasted time adds up.

Ticket activation / Schedules

Swipe to activate

With the activation flow redesign, I wanted to focus on providing an experience that was both easy and safe. Rather than forcing users to go through an activation dialog, the app instead relies on a simple swipe gesture to confirm activation. While simple for human fingers to perform, swiping on a particular section of the screen is difficult to do by mistake.

Location-Aware Schedule

In addition, I observed that while waiting for the train, commuters mostly care about when the next train would arrive (taking into account any service delays). The current app shows passengers the entire schedule for a train line, forcing them to hunt for their specific station. Service alerts are shown on a separate screen. This forces users to parse and aggregate information from disparate sources (and do a bit of math) to figure out how long they'd have to keep waiting. Not a good experience.

Instead, I envisioned a location-aware schedule which lets users know when the next train would arrive at their station, based on their phone's GPS location. It would automatically take into account any service delays and cancellations. And while the UI footprint would be tiny (just a single line), it encompasses a much greater deal of intelligence.

What's Next?

The MBTA recently released V2 of their API. While it does provide real-time information on train schedules, there's still no way to hook into the ticket purchasing/activation process.

However, the location-aware schedule feature of my redesign may still be valuable. I will certainly be toying around with the iOS SDK to see if I can make the minimized design a reality.

Stay tuned.

Splash image from Adam Moss / Flickr

The Problem

The National Agricultural Statistics Service (NASS) branch of the US Department of Agriculture (USDA) is in charge of gathering various statistics on crop production. This information is used by everybody from industry analysts to university research labs to understand the current state of US agricultural production.

In addition to filing monthly reports on the data it collects, NASS offers an API into their 33M+ records via a system called Quick Stats. While Quick Stats is very powerful, it also features a steep learning curve. After it was released, the organization found that only sophisticated researchers with programming experience were able to extract data. To make the database more useful, NASS developed a UI for the query interface. But with the number of options available, it was still difficult for a casual user to extract actionable information from Quick Stats.

Visualization Design

NASS came to me with a proposal to develop an interactive data visualization on top of Quick Stats. It was to allow researchers and the general public to explore NASS-produced data and gain insight into crop production trends and anomalies. As opposed to visuals featured on investigative reports from places like the New York Times, the app had to be general enough to allow users to draw conclusions for themselves.

Quick Stats data comes back as records of many fields, all of which describe some aspect of the measurement. But while there can be a lot of information to glean from a single record, the 3 most important pieces for visualization are the ones which describe location, time and value.

{
    "week_ending": "",
    "state_name": "ALABAMA",
    "country_code": "9000",
    "location_desc": "ALABAMA",
    "begin_code": "00",
    "zip_5": "",
    "county_ansi": "",
    "state_alpha": "AL",
    "util_practice_desc": "ALL UTILIZATION PRACTICES",
    "domain_desc": "TOTAL",
    "asd_desc": "",
    "freq_desc": "ANNUAL",
    "prodn_practice_desc": "ALL PRODUCTION PRACTICES",
    "end_code": "00",
    "sector_desc": "CROPS",
    "short_desc": "COTTON, UPLAND - ACRES PLANTED",
    "country_name": "UNITED STATES",
    "Value": "315,000",
    "reference_period_desc": "YEAR",
    "CV (%)": "",
    "class_desc": "UPLAND",
    "asd_code": "",
    "agg_level_desc": "STATE",
    "county_name": "",
    "region_desc": "",
    "watershed_desc": "",
    "state_ansi": "01",
    "congr_district_code": "",
    "domaincat_desc": "NOT SPECIFIED",
    "state_fips_code": "01",
    "group_desc": "FIELD CROPS",
    "watershed_code": "00000000",
    "unit_desc": "ACRES",
    "source_desc": "SURVEY",
    "load_time": "2015-12-09 12:00:55",
    "county_code": "",
    "statisticcat_desc": "AREA PLANTED",
    "commodity_desc": "COTTON",
    "year": "2015"
}

I decided that a map would be the most usable way to visualize geographic trends in the data. A timeline would assist in letting users scrub between years and focus on time periods they're the most interested in.

While a map was great for visualizing trends over time, we still needed a way to compare data across US states. A simple bar chart was all that was necessary for this. A bit of animation helped to bring the user's attention to changes in value.

Implementation

Docker

The USDA visualization app was my first foray into running Docker containers. I wanted to ensure that the app operated the same way across my OS X dev machine and DigitalOcean's Linux boxes. Docker made it possible to do that with just a few hours of configuration effort.

Getting Rails and Nginx working with Docker took some trial-and-error. I found a few guides to be quite useful in this effort:

• How to cache bundle install with Docker
• How to deploy a Rails app with Unicorn and Nginx on Ubuntu
• How To Add Swap on Ubuntu 14.04

D3

I wrote all the code for the timeline, map and chart with Mike Bostock's excellent D3 visualization library. The D3 gallery provided all the inspiration I needed to get some of the trickier interactions working seamlessly.

508 Compliance

The project was also my first project for which I had to pay close attention to accessibility requirements. Right off the bat, I realized that for text to appear crisp on older monitors, I couldn't stick to the usual light grays and thin fonts favored by so many startups design guides. You'll notice that colors and text on the USDA app were chosen with high contrast in mind.

In order to ensure screenreaders could sensibly navigate the page, I spent some quality time with Apple's Voiceover feature and the University of Illinois's Accessibility Evaluator. As I wasn't used to accessing the web without the benefit of sight, it was a very humbling experience to discover all the issues my app had around accessibility.

What's Next

The extendability of the USDA app is fairly obvious. The app will be augmented with new options as new data around crops become available. This is currently done through a single configuration file.

What's less obvious is how we can further enhance the visualizations to provide even more insight into the underlying data. A promising next step would be to work with USDA's analysts to understand ways to visually present some of the more astonishing (yet hidden) features of the data.