Every month, in the U.S, about 5 billion text messages are sent.
Most of these messages are personal. Many of them are mundane.
But we're going to start seeing them used for everything from updating your location on a map, to reporting on breaking news.
These new possibilities have arisen because of new services that break up our messages into archivable, exportable, searchable micro-chunks. These services have names like Jaiku, Twitter, Tumblr, Pownce, Hictu, and Moodmill. And while you can use them over any computer, they really come in handy when you can use them on a mobile device.
Soon there will be many more services like these. And people will prefer using a web-based message service of their choice to send messages over the canned text-message software that is pre-installed on these phones.
Why? Because these services let your messages be a lot more than just a one-way, direct message. By implementing API platforms, the services allow web developers to do useful things with your messages, like plot them on a map or a timeline, send them out to the social sites you use, or even help you report news.
Well, the reporting news thing is what I'm working on.
I've been inspired by pro-am projects like Assignment Zero and CNN's I-Reports to create a service that looks through all messaging services for items that look like breaking news, adding new data about what kind of news they are, and then making those breaking news items available to anyone that would like to use them - like CNN, and the AP, and Assignment Zero.
But I've ran into a problem. There are way too many messages. We're talking in the millions, and soon, in the billions.
Even if I could afford the hefty processing power needed to manually perform content analysis on each incoming message, there would still be many false-positives.
And for a breaking news wire service, false-positives are not an option.
That's why we should be talking about best practices for breaking news.
These best practices are standardized tags that you can use to describe your reporting.
Remember 30-30? You learned it in school, and you probably don't use it. It's a tag that is supposed to help people know when your story is finished.
The best practices I'm referring to are sort of like 30-30, although they can be a lot more useful.
By including recognizable tags in your message content, automated bots sitting at the API switchboard can figure out the best way to route your message.
For any messages that are likely being sent over mobile devices, these best practices should probably be short (2-4 characters) and in plain-text characters.
For breaking news, I'm suggesting that the 2-character br tag be written at the start of the message.
And if you're writing about a location in your news item, I'm suggesting the three-character loc tag.
I like those tags because they seem to be easy, and easy to remember. Exactly what we're looking for in best practices.
But breaking news is just the beginning of how pro-am journalism can bridge the gap between reporters and API developers. If you add recognizable tags to your reporting, web programmers like myself can then design services that make supplementary infographics for your story, or add related information as it arrives.
The end result is that your reporting work gains richness, depth, and distribution.
As both a journalist and a developer, I'm confident that we can create a distributed pro-am system that rivals the largest news organizations in the world for breadth and scope of content.
We, the programmers, will try to keep it simple.
Maybe you can help make sure of it.
