The case for simplification

9:29 pm by Heather Billings. Filed under: Hacking the News

I’m going to make a radical confession. I have *never* been a regular news consumer. There are several defensible reasons for this, but my life story isn’t the point here. The point is why, despite several efforts to become a regular newspaper reader, I still haven’t been able to form the habit. If something’s big, Twitter will tell me. I’ve been ashamed of this for a long time (no, really). But recently, I’ve discovered that it’s not my fault for having difficulty consuming news from a newspaper.com site. It’s the site’s fault.

First, let me set up some points. Again, the “why”s of my particular case don’t matter:

  • I wanted to consume my news online rather than in print.
  • I was willing to pay for news online.
  • I wanted to be educated on important issues without being treated as if I had some familiarity with the subject being discussed.

More than six years after I first started trying to develop this online news consumption habit, I’ve given up and just started reading a physical newspaper. I couldn’t figure out why reading the news in print instead of online was so much easier until I got about halfway through Donald Norman’s classic book, “The Design of Everyday Things.” In an era where marketing seems to revolve around giving people whatever they want, in as much detail as they want it, I believe that my difficulty with online news is a common one:

Newspaper websites offer too many options.

Norman’s book describes structures called “decision trees.” The basic principle is that any set of choices can be wide, deep, or both wide and deep.

Wide choices occur when you have a lot of different things you can pick from at this specific time.

Deep choices refer to decision paths with many sequential steps.

A choice that is both wide and deep has many sequential steps, and most steps have many parallel possible choices. Norman’s example of a wide and deep decision tree is a game of chess.

By induction, most newspaper websites are akin to playing a game of chess. There are simply too many things to pick from at any given time. When I read a physical newspaper, I can choose to read one of three to eight stories that appear to me at any given time (a wide choice). Then I can choose to follow the jump or turn the page. When I visit a newspaper website, I can choose to read one of several dozen stories that appear to me at any given time (which often have no more text than a headline). Or I can choose in granular detail the section and subsection I’d like to peruse. Or I can see what’s popular right now. Or I can see what my Facebook friends read. And when I do pick a story, I can see six more stories that are somehow related to the one I’m reading now.

Do you have decision fatigue yet? I do.

Newspaper websites are too amorphous.

There is another barrier to my online news consumption habit: my own OCD. When I am reading a newspaper, I know approximately how much is left unread at any time, and I know when I have finished a section. I can say to myself, “Self, you have now caught up on the news.”

My poor befuddled self cannot do this online. There is absolutely no way for me to know when I’ve scanned through everything that has been posted since my last visit to a section, short of pulling an entire newspaper into an RSS reader. Then I lose all sense of which stories were deemed important by the paper’s editors and which were mere footnotes to the day.

Steve Krug touches on this problem in his book “Don’t Make Me Think.” He likens navigating a website to navigating a store. In both instances, you’re looking for something, but online there are no visual markers to tell you what’s around you. My old boss, Brian Boyer, once told me that he thought about websites in the terms of Frank Lloyd Wright’s interior design: At every point, you should allow for “a peek around the corner,” a glimpse of what surrounds where you are.

Newspaper websites do a bad job of compiling previous coverage.

The whole notion of the “second-day lede” is outdated. I work pretty long days, I don’t have a radio or television, and as we’ve seen, I have a hard time getting news from actual news sites. That means I get my news in snatches: on Twitter, or from conversation. Then my brain tells me, “Hey, that sounds important. You should probably see what’s going on with that.”

Yet by and large, news websites overestimate my grasp of whatever they’re writing about. If we’re several days into a story, I have no hope of finding the backstory on a newspaper’s site. This makes me sad, because newspapers certainly have done a more trustworthy job compiling the information than anyone else.

Topic pages address this issue to some degree, but they are, for the most part, not very well done. For one, they tend to be in reverse chronological order (which makes great sense if you’re already familiar with the topic). I would love to see tag pages used to this end. An editor could specify which article (or articles) are the definitive ones. In lengthy, developing stories (like Arab Spring), these definitive stories would be numerous. Secondary to that, a reverse chronological river of posts about the subject could update savvy readers with the latest happenings.

(I’d love to see examples of simple, effective topic pages. I don’t know that they exist.)


