Jun 03 2011


Relevance Welcomes Mike Nygard to the Team

It is with great pleasure that I get to publicly welcome our newest team member, Mike Nygard. We've known Mike for a long time, and have been attempting to brainwash him into believing we deserved to have him join for nearly that long. After years of #hbb, too-smoky-to-drink-Scotch, and adopting a new language to play with, we finally managed the task.

Mike's bio:

Somewhere in the mid-90's, Michael went from "young hotshot" to "grizzled veteran". He's still not sure quite when or how that happened. It might have been the beard.

It might also be that Michael has worked in many different kinds of software development across many different domains, starting with assembly in the 8-bit micro days up through Java, Scala, and Clojure for massive distributed systems. That experience includes massive companies like Unisys, Best Buy, 3M, and Target, along with two startups that grew from 30 to more than 100 people, plus three terms as an independent consultant. He's always looking for people who know they can do anything, and that describes Relevance.

His desire to teach others shows in daily work, in speaking engagements, and in writing. Michael wrote "Release It!"---about building large scale systems to survive the real world, rather than just passing QA---and has contributed to several other books. These days, he is devoted to improving the odds that a client's system will make money for them, through a deep understanding of time, uncertainty, risk, ignorance, and architecture.

He finds it astonishing that the most buzz-worthy technologies of the past two years are Emacs, Vi, Lisp, and batch processing (Hadoop).

We were unable to convince Mike that we were really LivingSocial during his "interview". We did, however, convince him that we understood how to use parentheses appropriately when coding, and this seems to have done the trick.

Welcome aboard, Mike!

Apr 20 2011


The one where we welcome two more to the family

Our Apple gambit paid off. Two poor, easily deluded suckers......I mean, two fine, intelligent and wonderful people have decided to join our growing chorus. Let me introduce you to:

Jamie Kite Jamie is passionate about creating elegant solutions to complex problems. After receiving her B.S. in Computer Science from UCF (University of Central Florida, or alternately "Under Construction Forever"), she stumbled upon a social media marketing start-up in Orlando, FL where she went from Front-End Developer to Senior Ruby Developer and Project Lead faster than you can say "cakeplow." Jamie is equally comfortable debugging Ruby code as she is reworking designs in Photoshop or writing poetic CSS. She lives her life by the "Under Construction Forever" mantra, always learning and eager to pick up new technologies and techniques to improve her craft. When she's not writing code or designing user experiences, you can find her presiding over wedding ceremonies, pulling weeds, or cooking and writing for her food blog.

Lynn Grogan Lynn arrived in Durham after a two month road trip looking for a new place to live. She found Relevance and lured them in with two lines in her cover letter which read: I have memorized exactly two jokes in my life, but they are inappropriate for a cover letter and I would have to meet you in person to gauge whether or not they are appropriate to tell during an interview. One of them involves Willie Nelson, the other one involves a runny nose. Clearly these were good jokes because they hired her on as an office manager. Prior to Relevance, Lynn was working as Director of Operations at VonChurch, Inc. a firm in San Francisco that specializes in recruiting for the video game industry. Prior to that she was doing lots of stuff that mainly involved art galleries and coffee. Lynn was born and raised in the fine state of Wisconsin and has a B.A. from UW-Madison in Sociology.

I think we can stop pretending to be other giant companies now. Sorry, Groupon and Apple. We're still hiring, though, so this time, if you are interested, I'll just let our awesome team speak for itself.

Apr 06 2011


When You Start, Define How You Will Behave

When you are starting a new company, there are a lot of things you are asked to announce at the start. What are you going to do? Why are you doing it? What makes you so special? Why is your social coupon FPS better than LivingDiscountKillzone? Exactly when do you reach the magical $12B valuation?

By all means, answer these questions. Each is important to some constituency, be it the employees you will try to attract, the investors who are clamoring to get in, the customers you hope to target, etc. The great thing about the modern world of “lean startups” and “the pivot” is that you are expected to throw each of these answers away after three months. After all, the purpose of a startup is to discover a sustainable business model. Your first guess is going to be wrong.

