LWN.net Logo

Google releases "Living Stories" code

February 23, 2010

This article was contributed by Joe 'Zonker' Brockmeier.

You are reading a standard-form news article, and when new information comes to light, the piece you're reading might just be referenced in a follow-up — but it won't be displayed in context or be easy to navigate. However, if Google's Living Stories experiment takes off following the release of its code, that won't always be the case.

[NYT NFL Playoffs]

Along with The New York Times and The Washington Post, Google worked on developing a new prototype for displaying news dynamically. The Living Stories project, announced in December of 2009, was an experiment on how to present news coverage online in a dynamic format rather than the staid and unchanging single-story per page mode. The project ran for about two months, and has been highly successful. According to the Google team that worked on the project, the feedback received has been extremely positive — with 75% of the people reporting that they preferred the Living Stories format. More importantly to publishers, who strive to keep time on site as high as possible, the readers spent "a significant amount of time exploring stories."

The problem with the online news

For all of the advances and changes brought about by online publishing, the way that news is reported online has changed remarkably little from print days. The speed of publishing has changed, and readers are able to access information on new and exciting devices: But the actual layout of a news story has remained more or less static.

Standard Web publishing layouts, like print, only work so well for telling ongoing stories. The best most publishing platforms can muster is a set of related links to earlier posts on the same topic. Navigating through this can be something of a nightmare when trying to dig through long-running stories. The standard presentation also leaves something to be desired in terms of seeing what the most current report is for any given topic.

Publishers and content management system designers have put more effort into mirroring the print experience online (making sites much prettier than the early days of online publishing) and paid little attention to how online publishing might better present the information at hand. With any luck, the Living Stories experiment and code release will push the envelope a bit and inspire publishers and developers to develop more efficient and intuitive ways to deliver news and other information.

The Living Stories Format

The page components of a Living Story are broken into four sections: A summary, update stream, timeline, and filter. The summary gives the gist of the topic and helps bring the reader into the story if they're unfamiliar with it, giving just the most important details. In addition, the Living Stories prototype has a navigable timeline that puts the story into context by displaying all the developments in a continuum. Readers can follow along with this and see just the headlines or drill down further into the complete updates at any point in the timeline.

[WaPo DC Schools]

The update stream, displayed in the middle column, shows updates in reverse order. Depending on the importance of an piece in this stream, it can be displayed with a larger or smaller font, or "collapsed" to show only the headline if a given update is of low priority. Major updates can be given more prominence.

Filters allow publishers to associate content with specific themes for readers to filter content by. For example, readers could drill down on specific elements like videos, graphics, quotes, or specific aspects of a story. If an LWN story was put into the Living Stories format, one might be able to filter by specific companies, or licenses, or by topics like distributions and development. This raises interesting questions for journalists as well as developers and publishers: The topics that are chosen as filters can shape the reader's interaction with a story. Someday setting the filters for a given topic on a major news site may be as much a part of the gatekeeping function of journalism as choosing the topics to be covered in the first place.

[Filtered by Quotes]

The final component is the right-hand timeline of events, which also link off to stories that are key elements in the story. Here only the most important pieces might be displayed, rather than every element that might be displayed in the overall stream. For example, if Oracle's acquisition of Sun were laid out as a Living Story, one might highlight some developments in the "Save MySQL" campaign.

Another part of the Living Stories design is to track the user's interaction with a story. On subsequent visits to a page, users would see new information highlighted. According to the data outline the Living Stories package would track users who are logged in and their last visit. It's not clear from the notes whether users would only be tracked if logged in.

So far, the new format has been used to hit a moderate range of topics. The Times used it for stories from global warming to the NFL Playoffs, and the Post test drove the format by looking at school reform in Washington D.C. and the embarrassing season the Washington Redskins just had. The stories are no longer being updated, but the existing content is still up for all to see.

Working with Living Stories

The code is also up for all to see as of February 17. The release is available under the Apache License 2.0, and includes documentation on the data structures, content types, and how to build and run the application. The code is written in Google's AppEngine Java SDK, but it may be possible to run Living Stories using AppScale on infrastructure other than Google's. AppScale allows running Google AppEngine applications on Amazon EC2, Eucalyptus, and on Xen and KVM systems.

