You might have noticed that it has been a little quiet around here of late. We haven’t gone anywhere and we certainly haven’t stopped improving Guestlist. On the contrary, we’ve actually rewritten it.

A little while ago Guestlist quietly cut over to a shiny new Rails 3 application. We did this without downtime and without anyone even noticing.

Wait, Guestlist wasn’t already Rails?

Many people probably thought Guestlist was already a Rails application. This is *almost* true. We built the original Guestlist using Merb, a Ruby framework that emphasizes modularity and performance. Because the Ruby web framework community is so fantastic we were able to make use of many Rails components even though we were using a different framework.

Why?

While the two frameworks were originally competing for mindshare, over time Merb became an important influence on Rails. In fact, the projects ended up merging and a number of core Merb committers did a huge amount of the work involved in making Rails 3 a reality. We were incredibly pleased with how well Rails 3 turned out and decided that we should invest the effort in upgrading our app in order to take advantage of all it has to offer.

How we did it

We were able to make the upgrade seamless by leveraging many of the great libraries that the Ruby web community has produced. We had Guestlist running on Rack and Unicorn even before they were part of a stable Merb release. We had been very early adopters of Bundler from back when it was still a Thor script that came packaged with Merb. Over time we replaced many Merb components with Rails-compatible Rack middleware. In early February we started swapping out major parts of the infrastructure, getting our large automated test suite to pass, and repeating.

When it came time for the final release we made our Merb and Rails deployment environments identical. This included the database schema, Nginx and Unicorn configurations along with all of the daemons, watchdogs and other monitoring infrastructure. We already use Unicorn for seamless, no-downtime upgrades so rolling out the Rails rewrite release was no different than a bugfix deploy.

Some stats:

• 242 commits, 903 files changed, 18771 insertions, 32006 deletions.
• 26 gems added, 23 gems removed, 33 gems upgraded, 27 gems unchanged.

It has been a lot of work but we’re very pleased with the results. We are already starting to make use of many Rails 3 goodies and will be announcing some of the great features we are building on them shortly.

Just a quick heads-up that Guestlist will be unavailable for approximately 15 minutes tomorrow morning (April 17, 2011) starting at 06:00 EDT.

We will be upgrading our database server so that we can provide you with faster service.

First we did a redesign of our logo, then we evolved the application design to make it even easier to use, and now finally we release a new website that ties it all together beautifully.

We are still fleshing out some of the content, so if you have a great photo of a Guestlist event or want to be a featured customer, shoot us an email.

Just a quick note that we’ve added support for custom event backgrounds in Guestlist.

We’ve wanted to support custom backgrounds in Guestlist for a while. Twitter, for example, uses them to great effect. Although changing the background is one of the only available customizations in Twitter it really allows users to make pages unique and personal.

We try to choose new features that add a lot of value for a minimal amount of interface change. For custom backgrounds we’ve gently integrated uploads into the existing background swatch picker that is found in the event settings dialog. The uploader blends in with the background thumbnails and new images upload asynchronously with progress feedback.

Users who run frequent events will notice that any background uploaded is available for use in any of their events without having to re-upload. We will be bringing these improvements to the logo upload facility shortly.

Finally—although it probably goes without saying for our developer readers—there are a huge number of details to worry about for providing a smooth file upload experience. We’ve learned a lot from building this feature so a more detailed technical post is forthcoming.

We are in the process of creating a brand new website for Guestlist and figured it may be helpful to share some of our design process. Since our launch more than a year ago much has changed in how we see Guestlist and our place in the event registration market. The new website will communicate what we are about more clearly and also allow for some new feature additions.

The Guestlist design process, and really my design process since I am the only one doing design, is pretty simple. I don’t see design as a science. My design is largely driven by gut instinct. What this means in practical terms is that in order to get to a great design you need to go through a whole lot of mediocre and bad designs.

I am not suggesting making ten different versions and picking the best—that would be a colossal waste of time. Rather, a single design is reworked and refined until you find something that makes you think Yes!. A lot of work may be thrown away or abandoned along the way to perfection. Or, you might stumble upon something awesome on your first try.

The new homepage took two weeks to get to a final design, but only 4.5 hours of actual work. Why the discrepancy? If you stare at the same design for extended periods of time things will start to blend together. Sleeping on a design for a day or two will allow for a fresh look.

As the design for the new website comes along we will share some of the design thinking behind what we are doing.