Timelines, video screen capturing, live chats and more

A bunch of cool stuff has happened since my last blog, so this will be a bit scatterbrained.

First off, The Tribune made a major improvement to its photo viewer, which has been extremely successful by early indications. I made a video to show readers all the new features:

Whereas past videos I’ve done have been shot with an HD digital video camera and edited on Final Cut Pro X, this one required a different approach. Shooting a video screen of any type is likely to lead to blotches of pixels showing up in your video, which is distracting to say the least. I looked at several free options for screen capture software and came across screencast-o-matic.com.

While the name is horrible, the software is not. The free version lets you save up to 15 minutes of video per clip, which of course it watermarks with a logo in the corner. But get this, the pro version is only $12 for a year! No watermark, no limit. You can video capture your screen quickly and easily from a web-based client (meaning multiple people at the paper can use the same $12 account) and save directly to a variety of places, including YouTube, or to a file on your desktop.

I also used this software to convert a proprietary video for close-circuit TV to a universal format. I just set the screen capture tool to the size of the video as it played on the screen and then saved it out to a file on my desktop. That’s useful for police or jail videos that may be based on older systems.

Next, we’ve done a few live chats lately. We’ve done them before with various technologies, and varying degrees of success. One was a Twitter-based live chat about home-schooling and polygamous communities. It was pretty successful, and the two reporters who worked on the story both answered questions in a text-only Twitter chat for more than an hour.

Then I did a video chat regarding comments moderation on sltrib.com. This one was using Ustream for video and CoverItLive for the text portion. That worked well, although we learned that when you set up CoverItLive you have to set “guest comments allowed” before you go live, otherwise it won’t allow them later. So that chat I think could have been more successful had we not boxed out people who didn’t want to sign in using Twitter or Facebook. We have since done several of these chats with our Jazz beat reporter, who has done a fantastic job with them. The beauty of the video chat vs. a text chat is you can convey so much more over video than you ever could in text. Brian Smith can really crack open his wealth of knowledge when he can freely speak, whereas if he had to type all of it he would only get through two questions in an hour. The question by text / answer by video format is, for me, the smartest use of the medium.

The third option, and one I think has a lot of promise for other applications, is Spreecast. I was the producer for a Spreecast chat with Kim McDaniel of @sltrib, Trey Fitz-Gerald of @RealSaltLake and Tauni Everett of @RideUTA. Spreecast allows you to have multiple video participants appear on screen at the same time. You can have up to four people appear on camera at a time (and who appears is determined by the producer), and it also includes text chat for viewers, the ability to pop questions up on the video screen for participants and speakers to see, and a chance for viewers who want to appear on camera to do so. The chats are automatically archived (though you can tell it not to show up for anyone) so they can be seen later. There’s a whole host of great ways you can use this technology, and all that’s required for speakers is a webcam and maybe some earbuds. You can bring together speakers from different areas easily into one seamless chat. Really, really cool. (Note: This is Flash-based, which knocks out iPad and iPhone viewers, and we tried to add someone from a mobile phone connection, and that just wasn’t happening. However, Ustream has a great mobile app for embedding video from the field.)

Another feature we’ve always wanted was a good interactive timeline builder. I’ve looked at dozens of them online, and the best one I could find was Dipity. But to really use Dipity hard-core was expensive, and it can be buggy. Plus, it’s not like interactive timelines are necessary for every story. They’re really a big-project sort of item, and not something we would use more than a handful of times a year. So paying hundreds of dollars for a relatively little-used, online-only feature is a tough sell. Enter Verite.

This timeline is way better than the vast majority of tools I had found, and comes pretty close to Dipity for overall elegance. It’s still in its infant stages, I believe, but it works great and IT’S FREE. There’s a little bit that has to happen on the back end of your site if you want to host your own timelines, but we’ve managed to get it up and working with little trouble. The whole timeline is built in a Google Spreadsheet with a specific format, then you publish the Google Doc to the web and plug in the ID. You can use the embed generator if you don’t care about hosting the timelines yourself.

These tools are way cool, way useful and way cheap or better. I can’t wait to start getting more out of them in the very near future.


Why crowdsourcing won’t save journalism

Many big-thinkers in journalism rightly point out the traditional media are no longer gatekeepers of information. We no longer have a stranglehold on the pipeline. We are but one cog in the machine, albeit still a much bigger cog than many people realize.

With so much of the population constantly plugged in and able to report what’s happening around them, many of those big-thinkers say some day soon we will “harness the power of the crowd” to report the news.

After all, what could be better than mounds of free, timely information supplied by eyewitnesses from every corner of the globe?

How about accurate information.

