dummied

Recent Projects: Reporters

dummied@gmail.com (Chris) — Thu, 11 Jun 2009 02:50:14 GMT

Over the next week or so, I’m going to try to go into a little detail about some of the things the team at The Indianapolis Star has been working on lately.

First up: Reporters, our aggregation app for content created by Indianapolis Star reporters.

What it is

Reporters is a small Ruby on Rails application that allows the Information Center to easily add new reporters to the system and add new feeds and profile photos to each reporter’s dashboard.

It’s intended to be easy to update and enable users to get a more complete picture of the people behind the news coverage that read every day.

As we work out the bugs and add more content types (video’s a glaring hole right now), the plan is to get as many of our multi-platform reporters into the system as possible.

How it works

Originally the brainchild of Digital News Director Jon Sweeney and developed by the soon-to-be-departed Matt Rogers (leaving us to work here), we explored a lot of options at first.

The originally plan was to use friendfeed as the backend, but when we realized we’d end up doing RSS parsing anyway to get it on our servers, we decided to build it ourselves.

Total development time was maybe a week of man power. This was a side project, not a major project.

Its backend structure takes a lot of inspiration (and a few bits of code) from my side project, FollowIndy (source available on github). Essentially, we have users, users have many feeds and feeds have many entries (ergo, users have many entries through feeds).

We have custom parsers for the moment for IndyStar articles (more on those in a second), Twitter tweets (where we filter out @ replies), Flickr photos, AutoFocus photos (more on AutoFocus in a few days) and a default RSS parser.

Another reason for ditching friendfeed for this are the custom nature of these parsers. We had specific styling we wanted to accomplish (especially with photos), and friendfeed made that difficult at best. Also, there’s an element of keeping the Google juice and branding to ourselves instead of spreading stuff out more (after all, we can’t sell ads on friendfeed, now can we?).

Then there are the IndyStar articles. Because of our, ah, unique installation of Saxotech for the corporate-controlled website, we don’t have any easy way of aggregating articles by any particular author. Luckily for us, we already had a repository of Star content over at Indy.com that also retained a column pointing to the original IndyStar source. One custom atom feed output later, and we had per-author feeds of Star content (as an aside, you might notice that the Star content also gets nicely tagged on its way to Indy.com … which we’ll be exploring down the road).

Where its going

As I mentioned earlier, we plan on getting a lot more reporters into the system down the road.

But first, we have some expansion and bugs to take care of.

Our default RSS parser isn’t handling the XML escaping Publish2 uses in their RSS feeds that well at the moment (though we’ll be deploying a fix for that shortly), we have more content types to add, and we still need a suitable front page, for instance.

In all, this project is the very definition of “beta” at the moment: It’s buggy, it’s not at its final home (likely reporters.indystar.com) and we have a lot more we can do with it.

What folks are saying

We’ve already had some good feedback from journo-folks here and there:

Indy Star’s “info stream” like friendfeed for its reporters — Meranda Watling

Personalized news design — Paul Balcerak

A comment from Ryan Sholin on his Google Reader:

OK, follow Meranda’s link to “Andy’s info stream” and you’ll find something I just think is incredibly cool. Of course, I’m pretty sure a developer built this by hand (although SimplePie would make it not too hard, wouldn’t it?) when they could have just signed their reporters up for FriendFeed, pumped in the feeds, and embedded the stream here. (My guess: They didn’t want to open up another comment channel?)

And a smattering of twitter talk.

What I've been working on

dummied@gmail.com (Chris) — Wed, 11 Feb 2009 10:01:22 GMT

Just copy-n-pasting the README from my current work project to whet your appetite:

AutoFocus

Taking photo and gallery management at large media organizations to a new level

AutoFocus is a photo management application geared to the needs of media entities, primarily newspapers.

It features three primary data types:

Photos

The core of AutoFocus revolves around the basic building blocks of photos. In addition to image files, AF stores metadata about the photos. Photos can be tagged, associated with communities and geolocated.

AutoFocus can automatically resize photos to required sizes on the fly and cache the result.

If set up, it can also store master images on Amazon.com’s S3 service or have photos autotagged based on the caption using Yahoo.com’s term extractor service

Galleries

Galleries are collections of photos. They can either be standard or live (think iTunes’ Smart Playlist feature).

Standard galleries are what we typically think of galleries. An editor or user selects the photos for the gallery and sorts said photos by hand.

Live galleries are a criteria-based version in which matching photos automatically flow into the gallery. Say you have a live gallery looking for a tag of “colts” uploaded by a staff photographer. You can create a live gallery once and as new staff photos tagged “colts” enter the system, they will automatically appear in that gallery.

Like photos, a gallery can be tagged, towned and/or geolocated.

Packages

Where galleries are a collection of photos, packages are a collection of galleries.

The underlying logic is largely the same and a package can also be tagged, towned or geocoded.

Miscellaneous data types

In addition to the earlier-mentioned tags, towns and locations: packages, galleries and photos can also be linked to arbitrary internet pages.

With a json-based api, those linked pages can get a feed of the objects linked to itself and display the media on its own page.

Meta about the app

