blog

Barefoot recently launched a new web site for Taft Stettinius & Hollister LLP, a leading Midwest law firm with five offices and a strong international practice. The site’s redesign is in support of a rebranding effort that got underway last fall and launched this summer. Taft has over 200 attorneys in five offices with activities in over 50 practice areas.

Taft needed a web presence that gave clients and prospects quick & intuitive access to all of their services and capabilities. To make sure the site continued to be a vibrant, up-to-date part of their marketing communications, they also needed a full-featured, easy-to-use content management tool to allow Taft non-technical users to easily manage the site.

The Taft site required an unusually high number of relationships between pieces of information. Attorneys are linked in a many-to-many relationship with practice areas, news stories, press releases, events, campus interviews, publications, and representative matters. Community & professional affiliations, court & bar credentials, law schools, languages and certifications are linked to each attorney as well. Many of these entities are also related to one another: practices are linked to offices, news stories are linked to practices & offices, practices are related to each other, and many more.

Because of the high number of inter-related links, none of the open-source or commercial content management systems we reviewed were flexible enough to do the job. So, we turned to one of our favorite tools, Ruby on Rails. In retrospect, it was the best decision we could have made.

Rails is especially strong in its support for building data-centered web applications, especially those with unique structures of inter-related data. We were able to model the nearly 30 different kinds of data with all of their relationships in a very clean & understandable way.

I think we used nearly every kind of ActiveRecord association that Rails supports. Some of the most challenging were those many-to-many relationships where the join table included extra properties. For example, the link between an attorney and a practice area also needed to store whether the attorney was one of the designated contacts for the practice area. For these, we used has-many-through relationships, like so:

Attorney model:

has_many :attorney_practice_links, :dependent => :destroy
has_many :practices, :through => :attorney_practice_links, :conditions => 'practices.active = 1'

Practice Model:

has_many :attorney_practice_links, :dependent => :destroy
has_many :attorneys, :through => :attorney_practice_links, :conditions => 'attorneys.active = 1'

As you can see, the attorney_practice_links model is the join table between attorneys and practices. This lets you store extra data on the link itself, so you can do things like:

a = Attorney.find(1)
puts a.attorney_practice_links[0].contact?

In building the admin tool, we followed some of the design patterns used by Radiant CMS, an open-source CMS based on Rails. The user manager was especially helpful. The rest of the CMS was customized, however, because of the need to easily link nearly everything to everything else.

We took advantage of Rails’ great support for Ajax-ified forms to build many linking widgets. For example, on the practice area detail page you can link attorneys, news stories, publications and events without leaving the form. This provides a nice view of all of the relationships and easy editing.

One of the best things about using Rails was its “agility” — which for us meant the ability to rapidly respond to changes in scope. (Scope changes in development? Shocking!) Throughout development, we needed to add new kinds of data, and more relationships than we had originally planned. With Rails, we were able to “do it right”, rather than kluge changes into a rigid, inflexible packaged software product. When a new data type came along, we’d change the schema, add the models, declare the relationships, add the unit tests, and the added element became a first-class citizen with the other elements that were originally “in-scope”.

We also extended Rails with many extremely helpful plugins to support other needed features. For full-text site-wide search, we used the Ferret gem, with the acts_as_ferret (aaf) plugin. What an amazing tool, but not without learning curve. Among other things, we successfully setup aaf to search across multiple models, ignoring those records that were not published in the CMS (they are marked as Draft or Inactive in the admin tool).

The client especially loves the ability to print on-the-fly, nicely formatted PDF files of attorney and practice area details. This gives them completely dynamic, always up-to-date resume for all of their attorneys. We used the pdf-writer gem, which has a powerful (but poorly documented) and challenging API to build dynamic PDFs.

For WYSIWYG editing in the admin tool, we used the unfortunately-named FCKEditor. It is a powerful, configurable, Javascript-only in-browser editor that has some nice built-in features for uploading files, cleaning up pasted-in characters from Word, while being quick & easy to use.

We deployed the site on the wildly popular Mongrel web server, using a Mongrel cluster behind Apache. The always faithful MySQL database quietly, quickly, and efficiently managed the data. It’s amazing how well this site works with all the ferrets and mongrels running around, but somehow they get along.

The success of any Rails project often comes down to the outstanding community support for the framework, in the form of updates, plugins, blog posts, and other shared documentation. This project was no different — and we are very grateful to be a part of this thriving community.