NPR Blogs: Inside NPR.org http://www.npr.org/blogs/inside/ Inside NPR.org en Copyright 2009 Thu, 19 Nov 2009 11:34:22 -0500 http://www.sixapart.com/movabletype/ http://blogs.law.harvard.edu/tech/rss What Happens When Stuff Breaks On NPR.org By Jason Grosman (Programmer, Digital Media) Before we release new code, such as our recent redesign, we do our best to test as well as possible, but we can't possibly figure out everything that could go wrong before we put it out there in the world. Even under the best circumstances, in a web site this complex and busy, problems will occur. Some of them are are avoidable, such as bugs in our code. And some of them are environmental issues, such as a network problem or database failure. Often, it's difficult to distinguish between the two. That's why it is essential to have a solid error handling system to track the errors as them come in, prioritize them, and give us enough information to be able to fix them. Obviously, we have spent a lot of time building features of our system that users see. A large percentage of our time is also spent on error handling. The error handling system that we've developed has been through several rounds of incremental improvements, starting with writing to a log, then emailing a developer, and now updating our issue tracking system. These approaches are described below in greater detail. Logging Every time our PHP code encounters an error, it gets automatically logged by our Apache web servers. We have dozens of web servers and they generate thousands of lines of logging information every day. We could get lost in the torrential downpour of log messages. Parsing through the logs is a good way to track down a problem once we know about it, but it was horrendously inefficient way to stay on top of new issues as they come in. Not only were they coming in too fast for any one person to keep track of, they also didn't provide any context about what a user was doing when the error occurred (and context is critical to the fundamental truth of debugging code that you must be able to consistently reproduce the problem before you can fix it or test the fix). The other problem with this kind of logging was that we were missing out on client side error messages. In the past year or so, NPR.org has added more and more javascript to support a growing list of features. This resulted in more client side errors, which were very hard to track. All of the different combinations of web browsers, browser settings, operating systems, proxy servers, etc., each one potentially handling our javascript differently, led to problems that we might never have encountered while testing in our limited set of test environments. And since they only occurred on the client machine, we would never know about them unless a user sent us an email or complained in some other way. As a result, we implemented something last year that we call jslog. With AJAX, we are able to send messages back to the server without reloading the page. Now, every time one of our pages has a javascript error, instead of making the user's client browser handle the error, leading to a less than stellar user experience, we catch the error and send it to the server using AJAX to be logged in the Apache web server logs. This is completely transparent to the user and allows the page to keep loading, even if it is not 100% perfect. 255) { value = value.substring(0, 255) + "..."; } _debugData += "{" + key + ":'" + value + "'}"; } } catch (propEx) { // ignore } } _debugData += "}"; var lineNumber = 'unknown'; if (_e.lineNumber != null) { lineNumber = _e.lineNumber; } NPR.messaging.logMessage(_debugData, _function, _id, lineNumber); } return { }; }; For javascript errors that we didn't catch, we add a function handler to the window.onerror event. This will be called for every uncaught javascript exception on the page. The code is below. window.onerror = function(message, url, lineNumber) { message = "Window.OnError: " + message; NPR.messaging.logMessage(message, "window.onerror", NPR.messaging.constants.JAVASCRIPT_GENERAL_ISSUE, lineNumber); window.onerror = function () {     return true; }; return true; // prevents browser error messages }; Both of these functions call a common logging function that creates a JSON string out of the message data and then uses the JQuery library to post a message to the server using AJAX. NPR.messaging.logMessage = function (_msg, _function, _id, _line) { try { var message = {}; message.msg = _msg; message.func = _function; message.id = _id; message.line = _line; message.agent = navigator.userAgent message.url = window.location.href; var debugData = ''; debugData = message.msg + ' | f: ' + message.func + ' | ' + message.agent + " | in URL: " + message.url; message = JSON.stringify(message); $.post("path/to/jslog.php", {type: 'Warning', message: message}); }catch(e){} }; Of course, we still have the problem of too many log messages, made even worse now that we're adding javascript errors to the mix. Which lead us to our next step, email. Email We use the PHP function set_error_handler to set up a special handler to intercept an error or warning before it is printed to the logs. We used this function to capture as much data about the problem as we can, then email it to developers. We can now see every error that occurs on the website as soon as it occurs, in our inbox. However, we still have the problem of the huge volume of logging that occurs. We tried to address that in two way. One was to tag each type of error with an id number so that we could group similar errors. The other way was to keep track of how many of each type of error we were getting, only sending email messages once we exceeded a certain threshold. We could customize the threshold for each the error type, allowing us to focus on only the most frequent and serious errors. An intermittent network connection error is not something the developers need to see every time, but if it happens 5000 times in 10 minutes, that's a different ball game. Still, receiving an email is a little too immediate. Most of the time, we can't drop everything we're working on to figure out what is causing a syntax error in the PHP. Most error messages that we get don't necessarily mean that a page or some feature is completely broken. It's still useful to eliminate as many trivial error messages as possible so that the big and important ones that do break the system don't get lost. We also discovered that we had to push the thresholds up to some very large numbers in order to get some relief from the flood of emails. Since we received emails for only a small subset of errors, many issues got lost in between and we may never find out about the problem. We were not much better off than keeping everything in the logs. That lead us to our last (and current) step, adding a ticket to our issue tracking system when a problem occurs. Issue Tracking Every time that our website encounters an error in either the PHP code or Javascript, we now post to a PHP page whose only job is log the issue in a MySQL database. This database keeps track of the filename, function name, line number, error message, and most usefully for debugging, a stack trace. We are very careful to make sure that this action doesn't take any longer than necessary and we've set a timeout on the post so that the public facing page continues to load in a timely manner, even if something is wrong in the backend error handling. Every few minutes, a different process scans the MySQL database and looks to see if any of the issues can be found in Jira, our issue tracking system. The following diagram shows the path an error takes on its way through the NPR site. (Click here for a larger version of this diagram) Rather than grouping issues by error type, as in the email system, we use the filename and function name to create a unique key identifying this specific error. If the error already exists in Jira, we update the count so we know how many times this particular error has occurred. If the error has not been reported, we add it as a new issue in Jira. We can use these error frequencies to prioritize which issues need to be fixed when. We've set up a separate project in Jira just for application errors and can assign specific issues to the development team to fix. For those issues that are not from coding problems or are innocuous enough to not require any attention, we close them, assuming that it will automatically be reopened and incremented if it becomes more critical. For certain critical error types, we are still able to email those issues directly to developers. This way we can still keep track of the state of the website without being overwhelmed by it. All of these backend errors can be triaged into our regular cycle of development work. We've just added this issue tracking integration into the system, so we are still fine tuning it. Although the logs and error emails were too numerous to keep track of, it turns out that the number of individual issues added to Jira is a manageable number. One interesting issue that we didn't anticipate was error messages coming from JavaScript running on web browsers in languages other than English. Although the error is the same, each time the problem is encountered in Russian, Spanish, or even Icelandic, a new ticket is added to Jira. Unfortunately, none of our developers speak Icelandic. Our next step in improving this process will be to group similar errors together, regardless of language. As we move forward and add new features to the website, the quality of the website will consistently be improving, one error message at a time.]]> By Jason Grosman (Programmer, Digital Media)

Before we release new code, such as our recent redesign, we do our best to test as well as possible, but we can't possibly figure out everything that could go wrong before we put it out there in the world. Even under the best circumstances, in a web site this complex and busy, problems will occur. Some of them are are avoidable, such as bugs in our code. And some of them are environmental issues, such as a network problem or database failure. Often, it's difficult to distinguish between the two. That's why it is essential to have a solid error handling system to track the errors as them come in, prioritize them, and give us enough information to be able to fix them.

Obviously, we have spent a lot of time building features of our system that users see. A large percentage of our time is also spent on error handling. The error handling system that we've developed has been through several rounds of incremental improvements, starting with writing to a log, then emailing a developer, and now updating our issue tracking system. These approaches are described below in greater detail.

Logging

Every time our PHP code encounters an error, it gets automatically logged by our Apache web servers. We have dozens of web servers and they generate thousands of lines of logging information every day. We could get lost in the torrential downpour of log messages. Parsing through the logs is a good way to track down a problem once we know about it, but it was horrendously inefficient way to stay on top of new issues as they come in. Not only were they coming in too fast for any one person to keep track of, they also didn't provide any context about what a user was doing when the error occurred (and context is critical to the fundamental truth of debugging code that you must be able to consistently reproduce the problem before you can fix it or test the fix).

The other problem with this kind of logging was that we were missing out on client side error messages. In the past year or so, NPR.org has added more and more javascript to support a growing list of features. This resulted in more client side errors, which were very hard to track. All of the different combinations of web browsers, browser settings, operating systems, proxy servers, etc., each one potentially handling our javascript differently, led to problems that we might never have encountered while testing in our limited set of test environments. And since they only occurred on the client machine, we would never know about them unless a user sent us an email or complained in some other way.

As a result, we implemented something last year that we call jslog. With AJAX, we are able to send messages back to the server without reloading the page. Now, every time one of our pages has a javascript error, instead of making the user's client browser handle the error, leading to a less than stellar user experience, we catch the error and send it to the server using AJAX to be logged in the Apache web server logs. This is completely transparent to the user and allows the page to keep loading, even if it is not 100% perfect.

]]> Code Examples

NPR.community.displayCommentError = function() 
{
    try {
        var commentBlock = document.getElementById('comments');
        commentBlock.innerHTML = "< h3>Community features and 
content, including commenting and recommending stories, are 
unavailable at this time. We apologize for the inconvenience. 
Please try this page later.< /h3>";
    } 
    catch (e) {
        NPR.messaging.exception(e, 'NPR.community.storyId = ' + 
NPR.community.storyId, 'displayCommentError', 
NPR.messaging.constants.COMMUNITY_JS_ERROR);
    }
};

The above javascript code snippet from our implementation of commenting has a try,catch block to handle an exception, it calls the following function which captures as much information as possible about what what wrong. We trim the exception information to a max of 255 characters to keep the message size reasonable. Some browsers include a stack trace inside the exception, so that could be very long.

NPR.messaging.exception = function(_e, _debugData, _function, _id) 
{
    if(_e.message.match('RequestBatch is undefined')===null) {
        
        _debugData += " {Exception: ";
        var counter = 0;
        for (var key in _e) {
            try {
                var value = _e[key];
                if (!$.isFunction(value)) {
                    if (counter++ != 0) {
                        _debugData += ",";
                    }
                    
                    if (value.length > 255) {
                        value = value.substring(0, 255) + "...";
                    }
                    
                    _debugData += "{" + key + ":'" + value + "'}";
                }
            }
            catch (propEx) {
                // ignore
            }
        }
        _debugData += "}";
        
        var lineNumber = 'unknown';
        if (_e.lineNumber != null) {
            lineNumber = _e.lineNumber;
        }
        
        NPR.messaging.logMessage(_debugData, _function, _id, 
lineNumber);
     }
    return { };
};

For javascript errors that we didn't catch, we add a function handler to the window.onerror event. This will be called for every uncaught javascript exception on the page. The code is below.

