Transparency, all the way down.
How the Lab’s transparency principle impacts engineering, plus the release of our first open-source code for the HERE for Local Journalism app.
Citizens, local journalism is on the ropes.
The kind that routinely investigates the powerful institutions in your city on your behalf to keep them accountable to your community. Decades of technological change in communications (initially cable television; more recently, and far more decisively, the internet) have chipped away at the centuries-old product distribution and economic model that made local newspapers possible (print publishing and advertising), and by extension the journalistic effort it sustained.¹ Today we’re left wanting for an internet-first economic model to replace it.
The Lenfest Institute for Journalism exists to find that model, and our work inside the Lenfest Local Lab furthers that search for new product distribution and economic models through experimentation with new digital capabilities. In this experiment we’re leveraging native phone capabilities like geolocation, push notifications and motion detection to improve the local news experience, while also supporting the consumer revenue economic model. We recently launched HERE for Local Journalism, an iOS app that leverages all of those capabilities to notify you of stories nearby while you’re navigating your city.
In lieu of covering the many engineering decisions we made building HERE (mostly mirroring those in a typical consumer startup)², we’ll highlight the most unique and promising aspects of our work: how the Lab’s commitment to transparency shapes the products we build.
Transparency means letting newsrooms control tools and features
The premise of HERE is that journalists should be able to leverage mobile features like geolocation to reach their audience at just the right time and place when the news is most relevant to them. But those native features are just tools. And like any tool, they require study and deliberate practice to use well. So much of the engineering work on HERE has focused on “lifting” these low-level native features into interfaces accessible to everyone on the Lab team (product, design, and editorial) so that they too can study and “get a feel” for how the tools work in the wild.
Let’s look at one feature, geolocation.
Apple’s iOS vends not one but several different tools for locating someone over time. For the purpose of notifying you upon approaching a newsworthy location, we use iOS’s “geofencing” API, illustrated well in Apple’s documentation:
When you open HERE, the app fetches the stories nearest you and tells iOS to create a circle (“geofence”) around each of them. When you step inside one, iOS notifies HERE, which in turn notifies you of the story. Looking at that image, you could infer that the data HERE passes to iOS for each geofence are:
- center coordinates (latitude & longitude)
- radiusBoth those data are configured by the Lab from a Wordpress-like CMS. Crucially, the CMS is autogenerated by a tool that inspects our database and generates the necessary HTML forms, which 1) spares engineering loads of development time writing UI code that merely wraps a simple database and 2) shows everyone on the team how we’ve modeled the product. (Note: our choice of backend tools is irrelevant here: every popular server-side stack offers a similar CMS generator). In effect, our team has remote control over each story’s geofence:
Now, from an engineering standpoint it might be tempting to omit radius from the CMS, leaving it solely to engineering; less maintenance, variability, etc. But to do so would limit the entire team’s capacity to experiment with the API’s behavior on their own, to understand its limitations and bake those learnings into their work.
In this specific example, we learned that in practice setting geofences below 100m rarely matter: generally, the feature just doesn’t support that degree of precision.
Our lesson from the above experience? Adhering to the Lab’s commitment to transparency means more than simply open-sourcing our code³ and encouraging outside contributions (as important as they are!) It means sharing all the information available, by default, and trusting the work will be better for it.
Footnotes
¹ Kovach, Bill & Tom Rosenstiel. The Elements of Journalism (3rd Ed.) — If you’re new to the journalism industry like I am, you’ll find this the most helpful primer on the profession and its history. Here’s a litmus test: can you define what journalism is, precisely how it differs from other forms of public communication? If not, or uncertain, read this book!
² Including the perennial favorite, “Why iOS?” Briefly: because it offers the most stable platform for experimenting with the native capabilities we need for location-triggered notifications. Mobile browsers don’t offer background geolocation, and Android’s fragmentation serves us little better: we’d spend too much time sweating OS/device compatibility. For more context, I highly recommend Steve Cheney’s persuasive writing on the subject: Why Android First is a Myth
³ If you would like to explore our implementation, all of HERE’s source code (iOS, API and CMS) is available on Github: https://github.com/lenfestlab
The Lenfest Local Lab is a small, multidisciplinary product and user experience innovation team located in Philadelphia, PA supported by The Lenfest Institute for Journalism.
The Lenfest Institute for Journalism is a non-profit organization whose mission is to develop and support sustainable business models for great local journalism. The Institute was founded in 2016 by entrepreneur H.F. (Gerry) Lenfest with the goal of helping transform the news industry in the digital age to ensure high-quality local journalism remains a cornerstone of democracy.
