If you're among the estimated 120,000 Apple enthusiasts who signed up to get an iPad on April 3, rest assured that you'll be able to experience the NPR Web site in all its glory.

Our designers and developers have been hard at work the past few weeks adapting the site to the iPad's unique requirements.

From day one, iPad users who visit the NPR Web site will get an experience that is optimized for the device. Features like the NPR audio player have been given greater visibility and adapted for the unique technical requirements of this new platform; we've modified the navigation and made the site more "touch" friendly; and we've improved the sponsorship experience -- all without changing the main site.

The good news is it was all relatively easy to accomplish because of changes we made about nine months ago that make it simpler to adapt our systems to new platforms and new devices.

At the same time we're optimizing the Web site, we're also developing a companion "app" for the iPad -- one that builds on what we've learned from the iPhone, but takes full advantage of the new device's larger format. Like the iPhone app, the iPad app will prominently feature public radio streams and on-demand programming from around the nation, in addition to plenty of reading material.

So you'll have your pick of NPR experiences on this new device. It's all part of a broader effort to make NPR and member station content available wherever and whenever you want it and to position ourselves at the forefront of innovation.

As we get closer to launch, the NPR staffers who have been most closely involved in the effort will describe some of the work that went on behind the scenes. In the meantime, they're racing the clock to make sure we're ready for the April 3 release.

Kinsey Wilson is Senior Vice President and General Manager of NPR Digital Media.

NPR means a lot of things to a lot of different people. For some, it means great radio programming, while others may think of rich photo galleries, our iPhone app or our music coverage.

Well, we are happy to add one more thing to that list: NPR can now be known for having the tiniest shortened domain name for Twitter: n.pr. Others may be equally short, but none shorter, since it uses the minimum characters allowed in a domain name.

I know what you are thinking... Isn't npr.org short enough? Normally, yes, but Twitter only allows messages to contain 140 characters. Shorter URLs are better since they give users more room to add their own thoughts in a tweet. So when we had the opportunity to acquire n.pr - .pr is the top-level domain for Puerto Rico - we couldn't pass it up. Our regular URL, npr.org, will continue to be the primary domain for NPR, but we're going to start rolling out n.pr for Twitter use.

Right now, n.pr will work with an NPR.org page's story ID. For example, here's the normal URL for a story from NPR Music:

http://www.npr.org/templates/story/story.php?storyId=124212838

As is plain to see, this URL is rather long - 62 characters. Compare that to the shortened version of the URL, which is only 21 characters:

http://n.pr/124212838

Our plan is to introduce n.pr to various areas of our system over time. We also hope to go even shorter than this as we experiment with hashes to reduce the length of the story ID. We're planning to use the shortened URL when we distribute NPR stories through our main Twitter accounts, as well as when you use the "share" link on any story page, so you can post the link via your own Twitter account. So if you're on Twitter, stay tuned - expect to see lots of n.pr links in the near future.

Special thanks to Pablo Rodriquez at nic.pr, the Puerto Rico Top Level Domain, without whom we would not have been able to secure the domain.

Meaning. Framework. Storytelling. Social Good. These were some of the themes manifest during this year's IXD10 conference in Savannah, Georgia.

Since this is my inaugural post to the blog, let me start by defining what I do at NPR. I am a senior interaction designer in the user experience (commonly known as "UX") group. "What the heck is an interaction designer?" you might ask. The IxDA (Interaction Design Association) defines it succinctly:

Interaction Design (IxD) defines the structure and behavior of interactive products and services. Interaction Designers create compelling relationships between people and the interactive systems they use, from computers to mobile devices to appliances; Interaction Designers lay the groundwork for intangible experiences.

Now that that's out of the way, back to my weekend in Savannah. I attended the conference with Scott Stroud, one of the senior UX architects in our group. While the mid-Atlantic was disappearing under three feet of snow, we were in balmy, snow-free Georgia, listening to fellow interaction design professionals present their research, work practices and inspiring thoughts on the discipline.

