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?



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!



Week 3: Javascript and justices

10:31 pm by Heather Billings. Filed under: Hacking the News,Information Design,Programming

This recap is a bit later than it should be because I wanted to wait until I finished up the project I was working on at the end of last week.

This was a really cool project, and I was very excited to get to work on it. I built it in Javascript and jQuery (though the front graphic is in Flash, done by my mentor — “professional partner,” the term the Post uses, is just creepy — Wilson Andrews), and it was the first time I’d tackled a project done *only* in JS/jQ on my own. I’m pretty satisfied with the end result, but here are a few takeaways:

There’s a difference between JSON and a JS array. I mean, technically, I knew this, but I didn’t really get the usage. If you find yourself confused on what a JSON object is, read this very helpful piece on this very confusing matter.

I’m a messy coder. Part of this stems from deadline; part of it from plain ol’ bad habits. The biggest of the bad habits is not planning out the project effectively enough before I start coding. It feels like a waste of time sometimes, like I should just be building it. (Sort of like, in college, when making an outline of a paper before you wrote it felt like a waste of time. Oh, wait, that almost always was.)

But there’s another reason for messy code, and that’s lack of understanding. As I mentioned in a previous post, I understand functions now, and I was able to implement them to some degree in this. But my code is laughably, hilariously far from optimized. My goal this weekend is to go back over my code and figure out how I could have saved some effort. That way, hopefully next time I’ll be able to do it right from the get-go.

In addition, I’d really like to figure out how to pull data from an external source, whether a text doc or something else, so that I don’t have to include it all in my JS file every time. I don’t believe it’s difficult, but it is something I’ve never figured out before.

IE hates media queries. The print version of the graphic was accompanied by a QR code that would take people to the interactive. Which was fine until they decided to do the front panel in Flash. Hello, Steve Jobs.

I thought I would be clever and use media queries to assign different stylesheets depending on viewport width. Somehow, however, IE7 doesn’t recognize the media queries. Instead, it happily reads everything. So the queries looked great in Firefox, Safari, Chrome, and even my iPhone, but IE (even IE8) rendered a pile of steaming poo. Somehow I fixed it for 8, but when I got to work today, it was still broken in 7. In order to make it not broken online, we had to remove the queries completely and just let iPhone users suffer. Not a solution I’m happy with. So after I finish figuring out how I could have written more effective Javascript, I’m going to take another swing at media queries with just a very simple stylesheet and test page, and see if I can figure out how to write a media query that will get the job done, and that will ALSO be ignored by IE. Wish me luck.



Week 2: Charts, numbers, and popularity

3:41 am by Heather Billings. Filed under: Information Design

After last week’s insanity (“like taking sips from a fire hose,” as an old mentor used to say), this week…well, this week was insane too. It was a different kind, though: I spent most of this week creating graphics for print, something I’ve never done before. I’ll have a few coming out this coming week, too, but here’s the first.

I will admit to a bit of fluster when I was told to make a “two-column graphic.” Illustrator, which I am weaker with than Photoshop, does not have a “two-columns’ width” option. Hannah helpfully provided me a reference sheet that broke down how wide columns were, dependent upon how many legs you wanted, in…something that was not pixels.

Thus, I learned about pica notation. I also had to figure out what a “leg” was in newsprint, and then, frantically at the end, realize I’d created the whole thing in RGB instead of CMYK. Enlightenment!

I never realized before doing this how much design actually goes into creating a “simple” bar graph. Sure, I realized there were color and font choices, but working with Hannah on spacing, labelling and positioning gave me a deep appreciation for her eye for detail.

There were two things that disappointed me about this project. One, I was told that if I had ideas about how to make the graph interactive, I could try them out and we’d use them if they were good. I spent so much time creating the base graphic that I never got to try out interactivity. (Even something simple, like being able in this graphic to choose which income bracket, if any, you wanted to see stats for, would have helped unclutter the page.)

The second thing was that I thought I had a better handle on the Post’s CMS than I did. Friday night, I was unable to get all of the components of the story together, forcing me to lean on other members of the staff even more than I do already. They’re quite graceful about helping me, but I hate making them do extra work just because I overestimated my capability for Methode.

