www.bankruptcyhq.com

Here's a high-level description of the way we worked on this project:

First step for us was meeting with the customer to very clearly determine the goals of the website: generate leads, provide valuable content for the best SEO, etc. We then took a very close examination of the competitor landscape to see what the other bankruptcy websites out there were doing and what we thought worked/didn't work on those websites. Every time we found something we didn't like, we made sure to not implement those things in the design. In addition to reviewing the competitors, we looked outside of the industry to find websites that we thought were implementing similar functionality and we then tried to pick/choose the functionality we liked there.

After we noted all of this, we designed wireframes for the client to view the rough layout of the site. Putting the free bankruptcy evaluation form very prominently on the website was of great importance, and we also knew that we wanted the entire form to be clicked through without leaving the page -- sort of an AJAX type functionality, though it's not technically AJAX-based (it's javascript).

Once the client approved the wireframes, we worked with one of our excellent designers to come up with a few different versions of the designs. There was quite a bit of back/forth to land on the version that you see today, and there are improvements being made as we speak.

I would say that all of this work was pretty standard for Burn Bright as we've built many other sites. But the Drupal implementation itself was the trickier part, as it was our first Drupal site -- we had implemented mostly Joomla and Mambo sites prior to Bankruptcy Headquarters. From a project management perspective, really digging through the documentation to get my head around the Drupal terminology was a key aspect. Setting up dummy websites for a couple weeks and tinkering with them also helped. My technical lead at Burn Bright can absorb the terminology and functionality quickly, so that made it a little easier on us.

From his perspective, the large community support and good coding standards were key to having a site that could be quickly implemented and grow in the future.

Choosing one module over another depended on the extent of the community support for the module, viewing other sites that had implemented the module successfully to see if we could use it, and doing a dummy install to play with the functionality. Additionally, we did code reviews to make sure every module we implemented followed best practices.

Once we were comfortable with Drupal and it's capabilities, we sliced up our template into functional parts and targeted specific modules, views, and nodes for each area. This got us a rough list of what views we would need to create and what special node types would be needed.

What we found easy in the implementation was ability to use CCK to create custom page types. In conjunction with views, this allowed us to use many pieces of content in different ways. Also, the great form system made it easy to create our own module to track leads. The real power of Drupal is that even the most complicated ideas are possible.

The few things we would have done differently are installing global redirect from the beginning of the sites life. Having duplicate content on the node?XX pages seems to have a negative effect in Google and other search engines. We would highly recommend making this part of your base Drupal installation.

My recommendations for folks starting out with Drupal are to "play and read" first. Do a dummy installation on a directory that you can easily wipe out. Install as many modules as possible and begin playing around to see what you like and what you don't. Also, read this forum as much as possible along with the documentation. Make a list of what you don't like, and then ask the community how to change it. The power of any open source project is sharing knowledge and experience.