How We Made “Disappearing Rio Grande”
Tracking, photographing, and writing about a 1,900-mile journey
Last December, Colin McDonald pitched an opportunity for The Texas Tribune to partner on an ambitious project–he kayaks, canoes, and walks the Rio Grande’s entire 1,900 course, and we create a platform that makes it possible for him and his team to publish their reports on the journey. After a very successful Kickstarter campaign, the Disappearing Rio Grande project was born.
Colin is no stranger to enterprising endeavors like this. In 2009, he kayaked the entire coast of Texas as the water reporter for the San Antonio Express-News. In 2010, he partnered with Eagle Scout Jonathan Smith to walk from one end of Big Bend to the other in twelve days. His credentials certainly checked out.
One of the biggest inspirations brought to the table in early talks was National Geographic’s Out of Eden Project Walk project. In particular, we were fascinated by the “map room” version, which allows readers to follow the trail of the reporters and explore the posts geographically. In the beginning, many of our mockups revolved around this idea.
But we struggled to find a way to make this work best on mobile. Should a large map really be the primary method of navigation? What does it do to content being pushed down the page? (We concerned ourselves less and less with the concept of the “fold” as we progressed. (Don’t be afraid of scrolling!) We played with the idea of having a calendar navigation as well, but eventually settled on a tried and true format–the blog.
(For what it’s worth, the large map view is pending! We couldn’t deny how awesome it would be to see the entire journey on one large map. Coming soon.)
We were also pushed in this direction with the news that Erich Schlegel–an award winning photographer that has worked with National Geographic, The New York Times, and The Guardian, among others–would be joining the project. Erich’s photos were guaranteed to be fantastic, and it was vital to make sure they had the opportunity to shine.
Simple Works Best
Probably the biggest struggle with this project was ensuring that Colin, Erich, and Jessi Loerch–a friend of Colin’s and the project’s editor–had an easy way to update the site without any direct involvement from us. We wanted nothing more than to have control over the “publish” button. An editor on our side makes a sanity check on each piece of content in the morning and then flips the switch.
We also knew we were not going to be able to devote any staff time to designing pages. And because Colin and Erich would typically be uploading stories, photos, and data from a tent with an expensive satellite internet connection, page styles had to be functional and attractive enough to work for the entirety of the seven-month journey.
The Beginnings of Something Better
The Texas Tribune’s News App team is still relatively new, and a big part of our focus this year has been on revamping our publishing process. Taking inspiration from our peers (namely, our friends on the NPR visuals team and Los Angeles Times Data Desk), we’ve moved to a two tier system.
Traditionally, the Tribune’s larger projects (AKA ones that require a database) all lived under the www.texastribune.org banner. Examples of this include the salary database, the public school explorer and the higher ed outcome explorer. While this has worked well enough so far, it comes with one serious drawback—any changes to these projects require deploys of the entire Texas Tribune site, meaning any bugs that have snuck into the code base from any of the numerous other projects also within the site could potentially get pushed live along with an app update.
The Rio Grande project is the first in a series of three larger projects that move away from that model. Rio Grande is admittedly a small scale effort—it didn’t require any beefy database or hosting plan to get it going. The app itself is plugging away on Heroku, and the PostgreSQL/PostGIS database is hosted on Amazon RDS.
Why not all Heroku (or all Amazon)? The simplest answer is because it was easy!
We needed the PostGIS support, and Amazon RDS makes it really simple to do. But we weren’t quite ready to jump head first into the Amazon EC2 pool, so we leaned on our familiarity with Heroku’s service to get the project online.
Tracking Progress in Real Time
One of the coolest parts of the project was one the simplest to implement—Colin’s occasional latitude/longitude checkins.
Using a SPOT GPS device, Colin is able to send out simple “I’m still alive” pings with a push of a button. Thanks to SPOT’s relatively solid API, we are able to periodically check Colin’s feed and collect the GPS data.
Because the app is running on Heroku, we take advantage of Heroku Scheduler (essentially a cron job) and fire off a Django management command every hour to see if there are any new points to collect.
The API gives us the last 50 check-ins. The command checks the IDs of each check-in against the database. Is it a point we already have stored? Do nothing. Something new? Create the model and save it.
Is it real time? Not exactly. But it’s good enough.
Who’s Responsible For This?
While I served as project lead, I definitely didn’t do it alone.
Shout-outs to Ben Hasson (@been_hussln), who spearheaded much of the design work, and Jessica Hamel (@jessihamel), who created the wonderful maps.