When I was learning Python, my mentor Mark Ng gave me a helpful piece of troubleshooting advice. He told me to delete code — not add patches — until something worked. I feel this is where the news industry must go. Services like Instapaper are popular for exactly this reason, and newspaper websites are going to have to follow suit. There’s no reason Instapaper couldn’t have been developed by a newspaper, much like there’s no reason Craigslist couldn’t have been developed by a newspaper. But we don’t think in terms of the bare essentials. We think about retention rates and getting people to click to other stories, which usually just ends up in clutter. (One method of doing this cleanly is the sliding banner at the bottom of stories that the New York Times, among other places, has implemented.) Simplification will be a painful move for a lot of people inside the newsroom, but will make the experience painless for the audience. (Especially pissed off will be that bunch that still feels that having a piece of turf on the front page is somehow essential to their success. Newsflash: if that’s what it takes for you to say you’re a success, you probably aren’t serving your audience at all.)



When the web lets good journalism down

5:12 am by Heather Billings. Filed under: Information Design

I was lucky enough to spend part of last week in San Francisco at Techraking 2012, an event geared toward journ-curious geeks and tech-curious journos. (Many thanks to David Cohn for organizing it!) I was struck, as I always am at geek-focused journalism events, by the lack of focus on design in the storytelling and web production process. In fairness, David had a designer scheduled, but lost him at the last minute. Lauren Rabaino and I spent several minutes examining the package that the designer was to have critiqued. My notes on that are edited, fleshed out, and written below. I have no recollection of which of these are hers, mine, or ours (nor do I see the necessity of designating). But I think it’s a useful study in exactly what a disservice our websites can do to our journalism.

(Note: I have nothing but the greatest respect for the journalists who sweated over this. This only serves as an example of a much larger problem that I see going largely unaddressed in journalism thanks in part to a lack of emphasis on design, in part to one-size-fits-all solutions.)

Wheels of Fortune: Buy Here Pay Here auto dealers

Ken Bensinger was a Pulitzer finalist in 2010 for his coverage of the flaw that caused Toyotas to accelerate without warning. His talent shines in the Wheels of Fortune series as well. He does a fantastic job of explaining a questionable business practice that often fleeces those who can least afford it.

This is, however, also an example of how excellent journalism can fail miserably on the web. I’m going to rant another time (SOON) about the flaws of content management systems and generic solutions, but for now all I’ll say is that the LAT’s CMS is at least partly to blame for the poor presentation of this rich reporting. Example: When I first saw this, all I saw were the DocumentCloud resources. I didn’t understand why these weren’t explained better. It took some hunting to realize that there were incredibly in-depth, painstaking stories associated with them.

Also in this three-part series: At least one photo gallery, two animated illustrations, an interactive graph, several static graphs, and a multi-part video explainer. As Lauren and I explored this series, we both felt that a landing page was absolutely essential. And after a bit of digging, Lauren found that there is, indeed, a landing page for this series! Unfortunately, it’s difficult to find, linked to from only a few of the many pieces. It doesn’t do a great job of introducing the topic or aggregating the pieces. (Part of this is no doubt to blame on the CMS.)

So what could this series look like? Right off the bat, I want to know what Buy Here Pay Here is and why it screws people over, including a flowchart or other visual of how Buy Here Pay Here works. The video Q&A would be a great entry point. This series needs a landing page that shows all of the content items, arranged in a visual hierarchy that makes it clear which give overviews of the general topic and which are associated closely with specific story points. For instance, some pictures in this gallery puts a face on this lawsuit, and this interactive visualizes the data in these documents. However, you can’t get from one to the other very easily.


When Lauren and I first started looking at this package, we thought the documents were all there were. We were incredibly confused until we noticed the little “Read the full series” link.

As a good TribApps nerd, I gotta love and support the idea that you should SHOW YOUR WORK! But we sometimes forget a corollary that’s just as important: EXPLAIN YOUR WORK. I might get lynched for suggesting that putting source documents online isn’t always necessary, but…I don’t think it’s always necessary. I think you need a compelling “why.” In this case I feel like seeing the entire document is actually distracting from the story. I’m not going to comb through all of the documents myself (though some may). I’d rather see the story and explanation take center stage, with just a snippet of the document visible as a secondary element. I’d like links to related content at relevant points in the docs. (Note that the story does link to specific items in the docs throughout the text. Yes!) Ken mentioned in his presentation that he’d originally had much more in-depth explanations accompanying the source documents. I wish those had made it through to the finished version. The data can only speak so much for itself, especially in highly personalized instances like this (as opposed to, say, a table of high-rise fire safety inspections in which you can look up your own building).