However, this week I also got just a little more comfortable acting on my own ideas. I got to pitch ideas for a summer project, a couple of which were received with enthusiasm despite my immense nervousness. I’ve never liked pitching stories — does anyone? — but this was a whole new level. A tip: Don’t ever actually admit your nervous to your editor, as I mistakenly blurted at the end. I learned years ago, while showing horses, that if I admitted my nervousness, I got more nervous. Consequently, instead of memorizing my pattern, I’d focus on how tense I was. If instead, when people asked how I was, I replied that I was excited, I rode with less tension and a clearer head. (I still could never remember my number, though.) I’ve noticed the same applies to public speaking. Yet I allowed myself to get worked up about this, and as a result, I think I came off much less professional than I would have liked.

But she liked a few of my ideas and I’m going to get to pursue them. So it’s a win in the end.



First week on the job: Being the rookie

12:49 am by Heather Billings. Filed under: Hacking the News,Information Design,Programming

I just started my summer internship at the Washington Post. (I love DC, and you can follow along with more of that here on my poorly designed personal blog.) My supervisor has asked me to write a recap of what I did at the end of every week. Since I was busy moving into a new apartment this past weekend, my first is a bit late. Normally, I’ll post these on Fridays. I’m not sure if these thoughts will be useful to anyone else, but I hope they’ll at least be amusing.

After a day of orientation and awe, all of the interns were released to wreak havoc upon our respective departments. When Hannah Fairfield, my supervisor, told me in our morning graphics meeting that she had my first project, I was expecting something simple and innocuous. Something that would safely test the waters and get me accustomed to the workflow before pushing my limits.


She showed me a print graphic that depicted the latest NBA playoff games as line graphs. In each, you could see how much of a lead the frontrunning team had at any given time. They chased each other and wove in and out like sparrows fighting. It was a fabulous way to see the way the games had progressed.

“I’d like you to make this interactive,” she said.

My dirty secret: Despite many, many efforts by a multitude of people, I don’t understand sports. Baseball makes the most sense, but my grasp is tenuous. I never know what’s going on in football or basketball, though I’ve tried to understand both. I didn’t even know NBA playoffs were going on, much less anything about how the game worked. I knew I’d have to get my brain around the game if I were going to chart it.

So when I got the assignment, I felt like I couldn’t breathe. I had flashbacks to my first TA stint at ASU, where I was assigned to help with a sports journalism class. You know those moments in which it seems like the entire world is riding on your ability to say or do the right thing? And if you screw it up, you’re never going to be able to recover? They’re going to wonder why they brought me on board. I’ll never work in journalism again. This is my only chance and I’m going to blow it. You know, melodrama like that.

I wasn’t sure how to attack the problem, what sort of guidelines I was expected to work within, or whom I should ask for help from. Looking back, I wouldn’t have had it another way. But at the time, it was like having a mini panic-attack.

I felt that way on and off throughout the week as I worked on the project. I’d never worked this extensively with Javascript, and it was hard to transition from my jQuery knowledge to full-on JS. In addition, it was a lot of math to work with — something that’s never been my strong suit. It didn’t help that I was used to working in Python and kept screwing up the JS syntax as a result.

First I had to figure out how to get an Excel column into a text array, then change the format minutes:seconds to convert to all seconds. I was fortunate that I’d played with hacking together a Twitter scraper a few months ago, because I knew I’d need to strip the colon from the time format. parseInt() and Mr. Data Converter saved me. Then I had to figure out how to get the x-axis to plot the time of the entire game, even though the minutes and seconds in the spreadsheet zereoed out every quarter. My “professional partner,” Wilson Andrews, the guy who gets the utter joy of mentoring me all summer, helped me with a lot of this, but then left on vacation. Poor Kat Downs had to do most of the heavy lifting with me.

So I took a shot at writing the JS behind it, and then Kat rewrote it the next day. I learned so much from watching her work. (For one, usage of functions — something I’ve been trying to wrap my mind around since my C++ class a year ago — finally made sense.) But it was also nerve-wracking. This had been assigned to me, and it felt like a horrible failure that I wasn’t able to do the meat of it alone. I didn’t want to be a disappointment. Kat spent several hours working with the JS before it behaved itself, and that doesn’t even count the IE debugging (though I learned a bit about that, too).

