#000 and #FFF and #FF0000 all over.

Maker Week is an annual tech-sponsored event and an opportunity for many departments (including Data, Product, and Design) at The Times to dedicate one week to innovation, collaboration, and learning.

Our Team

Joshua Shao– Product Designer, Rhode Island School of Design

Anna Kambhampaty Engineer, Cornell University

Lilian Liang– Back-End Developer, University of Washington, Seattle

Mailiis Law– Front-End Developer, University of North Carolina, Chapel Hill

Kat Zhao– Back-End Developer, Duke University

Allyson Young– Front-End Developer, Northeastern University

Zoha Qamar– Data Analytics Engineer, Columbia University

The Problem (and Opportunity)

How can we contextualize Times content for our readers?

A common issue our readers face is that our coverage and stories, though fully intended to help them better understand the world around them, can feel out of reach. The people, issues, and occurrences in the news can feel far removed and, thus, unimportant to the reader. What good is it to know that a trade war is happening, when you don’t know what this will mean for you, why it’s happening, and what you can do to be more cognizant of its effects? So, we ask, how can we get our stories to hit closer to home?

We learned that our readers feel more connected to and a part of the news when they’re able to have meaningful discussions about it with their friends, family, and peers. Engaging with these topics through conversation, in an unscripted manner, allows a person to learn about them from varying perspectives and new lights. After a conversation about an article, a reader is left feeling more connected to the coverage topic, and thus, The New York Times.

When a beneath-the-surface, engaging conversation ensues, people are left feeling like they resonate more with the news and current issues. How might we, then, facilitate this initial, in-person interaction?

Sprint Process

The first two days of our week were spent in a sprint workshop with Jake Knapp, author of Sprint: How to Solve Problems and Test New Ideas in Just Five Days. Jake spent 10 years at Google and Google Ventures, where he created the Design Sprint Process. This past week at the Times, he led several teams through the Map, Sketch and Decide steps of the design sprint, and finished with guidance on prototyping and testing (massive thanks, Jake + team!).

The Brainstorm

After researching what other media companies were doing to solve similar issues and talking to readers, our team went through a series of brainstorming exercises, guided, mainly, by the question of “how might we facilitate an initial, in-person interaction between readers?”

Some of Our Initial Ideas:

  • A forum feature for coverage topics
  • Geographic feed
  • A push notification that lets you know when a high number of people in your area are a certain article
  • A “news club” type feature, where users can create groups with their friends and send each other hand-selected articles every week which get sent out in an email newsletter form
  • Creating user profiles on the NYT app with following, adding, and messaging affordances

Market Research & Analysis

What are other players in the industry doing? In what ways does it work and in what ways does it not? Who even are the other players?

In an age where the power of news distribution has shifted from the hands of journalists to those of social media giants, we see an urgent need to recalibrate this new and unimproved delivery of information for the sake of integrity and the truth. News curators do not have the same interests in mind as news creators, and forfeiting the gateway to news to monopolizers like Google or Facebook successively surrenders critical journalistic duties — from tackling misinformation to citing only credible sources — to companies proven serially negligent and irresponsible to such concerns.

The amount and magnitude of lawsuits associated with social media and search engines speak for themselves. Recently, the European Union’s General Data Protection Regulation fined Google a whopping, record-breaking $5.1 billion, reprimanding the company for its abuse of personal data and parallel issues. It’s also slamming Facebook with a similar suit that racks up around the same price. The beginning of 2018 further featured the unleashing scandal of Facebook and Cambridge Analytica, a disaster that proved meddling in the 2016 Presidential election and kindled concerns for political integrity and personal privacy going forward.

That merely scratches the surface of how unabashedly tech giants have flirted with questionable morals and heedless concern at the expense of its users.