The keynote speaker, Nathan Shedroff, co-author of Making Meaning: How Successful Businesses Deliver and chair of the California College of Art's Design MBA program, spoke about innovating meaningful experiences, focusing on triggers (i.e., attributes usually associated with the end of the design cycle -- sight, sound, smell, taste, touch, concepts, symbols), and significance (i.e., meaning, status/identity, emotion/lifestyle, price, and function) to create meaning from the inside out. As I sat there listening, I thought about how easy this aspect of design is for me at NPR. The meaning is there, in spades. NPR is one of those ethereal brands that speaks to its consumers on a gut level. People don't just listen to NPR or trust NPR. They love NPR on a visceral level. And it's because of the meaningful experiences we provide to millions on a daily basis.

Other highlights included a talk by Alexis Lloyd, a creative technologist with the New York Times R&D group. In her presentation, she discussed her research on the future of news consumption and how users will interact with journalism and media in the next 2-10 years. She anticipates that news providers will balance social activity, personal preference, editorial judgment and smart recommendations via real-time streams of content.

I was also inspired by Liz Danzico's presentation on improvisation's role in the design process, Cindy Chastain's assertions that interaction design has a lot more in common with screenwriting and storytelling than you might think, and especially Paola Antonelli's keynote on her work as senior curator of architecture and design at the Museum of Modern Art in New York. If you didn't get to see her last major exhibit, Design and the Elastic Mind, you missed out. But she's working on her next one, Talk To Me, which explores ways in which, through the products they create, designers write scripts that facilitate and shape cultural dialogue.

We hope to establish a consistent presence on this blog for those interested in how design manifests itself at NPR. Watch for us here and you can also follow us on our new Twitter account, @nprdesign.

By Kim Bryant

For those of you gung ho to get your geek on (and I mean that in the nicest possible way), this post is designed to give you the skinny on some of our basic Jira configurations. Not much philosophizing, but chock full of grainy-detailed goodness. Dig in!

User Types (Roles)
We have 5 main user types, what Jira calls "roles:" Component Lead, Project Administrator, Project Manager, Resource (developers, UX and designers), and Users.

Component leads are also usually Product Owners. They are responsible for specific products, driving the road map, and the work prioritization of a specific product. In Jira, they triage, enter, track and ensure completion of tasks. As I mentioned in my first post of this series, Jira automatically assigns tasks to component leads, though some users have the ability to change the assignee to someone else.

Project Administrators own a specific Jira project and have more permissions than most user roles. They can create components, assign component leads, set default assignees to a component, create new versions, and release and archive versions. For obvious reasons, there are only a few people with this role.

Project Managers are project managers at NPR, not just in Jira. They need some specific permissions in Jira that allow them to execute a handful of actions usually only given to Jira Project Administrators. For example, they can force tasks through specific workflow states, but they can't create or release versions.

Resources carry out the actual work required by the issue and include staff from the user experience, design, and development groups. Resources are usually assignees in Jira.

Users are our most basic role and usually stakeholders, managers, and business owners. They use Jira infrequently, and most often for logging bugs or enhancement requests.

NPR Jira's projects and similarly crunchy nuts and bolts, after the jump.

