Hat tip to Greg Bacon for the perl one-liner that makes up the bulk of this command.

In the example above (click to enlarge), I have the command bound to ctrl-shift-tab.

To do the opposite, converting tabs to spaces, use:

Taken from the rear-left window of the 3A metrobus on Annandale Road toward Rt 50.

“Obama’s Push for Health Care Cuts Faces Daunting Odds”

Thanks, Meg!

(Screen grab from nytimes.com, hilarious speech bubble added)

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 CRM 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 (example). 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, Publish2 newsgroups, galleries and videos, background information boxes, etc. I think this is basically a “web shell” 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 Holovaty‘s structured-data approach to online news.. I’d like to take the data coming out of a site like Everyblock 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 APIs, 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 mays. 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.