Early Mockups

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.

An early mockup

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.

So we threw out the JavaScript photo slideshow that could potentially throw a fit if a funny photo size was thrown at it, and went with a Big Picture-inspired photo list. No matter what content was prepared for each day, there would be a defined order—posts always come first, then galleries, then measurements, and finally check-ins. Colin and the gang never have to worry about where their content was going, and just had to focus on making sure it made it to us.

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.

Projects that can be static and standalone should be static and standalone, like our recent Hurting for Work investigative project. It’s nothing more than a collection of HTML, CSS, and JavaScript files living in an S3 bucket.

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.

Where is Colin?

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.