I came, I saw, I coded.

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.

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 + ‘

‘).appendTo(“body”).fadeIn(200);
}

…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.addClass(‘jqplot-cursor-tooltip’);
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) {
temp.push(ax);
}
}
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);
$(‘#tooltip’).show();
$(‘#tooltip’).html(‘

‘ + 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.

IE7

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.

Animation

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!

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.

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.

Ha!

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.

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?

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.

As journalists, we pride ourselves on asking the right questions.

Why, then, does the New York Times come excruciatingly close to nailing the key to journalism’s future, yet still ask the wrong question?

A recent Times Magazine article talked about how a Nick Bilton, former hacker-journalist at the Times, is teaching his students the importance of thinking like programmers.

“[R]eporters need to know how to manipulate computers in order to tell the stories that matter most to their audiences,” the article paraphrased Bilton.

Fact.

The author of the article, Nicholas Carlson, goes on to talk about the cutting-edgeness ofColumbia University’s new programming and journalism master’s.

Right on.

And then we have the question posed to us: “But what’s in it for the engineers, who might have more lucrative things to do than save journalism?”

Cue the ripping out of hair.

Programmer-journalists are not computer engineers.

Computer engineers are not the key to journalism’s survival.

Read that again. Ad nauseum, if necessary.

Sure, the l33t (hacker-speak for “elite”) ones may be. I know of a couple who started out as engineers and turned into journalists. But for the most part, it works the other way around. Most programmer-journalists are journalists who see the advantage in knowing how to bend a computer to their wills because they know they can get better stories or better audience connection that way. They’re already invested in saving journalism, because journalism is what they love.

That’s the difference between an engineer and a programmer-journalist. And its importance cannot be overrated.

And yes, the industry needs its hardcore hackers and its sysadmins to stay afloat. I’m not suggesting love for journalism is a must for all techie jobs in the journalism sphere. But it’s essential for anyone with programming skill who’s going to try to “save journalism.” (As an aside, I think it’s newspapers that need saving, not journalism. Journalism’s doing just fine, thank you very much.)

Need more proof? Read through this revealing and fascinating blog post written by Paul Biggar, one of Newstilt’s co-founders, about why he and his partner decided to shut down the startup. One theme you’ll find is that they weren’t all that excited about journalism in the first place:

“We weren’t intrinsically motivated by news and journalism… Our desire to keep pushing the “mission” was extremely low… We didn’t really care about journalism, and weren’t even avid news readers… This compounded when we didn’t really know anything about the industry, or what readers wanted.”

I’m not trying to knock the idea or Biggar. I think it was a great idea that flopped for a variety of reasons, and Biggar himself is taking a critical look at why. The first in a list of his personal lessons learned is, “Deeply care about what you’re working on.”

And what’s he doing now that his startup has folded? Working for Mozilla, on Firefox’s Javascript engine. Code is his passion: “I’m loving working on compilers again.”

Sound like the future of news to you? Apparently it does to the New York Times. That frightens me a lot.

There’s been buzz in the techie journalism community about the new master’s program that Columbia University unveiled yesterday. In five semesters, students will be able to graduate with a dual master’s in journalism (two semesters) and computer science (three semesters).

The program is touted as the first of its kind. Northwestern has had a programmer-journalist program (which includes sweet tuition waivers), but it seeks to attract programmers who want to learn about journalism instead of the other way around. As someone with a disproportionate number of nerdy friends, I can say that journalism isn’t exactly the first career field that springs to mind when computer geeks hit the job market.

I will say that I’m jealous of the 15 journalism students who are going to get three solid semesters of computer science. But a year and a half really doesn’t seem like enough time to go from n00b to code monkey. And two semesters of journalism training hardly seems enough for someone with no journalism background, especially for the kind of journalist that does the sort of in-depth research so often accompanied by programming skills.

Michelle Minkoff, a recent Northwestern grad, notes on her blog that she was able to learn programming and computer skills at Medill by being willing to pursue it herself. I agree with her when she says that self-reliance is completely necessary in a field where everything’s changing. (The HTML I learned as an undergrad was outdated when I learned it. I’d be screwed if I never educated myself about the XML, for instance, and I’m starting to learn HTML5 now.) Programs that don’t stress an attitude of continuing self-education are going to produce lazy coders. Lazy coders aren’t going to worry about best practices or keep up to date with new developments.

But the impact of Columbia’s decision goes beyond merely providing a smoother path for students. The really big deal here is that one of the most respected journalism schools in the nation has just laid its blessing upon pro-jos.

It’s more than education reform. It’s validation. This move signals that coders might finally be moving from the dark recesses of the newsroom into the respectable light of day. News organizations might finally start realizing that coder-journalists aren’t mutant freaks: They’re the future.

Everyone who’s for the future, join me in urging other journalism schools to forge relationships with their universities’ computer science departments. While the education is what you’re willing to make it, having administrators who understand the importance of such partnerships is priceless.

So now that y’all have seen a few examples of what application programming interfaces are and what they can do, it’s time to get serious. (Don’t worry, though: Lots more examples to come!) I’m in the process of writing a walkthrough for a simple mashup that I will eventually post here, but before I finish that up, I feel it’s necessary to give y’all a bit of an introduction to the world of code.

I’m not going to go into the basics of HTML and CSS, although it will help if you’re comfortable with interpreting both of those. Instead, I’m going to go over a tiny bit of JavaScript, a common scripting language that powers a lot of interactive multimedia. This will help set you up for using APIs.

Embedding JavaScript

It seems backwards to think about putting your code online when you haven’t written any code yet, but trust me. This is important if you want to play with anyone else’s code while you’re learning. (It’s the best way to learn, in my opinion.) All you need are these tags, some of which go in your page’s HEAD and some of which go in the BODY:

<html>
<head>

<meta http-equiv=”Content-Script-Type” content=”text/javascript” />

</head>
<body>

<script type=”text/javascript”>

<!- -

-->
</script>

</body>
</html>

Here’s what that means:

• <META: This tells the browser what sort of scripting language is going to be used on the page.
• <SCRIPT: You’re going to start a script here.
• type=”text/javascript”: This is is like telling someone you’re going to be speaking Spanish.
• <!-- and -->: This tells browsers that can’t handle JavaScript to hide everything between those marks. Those of you familiar with HTML may recognize this as the comment tag, which hides anything written within from the end user. Everything you write will go between these two tags.

Variables

Unlike life, in code you can control your variables. Variables are like shorthand. When I write “w/e” in my reporter’s notebook during an interview, I know what information that abbreviation represents — providing I can read my handwriting. (For those of you familiar with CSS, variables are sort of like declaring a selector’s properties in your stylesheet so you don’t have to declare all the properties every time you use a given selector.)

So a variable is a way of storing information without representing all of it at once. If, when I start my block of JavaScript code, I decide that paperName=”Los Angeles Times”, then whenever the variable paperName appears, the script will know to pull the string of text “Los Angeles Times.”

You can also put numerical variables through all sorts of mathematical paces. (Insert obligatory “Journalists can’t do math” joke here.) All your normal mathematical operators work with variables.  Variables can also store arrays (groups of values under one name) and boolean values (True/False). All variables should be prefaced with var.

Making a statement

As a journalist, everything you write should make a statement, and your code is no different. Actually, you don’t really have a choice. If you want to do anything with JavaScript, you’re going to use statements to do so. Statements are just what they sound like: Information displayed for the user.

So if I want my JavaScript to display “BREAKING NEWS,” I’ll do it like this, using the document.write statement:

<SCRIPT type=”text/javascript”>
<!--
document.write(“BREAKING NEWS”);
-->
</script>

Comments

Comments can be used to write hidden notes to yourself or other developers. This really helps if you ever want to go back and modify the code, or if your code is complex. You can write comments like this:

//I’m a single line comment

/*I’m a comment that can have
multiple lines*/

Functions

Functions are chunks of code that work together. Within a function, you can pack a bunch of different variables into one place. Then all you have to do is call that function, or tell the code to execute all of the actions inside it.

Without functions, all your code would execute when the page loaded, which wouldn’t be very helpful. But with functions, you can tell the code that you want something to happen when a user clicks on something, for instance.

A function has something called a return, which is another kind of statement. The return outputs the answer to what ever you coded the function to do.  A return can be used to output a variable or the answer to math preformed on variables.

Here’s what a function might look like:

//Declaring variables
var aSection = 10;
var bSection = 6;
var cSection = 6;

//This is the function
function numberOfPages() {

return aSection+bSection+cSection;
}

//This is what calling the function would look like
document.write (numberOfPages());

This would display the number 22.

Strings: Putting it together

If words are like pearls, strings are like . . . well, strings.  You can put multiple words together into a single variable to make using them easier.  String names should include str so you remember that you’re dealing with a string.  Placing those letters at the front of your variables name doesn’t change anything; it just helps the string variables stand out later when you’re using them.

In the example above, suppose you want to display context for the number 22 (because just the number 22 isn’t much help by itself).

//Declare your variables
var aSection = 10;
var bSection = 6;
var cSection = 6;
var strText1 =”Today’s issue is”;
var numberOfPages=aSection+bSection+cSection;
var strText2 =”pages”;

document.write (“<p>“+strText1+“ “+numberOfPages+“ “+strText2+“</p>“);

This would display the text “Today’s issue is 22 pages.” Without adding the blank spaces in quotes, you would get “Today’s issue is22pages.”

Remember

• You can use HTML tags inside JavaScript.
• JavaScript is case-sensitive. Best practice is to use all lower case, or to capitalize the first letter of every word after the first.
• Semicolons are your friends. All JavaScript statements end with them. Without them, life as a coder is very very bad.

This is an extremely basic overview. I haven’t even touched on if/then statements, loops or objects. Those are subjects for another blog on another day. But hopefully, you now know enough about JavaScript and basic coding principles to not be too intimidated when you see chunks of code. The best advice I have is to read tutorials (W3Schools.org has some good ones) and look at examples. The more code you pull apart and examine, the more you’ll get it.

Experiment with what you know. You might come up
with a creative combination — like vegan tacos.
Creative Commons photo by Geoff Peters.

Over at the Chicago Tribune, a small band of elite coders has quietly been churning out apps and interactive, data-driven stories. Their News Apps Blog has been around just since last September, and has some pretty cool stuff on it. While a lot of it is over my head (these are serious programmer journalists, and they’re seriously talented), it shows the kind of things newsrooms can be doing if they have pro-jos around.

For example, this page trolls several databases and pulls up relevant reports about nursing homes in the Chicago area. They talk about the kind of work that went into the app on their blog if you’re curious.

This interactive infographic shows where Agent Orange was sprayed in Vietnam in any given period. I will admit to being so preoccupied by the coolness of the interactivicity that the actual information didn’t hit me at first, but that’s probably just me being a geek.

I do wish that some of these had a bit less of a “developer” feel to them. With a little more graphic design, they’d feel less like data. (I think that’s important when you’re trying to get the public to digest something.)

So take an inspiration break and poke around with some of the ways these reporters are combining serious programming with serious reporting. These aren’t programmers working with journalists. These are programmers who are journalists — or journalists who are programmers. Yes, Virginia, there is a Santa Clause.