AutoFocus is primarily the work of Chris Vannoy, the Digital Development Manager at The Indianapolis Star.

If you run into problems or have suggestions/feedback, feel free to email Chris at dummied@gmail.com

Turning Indiana Blue

dummied@gmail.com (Chris) — Thu, 06 Nov 2008 04:21:00 GMT

StarFiles: Obama in Indiana - More IndyStar Galleries

I woke up Wednesday morning to a better America and a blue Indiana.

For the first time in eight years I don’t have to explore how to renounce my citizenship or pour over Canadian immigration law.

Start spreading the news (photos)

dummied@gmail.com (Chris) — Fri, 15 Aug 2008 03:01:24 GMT

Downtown rescue - More IndyStar Galleries

Obviously, photos and gallery management systems have been per projects of mine for a while at work, and the internal app at The Indianapolis Star is still a work in progress, but I managed to sneak in a really fun feature with this week’s newest release:

And embeddable version of each every gallery on IndyStar.

We don’t have it linked from everywhere just yet, but as long as you know the gallery id (which I don’t hide), you can have lovilies like these on your own blog or website.

Star photographer Matt Detrich’s photos - More IndyStar Galleries

The Press: A Newspaper Story - More IndyStar Galleries

Aggregation: To Link or Summarize

dummied@gmail.com (Chris) — Wed, 09 Jul 2008 07:59:30 GMT

So, as I mentioned in the last post, we’re working on a massive content aggregation project right now, with the plan to allow folks to include sources from all over the internet (essentially, anything that has an RSS feed).

So, the question becomes: Do we link directly to the referenced post? Or do we include the RSS summary with a “Read More” link?

Personally, I like the later, and it makes sense from a user perspective since they’re not jumping around all over the place and a business perspective.

The original plan is to do summaries and “Read More” links, for a number of reasons:

It’s a more-friendly user experience (in my mind).
It allows you to maintain a local conversation about non-local content.
Well, there is the whole ad impressions thing …
We can more easily do things with it, such as mixing it into group content, favoriting, linking, tagging, etc.

But, I care about being a good internet citizen as well … so, I’m wondering if anyone has any strong feelings about this sort of topic.

Not hyperlocal ... Hyper-Me

dummied@gmail.com (Chris) — Fri, 04 Jul 2008 05:15:02 GMT

So, the Wall Street Journal finally came out and declared LoudounExtra.com to be a “flop” … and I say, let this be the death-knell for hyperlocal.

LoudounExtra has a lot of issues: leaving out the hyper in hyperlocal, not allowing easy user interaction and contribution, an overwrought design (and yes I’m one to talk), a non-local team in charge, a lack of actual community outreach and a lack of actual promotion, but in the end, doing these neighborhood sites will never “move the needle” (to borrow a recent Curley phrase).

The fact of the matter is, most folks don’t care about their communities that much … they care about niches. Now, some of those niches might *be* communities, they might be interests, or they might be what the people they know are up to. The fact of the matter is, you and I don’t know what other people’s niches might be.

So, play to the niches … and let the user define and create those niches. And we play to those niches by making all (and I mean all) of our content sortable to an atomic level. Let the user create their own social hub around an interest, a community or their buddies and give them the ability to use our content to drive their sites.

What’s this require of us: metadata. We need deep, available metadata on every stitch of content we produce. Addresses on everything, subjects on everything and a way to pull objects (stories, photos, videos) by that metadata. Then we need to expose it to the public. That’s it. Quit trying to control the order of stories, or trying to decide which story is “important.”

Finally, we need to give normal folks a framework to consume those objects – a way for them to say, “Give me the news five miles around my house, the Colts stories and the photos that my friends upload.”

And give them a way to create social hubs around those same objects, a group of users who really care about Broad Ripple, Colts tight end Dallas Clark or local breweries. And let them pick which bits of your content they want to congregate around. And let them add their own content as they wish. Heck, let them add other people’s content if they want (but be kind, send traffic their way, too, and don’t claim it as your own).

Think of a Ning, powered by local content and local people. A spoked wheel of niches aggregated in one intensely local spot.

And expect to see it around October …

Finding somebody's Google Reader shared page

dummied@gmail.com (Chris) — Mon, 19 May 2008 10:27:50 GMT

So, after attending the Interactive Media Conference last week (and picking up an Eppy for Indy.com, natch), I found myself wanting to get a little more connected with folks out there that are doing things similar to me.

I bumped into Ryan Sholin, David Cohn and a bunch of other folks there and wanted to keep up a little better. Twitter’s a great start, but I live through NetNewsWire and it turns out Sholin has a shared Google Reader feed full of good, meaty journo-related content.

Issue is: I don’t want to use Google Reader. NetNewsWire and it’s synching to the web is the bees knees for me and I don’t want to keep another damn tab open (and I’m not on Leopard, so Fluid’s out, too).

Luckily, I figured out how to find Ryan’s shared page (and associated RSS feed).

So, for anybody else trying to hunt this sort of stuff down, here’s how I did it:

Firstly, I’m friends already with Ryan, so he shows up in my Friends’ shared items. Using Firefox and Firebug, I saw that Reader loads this url in the background when I click to see Ryan’s feed:

https://www.google.com/reader/api/0/stream/contents/user/07803237709052972366/state …

Now, I already know that my shared page url looks like this:

https://www.google.com/reader/shared/17170470741209837224

So, that mean’s Ryan’s would be:

https://www.google.com/reader/shared/07803237709052972366

In other words, the Google url structure includes the user id, which is this string of numbers in the api call:

https://www.google.com/reader/api/0/stream/contents/user/07803237709052972366/state …

Just slap that number onto the end of /reader/shared and walk away happy.

Now, a few quick caveats: I don’t know of a quick way to stumble onto somebody’s user id without being a “friend” of them already and this might be something stupidly obvious that’s already floating around the internet, but I didn’t stumble on it with a quick google.

Enjoy!

Addendum: While I don’t have Google Reader’s shared items feed for myself, I do have a Clippings feed from NNW available. It’s more than a little Rails-nerdy, but there’s also the occasional journalism-related goodness as well.

A clarification

dummied@gmail.com (Chris) — Thu, 15 May 2008 06:59:00 GMT

My last post might have been a little too bombastic, so allow me to backtrack a bit and get to the actual point (which isn’t video itself, really).

Media companies, especially newspaper companies have yet to master their core competencies when it comes to the internet. We still don’t do text and photos at any level approaching good enough.

Text and photos are what we do. That’s what we, as newspaper companies, produce heaps of every day. That’s the content we need to nail the leverage of before we start moving into other things.

Text and photos are not solved problems … even the best sites (LJWorld, LV Sun, Washington Post, NY Times) don’t nail it, and most don’t even come close.

It’s about treating our text and photos at an atomic level, and allowing our users to find and aggregate what they want, not what we want them to want. Our text and photos are commodities … and anything we do to keep eyeballs from them a) dumb and b) suicidal.

Text and photos can be a solved problem, but they’re not there yet: and we shouldn’t get to play with shiny new toys like video until they are solved.

And that was the real point.

F--- video*

dummied@gmail.com (Chris) — Fri, 09 May 2008 08:58:35 GMT

Newspapers everywhere are falling all over themselves to do web videos. It’s a goddamn waste of time and counter-productive to an industry that should be looking at what gets the most bang for the buck.

How long does it take to get a video onto your website? Three hours? Four? You shoot it, you edit it (and edit it and edit it and edit it) and you post it. And what do you get for it? 4,000 views (partials mostly).

It’s a waste of manpower, bandwidth and strategy cycles.

Give me the same photographer and the same 3-4 hours of time and I’ll give you 40,000 photo views, minimum. All with new ad impressions.

It’s a waste now and it’ll be an even bigger waste when TV stations get their head out of their asses.

Who do you think is going to be able to more efficiently manage large quantities of video: newspapers or tv stations that deal with it everyday? Shit, they should just post their news segments now, in little segment-chunks. The second they realize what they’re sitting on, they’ll own local online video – no matter how many videos your newspaper puts up of cute human interest stories and self-indulgent drivel your photographers choose to shoot because it makes them feel artistic.

TV stations do video all day, every day. They have the infrastructure and expertise already while newspapers are trying desperately to get a modicum of competence from still photographers and reporters.

Stop buying video cameras. Do it now. You’re wasting money you can’t afford to waste.

You have a hole burning in your pocket? Buy GPS taggers for your photographers so you can geocode all the photos they take and split them up in neighborhoods or down to specific users. It’s not hard to do, and infinitely more useful to your users than that four-minute monstrosity your photographer just did on Billy’s win in the 6th-grade spelling bee that nobody but his parents are watching for more than 10 seconds.

Got photographers itching to help out on the web site? First: lucky you. Second: put them to work adding tag metadata to all your photos and captioning every damn last photo they take (yes … all of them … if they’re in focus, they go into the database).

Stop wasting your energy on video.

Stop wasting your money on video.

Stop wasting your photographers on video.

STOP DOING VIDEO!

(Fun trick: change the word “video” in this entry to “soundslides” … most of it still holds true, minus the tv stations … )

* - Title adjusted at the request of my Mom. Hi Mom!

Come work with me

dummied@gmail.com (Chris) — Wed, 28 Nov 2007 11:39:21 GMT

We have an opening right now in the Innovation & Development department of The Indianapolis Star for a web designer. We’re mostly looking for someone who can take things from initial concept to Illustrator mockup/approval to clean, semantic HTML/CSS.

We’re a Rails house for the most part and we average three to four major new projects a year. IndyMoms.com, IndyPaws.com and Indy.com are our most visible from the last year (bunch of smaller ones thrown in there as well). We’re currently working on a reworking of IndyStar.com and have a whole mess of project ideas for next year as well.

We’re a small group (less than a dozen including management), and we’re the little pirate ship in the roiling seas of corporate Gannett. We work with an agile development environment which means lots of revisions and lots of room for growth for the right employee.

We might also have an opening for a kick-ass Ruby developer coming open soon as well if design’s not your thing.

If you have any interest in either (and we’ve been looking for a while now, so interest alone is a big plus), drop me a line at dummied@gmail.com and I can hook you up with more info.