Vancouver Magazine Redesign

The website needed to relaunch no later than October 30th, 2008. Given the tight two month timeline our team needed to hit the ground running. To help us meet this deadline we teamed with ImageX Media, a local Drupal shop, to assist with the initial CMS setup, module selection and some custom development. Also due to the timeline we decided to build on Drupal 5 as a number of key modules had yet to be completely ported over to D6. This was a particularly tough decision as we had just finished building a smaller site using Drupal 6 and have come to appreciate the improvements to workflow that version 6 contains. If we were to start this project now we would unquestionably built off of Drupal 6 as all the critical modules we needed (CCK, Views, Location and Gmap) are stable (and much improved!).

Our Process

Because of the short development schedule (less than 2 months) and the mass quantities of content that needed to be entered manually into the system, we began working in parallel once the new information architecture (sitemap, wireframes) and key user flows (shopper, foodie, clubber) had been approved. Sample user flow: The Foodie

Rapid Prototyping

When we took a look at the content the first thing that was clear to us was that we needed to normalize, categorize and organize all of the content in a way that made the restaurant, retailer and venue information more readily available. Also, being a resource for local knowledge in Vancouver and the Lower Mainland of BC, we knew we needed to have a neighborhood taxonomy vocab added to each piece of content so we can group these different content types together in an intelligent way.

One of our main concerns with the short timeline was the quantity of content that needed to be entered into the CMS. Prototyping of the CMS configuration began in parallel with information architecture where we worked on the data structure and key user flows (shopper, foodie, clubber). One of the best things about working with tools such as CCK and Views is the speed that you can create a working prototype. Prototyping a complex publishing system during the information architecture process simply would not have been possible for us if it was not for these systems.

As our design team created templates for approval (about 10 screens in total) we were building out the Drupal site with a minimally styled, fast loading theme to aid in data entry. This site would eventually become the live site, and it allowed the data entry to happen while we were working on the final theme because we could force the data entry theme on the content creator’s user account.

We wanted the content entered as early as possible in the development cycle, partly because we wanted to work with real data rather than greeking and partly because when I would show a client a bulleted list of all of the fields that would be in the Article content type their eyes would glaze over and I wouldn’t get any sort of approval. By entering actual content early on we were able to collect feedback from the data entry team and the client on the CCK fields as well as a rough version of the node, and from there could reorganize, add or remove CCK fields.

We didn’t go with an automated scraping type application for the content because they were mostly multi-page articles and we would have to mess with trying to get that all organized programmatically. Cutting and pasting from the old live site to the new ended up being a good way to go because we could clean things up and at least a few eyeballs saw the content before it went live.

CCK/Views saved us here again, as naturally things would come up and we would need to add new fields or modify existing ones during development. Also, we had so many eyes on the content as it was being entered and tweaked and if there was a big omission in the data entry we could easily build views like “all the articles that don’t have article images” or something similar and have a few interns work on fixing or adding content to the nodes.

The data entry theme had a summary of the latest content being entered as the homepage so there was no debate about how the data entry was progressing and if we noticed articles or other content types being entered wrong they could be noted and processes modified right away.

Content Types, Specs for custom modules

We installed the modules we thought we would need (major ones listed below) and started with the Article content type so the data entry could start, then rolled out the other content types as we specced and designed them so the data entry could start on those sections as well. There was talk in the beginning about combining the restaurant, retailer (shopping search) and venues (bar and club search) content types together into one but we got spooked at one point that the content entry form would become too unwieldy once all the various edge cases were added in. In retrospect it was a good decisions because those different pieces of content would never be listed together, or searched for. Though they share a common search interface they are different user flows. At this point they are fairly similar, but in the future restaurants will have menus (food menus), retailers could have specials and venues could have other info listed that wouldn’t apply. Each of these content types can grow into their own now without worrying about creating some sort of form-zilla on the admin side (or page-zilla.tpl.php file).

Interface Design

Our UI designer was working on layouts while we were working on the wireframe version of the site. We work beside each other and it worked well as he could show me what he had mocked up and I could show him the modules, content and content types as they were coming together. It helped the design because he could browse through the wireframe site and see how much content was there, how big the decks were, images, etc. Both sides had to iterate, the comps changed to support some of more default ways that Drupal would print content out, and we worked on theming out the data and interface to fix some of the UI issues we were dealing with. I can’t say that we didn’t have to re-enter or modify anything, we made a lot of changes on things that we thought had been locked down and approved. Even with that feedback and iteration I believe that the hours we put in were less than if we had been handed user flows and UI and hadn’t had any input along the way. Plus having genius programmers involved earlier in the process makes a better product in the end.

