index.md 13KB
title: Membrane: An Experiment in Permeable Publishing
url: http://nytlabs.com/blog/2015/11/05/membrane/
hash_url: 5b919a5c65
This piece originally appeared on Source.
Over the last several months, The New York Times R&D Lab has been thinking about the future of online communities, particularly those communities and conversations that form around news organizations and their journalism. When we think about community discussion, we typically think about comments sections below our articles, or outside forums that link to our content (Twitter, Reddit, etc.). But what comes after free-text comments?
To explore this further, we developed Membrane, which is an experiment in permeable publishing. By permeable publishing, we mean a new form of reading experience, in which readers may “push back” through the medium to ask specific, contextual (and constrained) questions of the author. Membrane empowers readers with two new abilities. The first is that they can highlight any piece of text within the article, select a question they want to ask (e.g. “Why is this?”, “Who is this?”, “How did this happen?”), and submit that question to the newsroom, asking the reporter to give further explanation or clarify. The second is that they can browse–inline–questions that have already been previously answered by the reporter, giving them the benefit of the discussion that has already occurred. When a reader’s question is answered, they are notified, letting them know that the newsroom is paying attention to their feedback. In this way, the article becomes a channel through which questions can be asked, responses can be given, and relationships can be developed.
Our Challenge
While free-text comments allow the reader to express their point in their own words, the individual nature of those comments creates several challenging constraints. First, it means that it’s difficult to understand anything about the aggregate conversation around a piece: what are people most interested in or concerned about, what types of questions are being asked, etc. Second, if journalists want to engage in a comment thread, they have to respond to individual commenters, rather than having any way to respond to an entire topic or an oft-repeated question. Third, they require teams of moderators to keep out off-topic or objectionable content.
Not surprisingly, other publications have been experimenting with alternative forms of incorporating user feedback into the story process and cultivating community. Hearken is a platform by the creators of Curious City that solicits questions submitted and voted on by the public that producers, reporters, and editors then work to answer. Digg Dialog is being developed as a tool for news organizations to make a “two way conversation between writers, editors, and readers.” The Coral Project–a collaboration between the Mozilla Foundation, The New York Times, and The Washington Post, funded by a grant from the John S. and James L. Knight Foundation–is rethinking community engagement around news and is currently working on a project to ascertain which users are most trustworthy. Buzzfeed Reactions are a classic example of a constrained interaction that provides insight into what users find interesting (or OMG-worthy). Several publications have been experimenting with removing comments entirely and shifting the conversation to social media.
Each of the previously mentioned tactics takes a different approach to time (synchronous/asynchronous), constraints on the reader (submitting free text/submitting something more constrained), and juxtaposition with the article (adjacent to the thing being talked about/below or away from the article). We began to wonder what other interactions could exist along these axes. What kinds of interactions might avoid the challenges of free-text comments? How might these interactions shape different kinds of behavior, both among our readers and between readers and journalists? How can we make it easier for newsrooms to understand where people want more context about a particular part of a story, and also provide tools for incorporating that feedback in the article itself? The way we design methods of communication shapes and informs the communities that form around journalism–what alternative kinds of communities can we foster?
How We Made It
Membrane is the result of a series of iterations and prototypes around the ideas of digital text and community. We spent quite a while thinking about how article text is typically treated as a static whole (a larger research project that you can read about here), without interactivity, save for occasional hyperlinks. When we think about adding interactivity, we tend to turn to multimedia, like video, slideshows or interactive graphics. Previous experiments around the potential of digital text in journalism are compelling but relatively rare: ProPublica’s thoughts on sentient articles and their Explore Sources tool, The New York Times’s piece on the best and worst places to grow up, Smarticles, and Tangle being a few examples. We wondered: how could we use the affordances of digital text as the anchor for compelling interactions that elucidate stories and provide context?
Card-Based Context
One of our first prototypes around this idea was an inline card-based interaction. Certain phrases or words in an article would be highlighted, and when the user clicked or tapped on these highlighted phrases, content would appear below the paragraph giving further context on that person, place, idea or event. We realized, however, that this assumed we knew every question our readers wanted to ask. What if they were curious about something we hadn’t predicted? How could we allow them show us where they were curious? And how could we design a system that wouldn’t require extensive moderation to do so?
Questions in the Margin
Our second prototype was a mock-up that visualized the core interaction of what would form Membrane. In this prototype, the user highlighted the text about which they had questions, and
could select a list of questions from a predefined drop-down list. We limited these questions to “who, what, when, where, why.” In this prototype, however, the actual Q&A happening in the article was moved off to the sides, centering the article as the core content and the responses to readers as ancillary to that primary information. We quickly realized that this thinking was still built on a print-oriented understanding of text.
Reader & Response
Our third prototype is what became the current version of Membrane. In this version, there are only two things: “prompts” and “responses.” A “prompt” is any question or feedback submitted by the reader to the reporter, in the form of highlighted text plus a question. A response is any content contributed by an author: the first piece of writing on the subject (which we refer to as the “opening”), an answer to a question, etc. A Membrane piece starts with an opening of any length, which readers can then mark up with prompts. Reporters can select prompts and respond to those prompts with more responses, which readers can also mark up, and so on, creating a tree-like structure that can be explored at any level of depth the reader likes.
What’s Inside
Membrane is written with Go, React, and Mongo. Prompts and responses form the core of Membrane. Each prompt and response keeps track of their parent, allowing us to find all given prompts on a particular response and vice versa. It keeps track of individual readers and their questions, allowing us to notify those readers when their questions are answered. Developers can add their own login systems, or, if they want to keep the barrier of entry low, just use cookies to keep track of users. Rather than building one interface and limiting developers to that, we instead created a full API for prompts, responses, notifications, and users. The API framework allows developers to use our interface if they like or to devise one of their own.
Future Possibilities
Although Membrane was developed in a journalistic context, we quickly realized that we shouldn’t limit our thinking about the technology to just reader/reporter scenarios. The overall interaction we had designed could support far more types of conversations than the ones we initially imagined. Because of this, we were mindful to keep Membrane relatively agnostic to both technical implementation and subject matter (hence “prompts” and “responses” rather than, e.g., “questions” and “answers”). In this way, the project as a proof-of-concept could demonstrate its use in one of the journalistic scenarios we had imagined, while also pointing to larger questions. For example, Membrane has led us to wonder how such systems could function with:
- Different types of responses. A reporter could respond to prompts with text, or they could respond to prompts with images, videos, audio, etc.
- Different types of subject matter. In addition to news articles about people or events, Membrane could be used for ongoing written pieces that are soliciting ideas/next steps from the community.
- Different lengths of time. The community that forms around an author who uses Membrane very consistently would likely look different from the more ephemeral communities that form around a time-constrained event (elections, Oscars, etc.).
- Different types of questions. A writer could use the default “who, what, when, where, why” list of questions, or customize their list with subject-specific questions (Membrane tailored for an article on cooking, auto repair, etc.).
- Different numbers and types of authors. Membrane supports multiple authors, so a piece could be written by just one author or several authors, and support community members who become authors.
- Different forms of interaction. Membrane might be used to get additional detail or source material on a finished piece; to get updates on an ongoing event or situation; to ask for more justification on an opinion piece; to nudge the evolution of an ongoing piece or project, and more.
In this way, Membrane functions both as a prototype on its own, while also prompting thought about how systems like it could support new forms of communication, communities, and journalism.
We will be open sourcing Membrane in the coming months, and look forward to other developers playing with the code and exploring some of these questions. Before that, we’ll be launching a live Membrane experiment, asking some of the most interesting voices in journalism and community building to write pieces with Membrane and engage with readers’ questions. Until then, you can see other New York Times R&D Lab projects at nytlabs.com.