window.onerror = function(message, url, lineNumber) {
    message = "Window.OnError: " + message;
    NPR.messaging.logMessage(message, "window.onerror", 
NPR.messaging.constants.JAVASCRIPT_GENERAL_ISSUE, lineNumber);
    window.onerror = function () {
        return true;
    };
    return true; // prevents browser error messages
};

Both of these functions call a common logging function that creates a JSON string out of the message data and then uses the JQuery library to post a message to the server using AJAX.

NPR.messaging.logMessage = function (_msg, _function, _id, _line) {
    try {
        var message = {};
        message.msg = _msg;
        message.func = _function;
        message.id = _id;
        message.line = _line;
        message.agent = navigator.userAgent 
        message.url = window.location.href;
        
        var debugData = '';
        debugData = message.msg + ' | f: ' + message.func + ' | ' 
+ message.agent + " | in URL: " + message.url;
 
        message = JSON.stringify(message);
        $.post("path/to/jslog.php", {type: 'Warning', 
message: message});
    }catch(e){}
};

Of course, we still have the problem of too many log messages, made even worse now that we're adding javascript errors to the mix. Which lead us to our next step, email.

Email

We use the PHP function set_error_handler to set up a special handler to intercept an error or warning before it is printed to the logs. We used this function to capture as much data about the problem as we can, then email it to developers. We can now see every error that occurs on the website as soon as it occurs, in our inbox. However, we still have the problem of the huge volume of logging that occurs. We tried to address that in two way.

One was to tag each type of error with an id number so that we could group similar errors. The other way was to keep track of how many of each type of error we were getting, only sending email messages once we exceeded a certain threshold. We could customize the threshold for each the error type, allowing us to focus on only the most frequent and serious errors. An intermittent network connection error is not something the developers need to see every time, but if it happens 5000 times in 10 minutes, that's a different ball game.

Still, receiving an email is a little too immediate. Most of the time, we can't drop everything we're working on to figure out what is causing a syntax error in the PHP. Most error messages that we get don't necessarily mean that a page or some feature is completely broken. It's still useful to eliminate as many trivial error messages as possible so that the big and important ones that do break the system don't get lost.

We also discovered that we had to push the thresholds up to some very large numbers in order to get some relief from the flood of emails. Since we received emails for only a small subset of errors, many issues got lost in between and we may never find out about the problem. We were not much better off than keeping everything in the logs.

That lead us to our last (and current) step, adding a ticket to our issue tracking system when a problem occurs.

Issue Tracking

Every time that our website encounters an error in either the PHP code or Javascript, we now post to a PHP page whose only job is log the issue in a MySQL database. This database keeps track of the filename, function name, line number, error message, and most usefully for debugging, a stack trace. We are very careful to make sure that this action doesn't take any longer than necessary and we've set a timeout on the post so that the public facing page continues to load in a timely manner, even if something is wrong in the backend error handling. Every few minutes, a different process scans the MySQL database and looks to see if any of the issues can be found in Jira, our issue tracking system.

The following diagram shows the path an error takes on its way through the NPR site.


(Click here for a larger version of this diagram)

Rather than grouping issues by error type, as in the email system, we use the filename and function name to create a unique key identifying this specific error. If the error already exists in Jira, we update the count so we know how many times this particular error has occurred. If the error has not been reported, we add it as a new issue in Jira. We can use these error frequencies to prioritize which issues need to be fixed when.

We've set up a separate project in Jira just for application errors and can assign specific issues to the development team to fix. For those issues that are not from coding problems or are innocuous enough to not require any attention, we close them, assuming that it will automatically be reopened and incremented if it becomes more critical. For certain critical error types, we are still able to email those issues directly to developers. This way we can still keep track of the state of the website without being overwhelmed by it. All of these backend errors can be triaged into our regular cycle of development work.

We've just added this issue tracking integration into the system, so we are still fine tuning it. Although the logs and error emails were too numerous to keep track of, it turns out that the number of individual issues added to Jira is a manageable number.


One interesting issue that we didn't anticipate was error messages coming from JavaScript running on web browsers in languages other than English. Although the error is the same, each time the problem is encountered in Russian, Spanish, or even Icelandic, a new ticket is added to Jira. Unfortunately, none of our developers speak Icelandic. Our next step in improving this process will be to group similar errors together, regardless of language.


As we move forward and add new features to the website, the quality of the website will consistently be improving, one error message at a time.

]]> <p><a href="http://www.npr.org/blogs/inside/2009/11/what_happens_when_stuff_breaks.html#email">&raquo; E-Mail This</a>&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://del.icio.us/post?url=http://www.npr.org/blogs/inside/2009/11/what_happens_when_stuff_breaks.html">&raquo; Add to Del.icio.us</a> </p> http://www.npr.org/blogs/inside/2009/11/what_happens_when_stuff_breaks.html?ft=1&f=91000411 http://www.npr.org/blogs/inside/2009/11/what_happens_when_stuff_breaks.html?ft=1&f=91000411 Technology Jira error fail Thu, 19 Nov 2009 11:34:22 -0500 NPR Partners With Youtube For Science Video Contest By Mark Stencel and Keith Jenkins YouTube announced today that NPR is one of a handful of news organizations pioneering YouTube Direct, a new tool that allows us to request, review and display video clips produced and submitted by YouTube users. YouTube Direct will be embedded on NPR.org, where we can easily solicit user-generated video and feature the pieces our editors select. Our first project will focus on science. The WonderScope Challenge is an occasional series that solicits original video, art and animation related to a particular scientific concept -- and challenges users to "bring the abstract to life." The first concept we are inviting submissions on is "time"; the deadline is Thursday, December 17, at midnight. We'll solicit submissions via NPR.org, YouTube, Facebook and Twitter. This is how it works: 1. We create an assignment, like the one described above. 2. Users upload their submissions via the submission box on the page. 3. All videos go into our "submission" box for review. 4. Once a submission is accepted, it is added to the playlist for that assignment. This playlist will be on the submission page and also be shown on our YouTube page. YouTube will also be promoting the assignments on their pages as well. 5. When we selected a user piece for our playlist, it will get a NPR icon attached that will travel with it wherever it is embedded -- on YouTube, our site or elsewhere. If we don't approve the piece, the video remains on the user's own YouTube page. The WonderScope Challenge is our first foray with YouTube Direct. We're hoping that it will have a number of applications when it comes to collecting and curating user-generated videos. And as always, we welcome your feedback. (Mark Stencel is NPR's managing editor for Digital News. Keith Jenkins is supervising senior producer for multimedia.) By Mark Stencel and Keith Jenkins

YouTube announced today that NPR is one of a handful of news organizations pioneering YouTube Direct, a new tool that allows us to request, review and display video clips produced and submitted by YouTube users.

YouTube Direct will be embedded on NPR.org, where we can easily solicit user-generated video and feature the pieces our editors select. Our first project will focus on science. The WonderScope Challenge is an occasional series that solicits original video, art and animation related to a particular scientific concept -- and challenges users to "bring the abstract to life." The first concept we are inviting submissions on is "time"; the deadline is Thursday, December 17, at midnight. We'll solicit submissions via NPR.org, YouTube, Facebook and Twitter.

This is how it works:

1. We create an assignment, like the one described above.

2. Users upload their submissions via the submission box on the page.

3. All videos go into our "submission" box for review.

4. Once a submission is accepted, it is added to the playlist for that assignment. This playlist will be on the submission page and also be shown on our YouTube page. YouTube will also be promoting the assignments on their pages as well.

5. When we selected a user piece for our playlist, it will get a NPR icon attached that will travel with it wherever it is embedded -- on YouTube, our site or elsewhere. If we don't approve the piece, the video remains on the user's own YouTube page.

The WonderScope Challenge is our first foray with YouTube Direct. We're hoping that it will have a number of applications when it comes to collecting and curating user-generated videos. And as always, we welcome your feedback.

(Mark Stencel is NPR's managing editor for Digital News. Keith Jenkins is supervising senior producer for multimedia.)

]]> <p><a href="http://www.npr.org/blogs/inside/2009/11/npr_partners_with_youtube_for.html#email">&raquo; E-Mail This</a>&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://del.icio.us/post?url=http://www.npr.org/blogs/inside/2009/11/npr_partners_with_youtube_for.html">&raquo; Add to Del.icio.us</a> </p> http://www.npr.org/blogs/inside/2009/11/npr_partners_with_youtube_for.html?ft=1&f=91000411 http://www.npr.org/blogs/inside/2009/11/npr_partners_with_youtube_for.html?ft=1&f=91000411 Tue, 17 Nov 2009 16:54:27 -0500 Reflections On PublicMediaCamp By Andy Carvin (@acarvin) On October 17-18 in Washington DC we held our first national PublicMediaCamp. I'm proud to say that it completely exceeded my expectations. Held in conjunction with PBS, American University's Center for Social Media and iStrategyLabs, PubCamp brought together more than 250 people from across the country, including bloggers, social media enthusiasts, techies and staff from around three dozen public media stations. Following the model of BarCamp and PodCamp, PubCamp was organized, as it were, as an unconference. We encouraged participants to brainstorm session ideas on a wiki prior to the camp, but the schedule itself wasn't created until each morning's opening session. Anyone who wanted to lead a session had to announce it to the entire group; volunteers wrote down the session titles and gave them to me for placement on a paper chart mapping out which rooms and time slots were available. If you've never attended an unconference, it might come as a surprise that this method of event planning (or lack thereof) could actually work, but we ended up spawning more than 50 sessions over both days of the camp. Very few of these sessions were your typical conference PowerPoint presentation. in many cases, the session leader would make everyone rearrange the chairs in a circle so everyone could participate equally, which was heartening given the fact we tried to emphasize that attendees should see themselves as full-fledged participants rather than passive audience members. The sessions themselves covered a range of issues, from strategies for stations to work with local bloggers to mobilizing volunteers during natural disasters. Many of the sessions managed to wrangle someone in the group to serve as official note taker; we've assembled these notes on the PubCamp wiki. PubCamper John Proffitt put together this video capturing some of the scenes from PubCamp: Some of the big ideas that've been on my mind since PubCamp: Emergency response. Many stations are grappling with the question of how to respond to natural disasters and other emergencies, both in terms of providing useful information to the public and keeping their operations running. A number of representatives from stations in the southeast participated, which led to a number of conversations on dealing with hurricanes in particular. Stations expressed interest in putting together a real-time drill to practice how they respond to such events. To avoid confusing people with an actual disaster, we thought about using a zombie attack as the subject of the drill, though they'd still have to remind people it's a drill -- just in case. :-) Station-blogger relations. One of the most intense sessions of the camp occurred on the first day, when a discussion about stations working with local bloggers led to a debate about the nature of that relationship. On one side, some public media staff advocated a more arms-length approach, occasionally utilizing blogger content when relevant. On the other side, bloggers (and some public media staff as well) advocated a more direct partnership approach, where they have an ongoing editorial relationship with stations around a given content product. Blogger Jessie Newburn wrote up a very interesting summary of the debate, breaking it down on generational lines. Volunteer management. Several sessions raised the possibility of creating a public media volunteer corps, an idea that I've been thinking about since working on the Hurricanes08.org and VoteReport projects last year. One question that came up a lot was what tools are available to manage volunteers locally and nationally. Julia Schrenkler of American Public Media said she'd explore the possibility of incorporating volunteer management tools into their Public Insight software, which allows the public to volunteer and serve as subject-matter experts for reporters. User generated content curation. One of the biggest themes from PubCamp was the question of how to curate user-generated content. Our experiences last year with VoteReport and related projects demonstrated that it's possible to create a system for both ingesting UGC from a variety of sources, as well as getting volunteers to help curate the content. But we still don't have a set of generic tools that makes it easy to ingest, curate and display UGC, whether it's for a station reporting project or a major breaking news event. There was a lot of interest in the development of tools like Swift, an open source spinoff of our VoteReport project that's attempting to tackle some of these challenges. Swift aims to ingest UGC from a variety of sources and then allow curation through a combination of people reviewing the content and machine-based algorithms. Whatever form these tools take place, it seemed clear that a range of toolsets would ultimately be needed at the local and national level. Creating an "Apps for Public Media" contest. Ever since we started to plan PubCamp this spring, I've been thinking about what public media can learn from software-building contests such as Apps For Democracy and Apps For America. These contests encourage people to develop free software with a community focus, using locally available APIs and data. Given the fact that NPR has its own API and PBS is working on some of their own, a contest might be an interesting way of encouraging development using those tools. We got some useful feedback at PubCamp on the idea. For example, while such a contest probably should encourage the development of local apps, it's probably not realistic to expect stations to run their own contests. Others suggested that an apps contest should include specific challenges, such as developing apps for the 2010 midterm election. They're definitely ideas worth considering if we choose to move forward. Perhaps the biggest takeaway from PubCamp is that this really is the beginning of something. The 10 stations we brought to PubCamp on scholarship have all agreed to host their own camps in 2010, and a number of other stations are likely to organize their own as well. To help them pull it off, we've published a PublicMediaCamp Field Guide, which includes step-by-step instructions on how to use unconferences as a model for stations to engage their communities. We also held a PubCamp 101 session to explain the field guide in greater detail, which John Proffitt also recorded on video: All in all, I think our first national PubCamp was a great success. Despite the fact we had some of the worst weather in months, combined with all sorts of road closures, we managed to attract an amazing and diverse crowd. Now let's see if we can take that momentum and convert it into real collaboration at the local level. By Andy Carvin (@acarvin)

