Incremental Redesign with Rails

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:

<%-ifcurrent_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.

classApplicationController<ActionController::Base

before_filter:add_view_path_for_redesign

private

defadd_view_path_for_redesign

ifcurrent_user.redesign_enabled?

prepend_view_pathRails.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.

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

Paul McKibbin says:

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.

Authors

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