But by the second and third day (of my two-day deadline), I was getting more confident. I was able to hunt down some bugs and fix them with the aforementioned function knowledge that I’d picked up. And a few things that I missed were obvious things that I chalk up to nerves.

The end result is clean and functional.

I’m not sure what I was expecting, but this wasn’t it — in a good way. The sink-or-swim lack of hand-holding surprised all of the interns, I think. (It was a recurring theme at our evening outings this week, at least.)

And I learned a lot about the way I work. I tend to underestimate the time it takes me to do things. Or, perhaps more accurately, underestimate the number of things that can go wrong and how long fixing them will take. I have to stare at a problem for a bit, turn it around in my head, before it makes any sense to me. But once it makes sense, all sensors are go.

Now that it’s Monday, “go” is now.



The Web’s storytelling potential and how we’re not using it

1:47 am by Heather Billings. Filed under: Information Design,Programming,The Future

“Jonathan Harris’ magical new media projects redefine storytelling” from PopTech. The entire video, which I recommend highly, is available here.

Registration for ONA ’11 has just opened, and that means it must be time for me to write about my takeaways from ONA ’10.

Today I ran into AP videographer Yvonne Leow at a Phoenix coffee shop, and during a passionate conversation about the future of news, she asked me who my inspiration in journalism was. There was really only one possible answer: Jonathan Harris.

In a way, I couldn’t possibly have written this post any earlier, because for the past six months I’ve been internalizing ONA ’10, most importantly Harris’ keynote.

Harris is my hero. If you’re looking for inspiration, there is none better. (I unfortunately cannot find his ONA ’10 keynote video, but I’ve embedded an excellent video from 2008 in which he talks about storytelling platforms as a way to share our experiences. Hint: Avoid the omniscient narrator. The entire 20-minute video is available here.)

He is an artist, not a journalist, but he is a storyteller.

I pulled up his site to show Yvonne some of the things he had done (unfortunately, Chrome doesn’t seem to like his projects very much). She agreed that they were cool, but asked me what I thought journalism could possibly do with them.

And it’s a fair question. Harris’ projects tend toward the avant-garde, are often difficult to navigate and understand at first glance, and can be overwhelming. But that’s because, first of all, he’s an artist and being avant-garde is all right. And secondly, he’s handling huge amounts of information. His online dating visualization, “I Want You to Want Me,” comprises thousands, if not millions, of online dating profiles.

But I think Harris’ approach is one that news should experiment with. We’ve lost the “multi” in “multimedia,” too often content to settle for a video or a graphic. His projects are true multimedia, engaging multiple senses while imparting information.

For instance, Harris’ We Feel Fine project maps people’s feelings. You can filter them by age, type of feeling, gender, and even weather. Now imagine the Arizona Republic adapting that idea to show how Arizonans feel about immigration.

Much better than the normal method of embedding a Twitter widget pulling the #immigration hashtag, eh? In one glance, you could see how an entire state feels about a controversial topic. (Granted, this is just the online population. With an issue like immigration, where the immigrants themselves don’t usually have a significant public online presence, these results would be a bit skewed.)

Harris’ Whale Hunt (caution: graphic material, though it isn’t immediately visible on the page) is another example of a format news organizations could adapt. In this project, Harris took thousands of photos during nine days he spent with an Alaskan Inuit village who every year kills a whale to keep their ecosystem going. You can view the photos in one of several ways, but my favorite includes a “heartbeat” graph. Harris took photos at five-minute intervals, but took them faster during moments of adrenaline rushes. This allows you to see Harris’ emotions over the span of the week. You can click anywhere on the graph to see the corresponding photos. Predictably, the chart spikes when the whale is killed and butchered.

What if a similar idea had been applied to election night 2008? A reporter on scene could have worn a pulse monitor (or, if that makes some journalists squeamish about injecting themselves in the story — a topic for another blog post at another time — an attendee waiting for results), removing the subjectiveness of using rate-of-photography. Photos, video, and text bites could have been mapped to the heartbeat. The emotions associated with that night on both the winning and losing sides made up the story. This is just another way of emphasizing it.