The interactive timeline has A LOT of numbers, and it’s easy to lose track of which one means which thing. This would be a lot more compelling and clear with a line chart showing the trend of each number instead, with details available upon hover. Also, colors should mean something. If you’re only using color for differentiation, just put the data in a table and zebra stripe that sucker.

The animations would be better as either static comics (which would probably see some decent social media sharing action) or as an animation, but the hybrid isn’t as compelling as it could be. People like to know where in the narrative they are. (One of many issues I have with pagination of stories.) The nonlinear movement is confusing, and trying to read words as they appear on screen can be stressful for viewers. Words moving onscreen also detract from parsing the visual. Photogs have this down: Powerful imagery + static, concise caption = compelling story. It’s all about the package.



I just want you to Like me.

8:32 pm by Heather Billings. Filed under: Information Design

Every time I help make anything journalistic, the question arises: Where are the social media sharing buttons going to go?

The more “news things” I make, the more I wonder how necessary all of those little bits of clickable confetti are. I would love it if news websites stopped begging people to share everything everywhere. Like flirting, news works best when you’re confident in your assets, not desperate to attract attention.

Reading the news is actually a very solitary experience, not a social one. We’ll share articles that moved us, but only after we’ve finished digesting them. Once I’ve finished digesting, I’m probably not anywhere near the place you’ve plopped your share buttons (unless, like this oldie-but-goodie graphic, your share buttons are literally everywhere.)

Is it really any more convenient for me to hit the “post to Twitter” button than it is to copy/paste the URL to Twitter? Do people still use StumbleUpon? Does anyone born after 1995 know what Orkut is? Did you even know you had an Orkut button on your stories?

No. No. No. And did you?

That said, it’s unfair to lump all social media sharing buttons together under one umbrella. There are really two different kinds: buttons that enable basic link posting, and buttons that offer service-specific shortcuts.

Facebook and Pinterest are the two shining examples in the latter category. A Facebook “Like” button on a Chicago Tribune story is a shortcut for having to navigate to ChiTrib’s Facebook page, find the story (if it’s there), and click “Like.”

A Twitter button, by contrast, eliminates…copying and pasting. It also adds the irritation of erasing whatever silly pregenerated text is in the tweet box before I can compose my own. (Email buttons are similarly redundant and ridiculous.)

Then there’s Pinterest. Pinterest exemplifies the necessity of understanding platforms and audiences, and also rather painfully exhibits news org’s rush to get on board with trends they don’t fully understand.

A Pinterest button simplifies the process of choosing an image and writing a description of your pin. (It also eliminates the step of having to choose between creating a pin or board.) That’s useful and helps streamline things. That doesn’t mean you should use it.

Pinterest keeps things you want to remember around. It’s almost less of a sharing tool, and more of an exploration tool. Pinterest works best with highly visual, timeless content.

That is exactly the opposite of most news content. The exceptions: Magazines, which are often very visual; photo galleries; and some television content. The media that works with Pinterest is, unsurprisingly, geared toward the sort of exploration that is core to the site (and the site’s users).

Lesson: Take some time to really understand the community you’re trying to tap into. Your audience will respect you more for it. Otherwise, you risk giving off that mid-life crisis vibe. Don’t be the 45-year-old driving around in a convertible candy-apple Mustang.

I’m on this soapbox because I’m tired of internet clutter. Design is hard. Reader engagement is hard. Neither of these is assisted by social share buttons. By assaulting readers with social sharing, we’re teaching them to ignore those buttons, just like we’ve already done with standard ad units.

We tell our readers they should invest in our product because our content is great. We proceed to drive our readers to distraction, and social sharing, while a small part of it, is often a contributor. SND did a great interview with Mandy Brown, where she talks about readability. One quote stands out:

I can’t say I love any news sites, though some are certainly better than others. The Times and Guardian both have very competent, readable designs. On the contrary, the Washington Post strikes me as cramped and uncomfortable; the text just feels so unloved.

If we don’t love our own content, how can we expect our readers to value it?



Be a better coder: Break things

5:12 am by Heather Billings. Filed under: Programming

I’ve heard it said that the second-best way to become a better coder is to read a lot of good code. The best way is to have someone else rip your stuff apart.

Since joining the Trib, having my code critiqued has been a regular occurrence. Painful as it is for a competitive perfectionist like me to admit she’s all thumbs at something, I’ve never learned so much. It’s the biggest problem with flying solo, I think — without someone better than you to tell you what you’re doing wrong, you’ll never improve much.