Yet all that being said, news on social media does carry a more personalized tone, and search engines do a similar job. By offering to people what those around them are consuming, these sites sharpen an often overwhelming slew of daily news into an approachable, digestible set of stories that people they know read, care about, and discuss. Despite the grave unease with these platforms, 93% of Americans obtain their news online, with the majority citing Facebook and Google as their specific sources.

With this in mind, we wanted to emulate the constructive elements of news and social media by pursuing the idea of a social reading feature. By allowing people to understand what others in their social and geographic circles alike are reading, our solution echoes the ability to show readers news that will resonate.

To note, we chose specifically to pursue a social reader, not necessarily a social “writer.” While we acknowledge the conversations that social media sites can yield from news articles, there is also a chronic concern that people often aggressively comment (as well as react or share) on article posts without even reading the piece, which can unleash online arguments associated with an article amongst users who barely or did not at all read it. We hope our application encourages a more informed consumption of journalism, and we believe that this sort of knowledge is cumulative and pervasive — that conversations in real life involving our readers will be more informed and constructive due to more reading and, hence, substantial understanding of the world at large. Our project aims to engage readers in news — not just in clickbait headlines or spicy captions.

Our Solution & Prototype

We decided to take a triply-pronged approach to solving the issue at hand, involving the following three features:

  • Reader Visualization: map visualization of an article’s readers
  • Social Caption (SoCap): caption indicating friends that have also read an article
  • Community Feed: feed of articles your friends have saved or shared

Why these three features? Read on!

The Reader Visualization

The geographic reach of an article can expose an underlying framework of understanding for the issue at hand.

Prototyped using D3.js.

The reader visualization is a heatmap that pops up at the bottom of an article, below the sharetools. Our aim with this tool is to let readers (and, of course, our very own editors and journalists) know who else is reading and where, in real time. Understanding this can provide context around who may care about the topic of the story and who is missing the coverage. We also hope it can reveal some surprising patterns of readership we may not be able to see otherwise.

The Social Caption

The first step in talking about the news- knowing the people you interact with have also read it.

The social caption is a small line of text placed at the top of the article that lets a reader know, subtly, so as to not detract from their reading experience, who else in their immediate social media networks have also read the same story. This feature aims to give readers the additional knowledge of who else in their circles have consumed the same content, so, the next time a reader sees one of them, they can bring up the fact that they both have read the same story. Or, a conversation will start based of that knowledge of mutual readership. Hopefully, this will initiate a meaningful discussion.

We want to make it clear to readers that The New York Times will be using their Facebook friends list for the Social Caption. Readers will have the option to opt out of this feature should they not feel comfortable giving this information. We think it is important to give readers agency over how much information they want NYT to see.

The Community Feed

What news are you missing that the people around you are reading?

This feature, going hand-in-hand with the social caption, is a feed of stories that will be placed in the menu of the news app. The feed will be populated by articles that are being read and are popular in the user’s specific social circles. This is aimed at bringing to the reader’s attention what their friends, family, and acquaintances are reading that they may not have seen or heard about in the first place.

These three additions to our reader experience provide more context about who around the world is reading the news, who in your circles is reading the same stories you are, and what stories people in your circles are reading that you may not have known about at all. Together, these three features provide the reader with a geographic and social lens to view and talk about news. We believe, to facilitate more meaningful conversations about news and further a reader’s understanding of the coverage, both geographic and social understandings are necessary.

Technical Briefing

What we need to implement and how

Facebook User Data

In order to access a user’s friends, we need to pull data from Facebook’s Graph API. Getting set up with this API is pretty straightforward — register our application with Facebook for Developers, and include the following script in the project’s index.html:

Courtesy of Facebook for Developers

The Graph API is structured as a network of nodes and edges, where each user is a node and their “traits” are the edges coming out of the node. The User Friends edge returns a list of User nodes for the friends of the original User, and can be accessed by hitting an endpoint /{user_id}/friends. Access to this endpoint requires an additional permission, “user_friends,” which must be requested from the User during the authentication process.

