DrupalCon or Bust!

Nedjo Rogers

What do you do when you need to merge two websites into one, do a complete redesign, and launch the new site within three weeks? And when most of your team is fully engaged in other pressing work?

In a word, you prioritize.

Relaunching has been a great refresher of what goes into a successful site build when time is of the essence.

Ticking clock

Drupal Watchdog is produced by a subsidiary company of Tag1 Consulting and as the Tag1 team we're responsible for A week into May, we decided it was time to get a planned redesign of the site done in time for DrupalCon Austin: June 2nd.

Luckily, we'd done our homework and already had some great mockups from Codename Design.

For historical reasons, was divided into two different Drupal installs: the main site and a commerce subsite. The new designs, though, had commerce features integrated on every page of the site. This meant there was no viable option except to merge the commerce site into the main one.

Gulp, no problem!

As usual in a redesign, we'd generated an ambitious wish list of new functionality: streamlined editing interfaces, a new blog section, lots of back end improvements.

But to Drupal Watchdog editor and Tag1 partner Jeremy Andrews, there was one priority that surpassed all the others: to have a new site by DrupalCon. It was an organizational priority, but also a personal one. If there was a subtext to Jeremy's messaging, it was along the lines of: "I can't face another DrupalCon where I have to point people to our pathetic old website!"

'Nuff said.

Back to Basics

So quickly the question became not "How do we get all this done in three weeks?" but "What's the minimal subset of the site we absolutely need for launch?"

In more than ten years of doing Drupal, I've been involved in more redesigns and upgrades than I care to remember. If there's one common current, it's the tendency to take for granted what already exists on the pre-upgrade site.

The conversation typically goes something like this:

Client: "So what we want to add to the site is... [insert long list of flashy new features]."

Website builder: "Sure. But, before we can even start on that long list, we first have to rebuild what you already have."

Client: Blank stare of incomprehension.

Thankfully, in this case, we were both the website builders and the client.

Given our timeline, we couldn't hope even to fully rebuild what was on the old sites. We needed to figure out in a hurry: just what is essential.

There's nothing like a bit of pressure to help "essential" come into sharp focus.

Drupal Watchdog is, at its essence, a print publication that has issues, each of which has a set of articles written by different contributors. Bingo, that became our "minimum viable product": issues, articles, and contributors. We'd do our best to get that subset of the site fully developed. Was the rest, including the new blogging section, important? Of course. Essential? No. It could, and would, wait.

Beyond the basics, we would add new features only if they were required to make the design work for the few pages we'd have at launch. We whittled this list down eventually to a single new feature: digital ads.

The store subsite sold two types of products: subscriptions and print ads. Were subscriptions essential? Absolutely. After all, what was the point of profiling Drupal Watchdog at DrupalCon if no one could even buy a subscription?

Print ads? They seemed pretty fundamental to an ad-based print publication. But, in point of fact, we wouldn't be selling ads for the upcoming issue until a week or two after DrupalCon. So--cut! Yes, even selling ads could wait.

Whew. Now down to work.

DrupalCon or Bust!

We put together a small development team from what we could pull from other projects: me as tech lead, me and Károly "ChX" Négyesi as developers, Mark Carver as themer, with backup from Jeremy, critical infrastructure support from Jeff Sheltren, and project management from the intrepid Peta Hoyes. Nice!

Tag1's staff roster includes a veritable who's who of core Drupal development. For the high end performance work we specialize in, that's just the talent you want. For quick building out of site configuration? Not so much. So we called in Rosemary Mann, my spouse and partner at our home-based nonprofit-focused Drupal shop, Chocolate Lily.

If you know that ChX has been a leading force in bringing Migrate into Drupal 8 core, you might assume he'd be using Migrate to merge the commerce site into the main one.

Guess again. He decided it was quicker and easier to dive right into the database and handle the site merging with custom code.

Clarification: it was quicker and easier for him. For the rest of us mere mortals, Migrate is a handy crutch indeed.

By week three, most of the Tag1 team was packing for Austin. That's about when we realized we hadn't even requested comps for pages where we would profile Watchdog contributors. Oh, and our menu included items that would lead site visitors out of the tiny box we'd built for them--the few pages that would be live at launch.

Time to panic?

Nope. Time to remember our mantra: DrupalCon or bust! User profiles not yet designed? No problem--remove all links to them. Main navigation menu confusing? Easy--disable it.

With some last-minute polishing by the amazing Mark "Unicorn" Carver, the Tag1 team members in Austin launched the site from their hotel rooms, with, heck, hours to spare before the conference opened.

Of course, this approach to getting to launch left a lot of followup work to do. Since DrupalCon, we've been building out the rest of the site. Case in point: this blog page. As for ad sales, we're rolling them out this week, in time for the call for the next issue of Drupal Watchdog. Launching on time didn't mean sacrificing functionality. It meant staging it.


Looking back on this brief site redesign reminds me of some of the key factors that go into happy site building. Two that come first to mind are flexibility and focus. By being flexible enough to focus on the essentials, we could quickly build a beautiful new site that covered the core requirements and left plenty of room for adding more as needed.

This is a site build I'm already mentioning to clients when we discuss upgrade plans, particularly when it comes to the question of getting to launch. "Well, when we were building our own site, what we did was…prioritize."