I’d suggest that, in addition to these ephemeral things, you also consider strongly announcing to the world how you are going to behave while you build this thing. This, however, is not ephemeral. It isn’t something you should pivot away from. It can’t be subject to A/B testing, and it can never be diluted through Series DD financing. It is the absolute statement of what you should expect of yourself, in normal times and in the face of crisis.

I recently had to craft a document for a new venture, and it includes the following paragraph:

I expect that we’ll create a company dedicated to the idea that you can be a capitalist, and still be a decent person at the same time. That we will treat employees, customers, investors and vendors with fairness, honor and dignity. We will empathize before we criticize, but criticize when it is important to do so. We’ll endeavor to understand our company’s externalities, minimizing the negative ones, accentuating the positive ones. We will, in all ways, act as if people actually matter.

Whenever the organization faces a tough decision, whenever it operates under stress, whenever it asks itself “what do I do now?”, it will have this statement as a guide. I guarantee that such a statement will eliminate a world of possibilities from the choice it has to make, and will draw a big Skitch-style red arrow at the right choice. You can pivot away from what you do, but you can’t pivot away from who you are.

Apr 05 2011


Introducing Postfixer

"Have you got anything without spam?"

We recently heard from a client concerned that a few of his customers weren't receiving automated emails. His email account was filling with hundreds of bounce notifications, customers were getting frustrated, and there was nothing he could do about it.

Inspection of the Postfix logs on his and several other servers revealed a systematic problem. When these apps were first deployed, most emails were successfully delivered to customers (although a few might have ended up in the Spam/Bulk folder). Over the years, however, the spam problem has only gotten worse; and email clients, ISPs, and mail services aggressively terminate suspect messages with extreme prejudice.

Enter Postfixer

Most of us aren't Postfix gurus, let alone email experts. Postfixer helps with the following error-prone tasks:

  • Configuring Postfix properly
  • Setting up the necessary DNS entries
  • Testing everything to ensure your emails make it to the Inbox

Postfixer is a standalone utility powered by Capistrano. Git clone it, drop in a config file, and say goodbye to the Spam folder.

$ git clone
$ cd postfixer
$ cp

Here's a sample config:

application_user: deploy

sudo_user: deploy

Let's break it down:

canonical_hostname: Fully-qualified domain name (FQDN) for your application server

additional_hostnames: Any additional hostnames that this server is known by (may be empty)

email_domains: All domains for which this server should be able to send email

forwarding_address: Email address for local messages (such as errors from cron jobs)

  • I typically use "errors@" followed by the first entry from email_domains.
  • The domain (the part following the @ sign) MUST be included in email_domains.
  • Email addressed to local user accounts (root, nobody, etc) will be forwarded to this address.

envelope_sender: SMTP envelope sender (where bounce messages end up)

  • As with forwarding_address, the domain (the part following the @ sign) MUST be included in email_domains.

application_user: Local user account under which your application runs

  • Emails addressed to this user's account (for example, error messages from cron jobs) will be sent to forwarding_address.
  • Outgoing email from this user's account (messages sent by ActionMailer without an explicit From address or sent using the /usr/sbin/sendmail binary, for example) will be rewritten to change the From address to the forwarding_address set above.

sudo_user: Local user account with root sudo permissions

  • Postfixer will SSH into the server using this account. Might be the same as application_user.

address: FQDN or IP address used to SSH into this server

Once you've updated your Postfixer config, a number of cap tasks are at your disposal:

$ export   # specifies which .yml file Postfixer uses
$ cap email:send_test_email                 # send a test message
$ cap email:check_dns                       # print a report of your existing DNS entries

The send_test_email task uses the very helpful port25 verifier. If you're like me, the response to the test email looks something like this:

Summary of Results
SPF check:          softfail      (BAD)
DomainKeys check:   neutral       (BAD)
DKIM check:         neutral       (BAD)
Sender-ID check:    softfail      (BAD)
SpamAssassin check: ham           (GOOD)

Yuck! Let's fix that up.

