Getting Over the 'Walled-Garden' Approach to News Web Sites

By: Steve Outing Most newspaper Web sites are "walled gardens." By that I mean that the content that resides on the sites is produced by staff members or freelancers, or comes from wire services or content syndicates. If a newspaper site invites the public to contribute content (so-called "citizen journalism"), then those members of the public submit their stories or photos directly to the site; that content is hosted by the news site's servers.

But times are changing, and the walled-garden approach to news publishing online doesn't make as much sense any more. It's time to break down some of those walls -- to let more outside content in (and let some inside content get shared outside the walls, though that's a topic for another column).

What am I babbling about here? Well, let's start with citizen journalism and photography as an example. Let's say you've got a site where you invite people to submit photos of a hurricane in order to beef up the visual coverage of the coming storm and give your users an opportunity to take part in the "news conversation" by being more than passive recipients of news from the professionals. (That's a worthy goal.)

Most news sites will ask that hurricane witnesses send them photos by e-mail, or upload them to the site. For instance, the New Orleans Times-Picayune's Web site during and after Hurricane Katrina invited the public to upload photos to a special Your Photos area.

But here's the thing. While some people will post their images to a site like this, there are a bunch more that use other (increasingly popular) photo-sharing sites already. So in the case of Katrina, we saw many eyewitnesses post their photos to popular sites like Flickr (owned by Yahoo!), WebShots, and others, because they're already in the habit of posting images to those services.

If a news site wants to get those eyewitness photos, then it's got to convince the photographers to upload the images to the site's server. Which is silly. Here's a better approach that doesn't "reinvent the wheel" and does expand the scope of visual coverage offered by a news site:

Offer witness photographers an option to copy images that they've placed on other services onto your site without going through the uploading process just for you. Devise a system that gives citizen photographers the option of either uploading an original picture, or merely copying a pointer to the image as hosted on a site like Flickr (or in the case of Flickr, supporting a way for them to assign a photo posted to Flickr to your site within the Flickr user interface).

This could be in the form of a choice that the citizen news photographer makes:
* Upload photo directly to news site, or
* Select from a menu of third-party photo-hosting services and then be guided through the process of selecting a photo and publishing it on the news site, or
* Giving instructions for assigning an image to your site within the third-party service's interface.

The wonderful world of APIs

A variation is to make use of an API (application programming interface) from a photo-hosting service to create a citizen-photo submission system that uploads images to the hosting service instead of the news site's servers -- yet maintains the news site's user interface and design. That's possible using Flickr's API, for instance. WebShots also offers an API.

This is a particularly appealing solution for smaller newspapers, since it eliminates the cost of hosting large amounts of user multimedia content. With the low costs of storage, that might not be a huge issue with still photos, but when you start thinking about hosting lots of citizen-submitted videos, storage costs might be an issue.

(Popular video-sharing sites like YouTube increasingly are where people think to post their personal videos. YouTube offers an API that can be used to put videos hosted there on your Web site.)

And because companies like Flickr are supporting APIs, there's not much of a branding loss by using third-party services to host this sort of content. Here's an example: a photo from a family vacation posted to my personal blog. The photo is hosted on Flickr; I've used a Flickr blog API tool (FAlbum) to show it on my blog with my design interface. The only Flickr branding is a line of text below the photo: "See this photo on Flickr," which links to the same photo shown in the Flickr interface.

Some Web publishers take an even simpler approach and forego some branding. New West, an online magazine covering the Rocky Mountain West, has a feature promoted on its homepage called "New West Photo Gallery." The site encourages its users to post photos to its area on Flickr. When you click through from the thumbnail photos on the New West homepage, the New West interface is lost; you find yourself in Flickr. For a small publication not terribly concerned about maintaining its full branding for everything, this can be an acceptable option.

The thing that the New West approach does is acknowledge that lots of people already use services like Flickr, and tap into that. So for a New West reader who happens to have a dynamite Western landscape photo that she's uploading to her Flickr account, she also can perform the simple step of assigning the photo to the New West Flickr photo group -- so all New West users can see it.

Think about that. If New West required its readers to upload their photos to its servers, its Photo Gallery would be much more sparcely populated. The same thing applies to news Web sites that expect citizen news photographers to upload just for them.

Relying on others

But isn't it dangerous for media companies to rely on third parties like this? What if a service that you're relying on or using its API goes out of business, or makes changes that break services that you've come to rely on?

I asked Adrian Holovaty, Web technologist for Washingtonpost.com and one of the smartest media developers I know, about the wisdom of media companies like his relying on others' APIs. He says that for some third-party services, you do need to be careful. Sure, small start-ups offering cool APIs could run into trouble and leave you with broken site services. But for services like Flickr, with the deep, deep pockets of Yahoo! funding it, he doubts it's much of an issue.

For something like citizen photo hosting, Holovaty says that's not part of the core business for most newspapers, big or small, but only one of many things that Internet staffs have to support. "I definitely don't condone reinventing the wheel," he says. If a newspaper site wants Flickr-like functionality, just use Flickr's API.

As for a third-party company changing its API and breaking features on your site that rely on the API, that's simply something that a tech staff needs to stay on top of, tweaking code that utilizes external APIs as those APIs evolve and are improved. It's no reason not to utilize them, he says.

Events: Another area needing change

There are other content areas where this concept of looking outside your own servers applies -- pretty much anything that involves mixing content from staff professionals and the public. You certainly can count on your staff posting content to your own servers, but not so with the public.

One other area that I urge you to consider is the calendar. Most newspaper Web sites that publish calendars of community events rely on the public to submit information, supplemented by some staff work. The same dynamic discussed above applies to events -- especially now that we're seeing a growing wave of online-calendar services appear on the scene. (Examples: Upcoming.org, owned by Yahoo!; Eventful; and Zvents.) And Web sites like Craigslist are used heavily by people posting public events.

Where in the old days, a newspaper was the central repository of what to do and where to go in a community, such new calendar services are starting to take hold. As they grow, more people will post their events information there. For a newspaper Web site to have a comprehensive community-events service (unless they can devote some serious staff resources to the job), it will be important to hook into these external services.

A key piece of thinking in the community events area is reciprocity. A newspaper website should not only be pulling in events from other services (utilizing their APIs), but also should be pumping out events that it gathers to other online events services.

Look at it this way: With a plethora of events services popping up, event organizers have a formidable task in making sure that they get listed everywhere. A newspaper Web site can be useful if it promises people and groups that the local-events information they share with the site also will be published to a bunch of other online event services. By offering this convenience, the newspaper site becomes the favored first stop when people in the community have events information to share.

Going in the other direction, by pulling events data from other services via their APIs ensures that your events service is comprehensive. Don't give your online users a reason to look elsewhere. (Here's Upcoming.org's API; here's the API for Eventful.)

To summarize, start knocking down some of the walls in your Web site garden. It's time to let the world in -- or risk becoming increasingly irrelevant as the rest of the Web world does its thing with or without you.


My moves

I wanted to let you know about some changes in my career. I've left the Poynter Institute, where I worked for the last 4+ years as a senior editor, to work on a citizen-media start-up company I've founded, the Enthusiast Group. Also, I've started at new blog at steveouting.com which covers online journalism and new media (and occasionally other stuff). Please check in there (or subscribe to an e-mail feed) for additional coverage of online media in between these monthly E&P Online columns.