Home » About Drupal » Case studies » Designer case studies

Aten Design Group: On Becoming a Drupal Development Shop

Last modified: April 17, 2008 - 22:37

Aten Design Group, Inc. is a web design company based in Denver, Colorado. Since it opened for business in early 2000, Aten has served a wide range of clients including museums, non-profits, resorts, manufacturers, financial consultants, civil engineers, and artists.

Aten is a multi-disciplined agency experienced in creating sites with web standards (XHTML+CSS), developing Flash content (static and dynamic), building and integrating e-commerce systems, and implementing content management applications (primarily using Drupal).

Two years ago we began working with Drupal at Aten. Before then, our content management implementations were dominated by our own PHP/MySQL-based CMS, which itself was the result of several years of development, revision, and rewriting. Since we began working with Drupal two years ago, we haven't launched a single project using our own CMS. And we never will again.

We are primarily a design company. The user experience is at the center of every project we take on, every design concept we create. The goals vary widely from client to client. When clients look to us to provide content management, we need a product that is flexible and efficient – one that allows us put the user experience first, without having to reinvent a solution for each project.

Our own CMS delivered in these two areas, but added a problematic maintenance burden to the development cycle. As I mentioned before, we are primarily a design company. Developing and maintaining a content management solution is not our core business.

Two years ago, when a new client asked us to review several open-source CMS products and provide a recommendation, we did some research and suggested Drupal. Since then, more than a dozen Drupal implementations have followed.

Here's why:

  • Drupal provides a presentation layer, via a robust theme engine, for customizing the HTML output of virtually any piece of the application. We can put the user experience first.
  • There is an incredibly active Drupal community. The product's maintenance is distributed across a passionate group of 1000+ developers.
  • The Drupal community cares about standards. The generated HTML code is a bit bloated at times, as happens with any generalized solution, but by-and-large its HTML output conforms to modern web standards.
  • There are literally thousands of contributed modules providing a vast range of additional functionality.
  • Often, the functional requirements for a project can be met without writing a single line of code. Specifically, the out-of-the-box flexibility provided by the Views and CCK modules is amazing.
  • Drupal offers a robust application development framework for add-on functionality.
  • Drupal is built on PHP with current support for MySQL and PostgreSQL databases, with pluggable database support on the product road-map for version 7.

We had some concerns going in.

Our biggest concern was that we might have to sacrifice our design process and our markup. Using our own CMS, we had complete control over all aspects of presentation. We could output precisely the markup we wanted, maintaining perfect consistency with the creative concept (for example, http://thehistorictriangle.net, or one of Ken Woodworth's personal projects, http://www.parkviewbaptist.net). We could publish content as XML to drive interfaces built in Flash (http://www.mariner.org/exploration/index.php?page=voyages).

In Drupal, controlling every piece of markup is at times more difficult than our previous experience with our own product. That said, there are theme hooks for virtually every aspect of Drupal's rendering engine. When we want markup that is different than the default, the question usually ends up being one of whether it is really worth changing, not whether we are able to make the change.

To follow that tangent for a moment, this has actually been a fairly common point of discussion between myself and our art director, Ken Woodworth. At times, Drupal outputs several nested divs (for example, CCK field output) when one would suffice for the specific application. Should we create a theme function for each of these cases to simplify the markup as we want it? Or should we just handle the extra markup visually in our CSS? It is an ongoing conversation with no fits-all solution; with Drupal, though, we at least have the option. We can use the generated markup as-is in cases where we are willing to live with a few extra divs, or write theme functions to simplify generated HTML.

The fact is, we haven't sacrificed our design process at all since moving to Drupal. Over the last two years we've deployed a wide variety of Drupal-powered websites, including:

Projects using Drupal have included simple, "brochure-ware" websites; websites that integrate with enterprise CRM systems and deliver real-time data for hundreds of projects worldwide; informational websites; and online communities featuring user-generated content. The applications have varied widely, and the final products have delivered on goals every time (for more on that, see our portfolio).

We're hooked.

» Login or register to post comments
 
 

Drupal is a registered trademark of Dries Buytaert.