$ cap email:install_packages                # install DKIM-milter (and Postfix, if not installed)
$ cap email:backup_config                   # archive your current config files
$ cap email:generate_config                 # generate new config file based on the .yml
$ cap email:install_config                  # copy new config files to the server
$ cap email:restart                         # restart Postfix and DKIM-milter
$ cap email:print_dns                       # generate a report of the DNS changes you should make

Based on the output from print_dns, you should add/update your DNS configuration. If you're using Slicehost for DNS, log in and edit DNS entries via SliceManager. Otherwise, check with your registrar (Namecheap, GoDaddy, etc).

(Note: print_dns assumes you're using Google Apps. If you're using your ISP's or your own incoming mail server, replace "" in the SPF records with something appropriate to your setup.)

Once you've updated your Postfix config and DNS entries, give cap email:send_test_email another try.

Summary of Results
SPF check:          pass          (GOOD)
DomainKeys check:   neutral       (BAD)
DKIM check:         pass          (GOOD)
Sender-ID check:    pass          (GOOD)
SpamAssassin check: ham           (GOOD)

Ahhhhh, much better.


Postfixer does not (yet) check if your server is on a blacklist

  • I recommend the awesome DNSBL Lookup tool from
  • If your server is on a blacklist, you'll need to request to be removed (the process should be available on the blacklist provider's web site)

Postfixer does not check for general DNS issues

Posfixer does not (yet) support Yahoo DomainKeys (as seen in the port25 verifier results above)


Huge thanks to Relevance for giving me Fridays to make these kinds of contributions.

Thanks also to Shay Frendt for being my first guinea pig and for his new feature ideas.

Thanks to Mike Bailey for deprec, from which I got the idea to generate config files locally (using ERB templates) and deploy via Capistrano.

I'd like to contribute

That sounds great; I'd like you to contribute, too! Postfixer is available on Github and distributed under the MIT license.

Mar 02 2011


Relevance Turns 30 (people)

All that pretending to be Groupon the last time around really helped with recruiting (not to mention revenue, what with all the coupons we sold). As a result of all this gorging on awesome software development, we had to convince some more folks to join our team. Since last we spoke, we've been incredibly lucky to add:

Ben Vandgrift Ben Vandgrift has devoted himself to the cause of 'better living through automation' for the past 15 years. After completing a BS in Software Engineering (Kentucky), he entered the world of enterprise software development. He has since been recovering--despite a growing startup habit--by applying himself to progressively smaller and smaller companies doing bigger and better things. An entrepreneur at heart, Ben also dabbles in art and music as time infrequently allows.

Marc Phillips Marc went to Colorado College where students take one class at a time for three and a half weeks straight followed by the next one, with three and a half days off in between for the whole school year. That means geology classes are month-long camping trips, literature courses require a novel a night, and biology labs often result in the sharing of hopes and dreams with fetal pigs. After waking up one morning in Seattle he got his first job at Microsoft in 1997 by explaining his ride had already left and they might as well give him something to do. After 10 years in mobile devices and forgetting to cash in his stock options before they expired, he spent the next 4 years in emerging markets and technology incubation, moving into online services and managing teams inspired by rapid iteration and agile development practices. His passion for taking risks, making mistakes, and learning from them for the benefit of others was exhibited in its purest form when on a trip to the Costa Rican jungle he led a group through the trees after their jeep broke down, discovered a hidden mud hole by sinking in it up to his waist, then located and diverted a swarm of army ants that was preparing to raid their cabin with his bare feet while trying to clean his pants, all in under 30 minutes. While he now focuses his action-oriented iterative style on more technical projects, he still frequently does his best work without pants.

Michael Fogus Fogus started out as a philosophy major (with a focus on Nietzschian vs. Kantian philosophy), but finished with a B.A. in Computer Science from St. Mary's College and an M.S. in Computer Science from Johns Hopkins University (with a focus on A.I.). As a software developer with experience in RTOS development, distributed simulation, machine vision, code generation, and expert system construction, Fogus has spent significant time with C, C++, CLIPS, Common Lisp, Java, Jess, Python, Scala, and Clojure. Additionally, Fogus has been involved in the Clojure and Scala communities as the Co-author of the book "The Joy of Clojure", author of numerous Clojure libraries, and a one-time external maintainer of the Scala XML language facilities.

