Walking into BCNI late, I missed the morning sessions and what sounded like a great lunch talk from Zach Seward of WSJ, who talked about what works and doesn't when tweeting news. A couple takeaways I heard repeated later on: Use a colon before URLs. Count engagement in clickthroughs, not followers or even RTs -- often, RTs and clicks don't track. (Complete-in-140-chars stories get RT'ed but not clicked through.) And duh, don't tweet about stuff behind a paywall, to which WSJ has some good answers. His slides are here.
Jumped in halfway into the 1pm session on tech in the newsroom. It was fascinating to me for a lot of reasons. Two guys, Greg Linch from the Washington Post and William P. Davis from the Bangor Daily News, talked about their CMSes and the cultural gap that exists between these two bright guys and the larger newsroom staff. Davis' system uses Google Docs (!) to push to WordPress, and setting it up involved a management change around the copy desk (which was renamed "display desk") and a cultural shift in which reporters needed to start turning in stories with headlines, a workstyle change that is a big big ask. An interesting question came up here: How do you train an entire newsroom on a web publishing system when the code changes pretty much every night, getting better and better, yes, but getting different? (Remembering how hard it was at my old place even to add another round of fact-checking.) What I found wonderful was the genuine concern in this room full of bright, technical people for making sure old-line reporters are comfortable with new platforms. Behind the occasional grumping about resistance, there was no doubting that traditional newspaper-style reporting and writing still had value. Marc Lavallee talked about how he was training a network of bloggers to write 5-6 posts a day versus the longform they were used to doing, and he actually sent his editor out to one blogger's house for 3 days to explain things to him. One takeaway from this: newspapers are lucky if they have guys like Linch and Davis who push them to do the right thing on the web. Another reporter in the room asked how he could start making his own newspaper employer smarter about web publishing, because they were still fixated on their print editions and only pushed web content live once a day, at midnight. It kind of broke my heart.
The 2pm session on using your metrics to drive actionable decisions was brave, and not what I expected. It was
Brian James Kirk from
PlanPhilly, and he basically showed a spreadsheet of last year's Google Analytics data to the room and, not in so many words but, asked what he should do about it. PlanPhilly has some amazing content -- especially their longform reporting on Philly neighborhoods. Whenever I end up there, I am impressed by the careful research and solid writing. But their core audience is 3,500 people who actively work in local planning in some way, and who want super-geeky news about meetings and decisions of the planning commission and L&I and all that. This year, the site has been asked to start generating some revenue. And last year, they lost their biggest single referrer when Brownstoner shut down. Plus, they're
hiring. So they're at an inflection point. The session turned into a brainstorm on what they needed to do. If it was my site, I'd think about both audiences -- those who want the geeky planning coverage and those who like the features. Take
@PurpleCar's suggestion and build some educational products they can sell to the planners. Do seminars, a conference, a newsletter. And then grab the casual readers, Brownstoner's readers, and become the entry point for homebuyers, baby neighborhood activists and neighborhood checker-outers. Sell Home Depot against that audience. Kirk, if I'm being honest, seemed a little worn out, like he'd been going too long without the resources to do the work he wants to do. Someone pointed out a design flaw on the site (... it wasn't clear that you could actually comment on the stories), and it brought a weary acknowledgment sound that is familiar to anyone at any website ever, but that was weird to hear in a room full of so many nimble thinkers. I'm not sure what I learned from this session, but I don't think learning was the point, except to learn how time-consuming it is to pull data from Google Analytics. But it was engaging from start to finish.
The 3pm session started out just being me, the instructor,
Dan Diamond from
Daily Briefing, and a local illustrator. So we started talking. At about 3:15 a bunch more people showed up and turned it into a real class, but we kept the chatty, open vibe. Diamond runs on a series of newsletters aimed at health system administrators, using Lyris and sending to a qualified list, with the goal of raising awareness of his company's research products. They test and test and test. Diamond is the master, and I learned a ton of good stuff here, some that reinforced work I'm already doing, whew. Test, test, test. An engaging subject line primes the recipient to open the matching story inside the letter, but a really engaging line can prompt more clicks overall, which surprised me; not just more opens but more engagement once opened overall. Subject lines need to exactly match something high up in the newsletter. Use a big, dark font, which duh, but designers like tiny, light fonts as a rule, so it was good to hear that testing shows it's a bad call. Newsletters that look like letters are more engaging than designed pieces. If you use Lyris or Mailchimp or another platform, your mailer has a ton of best-practices resources. A bigger takeaway is that email can be an effective front-end to hard-to-reach web content, and that's got me thinking about some of the things I can highlight in my own newsletter. I got to talk about some of our own best practices as well, which mirror what Diamond said. My one amazing tip: use some ALL CAPS, mixed with regular case, in your From: line so the email stands out in the mailbox. Don't everybody do this, or it won't work anymore.
So our 3pm session, which had started out just three people in a large empty room, turned into this great conversation and no one ended up going downstairs to see what the 4pm sessions were. Most of us just stayed in this same room, which turned out to be "Data Journalism." A huge crowd of coders walked in who all knew each other, and we newsletter people were wondering if we ought to stay. But it turned out the class was for non-coders, as the
WSJ's
Albert Sun showed us how to get started using Python to analyze big datasets. You can download his
demo, in which he showed us how to pull data from UPenn schedule files using regular expressions. It was more a proof of concept for most of us, to show that such a magical thing
could be done and maybe unlock some ideas for projects. The table of geeks was really helpful and sweet to those in the crowd who needed help getting TextWrangler going (though I wondered what they got out of the session themselves). Overall, for a presenter who started by spending 10 minutes getting people going in Terminal, many for the first time in their lives, things went smoothly, and it was fun to hear the little cheers in the audience when one of us did something right in Terminal and it delivered a result. OH: I'm programming.
The biggest takeaway from this session was something Albert said: "If you want to learn a programming language, it kind of doesn't matter which one you start with. Just pick one that someone you know knows, so you can bug them with questions."
After this we all trooped downstairs to the atrium to hear some university administrator talk about some new initiative or something as if it was really boring to him. Clearly it had been agreed that he would speak as a condition of using the building. He didn't use his time well.
And then the all-day hackathon guys came out and were not boring! What they did all day while we were in session was awesome. They are working to unlock Philly civic data and make it into usable apps, and what they built on Saturday isn't quite ready to share but it's great and wonderful. Find out more at
http://opendataphilly.org/.