Some colleagues and I recently took on a pretty cool project, testing the cellular data networks around Salt Lake City and creating a few maps to show the results. Despite technical issues with getting the data to display how we wanted, I think the results were great. We also asked readers to pick up where we left off, by testing the mobile network speeds on their own and entering the results into a form that we would turn into an online map.

It’s only been up about 24 hours at this point, but I’m pleased to have gotten 26 reader responses plotted. I didn’t expect it to go crazy, but I wasn’t sure it would even be this successful. But those responses also lay bare the biggest problem with crowdsourcing: You can’t trust it.

The instructions are explicit. I tell readers the exact format to enter dates, addresses and the speed readings they got in kilobits per second. About 70 percent of people did it right. The others gave me an address but no city and state; some gave readings in megabits per second instead of kilobits (despite the word being in capital letters); one person neglected to put numbers in the speed fields, instead writing “kbps”; and a few clearly had wifi connections when they ran the speed test, reporting numbers so far out of the realm of a 3G connection that I should delete them, although I won’t. I did convert the ones that were sent in Mbps to Kbps for consistency, and I did add in city and state when those were missing. I deleted the ones where the information was completely wrong. In other words, I did some basic editing.

Do I consider this experiment a failure? Absolutely not. In fact, I’d say it’s a mild success. We engaged readers and asked them to contribute to our body of facts. But had I asked the crowd to do all of my research instead of having a technology reporter hit the streets and run the readings, I would have ended up with a story that wouldn’t meet my paper’s standards. Perhaps 70 percent or more of it could have been wrong, and frankly I can’t vouch for the numbers we got that do look accurate.

This was a very simple assignment. Download an app, push a button to run the test, send the results in a specific format. If an editor can’t trust the information that comes in with something that basic, why should he or she trust the crowd with anything more serious?

Smartphone apps every news reporter should have and how to use them

You’re in the field. News is happening. Your editor wants a story, pictures and video stat, and your Twitter followers are waiting for the latest update. Keeping up with today’s news demands can be a challenge, but there are several ways news gatherers can stay ahead of the game.

To be effective in the field, you have to have the right tools and the knowledge of how to use them. Here are my tips on which apps reporters should have and how to use them effectively. Several of these are built in to the phone. I run Android, as do most reporters in my newsroom, but my suggestions should all have iPhone counterparts.

The first thing I recommend is having a “reporting home screen.” Smartphones usually have several pages of screens where users can drop widgets, icons and folders. You should consolidate all of your basic reporting tools into one screen (or folder) so you won’t be searching through a mass of applications in the heat of the moment. My reporting home screen is one swipe to the left of my main screen. Here’s what it looks like (killer Bruce Buffer background optional):

At the tippity-top is a Google search bar for quickly searching the Web (complete with voice-recognition option).

Obviously, the first two icons are shortcuts to my phone’s camera and video functions. Sure, you get to them essentially through the same app, but I want to quickly go to the function I need when news is happening, which is why I have a shortcut for each option.

Next I have the maps function, which is handy for finding out where you are or where something else is. This works in conjunction with both the GPS toggler — which turns your battery-sucking GPS function on and off — and Navigation — which is the turn-by-turn direction feature built in to most smartphones. A neat feature you may not be aware of: On Google Maps you can send a map to someone’s phone directly. This is useful if you are an editor sending a reporter to a breaking story because you can share the exact address via Google Maps. The reporter gets a text message with a hyperlink to the address, which opens in Maps. They can then activate turn-by-turn directions and be on their way.

Plume is my Twitter client. I use AIM for private messages with other reporters or editors, though you could use text messaging for that, too. Next up is Google Translate, which is a semi-useful real-time translation app I’ve covered previously. There’s also a voice recorder for sound bites or interviews. Ustream is my preferred live-streaming app and has the added bonus of allowing you to save your live-stream video for later embedding on your site.

Scanner Radio offers access to streaming police scanner traffic from around the world. It uses the same scanner feeds as RadioReference.com, so check those to see how well covered your particular area is on that front. This can be really helpful to listen to if you’re trying to find out what’s going on during a breaking crime story or public emergency.

The last slot on my reporting home screen is Dropbox, a file-sharing service that allows you to move files between your phone and desktop or laptop computer, as well as allows you to share file space with others in your office.

These are by no means all of the apps you will use as a reporter. Many people swear by Evernote, and that’s definitely one to check out as it allows you to access a lot of information between your phone and computer, among other cool things. You could use Evernote to store a copy of your source list so that you’re never without it.

You could also have a folder with bookmarks to websites you may use frequently for your job.

The key is to practice using the apps. Shooting video is no good if you can’t get it to your readers, and installing Ustream is pointless unless you’ve already set up an account to go live immediately and have a plan in place for getting the stream’s embed somewhere on your site when news breaks.