Luke Vanderhart From a young age, Luke has been fascinated by the possibilities of computation. Through highschool, he worked for a startup in Colorado, developing a distributed semantic network knowledge management product. He took a break from software development to get a degree in Philosophy and Linguistics from the College of William and Mary, only to discover that both are profoundly relevant to the art of creating software. After college, he worked as a consultant for several large corporate and government clients, doing enterprise-scale data management and search. During this time, he became fascinated with the beauty of functional programming, particularly Clojure, and ended up writing a book on it (Practical Clojure, published by Apress) with the help of Stuart Sierra. He lives in Annapolis, MD with his wife Hannah, who is a poet.

I think for the next round of recruiting we're going to pretend to be Apple. I hear they are doing some interesting things.

Feb 22 2011


The Legend of Team Iron Chef

This year, instead of holding our retreat the way we always have (holing up in the office for two days and pretending to discuss important things between Magic duels and Rock Band shenanigans) we decided to do something different. Since we're much larger now (28 this year compared to 11 last) and since a lot of folks are now remote, we decided to go offsite, and off-road, and holed up in Snowshoe, WV.

Now, you might think that a well-known ski resort like Snowshoe would have a lot going for it, and you'd be right, as long as you were thinking of things like nice slopes and good powder and relatively efficient lifts. If you were thinking of food, though, you would be sorely, sadly, and, alas, hungrily mistaken. Essentially, Snowshoe has a 7-11 with a Dominos Pizza built into it, and that's about it for food options. With 26 employees and a bunch of families around, we were going to be sadly limited in our comestibles without some heroics.

Enter Team Iron Chef. Before heading up to the retreat, we collected some volunteers to handle our cooking duties (2 breakfasts, 2 lunches and a dinner, all for 30 people). Our intrepid team of dupesHHHHHheroes consisted of Muness (@muness), Jared (@jdpace) and Michael (@parenteau). This wonderful crew sacrificed their sleep, their energy and their participation in parts of the retreat to keep our rogue band well-stocked with calories. And did they ever.

Breakfast consisted of an onslaught of french toast, mounds of sausage, gallons of scrambled eggs, mountains of potatoes, rivers of coffee. They had to rise at 7 to hit the stoves and slave away all through breakfast to keep the food available for the rest of us to shovel gluttonously down our gullets. Then we would head off to the business portions of the retreat.

Then lunch would arrive; on the first day, Team Iron Chef left the retreat a little early to prepare an Italian feast, essentially an infinite supply of carbohydrates. There was pasta, and bread, and lasagna, and bread, and mushroom calzones, and bread, and a stunning marinara, and bread. And comas. The second day, they left a LOT early, and Jared showed off his skills as a master sushi chef and wowed us with a rainbow of fish flavors. The immortal cry of "Volcano Rollllllllll!" will not soon be forgotten in the hills of West Virginia.

And dinner, oh dinner, Michael and crew crafted an Indian feast. Pots of stews, piles of flavors, bowls of chutney. And bread.

For a company that takes so much pleasure in feeding itself, Team Iron Chef completely and utterly knocked it out of the park. It was an unbelievable accomplishment, that was coupled with enormous personal sacrifice. It was the very embodiment of team focus, and the retreat was made immeasurably better through their efforts. When I am asked in the future for examples of people pulling together as a team, and for a team, I will scream "Volcano Rollll!" and think fondly of Retreat '11.

Feb 02 2011


Band Together Rocks -- You Should Help

For the past two years, we've been working with Band Together, a North Carolina non-profit organization with an incredibly cool mission. Every year, they throw one amazing party at which they raise money for a different North Carolina non-profit. Last year, that party was a concert featuring Michael Franti, The Old Ceremony, One EskimO and others, and they gave StepUP Ministry $358,000. That's big time.

