Durango, Colorado is in a state of change – and in the midst of a State that is changing rapidly. I’m VP of Design & Development at Ballantine Communications Inc. which publishes three community newspapers, and the majority of telephone directories in the 4 Corners area. Most prominent of the newspapers is The Durango Herald. It’s a perfect example of what a small-town community newspaper should be. It keeps people informed on everything from “Rodent’s nest sparks car fire on Hwy. 160” to national stories like ‘Catastrophe on the Animas‘. The Herald website is about to undergo a major redesign, but I will save that for another case study.
Shifting Audience Needs: Editorial
The Herald’s audience is an older demographic not necessarily interested in reading a column about craft beer or the latest marijuana strain of the week. Still, there are real cultural shifts happening in the community.
Ballantine saw a need for a new publication that could speak to the growing interests of the millennial audience, attract new advertisers, and provide a place to cover topics that didn’t quite fit in a traditional community newspaper. We needed a place where readers could find information and events calendars covering the arts and nightlife and social happenings in the Durango area. Thus DGO was born.
The Editorial team met for weeks developing a content plan to support the new product. A very talented print designer, David Holub, was named Editor of the publication.
Problem Definition: Development
The technical challenges were a little different. Changes were happening inside Ballantine, as well.
The task of new digital product development falls to my group. We are a Ruby on Rails shop. The newspapers are on a platform formerly know as Saxotech, now called NewsCycle. We developed new and improved digital products on Ruby on Rails, while the newspapers had their own editorial developer chugging away on NewsCycle.
Then he resigned.
The original plan was to develop the new DGO site in NewsCycle. My dev team would assist, but the heavy lifting would be done by the newsroom. Losing our newsroom developer meant that my group was not only picking up the new DGO site, but we now had to support the News websites too.
So, it was off to Florida for my developers for training at NewsCycle headquarters in Tampa. Cha-ching!
None of us were happy about having to develop a new site on the NewsCycle platform. Compared to Rails it is not a very elegant development platform. From a management perspective, I’m not a fan because it requires third parties for support and feature development. If there is a problem you put in a support ticket and hope for the best. I like the control we have in Rails to be master of our domain.
I will say that NewsCycle has a pretty good track record for responding to feature requests and support tickets. I still prefer having the tools at my team’s disposal.
One thing NewsCycle does really well is put out newspapers. Our newsroom has been using it since 2010. The expense of changing the entire CMS—and retraining the newsroom—was not a realistic option.
And then we had an idea!
What if we could keep the newsroom on the tools they know, and still develop our new application in Ruby? We looked at the NewsCycle API, but I was surprised to find out they actually charge for this service. Really? You’re going to charge me for access to my own content? I think not. So we went at the problem a different way.
We decided to leapfrog the situation and build our own API that sits on our side of the fence. We needed to make some changes to the editorial tools so, when an editor hits the publish button, we can grab the content and send it on its way to our database. Once there, we can do what we want with it.
Here’s what that looks like.
It was time to call in some big guns.
Our dev team is awesome, but they were new to NewsCycle. We were going to need some experienced help. On NewsCycle’s recommendation I contacted a firm called Tamberra. One of their principals is an amazing developer, Stacey Jenkins. The great thing about Stacey, and Tamberra, is that while they are extremely experienced with NewsCycle, it isn’t the only tool in their toolbox. I like that. A lot. It tells me they are good at lateral thinking. Approaching problems from all directions until a solution is found.
Stacey’s role was to develop the ‘Post Save Script’. Meaning, when the editor hits the publish button the data from the article is converted into a JSON feed that we could import into our Ruby application. I knew we had found the right developer when I got this meme in a Skype message the day she got everything to work.
Did I mention the deadline?
As much as I like to say we follow Agile development practices, most of our deadlines are not a product of constant iteration. They are given to us. In this case we had 10 weeks to develop a new publishing system, go through the design process, and build the website. Meanwhile our peers in Editorial had to design and create content for the weekly tabloid that would be the print component of the project.
What could possibly go wrong…?
Content & Design
As I mentioned, we were fortunate to have an excellent print designer and editor. I managed the digital product development, but I was also the lead web designer for the project. It was my job to interpret the print design, and the character of the content into a website that is an extension of the brand. Too often I see print publications whose digital counterparts feel like afterthoughts. Many traditional print organizations work under the premise that the print product is the center of their brand. Websites and native apps are an extension of print. I evangelize that the content is the core of the brand. All publications, print or digital, are extensions of the content. Getting print folks to embrace this is not always easy, but eventually they come around. Especially when they start to see digital metrics.
Fortunately, I had a great design foundation to work with, and really cool content.
Next step: Information Architecture
This part is always interesting. In larger organizations you have folks that specialize in content strategy and information architecture. In our small company yours truly played these roles. The challenge was working with print editors and writers who had no experience building a web site from scratch. Part of my job is to get the editorial team to think about a site structure that will house the content they will create over time, and make it easy for users – and Google – to find.
It’s harder than you think, but you can’t really blame the print team. Every week they start with a mostly blank canvas. Within that canvas they can mold and shape the content into whatever works. Getting them to think about sections and templated layouts is tough.
With tight deadlines and technical challenges, the project management process quickly takes center stage. As the content started to come together, and we had a site map laid out, it was time to start breaking the project down into tasks. We use Trello for task management. I have worked at larger organizations that use productivity tools like Jira, but for a shop our size Trello provides a clear visual interface that makes it easy to move tasks through the development process. It works well for us.
The dev team then evaluates each task and estimates their complexity. Once complete, adding up the estimates give us an idea of how long the project will take to complete.
Surprise! On paper, the project was going to take longer to complete than the deadline allowed. The deadline could not move because the debut of the tabloid was already planned, circulation points in place, and street racks were being deployed all over town. Our CEO would have been ok with the website launching shortly after the print product, and I appreciated that release on the pressure valve, but I was determined to make sure ‘Launch Day’ meant launch of the entire brand, not just part of it.
Meanwhile, the Editor was doing a fine job designing the print prototype. He supplied me with an EPS file that had the color palette and all basic design elements built in.
Color palette: Check.
As a web designer, this is the cool stuff. It’s challenging, but also a whole lot of fun. The way I look at it, the designer acts like a filter. The work so far had been focused on gathering and disseminating information, creating schedules and looking at a lot of data. The designer’s job is to take all of that and translate it into something awesome. It has to fulfill all the requirements, be visually compelling, easy to use, and has a touch of craft. You know, a little sumpin’ sumpin’ that brings delight to the reader.
I do all of the things most designers do. I find inspiration in competitor sites, sites that have similar functionality or images and whatever strikes me. My way is to sketch before jumping on the computer. I work in very lose thumbnails and then get more detailed as the ideas take shape.
Wireframes, Comps and Prototypes… oh my!
For years I used the tried and true method of starting the design process with wireframes. I would get approval from all the stakeholders and we would move on to polished Photoshop comps. Once the comps were approved prototypes were built. After the prototypes were approved… (you get the point) Finally we start to write front-end production code.
With a 10 week deadline I knew that process was going to take too long. We would get bogged down in approvals and the project would be late before it started.
Working in parallel
We had to take on the risk of dual-tracking this project. The Ruby developers would continue to work on the integration with NewsCycle, while the design team plunged right it into building prototypes.
I had worked on many projects in the LIFE section, the entertainment portion of USA TODAY, and designed many online entertainment packages. I had a good grasp on the visual tone the website needed to convey. It had to be appealing to a younger audience interested in nightlife and the quirkiness that is Durango. (I say that with all the love in my heart) And it needed to act as an event calendar for the community. THE place to find out what was happening.
Each prototype consisted of a homepage and an article page. Once the design approach was approved, we could fill in the gaps.
The first concept was minimalist.
Concept 2 was more magazine-like, and used the events calendar to anchor the design
We had a meeting with all the stakeholders to unveil the prototypes. Well, I did cheat a little and shared with the designer of the print product. After all, this design is a variation on his theme.
Any presentation where a client or customer has difficulty choosing between design concepts, I consider a success. After more than an hour of discussion it was decided to go with the magazine approach. The term I kept hearing was it felt more ‘Legit’.
We spent the next ten days (including some nights and weekends!) putting the prototypes together. This leap knocked at least three weeks off the schedule. The deadline was beginning to feel reachable.
Build like crazy
I’ll spare you the gory build details. Every day was filled with successes and failures. Eventually, we got more successes than failures. The dev team, with the help of Stacey from Tamberra, did an outstanding job connecting disparate and estranged platforms, building and styling the front-end, and working with the Editorial team to prep content for launch.
Launch: The Viral Approach
If you have been developing digital products for any length of time, the dreaded “bad deploy” has happened to you. Deploys go bad for a number of reasons, most of which trace back to the development and staging servers not matching the production server.
The big day comes. You hold your breath watching hundreds of files tick by on their way to the outside world. And WHAM! Everything crashes. You’re down for three hours. Your boss is pissed.
It happened to me on a project less than a year ago. I vowed it would never happen again. We decided to take the viral approach to launching this one. You really should read the article if you haven’t already, but the idea behind this approach involves throwing a temporary splash page up on the final domain, in our case dgomag.com. It can be used for social marketing while the site is being built. You can see our splash page here.
But here is the really cool part. While the splash page is up, you can be working the production environment all you want! Several days before launch, we started publishing content to the production environment. You get to test the system with live content, behind the scenes, without anyone being the wiser. Very simple. Very cool. We found a handful of bugs, but nothing catastrophic. We made a special Trello board to track these issues and fix them. When launch night came steaming around the bend, we were confident the system worked. There would be no nasty surprises. No staying up until three in morning working out all the bugs.
Ours was what all product launches should be. A celebration of the hard work the journalists, project managers, marketers, circulation, sales people, ad ops folks, designers, and developers put into the project.
We wanted it to be special so we launched the website from a staff member’s home rather than stay at the office until 9:00 PM.
I’ll probably get my wrist slapped by accounting, but I expensed pizza and beer for the occasion (ssshhhhhhhhh…). The launch team came to the house and did a final run through of the site. We found a couple of issues and fixed them on the spot. Then we were ready. It was time to move the domain. Doing this is actually easy and only takes a couple of seconds, but I wanted the launch to be a bit more climatic. So we did a check in, NASA style. I don’t know what kind of silly thumb dance I was doing in this video. I think I was just happy… with a touch of giddy nerves.
Launches like this happen when you have a great team. And I don’t mean just the dev team. This took cooperation from across the company, and hard work in many disciplines. We’re a bit like “The Little Engine That Could”. We’re small, but we get shit done.
So… Ask me about my DGO.