Examples of the wireframes that were presented and approved by the client:

Examples of the finished comps

Hosting Environment

The live site is running on a fully managed SAMP (Solaris, Apache, MySQL, PHP) server run by Bell. This box is hosting all of the TransContinental websites. We are using ImageMagik as the graphics library, and although we did our development using SVN, we have no source control on the live server.

Front End Development

Front end development happened in a typical fashion, and it didn’t really start until all the archival content had been entered. Because we had actual approved content and images in the database, the client could see their content realized in the new design as we brought page and node templates online.

I would put together a wish list of the templates that we needed for theming and our UI designer would created the templates, get them approved by the client and we could start building out those content types. Once all the templates were complete I had a PSD which I could refer to for style guidelines for the various blocks and views on the site.

An example of the header comp, approved early on so I could get started.

Some design decisions we made:

• Primary Menu. It isn’t part of the Drupal menu system. We did this because the top 6 menu items will never change, and if it does we would be involved to create the new graphic sprites for the menu item. The primary drop down menu items are editable HTML content blocks which are called from a special content area. This way they can be edited easily if new items need to be added using HTML or l().
• Secondary Menu. Managed as a traditional Drupal menu, rendered with the help of Nice Menus and a jQuery hack so the primary menu drop down appears on top of it correctly.
• EqualCols. We are using a jQuery script to make the columns on the multiple column layouts all the same length. This is to deal with the challenge in pure CSS layouts where you can’t set columns to the same height. It’s a bit hacky, but it loads last and saves me from having to create a pile of different background images (one col, 2 col, 3 col search, 3 col regular). It runs by looking for any div with class=”equal”, iterates through and sets the heights the same. In situations where the height changes, like on the restaurant search page where you can open and close the fieldsets on the node filter, you just run it again when it’s needed.
• I love Block Class as a front end developer. It’s simple and cuts down on the mass amount of css.
• Hidden check boxes. One fun thing we did was to hide the checkboxes and make new fake ones using CSS sprites and jQuery. This way they could be a bit more subdued than the standard ones, and are styled a bit more consistantly between browsers. The trick is to use display:hidden with them so the browser still treats them like they exist, the annoying part is that each browser pads and sizes them differently, so there is a bit of work there.

Custom Modules

Frontpage Feature Queue

We developed a custom module for the hero article on the home page. On the admin side the content creator is presented with a list of 10 or so node reference fields with a date input field beside them. The content creator looks up the title of the article using a node reference field and sets a date for the article above it to be bumped off the list. That way when the date comes the displayed article is replaced by a new article. It operates outside of the Drupal publish/promote/sticky system so we could use those for other things. The client will publish all the articles in a month on the same day, but wanted to be able to feature a new hero article every few days during that month (edit: We just found out about Node Queue last week).
 
 
 
 
 

List Builder

Probably the most custom work of any feature on the site, the popup lists are outside of drupal’s node system, but can lookup and autofill from nodes if needed. On the admin side, the workflow for the content creator is to create a new list by giving it a name, and then add items to that list. A list item consists of an image, a title and a description, but there is also a node reference lookup if they are creating lists from content that already exists on the site (eg. top 10 mexican restaurants) to autofill these fields. Once the title, image and descriptions have been populated, any of the fields can be edited as needed before saving and moving on to the next item.

To add a list player to an article, there is a ‘list lookup block’ which appears when you are logged in as a content creator in the right column. From there you can check the list ID of the list you want to link to, and add the link to the article using a syntax like [123:Best Mexican Restaurants]. We are using a custom filter to convert that syntax to the thickbox code we need to launch the player as an inpage popup.

Restaurant/Retailer/Venue Search

The search is a combination of Views, Fast Search and custom AJAX overrides. We use Location and Gmaps to present an embedded google maps view of the results. We based some of the google maps API work, specifically talking back and forth between the list and the map, on the tutorials by Mike Williams (http://econym.org.uk/gmap/).

Calpop

Changes the default action on the calendar so clicking on an item in the calendar launches the node into a thickbox window rather than sending you to the node view.