Facebook authenticates apps using the standard OAuth2 procedure, so once a user grants permission to the New York Times through a login process, a token is returned which gives access to that user’s information.

The OAuth2 procedure is roughly illustrated by this graphic.

After SoCap gets the Facebook User data, it can make a POST request to the internal Who’s Reading API to create a new user endpoint which serves a list of that user’s friends. This user endpoint will also hold a list of articles the user has read. In addition to keeping track of users, the Who’s Reading API will also have an endpoint for every NYTimes article, which stores a list of all the users who have read the article. The follow is an example of the response from GET requests to an article endpoint and a user endpoint:

On the Home Page, the app will need to pull data from the API endpoints of the user and each article, and find the intersection of the article readers and the user’s friend to display in the Social Caption UI. When a reader navigates to an article page, the app should fetch just the reader list for that article and compare it to the user’s friend list, feeding the entries which are present in both lists to the Social Caption UI. Lastly, for the Community Feed feature, the app will go through the user’s friend list and get the “articles read” list for each friend. These articles will then be sorted by date, with the most recent ones populating the Community feed.

To make this process efficient, the app should implement a cache of the user’s friends which is updated automatically every 24 hours. Users’ Facebook friend lists don’t change very frequently, so this will reduce the number of API requests needed to get and display user data without sacrificing performance. For the community feed, it could also be extremely slow to sort through the article data for each of a user’s friends, so developing a system for choosing the user’s most “relevant” friends is necessary. By only getting articles from these sources, the requesting and sorting processes become much more practical to implement.

Map Data

We used data from internal databases to get the number of clicks by state for a particular article. We recognize that the number of clicks is not an exact measurement of the number of users reading an article but we thought it was a good approximation to start with with the data that we could find.

In the future, we would like to visualize the number of readers by state for a particular article. We also hope to expand this visualization to other countries instead of just focusing on the U.S. We decided to focus on the U.S. first because the majority of the Times’ readers are here.

Story Implementation

For implementation in Story, the social button icon lives in the shared folder in ‘Share Toolbar,’ making it parallel to sharing on Facebook, Twitter, or via email. The social map visualization lives in the bottom class share tools. Clicking a link prompts the expansion of the visualization onto the bottom of story page — below Print Information and above Recirculation. The clicking of this expansion loads the data of the visualization so that the article loading is not disrupted.

Potential Issues & Moving Forward

Moving forward, there are two main issues that we would like to address-

  • Privacy
  • Measuring the real-life interactions

The potential privacy issues when using the Facebook Graph API in implementing SoCap have been on our minds throughout this whole project. Because the Facebook Graph API is not an internal API, we are not sure how much information Facebook would see about our readers. We are concerned that using this API would allow Facebook would be able to keep track of every Times article that the reader has read, as well as everything her friends have read. This would be especially concerning if it also include Times articles that were not read through Facebook. While using the Facebook Graph API gives us the convenience of accessing a reader’s social network, it could potentially sacrifice privacy. If we are not willing to sacrifice privacy by using Facebook, then another approach would be to build a “social network” within the Times where readers could follow other readers.

The second issue is finding a way to measure the interactions that result from this feature. We currently do not have a way to track whether or not adding more context actually results in more interactions outside of reading the article. One potential solution is to implement an additional “call-to-action” feature in the article, such as suggesting that a user shares this with other friends.

In the future, we would like to build this internal “social network” infrastructure so that we would not need to rely on the Facebook Graph API. We would also like to build a “call-to-action” feature that would allow us to track further interactions outside of reading the article.

Thanks for Reading!

We hope you found our research and process to be insightful. If you’ve made it this far in reading, we’d like to thank you and encourage you to reach out with any questions, concerns, and further musings!



Source link https://uxdesign.cc/new-york-times-maker-week-2018--reading-557f96898923?source=rss—-138adf9c44c—4

LEAVE A REPLY

Please enter your comment!
Please enter your name here