I came, I saw, I coded.

Among the subsets of programmer-journalists, two are kissing cousins: data journalists, proficient in assembling data and making it tell stories; and visual journalists, proficient in interactivity and design. In best-case scenarios, one pro-jo is both of these, resulting in a database that is easy to use and that yields interesting results. Unfortunately, these both tend to be rather esoteric areas of journalism. We are more often than not, as my data professor Steve Doig once put it, “the nerds in the corner” and “no one really knows what it is you do.”

Well, Paul Bradshaw has taken a bit of the mystery out of it all with his well-circulated article about how to be a data journalist. It really isn’t of much use if you’re looking for a how-to, but it does a good job of explaining what data journos do. A few of the programs he mentions are easy enough to start playing with even if you have no real programming experience: ManyEyes is just plain fun, and Yahoo! Pipes is far more powerful than you’d expect. One of my computer science friends uses Yahoo! Pipes to pull data from many different job hunt sources in order to produce a single jobs feed. Now that’s serious geekery.

(Need more things to play with? Check out this Read Write Cloud article on tools for data journalism. If you’re comfortable with programming, Factual’s API is really cool.)

Near the end of his piece, Bradshaw says, “If you’re good with a graphics package, try making the visualisation clearer through colour and labelling.” This very British footnote is his only nod to visual presentation.

Extending Bradshaw’s thought, I offer this thought: If you’re NOT good with graphics, please, for the love of Photoshop, find someone who is to help you out. Otherwise, you risk confusing and/or boring your audience. A print story that is confusing would (one hopes) be edited until it is clear. This same standard doesn’t seem to apply to Web graphics and visual data. Tables and raw Excel spreadsheets are fairly common. That makes me sad.

David McCandless operates the delightful Website Information Is Beautiful, in which he presents graphical interpretations of data that make my inner nerd squeal. (One of my favorites is his tongue-in-cheek “Because Every Country Is the Best at Something” map.) In his excellent TED talk earlier this year, McCandless said, “Information design is about solving information problems. It feels like we have a lot of information problems in our society at the moment, from the overload and saturation to the breakdown of trust.”

In other words, the way you present information is just as important to telling the story as the information itself is. If you present good information in a bad way, your audience isn’t going to get the proper impact. And this is where programmer-journalists come in. Sure, you could dump your carefully gathered info in a graphic designer’s lap. But he isn’t going to have the innate understanding of that data that you, after spending countless hours deciphering it, have. That’s why having both skills is important.

Here’s McCandless’ full talk, in which he breaks down several of his infographics to explain his designs. If you’re a visual thinker, this will jumpstart you, and if you’re not a visual thinker, it will give you some insight into what’s going on in our brains — and maybe some inspiration for your own projects.

Yesterday, Mashable posted a brief about pictures of the Baja California earthquake on Twitter. The point, as they put it, was that “social media can make personal experiences universal” and that Twitter makes it possible to instantaneously share news as it’s happening.

So if Twitter makes it possible to share news so quickly, why doesn’t anyone DO anything with these sorts of tweets?

While CNN was quick to pick up tweets about the quake, what I haven’t seen is a map of them. Using Twitter’s geolocation function, it should be fairly simple to mash up Twitter’s API with Google Maps, showing where people were tweeting from. Twitpics of the damage, such as those shown on Mashable, would be much more meaningful this way because viewers could actually place where the photos were coming from.

My gut feeling is that things like this don’t happen because newsrooms aren’t set up for them. Much like a paper has stock photos and a station has archive video, news organizations should have mashup templates set up and ready to go for situations like the quake. A preexisting Twitter/Google Maps mashup would have made it a snap for a reporter — even one that’s not a master code monkey — to pull together a presentable interactive diagram of who was tweeting what where. That alone would answer three of the basic journalistic questions in a 21st century sort of way.

An example of Outside.in’s API being utilized by an NBC affiliate in Ohio.
This shows on a map where stories originated.
Screengrab from Citizen Publishing.

Outside.in, the hyperlocal site that pulls news, blogs and other content for just about any given address, is doing what all papers should be doing. It’s made itself a platform.

Last year, Outside.in came out with an API that allowed developers to use the site’s hyperlocal news content in pretty much any way conceivable. As an example of what could be done with the API, Outside.in developers created near.ly, which allows users to get hyperlocal news delivered as direct messages via Twitter.

Why aren’t local papers taking advantage of this idea? Outside.in has a partnership site for news outlets that want to display hyperlocal results. A recent piece from Citizen Publishing makes it sound like Outside.in is really pushing for newspapers to start creating neighborhood pages with local content powered, of course, by the API. But that aggregated local news could just be the beginning of a community page. The page could also display local pictures using Flickr’s API, local restaurants and businesses with Yelp’s API, and local Twitter updates with Twitter’s API (while Outside.in pulls from Twitter, it seems messy to have tweets displayed with blog posts and news articles). And that’s just the automatically generated content, which by itself is not enough to create an engaging community portal. To do that, it needs to let the user take control of manipulating the data: It needs to become a platform. It needs to offer ways to connect with other users, to connect with reporters, and to share what they know. Citizen journalism should be encouraged, but the reality that most people don’t actually care about being citizen journalists should also be considered. In my admittedly limited experience, most people just want to be taken seriously when they do participate. I don’t think reporter-audience engagement can be overrated. Neither can the value of “soft” information like the Yelp rating of a nearby local dive you’ve been meaning to check out.

All of that combined can start making your audience take notice.

