By Evan Wyloge
Today a number of the fellows consulted with our Managing Editor, Jason Manning, Caige Nichols, one of the programmers for our project, and Andrew Long, who will help us develop much of the visual element of the end user experience. As our individual projects have begun to take shape, we discussed ideas for how to present our project powerfully. We definitely didn’t make final decisions about what the look and feel of our projects will be, but we certainly got this process moving.
Speaking only for myself, I’ve considered a lot of different ways for how the story I’m working on might best be presented, but I’ve also shied away from coming to absolute conclusions about this. I want to be sure that whatever decisions we make about the presentation fit the content of the story first. Andrew underscored this point, noting that journalists can fall into the trap of pursuing their story with plans for making it fit a certain visual conception, even if the story would be better served by making those decisions later.
My project utilizes a large quantity of data that’s been gathered by various government agencies over the years, and it has a geographical component. So I’ve considered representing that data on top of a map of the pertinent areas. I also began to think about how content and information that is regularly updated over time could be routed into the piece. This sort of buttressing seems like a great way to keep a story dynamic and compelling, even after its original publication. Examples of this might include using RSS fed updates from government agencies or media outlets, youtube, flickr or twitter filters to bring new content and users to the piece, or automated Web site monitoring tools to add updated context to the piece.
One of my other concerns is that we could to easily try to fit too many technological bells and whistles into our presentation, so I’ve been wary about that. Andrew urged me not to worry about it too much at this point in the process, because that’s where the innovation will happen. It’s the fine line between unrestricted consideration, and focused execution that will produce innovative and coherent work.
Caige and I talked about Yahoo! Pipes, and how it might be a powerful, behind-the-scenes engine for parts of the project. At the risk of receiving the programmer’s rebuke, I’ll try to describe what Pipes does. It essentially gives users the ability to write programs that search, aggregate, mash, tease and format data, information or content from the Web at all times. The program lives within Yahoo! but spits the output to wherever you like. Properly designed, a Pipe can act like a small team of researchers and web producers. What’s even better is that most, if not all of the Pipes are fully open. So you can look at other Pipes and decide you like what it’s doing, and copy or share pieces of the mechanism.
Just as an example of what they can look like, here’s a screen grab of a Pipe I’ve built and tweaked from time to time.
I’m interested to hear what anyone has to say about any of this. If you’ve got input, please don’t hesitate to offer it.