Today involved my boss deleting large chunks of my code only to rewrite them.

“I’m sure I’m breaking all sorts of things,” he said, with a bit of a laugh.

“Breaking all sorts of things” *terrifies* me. What if I can’t even figure out how I *almost* made it work before?

But “almost working” does not equal “functional code.” I realized something while watching Ryan shred and reconstruct my code: When you know something doesn’t work, the best thing to do is toss it and rewrite it. (It reminded me of another principle I learned from Mark Ng around this time last year: When something’s broken, remove things until it works.) It’s a first draft, not a final one, and the latter drafts are always better than the former. It was strikingly like an editor ripping apart a story:

“You’ve said this twice.”

“This part needs to come first.”

“Why do you have this here? It’s unnecessary.”

“This is clumsy.”

“Can you explain why you’re doing it this way?”

(All paraphrases, not quotes.)

Both stories and code are structured information. Both require careful consideration of facts and goals, plus a healthy dose of realism about what’s possible in the given time constraints.

And both require a lot of “just doing it.” In journalism school, I spent a good chunk of time cutting cruft from op-ed articles and re-crafting ledes. It’s foolish to expect elegant code to come any easier.



#jcarn: I see what you did there.

2:29 am by Heather Billings. Filed under: Hacking the News

Over at the Carnival of Journalism, the topic this month has to do with geeks in journalism. The lovely Jessica Binsch prodded me to participate, so I thought I’d oblige with a few hurried words squeezed in under the deadline (which is today). Besides, gotta jumpstart the ol’ blog somehow, right?

So here’s the #jcarn topic for December:

If you are a journalist, what would be the best present from programmers and developers that Santa Claus could leave under your Christmas tree?

And, correspondingly, if you are a programmer or developer, what would be the best present from journalism that Father Christmas could deliver down your chimney?

To start with, I dislike the if/else construction of this topic. How many times do programmers have to prove they can be journalists, and vice versa?

But I’m not here to rail about terms. That’s been done to death. In the end, it’s not what people call you that matters. It’s what you do.

I’m here to focus on that small last word there: “do.” You gotta make things. I know someone who has been looking for a job as a news hacker for some time. The problem, I believe, isn’t that she doesn’t have the skills. It’s that she hasn’t hacked a whole lot together on her own. She doesn’t really have a lot to show off.

This is a problem when you’re trying to get a job, sure. But it’s also a problem when you have a job as a newsroom geek, not only for you, but also for your fellow journos.

So, in the spirit of the Carnival of Journalism question, I’d like to propose a two-part “present,” one for each of the factions listed above:

Journalists (the data-crunching, pencil-snapping, yelling-at-the-cops-on-the-phone folks): Please utilize your geek. We love nothing more than helping you out with reporting, whether you need a PDF OCR’d or have some awesome datasets you want to examine or want to pull together a long arc of reporting together in a simple way. If you come to us early enough and treat us like partners, we’ll probably be able to help you do something really freakin’ cool with your story. (And if you’re totally in love with something another news org has made, tell us! Maybe we can adapt it for you.) Together, we might be able to offer our readers a tool they can use to inform their lives. Isn’t that what journalism is supposed to…well, do?

Geeks (the data-crunching, keyboard-banging, yelling-at-code-on-the-screen folks): Make yourself known. Approach journalists who are writing stories that you see potential for and pitch yourself. (Or, if you see it after it’s been published, let the writer know how you could have helped.) Here’s the rub: A pitch made with only words is a poor one. Much better: email ‘em some examples of things you’ve done, and explain how their story could work with something like this. Do. Build. On the weekends, on your own time. About things that interest you; make you curious. It doesn’t have to be fancy. It just has to be. If we want the respect of those pencil-snapping journalists, we’ve got to show why we deserve to be part of their process. Getting the ball rolling is the hard part.

(Disclosure: I have been very, very bad at this. I build half-projects and get distracted after I learn what I wanted to learn. This is exactly the wrong thing to do. Learn from my inner angst.)

This synergy, for me, is one of the coolest things to see in action at the Trib. The news apps team works with reporters every week, from helping visualize data for reporters to building awesome news websites. (By the way, we’re hiring and would love it if you came and built cool shit with us.) It’s not the right vibe for every newsroom, but it would look very good in a lot of them.



The best bits of job advice I’ve gotten