Digital Media Projects -- Contains medium to large projects that product owners, resources, and Digital Media managers need have on their radar (basic Jira users don't see this area). A Jira filter is used to generate a list of active, on hold, and proposed items for discussion in a weekly project status meeting.

Digital Media Requests -- Familiarly known around NPR by its Jira key, WWW, this is the big bucket where every user can submit requests and is the most heavily-trafficked section. Product owners and managers are watching for incoming requests to triage and teeing up items for future planned releases, resources are managing their work queues and reporting progress on their tasks, reporters are logging and verifying whether or not issues have been fixed, and administrators are cleaning up stragglers and misplaced items. There only two types of issues in this project: requests and immediates. The latter is for reporting issues that are urgent but not emergencies; we aim for someone to provide a substantive reply to an immediate ticket -- if not a fix -- within four to eight business hours.

Components for Digital Media Projects and Requests are very similar and we try to keep this list easy to use and as short as possible: API, blogs, contact forms/help, mobile/portable media, music, newsletters/viral, NPR Community, overall site, player/streaming, registration, Seamus (our content management system), search, sponsorship, strategy, and Web analytics. The only difference is that each project has one additional component: Digital Media Projects has "strategy" and Digital Media Projects has "editorial graphics."

Software -- This area is for the use of the Applications team, though all Jira users have at least read-only access. The really technical tasks show up here -- often gobbledygook to non-technical folks, but it allows a complex Digital Media Request to be mapped to many fine details in Software and those fine details to be mapped to our code base (via SVN). For example, someone might log a WWW task to (ahem) migrate databases from Oracle to MySQL. That one WWW task could be linked to multiple, intricate Software tasks performed by many resources.
Components: aggregations, blogs, crowd, miscellaneous, music, Seamus, story, www

Sys Admins -- As you might guess, the Digital Media team's system administrators use this area. We've allowed all users to enter tickets here because it includes tasks like setting up access to file servers for editors. Remembering this can be a bit challenging for those who use Jira rarely, though, so it's possible this area will evolve into something more like the Software project: a Jira project where the sys admin team can track and enter their own tasks.
Components: Atlassian dev tools, Confluence, Crowd, Jira, SVN, www

Application Errors -- this project collects automatically-generated errors from servers and creates Jira tickets. Jason Grosman wrote an inside npr.org post about this cool process. You can read more about it here.
Components: CMS, Javascript, www

Versions
We use a straightforward, 3-digit system in the Software project for managing releases. The first digit is for a major release, the second for a planned release (usually every 2 weeks), and the last digit is for emergencies. These versions are tagged and mapped to other tools we use, like SVN, Crucible, and Confluence. The Digital Media Projects project doesn't really have releases in the traditional sense; because we're using it as a portfolio roadmap, we use fiscal year quarters to indicate roughly when a project will launch. The Sys Admins and Application Errors projects don't require releases, but it's easy enough to add them if we need to in the future.

The Digital Media Requests project has the most complex versions, hands down. We created a cheat sheet for the Jira users who can see this field.
1. Unknown -- The default selected when most users create a Jira issue. An issue will not usually stay in this version.

2. Production requests -- Doesn't require a backend code release from the application team (e.g., CSS changes, editorial graphics)

3. Backlog -- A pool of potential work from which product owners pull candidates for planned releases. These issues sometimes require more thought or strategy before they can be implemented and often require a backend code release. They may be larger in scope/difficulty, or smaller, more obscure, or difficult to reproduce. If an issue is in the backlog, a resource is not fixing it yet.

4. Lobby -- Short-term holding pen for issues being considered for the next planned release. These may be returned to the backlog or moved into a planned release, depending on how the group of product owners prioritizes the lobby issues. If an issue is in the lobby, a resource is not fixing it yet.

5. Planned release -- Regularly-scheduled backend code releases. Items for these releases are chosen by product owners and key stakeholders. They are given names in alphabetical order. (e.g., Dino, Elmer, Foghorn, Gideon). If an issue is in a planned release, a resource is actively addressing it.

6. Emergency -- A backend code release to address one or more issues that are so urgent or badly broken, we cannot wait until the next planned release to push them live. An emergency release is followed by a 3-digit number to help the applications team map it to the code base (e.g., emergency 2.0.4, emergency 2.5.1). If an issue is in an emergency release, a resource is actively addressing it.

Some of our plugins and additional functionality:
1. GreenHopper -- Agile tool recently purchased by Atlassian. Allows for drag-and-drop story cards and burn-down charts. We're hoping this is more tightly integrated in a future Jira release, but it's a great start. We used the ranking portlet heavily during the npr.org redesign project to figure out tasks had to be done before others. Now it's a tool for roughly ranking the relatively importance of our Digital Media Projects.

2. Jira calendar -- Displays past and future release dates in a calendar view, which we post by default on our dashboard.

3. Jira Timetracking -- Enables sophisticated time tracking, including initial LOE estimates, "time remaining" adjustment after a task is in progress, and stop/start buttons for real-time tracking. The last item is unrealistic for NPR's responsive culture (e.g., important news pops up unexpectedly and we have to do stuff to support it), but it's still pretty nifty if you want to track a solid block of coding effort.

4. Jira Charting -- Used to display metrics and stats, especially on the custom metrics dashboard we designed for managers.

5. Bulk Move Restore Fields -- A lifesaver in the early days of our using Jira, it allowed us to restore versions and components after we migrated a horde of issues from one project to another. Repeatedly. Good to have in your back pocket if you are allowing rapid evolution of Jira as you discover how your organization uses it in the real world.

We're still tweaking how we use Jira, and we always will. We recently discovered that we needed to add a workflow status to one of our projects so it's clear when the next step can begin. Also on the horizon is an upgrade to a more recent version of all the Atlassian tools. We're currently rock-solid on Jira 3.13.2, but there are definitely some bells and whistles we're itching to get our hands on. Complex searching, easier-to-customize dashboards, and a history that follows you to wherever you're logged in are just a few of the features we're looking forward to trying in version 4.

By Andy Carvin (@acarvin)

It's been just over one week since a devastating earthquake struck Haiti. As relief organizations rushed to the scene and ordinary people opened their wallets to support the disaster response, hundreds of techies from around the world have also stepped up to offer their unique skills to these efforts.

In the five years since the 2004 Boxing Day tsunami, more and more software developers, designers and bloggers have offered their services to a wide range of relief projects. I've been involved with many of them, and am helping out with Haiti efforts as well. This time around, much of the activity has come together around a virtual project known as CrisisCommons, which last year held an Barcamp-like event called CrisisCamp, challenging techies to brainstorm ways to build digital tools that support relief efforts. The CrisisCommons volunteers kicked into high gear last week, wasting no time in organizing a series of CrisisCamps last Saturday in half a dozen cities around the US.

I participated in the DC CrisisCamp, hosted by the Sunlight Foundation, and it was a remarkable event. Nearly 200 of us gathered over the course of nine hours to work on a variety of projects, such as GPS-powered mobile maps of Haiti with the latest satellite imagery and incident reports, to an English-Creole dictionary that can be downloaded to iPhones and Android phones. The app, called Tradui (translate in Creole), is currently available in the Android Market and is waiting to be approved for the iPhone app store.

Meanwhile, I've pulled together a team of information architects and researchers to start creating a wiki that serves as a sort of Yellow Pages for disaster and emergency preparedness resources that can be deployed for any disaster. We did something similar for the 2008 hurricane season on a wiki called HurricaneWiki.org. This new wiki will allow us to document resources related to Haiti, but also allow us to add new sections easily if a tornado were to strike Kansas, for example, or if dengue fever broke out in Southeast Asia.

The crisis response team at Google has taken the lead in unifying all the various collections of missing persons lists, from Facebook and news Web sites to the Red Cross. And it's already getting use - the Haitian embassy is utilizing this database as a tool for coordinating their efforts back home. A list of the various projects can be found at CrisisCommons.org.

Despite all the work that's been done already, there's still a lot left for us to do -- so much so that we're organizing another round of CrisisCamps this coming Saturday. NPR will host CrisisCamp DC, and we'll also have events in Boston, Denver, LA, Miami, New York, Portland and Silicon Valley. Even more cities may organize their own camps -- I'll post updates as they happen.

It's not just techies who are coming to these events -- we're also looking for people who are really good at doing online research, for example, or anyone who speaks either French or Creole. Even if you don't have any specific skills and want to help out with event logistics, we can probably put you to work. So if you're free this Saturday and live in a city hosting a camp, please consider participating. Even if you can't attend, there may be ways you can volunteer online. Visit CrisisCommons.org to learn more about the projects.

One of the biggest projects to come out of the many online volunteer efforts in response to the Haiti earthquake is the Person Finder widget. Created by Google's Crisis Response Team, the widget allows you to search a database of missing people in Haiti, as well as to add new people to it. Here's the code to embed it:

<iframe

    src="http://haiticrisis.appspot.com/?small=yes"

    width=350 height=300 frameborder=0

    style="border: dashed 2px #77c"></iframe>

  

One of the most personally gratifying things to come out of this effort is the fact that Google is using PeopleFinder Interchange Format (PFIF) to process the missing persons report. PFIF was created in the days and weeks following Hurricane Katrina, during which time many websites served as ad hoc collections of missing persons information, often published by family and friends in a narrative format. While this format made for powerful, heartbreaking reading, it meant there was no easy way to organize all of this data into a single database. So a group of volunteers created PFIF as a way of structuring this data, then mobilized literally thousands of other volunteers to convert these collections of missing persons information into PFIF.

We've seen the same thing happen over the last week - websites from CNN.com to Facebook have attracted thousands of posts from members of the public looking for loved ones in Haiti. With the creation of the Person Finder widget, it's now possible for any website to host a simple mechanism for posting or finding missing persons information. Some sites, including NYTimes.com, have managed to export their collections into PFIF. In other cases, volunteers have either converted missing persons lists by hand or have written scripts to scrape the information from other sites and send it to Google as a spreadsheet. And as of today, there's even an API to make this process even easier.

If you haven't explored the widget yet, please try it out. And if you have a Web site where you can publish it, please consider embedding it on your site.

If you're a software developer, designer, database guru or any other type of geek who's got some free time on Saturday and wants to volunteer in response to the Haiti earthquake, be sure to check out CrisisCamp. Taking place in various cities across the US and in the UK tomorrow, these events will bring together technologists to tackle a variety of projects, such as building interactive maps of the earthquake zone, wikis, missing persons databases and other resources. Dozens of tech volunteers from around the world have been working on these projects all week, and CrisisCamp will be a chance for many of them to collaborate in person and kick them into high gear.

I'll be participating in CrisisCampDC, taking place at 9am Saturday at the Sunlight Foundation in downtown Washington. Check out this invitation page for more details. I'm helping out specifically in creating a wiki similar to our 2008 HurricaneWiki.org project, though focusing on a wiki that can be used for Haiti and future emergencies as well. Meanwhile, there are also camps scheduled tomorrow in Silicon Valley, Los Angeles, Brooklyn, London and Denver. Hope you can join us!

By Kim Bryant

Bugzilla, Gojira... issue tracking software manufacturers must have a thing for Japanese sci-fi. All monster-lizard monikered apps are not created equal, though, and our challenges hardly resembled Hello Kitty.

The Digital Media Applications team used Bugzilla for about 4 1/2 years to file bugs, note future enhancements, and keep a general record of past fixes. Besides the Digital Media technical staff, some editors and interns also filed bugs in Bugzilla. Careful thought went into designing the fields so the information gathered would be as complete as possible, including details on platforms, browsers, and components. Items were selected from Bugzilla for upcoming releases, but the product owners often kept separate lists of "their" bugs in Excel or Word so they'd remember what was most important to them and their area.

By January 2009, Bugzilla had become a giant to-do list that kept growing exponentially. There were 3,000 open bugs when we started prepping for the switch to Jira, and many of those were no longer valid. It was hard to search for specific issues, and non-technical staff members were intimidated by the number of choices in field drop-downs. Bugs were often missing key information as a result and duplicates were accidentally missed. When developers added comments or a request for details to a bug, it was often overlooked or ignored because Bugzilla emails were sent to a large distribution list. Before a release, we had to contact reporters in a separate email or call them so they'd know when their bug was fixed and ready for them to test.

Why we decided to go Jira (please groan at bad pun now), after the jump

2. Integration with other developer tools: We added several applications in the Atlassian suite to our toolbox, including Confluence, a wiki we use for technical and product information. Confluence macros pull in a wide range of Jira data; we use it to display lists of Jira issues in a specific release, for example. We've configured Crowd, Atlassian's solution for single sign on (SSO), so that our users log in to the Atlassian suite using their existing NPR Active Directory account. We've extended Crowd so that we can log in the same way to our in-house content management system. We're also using Atlassian's code review tool (Crucible) and source code repository (FishEye). Our commits to SVN include Jira issue numbers, so when we're in Crucible we can easily click links to Jira tickets and see details on code changes, as well as see what Jira tickets affect which files.

3. A smorgasbord of custom configurations: We're able to serve high, medium, and low-level details depending on the user type and needs, and we've set up some interesting plug ins, business rules, and processes. We configured a dashboard metrics view for managers. We've designed different workflows for each type of Jira project ("project" is a Jira term for a bucket of like requests). We turned on time tracking, not to Big Brother our staff and squish every last ounce of productivity out of them, but so we can put an estimate on requests and see how long it actually takes us to complete the task. This should improve our LOEs in the long term and sets expectations with requestors in the short term. I could talk about custom configs until the cows come home, but most folks start mooing for mercy after five minutes. If you want to know more, comment on this post and I'll reply.

4. The ability to track as much of our work as possible: We've got production requests (no backend release required), full-blown projects, and strategic work for designers and IAs that takes weeks or months. We have infrastructure enhancements, system administrator tasks, and graphic requests for stories running in 24 hours. All this work is now logged and tracked in Jira, and we're getting better at seeing the overall picture of requests. Different product owners are starting to group related issues together when asking for a fix. For example, the search and blogs product owners recently found four issues that, if done together, would take less time than if they were executed separately.

5. Statistics to make an ops manager weep for joy. We track trends like number of issues submitted vs. resolved in a thirty-day period, which can help us spot spikes that may indicate problems with a specific application. Another area we watch is workflow states per resource group. As of the time I polished this post for publication, our small but mighty User Experience team had 121 open issues, so we may need to set expectations that these requests could take longer to address. We can use burndown charts via GreenHopper (an Agile plugin that Atlassian recently purchased) for some projects to track and predict if we're going to complete all the work for a given release by the deadline. We're still getting our feet wet, but Jira stats are going to help us take corrective action sooner and plan better.

In my next post: some of the down-and-dirty fine points on how we've set up Jira at NPR.

Earlier this week, when our Washington office was closed and buried under two feet of snow, we compiled and released our first Android app to the Market, Android's version of the iTunes app store. Within seconds, the app was live to the world. There was no lengthy approval process, no request that the app more closely conform to the UI conventions of the operating system, not even a quiet suggestion from Google for how we might make our app perform faster. For a piece of software built by an old-media company, it was a bazaar beginning.

Coder-philosophers out there might have already caught my allusion to Eric Raymond's essay, The Cathedral and the Bazaar, the seminal work on the intellectual underpinnings of the open source software movement. Raymond's essay challenges the old notion that "the most important software...needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time." Rather, developers should "release early and often, delegate everything you can, be open to the point of promiscuity" and rely on a developer community that resembles "a great babbling bazaar of differing agendas and approaches."

When I compare the iPhone to the Android, I feel as though I am handling the tangible instantiations of these two abstract ideas. The iPhone is an exquisite cathedral, a bastion of controlled design, where everything functions with over-wrought precision. The Android is, of course, the bazaar. Managed by the Open Handset Alliance, the Android operating system comprises the collective contributions of carriers, handset manufacturers and software developers. In many ways, the battle between the Android and the iPhone is more than a battle for market-share; it is a battle of ideas.

NPR chose to approach these two philosophically-opposed operating systems in kind. Our iPhone app was a work for hire, built by a specialist app developer recommended to us by Apple. The code remains proprietary, and we have no plans to open this code to the world. Our Android app, in contrast, was built by Google developer Michael Frederick as a 20% project, as Google allows its engineers to spend 20% of their time on projects they're passionate about. This was not only a gift to NPR, but a gift to the world: in the next few weeks, our Android code will be open-sourced under the Apache license. That means that anyone in the world can steal our code and use it, in part or in total, in whatever project they want.

And there are some really good things to steal here. I'll let you be the judge of where the most valuable code resides (just search for 'NPR News' in the Android Market), but my favorite part of the app is the player tray, the slide-up tool bar that allows you to see what's playing and interact with it, no matter where you are in the app. That was Michael's idea, and it seems unlikely that we would have landed on that idea had we taken the top-down 'cathedral' approach to designing this app.

To be sure, this is not the iPhone app: there are no live streams from stations, no program guide showing you what's playing on stations right now, no sharing tools. With the iPhone app, we tried to release perfection. With the Android, we were more concerned with creating tight code. Tight code means lightweight development, a virtue that will support the open source community that we hope to build around the app. In short, our plan was to build the kernel and leave plenty of room for growth.

We hope you enjoy our work in progress and, if you really like it, we hope you'll progress our work.

This morning, David Kaplan of Paid Content noted that today's re-launch of the NPR mobile site is "part of a larger strategy designed to ensure that its member stations don't get lost in the listener transition from over-the-air to digital." Kaplan got that right. While we're excited by the new features at NPR Mobile, we're even more excited by the seismic change in our mobile strategy that it represents.

But first, I want to gloat a little bit about the new features. Today is the first time our mobile Web audience has ever been able to:

• stream live signals from nearly every public radio station in the country, from Anchorage to Bangor

• listen to hundreds of public radio programs (not just the handful we offered before)

• hear full-quality audio over the Blackberry

It's a big day for public radio fans everywhere.

Although these changes are valuable, the most important benefit of the new mobile site will come in the weeks ahead, as we take advantage of the control and flexibility of our new platform. Unlike our previous site, which was developed and hosted by a third-party provider, our new mobile Web site is hosted entirely by NPR, and we have made a commitment to carry on future development in-house.

And that is no small challenge. Remember the browser wars? Back in the late 90s, before software manufacturers embraced the Web standards we enjoy today, Web developers had to create a different Web site for every web browsing program. With the emergence of the mobile Web, browser wars are back in a big way. Now that there are hundreds of mobile devices, each with its own browser and software limitations, developers are faced with a complex dilemma. Do we build something mediocre that works everywhere, or do we push the limits of the technology by building for only the best devices?

To answer that question, NPR turned to Conmio, a mobile software company based in Finland. Conmio began by considering how we could build upon the success of our existing mobile Web site, which was launched in 2007 by Crisp Wireless and won the 2009 Webby for best mobile news site. But Conmio also pushed us to expand the feature set and content offerings of our mobile Web site.

The result is a site that works on even the most basic feature phones, but also offers advanced features for a select group of devices, such as iPhones and Androids. The mobile site also extends our content offerings to encompass all the full text stories and audio in our archive, including Car Talk, All Things Considered, and many music segments previously unavailable over mobile. None of this would have been possible without some big help from Conmio's head of Technology, Lauri Piispanen.

We will still lean on Conmio from time to time, new features will be built and coded by our Java team, with all mobile development led by NPR's own Joanne Garlow. When mobile was an experiment, we looked outside our building for expertise in this technology. As mobile becomes the future of radio, we need to understand the technology ourselves.

In a few weeks, we'll begin tweaking the mobile Web site, but before we do that, we need to know how you're using it. Are you listening to a playlist on your morning jog? Are you selecting your local station and listening to live coverage in the car? Maybe you're using it to pipe your favorite music station over your home speaker system. If you're not doing these things, give it a try. And if you are, let us know what works and (more important) what doesn't.

For more on today's mobile Web site launch, check out NPR's press release, as well as some of the related coverage by mocoNews and TechCrunch. And coming soon: details on our forthcoming NPR News Android app.

By Jon Foreman

Today we launched an NPR extension for the Google Chrome web browser. Powered by the NPR API, the extension displays the latest headlines for various topics, allows users to set up custom news feeds and provides a streamlined listening experience.

For custom news feeds, you can set up tabs featuring headlines associated with a keyword. So if you are interested in news about Russia, for example, you can go to the extension options, enter the keyword 'Russia' and a new tab will be created listing headlines associated with this topic.

For stories that have audio, you can listen with a simple click. The audio continues to play as you browse through any web site. The audio player uses HTML5 to play the story. HTML5 audio tags allow one to play a clip directly from the browser without any additional audio streaming software, like Flash or Windows Media Player.

To try out the extension, you'll need the beta version of Google Chrome. After that is installed, go to the NPR extension page and install it.

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.

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.

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.)

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:

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.

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 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.