It starts with hyperlocal news.

That said, my personal feeling is that Outside.in’s API’s functionality is somewhat hindered by old-journalism thinking. Just because something is happening in someone’s general area does not mean that the news will be of interest. (Though obviously enough people are finding it interesting to keep Outside.in afloat.) For stories, the API does utilize titles. I haven’t figured out precisely how, but it seems there would be a way to limit your results by keyword, thus producing stories about a specific subject — as long as the keyword occurred in a headline.

In other words, hyperlocal news is a great place to start, but it’s not enough.

Come to think of it, that’s true of programming, too.

Twitter’s become an integral part of the Web-savvy journalist’s artillery. The Virginia Tech shootings saw the first real emersion of social media as a reporting tool, showcasing both the problems and proper place of the technology. Most recently, the emphasis has been on using social media to connect to others not only for gathering information, but also for branding yourself as a journalist.

But the potential for using social media for journalism is far greater than it first appears. Wondering how you can use Twitter to do more than just tweet? Take a look at a few of these simple tools that make use of Twitter’s API.

• A World of Photos: Mashup of Twitter geotagged photos and Google’s Panoramio. See what pictures people are tweeting from locations around the globe. This is a better app in theory than in practice, since it seems like most of the non-Panoramio photos are coming from Eastern Europe. I wasn’t able to find another map that displayed pictures graphically on a map like this, but there’s definitely potential for such an application. Something like this could come in very handy if you want to see what people are paying attention to and telling their friends about, or if breaking news happens and you can’t get a photog there in time.
• TweepSearch(beta): Search profiles for keywords. You can even search a given Twitter user’s followers’ profiles for a keyword. Add the city or state, and it will narrow by location.
• Backchannel: Search for hashtags that have been published in the past. Doesn’t seem to go back farther than about a week, but could still be handy for covering events.
• UMapper: Create a map of real-time tweets in a given location, about a given topic or hashtag. A bit more complex that the previous click-and-go applications, UMapper requires you to build your own map. It’s something that could provide good supplementary visuals online. There’s just one caveat to be aware of when using geotagged tweets.

What Twitter features or mashups do you use?

“Why just read the news when you can hack it?”

With arguably one of the best R&D labs in newspapers, the New York Times released its own APIs last year, publicly recognizing that mashups are the way of the future.

No longer the Old Grey Lady, the New York Times and its snazzy Times Developer Network is enough to make a journogeek drool. It’s all there: The beta logo that looks pulled straight from Google Labs, a development console and the gallery of shiny new apps (made with the APIs) hot off the keyboard. I plan to do another installment in which I blog about using the APIs myself, but for now, here are some of the cool things other people have done with it:

• Here’s a straightforward, relatively simple (emphasis on “relatively”) creation by Taylor Barstow: The NYT Explorer. The New York Times’ itself doesn’t have the greatest search, so Mr. Barstow decided to create his own search using their Article API.
• There’s no doubt the media has become more self-aware in the last decade. The Sunlight Foundation created this visualization of how many times the word “transparency” appeared in the New York Times between 1990 and 2009. Even correcting for stories about extraordinarily clear windows, a trend is obvious.
• MovieAB compares New York Times’ movie critics’ reviews with Netflix. MovieAB is a mashup at its best, in my book. People want the information on the go, people will actually read what a newspaper has to say on this topic, and people feel strongly about movies. In addition, it’s comparing one of the oldest forms of media around with a business that is a child of the digital age.
• Politicians are wordy. How wordy? Check out Congress Speaks to find out just how much a given member of the 110th Congress spoke. You can even pit one representative against another to see who’s really got the gift of gab.

So, howdy. I’m Heather, and I’ll be your tour guide for the next several blog posts. Today, we’re going to look at APIs and just what the heck they’re all about.

And remember: Please keep your hands, legs, and purses inside the blog at all times.

I’m sure you’re familiar with Google Maps. You’ve probably seen them embedded in Web sites many times. Below is a very simple one denoting Arizona State’s Walter Cronkite School of Journalism (which just happens to be where I’m getting my master’s).

Nice, but not terribly impressive, though some of Google Maps’ more advanced functions can venture into “wow” territory. But thanks to Google Maps’ API, people can take the map above and turn it into something like Tom Scott’s Real World Racer.

As you can see, APIs, or application programming interfaces, are basically the Play-Doh of the computer world. You can roll a piece of Play-Doh into a ball, or you can take it and make something wild.

APIs allow applications to interact with other applications. Applications are complex things, as anyone who’s ever programmed anything knows. Rather than get into the nitty-gritty of the code, I’m going to focus on examples in which API is used in a journalism-worthy endeavour. Though I may get into the nitty-gritty some, too, especially if I happen to stumble across a tutorial I think is worth sharing.

If you’re not familiar with Google Maps by now, there’s very little hope for you. (Kidding, but not.) What you may not know about are the many other mapping services out there. Platial is one that I just learned about and think is possibly more useful than Google Maps when you’re looking for specifics.

Here’s a quick example I did using pictures a friend of mine and I took in Mesa, Ariz. last September.

Pretty cool. You can tag photos with given categories, meaning that if you want to find coffeehouses (always popular) near you, you can click on their cafe logo.

It’s not without its quirks, however, so be forewarned. When I put in the zip code for Phoenix, it put me in Morocco. I had to zoom out and pan halfway across the globe to put my first pin in. A friend of mine also got taken to Morocco, then got put in France when she tried it again. About as accurate as throwing a dart at a map to find out where you are!