On October 17-18 in Washington DC we held our first national PublicMediaCamp. I'm proud to say that it completely exceeded my expectations. Held in conjunction with PBS, American University's Center for Social Media and iStrategyLabs, PubCamp brought together more than 250 people from across the country, including bloggers, social media enthusiasts, techies and staff from around three dozen public media stations.

Following the model of BarCamp and PodCamp, PubCamp was organized, as it were, as an unconference. We encouraged participants to brainstorm session ideas on a wiki prior to the camp, but the schedule itself wasn't created until each morning's opening session. Anyone who wanted to lead a session had to announce it to the entire group; volunteers wrote down the session titles and gave them to me for placement on a paper chart mapping out which rooms and time slots were available. If you've never attended an unconference, it might come as a surprise that this method of event planning (or lack thereof) could actually work, but we ended up spawning more than 50 sessions over both days of the camp. Very few of these sessions were your typical conference PowerPoint presentation. in many cases, the session leader would make everyone rearrange the chairs in a circle so everyone could participate equally, which was heartening given the fact we tried to emphasize that attendees should see themselves as full-fledged participants rather than passive audience members.

The sessions themselves covered a range of issues, from strategies for stations to work with local bloggers to mobilizing volunteers during natural disasters. Many of the sessions managed to wrangle someone in the group to serve as official note taker; we've assembled these notes on the PubCamp wiki.

PubCamper John Proffitt put together this video capturing some of the scenes from PubCamp:

]]> Some of the big ideas that've been on my mind since PubCamp:

Emergency response. Many stations are grappling with the question of how to respond to natural disasters and other emergencies, both in terms of providing useful information to the public and keeping their operations running. A number of representatives from stations in the southeast participated, which led to a number of conversations on dealing with hurricanes in particular. Stations expressed interest in putting together a real-time drill to practice how they respond to such events. To avoid confusing people with an actual disaster, we thought about using a zombie attack as the subject of the drill, though they'd still have to remind people it's a drill -- just in case. :-)

Station-blogger relations. One of the most intense sessions of the camp occurred on the first day, when a discussion about stations working with local bloggers led to a debate about the nature of that relationship. On one side, some public media staff advocated a more arms-length approach, occasionally utilizing blogger content when relevant. On the other side, bloggers (and some public media staff as well) advocated a more direct partnership approach, where they have an ongoing editorial relationship with stations around a given content product. Blogger Jessie Newburn wrote up a very interesting summary of the debate, breaking it down on generational lines.

Volunteer management. Several sessions raised the possibility of creating a public media volunteer corps, an idea that I've been thinking about since working on the Hurricanes08.org and VoteReport projects last year. One question that came up a lot was what tools are available to manage volunteers locally and nationally. Julia Schrenkler of American Public Media said she'd explore the possibility of incorporating volunteer management tools into their Public Insight software, which allows the public to volunteer and serve as subject-matter experts for reporters.

User generated content curation. One of the biggest themes from PubCamp was the question of how to curate user-generated content. Our experiences last year with VoteReport and related projects demonstrated that it's possible to create a system for both ingesting UGC from a variety of sources, as well as getting volunteers to help curate the content. But we still don't have a set of generic tools that makes it easy to ingest, curate and display UGC, whether it's for a station reporting project or a major breaking news event. There was a lot of interest in the development of tools like Swift, an open source spinoff of our VoteReport project that's attempting to tackle some of these challenges. Swift aims to ingest UGC from a variety of sources and then allow curation through a combination of people reviewing the content and machine-based algorithms. Whatever form these tools take place, it seemed clear that a range of toolsets would ultimately be needed at the local and national level.

Creating an "Apps for Public Media" contest. Ever since we started to plan PubCamp this spring, I've been thinking about what public media can learn from software-building contests such as Apps For Democracy and Apps For America. These contests encourage people to develop free software with a community focus, using locally available APIs and data. Given the fact that NPR has its own API and PBS is working on some of their own, a contest might be an interesting way of encouraging development using those tools. We got some useful feedback at PubCamp on the idea. For example, while such a contest probably should encourage the development of local apps, it's probably not realistic to expect stations to run their own contests. Others suggested that an apps contest should include specific challenges, such as developing apps for the 2010 midterm election. They're definitely ideas worth considering if we choose to move forward.

Perhaps the biggest takeaway from PubCamp is that this really is the beginning of something. The 10 stations we brought to PubCamp on scholarship have all agreed to host their own camps in 2010, and a number of other stations are likely to organize their own as well. To help them pull it off, we've published a PublicMediaCamp Field Guide, which includes step-by-step instructions on how to use unconferences as a model for stations to engage their communities. We also held a PubCamp 101 session to explain the field guide in greater detail, which John Proffitt also recorded on video:

All in all, I think our first national PubCamp was a great success. Despite the fact we had some of the worst weather in months, combined with all sorts of road closures, we managed to attract an amazing and diverse crowd. Now let's see if we can take that momentum and convert it into real collaboration at the local level.


]]> <p><a href="http://www.npr.org/blogs/inside/2009/10/reflections_on_publicmediacamp.html#email">&raquo; E-Mail This</a>&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://del.icio.us/post?url=http://www.npr.org/blogs/inside/2009/10/reflections_on_publicmediacamp.html">&raquo; Add to Del.icio.us</a> </p> <p> <a rel="nofollow" href="http://u.npr.org/adclick/utype=rss/aamsz=300x80/position=rss1/site=NPR/blog=91000411"> <img border="0" width="300" height="80" src="http://u.npr.org/iserver/utype=rss/aamsz=300x80/position=rss1/site=NPR/blog=91000411" /> </a> </p> http://www.npr.org/blogs/inside/2009/10/reflections_on_publicmediacamp.html?ft=1&f=91000411 http://www.npr.org/blogs/inside/2009/10/reflections_on_publicmediacamp.html?ft=1&f=91000411 Social Media PubCamp PublicMediaCamp events Tue, 27 Oct 2009 09:32:48 -0500 Beats and Tweets: Journalistic Guidelines for the Facebook Era By Mark Stencel The NPR News staff is a chatty group, on-air and online -- as thousands of our Twitter followers and Facebook friends already know. Individual NPR journalists, from longtime host Scott Simon to new health blogger Scott Hensley, regularly muse online about their work and other subjects. Even the somewhat technical updates that our Digital Media staff posted on Twitter when we revamped NPR.org in July drew surprising interest and feedback. Popular social media sites and services are great reporting tools. They help our journalists find and keep in contact with a wide range of sources. They also provide powerful ways to connect with our listeners and users and to share our journalism. But all of us at NPR News need to remember that, as journalists, we are just as responsible and accountable for what we say and do online as we are in other aspects of our lives. Social media guidelines shared with the news staff on Thursday offer commonsense rules and reminders for those of us here who make use of these communication channels. Summarizing the guidance in an e-mail message, Senior Vice President for News Ellen Weiss urged the staff to "use social media for journalistic purposes and as a way to connect with the audience." Weiss also reminded our journalists -- including the engineering, operations and news administration staffs -- to avoid doing "anything online that will damage your credibility or the credibility of NPR." In a separate message, CEO Vivian Schiller emphasized that the guidelines for the news staff "are relevant to ALL employees." The rules are mandatory for all company officers, as well as any staff involved with programming, digital media, communications and legal affairs. But Schiller urged those who "fall outside those boundaries" to follow the guidelines as well. "NPR is first and foremost a news organization," she wrote, "which means staffers from Finance to Facilities represent the face of NPR's journalistic integrity. So I'd ask that you please use your best judgment when it comes to your public activities online." In the spirit of openness that social media often represents, we thought we'd share with you the full text of these Social Media Guidelines. (Please see below.) The guidelines also are posted in the About section of NPR.org, where you can find a link to the NPR News Code of Ethics. As ever, we welcome any thoughts and feedback -- whatever the medium. Mark Stencel (@markstencel on Twitter) is NPR's managing editor for Digital News. * * * NPR NEWS SOCIAL MEDIA GUIDELINES Social networking sites, such as Facebook, MySpace, and Twitter have become an integral part of everyday life for millions of people around the world. As NPR grows to serve the audience well beyond the radio, social media is becoming an increasingly important aspect of our interaction and our transparency with our audience and with a variety of communities. Properly used, social networking sites can also be very valuable newsgathering and reporting tools and can speed research and extend a reporter's contacts, and we encourage our journalists to take advantage of them. The line between private and public activity has been blurred by these tools, which is why we are providing guidance now. Information from your Facebook page, your blog entries and your tweets -- even if you intend them to be personal messages to your friends or family -- can be easily circulated beyond your intended audience. This content, therefore, represents you and NPR to the outside world as much as a radio story or story for NPR.org does. As in all of your reporting, the NPR Code of Ethics (http://www.npr.org/about/ethics/) should guide you in your use of social media. You should read and be sure you understand the Code. What follows are some basic but important guidelines to help you as you deal with the changing world of gathering and reporting news, and to provide additional guidance on specific issues. These guidelines apply to every member of the News Division. First and foremost -- you should do nothing that could undermine your credibility with the public, damage NPR's standing as an impartial source of news or otherwise jeopardize NPR's reputation. Recognize that everything you write or receive on a social media site is public. Anyone with access to the web can get access to your activity on social media sites. And regardless of how careful you are in trying to keep them separate, in your online activity, your professional life and your personal life overlap. Use the highest level of privacy tools available to control access to your personal activity when appropriate, but don't let that make you complacent. It's just not that hard for someone to hack those tools and make public what you thought was private. You should conduct yourself in social media forums with an eye to how your behavior or comments might appear if we were called upon to defend them as a news organization. In other words, don't behave any differently online than you would in any other public setting. While we strongly encourage linking to NPR.org, you may not repost NPR copyrighted material to social networks without prior permission. For example, it is o.k. to link from your blog or Facebook profile to a story of yours on the NPR site, but you should not copy the full text or audio onto a personal site or Web page. You may accomplish this through the NPR API or widgets that NPR provides to the public under the same terms of use as apply to anyone else. Remember that the terms of service of a social media site apply to what you post and gather on that site. The terms might allow for material that you post to be used in a different way than you intended. Additionally, law enforcement officials may be able to obtain by subpoena anything you post or gather on a site without your consent -- or perhaps even your knowledge. Remember the same ethics rules as apply offline also apply to information gathered online. Journalism should be conducted in the open, regardless of the platform. Just as you would do if you were working offline, you should identify yourself as an NPR journalist when you are working online. If you are acting as an NPR journalist, you must not use a pseudonym or misrepresent who you are. If you are acting in a personal capacity, you may use a screen name if that is allowed by the relevant forum. You should always explain to anyone who provides you information online how you intend to use the information you are gathering. When possible, clarify and confirm any information you collect online by later interviewing your online sources by phone or in person. While widely disseminated and reported, material gathered online can be just as inaccurate or untrustworthy as some material collected or received in more traditional ways. As always, consider and verify the source. Content gathered online is subject to the same attribution rules as other content. You must not advocate for political or other polarizing issues online. This extends to joining online groups or using social media in any form (including your Facebook page or a personal blog) to express personal views on a political or other controversial issue that you could not write for the air or post on NPR.org. Your simple participation in some online groups could be seen to indicate that you endorse their views. Consider whether you can accomplish your purposes by just observing a group's activity, rather than becoming a member. If you do join, be clear that you've done so to seek information or story ideas. And if you "friend" or join a group representing one side of an issue, do so for a group representing the competing viewpoint, when reasonable to do so. Realize that social media communities have their own culture, etiquette and norms, and be respectful of them. If you are writing about meetings and gatherings at NPR -- always ask first if the forum is on or off the record before distributing information or content about it. And a final caution -- when in doubt, consult with your editor. Social media is a very dynamic ecosystem so don't be surprised if we continue to revise or elaborate on our guidelines at a later date. In the mean time, we welcome your feedback. By Mark Stencel