And what a party we had last year. It rained like hell all over The Old Ceremony, which sucks because they are one of my favorite local bands, but it eased up enough for us to take the dance train to funky town as Michael Franti, my favorite artist anywhere, rocked the house.

This year, Band Together has launched a two-year fund drive to benefit Alliance Medical Ministry and Urban Ministries of Wake County. The goals are bigger, the concerts get better every year, and I encourage anyone who likes great music and crazy good ways to help the community to get acquainted with Band Together and check out the show this year. Relevance will be there, in force, in the VIP booth. Will you join us?

Jan 11 2011


And we grow, again.

Continuing a trend of both collecting truly awesome people and blowing right past any reasonable internal forecast of potential growth, we are enormously pleased to announce the following new additions to our team. Between them, they expand our corps of coaches, level us up at systems architecture, add a slew of awesome technical skills, and make us more likable and cuddly, to boot.

And here they are:

Maggie Litton: Maggie is a veteran project manager, scrummistress, and coach. After studying Film, Philosophy, and English at New York University and the University of Kentucky, she explored several career paths before falling in love with software development. Before joining Relevance, she spent the last several years scaling agile development practices for enterprise projects at IBM.

Sam Umbach: Most of all, Sam is passionate about the user! He finds not just the technology solution, but also the humane design to go with it. After several years of embedded systems work in network security and, most recently, video games, he is now addicted to closing the feedback loop, iteratively discovering and building what the user needs. When not at his computer, you'll probably find Sam at one of the many Triangle music venues, enjoying a concert and a beer.

Tim Ewald: Tim Ewald has 18 years of experience building distributed systems. Over the last decade he has worked primarily with web technologies. Tim is a pragmatic architect focused on designing effective solutions to complex problems. Prior to joining Relevance, he was VP of Architecture at SeaChange International, a world-leader in video-on-demand infrastructure for cable and telcos, where he worked on integrating Internet technologies with television infrastructure. Before SeaChange, he worked at Microsoft, where he helped design and build the first version of MSDN2 for delivering technical content to developers. Tim's primary technical interests include advanced languages like Clojure and Ruby and hypermedia service APIs based on REST. Tim holds a Bachelor's in Computer Science from Hampshire College and is a well-known conference speaker.

Craig Andera: Craig graduated with a master's degree from MIT in 1995, and has spent the intervening time working variously in C++, C#, and (most recently) Clojure. Specializing in large-scale web system implementation, Craig has written for MSDN Magazine and has spoken at conferences both nationally and internationally.

Bobby Calderwood: Bobby is half developer, half businessman, and all family-man. He graduated with a degree in Engineering and Economics from Dartmouth College. During his time in college he also played fullback on the football team and served a two-year mission for his church in Arizona. He has spent his whole career splitting the divide between business analyst and developer for small startups and large institutions alike, including being a technology consultant and developer for the FBI and the DoD. He, his wife, and their two small children enjoy playing guitars and singing together, participating in their church congregation, and chasing their dog, Wally.

Welcome to you all, I only hope that we live up to the fantastic expectations you must have of us after we pretended we were Groupon during your interviews.

Nov 16 2010


hooppps - A Mobile dribbble Browser

I wanted to make a dribbble browser for my phone, so I convinced some of my Relevance teammates to help me in this endeavor. The result: hooppps! hooppps is an open-source Rails 3 app hosted on Heroku. Under the covers it uses the swish gem, a Ruby wrapper for the dribbble API.

A screenshot of hooppps (from a desktop web browser): A screenshot of the regular browser layout of hooppps, seen at

(On the screenshot above, the images inside hooppps are shots on dribbble by: David Lanham and Dan Cassaro)

What is dribbble?

"Dribbble is show and tell for designers, developers and other creatives. Share sneak peeks of your work as 'shots' — small screenshots of the designs and applications you’re working on" - Quoted from the dribbble blog.