Some of this sort of innovation emerges in journalism once in a while, like Amanda Cox’s New York Times “Olympic Musical” infographic. It maps Olympic results audibly, driving home the fractions of a second separating winners and losers.

A moment of reality: Yes, the technical threshold for these projects is very high. The time required to make them is great. These are not reasons to avoid pursuing them. We should instead ask how we can reshape news to have room and resources for creating them.

Like a filter in Photoshop, these graphics emphasize parts of reality and fade out others.

Also like a filter in Photoshop, news organizations seem to largely be terrified of interpreting the human experience in any but the most cut-and-dried way. Newsflash: You filter reality any time you select quotes or decide which story to cover. It is unavoidable, and we should stop pretending that we don’t do it. Becoming aware that we do it will allow us to represent reality more effectively, not less. These sorts of creative graphics give people a new take on subjects they are familiar with already, create empathy and understanding for communities totally unlike their own, and help them (and us) understand the true impact of events.

Isn’t that what journalistic storytelling is supposed to be?



Tips for using design to effectively communicate

3:42 am by Heather Billings. Filed under: Information Design

I gave the above lightning talk at WordCamp Phoenix about how design communicates. This is an outgrowth of that talk.

Anyone who has ever conducted part of a significant relationship — whether that be a good friendship, romantic liaison or work connection — online knows how unwieldy text can be. Tone is misinterpreted; attention slips away. There’s even now a tone checkerthat purports to tell you the tone with which your message will be read so that you can be sure you are not unintentionally going to get yourself in trouble.

This is not a problem brought about by the Web. C.S. Lewis noted this problem in the foreword to his excellent book Mere Christianity, which is a compilation of short pieces originally produced as a radio series during World War II. Lewis, in a manner that would have done journalism proud, confessed that the publication deviated from his broadcasts somewhat. Once transcribed, he said, the words alone did not convey his message as he wished, and he refused to use such conventions as italics to show emphasis.

“In this edition I have expanded the contractions and replaced most of the italics by a recasting of the sentences in which they occurred: but without altering, I hope, the ‘popular’ or ‘familiar’ tone which I had all along intended,” he wrote in the preface to his 1952 edition.

Humans simply are not hardwired to rely solely on words to communicate. (That’s why, no matter how grammatically incorrect they may be, emoticons are here to stay.) Albert Mehrabian’s communication studies suggested that up to about half of our interpersonal communication is body language when the subject of conversation is emotion.

Design is the body language of the Web

When you move from face-to-face communication to the robotic Web, you’re left with a very large, body language-shaped hole in your communication. That’s where design comes in. The study I just cited focused on communication that has to do with emotions and feelings, which design often seeks to convey.

Design is not just about making things pretty. It’s about sending a message to your viewer. And so, you have to be careful that your design is saying the right things. If you’re not aware of what your non-verbal communication is telling your viewer, you can get yourself in hot water.

Know what messages you’re sending your viewer. If you don’t, you risk your user blowing you off as a joke. In Web design, I’ve seen this happen when a site employs a design that is accidentally similar to one of those link aggregator junk sites. For instance, I confess my early days of coding were heavily reliant upon w3schools.com, which at first glance seems to be nothing more than a scam.

Complexity: Good for dates, bad for websites

Communicating the correct message isn’t enough. You have to communicate the correct message quickly.

One of the first things you learn in J-school is the inverted pyramid style of writing. Developed in the 1800s as a means of communicating effectively via telegraph lines that could go down at any time (especially during the Civil War when soldiers targeted telegraphs), this method simply says that the most important information goes in the first graf, the second-most important in the second graf, and so on.

I use a version of this for visual design.The most important information (such as navigation) on the page should be visibly discernable immediately. Less important information shouldn’t fight for attention, but should be easy to figure out. Something really complex, like an interactive infographic, shouldn’t take more than a few seconds for a user to decipher. Much longer than that, and your user will get frustrated and give up, resulting in negative opinions about you.

As an example, let’s look at DRIFTLESS, a page from MediaStorm, the multimedia storytelling brainchild of Brian Storm. The most important thing, how to play the video, is immediately apparent, as is the navigation to other pages. The second-most important thing, which I would argue is the navigation of the storyline itself, is also easy to determine. The third-most, the sharing and social media options, only show up when you mouse over the video. It takes a little bit more to figure that out, but it’s still easy. (And an advantage of the mouse-over effect is less clutter on the screen; really important when you’re trying to get the user to focus on a 15-minute video.)

