Product, not Process

Journalism, like so many crafts, is often about the process more than the product. A good story will show the trail of reporting and let the reader in on the oblique conventions of policy or public happenings.

Online, too, there is a need for engagement, for openness, not just by those we cover, but by us, the journalists.

But in many ways, the process of getting newspapers from ink on paper to text and multimedia online is getting bogged down by process, when more people really ought to be thinking about the product.

I spoke to a reporter yesterday who is fuming over his paper’s website (it was a private chat about a paper I’d like to work for, so no names here). It’s a conversation I’ve had with friends at several papers, owned by different companies and using different technology. In most cases, there’s a similar theme:

Higher ups don’t get the web, and editors’ eyes glaze over at talk of moderating comments, integrating multimedia, building something that, as Rob Curley says, moves the needle.

What they’re getting stuck on, too often, is the technical details. They’re not thinking about what they want; they’re thinking about how to get there.

Don’t get me wrong, getting there is important, but the underlying code is not something every reporter, photographer and editor needs to, or even should be thinking about. Most of what we do online, as in print, calls for social science more than computer science.

I’ve done this before, helped build a website as the non-technical guy on the team. When we started DalianDalian, Alex was the coder, while Rick hunted for new technology to integrate and I…drew boxes and lines on notebook paper. I would hand those sketches to Alex and say, “Build this.” And to his credit, he did, and even encouraged me to keep doing it (instead of laughing at me or telling me to go learn PHP).

There are plenty of tools I use everyday that I don’t fully understand the underlying mechanics of:

• my car
• my laptop
• soundslides
• iMovie
• Wordpress

I know how to use all of these things, to be sure, but I couldn’t rebuild Wordpress any more than I could rebuild my car engine. That doesn’t stop me from hitting the gas or posting to my blog. If something breaks that I can’t fix, that’s what professionals are for.

And here’s where I think a lot of newspapers get off track: knowing what takes a technical professional (building and fixing tools) and what anybody should be able to do (use those tools).

In some ways, not knowing the intimate workings of available technology can be useful. It helps you think about what you want to build, not what you probably can build. Here are two ways creating something new can go:

1. I have these tools
2. I think I can produce this, that and the other thing

Or:

1. I want to build this awesome thing
2. What tools do I need to get it done?

Again, this is a very real process I go through when producing something online. I built a map this week, and I knew what I wanted it to look like (having explained it in an email to my editor) long before I chose Zeemaps to make it happen. Over the course of putting together the underlying database (taking notes in a Google Notebook, pasting into a Goolge Spreadsheet), I sent messages out over Twitter asking for suggested tools.

I settled on Zeemaps (which I already liked) because it got me closest to what I’d already envisioned with the least headache.

Bottom line: Systems are imperfect. People have limited skills, and there’s no way everyone can (or should try to) learn everything. But waiting for something ideal, or making excuses because a particular tool isn’t on the table, is going to produce a whole lot of nothing.