1:19 am by Heather Billings. Filed under: Hacking the News,The Future

Today word got around that I’ll be joining the news apps team at the Chicago Tribune when I finish my internship here at the Post. While I’m sad to be leaving my incredible colleagues here at the Post, I’m also completely excited for this new opportunity. I can’t wait. I also can’t believe it. I’ve followed the Tribune’s work for the better part of two years, and I can’t remember a time that I wasn’t fascinated by it. They do a little bit of everything, which is exactly the sort of team I want to be a part of.

Some of you know I was blessed and bewildered to be in a position where I had more than one job possibility. Certainly not ever the dilemma I thought I would have in journalism! Deciding what would be right for me was the toughest decision I’ve ever made. I do not say that lightly. But I was also fortunate to be surrounded by very wise friends and family. Here are synopses and paraphrases of some of the best pieces of advice — from serious to silly — I got from them:

From Adam:

Work at a good place around good people. That combination will open all sorts of opportunities regardless of the actual work you’re doing.

From Chris:

If you’re going to go somewhere with a harsh winter, get a damn good job so you can afford all the clothes you’ll need to buy.

From Derek:

Be willing to do whatever unglamorous work you have to do. Realize the future is more flexible than you think it will be.

From Mark:

If you’re having trouble making a decision, you haven’t gathered enough information yet.

From Michelle:

Be strong and ready to forge your own path.

From Trish:

Focus more on the people and work you’re attracted to than the location or the sexy (or unsexy) name.

(EDIT: Meant to include in my original draft that the above advice about working with awesome people is a large part of what made it so very difficult for me to choose. There were no bad potential coworkers!)

There were many, many others, and I am grateful for every one of them. I wouldn’t be in this position without the support and encouragement (and, sometimes, the disagreement) from everyone around me. I’m humbled by the people who have offered me everything from advice to the chance to screw up their websites (oops) to late-night chocolate to last-minute conference hotel rooms. From the time I first got pulled accidentally into the journalism world at The Collegian, the people around me have been the best part of every place, every project.

I’m going to need your support in the coming months, too. It’s going to be a wild ride.

PS: #BC9 and Leslie Thornton, a special thank-you for you. Thanks for giving me a chance to practice my razzle dazzle. <3, Sorceress



May I build you an app for that?

6:20 pm by Heather Billings. Filed under: Hacking the News,The Future

As I’ve been job hunting, I’ve been deluged with confusion over what a news app is, what a news apps team builds, how they integrate into the newsroom.

Oh, and what’s the difference between a tool and an app?

Do people who make tools for journalists to use still practice journalism?

I took some flack on Twitter for saying I didn’t want to be hired to build tools for journalists to use. I’m a journalist, I said. Hire me to do journalism.

I feel my statement has been incredibly misunderstood, partly due to Twitter’s character limit. I wrote and rewrote that tweet trying to fit in everything I wanted to say. So, hey, that’s what I have a blog for, right?

To compare what I said to a more familiar journalistic landscape, one with defined roles: Some reporters have really shitty grammar. Some have excellent grammar and may even be good at restructuring bad copy.

That does not mean that you should put the latter reporter on the copy desk. Chances are that he got into journalism to write his own stories, not to edit other people’s stories. He probably won’t be happy if he continually comes up with story ideas that he can’t pursue.

However, there are people who go into journalism to edit stories and are quite happy doing that. These people are just as invaluable to the end product as the ones who actually go out and get the story. But they operate in a distinctly different role.

Neither of these is right or wrong. They are merely different parts of the same journalism machine. We’ve all seen what happens when news outlets cut copyeditors and suffer from credibility problems.

Similarly, if you take someone who really wants to use technology to create new ways to provide valuable information and analysis to the public, and you hire that person to write threaded comment modules, you’ve got the shoe on the wrong foot.

In the process of providing the info/analysis/reporting mashup, you might just end up writing a threaded comment module (or creating a congressional database that is useful to reporters internally). In setting out with a goal of writing a threaded comment module, you are almost certainly not going to create journalism as a byproduct. This subtle but large difference is the heart of my beef with most journalism outlets hiring pro-jos today.

We need those comment modules. I’m not disputing that. At Cronkite, I worked with Retha Hill, who helped get the Washington Post online as Digital Ink. She told me about the late hours she pulled building pages by hand, and how much time it saved her when slideshow creation tools came along.

Those tools are incredibly important to what journalists do every day.

