It's funny, when I first started at CQ, I thought that the most difficult part of the job would be doing quality work on a small staff. Unlike the New York Times or the Washington Post, we can't throw fourteen people at a project, so it often takes longer than I'd like--especially factoring in CQ's well-deserved reputation for fact-checking and accuracy. It's true, lack of resources has been a sticking point at times, but what has surprised me is that it's not the hard part.
For example, today we're launching our new district results maps. Previously, maps like these had been done in a very clumsy manner--literally, each state was a frame on the Flash timeline, with manually-placed zoom areas linked to another frame for districts that are very small, like downtown New York City and parts of urban California. This was not only a poor design, but it was practically unmaintainable. This time, with the help of our graphics team, we started from a complete, Flash-native vector map. Then I designed a UI framework that would not only allow Google Maps-style dragging, but also programmatically auto-zooms to states and to small or oddly-shaped districts. The result is easier to navigate, looks better, and will be far more adaptable for representing other datasets--it was a piece of cake to take the original House results map and change it to display presidential results. I'm very proud of how it turned out, and feedback has been stellar.
Because we are a small shop, bottlenecks abound, and this map took two weeks from conception to finish. We still have work to do: searching and deep-linking are not yet enabled, and I want to refactor some of it out into a separate library. But still, this is the easy part: we were able to work completely within a known framework of Flash, Ruby, and internal XML. The hard part comes when we decide to place it on the actual website. CQ's publishing system, like many newspapers and magazines, is not geared toward interactive material. It doesn't understand it, and can't embed it--even embedding static images online is cumbersome, as for a long time CQ eschewed graphics in its print daily, and our web system is based on the print pipeline.
The result is a series of workarounds that we are still trying to streamline. Since we can't embed interactives, we end up storing them on other servers, which hurts our traffic numbers. Our search function also can't index items outside the standard text content management system, so we currently have to create pseudo-articles to link to them with metadata. And unless we are careful, such ad-hoc arrangements have a tendency to sprawl across directory structures and servers in such a way that they become impossible to manage in the future. I don't want to give the impression that we're standing still--CQ was a leader in early online journalism, and substantial upgrades to address these issues are in the making--but right now it's a real hassle.
If we do our jobs right, and I think for the most part we have, none of this is ever visible to our readers. But it's awkward and time-consuming from the newsroom's perspective, and we are certainly far from the only publication having these problems. To this day, I can't remember the last time I used a newspaper search box and got the results I wanted (Google finds them just fine, however). Perhaps this is why the industry has entered into such a state of hysteria over the Internet's corrosive influence, but it reflects a fundamental misunderstanding: these aren't indications that journalism fails to work online, but that print formatting fails. Does that seem obvious? Yeah, well: welcome to the conversation.