I suggest running the following drills to ensure you’re ready when the moment strikes.

1. The House Fire: Take a usable photo, send a tweet and upload a 20- to 30-second video within about five minutes (data speeds will affect your timing). This is a pretty good possibility for any news situation. If you can take a photo (and either email it to your editor or photo desk / or post it to Twitter), tell your readers what’s happening and then upload a short video to YouTube, you’ve covered a lot of bases quickly. While the video is uploading, you can put on a traditional newsgathering hat and start tracking down more information. Again, key here is having your YouTube account information saved already so that you can quickly upload and someone on your web team or your editor can get that video in front of your readers.

2. OMG!: Sometimes you’re just minding your own business and all of a sudden you notice something serious is about to go down. Maybe a fight is about to break out among City Council members. Perhaps some sports rivals are getting into a heated exchange. Maybe  supporters are getting out of hand outside a courthouse. Whatever it is, you can sense something newsy is about to happen. Like a Wild West gunman, you grab your phone from your pocket and begin live streaming. You want to get from pocket to streaming in under 20 seconds. (You can set up a private “test” channel for this exercise.)

3. Go! Go! Go!: Have your editor send you directions from Google Maps to your cell phone. Then load that address into your phone’s turn-by-turn directions app.

4. Si. Yes.: Take Google Translate for a spin. Find someone who speaks another language as well as English and try to hold a conversation with them using Translate. The results may not be pretty, but you should know how well it works before you need it for real.

5. For safekeeping: Record audio and upload it to your Dropbox account. Then download it to a computer.

Finally, readers will look at your PDFs

PDFs have long been a double-edged sword on our site.

They’re great because you can give readers so much more information without cluttering up your story with a bunch of numbers or names or extraneous details better suited for a sidebar or graphic. But as interesting or useful as that information may be, sticking a link to the PDF file in the story has never panned out traffic-wise. Readers just don’t seem to care enough about the information to click the link (or don’t notice it’s there because they don’t read every word) to get all that goodness.

Now we have a workable solution that won’t completely clutter the story. We’re using Scribd to embed documents inside the story text just like we do videos. The early returns are great. Far more people are reading the material in the few PDFs we’ve embedded than ever did through traditional linking.

So if you’ve got a PDF, text document of nearly any flavor (including those you can’t read because you don’t have the software) or PowerPoint presentation, it can now be shared in a meaningful way. Check with your friendly Web editor for details.

I speak 63 languages, and you can, too

I’ve been playing around with the Google Translate app for my smartphone. It allows you to type or speak into the phone and translate what you said into 62 other languages. I doubt I’ll ever need to converse with someone in Azerbaijani, but should the need arise, I could get by.

At this point, the app works fantastic translating English into other languages. Where it falls short is translating that language back to English. I hope updates will remedy this.

This app really has promise for the reporter out covering a story who needs to communicate who they are and why they’re there with someone who doesn’t speak the same language. Crime reporters often run into this bind. Sure, The Tribune has several bilingual English/Spanish speakers, but if you don’t know you need a Spanish speaker until you’re trying to talk with the main witness, it doesn’t matter who’s on the staff list.

To use the app (which is available for iPhone, as well, though the functionality may differ) you simply tell it which language you’re going to speak and which language you’d like to translate to. Then you type or speak what you’re trying to translate.

Sweet. Not only can I order some Schokolade in German, I can even have my phone say it for me if I’m a little nervous about declaring myself a jelly donut. Click the speaker button next to a word and a robotic lady’s voice does the hard work.

Translating one word is all fine and well, but that’s going to take too long on deadline. See that “Enter Conversation Mode” button at the bottom? Click that and you get something like this:

Yes, we’ve switched from German to Spanish. When in conversation mode, the app switches between the two languages so that each speaker my respond to the other and have it properly translated. As I mentioned, the translating to English is rough to say the least. The English to Russian and Russian to English were actually good. The English to Spanish translation was spot on, but the Spanish to English didn’t even give me something to work with. I found the same with German and Czech. All bilingual speakers say the app’s accent is great and they had no problem understanding what was said. But when they spoke in the other language, the English translation wasn’t even close.

So at this point I wouldn’t try to do a hostage negotiation with Google Translate, but I’d be very comfortable trying to tell someone who I am, why I’m there and how they might be able to help me. Even if their translation to English doesn’t seem to work, you’re at least further along in the process than you would be without the app.

Another beta feature is the ability to write characters for some languages. This has got to be the most painfully slow way to have a conversation, but at least it’s an option. You draw the characters with your finger and it converts it to text. It looks like this:

I would suggest everyone with a smartphone download this app, and then play with it — especially with someone who speaks another language as well as English — before you actually need to use it. You never know when you’ll need to be fluent in Yiddish.