10 Ideas I Want to Try at the Newspaper Where I Work
March 14th, 2009I am a programmer at an alt-weekly1. Here are some things I’d like to try:
1. Non-free online classifieds. Yeah, well, we have these, and Craigslist has been a problem for that business model. But here’s a gimmick: It would cost money to post a basic free-form listing, but you could bring the price down by providing a more detailed, granular, and professional listing. This is the opposite of the classic model where we charge more if you want to add pictures or extras. Forget that. You want to add real pictures of the apartment you’re showing? Take 10% off for each room you photograph. You could get all the way down to free if you were willing to put the extra effort into it. Reading listings would be free, as usual, and the experience would be better because there is a built-in incentive for people to make their listings better.
2. Wall view – a view of our content that looks like the old front page of Facebook, with all the new articles, blog posts, comments, restaurant reviews, etc. rolled into one stream of short blurbs. Like on Facebook, you could turn the volume up or down on different types of stories and different authors. I know this is kind of a cheap idea, but now that Facebook is trying to look like Twitter, maybe we can try to look like Facebook. This wouldn’t be the only view of the stories, it would just be one of several windows into our content.
3. Personalized concert feeds and email alerts. We have really good data on upcoming shows. People should be able to subscribe to their favorite bands and never miss a show because they hadn’t heard about it or forgot to check.
4. Follower and Audience Relationship Management. Our reporters currently try various things to promote their stories online, and everyone recognizes the importance of building relationships with their audience and other people who cover their beat. And these relationships grow “organically,” as the kids say (actually, the adults say it to me). But it seems like we could do a better job of pushing stories to the right channels if we had a way to efficiently remember who enjoyed and linked to a given story. There are a lot of forms that this could take. I’m thinking of a sort of CRM2 web app that keeps track of your stories, who has blogged about them or tweeted about them, and who has emailed you about them or commented on them.
5. Menu-level restaurant reviews. There are plenty of sites for rating restaurants, and they’re all sort of the same. We had some success a few years ago in this niche with our Restaurant Rater application, but it fell apart due to lack of resources to maintain it, and now we have to compete with sites that are entirely dedicated to that one function. Rather than recreating the wheel again, I would like to see a more granular view of the data. Let people rate specific menu items at various restaurants, so that you can find out who has the best Lo Mein or the best Carbonara. (I only eat noodles, feel free to modulate for your favorite food group.)
6. Lunch Finder. My friend Brian created a brilliant excel spreadsheet: You and your coworkers enter the restaurants where you commonly eat lunch, how much you like them, and how frequently you can tolerate eating there (for example, I can eat Harris Teeter deli food five days a week, Julia’s Empanadas once every three weeks, and Five Guys maybe twice a year). Then when it’s time for lunch, you check off the names of the people who are going out with you, and it spits out a recommendation based on your mutual preferences and the history of where you’ve eaten. I’d like to hook this algorithm up with our restaurant database and just play around with it. I think it’s cooler than just suggesting a random restaurant in a given category.
7. Mash-up stories, or topic pages consisting of multiple formats pulled together and trimmed into a coherent package. Right now, we do serial stories that run in our blogs, but the typical way to see the whole story is to look at the reverse chronological list for the tag that they share (example3). Not very usable. Authors should be able to create a dynamic, sensibly-organized story page by dragging and dropping elements onto a canvas, including the usual suspects like blog feeds (in chron, reverse-chron, or an annotated arbitrary order), comment threads, Publish24 newsgroups, galleries and videos, background information boxes, etc. I think this is basically a “web shell5” at the story level. The main thing I want to do is build an interface that makes it easy for a writer to create one.
8. Layer narrative on top of data, expose both. I’m a big fan of Holovaty6‘s structured-data approach to online news.. I’d like to take the data coming out of a site like Everyblock7 and create a view of that data that a reporter can latch onto and turn into a narrative. Everyblock does a good job of normalizing and cleaning up the data they receive, and that’s often a hard thing to do. I want to better enable our writers to use that stream of data to dig up stories, while allowing readers to drill down through the narrative to the data. A crime story, for example, should have links drilling down to the relevant crime report data, on Everyblock or wherever it’s available.
9. Content APIs – Enough said, right? The New York Times has a bunch of neat APIs8, ergo. We’re a side salad compared to them, but that shouldn’t stop us from implementing some nice, solid APIs that let people grab everything we offer in formats that are easy to manipulate and play with.
10. Open standards for the content APIs, and data portability. I think we could benefit by providing and consuming content using common, open formats. This could be anything from microformats to a shared spec for API calls and data structures. But it should be something that goes a little bit beyond publishing and parsing vanilla RSS, which is what most of us are doing right now. It doesn’t need to the one true format, just a useful standard with a lot of shoulds and mays9. Take the idea for music alerts in #3, for example. We’re an alt-weekly, we worry about the data for our town. We ought to allow our users to export their preferences and import them into another alt-weekly’s similar application if they are staying in another city for a month, so they can be alerted if their favorite band is playing there.
That’s 10 ideas I’d like to try. I have more. We definitely don’t have the resources to do all of these right now, but I think they’re all at least worth considering.
Links
tagged classifieds, journalism, newspapers, programming
Among other things, Will Atwood Mitchell (wam) is the web developer for
May 15th, 2009 at 5:44 pm
[...] @laurenmichell. It would be sweet to see experimentation with the news wiki.Daniel Bachhuber on 10 Ideas I Want to Try at the Newspaper Where I Work says: I dig the ideas Will has for community relationship management, as well as using data and [...]
May 16th, 2009 at 5:47 pm
I’m totally excited by about half of these ideas.
1. Sweet idea. I’m gonna steal this someday.
3. This is golden. And it’s easy. Just use a plugin for SMS, or a mashup with gCalendar. Combine with the revenue dept. at your paper, and you could even sell this service – $5 for the year.
4. Yea… this needs to be built. Sorta a freindfeed meets CRM with some automation. That’s a valuable tool that you could sell to corporations. Startup anyone?
7. This really goes to Jeff Jarvis’s ‘not the article’ idea. But, this is a good look at how the backend might work.
9. Anything you build needs to have an API.
‘nough said.
Cheers!
May 18th, 2009 at 6:53 pm
I had someone ask me today if they could subscribe to an RSS for listings.
We need a way to take the information to the consumers, not the other way around. Email newsletters are a step in the right direction.
May 18th, 2009 at 9:01 pm
@Joey Baker:
Re 4, The audience CRM – I’m working on a prototype, and it’s more or less exactly as you describe, a friendfeed-style wire plus some CRM bells. I first want to get it going for really basic inbound links and referrers first, and then maybe add things like twitter followers, rss subscribers, email correspondents etc as the model becomes more clear.
Re 7, Yeah, I am all about Jarvis’s proposal for topic-centric pages, though I haven’t built hardly any of them yet. But I think it goes to the heart of why newspapers have been struggling with revenue on the web. Newspapers have traditionally gathered and organized information through narrative and layout. The product is a trusted central place to find information about a topic (region, etc) and stories that help you make sense of the information by placing it in context. The narrative and composition of the page open a channel of trust between the publisher and the reader, and there’s enough leftover bandwidth in that channel for well-designed broadcast advertising.
The web, by being linky, inverts the whole thing. Because we click all over the place when we’re looking for news and skim articles, we’re constantly writing our own narratives to make sense of it — more than we do with print. On top of that, the compositional aspect of newspapers doesn’t translate well to the web. Ads make sense in the context of the book, not in the context of a single story. The channel of trust opened by a web story is too narrow to shove a crappy banner ad though. And as a programmer, I’m always looking for ways to make it narrower–by disentangling the data from the narrative to some extent and trying to make it more sharable with fewer restrictions.
And yet, as Scott Karp says, at the end of the day, you don’t want to buy the car parts, you want to buy the car. You want something to help you understand what’s going on. Narrative is still a great tool for doing that, but we need to organize it in such a way that it respects the fact that on the web, the reader has more agency in assembling information. Web shells or topic pages seem like a promising stab in the right direction, and may also have the effect of opening the channel a little wider, so as we can sell the extra room to the highest bidder and buy 30″ monitors and food.
Re 1, classifieds. Please steal this. I have little hope of actually building it.
May 18th, 2009 at 9:04 pm
@Riggs: We gotta do it. There must be at least an ad-hoc way that we can get a usable RSS feed out of the weekly listings dump. I’ll talk to Brian and see what we can come up with.
May 18th, 2009 at 9:27 pm
Likewise. These sorts of ideas are exactly what papers need to attempt instead of just complaining that the information they generate is too easy to pirate and paraphrase. The information is important, but the tools and services that make it interactive and valuable matter just as much these days.
May 18th, 2009 at 10:05 pm
Back in March we provided our own take on this –
http://www.scoopingthenews.com/2009/03/five-suggestions-for-how-newspapers.html
Here are five key elements present on the best blogs that newspapers should adopt:
1. Two-way communication between the writer and the reader. Reporters wouldn’t be obligated to respond to every comment posted, but how about trying to respond to at least a few.
2. Links to similar stories being published elsewhere on the Web. What’s wrong with acknowledging that other publications are providing their own perspectives on whatever the subject is that’s being written about?
3. Show us reader comments on the very first page of your Web site. That accomplishes two important tasks: One, it lets us see what other readers care about and how they are reacting to the news, which can only enhance our news consuming experience by providing more viewpoints; and two, it helps bridge that invisible barrier between reporters and readers, which will enhance the sense of community that newspapers used to provide when everyone read them around the breakfast table.
4. Tell us, the readers, about the people writing the stories.
5. Don’t worry about the presentation. Worry about giving us well-written and well-edited content.
April 8th, 2010 at 11:50 pm
[...] 10 Ideas I Want to Try at the Newspaper Where I Work I dig the ideas Will has for community relationship management, as well as using data and APIs well. [...]