The read-state problem
March 11th, 2010The problem
Google’s Josh Cohen and Search Engine Land’s Danny Sullivan did an excellent job of summarizing the read-state problem in this interview:
Think about it this way. The traditional newspaper reader would get their morning paper, read some stories and be done. The newspaper had no idea what they read. So when writing updates to those stories, the newspaper was forced to assume you knew nothing. It had to get the most important breaking aspects up at the top of a story, writing in “inverted pyramid” style so that if a reader drops off, the less important facts are safely buried further down in the story.
Online papers could be smarter. They could understand what you’ve read, where you left off and keep you informed with only the new material you need, because they’d understand your read state. But online news isn’t written this way. It continues to be produced as if people are reading offline. As Cohen explained:
Every single day I have to put something out in the paper. So there’s an on-going story. Every single day I file another article. A deadline comes in, 6, 7 o’clock or whatever, I file it, and it goes out there because I have to put something out there in the paper.
As a result, often times you have to have a certain set of facts, even if they’re just one little update to that story. It generates a larger story either to fill space or because I can’t just put a quick headline update to it and link back to my other sources to it.
Part of the reason that you see that is, one, there hasn’t been too much innovation in the space. But also because people don’t take into account your read state. So if I know that you’ve come there, I can give you the full story, or I can give you a quick update, a bulletpoint summary. That’s another level of personalization that I think is not there.
Potential solutions
- Google’s Living Stories prototype detects what users have already seen on a living stories page and de-emphasizes that familiar information.
- Apture can determine how much background information users have consumed if it’s provided in an Apture widget.
This is the kind of thinking I’d be 500% more excited and enthusiastic about (and confident that Google, at least, could pull it off) if . . .big if. . .I wasn’t worried about someone reading over my shoulder ,writing it down, and then selling it, handing it over to the government without asking me or requiring a warrant, or allowing it to be hacked with no fear of liability. From a market standpoint publishers don’t need to address this point, I bet (most people don’t care, it hasn’t stopped anything yet–except Netflix Prize II), but from an ethical standpoint I think its imperative.
That said, I think it could be incredibly exciting. Making inferences from things like Wikipedia look-ups and time-spent and scroll patterns (like Robin’s East wind story) could take the “figuring out what you know and what you need to know” to a whole new level of clever.
This really is the nub of the context problem. You can create great backgrounders and explainers and invent all sorts of ways to display them in relation to the news, but every user comes to the story with a different level of knowledge. If they see too much context, they get bored and go away. If they see too little, they get confused — and go away. Everyone says “why can’t journalism be more like NPR’s Giant Pool of Money”? The reason it was a success is not because, as Jay Rosen says, the NPR journalists put themselves in the shoes of the general public. It’s because the financial crisis was that rare story where everyone really was equally confused, and so one well-made explainer hit the sweet spot for an enormous audience.
So if customising the context to the user is too difficult or raises privacy worries, what can you do? The next best thing is to make it really easy for the user to customise the context for herself. The Money Meltdown (http://www.themoneymeltdown.com/) does this well in a very low-tech way by being really easy to navigate. It has several layers of simple-to-understand headings: Background, Key Facts, What’s Next, etc, with well-written sub-sections next to each one. It makes it easy for a user who comes with the question “What do I need to know?” to pick out what she already knows and get quickly to what she doesn’t know yet.
Ordinary wikis fail this test. They are single-layer documents, structured either around a chronology or around a set of relationships between the elements of the story that make perfect sense — as long as you already understand the whole story. Google’s Living Stories, even if it only shows you what you haven’t already read, fails too: it’s just a chronology of news pieces. Apture lets you pick what to surface, but it doesn’t tell you, in a quick and easy overall snapshot, what there is to know so that you can determine what you need to know.
So until a better technological solution comes along, that’s the structure. To tell people what they need to know, first help them figure out what they don’t know.
It’s because the financial crisis was that rare story where everyone really was equally confused, and so one well-made explainer hit the sweet spot for an enormous audience.,
Brilliant comment, imho.
Ordinary wikis fail this test. They are single-layer documents, structured either around a chronology or around a set of relationships between the elements of the story that make perfect sense — as long as you already understand the whole story.
Yes. If it’s going to be self-navigating, it’s all about creative use of structure.