Incremental Redesign with Rails

|   Jul 9, 2013

When the engineering team was planning the new version of Socialcast we knew that we were going to be overhauling virtually every page in the application. From a customer and marketing perspective we wanted to introduce all the changes together, but as an engineering team we were wary about introducing so much change in one big release. We wanted to find a way that we could incrementally release the changes as we built them without affecting our customer experience. If we could selectively turn the new design on and off, this would allow us to give early access to our customers so they could provide feedback on the design while using it with their own data.

We could have accomplished this with conditional checks:

<%- if current_user.redesign_enabled? %>
<%# new code %>
<%- else %>
<%# old code %>
<%- end %>

However, when you are modifying lots of files, particularly views, this has some problems:

  • Old and new code are intermingled in the same file, which makes some tasks like search and replace problematic.
  • Changing the indentation on all the old code is painful for code review and merge conflicts.

We came up with a trick to avoid this that I felt was worth sharing. Using prepend_view_path conditionally for some requests allows you to have a separate directory for the views in your redesign.

To implement this selectively call prepend_view_path in your Controller.

class ApplicationController < ActionController::Base
before_filter :add_view_path_for_redesign
 
private
 
def add_view_path_for_redesign
if current_user.redesign_enabled?
prepend_view_path Rails.root.join('app/views/redesign')
end
end
end

Then in your app/views/redesign directory add files that override the original views.

# original
app/views/users/edit.html.erb
app/views/users/show.html.erb
 
# redesign
app/views/redesign/users/edit.html.erb
app/views/redesign/users/show.html.erb

The new views will be used only when the redesign is enabled. Also, the original views will be used if the redesign views are not present so you can add them incrementally and the rest of the site will continue to work using the old views.

Building our redesign incrementally helped us to launch the new version of Socialcast with confidence because we were already running it production and many of our customers had already been using it with real data and giving us feedback. I would highly recommend trying this technique next time you are making a significant change in your application.

Comments

  • Excellent technique!! Thanks for sharing!

    Commented on July 11, 2013 at 1:14 pm
  • Thanks Lars,

    An interesting approach.

    I generally use a sub domain approach to achieve this

    constraints :subdomain => “redesign” do
    end

    Commented on July 11, 2013 at 5:02 pm
  • Great idea, thanks for sharing! Do you know if this technique also applies to layout files?

    Commented on July 11, 2013 at 6:27 pm
  • We do something really similar to this, but more from a version control by abstraction perspective, so in addition to doing this, we support additional functionality by also adding models, helpers and controller to a ‘brand customized’ set of autoloaded paths. That allows for an overlay (as opposed to an overlain Engine). Our particular choice is to run it as an initializer rather than a wrapper, which just feels like a better fit since we are dealing with really old and slowly being refactored codebase, but I’d be interested in if (and how) you manage changes to controllers/models/helpers with before filters.

    Commented on July 12, 2013 at 8:11 am
  • That’s a great idea, simple and effective. Thanks for the tip!

    Commented on July 12, 2013 at 11:10 am
  • @ Zubin yes – it does work for layout files.

    Commented on July 15, 2013 at 11:50 am
  • Nice solution.. Thanks for sharing..

    Commented on July 17, 2013 at 4:09 am
  • It`s sound nice? ‘cos i really like this:
    class User
    def redesign_enabled?
    Rails.env.development?
    end
    end

    Commented on July 30, 2013 at 12:33 pm

Leave a comment

Your email address will not be published. Required fields are marked *

Connect with Facebook

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Sign up to receive email communications regarding events, webinars, and product news.

What is Socialcast?

Socialcast by VMware (NYSE: VMW) is a social network for business uniting people, information, and applications with its real-time enterprise activity stream engine. Behind the firewall or in the cloud, Socialcast enables instant collaboration in a secure environment. Socialcast is headquartered in San Francisco, California. www.socialcast.com