The NPR News staff is a chatty group, on-air and online -- as thousands of our Twitter followers and Facebook friends already know. Individual NPR journalists, from longtime host Scott Simon to new health blogger Scott Hensley, regularly muse online about their work and other subjects. Even the somewhat technical updates that our Digital Media staff posted on Twitter when we revamped NPR.org in July drew surprising interest and feedback.

Popular social media sites and services are great reporting tools. They help our journalists find and keep in contact with a wide range of sources. They also provide powerful ways to connect with our listeners and users and to share our journalism. But all of us at NPR News need to remember that, as journalists, we are just as responsible and accountable for what we say and do online as we are in other aspects of our lives.

Social media guidelines shared with the news staff on Thursday offer commonsense rules and reminders for those of us here who make use of these communication channels. Summarizing the guidance in an e-mail message, Senior Vice President for News Ellen Weiss urged the staff to "use social media for journalistic purposes and as a way to connect with the audience." Weiss also reminded our journalists -- including the engineering, operations and news administration staffs -- to avoid doing "anything online that will damage your credibility or the credibility of NPR."

]]> In a separate message, CEO Vivian Schiller emphasized that the guidelines for the news staff "are relevant to ALL employees." The rules are mandatory for all company officers, as well as any staff involved with programming, digital media, communications and legal affairs. But Schiller urged those who "fall outside those boundaries" to follow the guidelines as well. "NPR is first and foremost a news organization," she wrote, "which means staffers from Finance to Facilities represent the face of NPR's journalistic integrity. So I'd ask that you please use your best judgment when it comes to your public activities online."

In the spirit of openness that social media often represents, we thought we'd share with you the full text of these Social Media Guidelines. (Please see below.)

The guidelines also are posted in the About section of NPR.org, where you can find a link to the NPR News Code of Ethics.

As ever, we welcome any thoughts and feedback -- whatever the medium.

Mark Stencel (@markstencel on Twitter) is NPR's managing editor for Digital News.

* * *

NPR NEWS SOCIAL MEDIA GUIDELINES

Social networking sites, such as Facebook, MySpace, and Twitter have become an integral part of everyday life for millions of people around the world. As NPR grows to serve the audience well beyond the radio, social media is becoming an increasingly important aspect of our interaction and our transparency with our audience and with a variety of communities. Properly used, social networking sites can also be very valuable newsgathering and reporting tools and can speed research and extend a reporter's contacts, and we encourage our journalists to take advantage of them.

The line between private and public activity has been blurred by these tools, which is why we are providing guidance now. Information from your Facebook page, your blog entries and your tweets -- even if you intend them to be personal messages to your friends or family -- can be easily circulated beyond your intended audience. This content, therefore, represents you and NPR to the outside world as much as a radio story or story for NPR.org does.

