Anthony DeBarros, DocumentCloud/IRE Maureen Linke, AP Chrys Wu, NYT
Both developers and journalists want to do storytelling well.
Developers do a good job when nobody notices anything's gone wrong. For some, it's a moral choice to work informing the public.
Share a drive to be creative, enjoy the creative process.
Journalists v. IT departments
Data vis v. journalists
- Timelines
- Changing workflow
- Getting developers engaged
- Being treated as code monkey when you're a journalist
- Getting people to sit at the same table
Journalist expectations are based on what they already know. Why does it take so long to do something?
Bring in the technologist early.
Journalists' and developers' timelines are very different.
Developers should educate newsrooms about realistic timelines.
Developers should have input into the project, not just be told what to do.
"Proposing solutions" v. "proposing ideas"
"If you would have told us you were doing this…"
The "product" includes not just the words, video, data viz, etc. It's the all-encompassing container, including delivery mechanism. Everyone should understand the capabilities and limitations.
Developers should create a presence in the newsroom. "Don't be the order taker at the drive-thru window."
Personal relationships are key.
Bring them in early. Sometimes too early, but too early is better than too late.
Have an idea what the story is before bringing in the technologist.
Difficult for journalists to know when to bring in technologists, how they set priorities,etc.
Different conversations at different times.
Technologists are a tiny proportion of the whole newsroom, so it's hard for everyone to have an opportunity to work on projects.
Some rules of thumb in one newsroom:
- Involve us from day one
- Data is not an optional, illustrative, extra. It's integral to the project.
If a developer isn't involved early with data, bad things can happen.
Missing data. Human error, machine error. Live data (election streams) can be fuzzy.
Doing it at showtime is too late.
From a presentation standpoint: I can't tell you anything until I see what the data is.
So developers should avoid making specific commitments early on in the process.
Pin it on your boss: "This is a really good idea, but I'll have to run it by my boss after I take a look at the data."
Constant communication helps.
When you're on a big project, a 10-minute status check-in every day or two can be a big help.
"The only way to avoid surprised disappointment is to communicate."
Specs help: Will the table be sortable. If there's a dropdown, what are the values. Should the map zoom in all the way or not?
The journalist will often have reasons why or why not that the developer may not know.
No surprises.
Working almost as another editor on a story as a data person.
Developing a culture of respect. Treat the developer as a journalist who can discover parts of the story too.
Communicate why what you're finding is important.
How do you say no?
Comes from a place of respect. It's not that you don't want to do it, it's that it doesn't serve the story. They need to trust your judgment. Analytics come into play too.
More granular analytics also help you figure out what features to include. Diminishing returns.
How do you deal with developers having to split time between business side and editorial?
Developers have responsibilities to fulfill, can't always take the time to work for the newsroom. Reporters can pitch stories to developers. Work as a side project, talk to manager, etc.