I love dribbble. People ask me, "What is dribbble?" and I always reply, "It's like Twitter, but for designers." The truth is, although there are similarities, it's very different from Twitter. dribbble is a community of some of the most talented designers and artists in the world! A dribbble user (AKA "player") is asked the question, "What are you working on?" You respond by uploading an image (AKA "shot") no larger than 400px x 300px. This community is invite-only (AKA "draft"), and you can only post a limited number of "shots" per month. "Players" can follow each other, "like" shots, and leave comments. There is a lot of feedback shared amongst players, and keeping in the spirit of the application's basketball theme, players can "rebound" shots. A "rebound" posts a shot that is inspired by another shot. If you like looking at beautiful art and design, you should definitely check out dribbble.

Why make hooppps?

While dribbble is amazing in a desktop browser, they have not yet created a mobile interface. So when dribbble came out with an API, it made me think of how cool it would be to browse dribbble on my phone via a lovingly-crafted mobile interface.

Not just for iPhones

Even though I personally use an iPhone, I didn't want to limit the functionality to just that segment. Others have released native iPhone clients for dribble that you can buy in the App Store. And they are great apps. What I wanted though, was a simple and lightweight browser that anybody could access via their smartphone browser. So, if you are on Android or iOS, you can experience dribbble on your phone in a mobile-friendly format via hooppps.

Start small and iterate

hooppps is not a complete implementation of dribbble, nor does it attempt to cover every feature of the dribbble API. It is a simple experiment meant to improve the dribbble mobile experience. So far, that initial goal has been accomplished. However, this is just the first release. We want to make hooppps better. As the API provides more functionality, we'll add that functionality to hooppps as we see fit.

Release 1

With the first release of hooppps, we hoped to get initial responses and feedback from people.

The first release features include:


  • popular shots
  • shot detail
  • player detail
  • go to player


  • comments on shots
  • pagination
  • share shot on Twitter
  • follow player on Twitter
  • iPhone home screen icon

In addition to the features in hooppps today, the dribbble API also provides access to "shots by everyone" and "debut shots." We did not implement these extra views...yet.

Coming soon!

When I created the first view on hooppps, I thought, "Let's implement the popular shots thread, because it's popular." Well, it turns out that it may be full of popular shots, but it's not the most popular view in dribbble. Since we first mentioned hooppps on Twitter, people have noted that the "everyone" thread is more interesting, and that is what people view the most. So that was our first feature request. We are implementing that, and we will include the "debut" thread as well.

What would you like to see in hooppps?

Desktop browser vs. mobile browser

I originally designed hooppps to just be experienced on a phone. But as I got to thinking about how people would be introduced to hooppps, I realized that a lot of people would end up on hooppps via their laptop or desktop computer. Simply showing them the mobile layout in their desktop browser would result in a subpar introduction to hooppps. But I didn't want to focus on a layout for desktop browsers, because dribbble already has a wonderful desktop interface. Nevertheless, I wanted people to have an awesome first impression of hooppps, which meant that hooppps needed a special layout for the desktop browser: a preview of sorts.

So then I got to thinking, "Why not make hooppps functional in its desktop preview?" I created a position:absolute div over an iPhone image with overflow: hidden. Then, using the jQuery mousewheel plugin, I enabled scrolling of the content inside of that div, simulating the mobile experience. (Thanks to Larry for solving that problem!) In short, hooppps has a fully functional mobile interface visible in a desktop browser!

Collaboration and fun

hooppps has been a really fun project for me. I have learned more about Rails and designing for the mobile experience. It has also been really fun to get other developers here at Relevance involved. (For a list of contributors, see the README.)

From the very beginning, the idea was to open this up for others to contribute or fork to make their own dribbble browser. So, all of the code is public on GitHub. I would love to help other designers get involved (or even get started with their own implementation), so @reply me on Twitter with any questions.


I want to say thanks to everyone here at Relevance for helping me get hooppps out the door. Thank also to Jeremy Weiskotten for the swish gem. Without that, I probably would have not been ramped up so quickly. I also want to say thanks to Dan Cederholm and Rich Thornett for doing such an awesome job with dribbble. And thanks to everyone out there that contributes to open-source software. It is really awesome to have so many tools and a wonderful community to work with!

Nov 09 2010


Thoughts and Lessons from Rails Rumble 2010

