The mobile site is at http://dmreg.com/potholes.

You can see the desktop browser version at DesMoinesRegister.com/potholes, and there’s more info on that project in a previous post.

This is our first extensively location-aware site, and it’s our first really extensive specialty mobile site, so there’s a lot of figuring out still left on this one. But we’re pretty happy with the result.

We used quite a few methods that were different or modified from our other mapping projects.

1. For geolocation, we’re using the W3C geolocation API built in to many phones’ browsers. Safari for iPhone and most Google phones have it, but BlackBerries don’t. Theoretically we’re also supporting Google Gears geolocation, but we haven’t really tested it on mobile devices.

2. We used the Google Static Maps API instead of the more-familiar Javascript API. The Javascript API actually works fairly well, technically speaking, on iPhones and Google phones, but the user experience can quickly become confusing. Dragging things on the map is hard on a mobile device, and zooming in and out on the map often messes with the browser zoom. The static maps API is a lot lighter load for a mobile connection to bear. Almost as a bonus, because I was about ready to write off the BlackBerry browser, using the static API also enables BlackBerry users to use the site (the lack of browser GPS still limits BlackBerry users, but they can at least submit a pothole using an address).

3. We’re using Prototype’s Ajax and JSON to load points and send new pothole data. We’ve done this a few times now, and it’s becoming our standard. JSON is lighter than XML on the server, and you can send data back and forth as Javascript objects, which makes sending complex data much easier (and much easier to modify later).

4. We did this as a website instead of an app in order to work with more platforms at once, and because we’re much better at Web design than objective C (which is to say I know not a bit, and learning will take a while). I’m curious to hear others’ thoughts on this, because I think most journalism shops are going to have a hard time making the economics of iPhone, BlackBerry and Google apps a pretty tough thing to make work. As long as mobile browsers keep developing quickly, I think this is probably the way to go for now, unless you can afford to build your own apps, have a lot more time to devote to one project than we do, or can afford to pay someone else to build them for you.

Check it out, let me know what works and what doesn’t.

HTML/Javascript/Facebook Connect Development: Michael Corey
Database backend/Local government admin: James E. Wilkerson

UPDATE: Mobile, location-aware potholes beta map now launched!

In case you haven’t noticed, potholes are everywhere. We hate ‘em, and we’re out to kill them.

We did a similar map two years ago, but there’s a few big twists that make us pretty proud of this one.

Working with local governments: We consulted extensively with Des Moines Public Works to see how we could build a system for reporting potholes that worked for our users AND for the city. We sent them data last time as well, but it didn’t work well for them. We didn’t have reverse-geocoding figured out two years ago, and someone had to re-enter our data into the city’s system to make anything happen.

Neither side wanted a repeat of that, but we really wanted to build a system Des Moines would actually use. The result: We send them daily e-mails with Excel attachments showing new potholes with exact locations. They’ve told use they’re going to hand those spreadsheets directly to their road crews and use that as a manifest for the day alongside their existing system. We’ve gotten word from several suburbs that they’ll participate as well.

As far as I know this is the first time we’ve ever pushed data TO a government agency. Usually we’re trying our best to pry it loose from them. And we think this is a pretty big win-win. We have a larger megaphone than the city Web site, and they have the power to make the evil potholes go away.

Facebook Connect support: This is our first Facebook Connect app. We’re giving users the option of logging in with their Facebook ID or their DesMoinesRegister.com account. We wanted to add registration of some kind this time around to cut down on spam and to see how willing people will be to use their real ID on our site.

We’re only scratching the surface of what we can do with Facebook Connect, but hey, we launched this thing today. Give us a bit. Lots more to come.

Geo-awareness: We’ve enabled browser-geolocation if the user chooses, so she can mark a pothole near her current location. This isn’t incredibly useful for desktop users, but we’re adding a mobile version soon, and we all know that’s where the real geolocation action is.

The early buzz on Twitter in response to the launch has really been good. And this is the first time I’ve been happy about the worst winter in my recent memory: there won’t be a shortage of potholes to fill this spring.

HTML/Javascript development: Michael Corey
Database back-end: James E. Wilkerson
Photo upload process: Pat McCoy and Michael Corey

The Register’s Annual Great Bicycle Ride Across Iowa, or RAGBRAI, is a massive human-powered party that pedals its way across the state each July. Riders have always taken tons of photos, and for several years we’ve wanted to share as many of those photos as we can on our site.

