Part of the mission behind NPR’s Project Argo is to construct a software platform that can maximize the output of a one- or two-person team of reporters. Project Argo is a collaboration between NPR and member stations to strengthen public media’s role in local journalism. As the project has progressed, we’ve realized that we evolved a set of design and development principles that have guided our work throughout.
This is how software invention looks in the era of the framework: Ten years ago, armed with an unstoppable designer/developer combo like Argo’s tech architect, Marc Lavallee, and our designer/front-end developer, Wes Lindamood, we would have built a system from scratch. But almost from the moment our planning for Argo began in early 2010, two things were clear to us: (1) Software such as WordPress, Drupal and Django gave us a great start toward what we wanted to accomplish. (2) No one piece of software would meet all the needs of our bloggers. The bloggers were certain to use tools like Twitter, Flickr, Facebook and Delicious in addition to whatever we used to publish their site. So we set about building a content management ecosystem, integrating a variety of systems into a coherent whole.
These are the principles that have guided the development of our platform (with credit to Wes):
- Capitalize: Build on what already exists.
- Synthesize: Tie elements together into a coherent whole.
- Harmonize: Polish the result for a stellar user experience.
DON’T REINVENT THE WHEEL
As these principles might suggest, much of the invention that powers Argo takes place under the hood. There’s a basic principle in programming, often abbreviated DRY: “Don’t Repeat Yourself.” A central aspect of the concept is that programmers should strive for as little duplication as possible, taking advantage of existing code. This principle leads to many key programming practices, one of which is broadly familiar: Don’t reinvent the wheel. Capitalize on what’s out there.
So that’s what we did. After we’d decided on WordPress as the foundation of our platform, we started asking how we could extend it by taking advantage of all the actions our bloggers would take elsewhere. Everything from the bookmarks they posted on Delicious to the accounts they followed on Twitter was potentially a wellspring of valuable content. For example, the most popular links among a blogger’s community on Twitter might offer a decent glimpse at the most interesting news developing in a niche.
Back in October, the Nieman Journalism Lab wrote about our link roundup tool, which remains a good demonstration of our approach. It’s a new tool, built for the platform, that seamlessly and efficiently links together existing tools. As Nieman Lab’s Laura McGann wrote:
As bloggers go through their links each day, scrolling through stories and posts looking for the most interesting stuff on their beat, they tag the links using Delicious. Their Delicious accounts are synced up with the Argo’s backend (WordPress modified using Django) to match up the tags. The backend pulls in the links, letting bloggers quickly put together a nice-looking post without all the copy/pasting and formatting.
As McGann’s post describes, this workflow powers more than the bloggers’ daily link roundups. It also elegantly feeds blogger-curated links into the “Latest Links” widgets seen around the site. (Bloggers tag their links in Delicious with “top” to include them in the home page widget, with “roundup” to include them in their daily link roundups, and with names of topics to include them in “Latest Links” on a specific topic page.) Around the site, the widgets blend the blogger’s hand-picked links with others from two potential sources: the most popular links among the bloggers’ communities on Twitter (as determined by TweetedTimes), and on topic pages, links related to the topic (as determined by Daylife).
So you can see how the “capitalize” principle works — minimal input powers maximal output. We exploit an implicit signal such as a blogger’s Twitter community to produce real, user-facing content for the blogger’s site. So far, what I’ve described is a straightforwardly efficient use of resources.
SYNTHESIZE AND HARMONIZE
But behind the scenes, much more is happening, and this is where the “synthesize” and “harmonize” principles come into play. For example, it would have been easy to merely present three feeds of links from Twitter, Delicious and Daylife as three widgets on a page. We felt that would be a poor user experience. Regardless of their origin, all these links were intended to serve the same function — directing users to interesting content in the broader universe of a blogger’s beat. So we decided they should be presented together, in one continuous stream. In other words, we synthesized the links into a single module.
If we stopped there, though, we found the stream would be rife with duplicate links. So Marc Lavallee, Argo’s tech architect, engineered a thoughtful back-end system that recognized each URL, no matter its input. If duplicate URLs came in from Twitter and Daylife, the system was smart enough to record them as one item rather than two. And it ranked them — if a link came in from multiple sources, it was deemed more important. If our blogger had submitted the link — whether through Delicious or directly — that trumped any other input.
All of this harmonization happens under the hood, out of sight of our bloggers and their site visitors.
The capitalize-synthesize-harmonize philosophy has really stood out in our approach to adding functionality to the platform. If you’ve run installations of software such as WordPress or Drupal, you know how easy it is to add plugins. You probably also know how easy it is for plugins to run amok, conflicting with each other, causing errors, slowing down your site and generally behaving badly. To make a coherent platform that could serve users with a range of technical abilities, Marc and Wes ran each new proposed feature for Argo through a rigorous evaluation process.
First, they researched existing plugins to see what already existed. If they found plugins that achieved some or most of the functionality we were looking for, they reviewed the plugin’s structure, behavior and presentation. Plugins that were structurally sound, accomplished what we needed, and didn’t clash with existing parts of the system could be used pretty much as-is. For example, when we wanted to integrate our bloggers’ back-end systems with Google Analytics so they could see information on their site performance, we were able to use the Google Analyticator plugin, without much modification.
Meanwhile, plugins with a mostly solid structure and only slightly problematic behavior could be patched to meet our needs. When we were exploring how to enable our bloggers to produce simple, photo-and-text slideshows for their sites, we were drawn to the Slides for WordPress plugin. It built on WordPress’ default photo gallery functionality to deliver a decent user experience out-of-the box. But we felt the administrative interface wouldn’t work well for our users, and given that large images and JavaScript files could place quite a hit on our site performance (especially on occasions when the tool would be heavily used), we needed to optimize how the tool loaded for site visitors.
CUSTOMIZING THE PLUGIN
So we built a plugin that borrowed what it could from Slides for WordPress, with several adjustments. Wes applied a custom look-and-feel to the front-end slideshows, allowing them to conform to Argo standards. Marc developed some scripts that would enable the site to load the necessary JavaScript only if there were a slideshow present on the page. Because we didn’t want the page to have to load 60-plus images if there were a large slideshow present, we also customized the plugin to load just a few images at first, and load more as users interacted with the slideshow. With a few other customizations — the addition of credit information for each photo, adding the ability for users to link to each image separately — our modified slideshow plugin was ready to go.
If we saw structural issues, or if a plugin’s behavior was largely out-of-sync with our user expectations, we might draw inspiration from it in building our own. From the beginning of the project, we had asked ourselves how we might enable our bloggers to quickly post and excerpt material from elsewhere, in a Tumblr-esque fashion. We liked the way Facebook extracted key information from a URL the moment you pasted it into the input box. The Embed.ly plugin for WordPress was part of the way there, and it led us to explore the Embed.ly API.
Taking these services — Tumblr, Facebook, and Embed.ly — as a beginning, we spent several weeks spec-ing out and building a completely homegrown plugin incorporating the Embed.ly API that we call “Jiffy Posts.” (You can see them in action here; they’re the posts with slightly smaller headlines and italicized excerpts.) So far, the bloggers have responded enthusiastically to Jiffy Posts.
Wes and Marc gave a terrific presentation at a recent WordPress event, called “Plugins Are Blueprints,” outlining our approach to feature development. You can view the slides here.
This is what a content management ecosystem looks like in practice. Almost a decade ago, technologist and commentator David Weinberger referred to the web as “a loose federation of documents — many small pieces loosely joined.” We’re finally developing tools that produce the web in a fashion that matches that ethos. Our platform is steeped in the spirit of the web, and I think that’s served us well.