I met Nick Plante working at Relevance and discovered that he was one of the people who organized the Rails Rumble. I asked him about it and expressed my interests in participating. It was too late to get in on a team, but he invited me to be a judge.

I was asked to review 20 apps in about 72 hours, judging each by 4 categories: Appearance, Completeness, Innovativeness & Usefulness. I took this all very seriously, and I created a template to give detailed feedback in all areas. (I know I would have loved to get feedback that way if I had entered.) There were many things that raised my brow throughout my review of the suggested apps. Without a doubt, there were some amazing wins. But, there were also several common fails for many of the apps I reviewed.

First and foremost, let me start by recognizing that these apps were all made in just 48 hours by a team of no more than four people. That's a serious feat! All of the apps had some serious sweat poured into them and just participating in the Rumble is a win, as there is much to learn from accepting such tight constraints. And under these constraints, it was clear that most teams fell apart around the same thing -- Minimal Viable Product (MVP).

A very unusable pen with lots of gadgetry and features... and the text that reads: 'When all you needed was a pen'

Minimal Viable Product

A Minimal Viable Product, in this case, would be the most simple and achievable feature set used to demonstrate a solution to users with limited time (i.e., the judges) with a goal of getting feedback on its value. Almost every great virtual product starts out small and introduces enhancements to test the value of new features, while all the while its core remains usable and intact.

The applications that I noticed most positively were those that had a clear understanding of MVP. They served a specific purpose. They were polished in appearance. And the minimal feature set was functionally complete. When certain features were not implemented, these apps clearly indicated that these features were "coming soon"; they were thoughtfully and tastefully integrated in appropriate locations throughout the app. These features were also enhancements not blatant omissions. The teams who got this right created products/tools that demonstrated solutions. They did so with clean interfaces that told the user what to do when and where. And it was clear that the tool was working by the feedback provided to the user post-interaction via validation and messaging. Even upon first laying eyes on these apps, they informed the user as to why they were there and what they should expect from their experience. They had clear calls-to-action that guided me to where I needed to be at each stage of my interaction with the app. Kudos to all who put such thought and work into your app so I didn't have to figure out how to use it!

The applications that I noticed most critically were those that completely missed the MVP boat. These apps may have had great functionality on the inside, but signing up was complicated. Or broken. Or upon landing, there was no clear explanation as to what problem the app was trying to solve. Other apps got the landing right, but then fell apart on the inside due to excess features which resulted in poor organization, poor flow, or general incompleteness. Some apps failed to guide the user through their experience; they lacked clear labeling and messaging. These apps seemed to lack focus and/or balance.

Questions that could be helpful in a Rumble

How do we apply this learning to future Rumble events? Asking the following questions could give you a head start on the competition.

For MVP:

  • What is the problem that I am solving? How can I solve it in the most simple and focused way?
  • Can we solve the overall problem one feature at a time?
  • Are there future (post-Rumble) features that I want to preview to the users? Can I provide those previews without compromising the core functionality of the app, or would these enhancements just be a distraction?
  • Is what I am working on essential to the current release of this product?

For Usability:

  • Have I clearly stated what the user should be doing at every stage — from landing, to signup, to sign in, to using the tool, to logging out?
  • Do I have validations, confirmations, and essential messaging in place?
  • Have I labeled forms and form elements clearly?
  • Are there any broken links?
  • Have I made it easy for users to recover from mistakes they might make when entering data?

Rails Rumble apps I reviewed that "wowed me"

Of the apps that were assigned to me for judging, these entries were the shining stars. (Note: they are not the list of top apps for the Rumble. For that list, you should check out the complete scores and all of the amazing stuff that came out of this 48 hour whirlwind of productivity.)


All in all, it was really great to be a part of the Rumble. I enjoyed looking over all the applications, and I was even more amazed and humbled to get thanks from teams for my thorough reviews and honest feedback. I would do it again in a heartbeat, but I definitely hope to join a team and participate in the thrill of the competition next year. I look forward to Rails Rumble 2011 and hopefully your feedback!

Popular Tags