Photos from the ride are a great example of inherently geographic data — time and place are important to the context — so we’ve also wanted to map them. In 2008 we developed a system that asked users to map their photos, but the process was clunky and we later realized we went about it backwards.

This year, we got it right, and riders have responded. We’ve simplified the photo uploading process (Pat McCoy built a photo uploader class to extend NextGEN Gallery’s uploader for Wordpres, which replaced an earlier Pluck Sitelife API system when we moved RAGBRAI.com to WordPress this year).

After users upload their photo and add a description, we then prompt them to tell us where the photo was taken, if they remember. First we check to see if there’s any geographic data in the photo’s meta data (iPhones and some newer cameras add GPS data by default). If that’s not there, we use any city or address data the user enters to run the photo through Google’s geocoder. Or if users remember exactly where the photo was taken, they can just click on a map to set the position.

As of today, 6 days after the ride ended, RAGBRAI.com’s 2009 gallery has 817 user photos, 554 of which have been mapped. That means users have given us geographic data for nearly 70 percent of the photos, compared to something like 5 or 10 percent last year.

So what accounts for the difference? It’s possible some of it i just that average Web users (RAGBRAI riders tend to be about 40) are just getting more accustomed to online mapping functionality. But I think the vast majority of the difference is in the process we use.

In 2008 we asked users to “map their photos,” and it was possible to upload photos without seeing that prompt. But I think fundamentally, people didn’t get it. But when we integrated it into the upload process, and just asked them where the photos were taken, it made more sense and was a much more passive user experience.

We’ve learned our lesson: Don’t expect users to share your goals for your apps and expect them to do something new — figure out what users are already doing and figure out how to tap into that process.

As you can see, a few photos got placed pretty far from the route. Ah, the joys of user-submitted content! Actually, I’m surprised it didn’t happen a bit more. I think a lot of it is users who initially input some data, then see the map that pops up, and click on it out of curiosity, not realizing that they’ve just moved their photo’s placement.

There’s definitely ways to handle it. If we had more time I’d probably add a spatial query to the uploading process that warns users that their photo has been placed outside a buffer zone around the route — something like 1o miles probably. We could still add this after the fact on the display side, so we only showed photos inside that buffer. But to be honest, as long as the number of outliers is small, I’m fine with a few of them — this isn’t news data analysis here.

Here’s our latest major project, A Des Moines Register analysis of state records revealed the top emitters of six health-threatening chemicals monitored by the state, plus two other contaminants.

The map is an Actionscript 3 application using the Google Maps Flash API for the geo functionality. The Flash also talks back and forth with Ajax on the HTML page. Both the Ajax and the Flash are driven by XML created by PHP with a MySQL database in the background.

Project Editors: Kaas & Mulvad
Database/Django development: Hot Type Consulting
Project design: Michael Corey

This analysis examined the deaths of 121,054 current members of the 3F union, Denmark’s largest union, from 1990 through 2006, and found that accidents are the greatest single cause of the high mortality among union members. Figures are from Statistics Denmark and the Cause of Death Register.

The project leaders wanted union members to be able to see as easily as possible how their local branch was affected. We settled on an Ajax model that showed basic chart data for each branch.

HTML/Javascript development: Michael Corey
Database back-end: James E. Wilkerson
E-mail alerts back-end: Matt Heeren

Classified advertising has long subsidized the practice of journalism, and traditional classified advertising has been under attack. At DesMoinesRegister.com, we wanted to see what we could do to influence that tide by applying the online development and mapping skills that we have learned in our Information Center to the user experience of finding and selling garage sales listings online.

Getting the project off the ground was initially a tough sell, as the collaboration broke through traditional departmental and philosophical barriers. But our conclusion was that there was no conflict of interest in creating a better experience for our customers, and that in trying economic times we have to use our development resources as widely as we can.

We felt we could offer several big improvements over traditional print garage sale listings. Our garage sales are automatically plotted on a Google Maps mashup, and the map display responds to user searches to show only sales in particular neighborhood or sales featuring a desired item.

Garage salers can pick their favorite sales, then print out a customized map with only their choices to take along with them as they shop.

Users can also sign up to be alerted by e-mail as soon as someone posts a new sale with items they’re looking for (“baby clothes” or “furniture,” for example) or a sale near their home.

Since the launch, we’ve had several requests from other newspapers wanting to adopt our technology for their own garage sales sites.

On a summer weekend we routinely have more than 200 sales listed — not an easy list to navigate in traditional form. Instead of fumbling with a map and a torn-out newspaper page with circled favorites, we’ve made garage sale shopping more convenient, most customized, and more fun.