Their creation is not the same as, for example, brainstorming a new way to interface disaster relief agency databases with stories about the aftermath of the latest act of God.

We need people to build both of these things. Neither is inferior or superior. But they are not the same job, and a person more inclined to one may not be happy with the other.

Of course there will be mundane, inglorious coding. There’s probably going to be a lot of Twitter widget-writing and RSS feed-parsing. The difference is where the focus lies. If that’s what you emphasize when I ask you for examples of the sort of things I’d be working on, I’m going to have the same reaction a sportswriter would have if you pitched him with, “And you’ll get to write obits! It’ll be awesome!”

Before I ever had a journalism background, I had a geek background. I’ve been designing and building sites for longer than people now in high school have been alive (scary!). Journalism drew me in because it was something I believed in that seemed like it needed people like me. And now, having fought tooth and nail to earn the right to be called a journalist, I’m facing people who tell me I should be happy building site components.

If that were what I wanted to do, I’d be freelancing as a web dev from a hammock in Hawaii.

My journalism background should be necessary to my job, not a bonus. The way I’ve been trained to look at information and link it together should inform what I do on a daily basis. If you don’t want me to do that, hire a programmer. But don’t mock me for wanting to practice journalism with technology instead of focus on building widgets.



My footsteps

10:23 pm by Heather Billings. Filed under: The Future

When I got involved with Longshot Magazine, I had no idea it would turn into anything even remotely resembling a big deal. I figured I’d show up, hack on some stuff with a bunch of other geeks, help build something cool, and go home. I never expected to be, as my friend/boss Adam tweeted, “the front-end queen of @longshotmag.” I never expected the site to make anything of a splash. I’m used to releasing stuff, showing it to family and friends, having them go, “I don’t know what you did, but that’s really cool!”

And then Awl did a writeup of the site’s nagwall. And MediaGazer picked up a blog post I wrote on the tools we’d used. And I got job offers, and praise I felt I didn’t deserve, and notice from people who shouldn’t know I exist.

Standing on the rooftop of Gawker Media with some of Longshot’s web team, watching the sun rise Sunday after a sleepless night of coding, I said, “I don’t even know how I got here. I’m just some kid from Fresno.” Adam responded, “We’re all just kids from somewhere.”

I was reminded of his comment today, when a friend of mine in Arizona State’s next graduate student cohort told me (partly tongue-in-cheek) that he hoped the entering class at Cronkite followed in my footsteps.

I feel like anyone can do what I’ve done, whatever that is. It feels very strange when people look up to me, or are impressed with me, because in my mind, I’m just doing what I’ve always done. And maybe there’s a lesson in that.

So, though it feels kind of strange giving it considering I’m still trying to find my first real job, some advice for those entering school behind me, and entering the workplace with me, and rediscovering themselves, and wondering how they can get where they want to be. This is my manifesto:

Do it.

Do it now. Do it every day. Love it. Live it.

Sacrifice for it.

Reach for it even if you don’t think you can get it. Knock on the doors you don’t think will open. Work your ass off. Innovate when it’s not called for, and run from those places that don’t appreciate innovation. Seek an environment where question-askers and boundary-pushers are welcomed.

Be genuinely humble.

Acknowledge the contributions of those around you. Surround yourself with amazing people, so that some of the awesomeness wears off on you. Avoid situations where you are the smartest person in the room. Find mentors. Welcome impostor syndrome. Find your people; the ones who understand what drives you.

Stay healthy mentally and physically.

Walk a lot. Do things that make you happy that are unrelated to your career: this is necessary even if it feels like a waste of time at first. Realize that your most creative thoughts come when you let your brain unfocus. Eat chocolate. Drink lots of water. Sleep. Stay up all night.

Let yourself get in over your head.

Seek opportunities that stretch you: speaking at conference lightning talks, volunteering for big projects. Don’t be afraid of them. Don’t let anyone know they scare you. Focus on the task at hand. Don’t look to far down the road; you can’t see anything anyway. Put one foot in front of the other. Be picky. Be a perfectionist. Never be satisfied with the job you’ve done, even when it’s finished. Go back and pick things apart to see what could be better next time.


Believe in yourself. Believe in a higher power, fate, the universe, the fact that all things work together for good in the end. Stick it out. Slog through the shit. Do it with just as much attention and enthusiasm as the stuff you really love. Save mementos — screenshots, ticket stubs, hotel keycards, silly hand-scribbled bits of brainstorming — that remind you of the high points in your career. Look at them when you doubt. Remember where you came from. Take it with you wherever you go.

If you’re not passionate about it, leave it. If you are passionate about it, don’t let anyone talk you out of it.

Sunrise over Manhattan at Gawker Media

Sunrise over Manhattan at Gawker Media, after a long night of coding and coffee.



How to make a Longshot happen

4:22 pm by Heather Billings. Filed under: Hacking the News,Information Design

When Longshot Magazine’s digital director, Adam Hemphill, asked if I’d like to help assemble a magazine site over the course of a weekend in New York City, I couldn’t say no.

Longshot’s third issue (issue #2, since they started their numbering at zero — geek points!) came out yesterday, much to the glee of a group of very tired editors, fact checkers, designers, audio engineers/producers/editors, and a kick-ass Web team.

The Atlantic featured an article about how the content was produced and what great, mostly free tools they used to put it together. At the bottom is a footnote saying that maybe they’d add something on what the web team used if they could get the info from the digital director.

I’m not Adam (thank sweet God in heaven), but I thought I’d pipe up from the web team. A few of the free/cheap things we used to get the site built in about 36 hours:

  • Django and Python for the back end. (WIN!) Matthew Gerring is a machine. The ease of Django’s admin page was proven as multiple non-techies entered the stories for us. The downside of Django’s admin was also proven as we had to instruct them to wrap each paragraph and block quote in the proper tags. EDIT: My friend/Django master Mark Ng tells me that the way around this downside is using markdown filters. D’oh!
  • Campfire to group chat/share files with the design team. Way easier than email threads that end up buried, especially for a project of this length, because you can see all the context. Better than sharing files on an external device, because you always know EXACTLY where they are.
  • The 1140 Grid System for a CSS framework. It’s pretty solid, lightweight, offers a lot of freedom for creativity, and does media queries pretty well. The down side is that you end up with a lot of div-itis. No doubt there’s a way to hack it so that you don’t have to use empty divs for spacing, but I didn’t have time to pursue that.
  • git and Brotherbard’s Gitx fork helped us all keep from stepping on each other’s virtual toes, especially as changes were flying around 3:30 p.m. on Sunday.
  • TextMate is my code editor of choice. Tons of shortcuts and very customizable to your personal tastes and quirks. Take one look at the About page, full of unordered lists, and you’ll realize how much I love my “wrap all of the highlighted stuff in these tags” option.
  • Basecamp for after-the-fact changes. We should have been using it (or PivotalTracker, which I greatly prefer) from the very beginning, but it didn’t occur to any of us, likely because none of us realized just how huge the project was going to be. But management programs like this are great even for small-scale, because everyone knows what still needs to go down. With our team now dissolved, it’s a great way to keep track of all the little buggy stuff we need to fix.
  • Coffee. Lots and lots and lots of coffee. No one on the web team slept for more than about two hours, and I’d venture to guess the editorial team was much the same. By the time we toasted Sunday’s conclusion on Gawker’s roof with champagne, I’m surprised any of us still had energy to stand up!

Hands-down, this was the best team I’ve ever worked with under intense deadline pressure. I’d do it again in a heartbeat (which is about the length of time the project comes together in).



Graphing the national debt with jqPlot (week…5? 6?)

7:56 pm by Heather Billings. Filed under: Hacking the News,Information Design,Programming

The past couple of weeks have been a blur of JavaScript and data. I’ve been buried in USDA reports researching two various possibilities for my summer project — something I’d better hop on as the summer is rapidly disappearing!

For the past couple of weeks, I’ve been working off and on on this infographic about the amount of debt that foreign countries hold. Credit for the analysis goes to coworker Todd Lindeman, who created the graphic for print and then gave it to me to make interactive.

My supervisor showed me a graphic that the department had done in Flash a couple of years prior with a similar chart. My instructions: Do this, but in Javascript.

There were two huge hurdles in this project. One was finding a jQuery graphing library that supported area chart hovers. The other was IE7 support.

I settled on jqPlot for the graphs. It was the only one I found that seemed to natively support area graph hovers, something I figured would save me a lot of time.

What I wasn’t figuring on was jqPlot’s horrible, horrible documentation. It’s basically an API reference, not real user documentation. (I eventually found the jqPlot user group, the most helpful post of which was this thread on deep customization.)

Breakdown of frustrations with the project (many of which, no doubt, are due to my inexperience):

Tooltip support

In Flot, I could have done something like:

function showTooltip(x, y, contents) {

‘ + contents + ‘


…and it would have just worked with whatever info was supplied in contents() — or, you know, whatever custom function you wanted to write and display. I wanted to display the name of the country whose graph the mouse was over. I had this in a variable that incremented or decremented depending on the data series.

In jqPlot, not only do you have to include a “plugin” to enable the tooltip, but the part of the code that renders the contents of the tooltip looks something like this:

var elem = document.createElement(‘div’);
c._tooltipElem = $(elem);
elem = null;
c._tooltipElem.css({position:’absolute’, display:’none’});

if (c.showTooltipUnitPosition){
if (c.tooltipAxisGroups.length === 0) {
var series = this.series;
var s;
var temp = [];
for (var i=0; i s = series[i];
var ax = s.xaxis+','+s.yaxis;
if ($.inArray(ax, temp) == -1) {
for (var i=0; i c.tooltipAxisGroups.push(temp[i].split(','));

Er, what?

So, yeah, I ended up stealing some super-simple tooltip code and just using this when a data series was highlighted:

function (ev, seriesIndex, pointIndex, data) {
var countryName, debtHeld;
if (seriesIndex == 6) {

countryName = “China”;
debtHeld = china.slice(-1);

‘ + countryName + ‘ holds $’ + debtHeld + ‘ billion in U.S. debt.

(click for detail view)


Custom axis labels

The way jqPlot wants data provided is in pairs: [[0, 50], [2.5,47]]…
That wasn’t how my data was formatted, and it didn’t readily occur to me that I could have probably wrangled it in Excel (oops). So instead of being able to tell it, “use this set of data to plot the x axis, but only show 10 tick marks,” it wanted to show all 126 tick marks. On a 600px wide graph. Yeeaaaah, not so much. I wrote a for loop to only show every 12th one (I only wanted to show January of each year), but then realized that the chart started in March 2000 and ended in April 2011. To save myself time, I just overwrote the CSS and plopped an image in for the axis ticks and text for the labels. Cheap hack, but it worked.

For the y axis, I couldn’t figure out how to tell it “round my numbers for the labels only.” I figured I could probably have just stuck a Math.round() on something, but that would have been too easy… I also wanted to convert the numbers, which were in billions, to trillions (because saying Asia holds 4000-some-odd billions is just weird).

Same fix as the x axis. Boo. There is absolutely no reason I shouldn’t have been able to achieve that with JS.


Okay, when is Internet Explorer NOT a frustration? In this case, though, part of it was a case of what I should have done versus what I did.

How I wrote my code:
I replotted the data every time someone clicked a continent or country, using the same div as the canvas each time. While a fast computer running Chrome shouldn’t even blink, IE7 slogged along, chewing on the data.

How I should have written my code:
On page load, process all the data and draw each chart in its own div. Hide the divs, and just show them with jQuery on click. Slower on the load time, but faster when you’re clicking around.

The other part? IE7 hates jQuery’s .append() call. .appendTo() supposedly works, but I couldn’t get it to (perhaps because I was trying to append to a hidden div). I ended up creating a different set of headers for each continent, and just using .show()/.hide() to pull them up. Ugly, messy solution.


The Flash graphic my boss originally showed me allowed you to select a large portion of the graph, then animated it in a sort of melting, expanding fashion, and showed you the detail.

One of the issues I have with many interactives is extraneous animation. In this case, the animation wasn’t extraneous. Its purpose was to draw your attention to the fact that you were actually zooming in, something that isn’t immediately apparent when you’re just rerendering on a graph *and* changing the y axis.

I’m sure there would be a way to animate a series of data points (slide them all to baseline 0 on click, for instance), but I made that my last priority and ended up just using .fade() to change between them. (That in itself was a pain, as the div would fade out, but show a flash of the new chart before it finished. I fixed that by appending the function that draws the chart as a callback to the fade.) But really, now all I want to do is figure out how that animation would work…

Running out of time

I wish I’d had time to pitch one additional feature. I would have liked to have added a small map of the corner of the world currently being examined. Americans are stereotypically ignorant about the location of other countries (while trying to determine the plurality of “The Philippines,” for instance, I got an autocomplete for “is the philippines…” of “…in Asia”). I had the white space for it. All I needed was to create a CSS sprite that would have highlighted various countries as their corresponding debt was moused over.

Ah well, there’s always next time!

Older Posts »