I came across
this op-ed in
The New York Times that you should take a look at. The op-ed's co-authors -- Betsey Stevenson and Justin Wolfers, assistant professors of business and public policy at the University of Pennsylvania -- say most journalists who reported on the
new divorce data released a couple of weeks ago got the story wrong:
The story of ever-increasing divorce is a powerful narrative. It is
also wrong. In fact, the divorce rate has been falling continuously
over the past quarter-century, and is now at its lowest level since
1970. While marriage rates are also declining, those marriages that do
occur are increasingly more stable. For instance, marriages that began
in the 1990s were more likely to celebrate a 10th anniversary than
those that started in the 1980s, which, in turn, were also more likely
to last than marriages that began back in the 1970s.
Why were so
many analysts led astray by the recent data? Understanding this puzzle
requires digging deeper into some rather complex statistics.
The
Census Bureau reported that slightly more than half of all marriages
occurring between 1975 and 1979 had not made it to their 25th
anniversary. This breakup rate is not only alarmingly high, but also
represents a rise of about 8 percent when compared with those marriages
occurring in the preceding five-year period.
But here’s the rub:
The census data come from a survey conducted in mid-2004, and at that
time, it had not yet been 25 years since the wedding day of around 1 in
10 of those whose marriages they surveyed. And if your wedding was in
late 1979, it was simply impossible to have celebrated a 25th
anniversary when asked about your marriage in mid-2004.
If the
census survey had been conducted six months later, it would have found
that a majority of those married in the second half of 1979 were
happily moving into their 26th year of marriage. Once these marriages
are added to the mix, it turns out that a majority of couples who tied
the knot from 1975 to 1979 — about 53 percent — reached their silver
anniversary.
Al's Morning Multimedia: Interactive Elections CoverageLast
week, Poynter hosted a group of journalists who cover politics for TV,
newspapers and online sites. While teaching in the seminar, I talked and learned about newsrooms that are using online interactives to tell political
stories.
One new invention blew me away. It may change the way we think about how to display videos online -- especially longer videos like speeches, debates and such.
Look at this
New York Times project, which includes a video of last week's debate. It also includes the text of the speech. As you click on headlines, the video and transcript fly
to that point in the debate so you can see and hear what
you are interested in. Awesome.
Now try something even cooler:
Click on the "Transcript Analyzer" tab, and type a word into the search box.
Try "Iraq," for example. You will see how many times the word was
spoken by each candidate. If you scroll over the tiny black boxes plotted out under the "Transcript" header, you can read the script. Absolutely amazing.
Via e-mail, I interviewed three of the people involved in this remarkable project. Tom Jackson handled the transcript analyzer, Gabriel Dance worked on the video analyzer and Lisa Tozzi oversaw the project. Lisa didn't want me to use photos of the three of them because she said so many others were also involved in this collaborative effort.
Lisa writes:
Here are a couple things we were hoping to achieve with this: At the most basic level, we try to give people a chance to see the highlights of the debate who might not have seen it. But there are always questions that follow an event like this, such as what were the"big moments," who got the most airtime, which subject got the most attention, etc. I think this allows people to see these things for themselves and also look for their own interesting patterns.
Part of the genesis of this was a feature that started in the paper a few years ago with State of the Union addresses, where we looked for patterns in the president's speech. Last year we moved this to the
Web. Our deputy graphics editor Matt Ericson created the feature.
I think that people do understand how to use this -- thanks to Gabe and Tom and Shan and Matt's excellent work on the interface. It is clear and easy to use.
I think this tool will have a number of other uses. Obviously we're looking to the Oct. 9 Republican debate -- but we definitely have other plans for it.
I asked Gabriel about the video analyzer:
Q. Give us a sense of the planning that went into this.
A. This idea originated quite a while ago (seven months or so). At the time, Shan Carter, Andrew DeVigal and I were considering using it for a different project, and we had built out a smaller proof-of-concept that was enough to generate excitement in the newsroom, but there wasn't a need for it at that point so it stayed as a concept for a good time. When the presidential debates started to get going a couple months ago, we pulled it out, dusted it off and realized it was going to be totally rebuilt and that the process was going to have to be worked out.
We were going to launch it with the democratic YouTube debate a month or so ago, and that night we realized just how much work it took on the day of the debate. It is necessary to record the video, cut the commercials out, encode the video, obtain a transcript, time-code the transcript, generate the XML and put it into the tool. This turned out to be a trial-run of the project because it wasn't ready to run until the afternoon AFTER the debate, which was just not quick enough. It turns out this dry run was incredibly valuable because this provided us with a chance to put actual content into both the video analyzer and the transcript analyzer. As most developers will tell you, it is very difficult to test your tools with fake or incomplete content. The biggest lesson we learned was that we were going to have to stream the video. It's a two-hour long debate, and the file size for that kind of video was ending up at around 350 megs. There was no way we could just launch that kind of download on our users.
Q. How in the world did you do this? Were the tools that you created in-house?
A. This turned out to be an interesting project for a couple reasons. There were certain programming obstacles that were fun and challenging. We had been working on a streaming video player, and that turned out to be a critical component to this project. Also, syncing the transcript with the video and vice versa presented different challenges. I had to work with Tom to make sure that we could use the same XML to power both of our projects and that it was structured in a way that was efficient for both of us. All of these things get worked out through trial-and-error and good conversation about what the end goal was.
This project was entirely home-grown. Luckily between Tom and I, the programming challenges were just that -- challenges. Over the last six months we've built out some components and tools (video player, programming classes) that make things a lot easier for ourselves. Now, I don't want to be misleading -- it takes a strong programming background and knowledge of the Internet to create an interactive like this -- but we've just worked through the process so projects can come together much quicker than they could a year ago. Programming is a tool that we use as journalists. Just like there are journalists who are 3D modelers, infographic artists, audio specialists, photographers, videographers, writers, etc. It's all journalism, it's just a skill set we use to communicate.
But this project really has two distinct parts. The programming part -- the actual building of the tool -- and the process of putting the piece together. This process is still being developed and is a challenge. The debates typically happen at night, and we want to have the project up by the morning at the latest. Just like with video encode time, this is a challenge, but it's also through a lot of hard work. Our politics producer, Sarah Wheaton, has the unenviable but incredibly necessary job of time coding the transcript. This is a painful process, and we're working on some tools that will make it easier, but in the end there is a decent amount of legwork that will have to get done every time we use this tool. That's just how it goes. A lot of times nowadays, we'll run into the question, "Well, can't the computer just do that?" or "Can't you write a tool that does that?" It always surprises people that even though computers can do a lot of the work for us, it still takes a team of journalists to make a project come together.
Q. Do you get the sense that online users get it? That they see what you have done and that they are actually using this tool in significant numbers?
It's an interesting question, whether or not users "get it." That is to say, "it" is constantly changing. Every morning I fire up the browser and see "it" is a changed beast. The Internet is an incredible -- and young -- form of communication. I think that users "get it" on several different levels, and we try to deliver accordingly. For example, it's possible to sit back and just watch the video and transcript and that's it. But if you want to, you can scrub the video and the transcript will update accordingly. Or, if you feel like it, you can click on any part of the transcript you want and it'll take you there. The day we put it up we decided to add the section links because it just seemed like a good idea. Point being, I don't think that everybody gets "it" in the same way. And I don't think that there is only one way to get "it." I don't browse the Internet the same way my friends do, or the same way my brothers do for that matter. The Internet is different things to different people, and we're looking to contribute. And that's the fun thing. We create these tools and give them to our users, and we go from there. It's a constantly adapting, flexible environment.
Lastly, I asked Tom to tell us about how the transcript analyzer came together:
The transcript analyzer was built in Flash, using
Actionscript 2, and took about a week to develop. Both the video tool and the transcript tool use an XML-formatted version of the debate transcript, which contains time-coded metadata about each participant's comments. The transcript analyzer simply takes the data from this XML document (which was created manually from a provided transcript of the debate), and provides its users with an interface to search and analyze it.
The transcript analyzer both empowers and engages its users in the political process in several ways. One such way is to allow them to quickly see which candidates got to speak the most and what these candidates were talking about. This information provides users with a fairly reliable snapshot of the state of the primaries (by seeing who the major candidates are and what the major issues are). Additionally, the transcript analyzer allows a user to actively search for the topics that interest him/her and see what candidates have to say about them. For users whose votes might be determined by one or two important issues, this is a very effective way to distill the full two-hour debate into something that is more approachable and personally relevant.
By producing tools like the transcript analyzer and the video analyzer, we are hoping to foster well-informed voters -- voters who are both aware of which candidates best represent their views and who are passionate about getting these candidates into office.
We are always looking for your great ideas. Send Al a few sentences and hot links.
Editor's
Note: Al's Morning Meeting is a compendium of ideas, edited story
excerpts and other materials from a variety of Web sites, as well as
original concepts and analysis. When the information comes directly
from another source, it will be attributed and a link will be provided
whenever possible. The column is fact-checked, but depends on the
accuracy and integrity of the original sources cited. Errors and
inaccuracies found will be corrected.
A lower tech version of the NYT "Transcript Analyzer," with...