Project link: http://www.DesMoinesRegister.com/buddyholly

Project editors: Kyle Munson, Michael Corey, Travis Graven, Craig Johnson
Design: Kelli Morris, Mark Marturello
Photography: Rodney White, Doug Wells
Reporting: Mike Kilen, John Naughton, Joe Lawler

“The Day the Music Died” played out 50 years ago in a frozen Iowa field. The Register faced the challenge of tackling the historical moment without making it unfold like a high school history lesson, completely irrelevant to our younger audience. It wasn’t enough to commemorate the event: the Register had to explain why it has become one of the most famous dates in the history of rock music.

From the start the project was built around a strong collaboration among our online, multimedia, photo, graphics and features departments. We made several major trips to Clear Lake, Ia., and the Surf Ballroom to gather video, photos and stories. We contacted musicians, Holly authorities and other sources around the globe.

The result is the Web’s most comprehensive hub for understanding “the Day the Music Died.” Highlights include:

• A video mini-documentary, presented within the Flash player skin of a vintage TV set, weaving together the entire project and serving as a gateway to the site.
• An eye-popping splash page that allows navigation to major sections of the site and includes a spinning 45rpm record that plays a Buddy Holly cover song.
• An hour-by-hour Flash diagram of the night of the crash, which traces the flightpath, includes precise details on the plane and more.
• A 360-degree, interactive panorama of the famous “signature room” backstage at the Surf, where hundreds of musicians have left their mark in the last couple of decades.

• Extensive coverage of the 50th anniversary weekend at the Surf, produced in conjunction with the Rock and Roll Hall of Fame, including video (both live replays and edited segments with key figures such as Graham Nash), stories, photos and more.
• A forum in which visitors to the site shared their own memories, tributes and thoughts.

For those wanting to go deeper, there was more:

• A wealth of source documents used in reporting for the project, including death certificates, coroner’s reports and a book excerpt.
• An interactive quiz that separates Day the Music Died fact from myth.
• Two Buddy cover songs solicited from an Iowa band (Poison Control Center) that claims significant Buddy influence. The cover of “Well All Right” brands the project with the spinning record on the splash page.
• Widgets to help spread the the project across the Web
• @buddyholly Twitter account used for project presence on social media and for live news updates the weekend of the 50th anniversary.

Project link: http://www.DesMoinesRegister.com/parkersburgfootball

Site and team photo graphic: Michael Corey
Story: Reid Forgrave
Photos: Justin Hayworth
Video: Todd Bailey and Justin Hayworth

Parkersburg, Iowa, has always shouldered more than its share. Before May 25, 2008, the town was best known for the four NFL linemen produced by the school’s small but powerful high school football team.

Since that Sunday, though, the town has endured more hardship than any town could be expected to overcome. A massive EF5 tornado killed seven people and devastated the town’s homes, businesses and schools.

Over the next year, residents rebuilt their homes and their lives. One of the most important milestones in that recovery was the Aplington-Parkersburg Falcons’ return to the field.

Several players and coaches faced dramatic brushes with death, but every team member had their own story. We couldn’t tell every one, but we wanted people to meet the entire team.

The Actioncript 3 team photo app I built includes a video player that pops up when users roll over a player with a featured story, and rolling over any player shows their name and position.

After the project was complete, the town suffered another shock: Ed Thomas, the team’s revered head coach, was shot and killed while supervising students in the school’s weight room. A former student and player was charged with Thomas’ murder.

Google Earth Video Production: Michael Corey
Data analysis: James E. Wilkerson
Voiceover: Doug Peterson
Reporting: Dave Elbert

We used the MovieMaker functionality of Google Earth Professional to create a virtual tour of the 10 homes with the highest assessed values in the Des Moines metro area.

This was our first attempt at Google Earth moviemaking, and we kept things pretty basic.

I made individual video clips of the Google Earth flyover effect between each property, and combined those clips with still images in FinalCut Express.

For most homes, we only had publicly available county assessor photos of the properties, so we were limited in the angles we could use. If we had the opportunity to take new photos we might have tried to transition a little more seamlessly between the Google and still images, but the effect works well enough as is.

The project also included a Javascript Google Maps API map of every property in the metro area with an assessed value over $1 million, a photo gallery showing the interior of one of the homes, and a story about the increasing numbers of homes with assessed values over $1 million.

After much discussion about the potential privacy issues involved in showing the homes, we limited the zoom level of the Google Map so people wouldn’t so easily be able to hone in on exactly where the homes were on each block.