Good communication is a dialogue

Relationships with uneven communication are their own unique brand of frustration for the communication-starved party (and sometimes for the communication-overloaded party). In fact, one-way communication almost always results in one party leaving.

Your design should not remind your user of his last ex.

In Web design, the most effective way to create dialogue with your user is to put him in control. He came to your site to accomplish a specific goal, after all.

One great example of doing this terribly occurs in shopping cart design. Shopping carts like Amazon’s require registration before the user can check out with his purchase. This forces your user to do something he may not really want to do. A better cart offers the user the option of registration after he has completed his purchase or provides a “check out without registering” option. A better cart lets the user do exactly what he feels like.

Be aware that different people have different communication styles. Like a good public speaker, your style must communicate to people with different educational levels, backgrounds, disabilities (especially important on the web) and personality quirks. Usually, this means simple is better. If you’re going to do something complex, make sure to get a variety of eyes on it before you call it good.

Know your audience

Your user’s goal may be different from yours. In that case, you need to decide if that user is someone you care about losing, or if you’d be better off without him.

You should also remember that just because you think something is nifty doesn’t mean your audience feels the same way. Twitter feeds are my pet peeve here, especially in the news industry. Unless Twitter is a very large part of your brand, your Twitter feed does not need to be prominently featured on your front page. A “follow us for updates” button works just as well, if not better.

Find your Zen

If you cannot live without a Twitter feed, please for the love of Helvetica don’t make it scroll. All that does is create visual noise, distracting your user from what’s really important.

Former Guardian science editor, letters editor, arts editor and literary editor Tim Radford said, “No one will ever complain because you have made something too easy to understand.”

Japanese minimalist art is very good at minimizing noise in design. In fact, it minimizes noise to the point that the drawings themselves almost seem to generate white noise.

But the Web is terrible at this. The biggest offender is advertising. Most ads are designed not to relay information but to be eye-catching. Flashing banners and floating pop-ups often do absolutely nothing to inform and everything to generate a click. Often I find that the click they generate from me is my back button.

When displayed on a page of search results, Google ads are the counterpoint to this. Designed to look just like the real information you’re looking for, they often (though decreasingly so, it seems) do have information that is relevant to you. Instead of causing discordance, they hum along in tune with the content.

(Ironically, when it comes to news, making advertising look like the surrounding content is something I have a severe ethical problem with. I’m definitely not advocating that here. Are you listening, Los Angeles Times?)

Good decisions yield good design

Every design is the product of hundreds of decisions. Know why things look the way they do. Know why you want some text to be a distinct color, or why your header seems to look better with 10 extra pixels of whitespace around it. By being aware of the decision-making process, you open yourself to seeing how others have made their decisions. It will enable you to pick apart other designs, compare them to your own, understand what makes them all tick — and to determine whether they tick like a Swiss watch or a time bomb.



Case study: Timeline of Mubarak’s presidency

2:56 am by Heather Billings. Filed under: Hacking the News,Information Design

A few days ago, the New York Times published an interactive timeline of Hosni Mubarak’s rule in Egypt. The content rocks, it really does. Great photos, synopses and even links to old articles the Times’ printed about the subjects being discussed.

But the usability leaves something to be desired. It should not be rocket science to position one’s cursor over a target. The markers on the timeline are maybe 10 pixels wide, and if that’s not bad enough, there are places in which they morph into one another.

This industry is supposed to be about making information accessible and interesting. It is definitely the latter, but not the former. A person has to be really, really interested in Mubarak to balance the hassle of browsing.

Another downside of making your mouseover targets so small is losing the ability to label them. There’s no indication of which marker contains what info until you mouse over the marker — very carefully, so as not to overshoot the little things.

I will say that I like the “previous” and “next” buttons in the top right corner. They seem to be aimed at remedying the problems I mentioned above, as they are both large and contain a description of the information to come. But design that requires a “fix” needs to be reworked so that it’s not broken.

Last thought: Why don’t interesting infographics like this ever seem to have an embed option?

Older Posts »