The instructions provided so far require Eclipse, Google Plugin for Eclipse, the Google Web Toolkit SDK, and Google App Engine SDK. I didn't have much luck building the code following the instructions, but, to be fair, Java development in Eclipse is not something I have done previously. Perhaps it's user error. However, it was less than encouraging that three days after posting a question to the Living Stories discussion in Google Groups, it had not yet been moderated through to the list. In fact, no new posts have been approved or posted as of this writing (February 21st) since February 17th.

It's possible to get a sense of the workflow for Living Stories even without setting up an implementation. Google provides detailed documentation on the workflow for creating and editing content in the Living Stories Content Manager. Based on the instructions given, the content manager is a bit rough around the edges — at least from the viewpoint of editors and reporters who would have to manually insert the code required for some of the Living Stories features. The data structure and content types available in Living Stories are a bit more complex than the standard content management system. Living Stories allows for eight types of content ranging from Events (details related to the story that don't fit into other content types) to Data (for facts and data related to the story).

The specific implementation may not be as important, however, as the concept. As the core principles and best practices page notes, the package released by Google only represents "one possible implementation of these principles. Any news organization, however, can use the principles as a guide to implement their own version of living stories" as best suits the publication and its audience. With the examples and data structures that the project has developed out for all to work with, it should be possible to adapt the Living Stories concept to other content management systems and for use with all types of content.

Users who aren't looking to deploy on AppEngine may have hope. According to the Build and Run guide, alternate instructions are forthcoming for users who would prefer to deploy Living Stories with Apache and MySQL. I'm eager to see what the community develops based on Living Stories, and a simpler implementation that could be deployed on a standard LAMP setup would be welcome.

Whether the code is going to see much development from Google, the New York Times, or Washington Post at this point is unclear. The post on Google's News blog thanks both publications for their involvement so far, but suggests that the papers are moving away from working with the Google hosted code now that public development has started. The posts from Google so far indicate that the company does intend to keep developing Living Stories for the benefit of other news organizations. As yet, though, no other publications have announced plans to work with Living Stories.


(Log in to post comments)

Google releases "Living Stories" code

Posted Feb 23, 2010 19:33 UTC (Tue) by geek (guest, #45074) [Link]

A couple of points I thought of in reading this. First is the keywords issue:

"one might be able to filter by specific companies, or licenses, or by topics like distributions and development. This raises interesting questions for journalists as well as developers and publishers: The topics that are chosen as filters can shape the reader's interaction with a story"

Well yes. One can view a public library's catalog in this way, too. Cataloging terms are a huge industry already, take a look at Google's results for Anglo-American Cataloging Rules. So your subject terms reflect what part of the catalog you see, how narrow or how broad, etc. I don't know whether the developers were aware of this kind of structural analog but it seems like a clear isomorphism to me.

And I see here a change in what has until now been a key pain in the butt for me personally. I use Google Alerts to filter news stories to me in a daily digest. But if I'm on the road for a couple of weeks, as often happens, I may be separated from my email or web access. Coming back home, it has often happened that the link in my email is now no good. It seems the most common news model has been to post it for a relatively short period, several weeks, say, and if you want access after that window you need to get archive acce$$. Nothing especially wrong with that as a business model (I don't know if it works, am inclined to doubt it) but it doesn't work well for me. But now the stories seem intentionally designed to be persistent. Better by far for me, I can expect (if this model becomes pervasive) to be able to not only follow up on the sequels to the original story but can read the whole timeline and any content that catches my eye.

"Living Stories" starting integration of "news" and "history"?

Posted Feb 24, 2010 4:59 UTC (Wed) by lethargo (subscriber, #26367) [Link]

Sometimes I wish news people would include more historical background in
their news stories, but then I think I am being unfair to them...because
it's "news", if I want historical background maybe I should read a history
book on the subject. I find this "Living Stories" format interesting
because it looks like a merger of news and historical background, at least
in a small way (just the more recent background, and just in a news format.)

Theoretically we could even see deeper background info on subjects included
in this same format along with the news. For example, maybe a story line
about the current Afghan war could include historical info on Afghanistan,
its peoples, and its previous wars, maybe from an encyclopedia.

Interesting stuff.

"Living Stories" starting integration of "news" and "history"?

Posted Feb 24, 2010 9:59 UTC (Wed) by magfr (guest, #16052) [Link]

That in turn suggests that it would be good to have vast background databases available and also have some kind of referrer links so that the background files could aggregate links to other storylines using the same background.

Inside an organization it might even work but on the wider net it probably is a pipe dream as spammers would do their best to destroy the content.

Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds