Twitter  Apply for a Nieman visiting fellowship to spend a few weeks here nie.mn/1rP8A1Z http://t.co/7RLlctRsQe  
Nieman Journalism Lab
Pushing to the future of journalism — A project of the Nieman Foundation at Harvard

Matt Waite: To build a digital future for news, developers must be able to hack at the core of old systems

Editor’s Note: Matt Waite was until recently news technologist at the St. Petersburg Times, where — among many other projects — he was the primary developer behind Politifact, which won a Pulitzer Prize. He’s also been a leader for the movement to combine news and code in new and interesting ways.

Matt is now teaching journalism at the University of Nebraska and working with news orgs under the shingle Hot Type Consulting. Here, he talks about his disappointment with the pace and breadth of the evolution of coding and news apps in contemporary journalism.

Pay attention to the noise, and you start to hear signal. There’s an awakening going on — quiet and slow, but it’s there. There are voices talking about data and apps and journalism becoming more than just writers writing and editors editing. There are labs starting and partnerships forming. There was a whole conference late last month — NICAR in Raleigh — that more than ever was a creative collision of words and nerds.

It’s tempting to say that a real critical mass is afoot, marrying journalists and technologists and finally getting us to this “Future of Journalism” thing we keep hearing about. I’ve recently had a job change that’s given me some time to reflect on this movement of journalism+programming.

In a word, I’m disappointed.

Not in what’s been done. There’s some amazing work going on inside newsrooms and out, work that every news publisher and manager should be looking at with jealous, thieving eyes. Things like the Los Angeles Times crime app. It’s amazing. The Chicago Tribune elections app. ProPublica’s Docs app. The list goes on and on.

I’m disappointed on what hasn’t been done. Where we, from inside news organizations, haven’t gone. Where we haven’t been allowed to go.

To understand my disappointment, you have to understand, at a very low level, how news gets published and the minds of the people who are actually responsible for the newspaper arriving on your doorstep.

Evolution, but only on the edges

To most journalists, once copy gets through the editors, through the copy desk, and onto a page, there comes a point where magic happens and poof — the paper appears on the doorstep. But if you’ve seen it, you know it’s not magic: It’s a byzantine series of steps, through exceedingly expensive software and equipment, run in a sequence every night in a manner that can be timed with a stopwatch. Any glitch, hiccup, delay, or bump in the process is a four-alarm emergency, because at the other end of this dance is an army of trucks waiting for bundles of paper. In short, it’s got to work exactly the same way every night or piles of cash get burned by people standing around waiting.

Experimentation with the process isn’t just uncomfortable — it’s dangerous and expensive and threatens the very production of the product. In other words, it doesn’t happen unless it’s absolutely necessary and can demonstrably cut costs.

Knowing that, it’s entirely understandable why many of the people who manage newspapers — who have gone their whole professional lives with this rhythmic production model consciously and subconsciously in their minds — would view the world through that prism. Most newspapers rely on gigantic, expensive, monolithic content management systems that function very much like the production systems that print the paper every day. Inputs go in, magic happens, a website comes out. It works the same way every day or there’s hell to pay.

And around that rhythmic mode of operation, we’ve created comfortable workflows that feed it. And because it’s comfortable, there’s an amazing amount of inertia around all of it. Change is scary. The consequences down the line could be bad. We should go slow.

Now, I’m not going to tell you that experimentation is forbidden in the web space, because it’s not. But that experimentation takes place almost entirely outside the main content management system. Story here, news app there. A blog? A separate software stack. Photo galleries? Made elsewhere, embedded into a CMS page (maybe). Graphics? Same. Got something more, like a whole high school sports stats and scores system? Separate site completely, but stories stay in the CMS. You don’t get them.

In short, experiment all you want, so long as you never touch the core product.

And that is the source of my disappointment. All this talk about a digital future, about moving journalism onto the web, about innovation and saving journalism is just talk until developers are allowed to hack at the very core of the whole product. To argue otherwise is to argue that the story form, largely unchanged from print, is perfect and to change it is unnecessary. Hogwash.

The evolution of the story form

Now, I’m not saying “Trash the story form! Down with it all!” The story form has been honed over millennia. We’ve been telling stories since we invented language. A story is a very efficient means to get information from one human to another. But to believe that a story has to be a headline, byline, body copy, a publication date, maybe some tags, and maybe a photo — because that’s what some vendor’s one-size-fits-all content management system tells us is all we get — is ludicrous. It’s a dangerous blind spot just waiting to be exploited by competitors.

I believe that all stories are not the same, and that each type of story we do as journalists has opportunities to augment the work with data, structure, and context. There’s opportunities to alter how a story fits into place, and time. To change the atomic structure of what we do as journalists.

Imagine a crime story that had each location in the crime story stored, providing readers with maps that show not just where the crime happened, but crime rates in those areas over time and recent similar crimes, automatically generated for every crime story that gets written. A crime story that automatically grabs the arrest report or jail record for the accused and pulls it up, automatically following that arrestee and updating the mugshot with their jail status, court status, or adjudication without the reporter having to do anything. Then step back to a page that shows all crime stories and all crime data in your neighborhood or your city. The complete integration of oceans of crime data to the work of journalists, both going on every day without any real connection to each other. Rely on the journalists to tell the story, rely on the data to connect it all together in ways that users will find compelling, interesting, and educational.

Now take that same concept and apply it to politics. Or sports. Or restaurant reviews. Any section of the paper. Obits, wedding announcements, you name it.

Can your CMS do that? Of course it can’t. The amount of customization, the amount of experimentation, the amount of journalism that would have to go on to make that work is impossible for a vendor selling a product to do. But it’s precisely the kind of experimentation we need to be doing.

Building from the ground up

The prevailing notions in newsrooms, whether stated explicitly or just subconsciously believed, is this print-production mindset. Stories, for the most part, function as they do in print — a snapshot in time, alone by itself, unalterable after it’s stamped onto a medium and pushed into the world.

What I’ve never seen is the complete counter-argument to that mindset. The alpha to its omega. Here’s what I think that looks like:

Instead of a single monolithic system, where a baseball game story is the same as a triple murder story, general interest news websites should be a confederation of custom content management systems that handle stories of a specific type. Each system has its own features, pulling data, links, tweets and anything else that can shed light on the topic. Humans + computers. Automated aggregates where they make sense, human judgment where it’s needed. The home page is merely a master aggregation of this confederation.

Each area of the site can evolve on its own, given changes in available data, technology, or staff. It’s the complete destruction and rebuilding of every piece of the workflow. Everyone’s job would change when it came to producing the news.

Crazy, you say? Probably. My developer friends and readers with IT backgrounds are spitting their coffee out right now. But is it any more crazy than continuing to use a print-production approach on the web? I don’t think it is. It is the equal and opposite reaction: little innovation at the core vs. a complete custom rebuilding of it. Frankly, I believe neither is sustainable, but only one continues at mass scale. And I believe it’s the wrong one.

While I was at the St. Petersburg Times, we took this approach of rebuilding the core from scratch with PolitiFact. We built it from the ground up, augmenting the story form with database relationships to people, topics, and rulings (among others). We added transparency by making the listing of sources a required part of an item. We took the atomic parts of a fact-check story and we built a new molecule with them. And with that molecule, we built a national audience for a regional newspaper and won a Pulitzer Prize.

Not bad for a bunch of print journalists experimenting with the story form on the web.

I would be lying if I said that I wasn’t disappointed that PolitiFact’s success didn’t unleash a torrent of programmers and journalists and journalist/programmers hacking away on new story forms. It hasn’t and I am.

But I’m not about to blame programmers in the newsroom. Many that I talk to are excited to experiment in any way they can with journalism and the web. The enemy is what we cling to. And it’s time to let go.

                                   
What to read next
lippmann-house-990
Ann Marie Lipinski    July 24, 2014
The Nieman Foundation for Journalism at Harvard wants to hear your idea for making journalism better. Come spend a few weeks working on it in Cambridge.
  • Pingback: Hacking the core | Hot Type Consulting

  • http://www.thewayoftheweb.net Dan Thornton

    Totally agree. A few years ago I suggested creating a major media site by using a modular approach to open source tools, but sadly it was never pursued…
    Luckily I’m now in the position of creating some of my own sites, and it’s the exact approach I’ll be taking as they hopefully continue to grow and evolve!

  • Anonymous

    One other reason for reluctance is that some of the newer, better ways to do journalism take the spotlight away from the writer and put it on the data. Sexy to journonerds but not to writers.

  • Jonathanstray

    I agree wholeheartedly with this. Another point to ponder: algorithms which handle information on the public’s behalf are necessarily editorial. Google finally said this out loud, when Matt Cutts noted that “our editorial judgement” is “expressed via algorithms.” Perhaps news apps can be thought of as a sort of “story-specific search engine.” Our job as journalists to get create the possibility of a rapid and accurate understanding the world. Today, that means far more than narratives.

    – Jonathan

  • http://www.facebook.com/sdupton Sean Upton

    Absolutely, the idea of confederation of loosely coupled systems protects innovation from incumbent interests, along with protecting the less risk-tolerant parts of business from the places that need to take them. The biggest conceptual leap for tech folks is that this requires some ways of thinking about identification of things (UUIDs, URIs, composed keys of system+identifier) and system-neutral indexing relationships among things. As a skeptic who doesn’t trust any CMS to hold and maintain these relationships correctly, it seems like it would be easier to build something like this if there was some kind of federated glue REST service that could be utilized by multiple CMS, site, and publishing systems (think something like Apache Solr, but for indexing and storing relationships, and querying transitive chains of relationships among items).

  • Pingback: » To build a digital future for news, developers must be able to hack at the core of old systems » Nieman J ournalism Lab » Pushing to the Future of Journalism Media Strategery

  • http://twitter.com/ChrisLKeller Chris Keller

    Thank you for saying what so many of us have thought for so long…

  • http://stdout.be/en/ Stijn Debrouwere

    “The amount of customization, the amount of experimentation, the amount of journalism that would have to go on to make that work is impossible for a vendor selling a product to do.” To some extent, yes, though a CMS with enough extension points (a plugin system, an API, webhooks, whatever) could fit into a broader news product like the one you describe, Matt.

    The reason such flexibility to mesh a CMS with more app-like functionality isn’t happening, and the reason all news (and regular) CMSes are still based around that big ol’ blob of text has more to do with the fact that vendors are basing their product on the feedback they get from executives at news organizations than with technical impossibility.

    News execs, as a rule, don’t care about structured information, database applications and new story forms. They might smell some money in new story forms and new ways to engage an audience somewhere down the line, but not enough and not soon enough to put serious money into any such system. So what’s the incentive for vendors to build anything like that?

    It needs to get worse before it’ll get better, I think.

  • http://twitter.com/tbarkow Tim Barkow

    It does seem crazy at first, but consider the alternative: building a new, uber CMS to handle all these editorial cases, import feeds, provide access to databases, serve up pages to mobile devices, customize workflows, etc. etc.

    It’s been tried a thousand times, and it doesn’t work. Even the best-thought-out systems will be obsolete by the time they are finished (I know, I’ve tried :). Millions of dollars will be wasted in the building — and the waiting.

    The best approach is to hack up what you need as you go. There is a wealth of free tools and affordable services out there that boggle the mind. And more are being invented every day.

    You need a good plan and a clear vision, but let the technical guts be messy. This is a time of learning and reinvention — give the entrepreneurs the reigns and leave the managers behind.

  • http://www.john-zhu.com/blog John Zhu

    I like the interesting concept of a news site being a confederation of CMSes, each tailored for a specific story type. However, I feel like there are actually two separate issues here: re-inventing the CMS for a news website, and re-inventing the story form for a news website. On the latter, here’s what I’d argue: The given example of how a crime story would be presented actually does not really address the problem of breaking out of traditional story form. In fact, the way Matt describes it, I can easily envision how that automated, data-driven system can be created without really disrupting the traditional print-production routine and mindset or busting up the traditional story form, because nothing this system does requires NOT WRITING a story.

    A newspaper may have the resources to hire a team of programmers and let them loose on building this system, but in the end, all of their efforts would still, in essence, be experimenting on the fringes because they’re still not doing anything to what the traditional newspaper mindset considers to be the core product — the story. Hey, add all the automated, data-driven flourishes you want, especially since they don’t require any extra work for the reporter, but until an editor says, “No, I don’t want a 15-inch story on X. Let’s build/we already have built something to present X in a different, better way,” and says that on a daily basis, the automated system will still be peripheral to the traditional story form. You want to plot locations mentioned in the story on a map? Knock yourself out. You want to tell the reporter to not write a story because all the information in it is/can be presented in a better way? That’s insanely more difficult.

    The idea of busting up the traditional story form is not new. It was a hot topic in the 90s and early 2000s as newspaper designers pushed alternative story formats — more infographics, more data visualization, and less prose. There are many anecdotes of success in that effort, but when you consider the fact that the overwhelming percentage of newspaper content remains in traditional prose form, it illustrates the problem. The alternative-story-format approach gained a place in the newsroom, but it could not supersede or even stand on equal footing with the traditional story form. There’s a big game tomorrow? What’s going to be your preview piece, a story or an infographic? Every editor would say preview story, many will say both, but very, very few will say just the infographic. The alternative format remains mostly supplementary, and that could easily be the way for web news products, in which case you can build as many CMSes as you want and still be on the outside looking in where it matters most.

  • http://twitter.com/wcp City Paper

    We’re pursuing a sort of federated system at Washington City Paper, where I’ve been methodically breaking the CMS apart into a set of independent applications, joined together by another application that essentially provides a templating service. A lot of the inspiration comes from Django and HMVC web frameworks. It’s tricky, interesting work. Each of the examples cited above reminds me of the ways data structures can surprise you as more data accumulates.

    This article has much in common with what Holovaty wrote in his influential 2006 call to arms “A fundamental way newspaper sites need to change.” I also wish we’d seen more change in the intervening period, but the scope of work is pretty significant.

    Like Sean Upton, I’m skeptical of CMSes and I believe a set of interconnectable APIs is the most promising direction for making things more flexible and easier to change. I also agree with Tim Barkow – hacking as we go has often yielded better results than trying to design every detail in advance. It doesn’t matter if you call this agile development or don’t call it anything at all. The best advance planning is planning for the things to change, and for rules to be broken.

    One thing I’ve observed is that classic narrative “stories” are still so ubiquitous because they work when data doesn’t. Did your developer design data relationships that don’t tell the whole story, or mangle some nuance of it? Narrative will get you around that, on deadline. Narrative is Perl of journalism. You can glue anything together with it. Given how understaffed many media outlets are these days, it’s not surprising to find people trying to get the job done with the tools they have. Journalists and writers can do as much with a single as many web developers (and designers) can do with a whole database. Okay…in an ideal situation, that’s hyperbole, but not when you consider the typical developer-to-journalist ratio.

    Any system we build to support new story forms should respect the power and flexibility of narrative. Figuring out when to use programming glue and when to use narrative glue is a big part of the work we need to do to make cooler, better news apps.

  • http://twitter.com/wcp City Paper

    We’re pursuing a sort of federated system at Washington City Paper, where I’ve been methodically breaking the CMS apart into a set of independent applications, joined together by another application that essentially provides a templating service. A lot of the inspiration comes from Django and HMVC web frameworks. It’s tricky, interesting work. Each of the examples cited above reminds me of the ways data structures can surprise you as more data accumulates.

    This article has much in common with what Holovaty wrote in his influential 2006 call to arms “A fundamental way newspaper sites need to change.” I also wish we’d seen more change in the intervening period, but the scope of work is pretty significant.

    Like Sean Upton, I’m skeptical of CMSes and I believe a set of interconnectable APIs is the most promising direction for making things more flexible and easier to change. I also agree with Tim Barkow – hacking as we go has often yielded better results than trying to design every detail in advance. It doesn’t matter if you call this agile development or don’t call it anything at all. The best advance planning is planning for the things to change, and for rules to be broken.

    One thing I’ve observed is that classic narrative “stories” are still so ubiquitous because they work when data doesn’t. Did your developer design data relationships that don’t tell the whole story, or mangle some nuance of it? Narrative will get you around that, on deadline. Narrative is Perl of journalism. You can glue anything together with it. Given how understaffed many media outlets are these days, it’s not surprising to find people trying to get the job done with the tools they have. Journalists and writers can do as much with a single as many web developers (and designers) can do with a whole database. Okay…in an ideal situation, that’s hyperbole, but not when you consider the typical developer-to-journalist ratio.

    Any system we build to support new story forms should respect the power and flexibility of narrative. Figuring out when to use programming glue and when to use narrative glue is a big part of the work we need to do to make cooler, better news apps.

  • http://www.niemanlab.org/ Joshua Benton

    For anyone who isn’t familiar with the Holovaty piece he’s referencing:

    http://www.holovaty.com/writing/fundamental-change/

    Great discussion going on here, everyone.

  • Pingback: Popular on Twitter: James Fallows’ new media love, Matt Waite’s old media hack and TBD’s candy jar » Nieman Journalism Lab » Pushing to the Future of Journalism

  • Anonymous

    And since Stijn didn’t pimp his work here, I’ll do it for him. His series “Information Architecture for News Websites” is the best, most thorough expansion and update of Holovaty’s ideas that I’ve yet to run across. Everybody working in digital journalism should read it.

  • http://www.facebook.com/matthew.waite Matthew Waite

    Great discussion, y’all. Really gratifying to see.

    Holovaty’s blog post was immensely influential on me as I was developing PolitiFact. The whole notion of bringing structure to journalism is key to all of this. But that post was almost five years ago now. Yes, the ideas in it are sweeping, but is change so hard that we still have but a few examples of what that kind of thinking a can do? Technologically, it’s not, which is why it’s clear there’s other forces at work.

    And I agree with you, John, Tim and Stijn, which is why I think this may be a lot more about wetware than it is software. That when I say fundamental rebuilding, I mean from the very beginnings of our assumptions of how news gets done. That said, are many of those assumptions going to survive? Yes, in some form or another. As Will points out, the traditional narrative story is still awfully damned good at presenting information.

    I’m not foolish enough to believe that I have found The Way and everyone should run out and do what I say. But I’d like to see more of an argument — for people to take the pretty widely held believe that that the web is fundamentally different than print and really explore — in actions, not words — what that means.

  • http://www.niemanlab.org/ Joshua Benton

    Is there a better example of this idea in action than at the bigger/better sports sites, where stories treat players, teams, games, etc. as linked data resources, and non-”stories” (blog posts, most obviously) can link into the same data resources as stories?

    It also leads to cross-platform reusability, where age-old baseball stats can be turned into the Pennant iPad app and Stats Inc. can easily answer questions like “Has any NBA forward ever hit 9 straight three-pointers in the fourth quarter of a playoff game?”

    In that case, there’s a clear, definable, easy-to-understand use case for that structured data. I wonder if the (relative) absence of that for other subjects/beats is part of what’s holding back the movement.

  • http://twitter.com/eyeseast Chris Amico

    The more I think about the problems Matt talks about, from a technical perspective at least, the more I’m inclined toward many systems, loosely coupled. I like the sound of Federated REST.

    There is simply never going to be a single CMS that does everything we want, nor should we be aiming for something like that.

    What I like about what (I think) Matt is getting at is trying to break down the need for centrally-managed, impenetrable and inalterable production processes. Getting away from the One True CMS is a step towards that.

  • http://www.facebook.com/matthew.waite Matthew Waite

    This is a simplistic idea, and it tracks the baseball idea pretty well, but it’ll work for sake of discussion: Let’s play pretend that we’ve created PolitiFact style promise databases for the politicians we cover, and we’ve linked that politician to elections data for each race the politician has run, and we link campaign finance data to that politician, and voting records, and in our politics CMS, with every story we write about that politician, we can link it to the person, the promise, the vote and the election, where applicable. Also, lets say we have some kind of flag and field in the story that says This Is a Significant Milestone Story and give us a summary paragraph why. Now lets pretend we’ve been doing this for a couple of elections now, and the local mayor that we’ve been following through her election to the state senate is now running for governor. At the moment of her announcement, we have a pretty massive corpus of news, data and information at our disposal that could tell you an awful lot more about a candidate for governor than a single announcement. A corpus that would grow in usefulness with every single story that was written or database that was updated. So we can create contextual content about electoral support, about common themes to promises across political offices (i.e. does this person promise the same talking points each election?), about financial support, about significant votes, and about significant moments in this person’s career, taken straight from our archives.

    Structuring the data and adding more data and annotating it and connecting it is about extracting maximum value out of the information that’s gathered every day. Newspaper archives are absolutely loaded with valuable information, but it’s trapped in unstructured text. There’s a lot of effort underway to extract meaning and structure from unstructured text and it’s all very cool and interesting, but what if we approached it from the other direction? Instead of having to extract meaning after the fact, what if we started with structured information as part of everything we did?

  • http://twitter.com/derekwillis Derek Willis

    The relative absence of the data is not the main problem. As Matt said, that’s a technical challenge and can be solved. The main problem is getting people to understand and value the utility of information in non-narrative forms. I’d like to say that it’s not a zero-sum game, but I’d be lying if I didn’t think that many people would see such a move as “subtracting” from the dominant story format.

  • http://www.holovaty.com/ Adrian Holovaty

    Hey, as the guy who wrote that back in 2006, I’ve gotta agree with Matt’s premise here — we haven’t seen nearly enough movement in the journalism world.

    Frankly, I don’t think the situation in mainstream news organizations will improve much. It’s only a matter of time before startups start implementing these new systems, building their own audiences and leaving traditional companies in the dust. (I’m biased. :-) ) I’d encourage any journalist interested in this stuff to start his or her own thing — it’s liberating and much more fun!

    Adrian

  • http://www.holovaty.com/ Adrian Holovaty

    Hey, as the guy who wrote that back in 2006, I’ve gotta agree with Matt’s premise here — we haven’t seen nearly enough movement in the journalism world.

    Frankly, I don’t think the situation in mainstream news organizations will improve much. It’s only a matter of time before startups start implementing these new systems, building their own audiences and leaving traditional companies in the dust. (I’m biased. :-) ) I’d encourage any journalist interested in this stuff to start his or her own thing — it’s liberating and much more fun!

    Adrian

  • Mark Poepsel

    But I think this is the root of the miscommunication. From data to info is one step, but info curation is a great job for great writers to do, and it always will be.

    Share the spotlight, save the world.

  • Mark Poepsel

    But I think this is the root of the miscommunication. From data to info is one step, but info curation is a great job for great writers to do, and it always will be.

    Share the spotlight, save the world.

  • http://twitter.com/jamesgoffin James Goffin

    I can see the attraction of this, but when you talk about things happening “automatically… without the reporter having to do anything” you sidestep one of the biggest issues here.
    Reporters really struggle with the value of data and see filling in forms as getting in the way of doing their job, not helping them do it. We require all our stories to have at least one geotag and that is perceived as a massive imposition by some – and I dread to check how accurately it’s done.
    Accurately indentifying a specific single human being, as in your crime example, and in a way that it is simple and quick is incredibly difficult.
    Loosely built systems are attractive until you consider that crossing your crime details with your politics details to see the dodgy past of a candidate would be really handy; but how do you do that if they have separate ways of recording the same data?
    I’m excited by the possibilities of a more semantic approach, but I think narrative storytelling will remain dominant not because of some intransigence by short-sighted middle managers but because it’s often the simplest of curating both for the writer and the reader.

  • http://www.communitybandwidth.ca/ phillipadsmith

    One example that comes to mind that’s not sports:
    http://www.bbc.co.uk/blogs/bbcinternet/2010/06/a_history_of_the_world_develop.html

    That said, a lot of the BBC’s ideas here around semantic data and their CMS are quite enlightening in the context of Matt’s piece:
    http://www.bbc.co.uk/blogs/bbcinternet/2010/07/bbc_world_cup_2010_dynamic_sem.html
    http://www.bbc.co.uk/blogs/bbcinternet/2010/07/bbc_news_websites_content_mana.html

  • http://twitter.com/zacechola Zac Echola

    You can definitely standardize how data are stored, even across multiple systems, but you have to take a good look at what you have first and you have to expect that it’s going to get messy sometimes on the edge cases. At FCCInteractive, we’ve set our eyes on Apache Solr (mentioned earlier in this thread) recently to help deal with this problem, but by also building a REST API on top of it. It’s early in those talks, but it could help give us that messy, but singular source of all our data without adding cruft to every input CMS. The general idea is that we use multiple CMSes for data input (Drupal, homebrewed, WordPress, whatever is the best tool for the job, etc.) and kick all the data over to Solr to index it. Then we’d pull data back out of the schema(s) via the APIs.

    Also, if your reporters can’t add geotags, get new reporters. Or at least send them a link to the wiki entry on the tyranny of small decisions.

  • Gkebbel

    I’m really glad we hired this guy.

    Gary Kebbel
    Dean, College of Journalism and Mass Communications
    University of Nebraska-Lincoln

  • http://twitter.com/chriswelle Christopher Welle

    Well Said Zac,

    I may be boiling this down to far but It’s nothing new to tie web services like, gMail, gReader, twitter and wordpress for my personal digital experience – So what we’re gunning for now is a way to stitch the publishing processes across a million micro-aggregation services that can be developed to and experimented with.

    Good times.

  • Eric Newton

    Let’s agree to just about everything being said and expand it into the realm of open government. Why can’t government systems be redesigned so that public information is public from the moment it enters a government computer? Then, the data for much of what Matt is talking about and what Adrian has been doing would be there on a scale not previously pondered. These are our government systems, by the way, and it is our data, and we shouldn’t have to ask for it and risk not getting it when in the digital universe it can be public from day one. Eric Newton, Senior Advisor to the President, Knight Foundation

  • http://twitter.com/reginaldchua reg chua

    Great post. CMSs are a big part of the problem, but I think the main issue is cultural. Despite running a 250-person newsroom, and wanting to do more in this direction, it’s a hard slog to move the meter even a little. It’s tempting to say we should just fire everyone who won’t play ball (and I’ve been tempted) and bring on a new team, but at most MSM newsrooms we’re still trying to turn out an old-fashioned newspaper at the same time. Not an excuse – in fact, a sad reflection on a pretty sorry state of affairs – but an unfortunate truth.

    One small step I think most newsrooms could take relatively easily is building databases of people and relationships. Almost all stories involve people, and getting reporters across the newsroom to input data each time they file, while probably difficult, seems doable. And I suspect those databases, if built properly and maintained well, could be valuable and hence encourage execs to invest more.

  • Pingback: Liens vagabonds (10 mars) » Metamedia | La révolution de l'information

  • Pingback: The Things That Tell Us What Is True (A Little Research Manifesto) « J-School: Educating Independent Journalists

  • Pingback: Fallows on Media Disruption: ‘Meh’ | Newspaper Death Watch

  • Pingback: Links you may have missed this week: March 13, 2011 | a curious Yankee in Europe's court

  • Anonymous

    Great post that touches the core of our challenges. When news websites were established some 16 years ago, they naturally had a starting point in the newspaper industry. In Norway, where there were many early adapters and tons of good work has been done, also the non-affiliated web only upstarts, some quite successful, carried the same baggage.

    There is still much valuable experimentation and innovation. But the finance crunch and media troubles, put a halt to many efforts.
    Presently the strongest trend is consolidation around old media ways. Web organizations are being integrated and co-opted under the banner of convergence. Two of the most innovative online news environments, those of VG.no and db.no, are being closed down as separate organizations within their companies.

    While there may be som valid arguments for these measures, they are very likely to slow progress even more.

  • Pingback: Molecular Journalism « (Re)Structuring Journalism

  • Pingback: Jonathan Stray » The editorial search engine

  • Pingback: Why the Future of Journalism Requires More than Personnel Restructuring « It's Not Over 'Til We Hit -30-

  • Pingback: Business Class: Freemium for News? | Daniel Bachhuber's weblog

  • Pingback: Ben Moskowitz » Final MoJo Challenge: People-Powered News

  • http://blog.digidave.org/ digidave

    This is one of the reasons we don’t have bylines at Circa: http://blog.cir.ca/2013/06/14/why-do-circa-stories-lack-bylines/

    TL;DR: Circa stories evolve over time (new bits of data added as story evolves) so no one person owns the story. If it were in an article format – then a byline would make sense.

  • http://blog.digidave.org/ digidave

    I like to think we are doing aspects of this at Circa. I’ve written about it in more detail elsewhere (including mentioning Politifact as an intellectual precursor): http://www.poynter.org/latest-news/top-stories/237862/circa-not-chunk-y-fying-news-but-rather-adding-structure/

    But we’ve only scratched the surface.

    To Matt’s point about Wetware: I would have to agree. Working on the editorial side of Circa has been immensely interesting in terms of questioning assumptions/Sacred cows. At the very heart of this entire notion of structured stories (as opposed to narratives) is a question about what a journalist is supposed to produce.

    If you ask a reporter: “What do you do? What are you supposed to produce at the end of the day?” – a fair answer is “write an article.” End of story right there. It’s the most fundamental thing one produces. It has a start and stop point and it’s the FOUNDATION of everything else in the newsroom.

    It’s technically possible (Circa is working on it from one specific angle me-thinks) but it requires a serious questioning of what a reporters output is. Do they produce articles or do they organize data in the service of a story.