Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


Rails Rumble 2009: Appearance and UI Winner

The Rails Rumble is an annual programming competition where teams of up to four people will have 48 hours to build an innovative web application in Ruby on Rails. Once the build portion of the competition is over, a two-phase judging process selects the winning entries in several categories. In the first judging phase, a selected panel of experts reviews all qualifying applications to determine the top tier. Once they're finished and the top applications identified, the public judging period begins. The categories of winners include: Grand Prize, Second Prize, Third Prize, Solo, Appearance and User Interface, Originality and Innovation, Usefulness, and Completeness. Thanks to Nick Plante, Darcy Laycock, Erin Shine, and Jeff Rafter who organized this year's event.

Appearance and User Interface Winners

The 2009 Rails Rumble prize for best Appearance and User Interface goes to the Lowdown application, developed by Sean Cribbs, Paul du Coudray, Wes Garrison, and Scotty Moon.

Figure 1: Lowdown, by Sean Cribbs, Paul du Coudray, Wes Garrison, and Scotty Moon.

Sean, can you tell us a bit about Lowdown.

In April 2009, Paul and I started working very intensely with Cucumber, which is a tool written in Ruby for creating feature descriptions and automated acceptance tests that are expressed as business-friendly "user stories". Cucumber encourages you to focus on features that always deliver business value, whether it be increasing revenue, protecting revenue, or managing costs. Our immediate reaction to the process was that it became clearer how to communicate features between each other and our clients, while still having something that directly relates to the code in the application; that is, your feature stories become living functional specifications. The downside was, it was hard initially to get the client to:

  • See the value of writing feature stories
  • Get involved in writing feature stories
  • Understand the cost of implementing a story

Lowdown was created to help with these problems. It provides a hand-holding interface for writing, estimating and prioritizing user stories. We envision Lowdown becoming the "software design watercooler" where the stakeholders -- clients, project managers, designers, developers -- discuss the needs of the software, how they affect business value, and what their costs will be. While the focus is on writing user stories, we feel that prominently displaying the cost estimate of each feature encourages the client to focus on the features that are most important to them and deliver the best value, while sidelining "nice-to-have" or "personal-mission" features of lesser value. People tend to get more serious when money is involved.

What tools did you use to build it?

We used Ruby on Rails, Cucumber, Authlogic (an authentication plugin), OpenID, and a number of other Ruby libraries for the application part. Supporting the user interface were Haml, Sass, Compass, and jQuery. We deployed on Ubuntu 9.04 with Apache, Phusion Passenger and MySQL for the database.

What was the hard part in building Lowdown?

Obviously, the time constraint was a problem, so I think the hardest part was excluding features that we really wanted to see in the application. Our team was also spread across three time zones and had differing weekend obligations, so coordination of work was challenging. Also, I'm personally pretty fanatical about test-driven development, so giving up the comfortable assurances TDD gives you for 48 hours was difficult.

What would you have done different?

Overall, we're very happy with the outcome and wouldn't change much. We could have spent more time planning the application. We definitely could have had better promotional and support material -- especially producing a really smart screencast. I might also have incorporated some TDD for the hyper-critical code, like authentication and signup, where we had some of our more egregious bugs.

What's next with Lowdown? Any changes coming?

We'll be relaunching Lowdown within the next few weeks as a subscription-based SaaS. It'll only cost you -- very modestly -- if you want to create projects; collaborators will be free. We'll likely offer it free to open-source projects soon thereafter.

We've got a huge number of improvements in the queue, including some of the best features that we had to leave out of the application for the Rumble. In our relaunch, we intend to support exporting or downloading projects in zip files (our most-requested feature) drag-and-drop reordering scenarios and steps within a feature, "read-only" projectviews, and huge number of bugfixes. Down the road, we want to add integration with other project management tools like Basecamp andPivotal Tracker and create some awesome developer tools.

A big part of our mission will be advocacy and education for the story-driven process and Lowdown as a tool within that process. We realize that developers are quick to pick up new tools for improving their workflow, but the "suits" are less exposed to new tools in their daily work. We have a lot of ideas for how to tackle this problem, but it will surely involve lots of blog posts, screencasts, and enhancements to Lowdown that help the newbie get started. We think this could be really big for the business of software development. We're big believers in "dogfooding", so we're using Lowdown to plan features for Lowdown!

For More Rails Rumble 2009

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.