As in all of your reporting, the NPR Code of Ethics (http://www.npr.org/about/ethics/) should guide you in your use of social media. You should read and be sure you understand the Code.

What follows are some basic but important guidelines to help you as you deal with the changing world of gathering and reporting news, and to provide additional guidance on specific issues. These guidelines apply to every member of the News Division.

First and foremost -- you should do nothing that could undermine your credibility with the public, damage NPR's standing as an impartial source of news or otherwise jeopardize NPR's reputation.

  • Recognize that everything you write or receive on a social media site is public. Anyone with access to the web can get access to your activity on social media sites. And regardless of how careful you are in trying to keep them separate, in your online activity, your professional life and your personal life overlap.

  • Use the highest level of privacy tools available to control access to your personal activity when appropriate, but don't let that make you complacent. It's just not that hard for someone to hack those tools and make public what you thought was private.

  • You should conduct yourself in social media forums with an eye to how your behavior or comments might appear if we were called upon to defend them as a news organization. In other words, don't behave any differently online than you would in any other public setting.

  • While we strongly encourage linking to NPR.org, you may not repost NPR copyrighted material to social networks without prior permission. For example, it is o.k. to link from your blog or Facebook profile to a story of yours on the NPR site, but you should not copy the full text or audio onto a personal site or Web page. You may accomplish this through the NPR API or widgets that NPR provides to the public under the same terms of use as apply to anyone else.

  • Remember that the terms of service of a social media site apply to what you post and gather on that site. The terms might allow for material that you post to be used in a different way than you intended. Additionally, law enforcement officials may be able to obtain by subpoena anything you post or gather on a site without your consent -- or perhaps even your knowledge.

  • Remember the same ethics rules as apply offline also apply to information gathered online.

  • Journalism should be conducted in the open, regardless of the platform. Just as you would do if you were working offline, you should identify yourself as an NPR journalist when you are working online. If you are acting as an NPR journalist, you must not use a pseudonym or misrepresent who you are. If you are acting in a personal capacity, you may use a screen name if that is allowed by the relevant forum.

  • You should always explain to anyone who provides you information online how you intend to use the information you are gathering.

  • When possible, clarify and confirm any information you collect online by later interviewing your online sources by phone or in person.

  • While widely disseminated and reported, material gathered online can be just as inaccurate or untrustworthy as some material collected or received in more traditional ways. As always, consider and verify the source.

  • Content gathered online is subject to the same attribution rules as other content.

  • You must not advocate for political or other polarizing issues online. This extends to joining online groups or using social media in any form (including your Facebook page or a personal blog) to express personal views on a political or other controversial issue that you could not write for the air or post on NPR.org.

  • Your simple participation in some online groups could be seen to indicate that you endorse their views. Consider whether you can accomplish your purposes by just observing a group's activity, rather than becoming a member. If you do join, be clear that you've done so to seek information or story ideas. And if you "friend" or join a group representing one side of an issue, do so for a group representing the competing viewpoint, when reasonable to do so.

  • Realize that social media communities have their own culture, etiquette and norms, and be respectful of them.

  • If you are writing about meetings and gatherings at NPR -- always ask first if the forum is on or off the record before distributing information or content about it.

    And a final caution -- when in doubt, consult with your editor.

    Social media is a very dynamic ecosystem so don't be surprised if we continue to revise or elaborate on our guidelines at a later date. In the mean time, we welcome your feedback.

    ]]> <p><a href="http://www.npr.org/blogs/inside/2009/10/beats_and_tweets_journalistic.html#email">&raquo; E-Mail This</a>&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://del.icio.us/post?url=http://www.npr.org/blogs/inside/2009/10/beats_and_tweets_journalistic.html">&raquo; Add to Del.icio.us</a> </p> http://www.npr.org/blogs/inside/2009/10/beats_and_tweets_journalistic.html?ft=1&f=91000411 http://www.npr.org/blogs/inside/2009/10/beats_and_tweets_journalistic.html?ft=1&f=91000411 Social Media Facebook Twitter ethics social media Thu, 15 Oct 2009 08:50:00 -0500 NPR News iPhone App Upgrade Includes Live Coverage And More By Robert Spier, Demian Perry and Daniel Jacobson We have just released a new update to our NPR News iPhone app. (v1.2, if you're counting; we sure are!) It's ready for download from the iTunes Store. Here are some of the updates we've made to it: Listen Live: Although NPR is not a radio station, we do "go live," over our member stations' broadcasts as well as from NPR.org, for major scheduled or unscheduled news events. With v1.2, we have now extended this capability to the iPhone; if NPR is in live coverage, you will receive a start-up alert inviting you to tune in. Down the line, we will improve the ways in which we notify iPhone app users about live coverage; we also anticipate presenting NPR Music live concerts. A Better Audio Experience: v1.2 offers two improvements here: improved audio streaming in low bandwidth scenarios, and greater Playlist stability. Sharing: We have added the ability for users to share, not just individual stories, but also many of the program episodes via email, Twitter and Facebook. We have also improved the Twitter share screens in particular. Story Page & Images: We have improved the layout of individual story pages. And, if you enlarge any photo on a story page, you will now see an overlay presenting the full caption. All in all, v1.2 offers a total of 32 improvements. Many of these are in response to your feedback via the NPR Facebook page, Twitter, other posts on this blog, iTunes reviews, etc. So, please, keep 'em coming -- we are already working on v1.3. By Robert Spier, Demian Perry and Daniel Jacobson

    We have just released a new update to our NPR News iPhone app. (v1.2, if you're counting; we sure are!) It's ready for download from the iTunes Store. Here are some of the updates we've made to it:

    Listen Live: Although NPR is not a radio station, we do "go live," over our member stations' broadcasts as well as from NPR.org, for major scheduled or unscheduled news events. With v1.2, we have now extended this capability to the iPhone; if NPR is in live coverage, you will receive a start-up alert inviting you to tune in. Down the line, we will improve the ways in which we notify iPhone app users about live coverage; we also anticipate presenting NPR Music live concerts.

    A Better Audio Experience: v1.2 offers two improvements here: improved audio streaming in low bandwidth scenarios, and greater Playlist stability.

    Sharing: We have added the ability for users to share, not just individual stories, but also many of the program episodes via email, Twitter and Facebook. We have also improved the Twitter share screens in particular.

    Story Page & Images: We have improved the layout of individual story pages. And, if you enlarge any photo on a story page, you will now see an overlay presenting the full caption.

    All in all, v1.2 offers a total of 32 improvements. Many of these are in response to your feedback via the NPR Facebook page, Twitter, other posts on this blog, iTunes reviews, etc. So, please, keep 'em coming -- we are already working on v1.3.

    ]]> <p><a href="http://www.npr.org/blogs/inside/2009/10/npr_news_iphone_app_upgrade_in_1.html#email">&raquo; E-Mail This</a>&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://del.icio.us/post?url=http://www.npr.org/blogs/inside/2009/10/npr_news_iphone_app_upgrade_in_1.html">&raquo; Add to Del.icio.us</a> </p>     http://www.npr.org/blogs/inside/2009/10/npr_news_iphone_app_upgrade_in_1.html?ft=1&f=91000411 http://www.npr.org/blogs/inside/2009/10/npr_news_iphone_app_upgrade_in_1.html?ft=1&f=91000411 Mobile Tue, 13 Oct 2009 11:00:00 -0500     Thinking About NPR's Digital Future By Kinsey Wilson The media landscape is changing at unprecedented speed. And news organizations everywhere are racing to keep up. One way NPR tries to stay current is by connecting with people who are working at the forefront of technological change. Usually, those are casual, behind-the-scenes encounters. But today, we've assembled an extraordinary group of technologists, entrepreneurs and innovators in San Francisco to spend the day thinking -- in public -- about NPR's future. The event is being hosted by frog design, a San Francisco-based global innovation firm. NPR's President and CEO, Vivian Schiller, and I will kick off the conversation and then invite guests to spend the rest of the day in small breakout sessions thinking about how we can tackle some of the biggest challenges of the day. Everything from how public radio's revenue picture might change in coming years to how we respond to a world in which information increasingly flows freely across every conceivable channel and device. We're calling it the NPR Digital Think In and you can follow it and join the conversation if you're so inclined. We're streaming selected portions and live-blogging throughout the day. Attendees will be tweeting using the hashtag #nprthink. And NPR's Andy Carvin will be posting to YouTube and Flickr under "nprthink" and updating NPR's Facebook page. We hope you'll join us and help us figure out how to keep NPR vital and engaging even as technology transforms the way we deliver the news. Kinsey Wilson is senior vice president and general manager of digital media for NPR. By Kinsey Wilson

    The media landscape is changing at unprecedented speed. And news organizations everywhere are racing to keep up.

    One way NPR tries to stay current is by connecting with people who are working at the forefront of technological change.

    Usually, those are casual, behind-the-scenes encounters. But today, we've assembled an extraordinary group of technologists, entrepreneurs and innovators in San Francisco to spend the day thinking -- in public -- about NPR's future.

    ]]> The event is being hosted by frog design, a San Francisco-based global innovation firm. NPR's President and CEO, Vivian Schiller, and I will kick off the conversation and then invite guests to spend the rest of the day in small breakout sessions thinking about how we can tackle some of the biggest challenges of the day.

    Everything from how public radio's revenue picture might change in coming years to how we respond to a world in which information increasingly flows freely across every conceivable channel and device.

    We're calling it the NPR Digital Think In and you can follow it and join the conversation if you're so inclined. We're streaming selected portions and live-blogging throughout the day. Attendees will be tweeting using the hashtag #nprthink. And NPR's Andy Carvin will be posting to YouTube and Flickr under "nprthink" and updating NPR's Facebook page.

    We hope you'll join us and help us figure out how to keep NPR vital and engaging even as technology transforms the way we deliver the news.

    Kinsey Wilson is senior vice president and general manager of digital media for NPR.

    ]]> <p><a href="http://www.npr.org/blogs/inside/2009/10/nprs_digital_think_in.html#email">&raquo; E-Mail This</a>&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://del.icio.us/post?url=http://www.npr.org/blogs/inside/2009/10/nprs_digital_think_in.html">&raquo; Add to Del.icio.us</a> </p>     http://www.npr.org/blogs/inside/2009/10/nprs_digital_think_in.html?ft=1&f=91000411 http://www.npr.org/blogs/inside/2009/10/nprs_digital_think_in.html?ft=1&f=91000411 Technology Fri, 09 Oct 2009 09:11:05 -0500     Jira: 'Swapping Chaos for a Little Overhead' * By Kim Bryant This post is the first in a series explaining the challenges we face in managing work requests, bug tracking and other operational processes. Specifically, I'll cover Jira, the tool that we selected to help with these challenges, as well as the ways we've configured it to suit our culture and needs. Part of my job is figuring out how we can work more effectively, and one of the first areas we needed to tackle was our work request system. Our overarching goal when managing work requests is to allow Digital Media to easily separate the noise from the important stuff. You know that scene right after the crash in the first episode of Lost where Locke sees the equivalent of a redshirt wandering near an intermittently-spinning jet turbine, and the guy can't hear the specifics of Locke's yelled warning so he stops long enough to shout "What?!" and then fahWHOMP-- redshirt becomes strawberry jam and the engine explodes and a horrible situation just got worse? Here's a refresher: We needed to stay off the path to experiencing our own redshirt schmear in the midst of premature labor, ineffective CPR, and lethal chunks of flaming metal shrapnel. Maybe ours wouldn't be as messy, but certainly no reprise of Beach Blanket Bingo. Our ops demons and how we started taming them, after the jump. We face the same operational challenges as most small-to-mid-size development shops when prioritizing: multiple types of requesters with different levels of expertise Our requests come from a wide range of people, including senior managers, interns, contractors, developers, project managers, and designers. Each stakeholder has a different comfort level with and ability to describe technical problems and suggestions for improvement. Our process management system must accommodate all of our users, making it as easy as possible for them to log and track issues. multiple paths for making requests Folks stop by our desks, call us, email us, IM us, report bugs in tracking systems, and pass along problems while walking by the kitchen when we're nuking lunch. We don't want to limit the amount of human contact, but we do need a central repository that we encourage people to use. multiple types of requests We get everything from backend changes requiring a release to design reviews, documentation needs, and front-end changes. Often, the requestor doesn't understand the scope of what they're asking for or how it might impact other applications or users. We need a way of bucketing the same types of requests and providing an LOE estimate. different teams working at different levels at the same time On any given day, we have a mix of 40+ developers, information architects, project managers, designers, and product owners working on projects, production requests, and emergency and planned releases. They need to be able to filter by and switch from type to type with a minimum of effort, and they need to see what everyone else is working on. figuring out resource load We receive hundreds of requests a week and have a limited number of staff and contractors who can address them. Our work request system should ideally show us how much work each developer or designer has in his/her queue and allow us to adjust the load for peaks and lulls (not that we've seen much of the latter). Taking these key challenges into account, we established some process ground rules, which include: 1. Jira isn't meant to take the place of human interaction. We use Jira to document, plan, track, and report on work requests and bugs. It's not like that fishing game at the community carnival where you cast your line over the wall and reel in your random prize when you feel a tug. We want our reporters to know exactly what they're getting, and we depend on them and many others to help us clarify and work collaboratively. 2. Jira isn't the first point of contact in a true emergency. While it doesn't take much time to enter an issue and several folks are monitoring Jira throughout the workday, we don't have 24/7 coverage and we don't have any staff 100% dedicated to triaging Jira tickets as they come in. If our site is down or an editor on a breaking news deadline can't publish, folks call an emergency support number, come to our desks, or page us on the intercom. Only if necessary (sometimes after the fact) do we or they enter a Jira ticket. 3. Product owners decide the priority of the issue. In the past, many requests requiring business analysis came to the developers for resolution. We tried to pull in product owners whenever possible, but it's a conflict of interest for developers to be setting product vision for stuff we don't own. Our new process makes product owners the first assignee by default. 4. Only one person is responsible for a Jira issue. This rule addresses the challenges we have when someone sends a request to an email distribution list: multiple email threads start, it may not be clear who is working on it (or if anyone is working on it), and a lot of time could pass before it's resolved. The assignee is the person who has to do something with the issue -- even if it's as simple as assigning it to the right person to carry out the work. Other group members may be notified/watching, but only one person owns an issue at any given point. Throughout the lifecycle of an issue, product owners need to weigh in, but they generally don't execute the work for task. 5. Closed issues stay closed. We often reopened bugs weeks or even months after they were closed, either to flag a recurrence of the same problem or to add comments about a new, related problem. Now, production code changes are tied to specific Jira requests, which enables more efficient troubleshooting and insight for future development. If a request goes live after UAT (User Acceptance Testing) and there's a production issue, it's a different problem and a new request is opened. We sometimes link to related issues to clarify the new problem. 6. We're never done improving. We're treating the work request process like our bastardized Agile development process: we learn more as we use it and make adjustments as necessary. Since we launched, product owners received more Jira permissions in order to ease a triage bottleneck. We're working on determining our optimum velocity for planned releases. We still need to come up with an overall plan for prioritizing production requests, now that Jira has been open to all Digital Media users for a little over a month. We know we always can do better and try to be as flexible as possible. So, why did we end up choosing Jira? Find out in my next post, "You say Godzilla, I say Gojira." * I wish could take credit for the title of this post; Harold Neal (Senior Software Developer) said it while reviewing the Jira implementation plan. By Kim Bryant

    This post is the first in a series explaining the challenges we face in managing work requests, bug tracking and other operational processes. Specifically, I'll cover Jira, the tool that we selected to help with these challenges, as well as the ways we've configured it to suit our culture and needs.

    Part of my job is figuring out how we can work more effectively, and one of the first areas we needed to tackle was our work request system. Our overarching goal when managing work requests is to allow Digital Media to easily separate the noise from the important stuff. You know that scene right after the crash in the first episode of Lost where Locke sees the equivalent of a redshirt wandering near an intermittently-spinning jet turbine, and the guy can't hear the specifics of Locke's yelled warning so he stops long enough to shout "What?!" and then fahWHOMP-- redshirt becomes strawberry jam and the engine explodes and a horrible situation just got worse? Here's a refresher:

    We needed to stay off the path to experiencing our own redshirt schmear in the midst of premature labor, ineffective CPR, and lethal chunks of flaming metal shrapnel. Maybe ours wouldn't be as messy, but certainly no reprise of Beach Blanket Bingo.

    Our ops demons and how we started taming them, after the jump.

    ]]> We face the same operational challenges as most small-to-mid-size development shops when prioritizing:

    multiple types of requesters with different levels of expertise
    Our requests come from a wide range of people, including senior managers, interns, contractors, developers, project managers, and designers. Each stakeholder has a different comfort level with and ability to describe technical problems and suggestions for improvement. Our process management system must accommodate all of our users, making it as easy as possible for them to log and track issues.

    multiple paths for making requests
    Folks stop by our desks, call us, email us, IM us, report bugs in tracking systems, and pass along problems while walking by the kitchen when we're nuking lunch. We don't want to limit the amount of human contact, but we do need a central repository that we encourage people to use.

    multiple types of requests
    We get everything from backend changes requiring a release to design reviews, documentation needs, and front-end changes. Often, the requestor doesn't understand the scope of what they're asking for or how it might impact other applications or users. We need a way of bucketing the same types of requests and providing an LOE estimate.

    different teams working at different levels at the same time
    On any given day, we have a mix of 40+ developers, information architects, project managers, designers, and product owners working on projects, production requests, and emergency and planned releases. They need to be able to filter by and switch from type to type with a minimum of effort, and they need to see what everyone else is working on.

    figuring out resource load
    We receive hundreds of requests a week and have a limited number of staff and contractors who can address them. Our work request system should ideally show us how much work each developer or designer has in his/her queue and allow us to adjust the load for peaks and lulls (not that we've seen much of the latter).

    Taking these key challenges into account, we established some process ground rules, which include:

    1. Jira isn't meant to take the place of human interaction. We use Jira to document, plan, track, and report on work requests and bugs. It's not like that fishing game at the community carnival where you cast your line over the wall and reel in your random prize when you feel a tug. We want our reporters to know exactly what they're getting, and we depend on them and many others to help us clarify and work collaboratively.

    2. Jira isn't the first point of contact in a true emergency. While it doesn't take much time to enter an issue and several folks are monitoring Jira throughout the workday, we don't have 24/7 coverage and we don't have any staff 100% dedicated to triaging Jira tickets as they come in. If our site is down or an editor on a breaking news deadline can't publish, folks call an emergency support number, come to our desks, or page us on the intercom. Only if necessary (sometimes after the fact) do we or they enter a Jira ticket.

    3. Product owners decide the priority of the issue. In the past, many requests requiring business analysis came to the developers for resolution. We tried to pull in product owners whenever possible, but it's a conflict of interest for developers to be setting product vision for stuff we don't own. Our new process makes product owners the first assignee by default.

    4. Only one person is responsible for a Jira issue. This rule addresses the challenges we have when someone sends a request to an email distribution list: multiple email threads start, it may not be clear who is working on it (or if anyone is working on it), and a lot of time could pass before it's resolved. The assignee is the person who has to do something with the issue -- even if it's as simple as assigning it to the right person to carry out the work. Other group members may be notified/watching, but only one person owns an issue at any given point. Throughout the lifecycle of an issue, product owners need to weigh in, but they generally don't execute the work for task.

    5. Closed issues stay closed. We often reopened bugs weeks or even months after they were closed, either to flag a recurrence of the same problem or to add comments about a new, related problem. Now, production code changes are tied to specific Jira requests, which enables more efficient troubleshooting and insight for future development. If a request goes live after UAT (User Acceptance Testing) and there's a production issue, it's a different problem and a new request is opened. We sometimes link to related issues to clarify the new problem.

    6. We're never done improving. We're treating the work request process like our bastardized Agile development process: we learn more as we use it and make adjustments as necessary. Since we launched, product owners received more Jira permissions in order to ease a triage bottleneck. We're working on determining our optimum velocity for planned releases. We still need to come up with an overall plan for prioritizing production requests, now that Jira has been open to all Digital Media users for a little over a month. We know we always can do better and try to be as flexible as possible.

    So, why did we end up choosing Jira? Find out in my next post, "You say Godzilla, I say Gojira."

    * I wish could take credit for the title of this post; Harold Neal (Senior Software Developer) said it while reviewing the Jira implementation plan.

    ]]> <p><a href="http://www.npr.org/blogs/inside/2009/10/jira_swapping_chaos_for_a_litt.html#email">&raquo; E-Mail This</a>&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://del.icio.us/post?url=http://www.npr.org/blogs/inside/2009/10/jira_swapping_chaos_for_a_litt.html">&raquo; Add to Del.icio.us</a> </p>     http://www.npr.org/blogs/inside/2009/10/jira_swapping_chaos_for_a_litt.html?ft=1&f=91000411 http://www.npr.org/blogs/inside/2009/10/jira_swapping_chaos_for_a_litt.html?ft=1&f=91000411 Administrative Stuff Thu, 08 Oct 2009 13:44:09 -0500     Journalism That Clicked By Mark Stencel Two of NPR's most ambitious multimedia projects -- "Planet Money" and "Climate Connections" -- collected prestigious awards for online journalism in the past week. The Online News Association gave its annual award for topical reporting and blogging by a large news Web site to Planet Money. The Planet Money team was set up last year to produce a series of on-air and online reports, blog posts and podcasts that explained the global economy. No easy task -- especially given the international financial crisis that was unfolding as the project made its debut last fall. "Planet Money provided a distinct value to a community of readers at a time when clear reporting on the financial crisis was just vital," the ONA judges said. "A lot of people were looking for and needed this information. The inaugural post that kicked off Planet Money was a feat of explanatory reporting. It stood out in an excellent field by the value it provided." The ONA prize, announced late Saturday at the organization's Online Journalism Awards banquet in San Francisco, came days after NPR collected another significant honor -- this one from The National Academies here in Washington. The National Academies is an influential scientific advisory organization comprising of the National Academy of Sciences, the National Academy of Engineering, the Institute of Medicine and the National Research Council. It gave its 2009 Communication Award for Internet journalism to NPR's online components of Climate Connections, a yearlong series developed in partnership with National Geographic to explain "how we are shaping climate" and "how climate is shaping us" -- subjects of considerable complexity and controversy. The Academies' prize for online journalism is one of four it awards each year with support from the W.M. Keck Foundation to recognize "excellence in reporting and communicating science, engineering, and medicine to the general public." "Singly, these are significant honors for NPR," Ellen Weiss, senior vice president for news and information, said in an e-mail to our staff on Monday afternoon. "We were competing with the best in our field -- including the New York Times and Wired. The awards illustrate the growing seamlessness between NPR News on the air and online, and they are a testament to the journalistic importance and integrity of our presence in the digital space." Planet Money and Climate Connections both represented major efforts to provide serious, in-depth reporting on complicated and important issues -- both online and on the air. All of us at NPR are thrilled for the staff who worked so hard on both of these projects. Mark Stencel is managing editor for digital news at NPR. By Mark Stencel

    Two of NPR's most ambitious multimedia projects -- "Planet Money" and "Climate Connections" -- collected prestigious awards for online journalism in the past week.

    The Online News Association gave its annual award for topical reporting and blogging by a large news Web site to Planet Money. The Planet Money team was set up last year to produce a series of on-air and online reports, blog posts and podcasts that explained the global economy. No easy task -- especially given the international financial crisis that was unfolding as the project made its debut last fall.

    "Planet Money provided a distinct value to a community of readers at a time when clear reporting on the financial crisis was just vital," the ONA judges said. "A lot of people were looking for and needed this information. The inaugural post that kicked off Planet Money was a feat of explanatory reporting. It stood out in an excellent field by the value it provided."

    The ONA prize, announced late Saturday at the organization's Online Journalism Awards banquet in San Francisco, came days after NPR collected another significant honor -- this one from The National Academies here in Washington.

    The National Academies is an influential scientific advisory organization comprising of the National Academy of Sciences, the National Academy of Engineering, the Institute of Medicine and the National Research Council. It gave its 2009 Communication Award for Internet journalism to NPR's online components of Climate Connections, a yearlong series developed in partnership with National Geographic to explain "how we are shaping climate" and "how climate is shaping us" -- subjects of considerable complexity and controversy. The Academies' prize for online journalism is one of four it awards each year with support from the W.M. Keck Foundation to recognize "excellence in reporting and communicating science, engineering, and medicine to the general public."

    "Singly, these are significant honors for NPR," Ellen Weiss, senior vice president for news and information, said in an e-mail to our staff on Monday afternoon. "We were competing with the best in our field -- including the New York Times and Wired. The awards illustrate the growing seamlessness between NPR News on the air and online, and they are a testament to the journalistic importance and integrity of our presence in the digital space."

    Planet Money and Climate Connections both represented major efforts to provide serious, in-depth reporting on complicated and important issues -- both online and on the air. All of us at NPR are thrilled for the staff who worked so hard on both of these projects.

    Mark Stencel is managing editor for digital news at NPR.

    ]]> <p><a href="http://www.npr.org/blogs/inside/2009/10/journalism_that_clicked.html#email">&raquo; E-Mail This</a>&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://del.icio.us/post?url=http://www.npr.org/blogs/inside/2009/10/journalism_that_clicked.html">&raquo; Add to Del.icio.us</a> </p>     http://www.npr.org/blogs/inside/2009/10/journalism_that_clicked.html?ft=1&f=91000411 http://www.npr.org/blogs/inside/2009/10/journalism_that_clicked.html?ft=1&f=91000411 Editorial Mon, 05 Oct 2009 16:44:09 -0500     Apply For A Travel Scholarship To PublicMediaCamp By Andy Carvin If you work at an NPR or PBS member station, you can now apply for a scholarship to attend PublicMediaCamp, scheduled for October 17-18 in Washington DC. We expect to award no more than 10 scholarships. Each of the station scholarships will cover basic travel-related expenses to attend PublicMediaCamp, as well as a $2,000 stipend towards that same station hosting a local PublicMediaCamp. One application per station, please. Scholarship Travel: Each station scholarship will cover basic travel-related reimbursements for one or two participants designated by the station to attend the PublicMediaCamp occurring in Washington DC Oct 17th and 18th. If sending two individuals to the unconference, one should be an employee of the station, but you have the option of having the second be a representative of a community organization that you will partner with to plan and host your local PublicMediaCamp. Such travel expenses may include: airfare, lodging, food and other expenses allowed by CPB travel guidelines. Local Event Stipend: In accepting a scholarship, the recipient station also commits to hosting a local PublicMediaCamp before September 1, 2010. An additional $2,000 stipend will be given scholarship recipients to offset organizing and hosting that local PublicMediaCamp. Note: Scholarship recipients (and all interested stations) will receive detailed information, documented processes, and tools to aid in hosting such events. Criteria: NPR and PBS will be selecting scholarship recipients -- pending CPB approval -- based on the applicant's experience with local community collaboration and ability to host a local PublicMediaCamp, and to create a balance of station market sizes and types (radio/TV). Deadline: Applications will be accepted until 5 p.m. ET on Wednesday, September 30, though will be considered on a rolling basis effective immediately. Please submit your information using this application form as soon as possible. Scholarship recipients will be notified immediately after being selected, and will be provided with information and process for booking and reimbursement of travel. By Andy Carvin

    If you work at an NPR or PBS member station, you can now apply for a scholarship to attend PublicMediaCamp, scheduled for October 17-18 in Washington DC.

    We expect to award no more than 10 scholarships. Each of the station scholarships will cover basic travel-related expenses to attend PublicMediaCamp, as well as a $2,000 stipend towards that same station hosting a local PublicMediaCamp. One application per station, please.

    Scholarship Travel: Each station scholarship will cover basic travel-related reimbursements for one or two participants designated by the station to attend the PublicMediaCamp occurring in Washington DC Oct 17th and 18th. If sending two individuals to the unconference, one should be an employee of the station, but you have the option of having the second be a representative of a community organization that you will partner with to plan and host your local PublicMediaCamp. Such travel expenses may include: airfare, lodging, food and other expenses allowed by CPB travel guidelines.

    Local Event Stipend: In accepting a scholarship, the recipient station also commits to hosting a local PublicMediaCamp before September 1, 2010. An additional $2,000 stipend will be given scholarship recipients to offset organizing and hosting that local PublicMediaCamp. Note: Scholarship recipients (and all interested stations) will receive detailed information, documented processes, and tools to aid in hosting such events.

    Criteria: NPR and PBS will be selecting scholarship recipients -- pending CPB approval -- based on the applicant's experience with local community collaboration and ability to host a local PublicMediaCamp, and to create a balance of station market sizes and types (radio/TV).

    Deadline: Applications will be accepted until 5 p.m. ET on Wednesday, September 30, though will be considered on a rolling basis effective immediately. Please submit your information using this application form as soon as possible. Scholarship recipients will be notified immediately after being selected, and will be provided with information and process for booking and reimbursement of travel.

    ]]> <p><a href="http://www.npr.org/blogs/inside/2009/09/apply_for_a_travel_scholarship.html#email">&raquo; E-Mail This</a>&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://del.icio.us/post?url=http://www.npr.org/blogs/inside/2009/09/apply_for_a_travel_scholarship.html">&raquo; Add to Del.icio.us</a> </p> <p> <a rel="nofollow" href="http://u.npr.org/adclick/utype=rss/aamsz=300x80/position=rss2/site=NPR/blog=91000411"> <img border="0" width="300" height="80" src="http://u.npr.org/iserver/utype=rss/aamsz=300x80/position=rss2/site=NPR/blog=91000411" /> </a> </p>     http://www.npr.org/blogs/inside/2009/09/apply_for_a_travel_scholarship.html?ft=1&f=91000411 http://www.npr.org/blogs/inside/2009/09/apply_for_a_travel_scholarship.html?ft=1&f=91000411 PubCamp PublicMediaCamp Tue, 15 Sep 2009 16:51:51 -0500     NPR News iPhone App Upgrade Includes Sharing, Audio Controls and More By Demian Perry, Robert Spier and Daniel Jacobson The NPR News iPhone app launched on August 15 and the feedback has been tremendous! But we are not content to leave well-enough alone... Today, we launched our first upgrade to the app (version 1.1). Many of the changes in this version were implemented based on your feedback via the NPR Facebook page, Twitter, other posts on this blog, iTunes reviews, etc. We built this app for you, the users, so we took your comments to heart. This release includes a lot of improvements. Most of these are "behind-the-scenes" changes to improve performance, minor layout issues and smaller feature enhancements. But there are some major additions as well, including: Sharing Tools With this release, you are now able to share stories via e-mail, Facebook and Twitter. All three sharing functions are performed within the app itself, so you can continue to listen to the story while you share it. Audio Controls One of the most frequent comments about the app has been that there was no way to pause the audio and continue where you left off. This version adds the pause button to on-demand audio, such as programs and news segments. We also added "scrubbing", which allows you to fast-forward or rewind within either program- or story-audio segments. Image Enlargement For any story that contains a photo, we have added the ability to tap on the image to see a larger version of it. Again, most of the changes for this are directly a result of your feedback. If you would like to see other features in the next version of the app, which we are already working on, please let us know. You can write us directly at techcenter at npr dot org, tweet us at NPRTechTeam or post comments to this blog. By Demian Perry, Robert Spier and Daniel Jacobson

    The NPR News iPhone app launched on August 15 and the feedback has been tremendous! But we are not content to leave well-enough alone... Today, we launched our first upgrade to the app (version 1.1). Many of the changes in this version were implemented based on your feedback via the NPR Facebook page, Twitter, other posts on this blog, iTunes reviews, etc. We built this app for you, the users, so we took your comments to heart.

    This release includes a lot of improvements. Most of these are "behind-the-scenes" changes to improve performance, minor layout issues and smaller feature enhancements. But there are some major additions as well, including:

    Sharing Tools
    With this release, you are now able to share stories via e-mail, Facebook and Twitter. All three sharing functions are performed within the app itself, so you can continue to listen to the story while you share it.

    Audio Controls
    One of the most frequent comments about the app has been that there was no way to pause the audio and continue where you left off. This version adds the pause button to on-demand audio, such as programs and news segments. We also added "scrubbing", which allows you to fast-forward or rewind within either program- or story-audio segments.

    Image Enlargement
    For any story that contains a photo, we have added the ability to tap on the image to see a larger version of it.

    Again, most of the changes for this are directly a result of your feedback. If you would like to see other features in the next version of the app, which we are already working on, please let us know. You can write us directly at techcenter at npr dot org, tweet us at NPRTechTeam or post comments to this blog.

    ]]> <p><a href="http://www.npr.org/blogs/inside/2009/09/npr_news_iphone_app_upgrade_in.html#email">&raquo; E-Mail This</a>&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://del.icio.us/post?url=http://www.npr.org/blogs/inside/2009/09/npr_news_iphone_app_upgrade_in.html">&raquo; Add to Del.icio.us</a> </p>     http://www.npr.org/blogs/inside/2009/09/npr_news_iphone_app_upgrade_in.html?ft=1&f=91000411 http://www.npr.org/blogs/inside/2009/09/npr_news_iphone_app_upgrade_in.html?ft=1&f=91000411 Mobile Fri, 11 Sep 2009 20:26:59 -0500     Registration Now Open For PublicMediaCamp By Andy Carvin For those of you who have been following our posts on PublicMediaCamp, I just wanted to let you know that registration is now open, as is the official PublicMediaCamp Web site. On October 17-18 in Washington DC, NPR and PBS will team up with The AU Center for Social Media and iStrategyLabs to host this unconference, focusing on exploring new forms of collaboration between public broadcasters and their communities. The event will kick off what we hope will be a series of local PublicMediaCamps hosted by stations and other community partners. Registration is free, and you should sign up as soon as possible; we've got room for around 350 people and we're almost one-third full in just the first 24 hours of registration. If you plan to attend, please be sure to visit the Web site and its wiki, as that's where we'll be planning the sessions. You can also join the PublicMediaCamp Google Group; we expect conversations to kick off there some time next week. By Andy Carvin

    For those of you who have been following our posts on PublicMediaCamp, I just wanted to let you know that registration is now open, as is the official PublicMediaCamp Web site. On October 17-18 in Washington DC, NPR and PBS will team up with The AU Center for Social Media and iStrategyLabs to host this unconference, focusing on exploring new forms of collaboration between public broadcasters and their communities. The event will kick off what we hope will be a series of local PublicMediaCamps hosted by stations and other community partners.

    Registration is free, and you should sign up as soon as possible; we've got room for around 350 people and we're almost one-third full in just the first 24 hours of registration. If you plan to attend, please be sure to visit the Web site and its wiki, as that's where we'll be planning the sessions. You can also join the PublicMediaCamp Google Group; we expect conversations to kick off there some time next week.

    ]]> <p><a href="http://www.npr.org/blogs/inside/2009/09/registration_now_open_for_publ.html#email">&raquo; E-Mail This</a>&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://del.icio.us/post?url=http://www.npr.org/blogs/inside/2009/09/registration_now_open_for_publ.html">&raquo; Add to Del.icio.us</a> </p>     http://www.npr.org/blogs/inside/2009/09/registration_now_open_for_publ.html?ft=1&f=91000411 http://www.npr.org/blogs/inside/2009/09/registration_now_open_for_publ.html?ft=1&f=91000411 PubCamp PublicMediaCamp collaboration stations unconferences Fri, 11 Sep 2009 15:17:10 -0500     Introducing The NPR Gadget For iGoogle By Jon Foreman Please welcome the latest NPR API-powered app: it's the NPR gadget for iGoogle. You can check out the gadget for yourself by adding it to your iGoogle page. Produced in collaboration with Google, the gadget offers maximum convenience to iGoogle users since content can be consumed entirely within iGoogle. It is possible to scan headlines, listen to audio, read stories, share stories, set up custom feeds, display the headlines of a favorite topic and even play the 'Wait Wait...Don't Tell Me!' news quiz all within the confines of a customized iGoogle page. Most of the items displayed in the gadget are delivered via the NPR API: headlines, story text, story audio and related story links. Items that don't make use of the API are the The Wait Wait...Don't Tell Me! quiz which is driven by a custom XML document, the sponsorship banner powered by JavaScript and the hourly news and program stream which are direct links to an mp3 file and stream respectively. Stories in the gadget can also be shared with friends -- this is powered by iGoogle's latest social features. Here are some screen shots of the gadget: Home View ( / )--> Canvas View ( / )--> Story View ( / )--> Quiz ( / )--> By Jon Foreman

    Please welcome the latest NPR API-powered app: it's the NPR gadget for iGoogle. You can check out the gadget for yourself by adding it to your iGoogle page.

    Produced in collaboration with Google, the gadget offers maximum convenience to iGoogle users since content can be consumed entirely within iGoogle. It is possible to scan headlines, listen to audio, read stories, share stories, set up custom feeds, display the headlines of a favorite topic and even play the 'Wait Wait...Don't Tell Me!' news quiz all within the confines of a customized iGoogle page.

    Most of the items displayed in the gadget are delivered via the NPR API: headlines, story text, story audio and related story links. Items that don't make use of the API are the The Wait Wait...Don't Tell Me! quiz which is driven by a custom XML document, the sponsorship banner powered by JavaScript and the hourly news and program stream which are direct links to an mp3 file and stream respectively. Stories in the gadget can also be shared with friends -- this is powered by iGoogle's latest social features.

    Here are some screen shots of the gadget:

    Home View

    gadget home view

    ]]>

    Canvas View

    gadget home view


    Story View

    gadget home view

    Quiz

    gadget home view

    ]]> <p><a href="http://www.npr.org/blogs/inside/2009/09/npr_gadget_for_igoogle.html#email">&raquo; E-Mail This</a>&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://del.icio.us/post?url=http://www.npr.org/blogs/inside/2009/09/npr_gadget_for_igoogle.html">&raquo; Add to Del.icio.us</a> </p>     http://www.npr.org/blogs/inside/2009/09/npr_gadget_for_igoogle.html?ft=1&f=91000411 http://www.npr.org/blogs/inside/2009/09/npr_gadget_for_igoogle.html?ft=1&f=91000411 3rd Party Tools API API gadgets iGoogle Wed, 02 Sep 2009 13:51:21 -0500     Why NPR.org Scrapped The Fees And Made Transcripts Free By Bruce Melzer One of the biggest changes we made with the launch of the new NPR.org was offering free transcripts on the site. Ever since NPR started transcribing its radio programs in 1990, we have been selling transcripts to help defray the costs of producing them. In the old days, we used to mail out copies of the transcripts, a time-consuming and expensive process for all involved. In 2002 we added e-commerce to the transcript operation and were able to drop the prices and deliver the transcripts via email. Why did we give up this revenue stream? First and foremost, the users expect to be able to come to our site and read the story they heard on the air. As rich as the radio stories are, reading is faster than listening, our users told us. Although we were writing Web versions of many radio stories, a number of stories still didn't have much text. Making transcripts free solved that. A second reason is accessibility for deaf and hard-of-hearing users. Although NPR has always had a policy of providing free transcripts to these users, we eliminated the need for them to contact us for transcript copies. There are solid business reasons for making transcripts free. Sales have been dropping over the years. As people search for, discover and share content, offering free transcripts will boost the traffic to NPR.org, traffic that can be monetized with sponsorship. Finally, search engines like text. Many of our stories could not be found by the search engines because they did not have enough text. Now it will be easier for the search engines -- and ultimately the users -- to find and enjoy NPR's stories. By Bruce Melzer

    One of the biggest changes we made with the launch of the new NPR.org was offering free transcripts on the site. Ever since NPR started transcribing its radio programs in 1990, we have been selling transcripts to help defray the costs of producing them. In the old days, we used to mail out copies of the transcripts, a time-consuming and expensive process for all involved. In 2002 we added e-commerce to the transcript operation and were able to drop the prices and deliver the transcripts via email.

    Why did we give up this revenue stream? First and foremost, the users expect to be able to come to our site and read the story they heard on the air. As rich as the radio stories are, reading is faster than listening, our users told us. Although we were writing Web versions of many radio stories, a number of stories still didn't have much text. Making transcripts free solved that.

    A second reason is accessibility for deaf and hard-of-hearing users. Although NPR has always had a policy of providing free transcripts to these users, we eliminated the need for them to contact us for transcript copies.

    There are solid business reasons for making transcripts free. Sales have been dropping over the years. As people search for, discover and share content, offering free transcripts will boost the traffic to NPR.org, traffic that can be monetized with sponsorship. Finally, search engines like text. Many of our stories could not be found by the search engines because they did not have enough text. Now it will be easier for the search engines -- and ultimately the users -- to find and enjoy NPR's stories.

    ]]> <p><a href="http://www.npr.org/blogs/inside/2009/08/why_nprorg_scrapped_the_fees_a.html#email">&raquo; E-Mail This</a>&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://del.icio.us/post?url=http://www.npr.org/blogs/inside/2009/08/why_nprorg_scrapped_the_fees_a.html">&raquo; Add to Del.icio.us</a> </p>     http://www.npr.org/blogs/inside/2009/08/why_nprorg_scrapped_the_fees_a.html?ft=1&f=91000411 http://www.npr.org/blogs/inside/2009/08/why_nprorg_scrapped_the_fees_a.html?ft=1&f=91000411 Mon, 24 Aug 2009 16:22:36 -0500     API Presentation at CPB By Daniel Jacobson Last week, at the request of Rob Bole, I gave a presentation on NPR's API to the staff of CPB. This presentation was the first in a series that Rob is hosting to expose the staff of the CPB to the rapidly changing technology advancements in the digital media space. This presentation is largely similar to the presentation I prepared for OSCON, with a few differences. The OSCON presentation focuses more on the technology of the API and digs a little more into the usage from a technical perspective. In the CPB presentation, on the other hand, I spent more time explaining what API's are, why they are useful, and the particular reasons why NPR built the ones that we have. Both presentations share a lot of the more interesting uses of the API across the four major target audiences: NPR, stations, partners and the public. So, here is the full CPB presentation. Click here to view the presentation (requires Adobe Acrobat) By Daniel Jacobson

    Last week, at the request of Rob Bole, I gave a presentation on NPR's API to the staff of CPB. This presentation was the first in a series that Rob is hosting to expose the staff of the CPB to the rapidly changing technology advancements in the digital media space.

    This presentation is largely similar to the presentation I prepared for OSCON, with a few differences. The OSCON presentation focuses more on the technology of the API and digs a little more into the usage from a technical perspective. In the CPB presentation, on the other hand, I spent more time explaining what API's are, why they are useful, and the particular reasons why NPR built the ones that we have. Both presentations share a lot of the more interesting uses of the API across the four major target audiences: NPR, stations, partners and the public.

    So, here is the full CPB presentation.




    Click here to view the presentation (requires Adobe Acrobat)

    ]]> <p><a href="http://www.npr.org/blogs/inside/2009/08/api_presentation_at_cpb.html#email">&raquo; E-Mail This</a>&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://del.icio.us/post?url=http://www.npr.org/blogs/inside/2009/08/api_presentation_at_cpb.html">&raquo; Add to Del.icio.us</a> </p>     http://www.npr.org/blogs/inside/2009/08/api_presentation_at_cpb.html?ft=1&f=91000411 http://www.npr.org/blogs/inside/2009/08/api_presentation_at_cpb.html?ft=1&f=91000411 API API CPB Presentation Mon, 24 Aug 2009 10:30:58 -0500     Incorporating Your Feedback Into The Next iPhone App Release By Demian Perry The next version of our NPR News iPhone app will include audio scrubbing and a pause button. (Calvin Carter / Bottle Rocket) I mentioned in my last post that the design of the NPR News app was based largely on ideas and suggestions from a panel of NPR listeners and heavy iPhone users. Immediately after launch, NPR ended the project precisely where it had begun: in consumer research. Through structured interviews and hours of videotaped close-ups of people playing with the NPR News app, we discovered several ways to improve the app. Because we failed to provide users with the ability to pause and skip ahead within an audio piece, our early testers were occasionally frustrated by the listening experience. We also learned that the distinction between news you read and news you listen to, once so clear to us, was lost on users. Our listeners also helped us see that the playlist, while intuitive, was hard to manage for certain tasks. In the hours that followed our release, we continued to track and learn from the comments in the app store and in our twitter feed. A couple of users discovered an error in the way some articles display, and we heard, time and again, of the need for better audio controls. Scott Stroud, in our user experience group, assembled the comments into a list of recommendations for our next version of the app. Some of the improvements, such as a more intuitive playlist interface, will take a major code rewrite that may not be available until later this fall. But our listeners also helped us to see a few ideas for improving the app that would be relatively easy to implement. Here, then, are the features slated for release within the next few weeks: Pause button - While listening to a piece, users will be able to pause playback and return to the audio later, exactly where they left off. Audio Scrubbing - Also while listening, users will soon be able to skip ahead to a particular place in an audio file. Sharing - Want to share NPR stories with your friends? We're adding support for Facebook and Twitter, as well as a way to send stories via the iPhone's native email application. Listener comments from the iPhone app release will also help us to improve the design of the other apps we have in development. Michael Frederick, a developer at Google who is leading our Android project, has created an intuitive player experience that seems to be in line with user comments and with the recommendations from our user experience group. The Symbian Foundation has also listened intently to the comments and recommendations from NPR listeners, and they're focusing the bulk of the effort for their upcoming NPR app on creating a fully-featured audio player. As you're making your own list of improvements, please share them with us. We really appreciate those five star reviews, but we also appreciate your suggestions for improvement, because they help us know where to focus our efforts. By Demian Perry

    NPR News iPhone 1.1 screenshot

    The next version of our NPR News iPhone app will include audio scrubbing and a pause button. (Calvin Carter / Bottle Rocket)

    I mentioned in my last post that the design of the NPR News app was based largely on ideas and suggestions from a panel of NPR listeners and heavy iPhone users. Immediately after launch, NPR ended the project precisely where it had begun: in consumer research.

    Through structured interviews and hours of videotaped close-ups of people playing with the NPR News app, we discovered several ways to improve the app. Because we failed to provide users with the ability to pause and skip ahead within an audio piece, our early testers were occasionally frustrated by the listening experience. We also learned that the distinction between news you read and news you listen to, once so clear to us, was lost on users. Our listeners also helped us see that the playlist, while intuitive, was hard to manage for certain tasks.

    In the hours that followed our release, we continued to track and learn from the comments in the app store and in our twitter feed. A couple of users discovered an error in the way some articles display, and we heard, time and again, of the need for better audio controls.

    Scott Stroud, in our user experience group, assembled the comments into a list of recommendations for our next version of the app. Some of the improvements, such as a more intuitive playlist interface, will take a major code rewrite that may not be available until later this fall.

    But our listeners also helped us to see a few ideas for improving the app that would be relatively easy to implement. Here, then, are the features slated for release within the next few weeks:

    • Pause button - While listening to a piece, users will be able to pause playback and return to the audio later, exactly where they left off.
    • Audio Scrubbing - Also while listening, users will soon be able to skip ahead to a particular place in an audio file.
    • Sharing - Want to share NPR stories with your friends? We're adding support for Facebook and Twitter, as well as a way to send stories via the iPhone's native email application.

    Listener comments from the iPhone app release will also help us to improve the design of the other apps we have in development. Michael Frederick, a developer at Google who is leading our Android project, has created an intuitive player experience that seems to be in line with user comments and with the recommendations from our user experience group.

    The Symbian Foundation has also listened intently to the comments and recommendations from NPR listeners, and they're focusing the bulk of the effort for their upcoming NPR app on creating a fully-featured audio player.

    As you're making your own list of improvements, please share them with us. We really appreciate those five star reviews, but we also appreciate your suggestions for improvement, because they help us know where to focus our efforts.

    ]]> <p><a href="http://www.npr.org/blogs/inside/2009/08/incorporating_your_feedback_in.html#email">&raquo; E-Mail This</a>&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://del.icio.us/post?url=http://www.npr.org/blogs/inside/2009/08/incorporating_your_feedback_in.html">&raquo; Add to Del.icio.us</a> </p> <p> <a rel="nofollow" href="http://u.npr.org/adclick/utype=rss/aamsz=300x80/position=rss3/site=NPR/blog=91000411"> <img border="0" width="300" height="80" src="http://u.npr.org/iserver/utype=rss/aamsz=300x80/position=rss3/site=NPR/blog=91000411" /> </a> </p>     http://www.npr.org/blogs/inside/2009/08/incorporating_your_feedback_in.html?ft=1&f=91000411 http://www.npr.org/blogs/inside/2009/08/incorporating_your_feedback_in.html?ft=1&f=91000411 Mobile NPR News App feedback iPhone user experience Wed, 19 Aug 2009 16:59:37 -0500